9月3日、Ben Lindersが「Rigorous Yet Sustainable Human Reviews in the AI Era」と題した記事を公開した。この記事では、AI時代においてコードレビューの質を維持しながら開発速度を持続可能な形で確保するための実践的フレームワークについて詳しく紹介されている。
AIがコードレビューを壊す前に
AIによるコード生成が普及するにつれ、開発チームが直面する問題がある。レビュー対象のコード量が増え続ける一方、レビューの質を維持するための人間の認知リソースは有限だ。
Craft Conferenceでの講演「Code Health Guardian」で、エンジニアのArtie Shevchenko氏はこの問題を「コグニティブデット（認知的負債）」と呼んだ。コグニティブデットとは、チーム内でシステムへの共通理解が失われていく現象を指す概念だ。ソフトウェア開発で広く知られる「テクニカルデット（技術的負債）」が設計・実装上の問題の蓄積を指すのに対し、コグニティブデットはチームの「理解の劣化」に着目した派生的な概念として用いられている。AIはコードの生成量を増やすことで、このコグニティブデットをさらに加速させる。
Shevchenko氏は経済史家Joel Mokyr氏の知見を引用し、技術的進歩が定着するには「実践と理論の深い理解が互いにフィードバックし合う知識ループ」が不可欠だと指摘する。AIはこのループを強化する可能性も、断ち切る可能性もある。
AIは理論をわかりやすく説明することで知識へのアクセスを改善する。しかし、人間がループの外に置かれると話は変わる。理解を伴わない知識、AIが生成するものをそのまま受け入れる姿勢は、知識フィードバックループの崩壊を招く。
大きな変更をどうレビューするか
コードレビューは「スキルや習慣」であると同時に「筋肉」でもある、とShevchenko氏は言う。鍛えることはできるが、処理できる量には限界がある。
非自明な大規模変更への対処として、氏は3つの選択肢を整理した。
- 厳密なレビュー — 以前から難しく、AIの登場でさらに困難になっている
- ざっと眺める — コグニティブデットが急速に蓄積する
- コーディング先行、AI二番手アプローチ
氏が推奨するのは3番目だ。レビュアーがまず自分でコードのスパイク（試作実装）を行い、そのスパイクと仕様をAIに渡して改善案を提示させる。提示された変更を一つひとつ個別に確認してから取り込む流れだ。
このアプローチのポイントは、レビュアーがすでにソリューションを深く理解した状態でレビューに臨める点にある。ゼロからAIの生成物を読み解くより、判断が格段に速く正確になる。
AIによるレビューの落とし穴についてShevchenko氏はインタビューでこう述べている。
AI生成コードの最大の課題はその量だ。高品質なレビューはもともと簡単ではなかったが、止まらないレビューのストリームは本当に消耗する。誰にでも個人的な閾値があって、それを超えると追加レビューから来る疲労は指数関数的に増える。
次に厄介なのが「もっともらしさ」だ。AI生成コードは一見正しく見える。その磨かれた表面の下に潜む微妙な欠陥を見つけるには、人間が書いたコードより多くの精神的努力が必要になる。
さらに、AIはリファクタリングより新規コードの追加を好む傾向がある。既存コードを整理する機会を見つけるには、コードベース全体への深い理解がまだ必要だ。
「AIがスタンプを押す」運用で速度を上げる
低リスクの変更に対してピアレビューをスキップすること自体は有効な最適化だが、Shevchenko氏が最も効果的と位置づけるのは「コードオーナーが自分のPRをAIレビューだけで承認・マージできるポリシー」だ。
ピアレビューの代わりに他のオーナーへ通知するだけでよく、AIがスタンプを押してマージできる。
このポリシーはコードオーナーシップへの強いインセンティブを生む。オーナーになれば、自分のPRを他者の承認待ちなしに進められるからだ。
ただし、前提条件がある。チームメンバーの大半がコードオーナーでなければ、オーナーである少数のメンバーがノンオーナーからのAI生成PRのレビューに時間を奪われ続ける。結果として、オーナーが自分のPRを速く進められても全体の速度は変わらない。
本当に解決するには、チームメンバーの大半がコードオーナーである必要がある。しかし、所有権を簡単に配れば、アーキテクチャの整合性が損なわれる。結論は明確だ。このポリシーを機能させるには、チームは小規模でなければならない。
「小規模チーム」がこのフレームワーク全体の前提条件だ、とShevchenko氏は結論づけている。
まとめ
Shevchenko氏のフレームワークを整理すると以下になる。
- 複雑な変更：自分でスパイクを打ってからAIに改善を提示させ、個別に確認する
- 低リスクな変更：ピアレビューをスキップ
- コードオーナーの自分のPR：AIレビューのみでマージ可能にする
- 前提：チームを小規模に保ち、大半のメンバーがコードオーナーである状態を維持する
AIによるコード生成が当たり前になるほど、「理解を伴わないままコードが積み上がるリスク」は静かに高まる。Shevchenko氏のアプローチは、その流れに対してチーム構造とレビュープロセスの両面から手を打つものだ。AI活用の恩恵を享受しながらコードベースへの知的制御を手放さないために、開発チームが今から設計しておくべき問いを明確に示している。
詳細はRigorous Yet Sustainable Human Reviews in the AI Eraを参照していただきたい。
