Laurie Voss - co-founder of npm, now Head of DevRel at Arize AI - gave a talk recently called “AI Writes the Code. So What’s Left for Engineers?” The numbers in it are worth sitting with.
Teams using autonomous coding agents generate 741% more code - roughly 8x their previous output. Shipping speed only went up 30%.
That gap is the whole story.
Writing Code Stopped Being the Constraint
For most of software history, the limiting factor on how fast a team shipped was how fast people could write correct code. AI agents removed that constraint almost overnight. A prompt now produces what used to take a day.
If writing code were still the bottleneck, an 8x increase in code production should produce something close to an 8x increase in shipping speed. It didn’t. Teams are stuck at 30%.
Something else is absorbing the difference.
Human Review Doesn’t Scale With Agent Output
Voss’s explanation: code review. Human reviewers have a rough ceiling of about 450 lines of code they can meaningfully evaluate per hour. That ceiling hasn’t moved. What has moved is the size of the diffs arriving in front of them - agent-generated changes routinely span hundreds or thousands of lines, often touching several files for one logical change.
A reviewer who could keep up with hand-written PRs is now being asked to apply the same line-by-line scrutiny to 8x the volume. They can’t, so they don’t - either review slows everything down, or it gets skimmed, and skimmed review is where regressions get through.
Voss frames this as a Theory-of-Constraints problem, not a people problem. Clear the review bottleneck - with better tooling, more reviewers, whatever - and the constraint doesn’t disappear, it moves downstream: to operations and scaling, then to security. He estimates it will take 5 to 10 years before agents handle those well enough to shift the bottleneck again. Review is where it sits right now, and it’s going to sit there for a while.
The Fix Isn’t Reviewing Faster. It’s Reviewing Selectively.
Voss’s advice to engineering leaders is to stop trying to review every line of AI-generated code equally. Scope human attention to the changes with real blast radius - architectural decisions, anything touching auth, billing, data integrity - and build automated evaluators for everything else that’s cheap to verify mechanically.
That’s a triage problem. It assumes you can tell, before a human opens the diff, which parts of a change actually warrant their attention and which don’t.
Most teams can’t make that call systematically today. They rely on whoever’s reviewing to notice that a function looks scary, or on tribal knowledge that “the payments module is where things break.” That works until the person who holds that knowledge is out, or the codebase has grown past what any one person tracks in their head - which is exactly the growth AI-accelerated commit velocity produces.
Where Hotspots Fits
Hotspots ranks functions and files by activity-weighted risk - combining structural complexity with how often and how recently code actually changes. The output is a short list: the 5-10% of a codebase where complexity and churn overlap, which is where defects concentrate.
Applied to review, that list is the scoping mechanism Voss is describing. Instead of a reviewer giving uniform attention to an 800-line agent-generated diff, hotspots tells them which functions in that diff sit in historically fragile, frequently-touched territory and deserve the full 450-lines-an-hour treatment - and which are boilerplate that a test suite or linter can validate just as well.
It doesn’t replace review. It replaces uniform review with targeted review, which is the only version of review that scales when the volume of code in front of you just went up 8x.
If your team is reviewing agent output by vibes right now, hotspots.dev is a place to start making that triage systematic instead of ad hoc.