Why Code Review Throughput Breaks Under Agentic Pipelines

What the throughput data shows when AI volume meets human review capacity

Sonar's survey of more than 1,100 developers found that AI now writes 42% of all committed code, with that share expected to climb to 65% by 2027. Agentic pipelines are breaking code review for a simple reason: code generation has pulled away from the human bandwidth available to check it. Nobody typed faster. A generation function scaled, and the verification function sitting right next to it did not, and structurally cannot, scale the same way.

Adoption moved fast. Sonar found that of developers who have tried AI coding tools, 72% now use them every day, up from a population that was mostly still experimenting six months earlier. Platform data tracks the same curve: monthly merged pull requests rose from a 2024 average of 35 million to 43.2 million in 2025, and industry data projects a jump from roughly 1 billion pull requests a year to 14 billion in 2026.

Faros AI's 2025 telemetry analysis, covering more than 10,000 developers across 1,255 teams, captures the resulting paradox in one dataset. Developers using AI completed 21% more tasks and merged 98% more pull requests than their non-AI counterparts. PR review time went up 91% over the same period. Output nearly doubled, and the time needed to check that output rose almost as fast behind it.

The rest of Faros' data explains why review time couldn't hold steady. PR size grew 154%. Bug counts rose 9%. Organization-wide DORA metrics stayed flat, meaning all that extra volume produced no net gain in delivery performance. More code moved through the pipeline. The pipeline itself never got faster at turning that code into something safely shipped.

LinearB's 2026 benchmarks, built from more than 8.1 million pull requests across 4,800-plus organizations, sharpen the picture. Agentic AI PRs sit in the queue substantially longer before anyone picks them up, and they close worse too: only 79% merge within 30 days, against 92% for human-only PRs. CircleCI's 2026 data shows the split: feature branch throughput rose 59% year over year, while main branch throughput for the median team fell. Code gets written faster than anyone can decide whether it's safe to merge, and that gap is the actual bottleneck. Not reviewer speed.

Reviewers didn't get slower. The unit of work landing in front of them got bigger, more complex, and more frequent, all at once, and those three forces compound rather than simply stack on top of each other.

The different kind of review burden AI-generated code creates compared with human-written code

CodeRabbit's analysis of 470 open-source pull requests found that AI-generated PRs carry about 1.7 times as many issues as human-written ones. The breakdown by category tells a reviewer where to spend limited attention. Performance problems occurred nearly 8 times as often. Readability issues ran more than 3 times as frequent. Concurrency bugs appeared at 2.29 times the rate of human-written code, and security vulnerabilities appeared at 1.5 to 2 times the rate. Performance and concurrency problems rarely appear on a quick read of the diff, which makes them exactly the bugs most likely to survive a rushed review.

Trust hasn't caught up with volume. Stack Overflow's 2025 Developer Survey put trust in AI accuracy at just 29%, down from prior years, and 66% of developers said they now spend more time fixing "almost-right" AI output than they expected to save by using the tool. Sonar's own survey found that 96% of developers don't fully trust that AI-generated code is functionally correct, and only 48% say they always check their AI-assisted code before committing it. AWS CTO Werner Vogels calls that gap verification debt, and the name fits: debt that piles up quietly until a release forces the payment due.

The trust numbers trace back to something structural. When an agent hands over a finished diff, the reviewer never watched it get built. There's no half-finished commit history to lean on, no implementation journey revealing what the author was actually thinking through along the way. A reviewer has to reconstruct intent from a ticket, a PR description, and the code itself, and that reconstruction costs real cognitive work, more per line than reviewing something a colleague already talked through in standup last week.

This dynamic has a name that has emerged in engineering discussions: vibe merging. A machine-generated PR lands in front of an already-overloaded reviewer. The diff is large, the code reads plausibly, nothing jumps out on a skim, and the reviewer approves it. Review time rose 91% over the same measured period, while approval quality moves the other direction. Review burden was never simply proportional to lines of code. It scales with issue density, with how much intent has to be guessed at, and with diff complexity, and all three run higher for agentic output than for anything a person wrote by hand.

The self-review problem and the limits of automated checks

The obvious answer to machine-scale volume is machine-scale review tooling. Fine, but treat that as a floor. An agent grading its own homework is the wrong architecture no matter how good the grading rubric gets, and no amount of tuning changes that.

The mechanism is structural: a model cannot objectively evaluate output it produced itself, because the same assumptions, the same training biases, and the same reasoning shortcuts that shaped the original code shape the review of that code too. Instead of independent verification, what comes out the other end is compounding error dressed up as confidence. Futurum's AI Platforms Decision Maker Survey (n=820) found that 55.4% of enterprise decision-makers already name "AI agent reliability and hallucination management in production" as a top challenge. It's already on their dashboards, not sitting in some research paper as a hypothetical.

Automated tools hit a ceiling on their own, self-review aside. They catch syntax errors, known vulnerability signatures, style violations. They can't verify intent, and they can't check code against a spec that exists only in someone's head. When requirements live as tribal knowledge instead of written documentation, no static analyzer closes that gap, no matter how sharp its pattern matching gets.

Sonar's survey found that 35% of developers access AI coding tools through personal accounts rather than company-sanctioned ones. Code that enters a pipeline that way skips governance, both automated and human, because nobody sanctioned the tool that wrote it. Automation belongs on an independent layer, architecturally separate from whatever agent produced the code, rather than running as a self-check the generating tool performs on its own output.

