信頼を得た後、説明可能性には何が起きるのか

What happens to explainability after trust is earnedの意訳です。

CodeRabbitを作り始めたころ、私たちには信頼についての仮説がありました。AIが指摘の理由を説明すれば、開発者はそれを検証できる。そして検証できることが信頼を生む、という仮説です。だから私たちは徹底的に説明しました。すべての指摘に、文脈や理由を添えました。今でも、それは正しい判断だったと考えています。当時のAIモデルは現在ほど高性能ではなく、開発者がその結論に慎重になる十分な理由がありました。説明なしに指摘だけを出すAIレビュアーは、無視されるか、さらに悪ければ盲目的に従われることを求めているようなものです。

そして、それは機能しました。その丁寧さによって、チームはCodeRabbitのレビューを評価し、時間をかけて信頼を築けるようになりました。開発者がCodeRabbitの考えを推測しなければならない場面はほとんどありませんでした。その透明性こそが、指摘を神託ではなく検証可能なものにしていました。

しかし、ある時点で私たちは気づきました。私たちを最も信頼しているチームほど、別のものを求めていたのです。

その気づきから生まれたのがQuiet modeです。レビュー全体はそのまま維持しながら、インラインコメントは最も重要である可能性が高い指摘に絞る、新しいレビュープロファイルです。

信頼によって変わるもの

包括的なコードレビューのフィードバックが持つ価値は、チームがそのツールとどのような関係にあるかによって変わります。AIレビュアーを評価している段階では、説明された指摘の一つひとつが証拠になります。量が欲しいのです。何を検出し、その理由が妥当かどうかを学ぶには、量が必要だからです。

いったん信頼が確立されると、計算は変わります。インラインコメントは無料ではありません。コメントの一つひとつは、人間同士の会話に割り込み、開発者に立ち止まって評価し、今それが重要かどうかを判断するよう求めます。大きなPRや日常的なPRでは、本当に丁寧なレビューは多くの指摘を生みます。それらがすべて同じ目立ち方で届くと、重大なロジックエラーと小さな提案が同じスレッドに同じ重みで並び、優先順位をつける仕事は開発者に渡されます。

まだ信頼を得ていないツールであれば、その順位付けを開発者に任せるのは妥当です。順位付けには判断が必要であり、検証していないツールに判断を預けることにユーザーが慎重になるのは当然だからです。しかし、CodeRabbitが何百回も正しい判断をしてきたことを見ているチームは、すべての指摘をインラインで再検証する必要はありません。検証はもう済んでいます。今必要なのは優先順位付けです。順位付けを毎回自分たちで続けるよう求めることは、透明性ではなく宿題になっていました。

これが、私たちが説明可能性について考えるうえでの捉え直しです。説明可能性とは、説明の量ではありません。もともとそうであるべきでもありませんでした。重要なのは、意思決定を変えられる瞬間に、適切な説明が届くかどうかです。信頼を築いている段階では、包括的なフィードバックがその目的を果たしていました。その段階を過ぎたチームには、対象を絞ることのほうが有効です。

Quiet modeは削減ではなく優先順位付け

Quiet modeを有効にしても、CodeRabbitはこれまでとまったく同じようにPRをレビューします。深さも、カバレッジも同じです。変わるのは公開の判断です。PRの結果を変える可能性が最も高い指摘、たとえばCodeRabbitがhigh-rewardと分類するcriticalやmajorの問題だけがインラインに投稿されます。それ以外はレビューサマリー内のグループ化されたセクションに移動します。その他のcriticalとmajorの指摘は一つのグループに、minorとinformationalの指摘は別のグループに入ります。

何も捨てられません。レビュー全体は今でもそこにあり、1回展開すれば確認できます。しかも、どれだけ重要かに応じて整理されています。PRの会話は、立ち止まる価値のあるコメントに集中できます。そしてサマリーにはQuiet modeが有効であることが示されるため、CodeRabbitが勝手に静かになったのではないかと誰かが疑うこともありません。

この対象を絞った説明可能性は、私たちのプロダクト判断です。レビューエンジンの仕事は、すべてを見つけることです。インターフェースの仕事は、優先度について正直であることです。つまり、実質的にはこう伝えることです。これらの指摘が、あなたを中断した理由です。残りは、必要なときにここにあります。 その二文目もまた、説明なのです。

レビュアーにどれくらい存在感を持たせるか

Quiet modeは、ChillとAssertiveに続く3つ目のレビュープロファイルです。3つが揃うことで、暗黙だったトレードオフが明示されます。Assertiveは、nitpickを含めてすべてをインラインに表示したいチーム向けです。実際に、それを求めるチームはたくさんあります。デフォルトのChillは、その中間にあるバランス型です。Quietは、すでにレビューを信頼していて、PRスレッドを最も重要な指摘のために確保したいチーム向けです。

これらのプロファイルはいずれも、CodeRabbitがレビューする量を変えるものではありません。変えるのは、見つけたことをどのように伝えるかです。この選択が存在すべきレイヤーはまさにそこです。チームによってPRの読み方は違いますが、バグを見つけてほしいという点は変わらないからです。

対象を絞った説明可能性への進化

まだ発見していない指摘に優先順位をつけることはできません。そして、十分な深さを証明するまでは、洞察を選別することもできません。CodeRabbitの初期の包括的な時代は、間違いではありませんでした。それは必要不可欠な第一幕でした。

Quiet modeが存在するのは、エンジニアリングチームが私たちのレビューを深く信頼するようになり、ボトルネックが移ったからです。問いはもはや、「AIは問題を見つけたのか？」 ではありません。今では、「自分のPRスレッドは読みやすいか？」 になっています。

Quiet modeは、CodeRabbit設定でreviews.profile: quietを指定することで利用できます。