Anthropicによると、Claude Codeは現在、自らのコードの約90%を書いており、チームはその成果をレビューする方法を見直している。Addy Osmani、Morgan Westlee Lunt、Qing Wangによる投稿では、プルリクエストの大半を、変更を書いた本人でもよい人間のレビュー担当者を最大1人としてマージすることを目指すと説明している。リバートやインシデントを増やさずに実現するのが目標だ。
チームによると、レビュー担当者がClaude Codeの全体像を頭に入れておく必要はない。理解が必要なコードベースの箇所について、Claudeに説明を求めるという。この方法はHacker Newsの議論で批判を招いた。AIの説明に頼ると、モデルの理解が誤っていた場合に、誰も問題をデバッグできなくなるのではないかと、コメント投稿者らは疑問を呈した。
レビューの承認基準
変更内容に基づいて分類器がリスク段階を割り当てる。変更者が誰かは考慮しない。ドキュメントや文言の変更、フィーチャーフラグの背後に追加する機能など、リスクの低い変更は人間の承認なしで通過できる。キャッシュ、自動アップデーター、システムプロンプトなどに関わる中リスクの変更には、1人の承認が必要だ。エージェントによる承認は人間の承認として数えないが、変更を指示した本人が必要なレビュー担当者を兼ねることはできる。
レビュー工程自体にも失敗する可能性がある。エージェントは、人間なら無視するかもしれない指摘にも対応する。Anthropicは、あるプルリクエストが一晩で50回を超えるレビューと修正を経た後、作成者が止めた事例を紹介している。レビューの回数を増やすだけでは状況が悪化すると分かったため、チームはレビューのラウンド数に上限を設けたという。また、後半のラウンドで指摘されたコードの約59%は、レビュアーが最初に確認した時点ですでに存在していたことも分かった。
なお残る不確実性
Claude Codeの公開リポジトリにある別の事例は、自動生成された説明の限界を示している。8月、Claudeが生成した回答は、問題を再現するために必要な情報が不足していたため、活動がない状態として課題をクローズしたと説明した。しかし、リポジトリのルールでは、課題にstaleラベルを付けて14日間経過した後、さらに14日が過ぎるとクローズできる。ただし、10以上のupvoteがある課題は例外だ。ある開発者は、再現手順ありとラベル付けされながら、非アクティブとしてクローズされた課題が6,000件以上あると数えた。また、コメントを投稿すれば課題を再開できるという回答の提案も、クローズから7日後に課題をロックするワークフローに阻まれた。
Anthropicによると、レビュー指標が悪化した場合に承認要件を厳しくするサーキットブレーカーは、まだ用意できていない。同社のCode Review製品は、TeamおよびEnterpriseプランで一般提供されている。セキュリティレビュー用のGitHub Actionはオープンソースだが、READMEでは、プロンプトインジェクションへの対策が十分ではなく、信頼できるプルリクエストのレビューに限って使うよう警告している。
なぜ重要か
AI主導のコードレビューを検討するチームにとって、Anthropicの仕組みは、低リスクの変更なら人間の承認なしでマージできる一方、中リスクの変更には引き続き人間の承認が必要であることを示している。同社は、レビュー指標が悪化した際に承認要件を厳しくするサーキットブレーカーをまだ構築していないとしており、安全策が機能しなくなった場合にどう対応するのかは、今回の投稿からは分からない。
