Everyone Agrees Code Review Is the Bottleneck. Almost No One Shows Their Math.
Key Points
What is Hotspots?
Hotspots is a free, open-source CLI that scores every function and file in a codebase by structural complexity, then layers in git history to separate active risk from dormant debt — surfacing which changes most need a human's limited attention instead of asking for uniform scrutiny on everything. It runs locally in under a minute, with no account and no code leaving your machine — hotspots.dev (source at github.com/Stephen-Collins-tech/hotspots).
Isn't "the bottleneck moved to review" already a well-known point?
Yes — by late 2026 it's been argued by LeadDev, Semgrep, CodeRabbit, LinearB, hackernoon, and a long list of dev.to posts, several citing real PR-volume data. This post isn't trying to make that case again. It's pointing at what's missing from nearly all of that coverage — a triage method that states a falsifiable claim, tests it against real outcomes, and publishes the result either way.
What's wrong with the existing "AI pre-triage" pitches?
Nothing in principle — risk-based routing is the right shape of fix, and several vendors propose it. The gap is evidence. Most published figures (defect multipliers, review-time increases) come from a vendor's own blog measuring its own tool, or from aggregator posts citing numbers that don't trace back to a primary source. A reader has no way to check whether the claim would survive on their own codebase.
What does Hotspots do differently?
It states one specific, falsifiable rule — a file in the riskiest 10% of its own diff is more likely to need a later fix — pre-registers the bar for success before running the test, reports the result even when the headline metric (a calibrated probability) failed, and re-tests the surviving narrower claim on five repos never used to find it. The methodology and a reproduction script are public, so the 6-7x figure isn't something you have to take on faith.
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.
The part everyone skips: showing the test
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 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.
One rule, pre-registered, tested against real outcomes
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 — 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.
Go break it yourself
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, the CLI is free and open-source, 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.