A Slack message appears: “Can you review this PR when you get a chance?” It seems harmless. The PR is small – maybe 150 lines. You stop what you are doing, open the pull request, read through the changes, leave a few comments, and go back to your task. Total time spent reviewing: fifteen minutes. Total time lost: closer to an hour.
The fifteen minutes of review time is visible and measurable. The forty-five minutes of context recovery is invisible and almost never accounted for. This is the real cost of context switching in code review, and it is one of the most expensive hidden taxes on engineering productivity.
The twenty-three minute problem
Research on task switching consistently shows that it takes a significant amount of time to return to the same level of focus after an interruption. The frequently cited figure is twenty-three minutes, though the actual recovery time varies by task complexity and individual. For cognitively demanding work like writing code, debugging, or designing architecture, the recovery time can be even longer.
Code review is particularly disruptive because it requires loading a different mental model. When you are writing code, you are holding a model of your current module, its dependencies, and the change you are making. When you switch to reviewing someone else's code, you need to load their module, their dependencies, and the change they made. These are two entirely different mental contexts.
After completing the review, you need to reload your original context. What was I working on? Where was I? What was the next step? The answers are not immediately accessible. You need to re-read your own code, recall your intent, and rebuild the mental model you were holding before the interruption.
A developer who is interrupted four times in a day for code reviews may spend an hour doing reviews and two hours recovering from them. That is three hours – nearly forty per cent of productive time – consumed by a process that most teams consider a minor overhead.
The false economy of quick reviews
Teams often respond to the context-switching problem by encouraging “quick reviews.” Keep PRs small. Review fast. Get back to your work. This sounds reasonable, but it creates a different problem: shallow review.
A reviewer who is trying to minimise disruption to their own work has a strong incentive to skim rather than read carefully. They look for obvious errors – syntax issues, missing null checks, formatting violations – and approve. The subtle problems slip through: a race condition, an inconsistent error handling pattern, a security assumption that does not hold in all contexts.
Quick reviews are not fast. They are incomplete. The bugs they miss create production incidents, debugging sessions, and hotfixes that cost far more than the review time that was saved. The economy is false because it measures the cost of the review but not the cost of the defects the review failed to catch.
The incentive structure is backwards. Developers are rewarded for reviewing quickly (the team velocity metric looks good) and not punished for reviewing shallowly (the bugs from missed issues are attributed to the code author, not the reviewer). This creates a systematic bias towards faster, less thorough review.
Synchronous review as a default assumption
Most teams treat code review as a synchronous process by default. A PR is opened. A reviewer is assigned. The reviewer is expected to respond within hours. The author waits. If the reviewer is slow, the author moves on to another task, creating yet another context switch when the review comments arrive.
This synchronous assumption is inherited from co-located teams where you could tap a colleague on the shoulder and ask them to look at something. It made sense when the entire team was in the same room and context switches happened naturally at shared break points.
It makes far less sense for distributed teams across multiple time zones, where a review request sent at 10am in London arrives at 2am in San Francisco. The synchronous model forces either long wait times (the reviewer responds the next day) or disruptive interruptions (the reviewer responds immediately, at the cost of their own deep work).
The synchronous model also creates a bottleneck. The senior developers who have the most context and are best positioned to provide thorough reviews are also the developers whose deep work is most valuable and most expensive to interrupt. Making them the default reviewers for every PR creates a perverse trade-off: better reviews at the cost of worse productivity from your most experienced engineers.
Batching review as a strategy
The alternative to synchronous, interrupt-driven review is batching. Instead of reviewing PRs as they arrive, dedicate specific time blocks to review work.
A developer might block out 9am to 10am for code reviews. During that hour, they review all pending PRs. Outside that window, review requests accumulate but do not interrupt. The context switch happens once (from their own work to review mode) rather than four or five times throughout the day.
Batching has several benefits. First, a single context switch per day is dramatically cheaper than multiple switches. Second, reviewing multiple PRs in sequence allows the reviewer to maintain a review mindset – they are looking for patterns, inconsistencies, and quality issues across multiple changes, not just within one. Third, dedicated review time encourages thoroughness because the reviewer is not trying to minimise the interruption.
The concern with batching is latency. If reviews only happen once per day, PR authors might wait up to twenty-four hours for feedback. For some teams, this is unacceptable. For most, it is a better trade-off than the alternative. A twenty-four hour review cycle with thorough feedback is more productive than a two-hour review cycle with shallow feedback that requires multiple rounds of revision.
Teams that adopt batching often find that their total review throughput increases even as latency goes up. This is because the time previously lost to context switching is recovered as productive work.
Async review artefacts
Batching works best when reviews produce artefacts that can be consumed asynchronously. A set of inline comments on a PR is one form of async artefact. A structured report is another.
The difference matters. Inline comments require the author to read through the PR diff, visiting each comment in context. This is a form of synchronous review in disguise – the author must reconstruct the reviewer's mental path through the code. A structured report, by contrast, groups findings by category and severity, making it possible for the author to process them in any order during their own dedicated time.
Full codebase review tools take this further. Instead of reviewing individual changes one at a time, a full codebase review analyses the entire project and produces a comprehensive report. This report is an artefact that can be consumed by anyone on the team at any time, without requiring the reviewer to be present or the reader to reconstruct context from inline annotations scattered across dozens of files.
VibeRails generates reports that are designed as batch-friendly artefacts. Findings are grouped by category, sorted by severity, and include the relevant code context inline so that readers do not need to switch between the report and the editor. The report can be reviewed during a dedicated time block – no interruptions, no context switching, no back-and-forth with a reviewer who may be in a different time zone. The team reads the report, triages the findings, and plans the work in a single session.
Measuring the hidden cost
If you want to understand the real cost of context switching on your team, run a simple experiment. For one week, ask each developer to note every time they switch from their own work to review someone else's code, and how long it takes them to feel fully re-engaged with their original task afterwards.
Most teams find the results surprising. The total time spent in review is modest – perhaps five to eight hours per developer per week. The total time spent recovering from review interruptions is often equal to or greater than the review time itself. Combined, review-related work and the associated context-switching overhead can account for twenty to thirty per cent of a developer's week.
This is not an argument against code review. Code review is essential. It catches bugs, spreads knowledge, and maintains quality standards. The argument is against review processes that maximise interruptions and minimise focus. Batching, async artefacts, and dedicated review time can preserve the benefits of review while dramatically reducing the productivity tax.
The best review process is one that produces thorough, actionable feedback without requiring anyone to stop what they are doing, load a different mental model, and then spend twenty minutes trying to remember what they were working on before the Slack message arrived.
Limits and tradeoffs
- It can miss context. Treat findings as prompts for investigation, not verdicts.
- False positives happen. Plan a quick triage pass before you schedule work.
- Privacy depends on your model setup. If you use a cloud model, relevant code is sent to that provider; local models can keep inference on your own hardware.