Code review burnout: the concentration problem and how to fix it

Code review burnout has a shape, and it is not evenly distributed. On most teams a small share of engineers does most of the reviewing, quietly and without a line item anywhere. They are the people whose approval everyone wants, whose queue never empties, and whose calendars absorb the cost. When they wear out, the failure is silent: reviews slow down, then hollow out, and the team discovers the problem months later as a quality regression nobody can quite date.

The concentration problem

Review load pools around expertise. The fastest, most useful reviews come from the people who know the code best, so assignment tools and human habit both route requests to them, and every good review earns them the next one. Open source shows the extreme version: maintainers of popular projects field unbounded inbound from an unbounded contributor pool, and maintainer burnout is a documented, recurring reason projects stall. Company teams run the same dynamic at smaller scale. Microsoft’s research on modern code review found that understanding the code is the central challenge reviewers face; that kind of comprehension work does not parallelize, does not survive fatigue, and cannot be delegated to whoever happens to be free.

AI multiplied the volume

Whatever equilibrium teams had, assistants broke it. Code generation got dramatically cheaper; careful reading did not. Addy Osmani’s agentic code review essay collects the numbers behind that asymmetry, and we have written about the resulting review bottleneck before: when authoring accelerates and review does not, the queue grows in front of exactly the people already carrying the most of it. The concentration problem and the volume problem multiply rather than add: the deeper queue lands on the same few desks, so the reviewers most likely to burn out are precisely the ones the new volume finds first. Burnout risk is no longer a culture nicety. It is the constraint on how much of that new volume a team can safely absorb.

The signals of code review burnout

Fatigued reviewers rarely announce it; the metrics whisper it first. Three signals, all trends rather than incidents:

• Rising latency. Google’s norm of responding within one business day makes a useful baseline: when a previously prompt reviewer drifts from hours to days, something is being traded away.
• Rubber-stamps. Approvals that arrive faster than the diff could be read are fatigue wearing a productive costume: the ritual continues after the attention has run out.
• Avoidance. Requests reassigned, snoozed, or left until the author gives up and finds someone else. Reviewers almost always protect themselves quietly before they ever complain out loud.

SmartBear’s peer review research gives the physiological floor under all three: review effectiveness drops after about an hour, which is why a reviewer running back-to-back sessions all day is not doing eight hours of review. They are doing two, spread thin across eight.

Fix one: rotate the load

The structural fix is to stop letting assignment follow the path of least resistance. Deliberate reviewer assignment spreads requests past the two obvious experts: round-robin within an ownership area, pairing a primary expert with a secondary learner, and load caps that make it normal to say a queue is full. Rotation costs something real, because the less familiar reviewer is slower at first. That cost is the investment: every rotation grows the pool of people who can review that code, which is the only durable cure for concentration.

Fix two: capacity honesty and tiers

Rotation redistributes the load; it does not shrink it. The second fix is admitting that review capacity is finite and budgeting it like anything else that is finite, which is the argument of review capacity planning: count the review hours the team actually has before committing to the volume it will absorb. Then spend those hours unevenly on purpose. A dependency bump with green CI does not need the same scrutiny as a change to the payment path, and pretending it does is how the payment path ends up reviewed by someone running on fumes. Tiered rigor is not lowered standards; it is standards applied where mistakes are expensive, by reviewers still fresh enough to enforce them.

One more fix deserves a mention because it costs nothing: make review work visible. Most teams can name their top reviewers but have never counted their review hours, because the work happens between the tasks that get tracked. Put review load on the same dashboard as everything else. A reviewer carrying triple the median load is either a staffing decision the team should make on purpose or a slow-motion resignation letter, and the difference is whether anyone is looking.

Burnout in review is a systems failure that presents as a personal one. The reviewer who got slow and cranky is downstream of an assignment graph that funneled everything through them and a plan that never counted their hours. Fix the graph and the budget before the exit interview does it for you, and the people, given an honest workload, tend to recover on their own.