Teams are celebrating a surge in pull request volume this quarter—some reporting 40% more PRs than last year. The problem? Nobody's asking the obvious follow-up question: did someone actually check them? AI coding assistants can generate remarkable amounts of code at unprecedented speed, but they don't generate extra reviewers. That bottleneck didn't disappear—it just relocated downstream into your review queue.

DORA Metrics Have a Blind Spot

The engineering world has embraced DORA metrics to quantify productivity: lead time, change failure rate, deployment frequency. But there's a critical gap in how these numbers get interpreted. Lead time measures the clock from first commit to production. If a PR sits waiting for review for three days because every senior engineer is drowning in AI-generated diffs, it shows up as slow lead time—but nobody's connecting those dots back to their review pipeline problem.

The Failure Pattern Nobody Names

The article describes a predictable cascade that's playing out in engineering teams right now: AI generates more PRs faster than ever before, the review queue balloons overnight, reviewers start skimming instead of carefully reading each change, and then change failure rate begins creeping upward. What do orgs call this? "Quality issues." Wrong diagnosis. The real issue is a capacity mismatch—your generation pipeline scaled dramatically while your review infrastructure stayed frozen in time.

AI Review Debt Is Real Technical Debt

The term "AI Review Debt" was recently coined by Sumant Thakur on his Substack, and it fits perfectly. Any AI-generated PR that enters the queue without an associated expansion of review capacity is debt—pure and simple. It accumulates silently sprint after sprint. Senior engineers are getting buried under review requests while junior developers generate PRs with Copilot but lack the context to meaningfully review each other's work. Suddenly three people become the bottleneck for everything in the organization.

What Teams Should Actually Track

The author suggests several concrete changes: measure review queue depth and cycle time separately from overall lead time so you can actually see the jam; stop celebrating raw PR count as a productivity metric since open PRs are inventory, not output; invest in AI-assisted review tooling with the same energy you've poured into generation tools; and set explicit human capacity limits—around 4-5 substantial reviews per day is probably your realistic ceiling for thoughtful review work.

The Real Risk: Velocity Theater

Here's what keeps the author up at night: when reviewers are overwhelmed, they don't decline bad PRs more often—they merge them faster just to clear the queue. This creates the worst possible outcome: the illusion of velocity paired with degraded code quality. Change failure rates climb, trust erodes across teams, and six months later everyone's wondering why the product feels fragile. The bottleneck moved. The org chart didn't.

Key Takeaways

  • Your PR volume metric is measuring output you haven't validated yet—it's inventory, not delivery
  • DORA metrics can show you slow lead time but won't tell you review queues are the culprit
  • AI Review Debt grows silently because nobody's putting it on a roadmap or creating Jira tickets for it
  • Generation capacity doubled or tripled? Your review capacity probably hasn't changed at all—that gap is your debt

The Bottom Line

If you're shipping more code than ever and feeling good about velocity, ask yourself one question: did your team's ability to thoughtfully review that code scale at the same rate? If not, you're not moving faster—you're just creating work faster. That's a dangerous game disguised as productivity.