Robert Martinが語るAI生成コード：コードレビューから制約エンジニアリングへの焦点の移行

Clean Codeの著者であるRobert Martinは、自身のAIエージェントが生成したコードをもう読んだりレビューしたりしていないと述べています。その代わりに、彼は出力を検証するために厳格な自動制約システムに依存しており、これこそがAIエージェントが提供する生産性の向上を最大限に活用する唯一の方法であると主張しています。

極端な制約によるAI出力の検証

Robert MartinのAI生成コードへのアプローチは、手動のコードレビューを自動検証の「試練（gauntlet）」に置き換えることです。彼は、AIが生成したコードに対する高い信頼性は、コードの行を読むことによってではなく、エージェントを極端な制約で囲むことによって達成されると断言しています。

Martinによれば、これらの制約には以下が含まれます：

• Unit tests
• Gherkin tests (Behavior-Driven Development)
• QA procedures
• Quality metrics
• Mutation testing
• Test coverage

コードがこれらすべての厳格なチェックに合格することを保証することで、人間の開発者がレビュープロセスにおけるボトルネックではなくなるため、AIエージェントの生産性が最大化されるとMartinは主張しています。

コミュニティの批判：「正しい」が間違っている実装のリスク

Martinの戦略を巡る技術的な議論では、いくつかの重大なリスク、特にAIエージェントが、実装とテストの両方が間違っているという「誤りの閉ループ（closed loop）」を作り出してしまう可能性が指摘されています。

仕様のギャップと論理的エラー

主な懸念は、自動テストは「コードがテストの指示通りに動作すること」を証明するだけであり、「ビジネスが実際に必要としていること」を必ずしも証明するわけではないという点です。あるコメント投稿者は、「高価なバグは通常、仕様そのものの欠落である」と指摘しており、制約では欠陥のある要件を修正できないことを示唆しています。

さらに、AIエージェントが機能を完全に逆方向に実装したにもかかわらず、その欠陥のあるテストに従えば実装が「正しい」ことを証明する包括的なテストスイートを作成してしまったという経験を共有する開発者もいます。これは、機能の根本的なロジックがAIによって誤解されている場合、形式検証や自動テストは人間の監視の代わりにはなり得ないことを示しています。

コストのトレードオフ

批判者たちは、このアプローチの効率性についても疑問を呈しています。高い信頼性を得るために必要なテストの量（SQLiteの「コード1行に対して500行以上のテスト」という比率を例に挙げる）は、テストの作成とレビューに多大な人的労力を要するため、単にコード自体を読んだ方が効率的であると主張する者もいます。

エージェント時代における「Clean Code」の再定義

一部の実践者は、Martinのアプローチは「Clean Code」の定義の転換を示唆していると述べています。AIエージェントの時代において、「クリーン」とは、人間が書いたソースコードの可読性や優雅さを指すのではなく、網羅的な仕様、設計上の制約、およびシナリオテストスイートに準拠するコードの能力を指すようになるのかもしれません。

この転換により、人間の労力は、コードの記述とレビューから、要件の指定、アーキテクチャの設計、およびドメインに合わせたテストシナリオの調整といった、より高レベルなタスクへと移行します。ある観察者が指摘したように、これにより人間の開発者は、実装の詳細について議論することではなく、ドメインと標準に集中できるようになるのです。