コードレビューの本質は自動検出だけではない
There is more to code review than (automatable) detection
LLMベースのコーディングエージェントが人間のコードレビューを不要にするという論文に対し、筆者は「代替神話」という問題を指摘する。レビューの機能を分解して機械が再現できると主張しても、人間の混乱や変更の必要性への懐疑、欠落の検知、書き手による注意の調整、双方向の共同認知、リポジトリ外の運用文脈、説明責任といった統合的な役割は捉えられない。レビューは検出だけでなく調整・意味形成・ガバナンスのプロセスでもある。
人間の貢献で最も重要だったのは、機能を横断する統合だった。
HNでの議論
30- dimbletimbers
人的コードレビューの擁護として、もっとよく見かけたいと思うのは、特に人々が認知負債や理解負債を懸念していることを踏まえると、理解の冗長性です。最終的に、真剣に受け止められれば、少なくとも2人がその機能の仕組みを理解します（たとえその数が平均して1から0の間に近づいていく傾向にあっても）。理想的には、その2人のうち少なくとも1人は、より広いシステムとその機能がその風景にどう適合するか、あるいはそこから際立つかについて、より良い理解を得て終わることです。
- n4r9
最近、コードレビューの目的について多くの議論があります。AIを前にすると理にかなっています。少し前に投稿されたリンクがこちらです：https://mathstodon.xyz/@mjd/115096720350507897
そしてそれに応えて、コードレビューが確認できる項目の非網羅的なチェックリストを書きました：
- 機能は（トラッカー課題やPRの説明に従って）意図したことを機能的に達成しているか？
- 余分なコードはないか？残ったデバッグプリント、プライベートAPIキーなど...
- 明らかな欠陥はないか？メモリリーク、未処理のエッジケース、セキュリティ上の欠陥、廃止されたAPI呼び出しなど...
- もっと理解しやすくできるか？抽象化の追加/削除、より良い変数名/メソッド名、より関数型/より少なくなど...
- スタイルはコードベースやスタイルガイドラインと一致しているか？
- 明らかなパフォーマンス改善はあるか？リストの代わりにハッシュセット、遅延評価など...
- 十分にテストされているか？
LLMはこれらのほとんどはまあまあですが、最初の項目が最も苦手だと思います。
- clintonb
自分の組織内でのコードレビューについて考えていて、何度も戻ってくる問いはこれです：
> この組織は人の学習を優先しているか？
これがコードレビューの主な動機でした。AIの利用増加によりコラボレーションが減少している中で、特に他者から教えたり学んだりしたいのです。
悲しい真実は、私のフィードバックはすべてエージェントに直接届くということです。おそらく10%だけが人間によって反応され、本当のレビューに価値があるのか疑問に思います。ロボットを下手に訓練して自分の仕事をさせ、チームメンバーの能力をさらに萎縮させるだけではないかと。
- bhouston
重要なシステム以外で生成されるコードの90%以上では、人的コードレビューはすでに廃れつつあると確信しています。
- refactor_master
私の経験では、自動コードレビューはかつてないほど無意味です。
リンター、テスト、そしてAIがコードを書いてくれるものがすべて揃っています。右手がよくやったと左手に言う必要はありません。PRをプッシュすればコードが動くことは確信しています。
今必要なのは、アーキテクチャ、長期的な視点、そしてビジネスの観点です。