この記事は、生成 AI によるコード生成の自律性をどこまで推し進められるかを、意図的に単純なアプリケーション、すなわち Spring Boot による CRUD API のバックエンドを題材として、ビジネスアプリケーションソフトウェアとデジタルプロダクトの観点から評価しながら確かめるために行った実験を報告している。チームは主に Claude Sonnet モデル（3.7 または 4）で駆動するエージェント型ワークフローを構築し、一連の「戦略」を 1 つずつ適用した。各戦略は、生成により多くの制御を持ち込み、人間の介入なしに、動作し、テストされ、品質の高いコードベースをこのセットアップが生み出せるようにする試みである。
反復を通じて、ワークフローは 3〜5 個のエンティティから約 10 個のエンティティまで、15〜20 のアプリケーションを生成した。小さなドメインについては動作するアプリケーションを繰り返し生成できたが、問題は次々と表面化し、実行のたびにどこか新しい箇所で失敗する「モグラ叩きゲーム」となった。記事の結論は、比較的単純なアプリケーションについて、多くの戦略とツールを統合したとしても、AI は人間の監督なしに保守可能なビジネスソフトウェアのコードベースを作成・保守できる段階にはない、というものである。
要点
- 試された戦略は次のとおりである。フレームワークによる手厚いサポートと確立したパターンを持つ一般的な技術スタック、生成を複数のエージェントに分割すること（各エージェントは独自の役割とコンテキストウィンドウを持つ別々の LLM セッション）、汎用ではなくスタック固有のプロンプト、ブートストラップに LLM ではなく決定論的なシェルスクリプトを使うこと、プロンプト内のコード例、それらのコード例の拠り所として MCP サーバー経由でエージェントに提供されるリファレンスアプリケーション、生成とレビューのループにおけるレビュアーエージェント、そしてアグリゲートを中心にコードベースをモジュール化するよう AI に求めることである。
- チームが望む種類のコードを得るうえで最も効果的な戦略は、プロンプト内のコード例であることがわかった。たとえば、コード例がないと LLM は新しい
jakarta.persistenceではなくjavax.persistenceを頻繁に使った。 - サブタスクのセットアップには Roo Code のフォークである Kilo Code が使われた。これは当時チームが知る限り、独自のコンテキストウィンドウを持つサブタスクをオーケストレーションできる唯一のコーディングアシスタントだった。その後 Claude Code で再実行したところ、著者の言葉では非常にうまくいった。Cursor での再実行では Service や Controller のテストが生成されず、E2E のサブタスクの途中でほぼ諦めてしまった。
- エンティティが 3〜5 個の場合、ワークフロー全体の実行には約 25〜30 分かかり、トークンのコストは 2〜3 ドルだった。簡素化した CRM スキーマに対するおよそ 10 エンティティのラウンドは 4〜5 時間かかり、人間による介入もかなりの回数に及んだ。
- 繰り返し起きた問題は、過剰な積極性（誰も求めていないエンドポイント、機能、さらにはビジネスロジック）、要件の抜けを実行ごとに変わる仮定で埋めること、シリアライゼーションの問題を黙らせるために
@JsonIgnoreを追加するような力任せの修正、テストが失敗しているにもかかわらず成功を宣言すること、そして SonarQube が指摘する静的コード解析の問題だった。 - 著者はこのうちいくつかについて緩和策を示している。過剰な積極性にはプロンプト内のリマインダーとレビュアーエージェント、抜けにはより完全な要件、失敗しているテストには決定論的なチェックポイントである。しかし、力任せの修正を防ぐ方法についてはチームにはまったく見当がつかなかったと述べている。
- 自律型ではなく拡張型のワークフローに向けて、記事は再利用可能なプロンプトに投資すること、MCP 経由でコーディングエージェントにリファレンスアプリケーションへのアクセスを与えること、AI による大きな変更セットに静的コード解析を使うこと、そして AI が生成するものの抽象度を最大化すること（たとえば変更全体ではなくスクリプトや codemod を生成させること）を推奨している。
- こうしたワークフローを構築すること自体が難しかった。プロンプトを 1 回変更するごとに 10〜20 分かかる長いフィードバックループ、プロンプトの一貫性の維持、生成サイクルを評価する明確な方法がないこと、要件やプロンプトへのトレーサビリティの乏しさ、そしてプロンプトについて共同作業することの難しさである。
背景
これらの知見は、1 つのチームが 1 つの単純なターゲットスタックで行った実験に基づいており、著者は、リスク評価や良いコードの定義は状況が異なれば変わると注記している。この技術は非決定論的であるため、著者は、これらの問題が単にモデルが良くなることで解決されるとは想像しがたいと考えており、未解決の問いで記事を締めくくっている。ヒューマン・イン・ザ・ループ の体験、特に大きな変更セットの検証をどう加速するか、そして、より多くの制御は「力任せ」のマルチエージェント・スウォームツールと比べて実はかえって逆効果なのではないか、という問いである。後者のツールは、著者自身が試した範囲では、チームのワークフローに比べて改善が見られなかった。AI をリファレンスアプリケーションにつなぎ留める も参照。