Your Cycle-Time Chart Is Going Down. So Is Your Review Quality. Nobody's Connecting the Two.

Day 1: Your PR Throughput Chart Is Lying to You

If the only number you've watched since rolling out Claude Code or Copilot is 'PRs merged per week,' you're staring at a pipeline stage that stopped being the bottleneck months ago. The bottleneck quietly moved to review. Nothing on your dashboard noticed it leave.

Two dashboards, same meeting

I've now watched this exact scene play out at two different companies. Someone pulls up the cycle-time chart — down and to the right since the AI rollout, the kind of chart that gets screenshotted straight into a leadership deck — and in the same review, someone else pulls up the incident postmortem timeline for that same team, same quarter. It's climbing. Nobody in the room connects the two charts until somebody actually puts them side by side. That's the moment this lesson is built around.

Where it clicked: the queue didn't disappear, it went invisible

PR throughput went up because writing code got cheap. I've watched one engineer with Claude Code turn out two or three PRs in the time it used to take to ship one. Reviewing those PRs did not get anywhere near that much cheaper — a human still has to read the diff, hold the intent in their head, and decide if it's safe to ship. The queue of 'work waiting on a human' never shrank. It just relocated from the editor to the review tab, while your metrics kept clocking the stage that got faster instead of the one that didn't.

What 'PRs merged' was quietly hiding

• ▹Reviewer load per engineer. How many PRs is each senior engineer reviewing a day now, compared to a year ago? Almost nobody tracks this at the individual level — they track the team aggregate, which is exactly what hides who's become the bottleneck.
• ▹Time-in-code vs. time-in-review. Cycle time dropped, but the split inside it flipped. On one of the teams above, code went from roughly 60% of cycle time to 15%; review went from 40% to 85%. The total looked great. The composition was the actual story.
• ▹Diff size and density. AI-generated PRs run bigger — more files touched, more generated boilerplate, more edge cases handled 'while I was in there' — even as the count of merged PRs keeps climbing. A reviewer facing a 400-line AI diff will often apply roughly the same quick-skim habit they used on a 40-line hand-written one.
• ▹Approval latency vs. approval depth. PRs got approved faster. Faster and 'read more carefully' are not the same thing, and a fast approval on a bigger diff should read as a red flag, not a win.

Why the incident often shows up two sprints later

When we pulled the escaped defects and traced them backward, a disproportionate share landed on PRs approved in under the team's median review time, on diffs above the median size — the rubber-stamp pattern, in other words. In the cases I traced, the roughly two-sprint lag tracked how long it took a shortcut merged under review pressure to actually get exercised by a real user path, turn into a support ticket, get triaged, and land in a postmortem. That's long enough that the reviewer who approved it — and the dashboard that showed green — are both well past the moment of decision by the time anyone asks 'wait, why did this pass review?'

The fix isn't 'slow down' — it's 'measure the other half'

Telling engineers to review more slowly doesn't survive contact with a sprint deadline. What does survive is making the hidden stage visible enough that it can't lie to you the same way twice. Add these next to cycle time — not instead of it:

• ▹Reviewer load per person, tracked individually, not team-averaged. A team average of 5 PRs/day can just as easily mean one senior engineer drowning at 15 while three juniors sit at 1.
• ▹Defect escape rate segmented by review speed and diff size. Does your data show the same rubber-stamp correlation I saw? If it does, that pairing is now your leading indicator — potentially sprints ahead of the postmortem.
• ▹Review depth proxy — comments-per-line or time-in-diff-viewer, if your tooling exposes it. A 300-line AI-generated diff approved with zero comments is a different risk profile than the same zero comments on a 20-line hand-written one.
• ▹Pair every 'PRs merged' chart with its review-debt counterpart before it goes anywhere near a leadership deck. If you can't show both, you haven't earned the win yet.

The Day 1 lesson for this series

Every KPI you inherited — cycle time, PR throughput, velocity — was built for a world where writing code was the expensive, bottlenecked step. AI coding tools didn't break those metrics. They exposed that the metrics were only ever measuring one side of the pipe. Over the next 30 days, you'll make this same move again and again: find where the bottleneck actually moved before it finds you in a postmortem.

Extend your knowledge

• ▹Pull your own team's diff-size distribution from before vs. after your AI coding tool rollout — GitHub and GitLab both expose additions/deletions per PR through their APIs for exactly this.
• ▹Cross-reference your last two quarters of incident postmortems against PR approval time and diff size for the responsible PR — look for the same rubber-stamp correlation described here.
• ▹Read up on DORA's Change Failure Rate — it's the existing industry metric closest to 'defect escape rate,' usually already collected, almost never reviewed alongside cycle time.
• ▹Track per-engineer review load for one sprint before deciding whether your review bottleneck is a process problem or a people problem.