What AI Reveals About Programming
TL;DR: Peter Naur argued in 1985 that programming is fundamentally theory-building — the code is the shadow of the mental model in the programmer's head. AI vindicates him sharply: the bottleneck was never code generation. But there's a flip side Naur didn't foresee, and it's the most important question in engineering right now.
Peter Naur Was Right in 1985
In a 1985 paper that deserved more attention than it got, the Danish computer scientist Peter Naur made a claim that cut against the prevailing view of software engineering. The code, he said, is not the program. The program is the theory inside the programmer's head — the mental model of how the pieces connect, why they connect, what breaks if you pull one out. Code is the shadow of that theory, projected onto a machine.
This distinction had consequences. When a programmer leaves, Naur argued, the theory goes with them. What remains are documents, diagrams, and code - artefacts which are enough to reconstruct a surface understanding, not enough to inherit the program. The cost of modification and maintenance spirals not because the code is complex, but because the theory is gone and nobody knows it. I can't begin to quantify the sum of time in my career where we've had to spend countless hours spanning months discovering what our own business already does in a given space before moving onto what could be improved. Worse still - groups of people in rooms all of whom pretend they know what's going on, hoping the person to their left knows more and doesn't realise they know next to nothing. For me this is where the analogy breaks out of the engineering space and into Product - but I digress.
Naur called this program theory loss. He wrote it in 1985.
The Bottleneck Was Never Code
If you've used an AI coding tool seriously, not to generate snippets, but to build something real, you'll have felt a specific thing happen whereby the bottleneck is no longer the speed at which code can be written - its something else. It's theory.
Do you have a coherent model of what you're building, how the pieces fit, what the edge cases look like? If you do, AI is an extraordinary accelerant. If you don't, it produces plausible-looking code that doesn't do what you intended, or appears to, but fails at the edges, perhaps without anyone even noticing. It even begs the question as to what it means to fail?
Naur's thesis, forty years on, now has stark relief with empirical proof. The bottleneck in software development is, and perhaps always was, the clarity and coherence of the mental model.
The Flip Side Naur Didn't Foresee
Naur assumed that theory-building happens through the act of programming. You build your mental model by writing code, hitting walls, debugging, iterating. Theory emerges from practice. The code isn't just the output of the theory - it's part of how the theory gets built in the first place. I have affinity with this view having begun my career as an engineer. Writing code is the act of addressing a business problem and creating value, but PRDs and Jira tickets never provided the required depth to capture the nature of an issue and describe the solution. Writing code is a process of discovery in and of itself, discovery of the space, the nature of the language or the development environment and in those, for me, rare moments of flow, the process feels alive as opposed to mechanistic.
With AI, we’re somewhat removing the mechanical work of coding and I can’t help but feel something is being lost, even if the gain is net positive. As with most periods of change, its both exciting and unsettling. What does appear clear is that business or Product, is moving closer to engineering and engineering close to Product and the business - which I think is positive provided we treat theory building as a joint endeavour and not something any one party owns over another. Its a challenge to business leaders: empower all teams and individuals, regardless of the hat they wear, to shape the work, not just produce it.
What AI Reveals
What AI reveals about programming is this: it was always cognitive work. The mechanical parts were real, and removing them matters. But they were never the rate-limiting step for people actually building difficult things that succeed.
What I have found so far: building with AI is more theory-intensive, not less. The difference isn't that AI writes the code so I don't have to think. The difference is that it writes the code fast, so the bottleneck moves immediately to the thing I'm least clear about. Every time I hit resistance, it was a failure of my mental model, not a code problem.
The iteration speed compresses the loop rather than removing it. The theory still has to get built. But what used to take days of writing-and-discovering now takes hours of directing-and-evaluating. The quality of your mental model is exposed faster, not bypassed.
Naur saw this in 1985. AI has given us, finally, a way to experience it directly.
The question worth sitting with - for engineering managers, for teams making hiring decisions, for anyone building software - isn't "will AI replace programmers?" It's a different question: one about how a new generation builds the theories the previous one built by writing code. What happens to a discipline when the apprenticeship that used to build the theory is no longer reliably happening?