もしかしたら、すべてのコードレビューをやめるべきではないか

コードレビューはすべて行うべきではないのかもしれない

TL;DR
あるいは、問題はAIがコードレビューを破壊したことではなく、私たちがコードレビューを使って間違った問題に対処してきたことなのかもしれない

先日、Code RemixでModerneがホストしたパネルディスカッションに参加しました。DXのBrian Houck氏も一緒でした。これは私が参加した中でも特に興味深いパネルの一つでした。なぜなら、私たちは意見が異なっていたからです。私の同僚であるMartin Fowler氏が言うように、パネルは意見が異なり、両者が良い議論を展開しているときの方がはるかに面白いものです。Brianと私は間違いなくそうでした。

Brianはその後、What are code reviews even for? という思慮深い記事を書いています。彼は明らかに自分の立場に情熱を持っており、私も自分の立場に十分情熱があるので、この返信を書いています。はっきり言っておくと、私たちはほとんど同じことを望んでいると思います。ただ、それを実現する最善の方法がコードレビューだとは思っていません。ちなみにBrianは素晴らしい人物で、私にこの記事を書くよう勧めてくれました。しかし、最後まで私が正しいと思わせたいという気持ちがないと言ったら嘘になります:)

では、私たちは何について意見が異なっていたのでしょうか？

AIは、人間が現実的にレビューできる量を超えるコードを生成しています。Brianは非常に印象的な数字を引用しています。Metaでは、人間が着地させた差分あたりのコード行数が1年間で106%増加したと報告されており、DX自身のデータでは、プルリクエストの平均サイズが64%増加しています。

彼の懸念は、私も共有するものですが、コードレビューを単に自動化してしまうと、私たちがコードレビューで利用してきた他のすべてのものを失うリスクがあるということです。コードレビューは単にバグを見つけるだけではありません。それは、チームが知識を共有し、ジュニアエンジニアを教育し、集合的なオーナーシップを構築し、アーキテクチャの理解を広める方法でもあります。

私の疑問はこうです：なぜ私たちは、これらのすべてを行うためにコードレビューを待っているのでしょうか？

私は、ソフトウェア開発プロセスの中核としてプルリクエストを特に好んだことはありません。エンジニアがお互いのコードを見るべきではないからではなく、何かを構築し、それを完成させ、パッケージ化し、他の誰かに渡し、それから、正しいものを正しい方法で構築したかどうかについての重要な議論をするという考え方に、私は常に苦労してきました。

そして、マージコンフリクトについては触れないでください。私は人生の多くの時間を無駄にしてきました。

判断を左にシフトする

Thoughtworksで非常に早い段階で学んだ原則の一つは、フィードバックループを短縮することです。フィードバックが価値があるなら、それを取り除かないでください。それが情報を提供している決定に近づけてください。

コードレビューが私たちに与えてくれると言うものを見てみましょう。

もし私たちが代替ソリューションを探求したいなら、それを実装する前にそうしたいです。

もし知識移転を望むなら、ペアを組みましょう。物理的または仮想的に誰かの隣に座って、彼らが問題解決の思考プロセスをたどるのを見ることは、後で完成したソリューションを読むよりもはるかに多くのことを教えてくれます。

もしジュニアエンジニアが経験豊富なエンジニアの考え方を学びたいなら、彼らが考えている間に経験豊富なエンジニアと一緒に働かせましょう。ここでもペアプログラミングが思い浮かびますが、チームは何かを書く（またはエージェントに書くよう指示する）前に、ホワイトボードを使って共同で設計セッションを行うこともできます。

もし集合的なオーナーシップを望むなら、人々がプルリクエストに頼って誰かが既に構築したものを知るのではなく、実際にソフトウェアを共同で構築し運用できるようにチームを組織しましょう。このためにも、ペアプログラミング、モブプログラミング、またはホワイトボードを中心としたチーム設計セッションを使用します。

もしアーキテクチャの整合性を望むなら、一緒に設計し（ペアプログラミングとチーム設計セッションについては繰り返しません、おっと…）、その後、重要な制約をフィットネス関数としてエンコードします。

そして、フォーマット、リンティング、既知のセキュリティ問題、または決定論的にテストできるもののためにコードをレビューしているなら、それらを自動化してください。2026年になっても、まだ空白文字について議論しているべきではありません。

ペアプログラミング、トランクベース開発、自動テスト、静的解析、フィットネス関数、セキュリティスキャンはすべて、フィードバックを早期に移動させます。エージェントもこれらのループに参加し、設計に異議を唱え、仮説をテストし、構築されているものを継続的に検証できるようになりますが、真の思考は経験豊富な人間から来ており、その経験がチーム全体に利益をもたらすことを望むなら、コードレビューよりもはるかに早い段階でチームとして行動しなければなりません。

例外によるレビュー

これらすべてが、誰もコードレビューをしないという意味ではありません。経験豊富な人間がもう一人見てほしいと願う変更は絶対にあります。例えば、根本的なアーキテクチャの変更などがそうです。チーム全体で設計セッションを行ったと仮定すると、チームとしてコードをレビューするか、正しく実装されたことに同意するか、何か変更したいかどうかを議論したいかもしれません。その他の例としては、機密性の高いセキュリティ境界を越える変更、影響範囲の大きい変更、重要なシステムの馴染みのない部分、あるいは単にチームが「これには自信がない」と言うようなものがあります。

これらはまさに人間の判断が価値を発揮する場所ですが、それは信頼を醸成するために歴史的に使用してきた儀式だからといって、すべての変更を人間が検査することを義務付けることとは全く異なります。

そして、この道を歩み続けることは現実的ではないことを私たちは知っています。だからこそ、コードレビューは問題やブロッカーとして繰り返し浮上してくるのです。エージェントが人間の10倍のコードを生成できるとしても、そのすべての行がシニアエンジニアの検査を待つキューに並ぶのであれば、私たちは10倍のエンジニアリング組織を作り出したのではなく、大きなバックログと新しいボトルネックを作り出したことになります。

そして、答えは、同じプロセスをより高速で維持するために、人間のレビュー担当者を装ったAIエージェントだとは思いません。それは儀式を自動化しているのであって、なぜその儀式が存在するのかを問うことではありません。

しかし、Brianの議論で心配な点が一つあります。彼は、チームが認知的負債と意図的負債を蓄積することについて話しています。ソフトウェアは成長するにつれて、それに対して責任を持つ人間は、なぜそれがそのように機能するのかをますます理解しなくなっていきます。これは非常に現実的な問題だと思います。ただ、義務的なプルリクエストがそれに対する特に強力な防御策だとは思いません。

エージェントが実装の大部分を生成するようになるなら、共同設計、ペアプログラミング、適切な境界設定、実行可能なアーキテクチャ、共有された運用責任、そしておそらくまだ発明されていないいくつかのプラクティスを通じて、人間の理解を維持するために、より意図的に取り組む必要があります。

私たちは、エンジニアがシステムを理解する必要があり、差分を理解する必要があるのです。

おそらく、それがAIが露呈させていることです。私たちは長年、謙虚なコードレビューに信じられないほどの数の責任を負わせてきました。品質ゲート、セキュリティチェック、アーキテクチャレビュー、メンタリングメカニズム、知識共有システム、オーナーシップモデルなどです。

人間がコードを生成できる速度が遅かった頃は、それは（ある程度）機能していました。その制約は消えつつあります。ですから、おそらく問題は、コードレビューをより速く行う方法ではありません。おそらく問題は、そもそもなぜすべての重要な会話をコードレビューまで待っているのか、ということです。