LLMが生成したコードを手動で打ち直すことで「認知の負債」を防ぐ

AI支援コーディングにおける「認知の負債」の問題

大規模言語モデル（LLM）にプロジェクト内の大規模なコードブロックを自動生成させ、そのまま挿入させることは、「認知の負債」を生み出します。これは、開発者が自分自身のソフトウェアがどのように構築されているのかを根本的に理解できなくなる状態を指します。AIアシスタントは開発の「退屈な部分」を加速させることはできますが、コードを書くことから、単にAIが生成したプルリクエストをレビューする作業へと移行することは、深い理解の喪失と、システムの断片化されたメンタルモデルをもたらすことがよくあります。

AIが生成したコードのレビューは、過度に防御的であったり、コメントが不足していたり、あるいは微妙に誤ったロジックを精査することになり、しばしば不満の残るプロセスとなります。成果物と同じくらい創造のプロセスが価値を持つ個人プロジェクトにおいて、この「作成者からレビュアーへ」という変化は、開発の楽しさを奪い、著者が完全に理解していないソフトウェアを生み出すという、プロフェッショナルとしての過失を招くリスクがあります。

解決策：手動での打ち直し

認知の負債に対抗するため、Ankur Sethi氏は、LLMがプロジェクトファイルを直接変更することを禁止するワークフローを採用しています。その代わりに、LLMはチャットインターフェース上で修正案を提示し、開発者はその修正内容を手動でエディタに打ち込みます。

実装戦略

Sethi氏は、この境界線を維持するために、AIエージェントに対して特定のシステム指示（system instructions）を使用しています。

このプロジェクトに組み込まれるすべてのコードの行を理解したいと考えています。私が明示的に指示しない限り、プロジェクトファイルの作成、編集、移動、名前変更、または削除は決して行わないでください。代わりに、提案されたすべての修正内容をチャットで示してください。そうすれば、私が手動で打ち込むことができます。

私が明示的にそのアクションを要求しない限り、プロジェクトファイルを変更したり、依存関係をインストールしたり、リポジトリの状態を変更したりするコマンドを実行しないでください。代わりに、それらのコマンドをチャットで示してください。そうすれば、私が手動で実行できます。

私は経験豊富な開発者です。明示的に尋ねられない限り、構文、API、プログラミングの概念、または実装の詳細について説明しないでください。

手動入力のメリット

このアプローチは、AIによるスピードアップ（潜在的な「10倍」の向上から、およそ「2倍」への低下）を減少させますが、いくつかの重要な認知的利点を提供します。

メンタルモデルの構築: 各行を打ち込むことで、開発者はコードベースの空間的なマップを構築し、機能がどこにあるのかを正確に把握できるようになります。
ハルシネーションの検出: 強制的にスピードを落とすことで、素早いスキャンやdiffレビューでは見逃してしまうような、不適切な設計の選択やAIのハルシネーションを特定しやすくなります。
能動的な学習: このプロセスは、教科書から例題を書き写すといった伝統的な学習方法を反映しています。書き写すという行為が、開発者に未知のAPIやアルゴリズムについて立ち止まって調査することを促します。
カスタマイズ: 開発者は、打ち込みながらリアルタイムで、自分の好みに合わせてコードをリファクタリング、再構成、および適応させることができます。

コミュニティの視点と反論

この提案は開発者の間で大きな議論を呼び起こし、深い理解を優先する層と、コーディングを高度なオーケストレーション・タスクとして捉える層との間の隔たりを浮き彫りにしました。

賛成意見

多くの経験豊富な開発者は、この「スローコーディング」の習慣はLLM以前の時代にも一般的であったと指摘しています。

"Stack Exchangeの時代には、システムに何を付け加えているのかを理解するために、見つけた回答を常に手動で打ち込んでいました。" — @bandrami

また、「生成効果（generation effect）」を挙げ、受動的な読解と比較して、テキストを生成する行為（たとえコピーであっても）が知識の定着を向上させると示唆する人もいます。

批判的な視点

批判的な人々は、再入力は実際の推論の代わりにはならず、開発者がロジジックの起点となっていない限り、認知の負債を防ぐことはできないと主張しています。

受動的な消費: 一部の人は、再入力は単なる「塗り絵」のようなものであり、真の学習には、構文的に正しいが「意味的に空虚な」回答を書き写すのではなく、意味を能動的に構築することが必要であると主張しています。
抽象化のシフト: 一部の開発者は、業界がより高いレベルの抽象化へと向かっており、「行単位」の理解は、AIエージェントを操る能力よりも重要ではなくなりつつあると考えています。
非効率性: 批判的な人々は、もし開発者がAIのコードを打ち直し、修正するために深く考える必要があるのなら、最初から自分でコードを書いたほうがよいはずであり、LLMを完全に排除すべきだと指摘しています。

代替的な緩和策

スピードと理解のバランスを取るために、いくつかの代替的な戦略が提案されました。

スキャフォールディング（足場かけ）: LLMを、高レベルの構造（クラス、インターフェース、関数シグネチャ）の生成のみに使用し、ロジックの実装は手動で行う。
テスト駆動AI: LLMにまずテスト（Redテスト）を書かせ、次にそのテストをパスさせるためにコードを手動で実装する。
ハイブリッドアプローチ: LLMを調査や学習のために使用するが、実際の、実装においては「エージェントによるコーディング」を禁止する厳格なルールを維持し、「コーディングのセンス（coding taste）」を保つ。