
2026/08/03 18:32
LLM で生成されたコードを手動で再入力し、認知負債を防ぐ
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
著者は、個人のプロジェクトの楽しさと深い理解を維持するために、コーディングアシスタントの使用を厳格な制約下で行うことに固執している。核心的な原則は、完全な自動化よりも手動実行を優先し、微妙なエラーや混乱を引き起こす可能性のある AI が生成したコメントによる認知負債を防ぐことである。 Entire features を委任すると方向性が失われ、エージェントがファイルを直接編集することを許可するとコードベースの論理が不明瞭になるという膨大な技術的負担が生じる。このメンタリティは以前の考えからの大きな転換であり、数百行に及ぶ不透明な AI コードを見直すことに対する将来のトレンドへの警告である。著者は、素早く但不明瞭な解决方案を受け入れるのではなく、ドキュメントなどの基礎的なツールを習得することを重視する。今後のワークフローでは劇的に変化し、アシスタントはチャットでコードを生成して人間がレビューするためのものとし、明示的な許可なしのファイル改修は厳しく禁止される。このバランスのとれたアプローチは、全権委任の倍程度の速度を実現すると同時に、開発者がプロジェクトへの明確なメンタルマップを維持できるようにしており、開発プロセスを単に結果志向なものではなく、本質的に楽しめるものとして保ち続ける。
本文
AI 開発における「認知の負債」と私のワークフロー:速度より理解を優先する
プロジェクト方針:AI に任せることのリスク
私個人のプロジェクトでは引き続きコーディングアシスタントを使用していますが、「ワンショット」で丸ごと機能を作成させるアプローチには満足感がありません。むしろ、以下の課題に直面することが多いです。
- 複雑性の増大: 一気に行うと処理が混乱し、制御が利かなくなることがあります。
- 認知の負債: AI に放置して任せてしまうと、膨大な**「認知の負債」**を負ってしまうリスクがあります。
- 実装方法を調べるのが嫌いなのではなく、**「どのように機能するかを理解したい」**という根本的な願いが動機です。
- 課題が退屈だからといって、解決策への理解を機械に丸投げすべきではありません。
2026 年の開発者像:レビューの苦痛と個人のプロジェクト
業界では「LLM が PR を作成し、人間がレビューを行う」ことが新たな標準(呪われた時代)として期待されています。しかし、以下の点でこのワークフローには限界があります。
- AI レビューの質: 生成された PR レビューは過剰に防御的であり、記述も不適切であることが多いです。
- 読解の苦痛: 微妙な誤りを含む数百行のコードを読み解くことは、快楽ではありません。
- 雇用主のために嫌々やればよいですが、個人的なプロジェクトにおいてそのような作業はありえません。
- 私たちの喜びは成果物ではなく、プロセスから生まれるべきです。
私の解決策:生成コードを手動で打つワークフロー
退屈な作業を LLM に丸投げしつつも、「スロップマシン(思考を委ねる機械)」化を回避する方法として、私が採用しているアプローチは以下の通りです。
基本方針
コーディングアシスタントにチャット上でコードを生成させ、その後にすべてを手動で編集(入力)することです。これを実現するために、エージェントファイルには以下のような厳格な指示文を設定しています:
- 新規作成・改変の禁止:
- プロジェクトファイルを新規作成、編集、移動、改名、削除することは禁止する。
- 私が明確に指示しない限り、何らかの変更を行ってはいけない。
- チャット上で全ての提案された変更を表示し、私自身が入力するようにする。
- コマンド実行の禁止:
- 依存関係のインストールやリポジトリ状態の変更などのコマンドを実行することは禁止する。
- 私が明示的に要求しない限りは、チャット上に表示させ、私自身が実行するようにする。
- 過度な説明の抑制:
- 私は経験豊富な開発者であるため、明示的な質問がない限り、構文や API の説明を省略する。
- 実装詳細については、簡潔に済ませる。
ワークフローの効果と特徴
この手法は LLM を全く使わない場合よりも**「速い」ですが、「マシンに思考を任せる」方法ほどには「遅い」**です。
- 速度: 10 倍の加速ではなく、おそらく2 倍程度のスピードアップです。
- 得られるもの: その分失う速度に対して、コードに対するより深い理解が得られます。
- 一行ずつ手動で打つ過程で、「どのように動作するか」「既存のコードベースとどう統合されるか」というメンタルモデルを構築します。
- API やアルゴリズムが理解できない場合は、そこで立ち止まって調べたり、LLM に説明求めたりできます。
- 自入力により、LLM の幻覚や悪設計を見逃すことが促されます。
- コードを入力する過程で自然にリファクタリング、再編成、コメント追加が行えます。
メンタルマップの構築
最も重要なのは、このワークフローによってコードベースに対する空間的な地図が形成できることです。
- 機能のすべてが、どこに位置しているかを把握しています。
- 変更が必要な際、正確な箇所を瞬時に把握できます。
- これは作業効率向上だけでなく、将来的にLLM をより効果的にプロンプト化・指示する手助けにもなります。
学習プロセスとしてのコード入力
プログラミング学習時代、私は以下のような指導を受けました。
- コピー&ペーストは禁止: 「コードはコピペしてはいけない」と言われました。
- 実践的学習:
- 本から学ぶ場合は、例題をすべて手書き(入力)し実行可能にすることを確認する。
- ブログ記事やフォーラムからは、自らの環境に合わせて入力しながら適応させることで理解を深める。
「手動で LLM が生成したコードを入力すること」は、まさにこの学習プロセスそのものです。
結論:速度より理解を重視
私はこの手法が最も効率的ではないことは承知しています。しかし、私の優先順位は以下の通りです。
- 生産性 > 理解: ここでは**「生産性よりも理解」**を重視します。
- 継続性: このワークフローを数月以来続けており、成果は良好です。今後もできるだけ長く採用し続けます。
なぜ今、この選択なのか
ソフトウェア業界全体で膨大な**「認知の負債」**が蓄積しており、近い将来に返さなければならない時期が来ると懸念しています。
- 大規模なデジタルインフラストラクチャーの構成法について理解を失う日は来るでしょう。
- 業界全体の方向転換は個人で変えられませんが、少なくとも世に出すソフトウェアについては完全に理解できるようにすることは可能です。
- それ以上のことを求めることは、専門的な悪行とさえ言えるかもしれません。