Code review is cognitive work. Reading unfamiliar code, holding it in working memory, evaluating its correctness against a mental model of the system -- these activities deplete the same attentional resources as debugging, system design, and incident response. When those resources are exhausted, review quality drops.
Review fatigue is real, measurable, and routinely ignored in engineering process discussions. It is especially acute in async teams, where the temporal distribution of work creates patterns that synchronous teams don't face in the same way.
How Async Work Patterns Create Fatigue Accumulation
In a co-located team, review requests arrive with some natural rhythm tied to working hours. Engineers submit PRs during the day; reviews happen during the same window. There is implicit social calibration -- reviewers can signal when they're overwhelmed, authors can hold a PR until a reviewer has bandwidth.
In a distributed async team, the rhythm breaks. A team spanning San Francisco, London, and Singapore has engineers producing code around the clock. A reviewer in London waking up to 6 PR review requests -- submitted while they slept by colleagues in Singapore and the US West Coast -- faces the full backlog immediately, before any other work has filtered in to create natural priority ordering.
The worst case is not a single day of high volume. It is the accumulation pattern: a reviewer who handles a heavy Monday backlog isn't recovered by Tuesday when the backlog has partially refilled from overnight submissions. Over two or three weeks, chronic partial recovery produces degraded baseline review quality even on days when volume is moderate.
What Review Fatigue Looks Like in Practice
Fatigued reviewers don't usually write worse feedback in ways that are immediately obvious. The degradation is more subtle:
Attention shifts to surface issues. Checking style consistency and naming conventions requires less cognitive load than evaluating correctness. Fatigued reviewers spend more time on style issues and less time on logic issues. The review looks thorough -- it has a lot of comments -- but it isn't catching the things that matter.
Late-PR sections receive less scrutiny. In a long PR, reviewers who are already tired when they start the review dedicate decreasing attention as they progress. The end of a large diff gets a faster pass than the beginning. If the most consequential change is in the last modified file, it is the one most likely to be approved without careful reading.
Familiarity bias intensifies. Fatigued reviewers default more heavily to "this looks like how we usually do this," which is correct for standard patterns but misses the cases where a standard-looking pattern is being applied in a non-standard context. Novel issues look normal to a tired reviewer.
Automation Is Not a Substitute for Rest, But It Changes What Rest Is Required For
The instinct when facing review fatigue is to add more reviewers or require fewer approvals. Adding reviewers distributes load but doesn't change the total cognitive work required to review the codebase -- it just spreads it more thinly. Reducing required approvals reduces load but also reduces coverage.
The more effective intervention is to change what human reviewers are required to do. Most of the cognitive work in a PR review falls into two categories: mechanical verification (does this code do what it says?) and semantic evaluation (is this the right approach, given everything we know about the system?).
Mechanical verification -- null checks, error handling, basic type safety, test coverage gaps -- can be handled by automated analysis that runs before human review begins. When reviewers receive a PR that has already had mechanical verification applied, they can focus their attention on semantic evaluation: is the architecture sensible? Does the abstraction hold up under the edge cases this codebase will encounter? Is there a simpler way to achieve the same result?
That shift doesn't eliminate cognitive load. Semantic evaluation is demanding. But it is a more sustainable use of engineering attention than spending the same budget on mechanical checks that automation can perform consistently and without fatigue.
Practical Changes That Help Async Teams
Review windows instead of immediate response expectations. Defining explicit review windows -- "reviews happen in the first two hours of the workday" -- allows reviewers to batch reviews and plan attention allocation. This is more cognitively efficient than interrupting other work to handle reviews as they arrive.
PR size limits with enforcement. Async teams that cap PR size at 200-300 lines of changed code report significantly lower reviewer burnout, independent of total review volume. The reduction in per-PR cognitive load matters more than the reduction in total review count.
Clear mechanical review before human review. Whether through Mergegleam or another automated tool, running a structural review pass before PRs enter the human review queue means reviewers are not duplicating work the tool already does. The comment "you're missing a null check on line 47" should come from the tool, not from the reviewer who could be evaluating the overall design instead.
Rotation calibrated to time zone, not just headcount. Reviewer rotation systems that assign reviews without regard to the reviewer's time zone create the backlog accumulation problem above. Routing reviews to the reviewer who will see them first in their active hours -- even if that means some reviewers see more of certain PR types -- reduces the overnight pile-up that drives morning overload.
Review fatigue is a process problem, not a motivation problem. Engineers who produce tired reviews aren't cutting corners by choice. The process has structured them into a position where thorough review of every PR is not sustainable. Automation handles a consistent share of the mechanical work, and process changes handle the load distribution; together they give human review capacity back to the work that actually requires it.