PR2倍超でrevert率40%減

チームが何を測るかという変化として今回の取り組みを位置づけている。人がコードを読んだかどうかを問うのではなく、何が壊れうるか、それを捕まえるのに自動と人のどちらのチェックが適切かを問う。人の時間は最小化すべきコストとなるが、それはrevert率とインシデント率が横ばいである場合に限られるため、チームはこれらを、単に作業を別に移すだけにならないためのガードレールとしている。

レビュープロセス自体は、完璧な単一のゲートではなく、重なり合う層として構成され、その下にロールバックが床として置かれている。人の承認は複数ある層の一つであり、誰が書いたかではなく変更のリスクによって割り当てられる。エージェントの承認を人の承認として数えない別のルールもあり、責任はエージェントに指示した者に帰される。

最も実用的な記述は、AIレビュアー間の収束に関するものだ。あるCLIのPRは、著者が止めるまでに一晩で50回以上のレビューと修正のラウンドを経た。git blameによると、指摘された問題の約59%は、レビュアーが最初にコードを見た時点で既に存在していた。3ラウンドの上限やdiffのみの再レビューを含む修正により、単一ラウンドのマージ率は65%から78%に上がり、平均レビューラウンド数は2.08から1.32に減った。

人に残るのは、より狭い範囲の判断だ。そもそも何かを作るべきか、高リスクのコード、アーキテクチャ、証拠を読むこと、結果に責任を持つこと。チームは、チーム外からの変更については、その作業をそもそも行うべきかを誰かが問えるように、特に人によるレビューを残しているという。また、Claude Codeの完全なメンタルモデルを持つ者は誰もおらず、人は必要に応じて一部を学ぶとも述べている。