Review Capacity Is the Bottleneck That Moved Past the Merge

Review capacity, not code quality, is the named technical risk of the moment, and it sets up every decision gate in this section. The Pragmatic Engineer's March 2026 survey of 906 engineers calls the gap between AI-generated volume and fixed human review capacity "the defining technical risk of the current moment". The arithmetic is simple. Generation got cheap; verification didn't. Monzo reports PRs per engineer up 10–20% and names code review as the new bottleneck. Spotify reports a 76% increase in PR frequency with 99% of engineers using AI tools weekly. At Stripe, 1,300+ PRs merged each week are entirely minion-produced: human-reviewed, but containing no human-written code. Reviewer headcount did not grow 76% anywhere.

When throughput outruns capacity, review doesn't fail loudly. It hollows out.

Rubber-stamping is already the norm, and practitioners say so

The clearest account comes from an ops engineer in a Hacker News thread on review tooling, April 2026:

"Most of human review I see of AI code is rubber stamping at this point, the volume is too big for human to keep up. ... At this point, human review seems like CYA then anything else, 'Why yes SOC2 auditor, we review all PRs.' I'm also seeing a lot more outages as well but management is bouncing around all happy about feature velocity."

That is the compliance failure mode: the ritual survives while the substance erodes. The control still appears in the audit binder; it just no longer controls anything. The same thread's founder states the underlying shift plainly: "The bottleneck isn't writing code anymore, it's reviewing it."

The failure does not depend on lazy engineers. A commenter on the rsync Claude-commits thread names the mechanism: careful review of AI output is fine "in a vacuum, but what happens when you're late and stressed out and can't be bothered with doing a proper job. ... If the AI-powered software world depends on humans not being lazy, we're all fucked." A process that holds only when everyone has spare attention is not a process. It is a hope.

The cost is measurable downstream. In the METR randomized trial discussion, one analysis of the 19%-slower result observed that AI workflows shift engineering hours "so that a greater percentage of time is spent on refactoring, testing, and resolving issues later in the process, including after the code was initially approved and merged." The work the reviewer skipped does not disappear. It moves past the merge, where it is more expensive.

The response: automate review, shrink the unit, keep humans on exceptions

Every team that hit this wall built the same three things: an AI reviewer, smaller PRs, and a human gate reserved for judgment instead of volume.

Uber built uReview, its AI code reviewer for a 5,000-engineer org. Cursor shipped BugBot for PR review. Spotify's Honk runs an LLM-as-judge over agent diffs before they enter the normal human review path. A Cloudflare thread on orchestrating AI review surfaced a platform engineer running roughly 15 review subagents that performed about 4,000 reviews in two months.

Intercom went furthest, auto-approving 19% of PRs with no human in the loop. Their argument is that this is the safe response, not the reckless one: "Speed is not the enemy of safety. It's a prerequisite for it. Accumulating code creates risk." Their reviewer refuses to approve large PRs, which makes scope discipline an enforced control rather than a style preference. The full design shows up in the decision-gate pages that follow: AI reviewing AI and scope discipline.

The far end of this spectrum is on the record too. Greptile's founder, in a thread admitting an AI code review bubble, predicts code validation "will be completely autonomous in the medium term" with all human intervention optional. The HN audience largely treated that as a confession, not a roadmap. The defensible middle, the one teams are actually shipping, keeps a human gate and changes what flows through it. That is the design the rest of this section builds out: review as a gate and approval fatigue.

The role changed: reviewer of everything becomes owner of exceptions

Capacity math forces a role redefinition. When an AI reviewer handles the first pass, the human reviewer's job becomes triage: large changes, risky surfaces, anything an engineer escalates. Intercom keeps opt-out universal: any engineer can request human review on any change, at any time. And ownership stays personal. The OpenHands maintainers learned this directly: bot-owned PRs meant the person who triggered the agent could approve their own change, and merged failures had no owner. Their fix was every PR gets a human face on it. That pattern, the author binding that makes triage-style review legitimate, is the subject of binding to the human.

One gap: the field publishes generation numbers, not review-capacity numbers. Monzo names the bottleneck and Cisco reports up to 50% faster review of complex PRs with Codex, but no company publishes reviewer throughput, queue depth, or time-in-review before and after agent adoption. The bottleneck everyone names is the metric nobody reports. Until someone does, the position the decision gates in this section are built on stands on what is public: the volume numbers are public, the rubber-stamping testimony is public, and a review process that depends on human discipline at AI volume is already broken, whether or not your dashboard shows it.

Instrument the metric yourself: two timestamps, open items counted to now

Stamp started_at when an item enters a review stage (review requested, approval pending) and completed_at when it leaves, then measure wait per stage as:

coalesce(completed_at, now()) - started_at

The coalesce is the load-bearing part. The naive version, average completion time over cleared items, systematically under-reports a worsening bottleneck: the worst-stuck items are exactly the ones still open, and a completed-only average excludes them until they finally clear. By then the number tells you about a backlog you already drained.

Counting open work to now() puts in-flight items in the running total, so the metric rises while the queue is growing. Report average, median, and max wait per stage alongside the count of open items, and the stage that is currently the constraint reads straight off the query.