Fast Coding Tools Are Creating a Bottleneck at Code Review
Faster AI coding tools flooded the kitchen — now every plate is stacking up at the pass. Your senior engineers aren't the bottleneck; your process is.
The Kitchen Got Faster, The Pass Did Not
Throughput metrics are up, delivery is not obviously faster, and your senior engineers are more tired than they were last year. That is a queueing problem, and it has an upstream fix.
In a professional kitchen, every plate that leaves goes through the pass. It is a physical station, usually a long heated shelf between the line and the floor, and the expediter standing at it checks every dish against the ticket before it moves. The ticket is the specification: table number, order, modifications, timing. The expediter's job is not to cook anything. It is to hold the intent of the order and confirm that the plate matches it before the server picks it up.
You can hire more cooks, add stations, tighten the prep, and run the line faster. None of it changes what leaves the kitchen if the pass cannot clear it. The plates stack up, the tickets pile on the rail, and the expediter absorbs all the pressure that the line's increased speed created. This is not a cooking problem. It is a queueing problem, and queueing problems do not respond to adding capacity at the wrong station.
Your throughput numbers went up. Your delivery did not get obviously faster, and your senior engineers are more tired than they were last year. If your instinct is that this means adoption is incomplete, or the tooling is wrong, or the team is not using AI the right way, those are reasonable instincts and they are probably not the root cause. The generation capacity increased. The pass did not.
Queueing problems have known behavior: when one station gets faster and the downstream station does not, work in progress accumulates at the boundary. The boundary for an engineering organization is code review, and two years of production telemetry now show exactly what you would predict.
What the Data Actually Shows
The Faros AI Engineering Impact Report 2026 draws on two years of telemetry from 22,000 developers and more than 4,000 teams, comparing each organization's periods of lowest and highest AI adoption across the same systems: task management, CI/CD pipelines, version control, incident management. Telemetry is not a survey. It does not capture what people say about their work; it captures what the systems record about it.
The throughput gains are real. Task completion rose 34%. Epics completed per developer rose 66%. These numbers are not artifacts of how questions were framed. The work got done at a higher rate.
The invoice arrived downstream. Median PR review time rose 441.5%. Incidents per pull request rose 242.7%. Code churn rose 861%. Pull requests merged without any review, human or agentic, rose 31.3%. Faros' assessment is that the unreviewed merges do not reflect a deliberate choice to skip oversight. The more likely explanation is that reviewers could not keep pace and the work moved anyway.
The constraint migrated, and the systems recorded exactly where it went.
LinearB's 2026 Software Engineering Benchmarks Report adds a second independent data point from a different methodology: benchmark analysis across 8.1 million pull requests from 4,800 organizations in 42 countries. Agentic AI pull requests are approximately 2.6 times larger than unassisted human pull requests. They wait 5.25 times longer before a reviewer picks them up. Their merge rate is 32.7%, against 84.5% for unassisted code. In the 2026 edition, AI origin of the pull request is now the single most predictive variable for pickup time, more predictive than team size, tech stack, or deployment frequency.
Two independent datasets, different methodologies, same result: the bottleneck moved to review.
The picture requires one important qualification. A METR randomized controlled trial run with 16 experienced developers on mature, high-complexity codebases using early-2025 tools found those developers completed tasks 19% slower with AI assistance than without it. That finding is real and worth sitting with, and it carries a scope limit METR itself marks as essential. It does not apply to junior developers, greenfield projects, or later tool generations. Research cited in a 2026 meta-analysis of AI coding efficiency, drawing on Stanford work, shows gains of 30 to 40 percent on low-complexity greenfield tasks, falling to near zero on high-complexity legacy work. The aggregate number hides a wide distribution, and the wide distribution matters when you are deciding where to apply the tools.
What the METR finding does confirm, with unusual methodological rigor, is that self-reported velocity is an unreliable signal. Developers predicted a 24% speedup before the tasks. After completing them with AI, they reported feeling 20% faster. The measured result was a 19% slowdown. The perception gap is the most durable finding in the study, and it applies regardless of which direction the actual number moves: people are poor estimators of their own throughput, which is why the measurement matters.
Organizations that do not measure review latency, incident density, and churn rate alongside task completion are looking at a number that cannot tell them what is happening.
Why Review Got Harder, Not Just Longer
Review time did not increase only because there is more code to review. It increased because the reviewer's question changed. Reviewing a colleague's pull request, you are largely checking work whose intent you already share, produced by someone who was in the same conversation you were. Reviewing generated code, you are reconstructing intent from the artifact, which is a harder cognitive task and a slower one.
This is why larger pull requests are disproportionately worse rather than proportionally worse. A reviewer holds a model of what the change is supposed to do, and that model degrades as the change grows. Past a certain size the review stops being verification and becomes a plausibility check, which is the exact failure mode that lets a confident and wrong change through.
The reviewer's real question is not "does this code work." It is "does this do what was actually asked." When the specification was a sentence in a ticket, that question has no reliable answer, and the reviewer supplies the missing intent from memory.
The specific difficulty with generated code is that it is frequently locally correct and globally wrong. The function does what a reasonable reading of the prompt would produce. The function does not do what the system actually needed, because the prompt did not capture that. A human reviewer catching a broken function has a clear signal. A reviewer catching a correct function in the wrong place, solving the wrong version of the problem, has to hold the full context of the intent and compare it against what was built, without any indication that something is wrong. The code compiles. The tests pass. The diff is clean. The change does something adjacent to what was asked, and a plausibility check does not catch it.
Nobody has ever read a specification document. People read the test that failed.
A substantial portion of developers, when surveyed by LinearB and in corroborating industry research, report that reviewing AI-generated code takes meaningfully more effort than reviewing code written by a colleague. That result is not surprising once you understand the mechanism. It is worth stating plainly because the instinctive response to a review slowdown is to add reviewers or increase review frequency, and neither of those addresses the cognitive cost per review. The effort is upstream of the hours.
The Fix Is Upstream
Widening the pass does not work for long. You can add reviewers, cap pull request size, and add automated checks, and all three help, but all three are capacity responses to a demand problem. The generation side will keep getting faster, and any fix that scales with reviewer headcount loses that race by construction.
The durable move is to make the intent machine-checkable before generation starts. That means a decision rule stated precisely enough to be tested, a tool or interface contract written before the logic that uses it, and an evaluation harness that fails loudly when behavior drifts from what was specified. Those three artifacts do the reviewer's hardest work in advance, because they answer "does this do what was asked" without requiring a human to hold the intent in their head.
This is a real shift in where engineering effort goes, and it is not free. It moves senior time from the end of the process to the beginning, which is a harder sell than it sounds, because effort at the end is visible and effort at the beginning looks like a delay.
What this looks like concretely: the decision rule is documented as an acceptance condition before any implementation begins. Not in prose that describes the intent, but in a form that can be asserted. The interface contract is written before the function that satisfies it, and it specifies behavior at the boundary, not inside it. The evaluation harness is treated as a maintained asset with the same standing as the application code, not as a disposable artifact that served its purpose at launch. This is described in more detail in work on building verifiable evaluation frameworks; the key point is that an evaluation harness is the executable form of a specification and carries the same maintenance obligation.
The cultural reference completes here: a precise ticket makes the pass fast. The expediter's job is checking the plate against the order, and that check is only as fast as the order is clear. If the ticket says "fish," the reviewer is doing interpretive work under pressure. If the ticket says what the table ordered, with the modification noted, the check is binary. Specification quality is not a documentation practice. It is a throughput lever.
On the first agent build I ran with a locked decision rule from day one, before any implementation started, the downstream reviews narrowed to a specific question: does this behavior match the contract? That question has an answer. The reviews that had previously consumed two hours were thirty minutes. The constraint was not the reviewer's attention. It was the absence of a checkable statement of intent.
This Has Been Tried Before
A senior engineer reading this has seen it before and has a fair objection. Waterfall requirements, formal methods, model driven development, and behavior driven development all promised that precision up front would eliminate downstream rework. Each produced a large volume of documents that nobody read, and each eventually lost to the observation that requirements are frequently not knowable until something exists to react to.
That history is real and I am not going to pretend this is different in kind. It is different in one specific way that matters. Every previous specification movement produced artifacts meant for humans to read, and human-readable artifacts decay silently the moment the system moves past them. A test, a contract, and an evaluation harness do not decay silently. They fail, in a pipeline, with a name attached.
That does not make the requirements knowable any earlier than they ever were. It makes the part you do know self-enforcing, and it makes the moment you were wrong visible immediately rather than at review time.
Executable specifications are compatible with discovering requirements late. They are cheap to change. When the requirement changes, the test fails, and the failure names exactly what broke. That is a fundamentally different feedback mechanism than a requirements document that is correct on the day it is written and quietly wrong for the eighteen months that follow. The objection from history is about human-readable artifacts. The answer is an artifact that reads itself and reports when it is no longer true. On building systems where that distinction is the difference between a detectable drift and a production incident, the argument for verification before generation rather than after it is not a workflow preference; it is an architectural one.
Iteration and precision are not in opposition when the precision is executable. You can discover that your requirement was wrong on day eight, change the contract, and have the pipeline tell you exactly what the change broke. That is faster than discovering it in review, which is faster than discovering it after deployment.
The Constraint Has Moved
Measure review latency alongside throughput this quarter. An organization tracking only task completion and PRs merged is watching the kitchen's output and not watching the pass, which means it cannot see where the time is going or why the senior engineers are tired.
The question the data has already answered is where the bottleneck is. Review capacity is the binding limit in AI-adopting engineering organizations, and the fix is not more review capacity: it is reducing the cognitive cost of each review by making the intent checkable before the code is written. The industry spent two years accelerating generation. The organizations that close the gap in the next two years will be the ones whose specifications were precise enough that review became confirmation rather than reconstruction.
The ticket is where the speed comes from.