AI Agents: PRs Up 98%, But Review Time Slips 91%. Where the Queue Really Went

Sergey Proshchaev, Tech Lead and head of Java | Kotlin development in FinTech & E-commerce, analyzed three major studies from 2025–2026 and found a consistent pattern: AI sped up writing code, but slowed down shipping it to production.

The basic observation is simple. A developer with an AI agent assembles in an evening a feature that used to take a week. They open a 1,500-line pull request. Then the MR sits in review for three days (with four more just like it waiting in the queue), gets one comment about a variable name, moves on to QA, and gets stuck there too. A week later, something nobody really read surfaces in production.

AI accelerated generation faster than the team can review, integrate, and ship. The bottleneck doesn't disappear — it just moves further down the pipeline.

Three studies, one conclusion: generating is cheap, verifying isn't

Faros AI: The AI Productivity Paradox (July 2025) — data from 10,000 developers across 1,255 teams. The headline looks like a win: developers actively using AI assistants close 21% more tickets and merge 98% more pull requests. But one detail changes the picture: review time is up 91%, average PR size up 154%, and bugs per developer up 9%. At the company level, researchers found no meaningful correlation with outcomes.

Faros AI: The Speed Trap (September 18, 2026) — 22,000 developers across 4,000 teams over 12 months. Time spent in QA grew by 300.6% — the sharpest decline among all flow metrics. Average PR size is 71.8% higher, and monthly incidents are up 125.4%. One alarming metric: PRs merged without review jumped from 31.3% to 76.3%.

CircleCI: Software Delivery Report 2026 — 28.7 million CI runs from September 2025. Average daily run count grew 59% year over year, but at the median team, feature-branch activity rose only 15% while main-branch activity fell 7%. The main-branch build success rate dropped to 70.8% (a five-year low), and the time to recover to a green build was 72 minutes. Fewer than 5% of teams managed to grow both development output and main-branch throughput simultaneously.

DORA 2025: in 2024, a 25% rise in AI usage came with a 1.5% drop in delivery speed and a 7.2% drop in stability. In 2025, the picture shifted: AI's correlation with delivery speed and product outcomes turned positive, but its correlation with stability stayed negative. The report's authors call AI a "mirror and a multiplier" — it accelerates development, but without strong test automation, growth in change volume turns into instability.

Where the queue actually jammed

Pull requests move in parallel through generation and human review, then wait for QA, integration, and rollout. The agent speeds up generation (the green block). Throughput for everything else doesn't scale to match.

If changes arrive faster than the system can process them, the queue grows, along with work-in-progress and delivery time. Review, QA, and integration throughput scale far worse than code-generation speed does.

Observation 1: MRs are growing faster than review throughput. The agent doesn't treat diff size as an engineering goal in its own right. Ask for a feature, and you get the whole feature plus a "while I'm at it" refactor of neighboring modules. On one project, a simple task to add a field to a service response ballooned to several hundred lines (the ticket called for 20). SmartBear recommends no more than 200–400 lines per review, a pace of up to 500 lines per hour, and sessions of about an hour — under those conditions, reviewers catch 70–90% of defects.

Observation 2: long review wait times create a queue problem, not a slow-reviewer problem. The incoming flow of changes simply exceeds review capacity. Google's own code review practices document sets a limit: first response to a review request within one business day, maximum. While an MR waits for review, the author doesn't sit idle — they open the next one, then another. At Faros, in 2025, developers with high AI usage touched 47% more PRs per day. One real-world example: a developer with seven open MRs, none merged for over a week. Capping each person to two open MRs per week forced people to start helping reviewers — and the queue started shrinking faster.

Observation 3: review degrades into a rubber stamp or an interrogation. Under volume pressure, teams fall into one of two extremes: approve without reading ("the agent wrote it, tests are green") or demand an explanation for every line because they don't trust generated code. The rubber stamp lets errors through because there was no real check. The interrogation lets errors through too, because attention goes to minutiae instead of the real question — "are we even building the right thing?" The better split: automation checks format, known vulnerabilities, and standard patterns. Humans handle questions of logic and context.

Observation 4: AI adds review throughput, but doesn't replace accountability. Automated review already helps — the first review arrives faster, and the share of failed changes is lower. But trust remains low: in the 2025 DORA report, only 24% expressed high trust, while 30% trust little or not at all. If the agent wrote the code, reviewed it, and a human just clicked approve, no independent check actually happened. The fix is risk-based tiering: mechanical changes go fully to automation, while critical ones (authorization, payments, security) get reinforced review with two independent reviewers.