Decision Fatigue Blunts Code Review Accuracy After 23 Files
The average software developer reviews between 10 and 20 pull requests per week, but the cognitive cost of that scrutiny is rarely measured against the quality of the output. When does the brain stop seeing logic flaws and start seeing what it expects to see? The question is not whether developers get tired, but whether that fatigue produces a measurable, predictable degradation in the ability to catch defects—and if so, where the specific breaking point lies.
The 23-File Threshold: Where Attention Becomes a Liability
In a 2021 analysis of code review velocity across several mid-sized engineering teams, researchers at a large SaaS firm tracked defect-detection rates against the number of files touched in a single review session. The data showed a stark inflection point: when a review request exceeded 23 files, the probability of catching a deliberately injected bug dropped by nearly 40 percent compared to reviews of five to ten files. This wasn't a gradual decline—it was a cliff.
The mechanism isn't mysterious. Working memory has a finite capacity, and code review is a task that demands continuous context switching. Each file opened requires the reviewer to re-establish a mental model of the system, recall the relevant interfaces, and track state changes across boundaries. Beyond a certain volume, the brain begins to offload—not consciously, but through a process of heuristic substitution. The reviewer stops reading the code as a sequence of logical operations and starts pattern-matching against prior reviews, scanning for syntactic anomalies rather than semantic errors.
This is the same cognitive shortcut that Daniel Kahneman and Amos Tversky documented in their work on judgment under uncertainty. When the cognitive load exceeds available processing capacity, System 1 thinking—fast, intuitive, and associative—takes over from System 2's deliberate, analytical mode. In code review, System 1 is excellent at catching a missing semicolon or a misnamed variable. It is terrible at catching a race condition or a subtle off-by-one error in a loop that only manifests under specific load conditions.
The Variable-Ratio Trap in Review Velocity
There's a deeper behavioral layer here that most engineering managers overlook. The decision to approve or request changes on a pull request is not purely analytical—it's a decision under uncertainty, and the brain treats it like one. B.F. Skinner's work on variable-ratio reinforcement schedules is directly relevant: when the consequences of a decision are unpredictable (sometimes a bug slips through, sometimes it doesn't), the reviewer's behavior becomes resistant to extinction. They keep reviewing at the same pace, even as accuracy declines, because the occasional catch reinforces the illusion of vigilance.
In practice, this means a developer who has reviewed 22 files with high accuracy will push through the 23rd, 24th, and 25th files with the same confidence but significantly reduced performance. The subjective experience of "being focused" persists even as objective accuracy collapses. This is why the 23-file threshold is so dangerous—it's invisible to the person experiencing it.
Loss Aversion and the Asymmetry of Review Decisions
Consider the emotional economics of a code review decision. The reviewer faces two possible errors: approving a defective change (a false negative) or rejecting a sound one (a false positive). Kahneman's loss aversion framework predicts that the pain of a missed defect should outweigh the minor social cost of requesting unnecessary changes. But in practice, the opposite often occurs.
A false negative is abstract—the bug might not manifest for weeks, and when it does, the blame is diffused across the team. A false positive, however, is immediate and social: the developer whose code was rejected feels the sting, the reviewer feels the awkwardness, and the conversation becomes a negotiation rather than a technical exchange. The expected emotional cost of a false positive is higher in the moment, even if the long-term cost of a false negative is greater.
This asymmetry shifts behavior in predictable ways as fatigue accumulates. Early in a review session, the reviewer has the cognitive resources to weigh both risks carefully. By file 23, the brain has shifted into a default mode: approve. The status quo bias takes over. It's easier to click "approve" than to articulate a concern, and fatigue amplifies the preference for the path of least resistance.
The Availability Heuristic in Bug Detection
There's also a compounding effect from the availability heuristic. A reviewer who recently caught a security vulnerability in an authentication module will over-index on security patterns in subsequent reviews, scanning for similar issues while missing data-validation bugs that are statistically more common. This isn't incompetence—it's the brain using recent, vivid examples as a proxy for probability.
In a long review session, this heuristic becomes more pronounced. The reviewer's mental model of "what bugs look like" narrows to the most recent examples they've encountered. By file 20, they're not reviewing the code in front of them; they're reviewing a projection of their recent experience. This is why a second reviewer, fresh to the same pull request, often catches issues the first reviewer missed—not because the second is smarter, but because their availability set is different.
The Replenishment Problem: Why Breaks Don't Work as Expected
The obvious countermeasure is to take breaks, but the research on attention restoration suggests that the standard advice—"step away for five minutes"—is woefully inadequate. A study from the University of Illinois on directed attention fatigue found that the brain requires a fundamental shift in cognitive mode to restore executive function. Checking Slack or scrolling through social media doesn't count; those tasks engage the same attention networks that code review does.
What works is a genuine disengagement from goal-directed activity. A walk, a conversation about something non-technical, or even a brief session of mind-wandering while looking out a window. But here's the catch: the restoration curve is not linear. After 45 minutes of continuous review, it takes roughly 15 minutes of true disengagement to restore baseline accuracy. After two hours, the restoration period stretches to 30 minutes or more.
The Interruption Paradox
There's a counterintuitive finding from the same research stream: interruptions, often considered the enemy of deep work, can actually preserve accuracy in long review sessions. When a developer is interrupted mid-review—by a question, a notification, or a meeting—the interruption forces a context switch that resets the attentional state. The reviewer returns to the code with a partially refreshed cognitive buffer.
The problem is that this only works if the interruption is brief and the reviewer doesn't try to resume exactly where they left off. The act of re-orienting to the code—re-reading the surrounding context, re-establishing the mental model—is itself a form of cognitive restoration. The brain treats it as a new task, and the review gains a second wind.
This suggests a practical pattern for engineering teams: rather than encouraging marathon review sessions, structure them with deliberate interruptions. Review 15 files, take a genuine break, then review the remaining files in a fresh session. The total time is roughly the same, but the accuracy curve is dramatically different.
Designing for Decision Quality: A Forward-Looking Approach
The 23-file threshold isn't a law of nature—it's a symptom of a workflow that ignores the cognitive realities of the humans executing it. The path forward isn't to demand more willpower from reviewers but to design the review process around the brain's actual capacity.
Structural Interventions
The most effective change is to enforce a hard limit on review scope. Not a guideline, but a technical constraint. If a pull request exceeds 15 files, the CI system should require a second reviewer or split the review into multiple sessions. This isn't about bureaucracy; it's about recognizing that the error rate beyond that point is a known quantity.
For teams that can't reduce file counts, the alternative is to sequence the review by risk. Review the files with the highest architectural impact first, when attention is fresh, and defer the mechanical files—config changes, test fixtures, documentation—to the end of the session when accuracy matters less. This aligns with the concept of ego depletion in decision-making: the quality of decisions degrades sequentially, so the most consequential decisions should come first.
The Calibration Feedback Loop
Another forward-looking approach is to build a feedback loop that makes reviewers aware of their own accuracy decline. This requires tracking review outcomes over time—not for performance review purposes, but for calibration. A reviewer who can see that their defect-detection rate drops after file 15, based on data from their own history, is in a better position to adjust their behavior.
This is analogous to the calibration training used in weather forecasting and medical diagnosis, where professionals are shown their accuracy rates across different conditions to improve their judgment under uncertainty. The goal isn't to shame reviewers for fatigue; it's to make the invisible visible. When a developer knows that their probability of catching a subtle bug drops by a third after reviewing 20 files, they can make an informed decision about whether to push through or to hand off the remaining files.
The Role of Automated Pre-Screening
There's also a technological angle that reduces the cognitive load of the review itself. Static analysis tools, linters, and type checkers can catch the mechanical errors that System 1 is good at, freeing the reviewer's attention for the semantic errors that require System 2. The key is to configure these tools to be aggressive enough that the reviewer can trust them—if the linter catches 90 percent of style issues, the reviewer can stop looking for them.
This isn't about replacing human judgment; it's about preserving it for the decisions that matter. The reviewer's cognitive budget is finite, and every mechanical check they perform manually is a resource taken away from the logical analysis that actually prevents production incidents.
The Broader Implication: Cognitive Budgeting as a Core Competency
The 23-file threshold is a specific instance of a general principle: every knowledge worker has a finite cognitive budget, and the quality of their output is directly tied to how that budget is allocated. The teams that will thrive in the coming years aren't the ones with the most brilliant developers—they're the ones that treat attention as a scarce resource and design their processes accordingly.
This means rethinking the entire review workflow, not just the file count. It means questioning whether synchronous reviews are necessary when asynchronous reviews allow for natural cognitive resets. It means considering whether the review should happen in multiple passes—one for architectural correctness, one for implementation details, one for style—rather than a single pass that tries to do everything at once.
The evidence from behavioral economics and cognitive psychology is unambiguous: decision quality degrades with fatigue, and the degradation is predictable and measurable. The question isn't whether your team is affected—it is. The question is whether you've designed the workflow to account for it.
The teams that acknowledge this reality and build their processes around it will see fewer production incidents, faster review cycles, and higher developer satisfaction. The teams that continue to pretend that willpower can overcome cognitive limits will keep hitting the 23-file cliff, wondering why their best reviewers miss the bugs that their junior engineers catch on the second pass.