- AIが書いたコードをAIがレビューするのは妥当なのか、という興味深い問い
- Devin AIのようなボットが最も多くのPRを作成しており、レビューもAIが行う事例が増えている
- LLMはステートレスであり、レビュー時と作成時では内部構造が異なるため役割を分けられるという主張もある
- AIが生成したコードは人間とは異なる種類のバグを引き起こしやすく、AIはそのバグを見つけるのにより効果的
- 結果としてAIレビューは人間のレビューより実際のエラー検出に有利だが、人間のアーキテクチャ判断やスタイルガイドは依然として重要
AIは自分のコードをレビューしてもよいのか？
- ほとんどの企業は作者 ≠ レビュアーの原則を守っている
- しかしAIはLLMベースでステートレスであり、リクエストごとに新たに判断する
- つまり、同じエンジンを使っていても**作成とレビューは別の「車」**と見なせる
Scaffolding: AIレビューの構造
- レビュー用AIは次のような特定のワークフローを実行する:
- コードdiffの分析
- バグ検出
- コメント作成と重大度の判定
- コードベース文書と関連ファイルの参照
- 一方でコード生成AIはまったく異なる文脈で動作するため、レビューと生成は機能的に異なる
人間も実は「同じエンジン」
- PR作者とレビュアーが異なっていても、同じ人間の知能から生まれている
- 同じ会社、同じ訓練を受けた似た知識と経験を共有している
- 結局AIも人間も**「同一エンジン、別ケース」**という点で似ている
AIコードには、より精密なレビューが必要
-
AIコードの品質はやや低い
- AIは速度は速いが、プロンプトの限界により要件の伝達が不正確になる
- 優れた開発者でさえ、AIコードについて自分のコードほど細かくレビューしない
- 結果として全体の品質は下方に平準化され、中程度の水準に収束する
-
AIのバグは人間には見つけにくい
- AIが作るバグは人間が通常は作らないタイプ
- 例: 予期しない行の修正、微妙な条件分岐の誤りなど
- Greptileの社内テストによると:
- AI(Sonnet) は「Hard」バグ209件のうち32件を発見
- 人間の開発者は平均5〜7件しか見つけられない
結論
- AIが自分のコードをレビューすることは技術的に可能で意味がある
- AIはバグ検出で人間より優れており、レビューに実際に有用
- しかし人間の意図の解釈、設計判断、コードスタイルの判断は依然として重要
- 作者 ≠ レビュアーという従来の基準は、AIに対しては新たに解釈する必要がある
3件のコメント
LLMモデルを切り替えながらレビューするのはどうでしょう。Aモデルで作成したコードをB、C、Dモデルでレビューする、といった具合に
あっ、うちの会社ではこうしています。Cursor（Claude）で書いたコードをPRに出したら、ChatGPTでレビューしています。これからは互いに戦え、という感じで。o4-miniのあたりからは、みんな感嘆していました。Cursorでもモデルを切り替えて依頼する形で、その場ですぐ試せます。
Hacker Newsの意見
この点を強調したい。エンジニアは、AIが生成したコードを自分で書いたコードほど細かくレビューしない。その理由は、タイピング速度よりもLLMがコードを生成する速度のほうがはるかに速いからだ。自分でコードを書くときは自然にレビューもしているが、AIが生成するとその工程が省略される。興味深いことに、普通のエンジニアにとってはAIがむしろコード品質を高めることもある。AIを多く使うほど、良いエンジニアとそうでないエンジニアが作るコードの水準はだんだん近づいていくはずだ。コードレビュー、設計、実装の各段階で思考の仕方が違うのはいつも興味深い
人によって相性の良い関わり方は異なる。私はコードを書くよりレビューするほうが楽だ。自分で書くときはコードベース以外にも多くの文脈を考えなければならないが、レビューではその文脈をコードベースに集中できるので、より速くパターンマッチできる。残念ながらLLMの水準はジュニアエンジニア級なので、PRレビューにはもっと多くの努力とエネルギーが必要になる
良いエンジニアが必ずしも良いコーダーとは限らないことは多い
コードレビュー用のAIとコード作成用のAIで、使うボットやプロンプトを分けると、はるかに多くの誤りを見つけられる。同じツールで何度も繰り返しても新しい問題が見つかることがある。人間でもAIでも、一度で完璧なコードは作れない。AIツールはどんどん進化していて、自分のコードを自分でテストし事前レビューする段階にまで来ているが、人間とAIの両方がPRコードをレビューするのは決して無駄ではないと信じている。自作のKamaraというツールでも、自分で書いたコードの問題を見つけることがよくあった。greptileの例のように、コード位置がまったく間違った提案をする問題もあったが、徐々に制御できるようになっている。まだ100%完璧なツールはなく、AIがすべてをtakeoverするまでにはもう少し時間が必要だと感じる
OpenHands（以前の名前はOpenDevin）を始めたとき、AIが作ったPRはAIアカウント名で投稿されていた。これには2つの深刻な問題があった。1) AIを呼び出した人がコードレビューなしでそのままマージできてしまい、未検証のコードが配備されるおそれがあった。2) PRの明確な責任者がいないため、マージされなかったり問題が起きたりしたときに誰に責任を問うべきか不明確だった。そこで、すべてのPRに人間のオーナーを持たせる方針に変え、コミットだけAI名義で残すようにした。PRそのものは完全に人間の責任だ
LLMがバグをよく見つけるという点は興味深かった。高い実バグ検出率を得るために、どれだけ多くの誤検知が出たのか気になる。私の経験では、LLMはバグがないのに「ある」と答えることが多い
本当にその通りだ。私はChatGPTに何かを尋ねて、提案が気に入らないと「その部分、よく分かってないんじゃない？」と言うと、すぐに答えを変える。実際には最初の答えが正しいこともあり得るのに、ユーザーに確信がないと簡単に揺らぐ。だからツールをきちんと検証するのは簡単ではない
今回のケースでは、各ファイルにバグは1つだけあり、しかもボットには正確に1つだけ見つけるよう指示していた。結果はすべて誤検知で、何の問題もない場所にバグを作り出していた
市場に出ているさまざまなAIコードレビュー・ツールの違いは、まさに信号/雑音比のチューニングにある。より正確で誤検知の少ないツールもある
プログラマーとして最も重要な責任は、自分が自信を持てる、正しく動作するコードを作ることだ。LLMを使ったかどうか自体は問題ではない。重要なのは、PRを出すときに「私はこの変更が問題を解決すると確信しており、自分の評判を懸けられる」という姿勢だ。したがって、人間であれAIであれ、PRには常に第二のレビュー担当者が必要だ
私は評判こそが核心だと思う。これはコーディングに限らず自然言語の文章でも同じだ。これからは著者ではなく公開した人、つまり投稿者が内容に責任を負う時代だ。5%だけチャットボットでも、95%がチャットボットでも、問題が起きたならその文章を投稿した私が非難されるべきだ。「チャットボットがやったことだから」という言い訳は通用しない
例としてDevinのような完全自動化エンジニアの話をしただけで、一般的なエンジニアとは少し違う状況だ
最近は多くのエンジニアが、AIが作った粗いコードを無責任に投げて、ほかの同僚が問題を見つけてくれることを期待している。以前はコード生成そのものが大変だったので、こうしたことは少なかった
あなたの責任は信頼できるコードを作ることだ、という言葉には深く共感する。ただ、AI以前から良いコードは十分に守られていなかった。私たちはコーディングを手段や金稼ぎとしてしか見なくなっていた。本来そこには「問題を解き、世界を変える楽しさ」があった。だが今は「素早く金を稼ぐこと」や「参入障壁を築くこと」に集中しがちだ。重要なのは美しいコードかどうかではなく、問題を洗練された形で解決できたかどうかだ。AIによってこうした文化が悪化する可能性はあるが、結局はどう使うかにすべてがかかっている
気になることがある。もしPRが問題はすべて解決していて、些細なバグだけを含んでいるなら、そのPRを時間の無駄だと見なすケースの例が知りたい
コードレビューはエンジニアリングで最も遅い工程だ。私もAIなしでコードを素早く書けるが、コードレビューは速くならない。だからレビュー前にAIで事前レビューして同僚の時間を節約し、あらかじめバグも見つけて、配備までの時間を数日単位で短縮している。AIが明白なバグだけでなく隠れたミスまで見つけてくれて、実際に深いバグを発見したこともある。
git cliやxclipなどでdiffをコピーし、o3のようなロジックモデルに貼り付けてレビューしてもらうワークフローを使っているAIの利点の1つは、人間よりはるかに速く大量の単体テストを書けることだ。そして、自分で見つけた問題を自分で修正することもできる。理想的なワークフローは、コードレビューだけでなくAIが自動でテストまで実行し、すべてが特定の仕様を満たしているか確認することだ。テストが多すぎると後のリファクタリングを難しくすることもあるし（たとえば実装の詳細に依存するテスト）、面倒なときはAIが書いたテストだけを別に捨てることもできる
必要なときに単体テストを再生成できるのがとても良いと思っている。レビューを出すとき、diffのサイズに大きな満足感があるし、退屈なテスト作成の時間を節約してより多くの仕事ができる
今でもプログラミングには面倒な作業が残っているが、理想的にはAIがこうした非効率を減らし、人間が創造的な領域に集中できるようにすべきだ。しかし実際には、AIはますます高次の創造的作業にまで踏み込もうとしている
実際のところ、AIでなくてもプロパティベースドテストのフレームワークを使えば、膨大な入力値による自動テストを生成できる
コードレビューするときの自分のルールがある。あとで自分が直接保守する自信がないなら承認しない。もしLLMをコード作成とレビューの両方に使うなら、同じ責任原則をツールにも適用していると言えるかもしれない。しかし実際にそんな状況に長く居続ける自信はない
1つのLLMで要求事項からGherkinスクリプトを作り、別のLLMでそのスクリプトからコードを生成し、Cucumberで結果をチェックするパイプラインを試した人はいるだろうか。いずれにせよGherkinスクリプトもコードもレビューは必要だろうが、こうした方法で作れないコードの種類が何か知りたい。AIを1人の開発者のように見ているが、人間の開発者と同じく、不得意な領域も明らかにあるはずだ
結局、PRを出した著者が自分のコードの影響と結果に責任を負わなければならない。AIコーディングが一般化し、ジュニアエンジニアも増える中で、この責任はさらに重要になった。AIがレビューの第一パスを担うのは合理的だが、人間のレビュアーは外部の視点からコードベースへの理解を深め、より高いレベルの問題を見つける必要がある。結論として、AIが一次レビューを行い、別のエンジニアが文脈や協業の観点からコードレビューを行い、最終的には著者がすべての結果に責任を負う構図が理想的だ