Recently I was working with a team that reminded me of something I see all the time. They had a senior engineer who reviewed every pull request for four teams. Nothing merged until she had looked at it. You probably know a team like that.
She hadn't written a line of product code in a week. Her own branch was going stale while the list of reviews she owed everyone else kept growing.
Ask her manager how reviews were going and you'd hear that she's amazing. She turns reviews around faster than anyone in the building, faster than anyone I've seen, and she keeps poor code out of the repos.
I agree. She is amazing. That's exactly the problem.
How one great reviewer becomes the gate for four teams
Nobody planned for her to become the gate. It happened one review at a time, the way these things do when you try to add process and scale teams.
She was the fastest, so people started asking for her. Then people started waiting for her. Now the whole system waits for her.
When her list gets long, the instinct is to push her to go faster, or to go find another person just like her. I understand why. Good people are hard to find. But if every team still waits on one particular person, a second hero just moves the dependency somewhere else.
That's the instinct I want to challenge this week. A faster reviewer won't fix this. She's a single point of failure that looks like a strength from the outside. Every number about her looks great until she takes a vacation.
AI changed the review volume underneath her
We've spent most of this year looking at AI and delivery, and here's the part that makes this story more urgent. Your review process was designed for the volume of code humans could type. It's now taking delivery of the volume machines can generate. That's a different set of problems.
A few weeks ago, in our episode on the line forming in front of code review, we found that queue and put a WIP limit on open pull requests so the line could hold steady. If you missed that one, go back and watch it. I won't reteach it here. This week is about what's inside that line: how big each piece of work is, and who reviews it.
What the 4.6x number does and doesn't tell you
Opsera published its 2026 AI Coding Impact Benchmark Report, built from data covering more than 250,000 developers at more than 60 enterprise organizations. In that data, AI-generated pull requests waited 4.6 times longer for review than human-written ones.
Weigh that number with a few things in mind. Opsera sells DevOps platforms, so they may be trying to sell you something, and the report doesn't say how much of its data set sits behind this one comparison. What you're looking at is AI pull requests compared with human pull requests in one vendor's data, rather than a wait that grew over time or one team's queue. The report also doesn't say why AI pull requests wait longer. Size may be part of it, but nobody knows for sure.
One more data point lines up with it. LinearB's separate 2026 Software Engineering Benchmarks Report, built from more than 8 million pull requests, landed on the same 4.6x and placed the wait before review begins. Once someone picks up an AI pull request, it actually moves faster. Unless you're tracking this on your own teams, those are the best numbers we have, and both point at the line in front of review.
Now put our engineer back in the picture. More code arrives, and all of it goes to the same person. The line has only one place to go.
That's a system problem. W. Edwards Deming said it plainly: a bad system will beat a good person every time.
Bound the batch: pull requests small enough to finish in one sitting
The first half is the batch. How big is each thing we ask somebody to review? I'd want a working agreement the team can hold itself to.
The principle comes from Donald Reinertsen's The Principles of Product Development Flow, which we lean on a lot here. He calls it the batch size feedback principle: reducing batch sizes accelerates feedback. That book came out in 2009, and it still holds. When feedback is delayed, rework gets expensive fast.
What DORA's research adds
DORA points the same way. Its AI Capabilities Model names seven capabilities that amplify the benefits of AI adoption, and working in small batches is one of them. Among teams in their survey that work in small batches, AI adoption went with stronger product performance and less friction.
It also went with smaller gains in how effective individuals felt. If you measure individual productivity, that may surprise you. It shouldn't. When people do more cross-functional work, individual utilization often goes down while the system gets better. And this is an association from a survey, not a controlled test. I like that DORA reported both halves. Small batches aren't magic, but they do change how the whole system behaves.
DORA's guidance also warns that large changes are hard to review, test, and integrate safely. In other words, resist the temptation of massive pull requests. The same guidance cautions that reviewing machine-generated code may cost more per line than reviewing code a person wrote, which is worth thinking about as more of your code comes from tools.
Smaller pull requests get feedback sooner
I'm not going to tell you that smaller pull requests make each review faster. None of my sources say that directly. What they support is that smaller pull requests get feedback sooner. The aim is a review a person can actually finish in one sitting, even if that person is juggling other work.
Small batches aren't free, though. Every pull request carries a fixed cost. Somebody has to stop, load the context, and run the checks. So as you shrink the batch, keep that fixed cost low: good automated checks, clear descriptions, and a clear owner for each review.
What a split pull request looks like
Let's make it practical. Say one of those four teams opens a 900-line pull request. It changes the database schema, the service layer, the API, and all the screens at once. That lands on our engineer's list as one giant review.
She either blocks out an afternoon for it or she skims it. In enterprise software, neither is a good option, and one of them is going to bite you.
Now say the team splits that change into four pieces, each one a working change with its own tests: the schema, the service, the API, and the screens with their integration tests. The split has to make sense for the code. The goal is that each piece can be reviewed on its own and get feedback on its own. That's the batch half.
Spread the load: one named reviewer per pull request, rotated
The second half is who reviews it. At Big Agile we've been coaching branching, merging, and code review for a long time, and the practice we teach is simple to say: one named reviewer per pull request, and rotate that name. Never one person for everything, and never the whole team at once.
Why one named reviewer
A review assigned to the whole team can end up belonging to nobody. Everyone assumes somebody else has it. Cross-functional teams run into that danger every day.
Why rotate it
If the same expert always reviews, that expert stays the only expert. Rotation spreads the knowledge a little every day, instead of making you pay for it in one lump sum when someone leaves. We've all been there.
And never one person for everything, because that's the engineer we started with. She's the single point of failure this whole approach is meant to guard against.
What about the code only she understands?
I hear some of you asking: what about the code nobody else can review? It's a fair question, and it's a recursive problem. Nobody else can review it because nobody else has ever reviewed it.
To me, that code is the clearest view of the risk you're carrying, and the most urgent. It's a reason to start spreading the load there first, not a reason to keep her on every review.
For that code, pair a new reviewer with her for a while. The new reviewer owns the review. She stops being the gate and starts being a teacher. Yes, it's slower. Think of it as small debt service payments. The alternative is going bankrupt the day she leaves. Stop chasing short-term gains. This is an investment, and some of what it buys is risk you no longer carry.
After a few rotations, check whether someone else can review that code without her. If they can, you've reduced the risk instead of admiring it from a distance and saying, "Look how great she is."
Putting both halves together
Go back to the split pull request. The schema change goes to one engineer. The service change goes to another. The API change goes to a third, and the screens go to a fourth. Our senior engineer might take one piece, not all four.
Next time, rotate. The names move. Somebody new reviews the schema work, and the person who reviewed it last time helps them learn it. That's cross-pollinating knowledge, and cross-functional teams depend on it.
| Piece of the 900-line change | Reviewer this sprint | Reviewer next sprint |
|---|---|---|
| Schema change + tests | Engineer A | Engineer B, with A helping |
| Service layer + tests | Engineer B | Engineer C |
| API + tests | Engineer C | Senior engineer |
| Screens + integration tests | Senior engineer | Engineer A |
Will it feel slower at first? Absolutely. People are learning code they didn't write and building new habits, and that's the dip in the change curve we see every time a team learns something new. What you're hoping to see on the other side is several people who can review the schema, not one. And a senior engineer who gets to write code again and contribute to the product.
To be clear, the sources I read this week didn't test this exact combination. This is our practice, not a research finding. I've seen it work in the wild, so treat it as an experiment with your teams. Try it, measure it, and keep it only if the numbers say it's working. But don't give up after one try. Give it at least two or three sprints.
Run it as an experiment next week
This Wednesday, we're publishing a free worksheet on the blog called the Review Load Map. Start there. Then work through these steps with your team:
- List who reviewed which pull requests over the last few weeks. Just names and counts. You're looking for the one name that shows up everywhere. If one person is carrying most of your reviews, you've found your engineer from the opening. Now you can see it instead of just feeling it, and as G.I. Joe used to say, knowing is half the battle.
- Pick one pull request size cap as a team and make it a working agreement. Use your number, not mine. It should be something your team agrees a person can review in one sitting.
- Name one reviewer for each pull request, and rotate that name every sprint or on whatever rhythm you choose. Not the whole team, and not always the same expert.
- Measure it. Before you start, count the pull requests waiting on a first review. Count them again after a few weeks. Also watch your senior engineer's review count over the same stretch, and check whether anyone besides her can now review the code only she used to understand.
If those numbers move the right way and the line keeps holding steady, keep going. If they don't, change something and try again. One cap, one named reviewer, rotated, and a few numbers to watch so nobody gets overwhelmed. That's the whole experiment.
Change the question leaders ask
If you lead these teams, change the question you ask. Don't just ask how fast reviews are. Ask how many people can review each part of the code.
We talked about refactoring recently, and how it should happen all the time. Reviewing should keep changing too, so the team keeps building that capability. If the honest answer is one person, you already know your delivery is fragile. You've probably felt it. You just haven't been able to see it or change it.
So let's go back to our senior engineer. I don't think she was ever the problem. The problem is that the whole system was built around her being fast, and that feels great while she's there. A review process that depends on one fast person isn't a process. It's a prayer.
Progress over perfection. We never truly arrive, but we should have a good system to travel in. Our job is to make that system a little better for our people every day.
Have a problem your teams are facing? Send it to us at big-agile.com/questions, and we may answer it in a future episode. If you want help building a review process that doesn't run through one person, come work through it with us in one of our upcoming Big Agile classes and workshops.