When one person gates code review, the queue runs at that person's speed, and no amount of effort from them changes that. Review throughput is an architecture problem, not an effort problem. This guide covers the two things a team can change this sprint, how big each pull request is and who reviews it, and carries the Review Load Map, a free worksheet for finding out whether your team has a one-name review queue.
Why a single-owner review gate breaks under AI volume
The pattern I see all the time starts innocently. One engineer is the fastest reviewer, so people ask for her, then they wait for her, and then the whole system waits for her. Her manager calls her amazing, and she is. She is also a single point of failure that looks like a strength.
Your review process was designed for the volume of code humans could type. It's now taking delivery of the volume machines can generate. When more code arrives and all of it goes to the same person, the line in front of review has only one place to go.
In Opsera's vendor telemetry, AI-generated pull requests wait 4.6 times longer than human-written ones to be picked up for review. Opsera places that wait mainly before first review, and names the step from PR submission to first review as the primary wait bottleneck. The figure comes from Opsera's 2026 benchmark report, which draws on its product team's data from more than 250,000 developers at more than 60 enterprise organizations, collected across 2025. Opsera is a vendor that describes itself as "the unified DevOps platform that automates and secures software delivery," so weigh the figure with that in mind.
Opsera, AI Coding Impact 2026 Benchmark Report (vendor-published): the report page
That figure compares two kinds of pull request in one vendor's data; it is not a wait that grew over time, not time spent in review, and not a measure of any one team's queue. Opsera doesn't say why AI pull requests wait longer, and it doesn't publish how it classifies a pull request as AI-generated. Size may be part of it; that is our reading, not Opsera's. The ratio says where the line forms, not why, and nothing in this guide claims to shrink it.
If you worked through Week 1's guide to the code review bottleneck, you capped open pull requests so that line could hold steady, with writers reviewing when it was full. Keep that cap. This guide is about what sits inside the line: who reviews, how big each piece of work is, and who it goes to.
Bound the batch: PR size limits that bring feedback sooner
The first half of the fix is the size of each thing you ask someone to review. Reinertsen's Batch Size Feedback Principle puts it in one line: reducing batch sizes accelerates feedback. It comes from The Principles of Product Development Flow (2009), a foundational book about product development in general, not code review in particular, and the same chapter warns that delaying feedback makes rework far more expensive.
DORA's guidance on working in small batches, which is practitioner guidance rather than a study, warns that "large changes are difficult to review, test, and integrate safely," and advises against generating massive pull requests. The same page adds a caution worth keeping: reviewing a small chunk of machine-generated code may cost more per line than reviewing human-written code. So a smaller batch can move cost onto the reviewer rather than remove it.
DORA, Working in small batches (guidance): the capability page
DORA's 2025 AI Capabilities Model, in its State of AI-assisted Software Development report, points the same way. It names seven capabilities, kept from 15 candidates DORA surveyed, that in DORA's word amplify the benefits of AI adoption, and working in small batches is one of them. Among teams that work in small batches, AI adoption went with stronger product performance and less friction, and with slightly smaller gains in individual effectiveness; DORA judges the net effect positive. That is an association in a self-reported survey, not a controlled test, and it measures no review time.
DORA, 2025 State of AI-assisted Software Development: the full report
Opsera's report also recommends reducing reviewer cognitive load through smaller pull requests, automated checks, and clear labeling of AI-generated changes, and says reviewers are becoming the safety net for AI output, increasing burnout and risk. That is a vendor's recommendation and view, not a finding, and the same report recommends investing in automation before expanding AI use.
Small batches aren't free. Every pull request carries a fixed cost: someone stops, loads the context, and runs the checks. So shrink the batch and keep that fixed cost low, with good automated checks, a clear description, and a clear owner for each review.
The split has to make sense for the code. A change that touches the database, the service layer, the API and the screens all at once lands as one giant review, and the reviewer either blocks out an afternoon or skims it. Split it into working changes, each with its own tests; for example, the schema, then the service, then the API, then the screens, so each piece can be reviewed and get feedback on its own.
The size cap is your team's number, not ours. No source this week supports a specific limit, so pick one as a working agreement: small enough that one person can review a pull request in one sitting. Write it down where the team will see it when they open a pull request.
Spread the load: reviewer load balancing with one named reviewer, rotated
The second half of the fix is who reviews. The practice we teach and coach at Big Agile is simple to say: one named reviewer per pull request, rotated, never one person for everything, and never a whole team at once. It is our practice, not a research finding, and no source this week tests rotation, so treat it as an experiment you measure.
We name one reviewer because a review assigned to a whole team can belong to nobody; everyone assumes somebody else has it. We rotate because when the same expert always reviews, that expert stays the only expert. Rotation, as we teach it, spreads that knowledge a little every sprint instead of all at once on the day someone leaves.
The nearest outside evidence is narrow. In a randomized trial at Meta, on code changes that had only a team assigned to review them, assigning one individual reviewer cut the time those changes spent waiting for or in review by 11.6%. The reviewer was picked at random from a recommender's top three, and reviewers spent no significantly different time on each review. That is one company, in a peer-reviewed paper whose authors say the result may not hold elsewhere, and it tests one person against a team, not rotation or who else should review.
Rigby et al., ACM Transactions on Software Engineering and Methodology (peer-reviewed): the published article
In five large open source projects (CoreFX, CoreCLR, Roslyn, Rust and Kubernetes), Mirsaeedi and Rigby (ICSE 2020, foundational) found that the 10 reviewers with the most reviews in a quarter did a large share of the reviews. They also found that assigning reviewers by file ownership concentrated knowledge on a small group of core developers. Our caution: open source isn't your enterprise, and core maintainers there may be expected to review most changes.
Mirsaeedi and Rigby, ICSE 2020: the paper
That ownership finding is why, in our practice, we don't route reviews by who owns the file. Routing by ownership sends each change to the people who already know the code, which keeps the knowledge exactly where it already is.
What about the code only one person understands? That isn't a reason to keep her on every review; it's the clearest sign of the risk you're carrying. In our practice, you pair a new reviewer with her for a while: the new reviewer owns the review, and she stops being the gate and starts being a teacher.
It's slower at first. You're making small debt payments now instead of one large one on the day she leaves. After a few rotations, check whether someone else can review that code without her, and if they can, you have reduced the risk instead of admiring it.
Naming one reviewer here is about load, not about who owns AI-generated code once it ships; that is a different job. Spreading reviews is also not permission to review less, because a rubber-stamped review is a signal about your system, not a saving.
Two weeks ago we argued that refactoring belongs inside everyday work, not saved for a big cleanup later. Who can review which code deserves the same treatment: built a little every sprint, not discovered the week your best reviewer is out.
Asynchronous code review, defined
You'll see "asynchronous code review" offered as the fix for a slow review queue. Pull-request review is already asynchronous: the author opens it and a reviewer picks it up later, and Opsera's wait is the wait in exactly that kind of queue. So the problem isn't when review happens; it's one owner and unbounded batches.
When we say async review at Big Agile, we mean something narrower: review that doesn't block a merge, for changes whose risk allows it. That is close to what Rouan Wilsenach calls Show in Ship / Show / Ask (martinfowler.com, 2021): open a pull request, merge it immediately, and let the team review after. His other two are Ship, merging without review, and Ask, opening a pull request and waiting for discussion before merging. The risk test is ours; his criteria are the kind of change and how much the team trusts each other.
Rouan Wilsenach, Ship / Show / Ask (martinfowler.com, practitioner model): the article
In Wilsenach's description, Show still waits for automated checks before the merge. In our reading it also needs a mainline you can release from, and review after the merge can quietly become no review at all. We don't treat skipping review as safe, and Ship is not this guide's advice.
Try this next week
Start with the Review Load Map below, and run it with the team in one sitting on the pull requests merged over your last few weeks. List who reviewed which pull requests, just names and counts, and look for the one name that shows up everywhere. If one person carries most of your reviews, you've found your one-name queue, and now you can see it instead of just feeling it.
Then pick one pull-request size cap as a team, and name one reviewer for each pull request, rotating the name every sprint or on whatever rhythm your team chooses. Before you start, count the pull requests waiting on a first review, the number from Week 1, and count them again after a few weeks. Watch the busiest reviewer's count over the same stretch, and check whether anyone else can now review the code only one person used to understand.
Keep the cap and the rotation if those move the right way while the line holds steady, and change something if they don't. Give it two or three iterations before you judge it, not one.
REVIEW LOAD MAP
Run it with the team, in one sitting, on the pull
requests merged over your last few weeks.
TEAM: ______________________ WINDOW: _______________
1. WHO REVIEWED WHAT
List each merged pull request and who reviewed it.
Names and counts only. No scores.
Reviewer: ____________________ Count: ______
Reviewer: ____________________ Count: ______
Reviewer: ____________________ Count: ______
Reviewer: ____________________ Count: ______
2. THE ONE NAME
Whose name shows up on most rows?
Name: ______________________________________
Code only this person can review today:
____________________________________________
3. ONE SIZE CAP
Pick one pull-request size cap as a working
agreement. Your number. Small enough that one
person can review it in one sitting.
Our cap: ___________________________________
4. ONE NAMED REVIEWER, ROTATED
Each pull request gets one named reviewer. Not
the whole team, and not always the same expert.
We rotate the names every: _________________
For code only one person knows, pair a new
reviewer with them. The new reviewer owns it.
New reviewer: ________________ with: _________
5. BEFORE AND AFTER
Pull requests waiting on a first review:
Before: ______ After a few weeks: ______
Review count for the name in step 2:
Before: ______ After a few weeks: ______
Can someone else now review the code in step 2?
Yes / Not yet
DONE WHEN: the team has run every step for two or
three iterations and decided, from the counts, to
keep the cap and the rotation or to change them.If you want help reading what the map shows you, this is the kind of change our team coaching works on.
A review process that depends on one fast person isn't a process. It's a prayer.
Ran the map and not sure what to change first? Send me a note if you need help.