AIエージェントがコードレビューを殺している—プリンシパル＝エージェント問題の解説

業界標準のコードレビュープロセス（GitHub PRで普及したレビュー後のコミット）は、低信頼コラボレーションのために設計されました。人間が変更を加え、別の人間がレビューし、反復を経て変更が取り込まれます。これは、レビュアーがコードを読むことで労力や理解を安価に推測できたから成り立っていました。AIエージェントはその前提を完全に壊します。

エージェントが介在する災害

AIエージェントの最良のケース：人間が機械にコードを書かせ、人間がレビューし、その後従来のレビューのために別の人間に送る。これではレビューの負担が倍増します。さらに悪いことに、エージェントは変更の総量を増やします。結果、エージェントによる生産性向上のごく一部が実現する前に、レビューの帯域が枯渇します。

しかし現実はさらに悪化しています。実際のパターンはこうです。人間が短いプロンプトを入力し、出力を軽く検証し、PRとしてまとめ、レビュアーのコメントをエージェントに戻して修正させる。これはまさに典型的なプリンシパル＝エージェント問題です。レビュアー（プリンシパル）はコードから労力や理解を推測できなくなります。なぜならコードは機械が生成したからです。エージェントを操る人間は、実際にコードを読んだり、レビュアーのフィードバックを批判的に検討したりするインセンティブを持ちません。5分ほど費やして、別のエンジニアに大きなレビュー負荷を生み出します。

これがオープンソースを蝕んでいるもの——プロジェクトやその制約、ツールを理解していない人々による「スロップPR」です。

小規模チームのための前進策

高信頼の小規模チームには、よりシンプルなプロセスがあります。人間がエージェントにプロンプト→人間がコードをレビュー→人間が直接デプロイ（2人目のレビュアーなし）。機械を操る人間がデプロイを所有することで全責任を負います。プリンシパル＝エージェント問題は、人間がドライバーでありデプロイヤーでもあることで解消されます。

exe.devでは9人のチームがこのアプローチを成功させています。重要なプラクティス：統合テストとE2Eテストを大幅に増やし、エージェントベースのワークフローでコミットの安全性/パフォーマンス/ユーザビリティバグを分析し、最終デプロイには常に人間が責任を持つこと。

従来のコードレビューモデルはエージェントでは救えません。小規模チームは適応可能ですが、大規模組織やオープンソースプロジェクトはより深刻な構造的問題に直面しています。