There is a sentence in the preface to Structure and Interpretation of Computer Programs, published in 1985, that most working engineers can quote from memory even if they’ve never opened the book:
Programs must be written for people to read, and only incidentally for machines to execute.
A year earlier, Donald Knuth had put the same idea more provocatively in his paper on literate programming: instead of imagining that our main task is to instruct a computer what to do, we should concentrate on explaining to human beings what we want a computer to do.
Both statements were arguments against an intuition that felt obvious at the time and still does. Code is instructions. Instructions are for the thing that executes them. Therefore code is for the machine, and clarity is a courtesy we extend to colleagues when we have the time.
Forty years of evidence say the intuition is wrong, and the reason is economic before it is aesthetic. The compiler reads a program once and never complains about its style. Every other reader is a person, and there are many of them: the colleague reviewing the change, the on-call engineer at three in the morning, the new hire six months from now, the auditor, the acquirer’s technical due diligence, and, most often, the author, who has forgotten why. Robert Glass, collecting what the industry actually knew about itself, put maintenance at 40 to 80 percent of a system’s lifetime cost. Most of the money spent on software is spent by someone reading it and trying to change it safely. Writing for the machine optimises the cheap part.
Then the machine started writing
It’s fair to ask whether any of that survives the last three years. If a model drafts most of the code, and a model will draft most of the changes to it, who exactly is the human reader we’re writing for? Perhaps the maxim was a product of its era: a way to manage the scarce resource of human authorship, and now that authorship is nearly free, the resource worth managing is something else.
We think the opposite has happened. Human authorship became cheap; human comprehension did not. And comprehension is now the whole job.
Look at what changed in practice. When an engineer types every line, understanding is a by-product of writing: you cannot produce the code without building a model of it in your head. When a model produces the code, that by-product disappears. Understanding has to be manufactured separately, by reading. The METR trial in our evidence review found that experienced maintainers were slower with AI assistance on their own mature codebases, and a large part of the time went into reviewing and correcting output they hadn’t written. The generation was fast. The reading was not, and the reading was the part that couldn’t be skipped.
So the reader the maxim was protecting didn’t go away. They moved from the keyboard to the review, and their bottleneck got tighter, because they now have to comprehend code at the speed something else can produce it.
The machine is a reader too
Here is the part that would have surprised the authors of SICP. The models are also readers, and they read the way we do.
A 2025 study titled When Names Disappear took code-understanding benchmarks and stripped the identifiers, replacing meaningful names with meaningless ones while leaving structure and behaviour untouched. Intent-level tasks collapsed: asked what a function was for, models stopped answering and started narrating it line by line. Even tasks that should depend only on structure, like predicting what code executes to, got measurably worse. Earlier work by Gao and colleagues found the same thing from the other direction: simply renaming identifiers produced substantial drops on code-understanding tasks.
That is a remarkable result if you think about what it means. Large language models learned to read code from the enormous corpus of code humans wrote for each other. The naming, the structure, the small acts of explanation embedded in a good function signature: those are the signal the models learned from, and the signal they still depend on. Code written for people to read turns out to be code that machines can reason about. Code written only to execute is opaque to both.
This has a practical edge. An agent working in a codebase has a context window, not a memory. What it can hold in view is what it can reason about. A module with a clear name, a narrow interface and a test that states its contract is a module an agent can change with confidence, because the intent is in the window. A thousand-line file called utils.ts is a module where the agent will do what the METR maintainers spent their time undoing: produce something plausible and wrong. The GitClear data from the same review, with duplication up and refactoring down across 211 million lines, is what it looks like when code is written for the moment of generation rather than for the next reader. The next reader, human or model, pays for it.
What “for people” means now
If the audience for code is the reviewer, the future maintainer and the model that assists both, a few old practices stop being hygiene and become load-bearing.
Names carry the meaning that structure can’t. The research says this literally: remove the names and understanding degrades, for models as for people. A name is the cheapest documentation there is, and the only kind guaranteed to travel with the code.
Boundaries are for the reader’s attention, not the machine’s. A compiler doesn’t care where you draw module lines. A person, and a model with a finite window, can only reason about what fits in view. Small, well-named units are how you keep intent inside the window.
Tests are the specification that doesn’t drift. A comment describes what the author believed. A test asserts what is true, and fails when it stops being true. For a reviewer checking generated code, and for an agent deciding whether its change is safe, an executable contract is worth more than any prose.
The “why” has to be written down somewhere, because nobody can recover it. This is the one thing neither a future engineer nor a future model can infer from the code. Why this database, why not that library, why the odd-looking constraint in the payments flow. A short decision record, dated and a paragraph long, is the highest-leverage document in a repository, and the one most often missing.
Delete what nobody reads. Generation makes it trivially cheap to add code and no cheaper to understand it. The discipline that matters now is subtraction.
None of this is new. What’s new is that the argument for it no longer rests on professional pride or on the hope that a colleague will be grateful. It rests on the observation that the only expensive thing left in software is understanding it, and that both kinds of reader we now have, the person and the model, depend on the same qualities to do so.
The same question, asked of a business
There’s a version of this that matters to anyone who commissions software rather than writes it. When a founder asks us “who owns the code?”, the honest answer has two parts. Legally, they do, on final payment, and we’ve written about that elsewhere. Practically, they own it only to the degree that someone other than us can read it. A codebase that only its authors, or only the model session that produced it, can understand is not an asset. It’s a liability with a licence.
That is why we care about readability more, not less, now that we write with machines. It’s the difference between handing a client a product and handing them a dependency on us. Code written for people is code that can change hands: to their first in-house engineer, to a diligence reviewer, to the next agent that will maintain it. Abelson and Sussman were making a pedagogical point in 1985. Forty years on, it reads like a description of what makes software worth owning.
Sources
- Abelson, Sussman & Sussman, Structure and Interpretation of Computer Programs, preface to the first edition (1985)
- Knuth, Literate Programming, The Computer Journal (1984)
- Glass, Facts and Fallacies of Software Engineering (2002), on maintenance as 40–80% of lifecycle cost
- When Names Disappear: Revealing What LLMs Actually Understand About Code (2025)
- Gao et al., on identifier renaming and code-understanding performance, via the survey in the paper above
- Our earlier posts: What the research says about AI-assisted development and Jev, and the case for models that don’t talk
