Claude Code Ships Faster — So Why Are Your PRs Sitting Longer?

Why This Matters

Claude Code and Copilot didn't remove your team's bottleneck. They moved it. Keep managing review the way you did before agentic tools, and more output from your engineers translates directly into slower shipping — not faster.

The Paradox: More Code, Slower Reviews

Here's the pattern I watched unfold at PhoenixDX as Claude Code went from novelty to daily habit: engineers ship noticeably bigger diffs, more often. A refactor that used to be a tight 80-line PR turns into 400 lines because the agent happily rewrote three adjacent files while it was in the neighborhood. You'd expect review time per PR to drop — the code got written faster, after all. Instead PRs started sitting in the queue longer. Reviewers weren't rejecting more work; they were opening a diff that touched files they never asked the agent to touch, and closing the tab to come back 'when they had a real block of time.' That deferral is the tell. The bottleneck didn't vanish when generation got faster. It just backed up further down the pipe.

The Hidden Assumption: Generation Speed Was the Bottleneck

Nearly every pitch for agentic coding rests on one premise nobody says out loud: that the thing slowing your team down was how fast code gets written. That was true for most of software engineering history. Pre-agent, a human typed every line, so writing speed and review speed stayed roughly coupled — a senior engineer writes a PR in two hours, a peer reviews it in twenty minutes, and the whole system moves at human-writes, human-reads pace. Agentic tools snapped exactly one side of that coupling. Claude Code produces in ninety seconds what used to take an afternoon. The reviewer on the other end still reads at the same speed they always did — human eyes, human working memory, human context-building. You didn't remove the bottleneck. You made one side of the pipe ten times faster and left the other side untouched. Now the slow side sets the whole system's speed limit.

What Actually Happens on a Team

Once review bandwidth quietly becomes the real constraint, I've watched two failure modes show up — and the second is more dangerous than the first:

• ▹Rubber-stamping: reviewers, buried under diff volume, start approving on skim. Tests pass, CI is green, the description reads fine — approve. Review becomes theater. It still says 'reviewed' in the PR history, but nobody's actually vouching for the logic.
• ▹Reviewer burnout: the conscientious engineers won't rubber-stamp, so they try to build a full mental model of code they didn't write and wouldn't have written that way. That takes longer than writing it themselves — verifying someone else's reasoning is harder than generating your own. These reviewers become the queue. They fall behind, PRs pile up specifically on their plate, and the team's best judgment turns into its scarcest resource.
• ▹The dangerous middle: teams that hit the first failure mode and mistake it for velocity. Throughput looks fine on a dashboard. 'Reviewed' has quietly stopped meaning 'verified.'

The Reframe: Review Bandwidth Is the Scarce Resource

Once you accept the bottleneck moved, the metric you're optimizing has to move with it. 'Lines shipped,' even 'PRs merged per week,' measured the wrong thing before agents ever showed up — now it's actively misleading, because an agent can inflate that number with zero corresponding increase in any human's actual understanding of the system. The unit of work that matters in the agentic era is diffs a human can actually vouch for. Not diffs that passed CI. Not diffs that got an approval click. Diffs where a specific person could explain, under questioning, why the change is correct and what it might break. That number is a lot smaller than 'lines generated' — and it's the number your team is actually constrained by. This is the Day 1 mental model for the rest of this series: every practice we cover next, how to structure agent output, how to review it, how to build trust in it over time, exists to make that number bigger without burning out the humans producing it.

The One Lever (Full Treatment Later in This Series)

I'll just plant the seed here — the how deserves its own lesson. The highest-leverage fix isn't reviewing diffs faster. It's reviewing the plan before the code exists. Verifying an agent's stated approach — 'I'm going to touch these three files, here's the data flow, here's what I'm assuming about the caller' — takes a fraction of the time that verifying the resulting 400-line diff line by line does, and it catches the wrong direction before it hardens into wrong code. Same instinct as reviewing a design doc before an implementation, just applied to a much faster loop. We'll go deep on structuring and running plan review — including when to skip it for low-stakes changes — later in this series.

The Stakes

Teams that don't fix this don't degrade gracefully. They don't get 'a bit slower' — they accumulate a growing body of reviewed-in-name-only code: work with an approval stamped on it that nobody actually understands or would stand behind under questioning. That code doesn't announce itself as risky. It sits quietly until it's the file at the center of your next incident, and the postmortem turns up an approved PR with no one left who can explain what it does. That's why I'm framing Day 1 around review bandwidth instead of a tool or a prompt trick: it's a management problem, not a tooling problem. Fixing it means redesigning how your team allocates its scarcest resource — human judgment — not finding a faster autocomplete.

Extend Your Knowledge

• ▹Track your own team's review turnaround before and after agentic adoption — not lines merged, but time-to-approval and time-to-'reviewer could actually explain this change.' That gap is your real bottleneck, made visible.
• ▹Read Google's engineering practices doc on code review — the small-CLs and reviewer-speed guidance — and re-read it asking whether the advice assumes a human wrote the diff. Most of it does, and that's exactly the assumption this lesson challenges.
• ▹Watch for the rubber-stamp signal on your own team this week: PRs approved within minutes of opening, with a diff over roughly 300 lines. That's the leading indicator, not the lagging one.
• ▹Next in this series: how to structure and run plan review with an agent before code exists — the lever named above, worked out in practice.