The Review Gap Is Now Measurable: 22,000 Developers, 861% Churn

Faros AI has published two years of systems telemetry from 22,000 developers across 4,000 teams, and the numbers end the anecdote era. Incidents per PR are up 243%. Code churn , lines rewritten within two weeks of being written , is up 861%. Merges with zero review are up 31.3%. Task throughput is up 34% and epics per developer up 66%. The productivity gains are real. So is everything accumulating downstream of them.

What the telemetry actually measured#

The Faros AI Engineering Report 2026, titled "The Acceleration Whiplash," draws from version control, CI/CD, work management, and incident data across those 22,000 developers. It is longitudinal, which makes it rare. Most AI productivity studies are point-in-time surveys of perception; this one compares system behavior from two years of recorded events.

The throughput side looks good by every conventional metric. But the quality side tells a different story. Bugs per developer rose 54%. Median time in code review rose 441.5%. Daily PR contexts per developer, the number of distinct pull requests one person has to hold in their head simultaneously, rose 67.4%. Work restarts are up 13.8%. Tasks sitting idle for seven or more days are up 26%.

These are median numbers across the dataset, not outlier teams.

No-review merges are a capacity problem, not a policy problem#

The 31.3% rise in zero-review merges is the number most likely to be misread. Teams did not decide to skip review. No policy changed. Reviewers stopped being able to keep pace with incoming volume, and unreviewed merges became the statistical residue of that failure.

LinearB's 2026 Software Engineering Benchmarks Report, built from 8.1 million pull requests across 4,800 organizations, gives the mechanism. At the 75th percentile, AI-assisted PRs exceed 400 lines. Unassisted PRs at the same percentile run 157 lines. A reviewer picking up a 400-line PR is doing more than twice the cognitive work, and the data shows they take more than four times as long to start: 16-plus hours to first reviewer pickup on AI-assisted work, versus roughly 200 minutes on human-authored work.

A 30-day merge rate of 32.7% on AI-assisted PRs, against 84.5% on unassisted work, follows directly. The PRs do not get reviewed; they go stale. The queue fills faster than it clears. The ratio of PRs loaded to PRs merged per week, held steady near one, is the diagnostic that shows which regime a team is actually in before it shows up anywhere else.

PR size compounds the debt#

There is a compounding effect that the headline numbers obscure. GitClear's analysis of 623 million code changes found that code duplication rose 81% and refactoring fell 70% over the same period. LinearB's data puts the refactoring rate on AI-assisted PRs near zero, versus roughly 37% on unassisted work at the same percentile.

The code that does merge is going in close to first draft. When it is also 400-plus lines, and when reviewers are operating at 441% of their prior review time just to get through the queue, the probability that logic errors, boundary condition failures, or permission-check gaps survive review approaches certainty. The 861% churn figure is what that looks like two weeks later: developers returning to rewrite code that was accepted quickly the first time.

New Relic's 2026 State of AI Coding report surveyed 200 technology leaders and found 94% rated AI-generated code as higher quality than human-authored code at the point of review. The same leaders reported 78% of their organizations saw production incidents climb. The confidence and the incidents coexist because AI-generated code is idiomatic, well-named, and syntactically clean , the surface is polished even when the underlying logic is wrong. FlowVerify calls this "hallucinated correctness": code that is confidently, plausibly incorrect in a way a normal read-through will not catch.

What the incident curve tells defenders#

A 243% rise in the incidents-to-PR ratio does not distribute evenly. The burden concentrates on senior engineers, who are the ones capable of catching what the surface polish hides. Faros estimates that catching AI errors requires reconstructing intent , understanding what the code was supposed to do, not just what it does , which is high-intensity work that junior reviewers cannot reliably perform. As that work consumes senior engineers' hours, the architecture, mentorship, and technical strategy that compound across a team give way to incident response.

The organizational feedback loop is slow. Executives see throughput rise, push for more AI adoption, and the incident curve accelerates again. The delay between code authoring and incident is long enough that the causal connection stays invisible in most retrospectives.

Defenders need a way to intercept failures before they reach production, and before they reach a human reviewer operating at capacity. The FlowVerify analysis is specific: CI is the right interception point. Guardrails that catch test deletion, threshold weakening, linting bypass, and untrusted-input injection into prompts , structural signals that show up in the diff, not in post-deployment telemetry , need to run before the code ever enters the review queue.

What autonomous review changes#

The Faros data frames this as an authoring problem: the fix belongs upstream at code generation, not at review. That framing is partially right. Equipping generation with richer context and tighter constraints reduces the defect rate. But it does not eliminate it, and it does not address the queue that already exists.

The other structural change is review capacity itself. Human review capacity is inelastic. It does not scale with agent output, and adding reviewers helps only until the next throughput mandate reopens the same gap. Autonomous review , systems that read code with full codebase context, apply checks across security, code quality, reliability, and API behavior, and run verification before flagging anything , changes the arithmetic. The capacity constraint is no longer human attention hours.

Hyrax reads the entire repository before evaluating a change, runs 13 verification steps on any candidate fix, and submits a PR for human merge. The six agent domains it covers , security, code quality, reliability, API and data, ops, and UX , correspond directly to the failure categories Faros observed accumulating under high AI adoption. The human still decides what ships. The verification happens before that decision, not after.

The two metrics worth tracking#

Pull requests merged and lines shipped are the wrong numbers once agents author most of the code. They measure how fast the queue fills, not how fast it clears.

Review-lead time, the interval from "ready for review" to merged, tells whether the queue is growing. Revert and rollback rate on agent-touched PRs tells whether what clears review is safe. If review-lead time climbs while revert rate holds steady, the problem is process. If revert rate climbs too, process changes will not fix it , the guardrail needs to move earlier, into CI, before the diff reaches anyone. The Faros dataset now provides a two-year baseline for both metrics at scale. Every team that has not measured its own equivalents is operating on assumption.

Hyrax is live at hyrax.dev.