Video summary

Code Review Time Is Up 441%. The Bottleneck Moved. Why More AI Agents Means Less Done

Main summary

Key takeaways

Technology

Technological concepts & main findings

  • AI agents increase code output, but don’t remove the delivery bottleneck — they shift it. Faster generation of pull requests increases the inflow to code review, creating queueing delays downstream.

  • Queuing theory explanation: When one stage is sped up (e.g., AI writing), the system constraint doesn’t disappear—it moves to the next slowest stage (human review/approval). The pipeline then behaves like a queue filling faster than it drains.

Product features / workflow metrics highlighted

Linear (issue tracker) telemetry trends (industry-scale)

  • AI-created issues in Linear rose from <1 per 1000 (about 2 years ago) to just under half today.
  • Pull requests opened per workspace increased 111% vs a 2024 baseline.
  • Work reaching review/merge also rose: teams opened about ~2x PR volume on similar headcount/cadence.

Independent measurement (Pharaoh’s telemetry)

  • Tracked 22,000 developers across 4,000+ teams using a before/after measurement on the same teams/codebases (not surveys).
  • Epics completed per developer: +66%
  • Task throughput per developer: +34%

Key “review bottleneck” results (the core contradiction addressed)

Despite higher output and throughput, delivery slowed due to review queue overload:

  • Median code review time: +441% (about 5x longer), not just a rare outlier effect.
  • Median time from first commit to done: +225%

This increase is framed as a capacity/volume mismatch, not necessarily reviewer skill decline:

  • AI assistance can produce larger diffs, which are harder to review in one sitting.
  • Agentic PRs are ~2.5x larger (Linear B data):
    • ~408 lines (75th percentile) vs 157 lines for non-agent work.
  • Larger PRs correlate with reduced acceptance:
    • AI-authored code accepted: 32.7%
    • Human-authored code accepted: 84.4%
  • Even rejected attempts still consume reviewer attention, reducing effective throughput even after PRs are opened.

Failure mode: queue aging and “DK”

A PR gets worse the longer it sits (referred to as DK in the subtitles):

  • +26% of tasks experience a full week with zero activity.
  • +14% increase in work being abandoned/restarted.
  • About half the diff may require re-explaining because the author moved on.

Escalation loop

  • Slower pickup → lower trust → more PRs merged without review.
  • PRs merging with no review at all increased +31.3%.

Business/quality cost indicators discussed

  • Churn & incidents increased alongside the slowdown pattern:
    • Code churn (lines rewritten shortly after commit): ~10x
    • Production incidents tied to AI-generated code: >3x
  • Important clarification: these are correlations, not controlled causation experiments (no “AI-only” isolation).
  • The pattern still matches across multiple datasets.

External survey corroboration

  • A New Relic survey (engineering leaders; subtitles mention “200”) reports 82% observed at least one production failure tied to AI-generated code in the prior 6 months.

“Good process isn’t a full shield”

  • Dora’s 2025 report framing: AI acts as an amplifier of existing conditions (strong practices benefit; weak practices worsen).
  • However, the video claims Pharaoh’s telemetry shows that even mature DevOps organizations experienced the same review-time collapse—good maturity didn’t insulate teams from this review queue bottleneck.

Recommended mitigation strategies (“fix section”)

The video argues you must control what enters the bottlenecked review stage, not simply “work harder” downstream. It proposes 4 approaches:

  1. Cap PR size Smaller diffs reduce review effort, wait time, and the DK aging loop.

  2. Move gates earlier Shift formatting, known security patterns, and known vulnerabilities into the dev environment so humans answer only the key question: does this change solve the right problem?

  3. Track review coverage, not throughput Don’t only track “PRs merged per week.” Track share of PRs that received meaningful review (not just accepted/merged counts).

  4. Change success metrics With agents writing most code, focus on review lead time and revert rate on agent-touched PRs, rather than PR volume/creation counters.

Explicit critique: hiring more reviewers, expanding QA, or targeting faster incident response addresses symptoms at the pipeline end—not the overloaded queue itself.

Main speakers or sources (as named in the subtitles)

  • Pharaoh’s AI (telemetry provider measuring before/after developer performance and pipeline effects)
  • Linear (issue/PR telemetry provider; includes reference to “Linear B” measurements)
  • Linear B (dataset/measurement referenced for PR size and agentic vs non-agentic differences)
  • DORA (Dora 2025 report) (used for the “AI amplifier” framing)
  • New Relic (survey of engineering leaders about AI-related production failures)
  • Circle (delivery report noting a similar pipeline shift)

Original video