The Review Queue Is Now Your Deployment Bottleneck

We inherited a client codebase earlier this year where four agents were opening roughly 90 pull requests a day, and the two senior engineers responsible for reviewing them had quietly stopped sleeping. Merge rate had flatlined at maybe fifteen a day while the open PR count climbed past three hundred, and the CI runners were pegged running the same test suite against branches that would sit untouched for a week before someone rage-approved a batch of them just to make the number go down. That is not a tooling problem, that is a process problem, and it is the exact thing GitLab's June 2026 AI Accountability Report put a number on when it found that 85% of developers now say the bottleneck has moved from writing code to reviewing and validating it. The interesting part is not the number. The interesting part is that almost nobody has changed anything in response to it. Most teams I talk to are running the same PR template, the same required-two-approvals branch protection, and the same 'whoever's free grabs the next one' review rotation they set up in 2023 when a busy week meant forty PRs from twelve humans who each understood the change they were shipping. Agents broke that assumption. A human opens a PR because they decided the change was worth making. An agent opens a PR because it was told to and it produced something plausible, and plausible is a much lower bar than worthwhile, so the ratio of noise to signal in your queue has inverted and your review process was designed for the old ratio. Treating a 1,300-PR-a-week firehose with a workflow tuned for a trickle is how you end up with reviewers who approve on vibes and a main branch nobody trusts.

The single highest-leverage change is to stop reviewing every pull request the same way, and the axis that matters is not who opened it but what it touches. We tier by risk surface first, code origin second. A PR that changes a Tailwind class, adds a null check in a display component, or bumps a patch version in package.json is categorically different from one that touches auth middleware, a payment webhook handler, a database migration, or anything under a directory we've explicitly marked as blast-radius sensitive. So the first tier is fully autonomous merge on green CI: agent-authored, low-risk surface, passes the full test suite plus type checks plus a diff-size ceiling, and it goes in without a human ever looking. The second tier is lightweight human sign-off, a single reviewer with a ten-minute SLA, for medium-risk changes or anything where the agent's own confidence signal came back shaky. The third tier is mandatory senior review with no auto-merge at all, and that covers the surfaces where a bad change costs you money or trust or a 3am page. You encode this in CODEOWNERS combined with a labeling GitHub Action that inspects the diff paths. We wrote one in Go for the client I mentioned that reads a paths-to-tier YAML, labels the PR risk:low, risk:medium, or risk:high, and then a branch protection rule keys off the label. The result there was that about 60% of agent PRs stopped needing a human at all, which is what finally let the two seniors go back to reviewing the changes that actually mattered instead of drowning in dependency bumps. The mistake teams make is tiering by author, waving through everything an agent produces because it's an agent or blocking everything because it's an agent. Neither is right. A junior human touching the billing code needs the same scrutiny as an agent touching it, and a senior making a copy tweak needs the same non-scrutiny as an agent making one.

Six months from now you will be staring at a production incident and the first question will be which commits came from a human, which came from which agent, and what prompt or task spawned them, and if you didn't capture that at commit time you are reconstructing it from Slack archaeology. Capture it at the source. We add trailers to every commit an agent produces, the same mechanism git already uses for Signed-off-by, so a commit message ends with Co-Authored-By, an Agent-Model trailer with the actual model identifier, an Agent-Task-Id linking back to whatever queued the work, and a Provenance trailer that's just human, agent, or agent-assisted. This is cheap to add, the agent wrapper injects it, and it means git log --grep and your data warehouse can slice merge rate, revert rate, and defect rate by provenance without any guessing. That last one is where it earns its keep, because once you can measure revert rate per model and per risk tier you can actually tune the tiering policy with evidence instead of politics. On one pipeline we found the agent's revert rate on tier-one auto-merged PRs was 1.8%, lower than the human baseline of 2.3% on the same surface, which was the argument that let us widen the auto-merge net. On tier-three surfaces the same model's revert rate was 11%, which was the argument that kept a human firmly in that loop. Without provenance tags those two numbers are indistinguishable and you're arguing from gut feeling. Tag it, store it, put it in a dashboard, and let the numbers decide where the trust boundary sits.

