Interrupt-Driven Engineering and the Cost of Codebase Questions

Engineering onboarding improves when new hires can query the whole codebase independently. Interrupt-driven engineering is a structural problem rooted in unequal access to codebase knowledge. Making that knowledge searchable for engineers, non-engineers, and AI agents reduces the human dependency behind interruptions and the recovery, mentoring, and review costs that follow.

Why codebase questions keep falling on the same people

A workplace chat ping breaks an afternoon of engineering work with a question about how a feature behaves. The person asking reasonably needs an answer. Yet the route to that answer reveals a structural dependency. Knowledge of the codebase sits with a few senior engineers, while everyone else can reach it only by asking them. Questions therefore cascade upward by seniority, toward the people most likely to know and least able to spare the time.

The requests arrive from across the organization. Product management asks about feasibility and effort, security and compliance teams raise audit requirements, and sales and customer success need explanations of technical capabilities. Executive leadership needs to know the risks, while other engineering teams need to understand the dependencies. These questions require different kinds of attention, but the codebase questions within them share a bottleneck. When the relevant behavior cannot be found independently, a human must retrieve and explain it before anyone else can proceed.

Growth makes this dependency harder to escape. As the codebase expands, its relationships become more complex and more knowledge accumulates outside anything colleagues can search. Technical debt adds to this work because engineers must explain why earlier decisions were made as well as how the code behaves now. AI coding assistants can increase the volume of code faster than the organization develops ways to understand it. A more considerate communication style may change how a question arrives, but it cannot supply the missing knowledge, so the system keeps producing interruptions.

What a single interruption actually costs the interrupted engineer

The visible interruption is only the first cost. To do their work, engineers need a mental model that keeps architecture, problem logic, edge cases, and interdependencies in working memory at the same time. An engineer thinking through a change needs to keep those relationships in mind while deciding what to do next. A question about another part of the system does not simply pause that model. It displaces the context needed to continue, leaving the engineer to reconstruct it after the answer has been given.

Recovery is work in its own right. The engineer must recover not just the file being edited, but the reasoning that made the next step sensible. Fragmented flow also reduces creativity and increases the risk of errors, so the loss cannot be expressed solely as minutes away from the original task. Duke and Vanderbilt research found that interruptions significantly increased time spent on code comprehension and code review. The research also found that people reported more stress after in-person interruptions, though physiological stress measures told a different story.

Checking a message without being prompted can impose a burden similar to an external interruption, because the change of context creates the burden. A brief exchange can be complete while its effect on concentration continues. Standard engineering dashboards leave out the work of rebuilding a mental model, so the time it takes to recover goes uncounted in the usual record of completed work.

How the cost compounds when the same engineers absorb interruptions at scale

Repeated interruptions prevent recovery from reaching its endpoint. If another question arrives before the engineer has rebuilt the original context, it resets an unfinished recovery cycle. Multiple stakeholders intensify the effect when the same senior engineer answers the same conceptual question in five separate conversations. Each requester sees a short interaction, while the engineer absorbs the sequence.

The slowdown then spreads through the team. Junior engineers who depend on that senior engineer’s guidance may be stalled while the person they need is answering questions elsewhere. The organization loses both the senior engineer’s uninterrupted work and the progress that their availability would have enabled. Pressure to compensate for that lost time increases the risk of compromised code quality, bugs, and accelerating technical debt.

Measures of how much work gets done can hide how little progress the team makes. Sabry E. Farrag’s May 2026 paper, The Productivity-Reliability Paradox, from the University of East London, documents a sharp increase in merged pull requests under large-scale AI adoption, together with a 91% increase in review time and flat organizational delivery metrics. That finding concerns AI adoption.

Sustained fragmentation also erodes morale and job satisfaction. Engineers who keep getting interrupted may eventually make themselves harder to reach so they can focus, but the questions still need answers. Those questions move to other senior engineers, restarting the same cycle. Burnout and reduced availability are consequently capacity constraints. Time spent recovering, waiting for guidance, and dealing with pressure to fix rushed work still has a cost, even when it appears nowhere in the engineering budget.

Why new hire onboarding is where the structural cost becomes impossible to ignore

Engineering onboarding concentrates this daily dependency into a sustained demand. A new engineer who cannot navigate the codebase independently needs repeated help from someone who already understands it. That support can consume a large fraction of one or more senior engineers’ weeks for months. Unlike an occasional stakeholder question, the need is both continuous and difficult to defer without delaying the new hire’s progress. The same knowledge bottleneck now affects the productivity of the person learning and the person teaching at once.

Codebase opacity sets the mentoring burden directly. A well-documented greenfield service may require a modest share of a senior engineer’s time, while a legacy monolith shaped by tribal knowledge can require the majority of it. A senior engineer who spends 15–20 hours per week mentoring has much less time for their own work. That is senior engineering capacity consumed by onboarding, even when the hiring budget records only the new employee’s salary.

