We Cut PR Approval Time 80% — Then Found the 12-Second Approval That Broke Prod

Why This Matters

Agents can 10x your PR volume overnight. Review capacity does not 10x with it. And if nobody was clearly on the hook for a given codebase before agents showed up, that gap was already there — it was just small enough to ignore. Agent-scale throughput doesn't create the gap. It just makes it too loud to keep pretending it isn't there.

The 12-Second Approval

A few months into rolling out coding agents at PhoenixDX, our median PR approval time dropped about 80%. We put it on a dashboard. We called it a win. Agents write the diff, humans hit approve, everything ships faster — that was the story we told ourselves. Then we had a production incident, pulled the approval log to see what went wrong, and found the offending PR had been approved 12 seconds after it was opened. Twelve seconds is not review. It's the time it takes to read a title, glance at a green CI check, and click the button. That's the moment we stopped celebrating the metric and started asking what it was actually measuring.

The Tell: A Measurable Mismatch, Not a Vibe

"Rubber-stamp review" sounds like a complaint about culture — the kind of thing you'd say in a retro and nobody could quite prove. It isn't. It's a data problem, and you can detect it precisely: it's the mismatch between diff size or complexity and time-to-approve. A one-line config change getting approved in 20 seconds is completely normal. A 400-line change touching a payment path or an auth check approved in 20 seconds is a rubber stamp — full stop, regardless of who clicked the button or how many years they've been on the team.

• ▹Pull time-to-approve and lines-changed (or files-changed, or a complexity proxy like cyclomatic delta) for every merged PR in your last month or two.
• ▹Plot them against each other. Skip the trendline — you're hunting for the cluster of large, complex diffs sitting on the same low-approval-time band as the trivial ones.
• ▹Segment by author type if you can tag agent-assisted PRs versus hand-written ones. The mismatch usually shows up in agent-generated PRs first, simply because volume rose there before review capacity caught up.
• ▹Segment by file path or code owner too. The mismatch clusters around specific areas of the codebase — it's not random noise. That clustering is the signal that actually matters.

If you see large, complex diffs approved in under a couple of minutes with zero comment thread, that's not a fast reviewer doing great work. That's an unreviewed merge wearing a green checkmark.

Reframe: This Was Never a Throughput Problem

It's tempting to read a 12-second approval as "we need better agent output" or "we need stricter CI gates." Both are worth doing in general. Neither explains what actually happened here. The real story is this: culture is what survives pressure, and agent-generated volume is pressure applied at a scale our review process had simply never been tested against. Teams that had real ownership — someone whose name you could say out loud when asked "who owns this" — held up fine under 10x volume, because the routing question already had an answer. Teams running on tribal knowledge and "whoever's free reviews it" collapsed into rubber-stamping, because that same question suddenly had no answer, 10x more often, every single day. The agents didn't invent the ownership gap. They just pushed enough PRs through it, fast enough, to make it visible in a single sprint instead of staying buried for years.

The Mechanism: Diffusion of Responsibility Scales With Throughput

This part comes straight out of the multi-agent-systems literature I work with for my PhD, and it maps onto human review teams just as cleanly as it maps onto agent fleets. Diffusion of responsibility is the classic finding that as the number of people who *could* act on something grows, the odds that any one specific person actually *does* act on it fall — because everyone quietly assumes someone else already has it covered. It isn't laziness. It isn't bad faith. It's a structural property of any group with no assigned owner.

Now scale that with throughput. At low PR volume, a team of five without formal ownership can still more or less cover a codebase — there's enough slack that someone eventually reads carefully. At agent-generated volume, that slack is gone. Throwing more PRs into a shared queue with no owner doesn't produce more real review. It produces more diffusion, because each reviewer's individual odds of being the one who does the deep read keep dropping as the queue grows. It's the exact failure mode you see when you fan a task out to N agents with nobody accountable for the final check: you get N shallow passes, never one deep one. Adding more reviewers to a broadcast queue is mathematically the wrong fix — it drags average diligence per PR down, not up.

PhoenixDX: How Tribal Ownership Broke

