martinfowler.com の「Exploring Gen AI」シリーズの一編であるこの記事で、Erik Doernenburg は、AI コーディングエージェントに関する報告ではめったに扱われないと彼が言う問いを立てている。それは、生成されたコードが求める機能を実装しているかどうかではなく、その内部品質がどうなのかという問いである。彼は、何年にもわたって持続可能なペースで開発を続けるには内部品質が決定的に重要だと主張し、CCMenu に GitLab のサポートをエージェントに追加させることでそれを検証している。CCMenu は Swift で書かれた既存の Mac アプリケーションで、CI/CD ビルドのステータスをメニューバーに表示し、すでに GitHub Actions をサポートしていた。彼はこの実験を、夏に Windsurf と Sonnet 3.5 で、その後 Claude Code と Sonnet 4.5 で試しており、いずれの場合もタスクをより小さな塊に分割した。
彼はこれが研究ではなく逸話であると明言する一方で、見たことの多くは、少なくとも彼の経験上、一般化できるパターンに当てはまると考えている。
要点
- 既存の GitHub API ラッパー、フィードリーダー、レスポンスパーサーに相当する GitLab 版を実装するよう求められたエージェントは、2 つの API の主要な違い、すなわち GitHub のリポジトリが GitLab ではプロジェクトにあたることや、両者が実行の配列を異なる形の JSON で返すことに対処し、コードはコンパイルできた。
- それでも、生成されたラッパー関数はすべての関数で認証トークンを非オプショナルとして宣言していた。トークンはオプショナルであり、その下にある共通のリクエスト関数はオプショナルなトークンを受け取るよう正しく生成されていたにもかかわらずである。この欠陥は、呼び出し側のコードがオプショナルなトークンを渡したときに、初めてコンパイラエラーとして表面化した。
- そのエラーを与えられたエージェントの修正は、トークンがない場合に呼び出し箇所で空文字列を代入するというものだった。著者はこれを「vibe fix」と呼ぶ。コンパイルでき動作もするが、空文字列が「トークンなし」を意味するという新しいセマンティクスを持ち込むものであり、彼はそれを慣用的でなく、自己文書化的でもなく、Swift の型システムにも支えられていないと評している。しかも、すべての呼び出し箇所に変更が必要だった。正しい修正は、ラッパーの宣言でトークンをオプショナルにすることであり、1 文字の変更で済むものだった。
- 彼はこれを、同様の多くの事例の 1 つとして報告している。エージェントは、自ら正当化できない不要なキャッシュを提案し、GitLab には存在しない GitHub のユーザー／組織の重なりのために複雑なロジックを組み、それをやめるよう説得されても抵抗し、既存の関数を再利用せずに URL 構築のロジックを複数箇所に複製した。その際、テスト用にベース URL を上書きするといった自明でない機能を見落とすことも多かった。
- いずれの事例でも、生成されたコードは動作し、求められた機能を実装していたが、不要な複雑さを加え、自明でない機能を見落とし、コードベースの品質を下げるものだった。彼の結論は、エージェントに任せきりにしていたらコードベースは悪い方向に変わっていただろうということ、それに気づいて方向を正すには経験豊富な開発者が必要だったということ、そして注意深い監督がなければ、AI エージェントには、人間にとってもエージェントにとっても将来の開発を難しくする技術的負債を持ち込む強い傾向があるように見えるということである。
- 両方のエージェントとも、API 設計の違いで大きくつまずいた。GitLab はビルドのレスポンスに、トリガーしたユーザーのアバター URL を含めず、別の呼び出しを必要とする。Claude Code は、URL がレスポンスに含まれていると長々と彼を説得しようとし、結局彼はその部分をエージェントなしで実装することになった。
- 2 つの構成についての彼の比較は次のとおりである。Windsurf と Sonnet 3.5 はコードを書く速度を上げたが、プロンプトの入念な計画と、Xcode との間の絶え間ない切り替えを必要とし、生成されたコードには品質上の重大な問題があったため、全体として彼はそこから多くを得ているとは感じなかった。Claude Code と Sonnet 4.5 は必要なプロンプトが少なく、生成されたコードもより良かった（決して高品質とは言えないが）。また Xcode と並べてターミナルで実行するのがより自然に感じられ、彼にとっては日常的に使うのに十分なものだった。
背景
著者はこの記事を、エージェントが大量のコードを素早く書いたという報告に対置させている。彼によれば、そうした報告が非機能要件に触れることはめったになく、生成されたコードの品質を評価することはさらにまれである。彼の主張は、コードベースの内部品質に投資することには価値があるという彼自身の長年の経験に基づいている。複雑なコードベースは、人間にとってもエージェントにとっても扱いにくいからである。