Writing code got faster. Review did not. That mismatch is the code review bottleneck: pull requests pile up, seniors drown in “quick looks,” and merge velocity collapses even when everyone is shipping.
What the bottleneck looks like day to day
- PRs older than a business day with zero comments
- Authors pinging in Slack because the “easy” change is blocked
- Reviewers batching 8 tabs at 5pm and rubber-stamping
- Big diffs that sit for a week because nobody wants to start
If that feels familiar, you do not have a motivation problem. You have a queue problem: reviewers are a scarce, single-threaded resource and PR volume rose without matching capacity.
Why 2026 made it worse
AI coding tools raised how many diffs a team can open per week. Reviewer headcount usually stayed flat. The result is classic queue math: arrival rate up, service rate flat → wait time explodes. Forum threads and eng blogs keep rediscovering the same symptom — “PRs sitting unreviewed” — because the system, not the people, is broken.
Fixes ranked by effort
1. Ownership rules (hours, not weeks)
Every PR needs a default reviewer path: CODEOWNERS, a rotating “review desk,” or a team SLA like Google’s one-business-day response norm. Ambiguous ownership is how diffs die quietly.
2. Size limits
Large PRs are queue poison. Aim for diffs a human can finish in one sitting (often under a few hundred lines of meaningful change). Split refactors from behavior changes. Small PRs get reviewed as a break; large ones become a project.
3. An always-on first reviewer
Humans should not be the first eyes on every mechanical issue. Put an AI reviewer on every push so the human pass starts after nits and obvious bugs are already flagged (or patched). That is the “zero-th reviewer” pattern: capacity appears without hiring.
On Mergestorm that maps to agents — Vortex (inline comments), Cyclone (patches), Tempest (deep review). Maelstrom is a plan name, not an agent. The useful shape is a loop: review, then trust the patcher on mechanical fixes, then review the new commit. That is how the queue actually moves.
Watch the AI death spiral
An automatic review + patch loop is the right default. The failure mode is a death spiral: the PR balloons, the reviewer and the patcher start disagreeing on policy, and the thread chases race conditions and nits that were never the point of the change. Latency comes back — just as agent chatter instead of Slack nudges.
Prompts and review policy help: tighter instructions, what not to flag, a cap on “drive-by” refactors. That is necessary. It is not always enough once a PR has already started to churn.
The better tripwire is a governance specialist — a human or a dedicated agent invoked when the PR shows too much churn (comment storms, patch ping-pong, the diff growing after the original job was done). Its job is not another pass of nits. It governs the other agents: stop the balloon, drop the policy fight, and put the loop back on the change that was actually requested.
What “good” looks like
Same-day first response on most PRs. Median time waiting for review measured weekly. Authors rarely nag. Reviewers open fewer giant surprise diffs. For how to measure that, see PR review turnaround time. For tactics authors can use tomorrow, see how to get pull requests reviewed faster.