AIコードが動作しても拒否する理由

実装の速度がますます速くなるにつれて、本当のボトルネックはAIが生成したコードの量をレビューすることに移っています。これは同僚（とそのエージェント）のプルリクエストだけでなく、自分のコーディングエージェントが作業を終えた後のgit diffについても言えます。良いプラクティスに従っていても——計画モードから始め、大きなタスクをフェーズに分割し、小さな変更を出す——自分で実際に考え抜いていないものをレビューするときには、認知的な過負荷を感じます。

コーディングエージェント以前は、タスクを与えられると、コードベースを探索し、さまざまな解決策を考え、実験し、それから実装していました。これにはすべてのコンテキストを統合するのに数日かかることもありました。最終的にプルリクエストを提出したとき、自信はより高く、同僚に各変更を説明するのも容易でした。

AIを使っても、大きなタスクを完了するにはまだ数日かかることを認めざるを得ません。多くの場合、AIによるすべての変更を拒否してやり直します。最初のセッションと2番目のセッションの違いはLLMモデルではなく、画面の背後にいる人です。解決しようとしている問題を統合する時間が増えることで、AIに主導されるのではなく、AIをより良い解決策に導くことができます。

私はますます、次の理由でAIコードを拒否しています：自分の言葉でアプローチを説明できない場合、diffが問題よりも大きい場合、必要性が証明される前に抽象化を導入する場合、ローカルでは動作するがシステムの理解を難しくする場合、そして自分の理解よりも出力を信頼している場合です。

エンジニアがAI生成の変更をすぐに受け入れすぎることは珍しくなく、AIレビューと合わせて人間によるレビューを必須にすることを提唱する理由です。現実には、実行できてCIをパスするコードでも、悪い解決策である可能性があります。エンジニアリングとは、常に適切でスケーラブルで拡張可能な解決策を実装することです。

私はコーディングエージェントをしばらく使ってきましたが、それらが印象的である一方で、優れたエンジニアが優れた解決策に導くことがまだ必要です。はい、コーディングエージェントはコードを書く以上の方法でこのタスクを助けてくれますが、それはまだ持続可能な方法で自律的に実行できるという意味ではありません。