# Everyone Agrees Code Review Is the Bottleneck. Almost No One Shows Their Math. > Source: > Published: 2026-11-14 19:38:59+00:00 By now, "AI broke code review" isn't a hot take — it's the consensus. LeadDev's 2026 state-of-AI-releases survey, Semgrep, CodeRabbit's defect-density numbers, LinearB's PR-volume benchmarks, and a long shelf of dev.to posts all converge on the same shape of claim: AI agents made writing code cheap, review capacity didn't move, and the gap is now where the pain lives. Laurie Voss made the same point at AIE CODE with a specific pair of numbers — generated code volume up 741% year over year, end-to-end delivery speed up closer to 30%. Naming that gap again isn't useful at this point. What's worth looking at is what almost none of that coverage does next. Scan the "AI code review is broken, here's the fix" posts and a pattern shows up fast. The defect-rate numbers (1.7x more issues in AI-assisted PRs, 91% longer review time, pick your multiplier) are almost always a vendor's blog measuring its own product, or a secondary post citing a figure that doesn't trace back to a primary source with a stated method. The proposed fixes — risk-based routing, AI pre-triage, flag the exceptions — are the right shape. But "risk-based routing" is not itself a method. It's a sentence. Someone still has to say, concretely, which changes count as risky, test whether that rule actually predicts anything, and show the test. That's the gap [hotspots](https://hotspots.dev) was built to close — and no, this isn't a lead-up to a pricing page. It's a free CLI. Point it at a repo and it tells you which files to worry about. `file_risk_score` — hotspots' per-file complexity-and-churn composite — started as the kind of number every static-analysis tool ships: higher score, riskier file, trust it. I tested whether it actually behaved like a probability of a future bug fix, against a 0.8 correlation bar set *before* running the test. It scored 0.515. As a standalone probability claim, it failed. What survived was narrower: files landing in the riskiest 10% of a diff's own files — not the whole repo, just the files already in front of a reviewer — were 6-7x more likely to need a later fix than the rest. That held up across four separate attempts to break it (moving the cutoff, removing each formula term, beating a lines-changed baseline), and then replicated on five repos in five different languages that had never been part of any prior test. [The full methodology, every cutoff table, and a script to rerun it against any repo are public](https://github.com/Stephen-Collins-tech/hotspots-public-research) — including the failed calibration test, which would have been easy to quietly drop. That's now a real flag: `hotspots diff` ranks the files you're actually touching and tells you which ones sit in that top decile, so "review this one harder" is a specific, reproducible claim instead of a gut call. A risk-ranking pitch you can't rerun on your own repo is a claim, not a result. So don't take my word for it — [the methodology and reproduction script are public](https://github.com/Stephen-Collins-tech/hotspots-public-research), the CLI is [free and open-source](https://hotspots.dev), and it runs locally in under a minute with nothing leaving your machine. No account, no sales call, no "contact us for pricing." Go run it on your own repo and try to break the claim.