Review fatigue has a specific pattern that engineering managers eventually learn to recognize: a senior engineer who used to write detailed, thoughtful review comments starts approving PRs with a single "LGTM." Not because the code quality improved. Not because the PR is trivial. Because they're reviewing their twelfth PR that day and their capacity for careful attention has been depleted.
This isn't a character flaw. It's a predictable outcome of a system that asks a small number of people to maintain a high-attention cognitive task across too many instances per day. Code review requires sustained attention. Sustained attention is a limited resource. When the demand for reviews exceeds the available attention budget, quality degrades — not all at once, but in ways that are invisible in individual reviews and only apparent in aggregate when you start tracking post-merge defect rates and rollback frequency.
The attention budget problem
Researchers studying knowledge work have characterized high-attention tasks — those requiring active reasoning rather than pattern matching — as sustainable at roughly 3–4 hours per day before meaningful quality degradation. Code review for non-trivial changes clearly falls in this category. Catching a subtle logic error in a concurrent data structure, or recognizing that a new service is duplicating functionality that exists in a different module, requires the kind of active reasoning that fatigues.
When we look at review throughput and review quality data together — using post-merge defect rates as a quality proxy — a consistent pattern emerges: senior engineers reviewing more than 8–10 PRs per day show elevated defect escape rates on the PRs they reviewed compared to their own baseline on lower-review-volume days. The number is the problem, not the reviewers.
This matters for engineering managers because it means that "add more review capacity" through hiring doesn't necessarily solve the problem if the underlying distribution of review work remains concentrated. You can hire 10 new engineers and still have the same 4 senior engineers bottlenecking critical-path reviews, because CODEOWNERS and institutional knowledge don't redistribute automatically with headcount.
What review fatigue looks like in practice
The surface signs are familiar: LGTM approvals without substantive comments, review threads that trail off without resolution, growing comment thread backlogs, senior engineers who have become "review avoiders" — they look at their notification count and close the tab.
The less visible signs: attrition from engineers who joined specifically because of the technical culture, and who leave when they see that the review process has become a formality. Growth engineers who were supposed to learn from detailed review feedback aren't getting it. Architectural drift that would have been caught in review is being caught in production instead.
An engineering organization at around 250 engineers ran an internal retro on a sprint where they'd shipped two significant production incidents. Tracing the incidents back through the review history, both had received LGTM approvals from a senior engineer who had done 14 reviews that day. The code wasn't obviously bad — the issues were subtle enough that a fresh reviewer would have needed to read carefully. But a fatigued reviewer pattern-matches to "this looks reasonable" and moves on.
Why this is a system problem
Individual engineers can't solve this by trying harder. Asking a reviewer to "be more careful" when they're doing 12 reviews per day is asking them to exceed their sustainable attention budget through willpower — which works for a week and then collapses.
The system creates the problem in a few structural ways:
- Undifferentiated review queues: Every PR in the queue is treated as requiring the same type of attention. A 5-line variable rename and a 400-line service refactor sit in the same review list. There's no mechanism to triage which items require deep review and which are routine.
- Review concentration via CODEOWNERS: CODEOWNERS files accumulate required-reviewer paths over time as the organization grows. Pruning them requires explicit effort and institutional knowledge of which ownership rules are still serving their purpose. They tend to grow and never shrink.
- No attention-weighted scheduling: GitHub and GitLab present reviews in chronological order or via alphabetical assignment. Neither system knows that Engineer A has already done 9 reviews today. Reviewer assignment ignores current load.
- Review noise from automation: If automated tools are posting comments at high volume with low signal quality, reviewers add "read the automated comments" to their cognitive task list. When the automated comments are mostly noise, reviewers learn to skip them — but they're still spending attention deciding to skip them.
What engineering managers can actually change
We're not saying fatigue can be completely eliminated — code review will always require attention. We're saying the system can be redesigned to concentrate human attention where it produces the most value.
Triage the review queue: Not all PRs need the same depth of review. PRs touching non-critical paths, small in scope, and authored by experienced team members can go through a lighter review process. PRs touching critical infrastructure, crossing service boundaries, or touching data models should get deeper review. This isn't about lowering standards — it's about directing limited attention appropriately.
Automate first-pass review: When an automated tool handles convention checks, style consistency, and common pattern issues before a human reviewer sees the diff, the reviewer's attention is freed from those tasks entirely. They open the PR, see that the automated layer has already resolved the routine surface area, and can focus on architecture and correctness. The average review time for convention-heavy PRs in teams using automated pre-triage is 30–40% lower than in teams without it.
Prune CODEOWNERS aggressively: Run a quarterly audit of which CODEOWNERS paths actually required input from the required reviewer in the past 90 days. Paths where the required reviewer approved in under 5 minutes with no substantive comments are candidates for either removal or replacement with a broader team ownership group. This won't feel safe — the instinct is to keep senior engineers on critical paths as a safety net. But a fatigued senior engineer on the path is less protection than a fresh mid-level engineer who has been given actual context on why that code is important.
Load-balance reviewer assignment: If your tooling supports it, route reviewer assignments based on current review load rather than static assignment. Engineers who have done 10+ reviews today should be lower priority for new assignments. Engineers who haven't reviewed anything today should be higher priority, assuming they have the relevant context.
The attrition risk that doesn't get tracked
Review fatigue has a downstream effect that doesn't show up in any cycle time dashboard: attrition of the exact engineers whose review judgment you most need. Senior engineers who are burning out on review volume are also the engineers with the most institutional knowledge and the highest replacement cost.
Exit interview data from engineering organizations rarely names "too much code review" as a primary reason for leaving. But when you track the review load of engineers who resigned in the past year and compare to the org average, the correlation is consistent: the engineers who were doing the most reviews were leaving at above-average rates. That's a signal worth paying attention to before the exit interviews start.
The fix path is system design, not individual resilience. Distributed review load, automated triage of routine issues, and CODEOWNERS hygiene are engineering process decisions, not requests for engineers to try harder. The question for engineering managers is whether those decisions are being made deliberately, or whether the review system is being designed by accumulation.