Here's a quick test. Without opening GitLab, can you name the two people on your team who review the most code? And the two who review the least? If you can't, you're not alone. Most managers can rattle off who shipped what last quarter, because shipping is visible. Reviewing isn't. It leaves no feature behind, no demo, no line on a promo packet. It just quietly makes everyone else's work better.
That blind spot was tolerable when review was a side dish. It isn't anymore. AI assistants made writing code dramatically cheaper, which means your team is producing more merge requests, bigger ones, faster than ever. Every one of those MRs lands on a human reviewer. The writing got cheap; the reading didn't. We wrote about that shift in code review in the age of AI: when the first draft comes from a model, review is where the actual engineering happens. This post is about what that means for you as a manager.
The 60-second version
- AI multiplied the code your team produces. Review capacity didn't grow with it.
- Review load is almost always concentrated: a few people carry most of it.
- That work is usually invisible in performance reviews, so your best reviewers are effectively penalized for being good at it.
- Fatigued reviewers don't complain first. They start rubber-stamping first.
- Fix: measure the distribution, count review work as real work, and spread the load on purpose.
The load is bigger than it was a year ago
You don't need a study to see this one, your own MR list will do. When an assistant can produce a working draft of a feature in an afternoon, people produce more drafts. More MRs, and often larger ones, because generated code comes out verbose by default. The team's output chart looks great. What the chart doesn't show is that every extra line lands on a reviewer whose attention is the same finite resource it was before any of this tooling existed.
So review went from a manageable side activity to a real, daily workload. And unlike coding work, nobody planned for it, estimated it, or assigned it. It just gets absorbed. The question is by whom.
It's not absorbed evenly, and you can guess who absorbs it
Review load concentrates, every team that measures this finds the same shape. The senior engineer who knows the whole codebase. The conscientious one who actually reads the diff instead of skimming it. The person whose reviews are so useful that everyone requests them by name. Being a good reviewer is self-reinforcing in the worst way: the better you are at it, the more of it you get.
These are usually your most valuable people, and they're spending a growing slice of their week on work that helps everyone else ship. Which would be fine, that's what senior people are for, if the work were seen. Mostly it isn't.
The performance review blind spot
Think about what feeds into your perf cycle. Features shipped. Projects led. Incidents handled. Maybe commit and MR counts if someone insists on numbers. Now ask: where does "reviewed 240 merge requests this half, caught two incidents before they happened, and taught three juniors the codebase through review comments" show up? On most teams, nowhere.
The incentives this creates are quietly terrible. Your strongest reviewer looks less productive on paper, because every hour in review is an hour not generating the artifacts your process measures. Meanwhile a teammate who declines review requests and pumps out MRs, increasingly with an assistant doing the typing, looks great. You're rewarding the cheap part of the job and taxing the expensive part. People notice. The rational move is to review less, and rational people eventually make it.
The fix isn't complicated, it's just rarely done: pull the numbers. Who reviewed how many MRs, with what turnaround, leaving substantive comments versus a bare approval? GitLab has all of this. Put it next to authorship stats in calibration discussions, mention it in promo packets, and say out loud in team meetings that review is engineering work, not overhead. Visibility changes behavior more than policy does.
Where we sit in this: we build PRFlow, which posts each GitLab merge request to Slack as one updating message, with CI status and review comments synced in. One side effect managers tell us about: when every MR and its review activity is visible in a channel, it becomes obvious who's doing the reviewing and what's sitting unreviewed. You can't rebalance a load you can't see.
What fatigue looks like before anyone says the word
Overloaded reviewers rarely announce it. The signals show up in the work first:
- Approvals speed up while comments disappear. A 500-line MR approved in four minutes wasn't reviewed, it was waved through. Watch for the bare "LGTM" rate climbing.
- Turnaround gets bimodal. Some MRs reviewed within the hour, others sitting for days. That's one person keeping up heroically and then drowning.
- Review requests start orbiting one name. If the same person is on every MR, you don't have a review process, you have a single point of failure with a calendar.
- Quality issues surface in code that was "reviewed". When tired eyes skim AI-generated code that looks polished, plausible-but-wrong slips through. This is exactly the failure mode AI-written MRs are best at producing.
The endgame is worse than slow reviews. The person carrying the load burns out or leaves, and they take the team's deepest codebase knowledge with them. That exit interview will mention "too much glue work". Review was a big part of the glue.
What to actually do
- Measure the distribution first. A half hour with the GitLab API or your analytics tool of choice. You're looking for the spread, not precision: if two people do 60% of reviews, you have your answer.
- Count review work in performance reviews. Explicitly, with the same weight as authored code. If your rubric has "impact through others", review is the most concrete example of it that exists.
- Spread the load on purpose. Round-robin assignment, review pairs, "everyone reviews" norms. Yes, juniors review slower. That's not waste, that's how they stop being juniors.
- Budget for it. If your team merges 40 MRs a week, that's real hours of review work. Plan capacity like it exists, because it does.
- Keep MRs small and reviews fast. Stale reviews cost double: the reviewer has to reload context, and the author has moved on. Whatever shortens the loop, smaller diffs, visible queues, fewer "can someone look at this?" messages lost in Slack scrollback, pays for itself.
Bottom line
Your team's real constraint is no longer how fast people write code, AI took care of that. It's how much careful human attention you have for reading it, and right now that attention is probably concentrated in two or three people you couldn't name off the top of your head and aren't rewarding for it. Find out who they are. Then make sure the system sees what they do, before they conclude it never will.