The numbers nobody wants to talk about

The AI Engineering Report 2026 analyzed telemetry from 22,000 developers across more than 4,000 teams. The top-line metrics are impressive: epics completed per developer are up 66%, task throughput is up 34%, and PR merge rates are climbing.

But look one layer deeper and the story changes completely.

Median time in PR review is up 441%. Average time spent in code review is up nearly 200%. Pull request sizes have grown 51%. And 31% more PRs are merging with zero review — not because teams chose to skip it, but because reviewers can't keep pace with the volume.

The report calls this pattern "Acceleration Whiplash."

The bottleneck moved

For decades, writing code was the slowest step in the software delivery pipeline. A developer opened one or two PRs a day, and a teammate reviewed them over coffee. Review kept up because there wasn't that much to review.

AI changed the first step. Developers with AI tools now produce five or six PRs a day. But a reviewer can still only handle the same number they always could. The pipeline is no longer balanced.

Faros AI analyzed data from more than 10,000 developers and found a 98% increase in PR volume. The result: PR review time went up 91%, even though code generation itself got faster.

This shift hits senior engineers hardest. A 2025 study found they spend an average of 4.3 minutes reviewing AI-generated suggestions, compared to 1.2 minutes for human-written code. It's not that they're slower — it's that AI-generated code requires a different kind of review. You're no longer validating correctness. You're judging necessity. Does this abstraction earn its weight? Would the team want to maintain this defensive code six months from now?

That takes more cognitive effort per PR, not less — at the exact moment volume is exploding.

What actually helps

The answer isn't skipping review or rubber-stamping AI-generated code. It's getting smarter about where review effort goes.

Not every PR carries the same risk. A one-line config change and a 500-line refactor touching authentication logic should not receive the same scrutiny. Risk-based triage — automatically scoring PRs by diff size, CI status, sensitive file changes — lets reviewers spend their limited attention where it matters.

Visibility matters too. When PRs are scattered across dozens of repositories with no unified view, stale reviews go unnoticed. Tools like Code Board aggregate PRs from GitHub and GitLab into a single Kanban board specifically to make aging and queue imbalance obvious at a glance.

GitHub is also responding. In April 2026, they launched native stacked PR support through a CLI extension called gh-stack, aimed at breaking large changes into reviewable layers.

The real metric

High-performing teams review PRs within 4 hours. If your average exceeds 24 hours, that's likely your biggest hidden bottleneck — and it cascades through your entire development process.

The organizations that win in 2026 won't be those generating code fastest. They'll be the ones who deliver value fastest — and that means fixing the step that's actually stuck.