Organizational Reorganizations and Codebase Knowledge Loss
Reorgs destroy codebase knowledge that lives only in engineers' minds, not in code.
Organizational restructurings do more than shrink a team's size: they destroy tacit, contextual knowledge that existed only in the minds of the engineers who left, and that destruction is usually permanent. Klarna's trajectory through 2025 and 2026 traced this exact arc: aggressive cuts framed around an AI-first future, followed by a quieter return to hiring once the gap between what the remaining systems required and what the remaining staff understood became obvious. Klarna was not an isolated case. The same sequence, cuts, an AI-first announcement, quiet rehiring, played out at multiple companies that moved fast on headcount reduction across 2025 and 2026.
One common objection holds that the organization has documentation, and it has version control, so the knowledge should be recoverable from the historical record. That objection misreads what those systems actually capture. Documentation records what was built. Tacit knowledge, in a codebase context, is the accumulated understanding of why systems took the shape they did, which edge cases had already been found and fought, and what had broken before and why. None of it lives in a diff or a wiki page. The next section traces exactly where it does live, and what happens to it when the person carrying it walks out the door.
Where codebase knowledge lives (and what happens when it walks out)
Most engineering organizations operate on an assumption that turns out to be false: that the codebase is the primary repository of understanding. It is the engineers' heads that hold that understanding. The engineers' heads are. The codebase captures the current state of implementation, nothing more. It does not capture the reasoning behind an architectural choice, the failure modes a team already discovered and designed around, the constraints, political or technical, that shaped a decision three years ago, or the cross-service dependencies that exist only because someone remembers building the integration and never wrote it down.
That reasoning does not vanish into nothing. It lives in conversational residue: Slack threads where an architecture decision got argued out, PR review comments where a reviewer explained why an approach was wrong, Jira tickets where a bug's real cause got discussed before the ticket was closed, hallway conversations that never got logged anywhere. These formats were never built for retrieval. They sit in tools designed for conversation, not institutional memory, and when the person who generated that thread leaves, the thread itself usually survives while the understanding it represented does not.
Memora Research's 2026 study of 350 enterprise tech leaders put numbers to this pattern. Each of those figures describes the same underlying failure: knowledge that existed, briefly, in a readable form, and then became unreadable the moment the person who created it stopped being reachable.
The departure of a single senior engineer does not just slow the person who replaces them. The cost of a reorg's knowledge loss never appears on the departing engineer's line item. It appears later, distributed across the team that has to work around the hole left behind, so leadership easily underestimates it.
Why knowledge-risk metrics have stopped working
The tools engineering organizations have long used to measure this exact risk have stopped measuring it, because the inference they depend on no longer holds. Truck factor and related knowledge-risk metrics all rest on one assumption: that authoring a region of code is evidence of understanding it. For most of software's history that assumption was reasonable, because getting code into a repository required a human to write it, and writing it tended to force at least a passing understanding of what it did.
Brett Wheeler's June 2026 paper on what he calls the substrate collapse argues that AI code generation severs this inference at its root. When an AI agent generates a module and a human merges it, version control still records that human as the author. The metric still produces a number. It is reading the wrong substrate, and the number it returns no longer corresponds to the thing the organization believes it is measuring.
This is not a problem that better weighting fixes. No adjustment to how authorship data gets scored recovers the inference, because the inference itself has collapsed, not merely degraded. A team that ran a truck factor analysis before a reorg, and used the result to decide which engineers were safe to let go, may have made that decision on an instrument that was already measuring the wrong thing before the reorg ever happened.
How AI-generated code compounds the loss after the reorg
A reduced post-reorg team under pressure to keep shipping typically leans harder on AI coding agents to make up for lost capacity, and that choice accelerates a second kind of loss layered on top of the first. Call it comprehension debt: the gap between what the codebase demands of the people maintaining it and what those people actually understand about it. Technical debt lives in code artifacts and architectural shortcuts, and static analysis tools can find it. Comprehension debt lives in team cognition. It is what developers do not know about the system in front of them, and no automated tool can detect its absence.
The field has converged on this phenomenon from several directions at once, naming it comprehension debt, cognitive debt, and epistemic debt in quick succession. Wheeler situates the pattern inside the same substrate collapse he identifies in authorship metrics: the AI generation that invalidates those knowledge-risk metrics also produces code that the engineer merging it may never fully understand, deferring the cognitive load of that code elsewhere.
Margaret-Anne Storey's Triple Debt Model, published to arXiv in March 2026, gives this a more complete structure. Storey's framing is specific on this point. Static analysis cannot find it, and a delivery mechanism built only to retrieve documentation will not satisfy it either, because there is nothing there to retrieve until someone writes the reasoning down.
The scale of the resulting damage to the codebase itself is visible in GitClear's analysis, cited in Wheeler's paper: the prevalence of duplicated code blocks in 2024 ran roughly ten times higher than it had two years earlier, with code blocks containing five or more duplicated lines appearing roughly eight times more often during that single year, which happens to be the period when AI coding tools went mainstream. Refactored code declined over the same period. That combination, more duplication, less consolidation, is the physical residue comprehension debt leaves behind in a repository: engineers generating new code because they do not understand the old code well enough to extend it safely.
The mechanism that plays out on a reduced post-reorg team follows a predictable shape. A smaller team under velocity pressure accepts more AI-generated code with less review attached to each merge. Anthropic's 2026 Agentic Coding Trends Report observes the shift this creates in what engineers are for: as agents take on more of the long-running implementation work, human attention has to move toward architecture, strategic direction, and confirming the system is solving the right problem. That is a role that demands a deeper grip on the codebase, not a lighter one, which is the opposite of what a depleted, under-pressure team is positioned to supply.
What AI coding agents miss without organization-wide context
An AI coding agent working from a narrow, local view of a codebase will produce changes that look correct on the developer's machine and turn out to be dangerous at the organizational level, because the knowledge it is missing was never going to be found there. Consider an agent asked to deprecate an API field. It can read the code in front of it and search for references within reach. It has no way of knowing that the field is consumed by four other services spread across separate repositories, that one of those services belongs to a different team entirely, or that the field carries sensitive data into a third-party integration the agent never had visibility into.
Feeding the agent a larger context window does not fix this. The agent needs accurate, current, organization-wide evidence of how the software actually behaves in production, not just a larger context window: cross-service dependencies, dataflows, and call sites that no single repository contains. Gal Bakal, writing from Yahoo in 2026, frames this as an architectural problem. When an agent meets an enterprise task without institutional context behind it, the result is guesswork, a cascade of corrections once the guesswork surfaces, and a disproportionate burden placed on the senior engineers who end up manually supplying everything the agent could not infer on its own.
Anthropic's 2026 report describes the same divide from the adoption side: a widening gap has opened between early adopters who worked out how to scale human oversight of agents without it becoming a bottleneck, and late movers who have not. The differentiator Anthropic identifies is how that team has structured the context its agents draw on, not which models it has chosen to use.
That gap matters most in exactly the situation this piece has been building toward. After a reorg, the institutional context that a departing senior engineer might once have supplied, informally, in a code review comment, in a quick Slack correction before a bad change shipped, is simply gone. The agent has no fallback source for it. The team left behind has less capacity than before to catch the agent's mistakes before they reach production. The failure mode described above does not require a particularly aggressive reorg to appear. It requires only the ordinary post-reorg condition of fewer people, more automation, and less institutional memory standing between the two.
The structural practices that make codebase knowledge durable enough to survive a reorg
Surviving a reorg without this kind of catastrophic knowledge loss requires capturing institutional context continuously, structuring it for machine retrieval, and surfacing it to engineers and agents alike through a shared context layer. It does not mean writing a wiki page after someone has already announced they are leaving.
Exit-interview documentation fails for a specific, structural reason. Asking a departing engineer to write down what they know during their final two weeks captures almost none of the knowledge that actually mattered, because it was never recorded as it happened, the engineer cannot reliably reconstruct decisions made months or years earlier under deadline pressure to finish up, and whatever they do manage to produce gets formatted for a human reader rather than for an agent that needs to query it later.
The corrective is to capture decisions where the work is actually happening. Architecture choices made inside PR reviews, Slack threads, and Jira tickets need to be indexed as they occur, not reconstructed from memory afterward. The failure is that it evaporates unless something is built specifically to capture it as it forms.
Bakal's Knowledge Activation framework, published in 2026, gives one concrete answer to what that capture should look like. Deployed this way, the approach compresses onboarding time, reduces the friction that builds up between teams working on adjacent systems, and removes the correction cascades that follow an agent's bad guess.
A parallel practice applies to architectural rationale specifically: writing ADRs and design patterns once, then surfacing them to every agent through MCP at the moment of use, rather than hoping each new model session rediscovers the organization's conventions on its own. This is the practice that answers Storey's intent debt directly, since intent debt is, by definition, the absence of externalized rationale, and an ADR retrievable by every agent on every run is exactly that rationale made durable. Writing things down does not by itself solve retrieval, and it only solves intent debt if what gets written down contains the reasoning, not just a restatement of what the code does.
Bus-factor monitoring belongs earlier in this process than most organizations place it. Wheeler's argument about the collapse of authorship-based inference applies here with full force: this kind of monitoring has to be grounded in actual evidence of comprehension, because an authorship footprint alone no longer tells anyone who understands a system and who merely merged it.
None of this infrastructure serves developer productivity alone. The same context layer that keeps an agent from making a dangerous unsupervised change also supports onboarding, compliance reviews, security investigations, and the mapping of where sensitive data flows through a system, making the investment in building it a shared asset across the organization.
Self-hosted code intelligence for knowledge that must stay private
The context layer built to solve all of the problems above does something else at the same time: it gathers an organization's most sensitive architectural information into a single place. That concentration is the point of the exercise, and where that system runs matters as much as how it is designed.
This is information that cannot safely leave an organization's own security perimeter. A dependency map that shows which services touch a sensitive data field is, by its nature, a map of where an attacker would look first. An incident playbook that explains how a past breach was contained is a playbook for reproducing the same failure. Code intelligence built to survive a reorg has to be built to run inside the walls of the organization it serves, because the alternative asks a company to solve a knowledge-retention problem by handing the knowledge itself somewhere else to retain.
