On-call for code nobody remembers writing
Incident response has always leaned on a hidden asset: somewhere in the organisation, a human remembered building the thing. That asset is quietly disappearing, and most runbooks assume it is still there.
Every experienced incident responder has a moment they can describe. Something is broken, the graphs are ambiguous, three theories are on the table, and then someone types a message in the channel that collapses the search space: “that path has a cache with a five minute TTL, it is not in the config, it was hardcoded during the migration.”
That message came out of a human memory. Not from a document, not from the code, not from a dashboard. Somebody was there when it was built and remembered.
Incident response as practised almost everywhere depends on that asset far more than its documentation admits. And it is the asset most directly threatened by a life cycle in which changes are produced faster than people read them.
The hidden dependency
Consider what actually happens during a difficult incident. The observable symptoms underdetermine the cause. There are more plausible explanations than time to test them, so the responder does not search exhaustively; they prune. Pruning is done with a mental model of the system, and the highest-quality parts of that model come from having built or debugged the thing before.
Take the model away and the search does not fail, it just gets much longer. And incident duration is not linear in difficulty, because the organisational cost of a long incident includes escalation, customer communication, and increasingly panicked decisions taken by people with less information.
Incident with a human model
- Symptoms underdetermine the cause
- Responder prunes to two candidates from memory
- Tests both, finds it in twenty minutes
- Fix informed by why the code is like this
Incident without one
- Symptoms underdetermine the cause
- Nine candidates, no basis to prune
- Sequential search, ninety minutes and rising
- Fix addresses the symptom, cause unexplained
The second column has a sting in the tail worth dwelling on. Under time pressure, a responder without a model will find a fix, apply it, and restore service. The incident closes. But the causal explanation is missing, which means the same class of failure recurs, and the review produces action items about monitoring rather than about the actual defect. Organisations in this state experience recurring incidents that each look novel and are not.
Why this is different from ordinary staff turnover
The obvious objection: people have always left, and codebases have always outlived their authors. True. Two things make this different in degree enough to be different in kind.
The first is rate. Turnover removed context at the speed of resignations, which gave the organisation years to spread knowledge, and it removed context in whole-person chunks that were visible. Someone leaving triggered a handover. Generated code that nobody deeply read creates context gaps continuously, in small pieces, with no event that marks them.
The second is that the code was never in anyone’s head to begin with. When a departed colleague’s code is confusing, there was once an intent, and traces of it survive: a commit message, a ticket, a design document, a comment written while thinking. Reconstructing intent is possible because intent existed. Code generated from a thin prompt, reviewed quickly, and merged has a much weaker provenance chain. The question “what were they trying to do” may have no better answer than the ticket title.
What has to replace memory
If the human model is thinning, the response is not to demand people read everything, which does not scale and will not happen. It is to make the system produce the artefacts that memory used to supply.
There are three, and they are quite specific.
Provenance is the one that gets easiest, and it is the direct compensation for the loss. In a well-instrumented agentic pipeline the chain from a line of code back to the intent that produced it is complete and machine-readable, which is more than was ever true of human-authored code. During an incident, being able to ask “what changed in this path in the last week, against what criteria, and what did the verification actually check” replaces a substantial fraction of what the person with the memory used to supply.
This is worth stating plainly because it is the genuinely good news here: the recorded chain can be better than memory. Memory is lossy, biased toward the dramatic, and unavailable when its owner is on holiday. A proof chain is none of those things. The catch is that it has to be built deliberately, before it is needed, by someone who was thinking about incidents at a time when nobody was having one.
Decision records are the hardest, because they require someone to write down a reason at the moment of choosing, and the reason feels obvious at that moment. The discipline is unnatural and the payoff is eighteen months away. I have no clever mechanism to offer; the teams that do it have simply decided to, usually after an incident that cost them enough to change behaviour.
Behavioural documentation is the one most often skipped and it is where the sharpest edge is. Generated code that passes its criteria can still have failure characteristics nobody has ever observed. What it does when the downstream service is slow rather than down. Whether it retries and whether the retry is bounded. What happens when the queue is full. These properties are usually not in the criteria because nobody thought to state them, and they are exactly what an incident is made of.
The two-in-the-morning question set
For teams operating in this world, the practical shift is that incident response leans harder on interrogating the record and less on interrogating people. That changes what needs to be available at three minutes’ notice.
The third box is the one people miss. When a change passed verification and still caused an incident, the interesting artefact is not the change, it is the shape of the gap: the property that mattered and was never asserted. That gap is almost always a class rather than an instance, which means the correct output of the incident review is a new criterion applied to every future change on that path, not a fix to one function.
The rotation problem
There is an organisational failure I would flag ahead of time, because the incentives point straight at it.
When a small team produces a large volume of change, the person who has the best model of the newest subsystem is whoever prompted it into existence. Under pressure, that person becomes the de facto escalation for anything touching it. This is convenient, it works, and within a few months you have a single point of failure that the org chart does not show and that nobody chose.
The counter-measures are ordinary and unpopular: deliberate rotation, requiring that at least two people can operate anything in production, and treating “only one person understands this” as a defect with a ticket rather than as a fact of life. All three lose to delivery pressure unless someone senior insists, and the cost of not doing it is paid at two in the morning by whoever is unlucky.
Where this breaks down
Provenance only helps if the incident is change-related. A meaningful share of incidents are caused by traffic, dependency failures, certificate expiry, or capacity, and no amount of chain-of-custody information helps. The record narrows the search when something changed; it does nothing when nothing did.
A complete record can be worse than no record if people trust it too much. If the chain shows criteria passed, there is a strong pull toward concluding the change is innocent and looking elsewhere. Passing criteria means the stated conditions held, which is a much weaker claim than correctness. I have watched a team lose forty minutes to exactly this, and the record was accurate the whole time.
Documentation and decision records decay. A stale decision record actively misleads a responder at the worst possible moment, and it does so with the authority of a written document. Anything in this category needs a date and a bias toward deletion when nobody will vouch for it.
Some knowledge is genuinely irreducible to artefacts. The sense that a graph is wrong before you can say why, the memory of a similar shape of failure three years ago, knowing which team to call: none of that is written down anywhere and I do not think it can be. Experienced responders remain the most valuable asset in an outage and nothing here changes that.
The takeaway
Incident response has always depended on a human somewhere remembering how the thing was built. That dependency was invisible because the asset was reliably present, and it is now thinning out for a structural reason rather than through anyone’s negligence.
The compensation exists and it can be better than what it replaces: a complete provenance chain from any line back to the intent that produced it, decision records for why the system is shaped as it is, and behavioural documentation for how it fails. All three have to be built before they are needed, which is the entire difficulty.
If you take one thing into next week: pick a recent incident and ask how much of the resolution came from something written down versus something someone remembered. Then ask what happens to the second number in a year.
This closes the roles series. The next set turns to governance and security, starting with the question that determines everything downstream: what an agent should never be permitted to do, regardless of how well it performs.