Review Is Infrastructure. Your AI Rollout Forgot to Build It.

AI adoption doubled our code output. Nobody budgeted for the reading. Telemetry from 22,000 developers shows what that costs, and what treating review as infrastructure actually means.

---

The AI tools have been mandated long enough that nobody on my team calls them new anymore. They are simply how work happens now: describe, generate, adjust, ship. The rollout came from the top, the adoption curve did what adoption curves do, and at some point the whole thing stopped being an experiment and became furniture.

Last month I finally sat down and asked what the tools actually changed. Not in the demos. Not in the vendor slides. In my calendar.

Here is what I found. My days used to have building in them. Architecture sessions, actual code, the occasional deep dive into a problem nobody else had time for. Now my days are review, verify, review, verify. Not because anyone assigned me more review. Nobody assigned the reading to anyone. That is exactly the point. The tools were rolled out with training sessions, license budgets, and adoption dashboards. The reading was rolled out to no one. It just landed on whoever holds the quality bar.

And the units of reading got heavier while nobody was looking. A pull request used to be twenty, maybe thirty files. Now I regularly open ones twice that size. Clean, consistent, fully generated. And still wrong in ways that take longer to find than the code took to produce. The code arrives faster than ever, looking finished, and every one of those finished-looking files is a promise someone has to check.

For a while I filed this under "temporary". The awkward middle phase of a transition that would fix itself. Then I found the industry numbers, and I stopped thinking it was a me-problem. Or a temporary one.

The bill arrived, and it is itemized

Faros AI has been collecting telemetry on exactly this question. Not surveys, not opinions, but measured data from real engineering organizations. Two reports, two years, one pattern that keeps getting stronger.

The 2025 report analyzed telemetry from 10,000 developers across 1,255 teams. The headline finding was a paradox: teams with high AI adoption merged 98% more pull requests and completed more tasks, while their delivery metrics at the company level did not move. Deployment frequency, lead time, change failure rate: flat. So where did the gains go? The report shows the leak. Review time up 91%. Average PR size up 154%. The productivity was real at the individual level, and it got absorbed at the system level, mostly by a review process that was never scaled to receive it.

You could read the 2025 data in a positive way. Transition costs. Teams still learning. Give it a year.

The 2026 edition gave it a year, doubled the sample to 22,000 developers across more than 4,000 teams, and the picture got sharper in both directions at once. The throughput gains finally became visible at the company level: epics completed per developer up 66%, task throughput up 34%. AI is genuinely moving roadmaps now, not just individual task counts. That part of the promise landed.

So did the bill. Median time in PR review: up 441%. Five times longer than before, compared to "only" 91% the year before. Bugs per developer: up 54%. Production incidents per pull request: roughly tripled. And the number I cannot stop thinking about: 31% more pull requests now merge with no review at all.

Read that last one again. The system did not slow down to match its verification capacity. It did what overloaded systems always do. It started skipping the step. The unread pile is not a metaphor. They measured it.

One more data point, from a completely different tool: LinearB's 2026 benchmarks found that AI-generated PRs wait 4.6x longer before a reviewer even opens them. Once opened, they are reviewed faster, but the waiting time dominates. Different instrument, same shape: generation sprints, verification queues.

Three sources, one conclusion. This is not a discipline problem, and it is not a temporary bump. It is a structural imbalance, and it is getting worse.

Why the cost concentrated instead of spreading

Here is the mechanism, and it is simple enough to be uncomfortable.

Generating code became cheap and distributed. Every developer with a license has, in practice, a team of tireless typists. Production capacity scales with the number of seats you buy. A purchase order can fix it.

Verifying code stayed expensive and concentrated. Checking that code is right costs exactly what it always did: attention, context, judgment. And that cost lives in a small number of people. The ones who hold the architecture in their heads, who know the history of the codebase, who are trusted with the merge button. Reading capacity scales with the number of senior engineers you have. No purchase order fixes that.

So when a rollout multiplies production without touching verification, the difference does not disappear, and it does not spread out. It concentrates in the most expensive people in the organization. The exact people the rollout was supposed to multiply are the ones being consumed. Every reasonable individual decision (use the tools, generate more, ship faster) adds up to a system where the scarcest resource carries all the new load.

