Nobody Remembers Why

Your codebase lost its decisions. Your engineers stopped forming mental models. The public knowledge pool is collapsing. Three layers of forgetting are compounding at the same time.

I was reviewing a service boundary with one of our engineers at INNOMIZE last month. The service had been in production for a year. It worked. Nobody had touched it in a while. The question was straightforward: why is the user authentication check happening here instead of at the gateway? The engineer looked at the code, looked at me, and said he didn’t know. The original architect had moved on. The commit message said refactored the auth flow. The PR description was blank. The code told us what was happening. Nothing anywhere told us why.

I’ve been thinking about that moment since, because it connects to something I keep seeing at a larger scale. Engineering teams are forgetting things at three levels simultaneously, and the levels are reinforcing each other in ways that most leaders are not watching. The codebase is losing its decision history. The engineers are losing the habit of understanding the system they work in. And the public knowledge pool they used to learn from is collapsing. Each of these would be a problem on its own. Together, they compound into something I think is going to define the next five years of engineering leadership.

Your codebase remembers what, not why

Every codebase is a collection of decisions. Which database. Which auth pattern. Where the boundaries sit between services. Why the retry logic uses exponential backoff with a cap instead of a fixed interval. The code records the outcome of each decision but almost never records the reasoning. That reasoning lives in the heads of the people who made the call, and when those people leave, it leaves with them.

This has always been true. What changed is the rate.

I wrote in Your Team Ships Faster with AI but Your Systems Don’t about what I called context evaporation, the way AI-generated code never builds a mental model in the engineer who ships it. That same dynamic applies to the codebase itself. When code is generated through prompting, the decision trace is even thinner than it was with hand-written code. At least when a human wrote it, there was a chance they remembered why. With AI-generated code, nobody ever knew why. The model picked a pattern that fit the prompt. The engineer accepted it because the tests passed. The reasoning behind the choice was never formed, so it cannot be lost. It never existed.

At INNOMIZE, we regularly inherit codebases from other teams. I described this in the last issue: systems that work but nobody can explain. Documentation that does not exist. The answer to every why question is read the code. What I’m noticing now is that the codebases we inherit from teams using heavy AI assistance are harder to understand than the ones written entirely by humans. The human-written ones at least have consistent patterns, even if undocumented. The AI-assisted ones have locally correct code with globally inconsistent decisions, because each prompt was a fresh starting point with no memory of what came before.

Architecture Decision Records exist precisely for this problem. They capture what was decided, what alternatives were considered, what constraints existed, what trade-offs were accepted, and most importantly, why. AWS reports implementing over 200 ADRs across their projects and finding that development teams spend 20-30% of their time coordinating with other teams when decision history is absent. That is time spent reconstructing context that was already understood once and then forgotten. The industry knows the tool exists. Almost nobody uses it.

Your codebase remembers what it does. It has forgotten why it does it. Every engineer who leaves takes a piece of that reasoning with them. Every AI-generated commit adds code that had no reasoning to begin with.

Your engineers stopped building mental models

The second layer of forgetting is happening inside the people, not the code.

I wrote about this pattern in The Junior Developer Problem Nobody Wants to Solve, but what I’ve seen since publishing that issue is that it extends beyond juniors. It is happening at every level. I run regular one-to-one with engineers across my team at INNOMIZE, and a pattern keeps surfacing that I’ve started calling the ownership gap. Engineers are completing tasks without understanding the system those tasks live in. They arrive at the task, prompt the AI, ship the output, and move on. They are operating within the system without ever building a model of the system.

The symptoms are consistent. Not actively understanding how the system works, waiting for tasks to learn about it instead of seeking that understanding independently. No opinions about architecture or approach. No questions before starting. Never I investigated and decided X. Always the AI suggested X, the tests passed. When I ask why they chose a particular approach, the answer is some version of uncertainty. They are not sure, but it works. Working by habit, not with intention.

This is what I think of as reactive engineering. The engineer responds to work instead of driving it. They are task executors, not system owners. And AI is accelerating this pattern because AI removes the friction that used to force understanding. When you write code by hand, even badly, you simulate every branch, every edge case, every interaction as you type. That simulation is a tax, and the tax builds intuition. When you prompt for code and scan the output, the simulation never happens. The intuition never forms. The engineer gets faster at producing output and slower at understanding what the output is doing inside the system they are supposedly responsible for.

DX’s research on developer ramp-up shows that engineers using AI daily reach their 10th pull request in 49 days, nearly half the 91 days it takes engineers without AI. That looks like progress until you ask what reaching the 10th PR actually means. It means they are committing code. It does not mean they understand the system they are committing to. We are measuring typing speed and calling it competence.