The sharper measure is arrival at net-positive contribution. A new hire remains a net cost to the team until the value they deliver exceeds the senior time needed to support them. New hires may still need so much explanation and guidance to finish their first tasks that their work costs the team more than it adds. Every week of delay includes both salary during ramp and the senior capacity needed to sustain it. Codebase complexity and team structure therefore make a universal onboarding timeline misleading, especially when comparing a legacy monolith with a well-documented greenfield codebase.

Non-engineering onboarding exposes an even narrower route to understanding. New PMs, support staff, and analysts may have no codebase access at all, even though their work requires knowing what the product does. To understand a feature, trace a bug report, or check a technical claim, they then have to ask engineering for help. Onboarding reaches its structural limit when increased experience still leaves a person dependent on an engineer for every codebase answer.

Why AI coding tools, as currently deployed, do not reduce the interrupt load

An AI coding tool can speed up one task while colleagues still need help to answer questions about the system it produces. Afroz et al. at FSE’26 used the SPACE framework to survey more than 400 software practitioners and found that those who used GenAI often said they finished tasks faster and got more work done. Those gains were offset by more code review work, the ongoing cognitive load of checking the code, and no change in how people worked together. The researchers characterize the result as a systematic redistribution of effort.

Unchanged collaboration is the central finding for interrupt load. The survey did not show GenAI adoption changing the pattern through which colleagues and stakeholders depend on engineers. Generating code more quickly therefore does not establish that fewer questions reach the people who understand the architecture. More code also gives people more to explain, review, and oversee. When access to knowledge stays concentrated, questions about what that code does and how it connects to existing systems return to the same senior engineers.

Context also constrains what agents can handle independently. Farrag’s paper identifies the context window constraint as one of two mechanisms amplifying the productivity-reliability paradox, with insufficient codebase context contributing to failures on tasks requiring architectural understanding. Those failures lead to more questions and more rounds of review. The paper contrasts gains on well-scoped tasks in controlled studies with slower work by experienced developers using AI on mature codebases in the most rigorous randomized controlled trial it discusses. Low-abstraction syntactic work and high-abstraction architectural reasoning place different demands on an agent’s understanding of the surrounding system.

LinearB’s 2026 AI benchmarks, based on millions of pull requests from hundreds of engineering organizations, found that autonomous agents made fewer than 5% of pull requests even in the organizations that used AI the most. The benchmarks also found that pull requests opened by agents tended to stay unmerged when no engineer owned them. AI deployment therefore needs to be assessed by whether it reduces the work routed back to humans. Full codebase context is a precondition for addressing architectural questions.

What actually reduces interrupt-driven engineering: making the codebase queryable

The structural fix makes the codebase the first point of contact for questions. That requires more than recording a subset of its architecture in a static document. Gloaguen, Mündler, Müller, Raychev, and Vechev’s February 2026 ETH Zurich study tested context files on AGENTBENCH and found that human-written files produced only a 4% average increase in task success while raising agent costs. With architectural overviews, agents still took as many steps to find the files they needed. Static context files were therefore insufficient on their own as a retrieval layer in that evaluation.

Documentation still serves a distinct human purpose. Writing a context file makes a team articulate knowledge that previously existed only in senior engineers’ heads, giving new hires something they can consult independently. But documentation answers the questions someone anticipated when writing it. Dynamic retrieval addresses questions about files, repositories, and dependencies at query time, rather than depending entirely on what an author chose to explain earlier.

For a team reducing interrupt load, the practical sequence begins with search across all repositories. The next step is direct natural-language access for non-engineers, who cannot be expected to know code syntax or repository structure before asking a question. AI agents then need full-repository context at inference time. Sourcebot is one example of this infrastructure, combining self-hosted deployment in a single software container with natural-language codebase search and MCP connectors for agents. Its role is to broaden access to existing knowledge.

Deployment constraints determine who can use that access. Self-hosted options, including Sourcebot, are relevant where code cannot leave the organization’s environment. The EU AI Act’s Articles 10 and 12 set requirements for data governance and logging, while GDPR’s cross-border transfer rules put more pressure on organizations to ensure their development tools comply. HIPAA’s 2025 proposed Security Rule update, still not finalized, would explicitly include AI tools in organizational risk analysis, and financial services regulators across multiple jurisdictions are tightening processing requirements. Otherwise, rules that limit the use of cloud-hosted tools can keep people from getting the access they need to cut interruptions.

The organizational change is a different route to answers. When a PM, security colleague, or new hire can query the codebase directly, the senior engineer does not have to abandon a mental model to explain it. When an agent can retrieve the relevant repository context, it is better equipped to address architectural work without sending failure-driven questions back to people.