In 1985 Peter Naur wrote a sentence I think about every time an engagement ends. “The death of a program happens when the programmer team possessing its theory is dissolved.”
He was not talking about the code. The code survives. It sits in the repository, it compiles, it passes its tests. What dies is anyone’s ability to say why it is the way it is, and therefore what is safe to change.
Forty one years later, the code is the cheap part. The theory is not.
The thesis
When AI collapsed the cost of writing code, the handover became the only deliverable in an engagement that got more expensive. What a client is actually buying now is the reason each decision was made. Almost nobody prices that separately from the code, and on any system with money running through it, it should be the larger line.
What changed
Three numbers tell the story of the build. Google said about 25% of its new code was AI generated in October 2024. By late 2025 it was reported at 50%. In April 2026 TechSpot reported Google putting the figure at roughly 75%, with engineers reviewing the output. Whatever your own number is, the direction is the same. The marginal cost of producing code is heading towards the cost of reviewing it.
That changes what a handover document is worth, because a handover has two halves and AI only touched one of them.
The first half is what the system does. Which services exist, what calls what, where the data lands. That half is now derivable. Point a model at the repository and you get an accurate tour in minutes. So a handover that describes the system is worth roughly what it costs to regenerate, which is close to nothing.
There is evidence for this. A team at ETH Zurich evaluated repository context files, the AGENTS.md and CLAUDE.md files developers now write for coding agents, in a paper accepted at ICLR 2026. Their finding: context files, whether model generated or committed by developers, generally did not improve task success, and they raised inference cost by over 20% on average. Repository overviews in particular did not help. I read that as a clean result. A description of the repository is redundant with the repository.
The second half is why. Why this queue and not a cron job. Why the pricing table is duplicated in two places. Which alternative was tried in March and abandoned, and what broke. Which constraint came from the client’s finance team and not from engineering at all. None of that is in the code, and no model can infer a conversation that was never written down.
Naur put it precisely. The programmer who holds the theory “can explain why each part of the program is what it is” and “is able to respond constructively to any demand for a modification of the program”. That is the asset. It is also the only asset in the engagement whose replacement cost went up this year.
It went up because volume went up faster than understanding. GitClear analysed 211 million changed lines and found moved lines, its proxy for refactoring, fell 39.9% in 2024. Blocks of five or more duplicated lines rose eightfold, and copy pasted lines outnumbered moved lines for the first time. More code per person who understands it means the theory is spread thinner every quarter.
I have written code for 30 years. In every system I have been handed in that time, the code told me what. The expensive week was always the one spent finding the person who could tell me why, and the worst weeks were when that person had already gone.
Three cases, all public
Naur’s own compiler. The 1985 paper rests on a real case. A second group took over a working compiler to extend it, with “full documentation, including annotated program texts and much additional written design discussion”, plus advice from the team that built it. In several major cases their extensions were patches that ignored facilities the compiler already had, facilities the documentation discussed at length. The original team spotted it immediately. Ten years later, under other maintainers, the original structure was “still visible, but made entirely ineffective by amorphous additions.” That was a well documented system. The documentation described it. It did not explain it.
The truck factor. In a study of 133 popular GitHub applications, Avelino and colleagues found 46% had a truck factor of one and a further 28% had a truck factor of two. Nearly three quarters of widely used open source applications would lose most of their theory with two departures. Those are public projects with public commit history and public issue threads, which is the best case. A private codebase built by a contractor on a fixed term is worse.
The rent on a missing why. The 2024 Stack Overflow survey found over 60% of developers spend at least 30 minutes a day looking for answers, about one in four spend an hour or more, and 30% say knowledge silos hit their productivity 10 or more times a week. That is the cost of an unwritten theory inside companies where the people who hold it are still employed. After the handover, the people are gone and the rent becomes a rewrite.
The fix has existed for fifteen years. Michael Nygard proposed the architecture decision record on 15 November 2011, five headings: title, context, decision, status, consequences. His reason was exact. Someone new to a project, without the rationale, has two choices: “Blindly accept the decision” or “Blindly change it.” AI made the second option fast and cheap. That is the problem, not the solution.
Where this breaks
The strongest objection is that models will recover the why from the exhaust: commit messages, tickets, pull request threads, chat history. Partly true. Where a decision was argued in writing, retrieval finds it, and that is a real gain. But the expensive decisions are usually the ones made in a meeting, and a rejected alternative leaves no trace in the code that replaced it. Retrieval recovers what was written. It cannot recover what was not.
Second, Naur himself argued the theory cannot be fully written down. Granted. A decision record is a lossy copy of what the team knew. It does not replace the team. It shortens the revival, and on a system with live revenue paths, the length of the revival is the cost.
Third, a growing share of code is disposable. Prototypes, internal tools, a script due to be replaced next quarter. If rewriting is close to free, rewrite it and skip the record. That is a fair call, and I make it myself. The thesis bites on the other kind of system: the one with customers, integrations and money flowing through it, where a blind rewrite is the most expensive option on the table.
What I would do on Monday
Split the next statement of work into two priced lines: the build, and the decision record. If the second line is zero, you are buying code you will not be able to change.
Require one decision record per non obvious choice, on Nygard’s five headings plus one more: what we chose not to do, and why.
Test the handover before the team leaves. Give an engineer who has never seen the system the records and one real change request. Time how long it takes them to say whether the change is safe.
Stop paying anyone to write repository overviews. A model produces those on demand, and the ETH Zurich result says they do not help much anyway.
For every path that touches revenue, count the people who can explain why it works the way it does. Where the answer is one, you have found your exposure.
The close
Naur wrote one more sentence in that paper. “Revival of a program is the rebuilding of its theory by a new programmer team.”
The code will still compile the morning after the team leaves. It always has. The question was never whether the program runs. It is whether anyone left can tell you why.
Most of what I write about here started as a client problem. If yours is a system nobody left in the building can explain, put it on my calendar.