なぜコーディングエージェントはコードベースを悪化させ続けるのか
概要
HumanLayerのCEO Dex Horthy氏が、AIコーディングエージェントがコードベースの保守性を悪化させる問題を、ベンチマーク「SlopCodeBench」を軸に議論する対談。オンライン上の「エージェント活用術」の多くは見せかけであるとし、トークン使い切り競争や100倍生産性ではなく、2〜3倍の改善を積み重ねる現実的な姿勢を提案している。後半では自身のエージェント開発ワークフロー(ほぼワンショットのPR、夜間に動くクリーンアップボット)を紹介する。
主なポイント
- SlopCodeBench: グリーンフィールドで作らせた後に機能追加を3〜10回繰り返し、コードベースが時間とともに劣化するかを測るベンチマーク。全モデルで失敗テスト数が増加傾向になる。研究室(ウィスコンシン大学)が開発し、実行が遅く高コストなため普及は限定的。
- 従来ベンチマークとの違い: SWE-benchは小さなPR単位、マラソン系は巨大タスクを最初に全部与える、Cognition式は規約違反を審査モデルが採点する。いずれも「問題の全体像を事前に与える」点が実際の開発と異なる。
- モデルの改善は当てにできない: 「そのうちGPT-7が解決する」という姿勢は通用していない。各ラボはコンピュータ操作など別領域を優先しており、保守性の最後の10%は最初の90%と同等以上に難しい可能性がある。「将来のモデルに期待してコードベースを抵当に入れない」が助言。
- 決定的ツールの限界: 循環的複雑度などのリンターで大量のスロップは防げるが、保守性を人間なしで高めるプロンプトやツールは見たことがない。アーキテクチャ改善スキルも人間が方向修正できて初めて有効。
- 「テイスト」は人間が持つ: 深夜障害対応などで悪いアーキテクチャに苦しんだ経験が判断力になる。RLにコード削除や抽象化の統合タスクを入れてほしいという声もある。若手はメンターシップや、エージェントを使ってコードを理解する宿題で育つ。
- 設計ドキュメントを早期にレビュー: 一発で完璧な計画は作れないが、1ページ概要(上空25,000ft)→詳細設計(10,000ft)と段階的に悪い解を除外し、PR時の手戻りを0〜10%に抑える。設計ドキュメントは実質プロンプトなので、そこへのコメントが教育にもなる。
- 大規模組織でのPM向けパターン: 2文のプロンプトから、200リポジトリを横断して関連7つを調査し、「どんな課題か」「成功指標は」と質問攻めにするパイプラインでPM仕様書を作る。10ページのAI生成文書が現実離れする問題を防ぐ。
- 生産性の現実的目標: 全エンジニアが2〜4倍速くなるだけで社会的に大きな価値。100倍を狙って既存のエンジニアリングを全部捨てるのは失敗する。2〜3倍を複利で積み上げる。「トークンを使い切った自慢」やダークファクトリー信仰の多くは誇張。
- PRとレビュー文化: プロセスより文化が勝つ。承認者ではなく「書いた本人が全責任を持つ」文化が重要。AI生成コードへのレビューコメントがそのままエージェントに貼られるだけだと学びが生まれない。
- Dex氏のワークフロー: 作業の50〜60%は事前計画なしでほぼワンショット(数百行以下)。PRの約10%は夜間のジャニターボットがマージ。サーモスタットのように「あるべき状態」へコードベースを寄せる制御ループで、毎朝複数のクリーンアップPRが届く。
実践に使えること
- 小さな変更(数百行以下)は計画なしでエージェントに任せ、大きな変更は1ページの設計ドキュメントを作って同僚にレビューしてもらってから実装に入る。
- 設計ドキュメントに「必ず答えるべき質問」(目的・成功指標・対象リポジトリなど)を定型として入れる。
- 複雑度などの決定的リンターを導入しつつ、保守性の最終判断とリファクタ方針は人間が行う。
- 夜間にリファクタや整理を行うバックグラウンドエージェントを試し、朝にPRとして確認する運用を検討する。
- 生産性目標は2〜3倍の積み上げとし、トークン消費量ではなく出荷物で評価する。
- 新人育成では、レビューコメントで答えを教えず「なぜこうしたか」「他に同じパターンはないか」と問いかける。