発生日：2026年8月3日。 あるソフトウェア開発者が、大規模言語モデルをプログラミングに利用する、意図的に速度を落とした方法を提示した。それは、チャット画面上でアシスタントにコードを提案させた後、すべての変更を手作業でプロジェクトに入力するというものだ。アンクル・セティは、この手法により、日常的な作業の時間を節約しながら、開発者がコードベースを理解した状態を保てると主張している。

セティは、大規模な自動変更を受け入れることのリスクを「認知的負債」と表現している。彼の説明では、コーディング支援ツールに機能全体の実装を依頼すると、その機能が一見正常に動作していても、人間である担当者が状況を把握できなくなる可能性がある。AIが生成した大規模なプルリクエストをレビューすることも魅力的な代替策ではないと彼は書いている。レビュー担当者が、過度に防御的であったり、説明が不十分であったり、微妙な誤りがあったりするコードをたどらなければならないためだ。

彼の代替策は、個人プロジェクト全体で使用する指示に組み込まれている。明示的な許可がない限り、アシスタントにはファイルを作成、変更、移動、削除しないよう指示する。提案する編集内容や状態を変更するコマンドは会話内に表示し、セティ自身が入力または実行できるようにしなければならない。こうした制約によって、モデルはリポジトリを直接制御するのではなく、助言役にとどまる。セティは、知らないAPIやアルゴリズムが出てきた時点で立ち止まり、提案を自分のコードに取り込む前に、文書を調べたりアシスタントに説明を求めたりできる。

この手法では、自律型コーディングツールの目玉とされる生産性の多くが犠牲になる。セティの推定では、アシスタントを使わずに作業する場合と比べて速度はおよそ2倍になるが、AIコーディングについて時に主張される、はるかに大きな向上には及ばない。それでも彼がそのトレードオフには価値があると考えるのは、コードを手作業で入力することで、APIを確認し、アルゴリズムに疑問を呈し、ハルシネーションや弱い設計判断に気付くための時間を強制的に確保できるからだ。また、提案を取り込む過程でリファクタリングし、調整する機会も生まれる。

セティの見方では、第2の利点は空間的な把握である。一つ一つの編集を自ら行うことで、どこにどの機能があり、新しい作業が既存のコンポーネントとどのようにつながるかについての地図を頭の中に作ることができる。こうした把握は後の保守に役立ち、アシスタントに対してより正確な指示を出すことにもつながり得る。彼はこのプロセスを、学習者に昔から与えられてきた助言になぞらえている。つまり、本やフォーラムの例を考えずに貼り付けるのではなく、自分で入力するということだ。

この提案は個人的な作業手順であり、手作業での再入力があらゆるチームやプロジェクトを改善するという証拠ではない。セティは、この方法が数カ月にわたって自分には有効に機能しており、最大限の処理量よりも理解を重視していると述べる。彼がより広く懸念しているのは、機械への大幅な委任により、ソフトウェア業界が、保守する人々にもその構築方法が十分理解されていないシステムに責任を負うことになりかねないという点である。