この記事は、Code Remix のパネルで著者と意見が分かれた DX の Brian Houck への応答として書かれたもので、 AI が今や人間が現実的にレビューできる以上のコードを生み出しているという問題を取り上げている。Houck の懸念は、 著者も共有していると述べるもので、コードレビューを自動化して取り除いてしまうと、チームがコードレビューを 使って行っているそれ以外のすべてのこと、すなわち知識の共有、ジュニアエンジニアの育成、集団的オーナーシップの 構築、アーキテクチャの理解の浸透を失うおそれがある、というものである。これに対する著者の問い返しは、なぜ チームはそれらのことをコードレビューの段階まで待ってから行うのか、というものである。
記事は、AI がコードレビューを壊したのではなく、コードレビューにどれほど多くの責任が負わされていたかを AI が 露呈させたのだと論じる。品質ゲート、セキュリティチェック、アーキテクチャレビュー、メンタリングの仕組み、知識 共有のシステム、オーナーシップのモデルである。この体制は、人間がコードを生み出せる速さに限りがあるうちは 機能していたが、著者はその制約が今や消えつつあり、レビューが レビューのボトルネック に なっていると論じる。
要点
- フィードバックループを短くするという原則に従えば、価値のあるフィードバックは取り除くのではなく、それが 情報を与える意思決定により近い場所へ移すべきである。
- コードレビューに帰せられる利点には、それぞれもっと早い段階に置き場所がある。1 つの解決策を実装する前に 代替案を検討する。ペアリングによって知識を移転し、ジュニアエンジニアに学ばせる。ペアリング、モブ プログラミング、あるいはチームでの設計セッションを通じて集団的オーナーシップを築く。共に設計し、重要な制約を フィットネス関数として記述することで、アーキテクチャの整合を取る。
- フォーマット、リント、既知のセキュリティ問題、そして決定論的にテストできるものはすべて、レビューするのでは なく自動化すべきである。
- ペアプログラミング、トランクベース開発、自動テスト、静的解析、フィットネス関数、セキュリティスキャンは いずれもフィードバックを早い段階に移すものであり、エージェントもそうしたループにますます参加できるように なっている。ただし著者は、本当の思考は依然として経験豊富な人間から生まれるという立場をとる。
- 人間によるレビューは、あらゆる変更に適用される儀式としてではなく、例外として行うべきである。すなわち、 根本的なアーキテクチャの変更、機密性の高いセキュリティ境界をまたぐ変更、影響範囲がきわめて大きい変更、 重要なシステムのなじみのない部分への変更、あるいはチームが確信を持てないときである。
- エージェントが 10 倍のコードを生み出せても、そのすべての行がシニアエンジニアの順番待ちになるのであれば、 結果として生まれるのは 10 倍のエンジニアリング組織ではなく、バックログと新たなボトルネックである。
- AI エージェントに人間のレビュアーのふりをさせるのは、その儀式がなぜ存在するのかを問い直すのではなく、 儀式を自動化するだけである。
- 著者は、ソフトウェアが成長する一方で理解が縮小するにつれてチームが認知的負債と意図の負債を蓄積するという 点で Houck に同意するが、プルリクエストの義務化が強力な防御になるとは考えていない。著者は、協調的な設計、 ペアリング、適切な境界、実行可能なアーキテクチャ、運用責任の共有を通じて、意図的に理解を維持することを 主張する。「エンジニアが理解すべきは差分ではなくシステムである」。
文脈
この記事は martinfowler.com 上の著者の個人コラムに掲載された意見記事であり、ある論争の一方の側を論じるために 書かれている。著者は、プルリクエストを開発プロセスの中心に据えるやり方をもともと特に好んでいなかったと 自らを説明しており、両陣営は大部分において同じ結果を望んでいると提示している。記事が引用している差分や プルリクエストのサイズの増大に関する数値は Houck 側の主張に由来するもので、著者自身の測定によるものではない。