For seventy years, the economics of software rested on one assumption: writing code is expensive. Everything we built around it — team structures, sprint rituals, seniority ladders, the metrics on your dashboard — priced code production as the scarce resource. In 2026 that assumption quietly died. Code is now cheap. And almost nothing downstream of the keyboard has been repriced.
This week's article is about where the bottleneck actually went, why your dashboard probably can't see it, and what the honest data — including the data against my own thesis — says about what happens next.
Where we actually are
Start with the volume side, because it's not in dispute. Faros AI's 2026 AI Engineering Report, built on telemetry from 22,000 developers across 4,000 teams, found that under high AI adoption, tasks with code completed increased 210%. Pull requests got 51% larger, touching 60% more files. Production is up, massively and measurably.
Now the other side of the ledger, from the same dataset: bugs per PR are up 54%. Median time to first review is up 157%. Median time in review is up 441% — not a typo, the review queue didn't degrade, it broke. And the pressure release valve is the worst one available: 31% more PRs are merging with no review at all.
The quality data explains why review got harder, not just bigger. CodeRabbit analyzed 470 real-world pull requests and found AI-authored code carries 1.7× more issues than human code, with logic and correctness errors up 75%. The dangerous part is how it's wrong: AI code is idiomatic, consistently styled, and structurally tidy even when the logic is broken. Bad human code announces itself — awkward naming, obvious shortcuts. Bad AI code fails in ways that look like competence. Catching it requires reconstructing intent, which is the most expensive cognitive work a senior engineer does.
Two more data points close the loop. A JetBrains behavioral study of 800 developers, presented at ICSE 2026, tracked actual IDE telemetry and found AI users performing roughly 100 delete/undo actions a month against 7 for non-AI users — a 14× gap in rework that half the developers didn't notice in themselves. Which rhymes with the most uncomfortable result in the field: METR's randomized controlled trial found experienced open-source developers were 19% slower with AI tools on mature codebases they knew well — while estimating they'd been 20% faster. (METR itself now flags the result as historical — tools have moved on — but the perception gap it documented keeps replicating.)
And the honest counterpoint, before I build anything on this: the aggregate picture is improving, not collapsing. Google's DORA program, which in 2024 found AI adoption correlated with lower delivery throughput, reported in its latest State of AI-assisted Software Development that throughput has caught up — modest gains, honestly labeled — though delivery instability continues to rise alongside adoption. Organizations are adapting. The bottleneck is real, but it is not a law of physics.
So here is the state of play, stated plainly: generation scaled roughly 3×; verification scaled roughly 0×. Coding was always a minority of the work of shipping software — GitLab's research puts it around 15%, with the other 85% in review, testing, security, compliance, and deployment. AI turbocharged the 15% and left the 85% running on human attention, which does not scale by buying more tokens.
The trajectory
Three extrapolations I think the data supports.
The scarce resource in software engineering is repricing from production to judgment. The senior engineer tax is what repricing looks like mid-transition: the people with the pattern recognition to catch subtly-wrong code are absorbing the load, at the exact moment only 16% of senior developers say juniors fully understand the AI-generated code they submit (BairesDev's Q2 2026 survey of 1,569 developers). Verification skill — the ability to look at plausible output and know whether it's true — is becoming the paid skill. Hiring hasn't caught up; it will.
The verification gap gets attacked from both ends, and partially closes. Upstream: context engineering — feeding agents repo history, architectural decisions, spec intent — measurably improves first-pass correctness; Faros's own eval found a previous-generation model with repo context outperforming a frontier model without it. Downstream: AI review agents went from 0% to 25% of PRs in a year. Neither solves intent verification — an automated reviewer without ground truth about what the code was supposed to do can flag patterns but can't reconstruct purpose — but together they compress the gap from crisis to chronic condition.
Metrics regimes will be rebuilt, because the current ones are now measuring the wrong scarcity. A dashboard that celebrates merged PRs is celebrating the thing that got cheap. DORA's own authors have spent two years warning that AI amplifies whatever organizational system it lands in. The teams that instrument verification — review depth, escaped defects, rework, time-to-trust — will see the bottleneck; the teams that instrument production will see a triumph right up until the incident review.
The limits of these extrapolations, explicitly: the most dramatic numbers (441%, 210%, 54%) come from vendors who sell engineering-metrics products — treat directions as solid, magnitudes as marketing. "High AI adoption" cohorts are self-selected, not randomized; teams drowning in review debt may simply be the teams shipping the most ambitious work. And the two-sided attack on the gap is improving fast enough that this article's core tension could look dated in eighteen months — DORA's throughput reversal between 2024 and 2025 is proof the ground moves.
What if...
This section is speculation, clearly flagged as such. These may or may not happen. For each one I'll say what would need to be true.
What if code review inverts? Today: humans write intent sloppily (tickets, vibes, Slack threads), machines generate code, humans verify the code. A plausible end-state flips it: humans write intent precisely — machine-readable specs, executable acceptance criteria — and machines verify machine-generated code against that spec continuously. Review stops being archaeology and becomes specification. The senior engineer's job title survives; the job becomes writing down what "correct" means. What would need to be true: intent capture has to get an order of magnitude cheaper — spec languages that feel like writing, not like formal methods homework — because today nobody writes specs precisely for the same reason nobody wrote tests before frameworks made it cheap.
What if the rework economy becomes visible — and billable? The JetBrains 14× rework signal is today invisible: it hides inside "development time." If token costs keep falling but senior-attention costs keep rising, someone will start pricing the two separately — engineering orgs accounting for "generation spend" versus "verification spend" the way cloud FinOps split compute from egress. The moment verification cost lands on a dashboard as a line item, the 85% gets the investment the 15% has been hoarding. What would need to be true: attribution — telemetry that can trace a rework hour back to the generated change that caused it. The pieces (IDE telemetry, PR provenance tagging) exist; nobody has assembled the bill yet.
What if we're wrong about the direction entirely, and verification becomes abundant too? Everything above assumes checking is intrinsically human-bounded. But test generation, property-based checking, and review agents are improving on the same curve that made generation cheap. If verification gets its own 210% moment — machines that can prove behavioral properties of generated changes cheaply — the bottleneck dissolves rather than migrates, and the 2026 review-queue crisis becomes a transitional anecdote, like the early-2000s panic about testing capacity before CI. What would need to be true: verification agents would have to close the intent gap, not just the pattern gap — and that's the same unsolved problem from both this article and last week's: machines that can tell you what code does, but not yet whether it's what you meant.
What I'm doing about it
I run a content and research operation staffed almost entirely by autonomous agents — the article you're reading was researched and drafted inside that system. Which means I hit this exact bottleneck months ago, at small scale, and got to feel it before I read about it.
The design answer I converged on, borrowed from my agent_factory pipeline: nothing generated ships without passing a gate that is separate from the generator. In agent_factory, producer agents create; a distinct curator agent scores every asset against a rubric with a hard threshold, and anything below it dies — the curator has no stake in the producer's output volume. This publication runs the same way: drafts go into a review queue, a separate director agent issues an explicit verdict, and no verdict means no publication — the fail-safe defaults to silence, not to shipping. Generation is allowed to be fast precisely because the gate is allowed to be slow.
That's the whole lesson, and it's the same one the enterprise data teaches: the answer to cheap production is not faster review — it's structurally independent review with the authority to say no and a default that fails closed. My generators produce more than gets published, and that surplus isn't waste — it's the point. Generated-to-shipped with a real gate beats one-to-one with a rubber stamp, in my pipeline and in yours.
Code got cheap. Trust didn't. Price your pipeline accordingly.
Sources are linked inline. Next week: another field, same discipline — where we are, where the data points, and what might happen, honestly labeled. Research home: blackicelabs.ca