コードレビューの本質は自動検出だけではない
There is more to code review than (automatable) detection
LLMベースのコーディングエージェントが人間のコードレビューを不要にするという論文に対し、筆者は「代替神話」という問題を指摘する。レビューの機能を分解して機械が再現できると主張しても、人間の混乱や変更の必要性への懐疑、欠落の検知、書き手による注意の調整、双方向の共同認知、リポジトリ外の運用文脈、説明責任といった統合的な役割は捉えられない。レビューは検出だけでなく調整・意味形成・ガバナンスのプロセスでもある。
人間の貢献で最も重要だったのは、機能を横断する統合だった。
HNでの議論
110- dimbletimbers
人的コードレビューを擁護する論として、もっと頻繁に目にしたいと思うのは、特に人々が認知負債や理解負債を懸念していることを踏まえると、理解の冗長性だ。最終的に、真剣に受け止められれば、少なくとも2人がその機能の仕組みを理解している（たとえその数が平均的には1と0の間に近づいていく傾向にあっても）。理想的には、その2人のうち少なくとも1人は、より広いシステムと、その機能がその風景にどう適合するか、あるいはそこから際立つかについて、より良い理解を得て終わる。
- n4r9
最近、コードレビューの目的について多くの議論がある。AIを前にしてそれは当然だ。少し前に投稿されたリンクがこちら：https://mathstodon.xyz/@mjd/115096720350507897
そしてそれに応えて、コードレビューが確認できる事柄の非網羅的なチェックリストを書いた：
- 機能的に意図したことを達成しているか（チケットやPRの説明に従って）？
- 余計なコードはないか？残ったデバッグ出力、プライベートAPIキーなど…
- 明らかな欠陥はないか？メモリリーク、未処理のエッジケース、セキュリティ上の欠陥、廃止されたAPI呼び出しなど…
- もっと理解しやすくできるか？抽象化の追加/削除、より良い変数名/メソッド名、より関数型/より少なくなど…
- スタイルはコードベースやスタイルガイドラインと一致しているか？
- 明らかなパフォーマンス改善はあるか？リストの代わりにハッシュセット、遅延評価など…
- 十分にテストされているか？
LLMはこれらのほとんどはまあまあだが、最初の項目が最も苦手だと思う。
- clintonb
自分の組織内でのコードレビューについて考えているが、いつも戻ってくる問いはこれだ：
> この組織は人間の学習を優先しているか？
これがコードレビューの主な動機づけだった。AI利用の増加によりコラボレーションが減っていることを考えると、特に他者から教えたり学んだりしたい。
悲しい真実は、私のフィードバックはすべてエージェントに直接届くということだ。おそらく10%だけが人間に反応されるので、本当のレビューに価値があるのか疑問に思う。ロボットを下手に訓練して自分の仕事をさせ、チームメンバーの能力をさらに萎縮させるだけではないか。
- metalspot
コードレビューが普遍的なのは、過失に対する責任の盾を提供するからだ。過失は興味深い。壊れたものを出荷するかどうかとは何の関係もない。壊れたものを出荷しないように試みるプロセスに従っていれば、過失にはならない。
エンジニアはこの茶番に付き合ってきた。コードレビューが価値あるチームのコラボレーション、調整、管理機能を果たしていたからであり、記事の著者はその点で正しい。
コードを読んでシステムを理解するのは、コードを書いてシステムを理解するより難しい。
AIが人間の能力の100倍、1000倍、10000倍のコードを生成でき（上限なし）、システム理解のメカニズムとしてコードレビューがボトルネックなら、チームの生産的な成果はほとんど増えない。
企業がAI生成コードの世界で競争したいなら、人的コードレビューはなくならなければならない。唯一の問いは、何がそれを置き換えるかだ。
AI生成速度で出荷し、それが唯一のゲートで、正確性を検証しリスクを制限する他のシステムやプロセスがなければ、AI生成コードに人的コードレビューを適用し続けるのは過失だ。
エンジニアリング側では簡単に適応できる。
コードレビューは決してバグを見つけることではなかった。コードレビューをするとき、最初に確認するのは「テストは通っているか？」だ。次に変更とそれに対して追加されたテストカバレッジを見て、「テストカバレッジはコードの機能を適切に示しているか？」と問う。そして「範囲と潜在的な…」と問う。
- ChicagoDave
私はちょうどデンバーで開催されたExplore DDDカンファレンスにいて、金曜日の一部はカフェのテーブルで著名な人々とGenAIがソフトウェアエンジニアリングに与える影響について非公式に議論していた。
これらの人々のほとんどは、「すべて」にGenAIを使うことに傾倒すると、集合的知識が消散することを深く懸念していた。
私は声高な反対者だった。人間が進歩を単純化するために知識を曖昧にした歴史的な例はたくさんある。
今、誰が大規模に自分のマイクロチップをはんだ付けするだろうか？誰もしない。驚くべき成果を上げる高度に洗練されたロボットや機械がある。
ソフトウェアエンジニアリングでは、「コーディング」を専門分野から取り除けば、ソフトウェア設計の他のすべての側面が残り、それは大学のCSカリキュラムで再ターゲットできると私は主張する。
飛躍はコードレビューについてではない。設計レビューについてであり、そこではGenAIが関与するかどうかに関わらず、より良い成果がもたらされる。
私は約1年前のコードベースを https://github.com/ChicagoDave/sharpee/ に持っている。これは私が設計したが、Claude Codeによって私自身のスキルとエージェントをガードレールとして生成された。Claudeから抽出したコードは人間のレビューを必要としないとかなり確信しているが、システムの設計とその変更は私が継続的にレビューしている。
私の主張は、私たちは「集合的に」AIと人間の境界線がどこにあるかを見極めようとしており、ほとんどがその線を人間の相互作用に「保持」しているということだ。
手放そう。どの部分に人間の決定が必要かを定義し、焦点を…
- bob1029
私のクライアントの1つに、PRを作成するたびに実行される自動「ベストプラクティス」AIロボットがある。純粋にデメリットしかない。それを作成した責任者でさえそう認めている。
しかし、奇妙な理由でそれはまだ存在している。これが実際に私を心配させる部分だ。くだらないコメントを無視するのは簡単だ。静かで容赦ないエントロピーの蓄積があらゆる場所で起きている。これがGitHubが毎営業日の正午にクラッシュする理由だ。
- grumpy_coder
コードレビューは、GitHubが2008年に登場してプロセスに簡単に追加できるようになるまで、かなり稀だった。
正直なところ、人々が思うほどコード品質の改善は見られなかった。友人が友人のPRを承認する。ほとんどのコーディング文化はPRを拒否することに本当に抵抗がある。
CIでの自動テストの方がはるかに大きな改善だった。少なくともコードは今コンパイルされる。
- fwlr
私のマシンができないことを正確に教えてくれるなら、私はいつでもマシンにまさにそれをやるようにプロンプトできる。
- ジョン・フォン・アルトマン
「人間ができることでAIができないこと」を明確に表現するのは愚かなゲームだ。十分に指定すれば、彼らはあなたのテキストを/goalプロンプトボックスに貼り付け、エージェントの群れをラルフループさせ、その行為と区別がつかないほど疲れるものを生成するまで続ける。十分に指定しなければ、人間中心の魔法の思考でゴールポストを動かしているだけだ、などなど。