この記事は、コーディングエージェントによってソフトウェアエンジニアリングの難所がコードを書くことから、そのコードを信頼するかどうかを判断することへと移り、コードレビューが現在のソフトウェアにおいて最もレバレッジの効くスキルになったと論じる。記事は 2026 年の業界データを概観し、AI の導入が開発者のアウトプットを大きく押し上げる一方で、コードチャーン、欠陥率、レビューにかかる時間、そしてまったくレビューされずにマージされる PR の割合も押し上げていることを示す。そのうえで、適切なレビューの労力は、全員に適用される単一の基準ではなく、変更の「影響範囲（blast radius）」、すなわち誤っていた場合に何が壊れるか、そのコードがどれだけ長く使われるか、何人がそれを理解する必要があるかによって決まると主張する。
記事はまた、レビューの中心的な問題が変わったと論じる。人間がコードを書く場合、その推論はレビュアーが確認できる形で存在するが、エージェントの推論は diff が生成されると通常は破棄されてしまうため、レビュアーは一度も書き留められなかった意図を再構築しなければならない。記事は、レビューを速くするために、エージェントが述べた推論を意思決定ログとして記録することを推奨する。そして結びとして、AI レビューツールがレビュー作業のより多くを担うようになるにつれ、人間はすべての diff を読むことから、説明責任を負うこと、その変更が作るべき正しいものかどうかを判断すること、最もリスクの高い変更だけをゲートすることへと役割を移すべきだと論じる。
要点
- Faros AI が 2026 年 3 月に 22,000 人の開発者と 4,000 チームを対象に収集したテレメトリーによれば、AI の導入度が低い状態から高い状態へ移ると、コードチャーンは 861%、インシデント対 PR の比率は 242.7%、開発者 1 人あたりの欠陥率は 9% から 54% へ、レビュー時間の中央値は 441.5%、レビューなしでマージされた PR は 31.3% 増加した。成熟した規律あるエンジニアリングプラクティスを持つチームも、他のチームと同じように影響を受けていた。
- CodeRabbit が 2025 年 12 月に 470 件のオープンソースの PR（AI との共著が 320 件、人間のみが 150 件）を対象に行った調査では、AI が書いた変更には人間のみの変更の約 1.7 倍の問題が含まれており、ロジック／正確性の問題は約 75% 多く、セキュリティの問題は 1.5〜2 倍多く、可読性の問題は 3 倍以上に増えていた。
- GitClear の 2025 年までの生産性データによれば、AI を毎日使うユーザーは非ユーザーの約 4 倍の生のコード量を生み出すが、本人の前年のアウトプットと比べた実際の生産性の向上は約 12% にすぎない。
- GitHub は、Copilot のコードレビューがこれまでに 6,000 万件を超えるレビューを実行し、1 年足らずで 10 倍に増えたこと、そしてプラットフォーム上のレビューの 5 件に 1 件以上にエージェントが関与していることを報告している。
- 4 つの AI コードレビュアー（CodeRabbit、Sentry Seer、Greptile、Cursor BugBot）を 146 件の実際の PR に並列で適用し、679 件の指摘を得た独立したテストでは、指摘された 617 の異なる箇所のうち 93.4% は 4 つのツールのうちちょうど 1 つだけが検出しており、4 つすべてが検出した箇所は 1 つもなかった。これは、「最良の」ツールを 1 つ選ぶのではなく、異なる作りの複数のレビュアーを動かすべきだという論拠として示されている。
- Anthropic の社内コードレビューツールは、その指摘のうち Anthropic 自身のエンジニアに誤りとされたものが 1% 未満であり、実質的なレビューを受ける PR の割合を 16% から 54% に引き上げたと報告されている。
- 記事は次のことを推奨する。レビューの労力を作成者ではなく変更の影響範囲に応じて段階分けすること。「サーキットブレーカー」モデルを使い、重いメンテナンスが必要になると予測される PR を人間が見る前に即座に却下すること。レビューの前に証拠（述べられた根拠、テスト出力、テストを実行した証明）を求めること。エージェントが書いた PR は平均して大きくなりがちなので小さく保つこと。エージェントは根底にある振る舞いを修正する代わりに失敗しているアサーションを書き換えることがあるため、テストファイルの編集は特に注意深く読むこと。そして CI を、その判定を言いくるめて覆すことのできない厳格なゲートとして扱うことである。
- 記事はこの変化を、「ヒューマン・イン・ザ・ループ」が「ヒューマン・オン・ザ・ループ」になることとして捉える。人間はすべての diff を読むのではなく、説明責任を保持し、その変更が作るべき正しいものかどうかを判断し、影響範囲が最も大きい変更をゲートし、すべてをレビューするのではなくシステムをサンプリングして監査する。
- 元 Meta のエンジニアである Kun Chen を紹介している。彼は事前に詳細な計画を書き、自動化されたマージ前のゲートに頼ることで、行単位のレビューをほとんど行わずに 1 日に約 40 件の PR を出荷している。ただし記事は、このアプローチは一般的に推奨されるものではなく、彼の特定の状況（大規模なチームやレガシーシステムを持たない単独の開発者）に適したものだと注記している。
背景
記事は、「AI slop」に関する 15 の Reddit と Hacker News のスレッドにわたる 1,154 件の投稿を分析した 2026 年の研究を引用し、エージェントの PR をレビューすることで、レビュアーが「このコードを目にする最初の人間」になりうるという観察を紹介している。そして自らを、ループエンジニアリング、意図の負債、理解の負債に関する著者の他の記事と並ぶものとして位置づけている。また、盲点が相関した複数の AI レビュアーによる閉じたループは、それを捉える人間が誰も残っていないまま、確信に満ちているが誤った判定を下しうると警告している。これは、著者が別の場所で 認知的降伏 として捉えているリスクである。