68件のレビューコメントにより、ある関数は28行から42行に拡張され、62件の修正が行われ、それぞれが実際の問題に対処していました。問題はレビュー担当者の正確さではなく、コメントに対する意思決定ルーチンの欠如でした。AIエージェントシステムであるAgentCoopプロジェクトは、OpenAIのCodexを使用して自動コードレビューを行い、すべてのコメントに対処するという厳格なルールを採用していました。これにより、より広範な影響を考慮せずにコメントを修正することがしばしばありました。4つの主要な問題が発生しました。小さく正確な修正によるスコープクリープ。実際のインパクトに関係なく「セキュリティ」または「可用性」タグを緊急に扱うこと。まれな、または存在しない問題のために永続的なコードの複雑さを追加する悪いトレードオフ。そして、根本原因ではなく、コメントが指摘した場所を修正すること。設定ファイルを破損させるアップグレードに関する「クリティカル」な問題は、当初エスカレーションされましたが、後にドキュメントの1つの段落で解決されました。実際のユーザーインパクトは最小限であり、システム全体の停止ではなく、数分間の設定調整で済みました。その後、チームはレビューコメントを評価するルーチンを開発し、直感を超えて進みました。まず、3つの簡単な質問で、修正が安価（10行未満）かどうか、問題が実際に発生するかどうか、そしてサイレントに失敗するかどうか（少なくともログ記録が必要）を判断します。安価な修正は直ちに実装され、到達不可能なコードパスは削除され、サイレントな失敗は優先されるか、または顕著になります。「安価」の重要な注意点は、レビュー担当者の提案ではなく、最も安価で効果的な修正を考慮することです。ステップ1を通過したコメントについては、定量的な評価が数時間かけて行われます。これには、インシデントあたりのバグのコスト、年間発生頻度、ユーザーが許容できるペイン（乗数による）、修正のビルド時間、および永続的な年間保守コストの見積もりが含まれます。これらの値を使用して、年間節約額と修正の回収期間を計算します。正味年間節約額がゼロまたはマイナスの場合、修正は価値がないと判断されます。冒頭の例である設定解析の問題は、分析時に正味マイナスの節約額となり、修正されるべきではなかったことが証明されました。インシデント発生頻度を推定するには、推測ではなく、具体的で証拠に基づいた部分から数値を構築する必要があります。競合状態も同様に、トリガーアクションと脆弱なウィンドウを考慮して評価され、純粋な偶然よりも意図的に調整されたイベントが発生するシナリオが優先されます。