Review fatigue and rubber-stamping at volume

A senior engineer opens her review queue on a Tuesday and finds nineteen pull requests waiting. Four are hers to review as the only person who knows that subsystem. The rest are spread across the team but she is on the default reviewer list, so they landed on her anyway. Three are marked urgent. Two are from a colleague who is blocked and has asked twice in chat.

She has roughly ninety minutes before her first meeting.

There is no version of the next ninety minutes in which nineteen pull requests get a real review. She knows this. She is not going to send a message saying “I cannot do this,” because that message has no obvious recipient and the honest answer would be that the team needs to slow down, which is not a thing an individual can decide. So she does what any competent professional does when handed an impossible queue: she triages, and she optimises.

She reads all nineteen descriptions. She opens the diffs for the four she owns and reads two of them carefully. She approves eight on the strength of the description, the tests passing, and who wrote them. She leaves comments on three, mostly style, because leaving a comment is evidence of engagement and takes ninety seconds. She lets four sit.

At the end of the week, her review count is high, her median time to first response is excellent, and eight changes went into production having been read by nobody.

She did not decide to rubber-stamp. She was handed a workload with no correct solution and found the least-bad one available to her.

19 pull requests waiting        90 minutes available
4  owned, only person who knows the subsystem
2  read carefully
8  approved on description + green tests + trust
5  left for tomorrow
Week’s numbers:  review count high
time to first response excellent
changes read by nobody: 8

The queue is a system output, not a personal failing

Almost every conversation about review quality frames it as an individual behaviour: reviewers should be more thorough, reviewers should push back more, we need a culture of rigorous review.

I think that framing is close to useless, because it puts the fix in the hands of the person with the least control over the cause. The queue length is not something a reviewer chooses. It is determined by how many changes the team produces, how they are distributed, how many people are eligible to review each one, and how much protected time reviewers have. A reviewer can control exactly one variable: how much attention each change gets. So when the queue grows, that is the only variable that can move, and it moves.

This is why exhortation fails so reliably. Telling the engineer in that scene to review more carefully is telling her to make the queue longer, which she correctly perceives as making things worse for her colleagues. She is not choosing speed over quality out of indifference. She is resolving a conflict between two things the organisation wants, using the only lever she has, and she is resolving it in the direction the organisation actually rewards.

If you want to know what an organisation truly values, look at what happens to someone who lets a review sit for four days versus what happens to someone who approves something that later breaks. In most places the first is visible and immediate and the second is diffuse and weeks later. The incentive is not subtle.

Rubber-stamping does not look like rubber-stamping

The reason this failure mode persists is that it produces no artefact that distinguishes it from real review.

An approval from a careful two-hour read and an approval from a forty-second skim are the same object. Same button, same record, same green tick. The audit trail says reviewed either way. There is no field for “how much of this did you actually look at,” and if there were, nobody would fill it in honestly.

Worse, the observable metrics improve as review quality degrades. Time to first review goes down. Time to merge goes down. Review throughput goes up. Approval rate goes up. Every number on the engineering effectiveness dashboard moves in the direction that gets celebrated in the quarterly review. A team whose review process has completely hollowed out looks, on paper, like a team that has got dramatically better at collaboration.

I find this genuinely one of the more insidious dynamics in modern delivery, because the feedback loop is not merely absent, it is inverted. The degradation is rewarded. And the correction, when it eventually arrives, arrives as an incident with a specific cause that gets a specific fix, and the review process is never named, because there is no data pointing at it.

The comment that costs nothing

There is a specific behaviour worth naming because it is so common and so quietly corrosive: the participation comment.

A reviewer under time pressure knows that a bare approval looks thin, and that leaving a comment signals engagement. So they leave one. It is almost always about something surface-level, because surface-level things are the ones you can find in ninety seconds: naming, a missing comment, a slightly awkward conditional, a suggestion to extract a function.

The comment is not bad. The suggestion is usually correct. And it is entirely disconnected from whether the change works.

This is worse than a bare approval in one important way: it creates evidence of scrutiny. Six months later, when someone is investigating how a defect got through, they will find a pull request with review comments on it and conclude it was reviewed. The comment made the review look real without making it real, and it did so accidentally, by a person acting in good faith.

If you want a cheap diagnostic for review health on your own team, go and read a random sample of thirty review comments from the last month and classify them: does this comment engage with whether the change is correct, or with how the change is written? A healthy ratio is not 100 percent correctness comments, because style comments have real value. But if it is running at nine to one toward style, your reviews are decorative.

Volume is the variable, so treat it as one

If review quality is a function of queue length, and queue length is a system property, then the interventions that work are the ones that change the system, not the ones that ask reviewers to try harder. A few that hold up.