We bought a faster printer and hired no one to read.

I wrote earlier this year about the individual layer of this problem: why our brains do not read generated code, why smooth output looks reviewed when it is not, why "looks done" gets treated as "checked". That post was about psychology. This one is about economics. Even a team of perfectly disciplined readers hits a wall when the reading load grows five times and the reading capacity does not move. You cannot fix a capacity problem with willpower. At some point the only honest way to describe the situation is this: verification became a cost that nobody put in the AI business case. The tools are in the budget. The reading is not anywhere.

What "infrastructure" actually means here

Infrastructure is the stuff you design, measure, budget, and assign an owner to, before it gets overloaded. Nobody treats CI as a heroic act performed by whoever feels responsible that day. Nobody handles production monitoring by hoping a senior engineer notices. Those systems have capacity plans, dashboards, and someone whose job is to keep them healthy.

Review, in most organizations I have seen, has none of that. It is treated as invisible work, done between "real" tasks, unmeasured, unplanned, and staffed by guilt. That model was already weak when humans wrote all the code. Under AI-scale generation it is not a model at all. It is a queue with no operator.

Treating review as infrastructure starts with measuring it like infrastructure. Four numbers a team lead can start tracking this week, without buying anything:

Generated-to-verified ratio. You almost certainly know how many lines your tools produce. The vendor dashboard is proud of it. Do you know how many of those lines a human actually read before merge? If you can only measure one side of that ratio, you are not measuring productivity. You are measuring how fast the unread pile grows.

Time to first review. Not total review time. Queue time. How long does a PR sit before anyone opens it? This is where the LinearB 4.6x lives, and it is the earliest warning light. If queue time grows while review time stays the same, your readers are not slow. They are full.

Percentage merged without review. The skipped-step metric. Faros found it rising 31% under high adoption. If yours is rising, your process did not get leaner. It got bypassed. This number should be boring. The moment it becomes interesting, it is an incident.

Reviewer concentration. What share of reviews lands on your top two reviewers? If it is most of them, you do not have a review process. You have two people holding a dam. This is also your burnout early-warning system, because dams do not file complaints before they break.

None of these require new tooling. They require one decision: reading is work. Work you can plan, measure, and own. Not a tax that responsible people pay in silence.

The reading layer: how I structure mine

Measurement tells you the pile is growing. Then you need machinery that shrinks it. And this is where most teams reach for the obvious move: "let AI review the AI."

By itself, that is the same trap in a different costume. A single general-purpose reviewer bot produces smooth, confident, plausible review comments. And smooth, confident, plausible output is exactly what caused the verification problem in the first place. You have added a second layer of finished-looking text that someone still has to judge. One reader of unknown reliability checking one writer of unknown reliability is not a quality system. It is an echo.

What has actually worked in my setup is layers, each with a narrow job. Automated passes run before the human, and each one checks one specific thing. Not "is this good code", but concrete questions with clear yes-or-no answers and a small scope. Narrow checks fail loudly and honestly, in a way a general-purpose reviewer never does. The human stays where humans cannot be replaced: business logic, architectural fit, the judgment call. And the human owns the merge, always. The automation's job is to make sure that when I open the PR, I spend my attention on the questions that need me, not on the mechanical layer a machine already cleared. It shrinks the pile. It does not replace the reader.

I have written up the full implementation separately: the multi-agent pipeline that runs these passes in CI, and the model routing that keeps its cost under control. So I will not rebuild it here. The specific agents matter less than the principle: automation before the human, narrow over general, and the merge belongs to a person. Any team can build a version of this with the tools they already have. The pipeline is a detail. The reading layer is the point.

Who wins this phase

The last few years rewarded teams that adopted generation fastest. That race is over. Generation is table stakes now, mandated from above, priced per seat. The next phase rewards something else entirely: verification throughput. The ceiling on how fast you can safely ship is no longer how fast you can produce code. It is how fast you can know the code is right.

The organizations that figure this out will keep the 66%. The real, measurable throughput gains, without paying for them in tripled incidents and unread merges. Everyone else will keep celebrating the printer.

The teams that win will not be the ones with the fastest printer.

They will be the ones that staffed the reading room.