コードレビューは（自動化可能な）検出以上のものがある

「コーディングエージェントが人間の検査に取って代わる、コードレビューの終焉」という論文の要旨は、読者にこの絵を描いています…要旨 – コードレビューは、1976年にFaganがコード検査を形式化して以来、ソフトウェア開発における主要な品質ゲートとなっています。50年間、マージ前に同僚の変更を人間が検査しコメントすることは、あらゆる規模の組織で中心的な実践となってきました。コーディングエージェントは、ソフトウェアを読み書き、テスト、修復できる、大規模言語モデル（LLM）ベースの自律システムです。私たちは、コーディングエージェントが能力の閾値を超え、従来の人間によるコードレビューがソフトウェア品質パイプラインの必須コンポーネントではなくなったと主張します。私たちの議論は、2つの主張に基づいています。コードレビューのすべての目標は、エージェントによってより低コストでより高いスループットで達成できること。エージェントがコードを書き、人間が必須のレビューアであり続けるというナイーブな統合は、意味のある保証を提供せず、AI支援のスループットでスケールしないため、行き止まりです。この記事は、研究論文をあまり読んだことのないエンジニアにとって、よく構成されており、非常にわかりやすいです。しかし、この議論は問題のあるフレーミング、つまり代替神話に決定的に依存していると思います。著者は、ピアコードレビューを4つの目標とされる機能に分解します。欠陥検出、スタイル適用、知識移転、認識。そして、エージェントがそれぞれを実行できると主張します。結論はもちろん、エージェントがこれらの各機能を実行できるなら、エージェントは人間のレビューアを置き換える能力があるということです。私はこれが、機能に還元できないピアコードレビューの重要な側面を見落としていると思います。 経験豊富なエンジニアが差分を読んで「これは理解できない」と言うとき、その混乱こそが発見です。それは、コードが複雑すぎる、抽象化が間違っている、または意図が不明確であることを意味します。LLMは、それを処理できるという意味で、常にコードを「理解」します。それは、正当な人間の理解不能のシグナルを与えることはできません。この記事は、理解可能性をスタイル以上のものとして扱っています。それは違います。それは創発的な特性であり、アーティファクトを理解しようとする人とアーティファクト自体の間の相互作用で現れます。 「この変更は本当に2つのPRであるべきか？」や「これは症状を解決しているが、問題ではない」のような、変更の存在に疑問を呈すること。これらは、意図、範囲、および変更の適切さに関する質問です。すべては、コードが「正しい」かどうかよりも前に来ます。この記事のフレーミングは、a) レビューされているコード変更は必要であり、b) レビューの主な目的は検証であると仮定しています。しかし、本番環境に触れたことがある人なら誰でも、コードレビューはしばしば、変更が必要かどうかを異議を唱えることができる最後の（または唯一の）瞬間であることを理解しています。 人間がレビューできるのは、API契約が変更されたがエラー処理は変更されていないことに気づくことです。彼らは何が欠けているかに気づくことができます。言い換えれば、存在することが期待されているが、存在しないものを認識できるということです。この記事はこれを全く認識していませんが、欠如の盲点はLLMが非常に苦手とする失敗のクラスであるため、特に興味深いです。エージェントは存在するものをレビューしますが、専門知識を持つエンジニアは欠けているものを容易に認識できます。 ピアコードレビューアは、コードの作者、しばしば同僚との過去の経験から来る、一種の調整された注意を持っています。例えば、支払いモジュールへの経験の浅いエンジニアの最初のコミットは、ベテランの「グレービアード」エンジニアのルーチンリファクタリングよりも異なる注意を受ける可能性が高いです。レビューアは通常、リスクがどこにあるかについての自身の経験と、状況の誰が、何を、いつ、どこに一致させます。この記事は、すべての差分を同等の入力として扱っているようです。 それは私には、論文が知識移転を単なる情報伝達に還元しているように思えます。エージェントは単に「説明を生成」します。しかし、コードレビューでの議論は共同の認知活動です。ピアレビューアは作者のアプローチについて学び、作者はレビューアの質問を通じて学び、その結果は、議論の前にどちらの当事者も持っていなかった共有された理解になります。これは単なる伝達ではなく、共同作業です。エージェントの要約は、両方の参加者のメンタルモデルを変更する会話の代わりにはなりません。 「先週の火曜日にこのサービスでインシデントが発生しました。」「この下流のコンシューマーを所有するチームがそのインターフェースを廃止しようとしています。」「法務部からこのフィールドをログに記録しないように言われました。」人間がレビューできる人は、自分たちが思っているよりもはるかに多くの文脈知識を持っていますが、それらが実際の状況でつながりを認識できることは言うまでもありません。人々は、組織の現在の状態、最近の出来事、およびテスト、ドキュメント、またはバージョン管理にキャプチャされていない非公式な合意を理解しており、これらがレビュー中のコードにどのように影響するかを認識できます。これは非常に頻繁に起こるため、ほとんど見えなくなっています。記事はコードベースが完全なコンテキストであると仮定しています。それは決してそうではありません。 この記事は、人間の責任をコンプライアンスの成果物、つまり法的またはその他のルール関連の目的のための「名前付き人間」として扱っています。しかし、変更を承認することに個人的に責任があることを認識していることは、レビューの方法を形作ります。それは「スキン・イン・ザ・ゲーム」です。プルリクエストに「署名」するエージェントは、結果を負わず、確かに真剣な評価を促進するインセンティブ構造を持っていません。論文は議論セクションで倫理的な懸念を含んでいますが、それは「要件エンジニアリングと展開後の監視」にリダイレクトされており、これは問題を先送りにするごまかしの方法のように思えます。 私がこの記事で最も根本的な問題としているのは、コードレビューを第一に検出プロセスであると仮定していることです。つまり、欠陥、スタイル違反、セキュリティの問題などを見つけ、検出がより速く安価であることが普遍的に良いという仮定です。しかし、コードレビューは調整プロセス、意味把握プロセス、ガバナンスプロセスでもあります。代替神話はしばしば同じように展開します。まず、仕事における人間の貢献を測定可能な機能に分解します。次に、機械が独自の測定可能な機能にこの人間の貢献を複製できることを示します。そして、人間は不要であると宣言します。このアプローチはしばしば同じ点で崩壊します。最も重要だった人間の貢献は、機能間の統合でした。人々が計画外の状況や文脈に適応し、期待される社会的説明責任を果たす能力。これらの状況での適応能力は、上記の元の分解ステップ1では考慮されていません。元の記事でも考慮されていなかったと思います。