AI didn't remove your bottleneck. It moved it onto the one person who can't scale.

Throughput per developer is up 33.7%. Median time in code review is up 441.5%. If you're a solo maker, you are the review queue — and you quietly stopped showing up for the shift.

There's a report that came out this spring that I keep coming back to, and I don't think it landed properly with makers because it's written for engineering leaders at big companies. Faros AI published "The Acceleration Whiplash" in April — two years of telemetry from 22,000 developers across more than 4,000 teams. Not a survey about how developers feel. Actual measurement of what came out the other end.

The headline finding is the one everyone quoted: throughput is up. Epics completed per developer up 66%. Task throughput per developer up 33.7%. PR merge rate up 16.2%. Real acceleration, and I don't want to be cynical about it, because it's the thing that let me ship a product I couldn't have built otherwise.

But the numbers underneath are the ones I'd tape to the wall. Median time in review: up 441.5%. Median time to first review: up 156.6%. And this one, which is the whole article in a single stat — pull requests merged with no review at all, human or agentic, up 31.3%.

Read that sequence again in order. Writing got faster. Reviewing got much, much slower. And so a growing share of code stopped getting reviewed at all.

That's not a discipline failure. It's an arithmetic one. The reviewers didn't get lazy; the queue got faster than they are, and something had to give.

Here's why this matters more for us than for the enterprise teams the report is actually about. In a company, "merged without review" is a deviation from a process. Somebody eventually notices the number in a dashboard. If you're solo or two people, unreviewed merging isn't a deviation — it's the default state, and it always was. You never had a second pair of eyes. What changed is that the volume flowing past those absent eyes went up several times over, and the code arriving now is code you didn't write and often can't fully explain.

The report has a good phrase for the mechanism: AI-generated code is "superficially convincing." Idiomatic, well-named, stylistically consistent with everything around it. It reads like code written by someone competent, because it was trained on code written by someone competent. The failures are structural and they sit underneath a surface that gives you no reason to look. Reviewing it properly means reconstructing what the code was supposed to do and checking whether it does that — which is slower than writing it yourself, and enormously slower than skimming it and hitting merge. Everyone skims. I skim.

The downstream numbers are what you'd expect from that. Incidents per merged change up 242.7%. Bugs per developer up 54% — and worth noting, in the same team's 2025 report that figure was 9%. It's steepening, not flattening, as adoption matures. Code churn, lines deleted against lines added, up 861%. Some of that churn is healthy refactoring that was finally cheap enough to do. Some of it is code that got accepted fast and thrown away a week later. You cannot tell which from the outside, and honestly most of us can't tell from the inside either.

One finding I'd flag because it cuts against the comfortable story: Faros looked specifically at whether strong engineering fundamentals protect you, and found they don't. Teams with mature practices and good DORA scores showed the same downstream deterioration as everyone else. Their read on why surveys say otherwise is sharp — developers feel more productive because individually they are. Perception lags reality. The queue backing up doesn't feel like anything until it does.

And a genuine counterweight, because I don't want to write a doom piece. An empirical study out of NAIST and Nara College, presented at EASE 2026, tracked AI-generated files in real repositories for six months after merge. AI-generated files actually received less maintenance than human-written ones, and smaller changes when they did. That's a real result and it complicates the panic. But read their own caveat, which is the honest part: low maintenance frequency doesn't prove quality. Developers may simply be avoiding code they find hard to comprehend. And when maintenance does happen, humans do about 83% of it — the agent that wrote the file contributes roughly 17% of the work of keeping it alive. Whatever the agent produced, you own it.

So what do you actually do, as one person, without pretending you're going to institute a review process for yourself?

The only thing that's worked for me is to stop treating review as a step and start treating it as a budget. Whatever time I saved not writing the thing, some fixed fraction of it goes back into reading the thing — before merge, not after the bug report. Ten minutes of generation buys three minutes of reading. It's not rigorous and it doesn't need to be; the point is that the ratio can't be zero, and left alone it drifts to zero.

The second thing: pick the surfaces where you refuse to skim, and be specific. Anything touching auth, payments, data deletion, or what leaves your machine gets read line by line no matter how convincing it looks. Everything else gets the budget. I'd rather have two categories I actually honor than one standard I quietly abandon by Thursday.

And the last one is less a technique than a posture. If you can't explain what a piece of your product does, that's not a neutral fact about your codebase, it's a debt with an interest rate. Sometimes I take that debt on purpose — I've shipped things I couldn't fully explain and I'd do it again. But I try to know when I'm doing it, and I try not to do it in the places where being wrong is expensive.

The acceleration is real. I'm not giving it back. But the thing to internalize from a dataset this size is that the work of making output safe and correct didn't shrink when the output got cheap. It grew, and it moved, and if you're small it moved onto exactly one desk.