Stripe's internal agent fleet, the thing they call Minions, reportedly pushes north of 1,300 pull requests a week, and the temptation is to read that number as proof that human review is obsolete. That's the wrong lesson. The right lesson is where they keep humans, not where they removed them. The volume is high precisely because the surfaces the agents operate on are constrained and well-instrumented, refactors with strong test coverage, migrations behind feature flags, boilerplate generation against schemas that already have property-based tests. Human judgment didn't disappear, it moved upstream and got concentrated. Someone defined the constraint, someone set the acceptance criteria, someone owns the surface the agent is allowed to touch, and when the agent produces something that clears the automated gates on that constrained surface, a human review of the individual diff genuinely adds little. The judgment happened before the PR existed. This is the part engineering leads keep missing. You do not scale to agent volume by reviewing faster, you scale by moving the human decision earlier, into the definition of what agents are allowed to attempt and how their output is validated, so that the per-PR review can shrink to almost nothing on the surfaces where you've done that upfront work. The corollary is brutal and worth saying plainly. If your codebase has thin test coverage, ambiguous ownership, and load-bearing implicit behavior, agents will multiply your review burden rather than relieve it, because every one of their plausible-looking diffs now requires a human to reason about consequences the tests don't catch. Agent throughput is a downstream symptom of upstream discipline. The teams shipping 1,300 PRs a week earned it by investing in the boring stuff first.

Redesigning who reviews what fixes half the bottleneck. The other half is that agents will happily saturate your CI runners running full suites against branches that never merge, and that's pure waste you're paying for by the minute. A few things worth doing here. Run a fast lint-and-typecheck gate first and fail cheap before you ever spin up the expensive integration suite, because a huge fraction of agent PRs die on something a two-minute check would have caught. Deduplicate work by hashing the diff and skipping full runs on branches whose relevant paths haven't changed since the last green run. Put a concurrency cap per agent so one runaway task can't consume the whole runner pool and starve the human PRs that a person is actively waiting on, since a developer blocked for thirty minutes is far more expensive than an agent PR sitting in a queue. We also enforce a staleness reaper, a scheduled job that closes agent PRs with no activity and no merge after 72 hours, because an unmerged agent PR is not a work item you'll get back to, it's just noise inflating your open count and occasionally rebasing itself into conflicts. None of this is exotic. It's the same capacity-planning instinct you'd apply to any system where demand suddenly went up two orders of magnitude, applied to the one resource nobody thought to plan for because in 2023 CI capacity was effectively free relative to how many PRs humans could generate. That assumption is dead. Plan for the queue like it's production infrastructure, because it now is.

If you're an engineering lead watching your CI queue grow while merge rate stagnates, don't try to boil this all at once. Pick one surface with strong test coverage, say your component library or an internal admin tool, tier it, turn on auto-merge for the low-risk band, and add provenance trailers so you can actually watch the revert rate. Give it a month. If the revert rate on the auto-merged band stays at or below your human baseline, widen the net to the next surface. If it doesn't, you've learned exactly where your test coverage is lying to you, which is useful information you were going to need eventually anyway. We've done this rollout enough times now at steezr, on document processing pipelines and customer portals and a couple of internal systems where agent volume was quietly crushing the review team, that the pattern is boringly repeatable, and the thing that consistently surprises clients is how much of the win comes from the process changes rather than from anything clever in the agents themselves. The agents were never the bottleneck. Your Prague-based skepticism is warranted about most AI-in-the-loop pitches, and I share it, but this particular shift is real and measurable and the teams that redesign their review process for it will ship while the teams still running their 2023 workflow watch three hundred open PRs and wonder why nothing merges.