Reduce the number of things that need a human review at all. This sounds like heresy in a piece about review quality, and it is the single highest-yield move available. A meaningful share of any team’s pull requests are mechanical: dependency bumps, generated code, formatting, config with narrow blast radius, changes confined to test files. If those are consuming a third of your review capacity, that capacity is being spent on the changes least likely to hurt you. Route them differently, whether that is automated checks, a lighter approval path, or batching. The goal is to make the queue smaller so that what remains can be read properly.

Make the queue’s shape visible. Nineteen pull requests is not one number, it is a distribution: some high-risk, some trivial, some blocking a colleague, some fine to sit for a week. Reviewers triage this in their heads, badly, with incomplete information. Anything that surfaces the risk profile of the queue, which changes touch sensitive paths, which have unmet acceptance criteria, which have been sitting longest against a real dependency, converts a guess into a decision. This is one place where automated risk scoring genuinely helps, because it is not making a judgement call, it is ordering the work so the human judgement lands where it matters.

Give review protected time and count it as work. Almost nobody does this. Review is treated as an interstitial activity, done between the real work, which guarantees it gets whatever attention is left over. Teams that block time for it and treat review load as capacity consumed, rather than as free, get noticeably better outcomes, and the reason is not moral. It is that they stopped pretending an hour a day of review was zero hours.

Cap work in progress upstream. The most unpopular one. If the constraint on your system is review capacity, generating more changes does not increase throughput, it increases queue depth, which degrades review quality, which pushes defects downstream where they cost more. This is standard queueing theory and it has been true since long before agents. What agents changed is that the upstream generator no longer has a natural rate limit, so the queue can now grow without anyone deciding to grow it.

The thing that actually scares me

There is a second-order effect here that I think is underdiscussed.

When review becomes unreliable, teams notice. Not consciously, but they adapt. Authors start caring less about whether a change is reviewable, because it is not going to be read closely anyway. Descriptions get thinner, or they get longer and more generic. The implicit contract, “I will make this readable and you will read it,” decays on both sides at once.

That decay is much harder to reverse than the queue problem that caused it, because it lives in norms rather than in a number. You can fix a queue in a sprint. Rebuilding a team’s belief that review is a real quality gate takes considerably longer, and it usually requires an incident bad enough to make the case for you.

So the argument for addressing review load early is not mainly about the defects that slip through this month. It is that review quality is a norm with hysteresis, and it is far cheaper to protect than to restore.

Where this breaks down

Several places, and the first is the one I would most want to be argued with on.

Deep review may simply not be the right control any more. I have written this piece assuming that thorough human review of each change is the goal and that failing to achieve it is a loss. That assumption deserves challenge. Review is an extremely expensive control with mediocre measured effectiveness even in its healthy form, and there is a serious argument that at high change volume the right response is not to protect review but to shift the quality budget elsewhere entirely: to stronger automated verification, to better observability and faster rollback, to progressive delivery where the blast radius of any single change is small enough that being wrong is cheap. A team that can revert in ninety seconds and detect a regression in five minutes may rationally accept much shallower review than a team shipping monthly to an on-premise install. Fighting to preserve a control that was designed for a different change rate may be nostalgia dressed as rigour.

Some rubber-stamping is correct triage, not failure. The engineer in the opening scene approved eight changes on thin evidence. If those eight were low-risk changes with easy rollback, that was a good decision, not a degraded one. Her mistake, if she made one, was not that she skimmed, it is that she had no reliable way to know which of the nineteen deserved the skim. Attention is finite and spending it unevenly is the whole point. The failure is unaimed skimming, not skimming.

Making review heavier can reduce total quality. If you successfully impose deeper review without reducing volume, the queue grows, changes sit longer, batches get larger, and larger batches are harder to review and riskier to deploy. You can absolutely make things worse by improving review rigour in isolation. The interventions that work are the ones that change volume or routing; the ones that only change expectations tend to backfire.

And the metrics critique cuts both ways. I complained that review metrics improve as quality degrades. It is equally true that there is no good metric that improves as quality rises. Review depth is not measurable in any way I trust, and anything you start measuring, comment counts, review duration, will be gamed within a month, probably unconsciously. I would be suspicious of any tool, including ours, that claims to measure review quality directly. The honest offer is to reduce and order the queue, not to score the reading.

The takeaway

Rubber-stamping is not a character flaw and it is not fixed by asking for more rigour. It is the rational output of a system where change volume grew by an order of magnitude, review capacity did not, and every visible metric rewards clearing the queue rather than reading it.

The interventions that work operate on volume and routing: fewer things needing human eyes, a queue whose risk profile is visible so attention lands where it matters, review counted as real capacity rather than free time. And it is worth genuinely considering whether some of your quality budget should move out of review altogether, toward the controls that make being wrong cheap.

The next piece looks at what happens when you succeed at the thing this series keeps recommending, when you write acceptance criteria precise enough to check, and an agent satisfies every one of them while missing the point entirely.