- AIがコードを書く時代には、プルリクエスト（PR）レビューの方式そのものを根本から変える必要があり、現在のレビュープロセスはAIコーディングのワークフローに適していない
- レビュアーが「なぜこうしたのか？」と質問すると、開発者がAIに聞き直してその回答を貼り付ける構図になり、人間が仲介者（middleman） にとどまる非効率が生じる
- AIの**意思決定ログ（decision log）**をコードとともにソース管理に含め、レビュアーが文脈を直接確認できるようにすべき
- レビュアーのコメントをAIが直接受け取り、パッチと応答を自動生成するワークフローは、GitHub/GitLabのWebhookとMCPサーバーの組み合わせですでに実現可能
- 設計文書やアーキテクチャ図も、MarkdownやMermaidのようなLLMが解析可能なフォーマットでソース管理に含めるべきであり、「コンテキストが王」
AI時代のコードレビューの問題点
- PRレビューで質問するとAIが生成したような回答が返ってくるが、実際にコードを書いたのがAIだからである
- 「なぜこのライブラリを選んだのか？」という質問に人間の開発者は答えられず、AIに再度質問してから回答をコピーして伝える構図になっている
- AI以前は開発者（コードを書いた本人）に直接聞いており、そのマネージャーに聞いていたわけではないので、仲介者を排除すべき
- コードのすべての作成者がレビューに参加すべきであり、レビューの質問に対して別のAIエージェントが事後的に理由を逆推論する方式は完全に誤ったアプローチ
意思決定ログの必要性
- 人間に「なぜ？」と尋ねるときは、PRに含まれていない内部の思考過程を尋ねている
- AIのchain-of-thoughtは外部監査可能（externally auditable）であり、AIとの相互作用の記録も監査可能なので、この文脈をレビューとソース管理に入れるべき
- PR作成の過程で生成されたすべてのトークンをコミットする必要はなく、Random Labsのepisodeの概念に着想を得て、成功したツール呼び出しと結論のトランスクリプトだけを含める
- エージェントスウォーム（agent swarm）環境でも拡張可能で、PR前段階で意思決定ログをつなぎ合わせ、最終的な整形を行う
インラインコメントの限界
- ソースファイルの変更は、コメントだけを修正する場合でもビルドパイプラインの再実行（リンティング、コンパイル、テスト）が必要
- 意思決定のトランスクリプトは、通常のインラインコメントで許容される分量よりはるかに大きい
- 既存のコメントはコードが現在どのように動作するかを説明するものであり、その決定に至るまでの過程は説明しない
AI統合レビューのワークフロー
- レビュアーがコメントを付けると、開発者のAIがそれを直接受け取り、パッチと応答を自動生成できるべき
- GitHub/GitLabのWebhookとMCPサーバーの組み合わせで、現時点ですでに実装可能
- Devin AIやClaude Code via GitLab Duoに近い方式
- 開発者がまずAIに許可を求めるよう設定することも、AIが自律的に判断してすぐ対処するよう設定することも可能
- 人間の開発者も引き続き自分でコメントや修正を行える
- レビューコメントが数時間あるいは数日後になってようやく反映されたり、まったく反映されなかったりする問題を大幅に減らせる
レビュアー向けツールの要件
- レビュアーもコードベースを探索するように、PRをAIに直接質問しながらレビューできるべき
- 意思決定ログがコードと一緒にチェックインされていることが、この目的のために重要
- 既存のPRインターフェースをそのまま使いつつ、横にCodexやClaudeと会話できるウィンドウをIDEの開発環境のように統合すべき
- まだ洗練されたツールがないので、誰かが作ってくれるとよい
- diffで知らないライブラリ、見慣れない言語、ベストプラクティスについてAIと非公開で質疑応答したうえで、コードレビューコメントが必要かどうかを判断する
- コメントが必要な場合、それは意思決定ログに**空白部分（gap）**があるというシグナルなので、PR承認前にログを更新すべき
設計文書とコンテキストの重要性
- AI統合レビューでは、レビュアーが直接パッチを提案することもはるかに容易になる
- 設計文書、意思決定記録（decision records）、アーキテクチャ図をMarkdownやMermaidのようなLLMが解析可能なフォーマットでソース管理に追加すべき
- 「コンテキストが王（Context is king）」
10件のコメント
PR が死んだ理由は、PR そのものというより、Vibe coder たちのずさんなコミュニケーションにあるように思います。
どんな flow で実装したのか、他にどんな方法があってなぜ採用しなかったのか、なぜ package.lock が変わる必要があるのか。どれも先に説明しておくべきことではないでしょうか？
PR Description に書いておけば済むことなのに、わざわざ聞かせるようなコーダーたちのほうが淘汰されるべきだと思います。
同感です。昔のPRには、自分が作った成果物に自分で責任を持つという感覚がありましたが、
Vibe coderのPRは「自分が何を作ったのかも分からないし、とにかく成果物はあるので、あなたが評価して問題点を見つけてくれ」という感じです。
同感です。
まず話し合うべきことを、後で責任を取らない形で進めています。
同感です。いら立つほどですね。
同感です。
1つのPRで500ファイルも変更されているのに、提出した本人は30分以内にレビューしてくれなかったと不満を言っているんですね。説明欄には5〜6行だけ書いて終わりだし、これをそのまま信じて承認しろってことなのか……？
テストは全部やったよね？
はい
よし、頑張ろう
何でもかんでも死んだって言うなよ
このままじゃみんな死ぬ！
何かあるたびに「死んだ」というタイトルの記事が増えすぎて、
かなり疲れてしまう感じがします。
私も、もうそろそろ殺すのはやめてほしいと思います
「死んだ、万歳」
という類いの記事が増えすぎていますね。でも、AIがすべてを変えつつあるという点は認めます。