A shared queue with no owner behaves like a commons: everyone assumes someone else will pick up the oldest item, and the oldest item gets older.
The symptom before the diagnosis
We noticed review latency creeping up on a project where nothing else had changed — same team, same cadence. What had changed was volume. Two engineers using coding agents were opening three or four times as many pull requests as before, each smaller, each waiting for the same pool of reviewers.
Rotation, not volunteering
We assign a named reviewer-of-the-day rather than leaving pull requests open for whoever has time. It sounds bureaucratic for a five-person team. It is bureaucratic, and it is also the only thing that reliably moved the number.
- One name per day, published where the whole team can see it, not buried in a tool.
- A queue limit — if more than six diffs are waiting, no new feature work starts until it clears.
- Small diffs by default — a ticket that would generate an eight-hundred-line change gets split before implementation, not after.
What generated code changed about review capacity
Review is now the bottleneck on most of our AI-assisted projects, not implementation. That is a reversal from two years ago and it means the old assumption — that senior time is best spent writing code — no longer holds. We have moved senior engineers off some implementation entirely and onto review rotations, and throughput went up.
Speeding up generation without speeding up review just moves the queue further downstream. It does not remove it.
The failure mode we watched for
A named owner can turn into a bottleneck of one. We rotate daily specifically so no single person becomes the queue, and we track how long items sit before first comment, not just before merge — the first comment is usually where the real feedback loop starts.
What we would tell a team starting this
Measure the queue before you add an agent, not after. Without a baseline you cannot tell whether the tool bought you anything or just moved the cost from typing to waiting.