The structural changes in the SDLC when code generation decouples from verification

DORA's 2025 research, drawn from roughly 5,000 survey responses, finds that AI amplifies the strength or weakness of a team's existing engineering practices rather than fixing them. Teams with clear ownership, strong testing habits, and fast feedback loops give AI a good environment to be productive in. Teams with fuzzy priorities, fragmented ownership, and rushed reviews give AI more surface area to scale inconsistency instead. A review process that was already overloaded before agents arrived just gets a longer queue behind it. Standards that were already unclear get reflected back at a much larger scale, in code, at commit volume.

The deeper shift is a change in the job itself. Engineers are moving from writing implementations toward specifying intent, verifying outcomes, and orchestrating agents that produce the first draft. Forrester Principal Analyst Devin Dickerson frames the resulting unevenness well: "You might have a few developers running sophisticated agent workflows while others on the same team don't see the value yet. AI maturity isn't linear: it's fragmented." That fragmentation is a risk on its own. A standard applied only when convenient functions as a suggestion, not a standard. It's a suggestion some people happen to follow.

Documentation moves from nice-to-have to load-bearing infrastructure, because agents depend on it directly rather than filling gaps with judgment the way a human engineer would. An agent can't follow business logic that was never written down, and it can't call an API correctly if that API's behavior lives only in one engineer's memory. Implicit knowledge a human team tolerated for years turns into a defect surface an agent hits constantly the moment it starts generating against it.

Human-in-the-loop governance needs deliberate design now, before the first incident forces a policy into existence. Teams need explicit answers to where an agent can act alone, where it can only recommend, where a human sign-off is mandatory, and who owns the outcome when something breaks in production. Two metrics carry more weight here than the traditional ones: Mean Time to Verification, tracking how fast a human can safely review and merge an AI-generated PR, and Change Failure Rate tracked specifically for AI-generated code as its own category, separate from the aggregate number that hides it inside the average.

The acute failure point in mobile app pipelines

Mobile pipelines inherit every problem above, then add platform-specific ones that get caught later, when they cost more to fix.

Mobile apps have no DOM equivalent, so a selector-based test suite breaks every time an agent touches the UI. Behavior determines correctness far more than coverage percentage here, because an agent can write a test that passes while checking the wrong thing entirely, chasing a green checkmark instead of writing a test that verifies actual correctness. Concurrency bugs are among the sharpest versions of this risk: they are difficult to catch without real, layered device runs, and when PR queues are already stacked, teams skip those runs to keep the queue moving.

Device fragmentation compounds it further. Android alone spans a large number of device variants across manufacturers, Samsung, Xiaomi, Huawei, OPPO among them, so a UI change that passes clean on a simulator can still fail on one specific real-hardware combination the agent had no reason to consider.

The App Store adds a hard external gate that server-side pipelines never face. Apple's App Store review process rejects a meaningful share of submissions each year. Privacy, specifically around AI data disclosure, has become a notable and growing rejection risk. Under Apple's App Review Guidelines, apps calling external AI services have to clearly disclose where personal data goes and get explicit permission before sharing it. AI-generated code that quietly calls a third-party AI API without that disclosure is a direct rejection risk, and most teams aren't checking for it systematically. Metadata carries a quieter version of the same risk: a support URL breaks, a privacy policy goes stale, or an App Privacy label stops matching what the binary actually does, because an agent adds a feature or bumps a dependency and nobody updates the metadata to match. A SmartBear survey of software experts found that 70% believe application quality has already declined as AI speeds up development, and 60% reported quality problems specifically because development outpaced testing. Mobile is where rising throughput meets a reviewer who isn't on the payroll and can't be argued with, which makes the cost of ungoverned agentic output concrete in a way it rarely is on the server side.

What a verification architecture that can keep pace with agent speed requires

The fix has to match the shape of the problem. If the failure is structural: volume outpacing human capacity, intent gaps, issue density compounding, governance scattered across a fragmented team, then the answer is a different architecture entirely, not faster reviewers, more of them, or an agent checking its own homework more carefully. It's a different architecture.

Four things have to hold true of whatever replaces the current setup. A core principle for enterprise-grade agentic pipelines is that verification has to run on a layer architecturally separate from the agent doing the generating, with no stake in whether its own output gets approved. Quality standards need to get written down once, in one place, approved by people who understand the product, then applied the same way across every build and every PR, instead of getting re-litigated informally in each review thread. Coverage has to span product intent, design consistency, security, performance, accessibility, and store compliance together, because agentic output can regress any of these at once and no single tool or single role watches all of them at the same time. And humans keep the authority to override and approve, even as agents handle the mechanical verification work underneath them.

Gating at the PR level is the floor, not the ceiling. DORA's 2025 research supports gating regression checks at the pull-request stage, with unit and integration tests blocking the merge and critical flows tested on every single PR without exception. LinearB's data points to a faster, tactical win inside that structure: AI-assisted code review at the PR level measurably improves review outcomes. Real, but it functions as a component bolted onto an architecture, and that architecture has to be built before the component can work.

None of this is a tool swap. As agents take over more of the writing, verification becomes the point where the whole system either holds or breaks under its own weight. Hiring more reviewers alone cannot scale at the same rate as agent output, full stop. The only thing that scales at the same rate as the agents is an equally capable, independent layer checking every PR on the other side of the queue.