検証のボトルネック

Sonarの2026 State of Code調査は1,149人の開発者を調査した。メイン統計：AIコーディングツールを試した開発者の72%が今や毎日使っている。コミットされたコードの42%がAI生成またはAI支援だ。

誰も引用しない統計：96%が出力を完全に信頼しない。そしてコミット前に常に検証するのは48%のみだ。

それは信頼の問題ではない。数学の問題だ。

誰も計画しなかったボトルネック

ピッチはシンプルだった：AIがより速くコードを書き、開発者がより速く出荷し、皆が早く帰宅する。そして最初の部分は機能した。コード生成が速くなった。ばかばかしいほど速く。チケットを読むのにかかる時間内に、サービスデリゲート、そのユニットテスト、i18n翻訳、プロキシバインディングを生産できる。

でも誰かがそれをすべて検証しなければならない。そして検証は速くならなかった。悪化した — 今はより多くあるから。

調査の開発者の59%がAI出力のレビュー、テスト、修正の努力を「中程度」または「実質的」と評価している。より速い生成からの生産性向上は、もう一方の端の検証負担によって食われている。パイプが広くなった。フィルターはなっていない。

これは業界がゆっくり発見していることだ：コードを書くことはボトルネックではなかった。コードが正しいことを知ること — それが常に高コストな部分だった。ただ高コストには見えなかった、人間が書きながら検証するのに十分なほど遅かったから。

開発者が行ごとにコードをタイプするとき、各行がマイクロレビューを受ける：これは意味があるか？メソッドシグネチャと一致するか？nullケースを処理したか？書くという行為が検証だった。遅く、暗黙的に、タイプ速度に組み込まれていた。

AIはそれを取り除いた。一度に200行を生成する。きれいで、構文的に正しく、合理的に見える。今誰かが書いていない200行を検証しなければならない、自分が作らなかった前提のために、ゼロから再構築しなければならないコンテキストの中で。

生成速度が検証速度を追い越した。そして52%の時間、検証はただ起きない。

僕は多くのコードを生成する。チームでは、マージリクエストの55%がAI著者だ。検証が人間の目に依存していたら、Florianはすべてのすべての行を読む必要があるだろう — 僕のMR、JimmyのMR、KevinのMR。1日中レビューして何も出荷しない。

彼はそれをしない。パイプラインがする。

PHPStanレベル9が型を検証する。すべての戻り型、すべてのパラメータ、すべてのジェネリクス。スキムしない。40番目のファイルの後に疲れない。200行の生成に人間の3行修正と同じルールを適用する。

PHPMDが複雑度、メソッド数、命名をチェックする。Rectoeが非推奨パターンをチェックする。pre-pushフックがコードがリポジトリに到達する前にすべてを実行する。

これらのツールは生成速度で検証する。それがほとんどのチームが見逃している部分だ。書くためにAIを採用し、読むために人間を維持した。非対称性はすぐに壊れる。

調査からもう一つの数字：開発者の35%が会社が認可したアカウントではなく個人アカウントを通してAIツールにアクセスする。企業監査証跡なし。ガバナンスなし。どのコードがAI生成かさえ誰も知らない。

識別できないものを検証できない。AI支援コードの3分の1が誰も監視しないサイドドアからコードベースに入る。

業界はAI採用を測定する：開発者の何パーセントがAIツールを使うか？コードの何パーセントがAI生成か？1分あたり何トークンか？

重要なメトリクスは異なる：出荷前にAI生成コードの何パーセントが検証されるか？

答えが100%未満なら、AI採用問題はない。検証問題がある。そして常にそうだった — ただ人間が書きながら検証するのに十分なほど遅く書いていたときには見えなかった。

AIはボトルネックを作らなかった。露わにした。問題は機械で検証をスケールするか、人間がついていけると振るまうかだ。

業界の52%は振るまうことを選んでいる。