Before any of this, ownership at PhoenixDX was real but informal. Everyone roughly knew the payments integration was "Minh's area" and the ingestion pipeline belonged to "whoever's been here longest." That worked fine when PR volume was low enough that routing happened through Slack DMs and hallway conversations — a new engineer got told, or guessed right often enough that it didn't matter. Tribal knowledge routes okay at human-authoring speed, because there's a natural rate limiter: a person can only write so many PRs in a day, and that gave the informal network time to catch a misroute before it mattered.

Once agents were producing a real share of our diffs, that rate limiter was gone. PRs hit the shared queue faster than tribal routing could keep pace, new engineers who hadn't absorbed the tribal map yet were reviewing code in areas nobody had told them they owned, and the one person who *would* have caught the payments issue was three PRs deep in a growing backlog instead of getting auto-assigned. The 400-line payments PR that got approved in 12 seconds wasn't waved through by someone careless. It was approved by someone who had no way of knowing they were supposed to be the one giving it a hard look — nothing in the process told them that. Tribal knowledge doesn't route volume it was never built for. It just gets bypassed by it.

What Actually Fixed It

The fix wasn't "hire more reviewers" — that just hands more people to the same diffusion problem. It wasn't "slow the agents down" either — that treats the symptom (volume) and ignores the cause (no routing). What actually worked was making ownership explicit and mechanical instead of tribal:

• ▹A CODEOWNERS-style mapping from file path or directory to a named owner, enforced by the repo host so a PR literally cannot merge without that person (or their designated backup) approving.
• ▹One owner per area, not a rotating pool — diffusion comes right back the moment you assign "the payments team" instead of "Minh, backup Anh."
• ▹Owners told explicitly, out loud, which paging responsibilities came bundled with which code area — the same question we now use as a diagnostic, below.
• ▹Escalation paths for cross-cutting agent PRs that touch multiple owned areas, so "this spans three owners" has a defined process instead of defaulting to whoever happens to be online.

None of this slowed agent output down. It slowed *approval* down exactly where it needed to — on the diffs that actually carried risk — while trivial, low-risk PRs kept moving fast. That's the outcome you're after: throughput stays high, but it stops being uniform across risk levels.

The Diagnostic to Run This Week

Two steps. Do both — the data half tells you where the problem lives, the conversation half tells you whether it's actually fixed.

-- Approval-time vs. diff-size for your last 200 merged PRs
SELECT
  pr.id,
  pr.file_paths,
  pr.lines_changed,
  pr.is_agent_assisted,
  EXTRACT(EPOCH FROM (pr.approved_at - pr.opened_at)) AS seconds_to_approve
FROM pull_requests pr
WHERE pr.merged_at IS NOT NULL
ORDER BY pr.merged_at DESC
LIMIT 200;

-- Then look for the cluster you care about:
-- large lines_changed + low seconds_to_approve + no review comments

Then go find every senior engineer on the team and ask one question, word for word: "If this file broke prod tonight, are you the one who gets paged — and do you know that right now, without checking anything?" If they hesitate, say "probably," or name a team instead of a person, you've found an area where review is diffusing, agent-generated volume or not.

Close

Agent-scale throughput is now a permanent fixture of the stress test your engineering culture has to pass. It doesn't invent new failure modes so much as pour more pressure, faster, onto the ones already sitting there. Day 12 pressure-tests the next one: what happens to incident response when the person who merged the PR is an agent, and the 3am page has no obvious person to call.

Extend your knowledge

• ▹Set up (or audit) your repo's CODEOWNERS file — GitHub supports enforced owner-based review natively; GitLab and Bitbucket support CODEOWNERS too, but enforced approval rules sit behind their paid tiers, so check your plan before assuming it's on.
• ▹Read Accelerate (Forsgren, Humble, Kim) on the DORA research — it found lightweight, peer-based code review correlates with better delivery performance and stability than heavyweight approval boards (CABs). That's the empirical case for routing review deliberately instead of broadcasting it to whoever's free.
• ▹Look at Google's Engineering Practices documentation on code review (published as part of their eng practices guide) for a concrete model of what 'real review' looks like at scale.
• ▹Run the approval-time-vs-diff-size query in this lesson against your own repo this week before Day 12 — you'll want the baseline before the next lesson pressure-tests it further.