AI can fill a pull request queue faster than reviewers can clear it. That doesn’t mean the software delivery system got faster. Engineering leaders need to see where work waits after a pull request is ready, including review, validation, merge, and deployment.
Key Takeaways
- LinearB found that agentic AI PRs waited 5.3x longer for reviewer pickup than unassisted PRs at the 75th percentile, pointing to a potential constraint after code generation.
- CircleCI found that the median team increased feature-branch throughput by 15% while main-branch throughput fell 7%, showing that more development activity doesn’t automatically translate into more production throughput.
- In one Larridin customer’s pipeline, PR-ready time was 0 seconds, while review took 1 hour 2 minutes and merge took 57 minutes. Stage-level visibility showed where measured time was accumulating.
Code Generation Is Only One Stage
AI coding tools can reduce the time required to produce code that looks ready for review. But the delivery cycle continues after the code is created. Someone or something still has to verify intent, run tests, resolve failures, approve the change, merge it, and move it into production.
LinearB’s 2026 benchmarks analyzed more than 8.1 million pull requests across 4,800 engineering teams in 42 countries. At the 75th percentile, AI-assisted PRs were 2.6x larger than unassisted PRs, at 408 versus 157 lines of code. Agentic AI PRs also waited 5.3x longer for reviewer pickup, at 1,055 versus 201 minutes.
CircleCI found a similar split between activity and delivery. Across all projects in its 2026 State of Software Delivery report, average daily workflow runs increased 59% year over year. For the median team, however, feature-branch throughput rose 15% while main-branch throughput fell 7%.
These findings don’t prove that code review is the bottleneck in every organization. They show why generation volume, accepted suggestions, and PR counts can’t answer whether the full delivery system improved.
Where the Time Is Actually Going
In one Larridin customer’s pipeline, PR-ready time was 0 seconds, while review took 1 hour 2 minutes and merge took 57 minutes. In that environment, most measured post-commit time accumulated after the PR was ready.
The data suggests that investing further in generation speed without examining downstream stages could optimize the wrong part of the pipeline.
The constraint may sit in reviewer pickup, active review, CI capacity, test failures, branch policy, merge governance, or deployment. It may also differ by team, repository, risk level, and type of change. Leaders need stage-level data to identify which explanation fits their environment.
Why AI Can Put Pressure on Review
LinearB’s benchmark shows that AI-assisted PRs can be substantially larger. Larger diffs may require more reviewer attention, but PR size alone doesn’t explain why a change waits before anyone starts to review it.
Long pickup times can reflect several conditions: too many open PRs, unclear reviewer ownership, uneven workload distribution, scarce subject-matter expertise, competing priorities, or policies that route too many changes through the same people. CI and validation delays can add another queue after review begins.
Acceptance rate adds another signal. LinearB reported a 32.7% acceptance rate for AI-generated PRs, compared with 84.4% for manual PRs. In its benchmark, acceptance means the PR merged within 30 days. The gap doesn’t reveal why a PR failed to merge, but it shows that a much smaller share of AI-generated PRs completed that step within the measurement window.
What to Measure Beyond PR Volume
To find an AI code review bottleneck, leaders should separate the delivery cycle into stages:
- PR-ready time: How long does it take for a pull request to be created and submitted for review?
- Pickup time: How long does a ready PR wait before review starts?
- Review time: How long does active review take?
- Validation time: How long do tests, security checks, and CI workflows take?
- Merge time: How long does an approved change wait to merge?
- Deployment time: How long does merged code take to reach production?
Break those measures down by AI-assisted versus manual work, team, repository, PR size, risk, and coding tool. Then pair speed with downstream outcomes such as acceptance, rework, reversions, and change failure rate.
Aggregate DORA metrics still matter, but they can’t identify the specific stage creating the delay. Pipeline visibility turns a broad lead-time problem into a decision about where to act.
Diagnose the Constraint Before Adding Capacity
The right investment depends on where the time is accumulating.
- If pickup time is rising, examine reviewer routing, ownership, work-in-progress limits, and PR size.
- If active review time is rising, improve the context attached to AI-generated changes and focus review requirements on the risk of the change.
- If validation time is rising, examine test selection, CI capacity, flaky tests, and failure recovery.
- If merge time is rising, review branch policies, approval requirements, and release coordination.
More AI generation capacity won’t solve a downstream queue. Neither will adding reviewers before determining whether reviewer capacity is the actual constraint. Measure the stages first, then target the part of the pipeline limiting throughput.
Frequently Asked Questions
Why are AI-assisted PRs waiting longer for review?
The benchmark data shows a pickup-time gap, but it doesn’t identify one universal cause. Larger PRs, queue depth, reviewer ownership, workload distribution, validation requirements, and change complexity may all contribute. Internal pipeline data is needed to determine which factors matter in your organization.
Does the 5.3x figure mean reviewers take 5.3x longer to review AI code?
No. The figure measures pickup time, or how long a PR waits before a reviewer starts. It doesn’t measure the duration of active review.
How do we identify the bottleneck in our software delivery pipeline?
Track time at each stage rather than relying only on total lead time or PR volume. Compare PR-ready, pickup, review, validation, merge, and deployment times, then break the results down by team and type of work.
Should we hire more reviewers to address the bottleneck?
Not automatically. Hiring may help when reviewer capacity is the confirmed constraint. But delays caused by routing, oversized PRs, unclear ownership, CI failures, or branch policies require different changes.
See Where Your Pipeline Constraint Actually Lives
Larridin’s AI Dev Productivity platform shows where time is accumulating across the full delivery cycle, from commit to review to merge to production. Engineering leaders can identify the actual constraint before investing in more generation capacity, review resources, or pipeline infrastructure.
Book a discovery call to see where your software delivery pipeline is slowing down.