The knowledge pool is collapsing

The third layer of forgetting is the one nobody controls.

For two decades, Stack Overflow was where engineers went when the codebase and the team couldn’t answer their question. It was the public memory of the profession. A question asked once, answered once, accessible to everyone who came after. That pool is drying up. Techzine’s analysis of Stack Overflow data found that monthly question submissions dropped 78% in a single year, from December 2024 to December 2025. PPC Land’s reporting puts the overall traffic decline at roughly 75% from peak. Question volume is back to 2008 levels, erasing fifteen years of growth.

The decline started before AI. Moderation policies frustrated contributors, and participation began falling as early as 2018. But AI accelerated it past the point of recovery. Engineers now ask their coding assistant instead of the forum. The assistant gives a faster answer. But the forum answer was public. It accumulated. Other engineers found it, improved it, debated it, corrected it. The assistant answer is private. It dies with the session. Nobody else benefits.

Here’s the part that should worry engineering leaders: the knowledge AI assistants draw from is partly built on the public contributions that are now declining. The training data includes years of Stack Overflow answers, blog posts, open-source discussions, and technical documentation written by humans who shared what they learned. As that sharing slows, the pool the models learn from gets shallower. We are drawing from a well and contributing nothing back. The well is finite.

Stack Overflow question volume dropped 78% in a single year. The public knowledge pool AI depends on is shrinking. We are consuming collective engineering memory faster than we are creating it.

I captured the context squeeze as an insight earlier this year, connecting two observations: LLM constraints like rate limits and token budgets are narrowing how much you can ask, and the public knowledge collapse is narrowing what is available to ask about. Both constraints point in the same direction. The teams that win are not going to be the ones running more prompts. They are going to be the ones that build better private context, documentation, patterns, playbooks, decision traces, that the public pool no longer provides.

What compounds when all three layers hit at once

Each of these layers would be manageable on its own. A codebase without decision history is hard to work in but survivable if the team still understands the system. A team with weak ownership habits can get by if the code is well-documented or the public knowledge pool can fill the gaps. A shrinking knowledge base matters less if your team has deep institutional memory and your codebase tells its own story.

The problem is that all three are degrading simultaneously, and they feed each other.

When the codebase has no decision history, new engineers cannot learn from the code. They need to ask someone. But if the engineers around them have weak ownership of the system, nobody has the answer. So they turn to external resources: Stack Overflow, blogs, documentation. But that pool is shrinking too. They end up back at the AI, which generates locally reasonable code with no systemic understanding, which adds more context-free code to the codebase, which makes the amnesia worse. The loop closes. Each layer of forgetting amplifies the others.

Industry research estimates that 70% of turnover expense is indirect, institutional knowledge walking out the door, and it never appears as a line item on a standard budget. When that knowledge was never captured in the codebase, never built into the team’s habits, and can no longer be found externally, the effective cost of losing an engineer is far higher than any budget model shows.

Building the memory your team will need

I’m not going to pretend I have this figured out. I’m working through it at INNOMIZE in real time. But the direction is becoming clear to me.

The codebase needs decision memory. Decisions recorded where they can accumulate over time: ADRs for architecture choices, PR descriptions that explain why a change was made alongside what changed, commit messages that capture the trade-off behind the change. We started requiring a one-paragraph why section in every PR template six months ago. It felt like overhead at first. Now it is the first thing I read when I need to understand a piece of the system, and it takes less time than reconstructing the reasoning from scratch.

The team needs ownership culture. This means shifting one-on-ones from status updates to thinking patterns. Instead of what did you ship this week, I ask what do you understand about the system that you didn’t understand last week? Instead of celebrating PR velocity, I celebrate the engineer who found a latent bug by reading code they didn’t write. The goal is to make system understanding a visible, valued skill, as important as task completion.

The organization needs its own knowledge base. Something more durable than a wiki nobody reads. A living context layer: architectural standards, patterns, playbooks, accumulated decision traces that serve both the team and the tools the team uses. When I give an AI assistant our architecture doc and our ADR history alongside a coding task, the output is meaningfully better than when I give it the task alone. Private context is becoming the moat. The teams building it now will have it when the public pool can no longer substitute.

Foundation first. Always. Even when the foundation is memory itself.

When the last engineer who understood the original decision leaves your team, where does that understanding go? Is it in the codebase, in the team’s habits, in a document someone can find? Or does it just disappear?