コードレビューは著者を前提とする

コードレビューは、プルリクエストに責任を持つ人間がコードを理解し説明し操作できることを前提としている。その前提は完全に正しかったわけではない——人々は半分しか理解していないスニペットをコピーしたり、自分が書いていないコードを引き継いだりしてきた。しかし、プルリクエストは依然として、人間が作業に近く、質問に答えられるという基本的な仮定に基づいていた。

なぜそのように実装されたのかと尋ねれば、答えはどこかから来た。作者が回避していた制約かもしれないし、チームメイトとの非公式な議論かもしれない。レビューは作者が見逃したものを捉えたが、それは作者が頭の中に変更のモデルを持っていることから始まった。

その仮定は崩れ始めており、エージェント型開発は障害モードを変えている。モデルにコードを書かせることはもはや難しい部分ではない。変化は、システムが自身の出力を反復し、人間が何を変更したか、どのように壊れるかを理解する前に、プルリクエストのような成果物を生成できるようになったことにある。

今や多くのコードが、表面的には流暢で行ごとに妥当だが、その選択を説明できる人間が背後にいない状態で届けられている。著者は単なる代理人だ。差分は実在し、テストはパスし、プルリクエストには人間の名前があるが、その背後にある推論がその人間の頭の中にあることを意味しない。

なぜと尋ねると、答えは時々「それが私が受け入れた出力だ」だけだ。それは別の種類の著作者である。さらに悪いことに、質問を別のモデルにそのまま流し、プロセス中に思考が行われないようにしている。

ボトルネック

よくある不満は、コード生成が安価になるとレビューがボトルネックになることだ。それは真実だが、現在起こっていることの中で最も面白くない部分だ。より重要な問題は、ボトルネックが今や何をするよう求められているかである。

レビューは、誰かが（ある程度）理解している作業に挑戦するために設計された。今や私たちはそれを、理解が初めて現れるべき場所として使っており、それははるかに重い仕事である。

別のモデルをレビューに向けることはある程度役立つ。スタイルの問題、欠落したnullチェック、明らかなセキュリティ上の危険を捕捉する。それは有用であり、可能な限り自動化する価値がある。しかし大規模システムでは、レビュアーの真の価値は差分が語らないことを知っていることにある。

3つ離れたリポジトリのサービスがこのリトライ動作に依存している。誰も1年間開いていない夜間ジョブがそのフィールドを読み取る。この移行は新しい顧客には安全で、古い顧客には危険だ。コードが冗長に見えるのは、インシデント後に誰かが明白な抽象化を削除したためであり、そのテストがパスするのはフィクスチャが間違っているためだ。

そうしたコンテキストの一部は取得可能であり、時間とともにより多くが取得可能になるだろう。モデルはより多くのファイルを読み、リポジトリやログをさらに横断するようになる。それはレビューを改善するが、根本的な問題を取り除くわけではない。

最も難しいコンテキストは通常、コードベースにはまったく存在しない。それはインシデント履歴やチームの境界、そしてどこにも記録されていない記憶——明白な解決策が3年前に却下された理由——の中に存在する。モデルは成果物を取得できるが、それらを結びつける判断に対して責任を負うことはできない。

コードレビューは絶望的か？

最初の適応は恥ずかしいほど単純かもしれない。AI支援のプルリクエストは、それを提出する人間が意図、触れる不変条件、安全性の証拠を説明できるまで、レビューの準備ができていない。その説明を生成することがプロセスに所有権を取り戻させる。文書自体はほとんど重要ではない。

著者が変更を説明できないなら、プルリクエストは準備ができていない。それはまだ単なる生成された出力だ。

これで全ての問題が解決するわけではない。巨大なエージェント生成の変更をどのようにレビューするか、所有権をどのように割り当てるかは示されていない。この早い段階で完全な代替品を売り込む人には懐疑的だろう。

しかし、一つ確かなことがある。今日のプルリクエストはLLM以前の遺物だ。それは著作者、所有権、理解に関する仮定を符号化しており、人間がコードをタイプしたときにはほぼ成立していたが、モデルが生成したときにははるかに信頼性が低い。

私たちは儀式を維持し、それが依存するものを認めずに変えてきた。

誰もがAI生成コードをより速く、さらに多くのAIを使ってレビューすることに取り組んでいる。より難しい問題は、承認を求める人がその下にあるコードを理解していないかもしれないとき、レビューが何を意味するかということだ。