Programming as Theory Building

In 1985, Peter Naur, a Danish computer scientist, the "N" in BNF (Backus-Naur Form), and a Turing Award winner, published a short paper called "Programming as Theory Building." It ran nine pages in Microprocessing and Microprogramming, Volume 15, Issue 5. It's the single most useful idea I've encountered for thinking about how to work with AI in 2026.

The thesis is short enough to fit on an index card:

A program is not its source code. A program is a shared mental construct, a "theory", that lives in the minds of the people who built it. Source code is a shadow of the theory. Documentation is incomplete. Rebuilding the system requires rebuilding the theory.

Who Naur was

Peter Naur (1928-2016) was one of the original computer scientists. He worked on ALGOL, won the Turing Award in 2005, and spent decades thinking about how programming actually works as a human activity, not as a logical exercise, but as a craft of building shared understanding.

He wrote "Programming as Theory Building" as a reaction to the dominant 1980s assumption that you could write a software system, document it well, and then any qualified team could maintain it. Naur argued: no. The original team carries the theory of the program. When they leave, the theory leaves. The new team can read the source code, can read the documentation, but the theory is gone, and without the theory, every change becomes guesswork.

He had data: companies that had let original development teams go and brought in new teams later could not effectively maintain the systems, even with full source code access. The code was visible. The theory wasn't.

The "shadow" insight

Naur's framing: code is the shadow of a mental construct. The construct lives in your mind. The code is its visible, executable trace.

This implies several things that sound simple and are profound:

• Two programs with identical source code can be different programs, if the underlying theory differs. The code is the shadow. The theory is the substance.
• You can't fully document a program. Documentation is always partial, it captures some of the theory, never all of it.
• The original builder has an irreducible advantage. They carry the theory. New maintainers have to rebuild it from incomplete shadows.
• Code reviews are theory transfers. The most valuable thing a senior engineer does isn't catch bugs, it's transmit theory to whoever's listening.

Why this matters in 2026

Now apply Naur to AI work. The theory is what gives Claude context.

When you ask Claude to do something and the output is bad, the temptation is to blame the model. Naur tells you to look elsewhere: the theory hasn't been articulated well enough for Claude to render its shadow. Claude doesn't fail at execution; you fail at theory transfer.

Three implications for operators working with AI:

1. Your CLAUDE.md is the explicit articulation of the theory. The brand voice, the audience, the goals, the constraints, the way you think, all expressed in markdown so Claude can read it. When Claude works well with you, it's because your CLAUDE.md has captured enough of the theory. When Claude works badly, the theory leaked out somewhere you didn't notice.
2. Code that an AI generates without theory is "shadow without substance." The output looks right at first glance. Six weeks later it's full of bugs you can't trace, because the underlying mental model was never coherent. Vibe-coded systems are theory-less systems. They run, until they don't.
3. The Command Kit is theory infrastructure. Wiki entries are theory. Decision logs are theory. Naming conventions are theory. The folder structure itself is theory. This is why we build Command with care, not as documentation overhead, but as the substance of how you think about your business.

The translation: from code to operations

Naur was writing about software engineering in 1985. The translation to AI-native operations is direct:

What this means for "vibe coding"

Vibe coding, Karpathy's term for prompting your way to working software, is theory-less by default. You prompt, the AI produces, you keep prompting, eventually something works. There's no underlying theory. There's just the accumulating shadow.

This is fine for prototypes. It's catastrophic for systems you have to maintain. Six months in, you can't find your own bugs because there's no coherent theory under the code. You become a maintainer of a stranger's program.

The fix isn't to stop vibe-coding. The fix is to build the theory alongside the code. CLAUDE.md from day one. Wiki entries as features stabilize. The Command Kit grows in lockstep with the Compute output. By the time you have a working system, you also have an articulated theory of how it works, written down, AI-readable, transferable.

The captain transfers theory

This is what makes the captain's role irreducible. The captain holds the theory. The captain transfers it, to Claude via CLAUDE.md, to teammates via wiki entries, to future-you via decision logs. Without the captain articulating theory, the agents work with shadows of shadows, and the system gets less coherent every iteration, not more.

When you wonder why MaxShip puts so much weight on writing things down, on the Command Kit discipline, on context engineering, on the wiki, this is why. Naur was right in 1985 and is more right in 2026. Theory is the substance. Everything else is shadow.

Read the original

Nine pages. Free PDF: pages.cs.wisc.edu/~remzi/Naur.pdf. Read it once if you've never read it. Re-read it once a year. It will change how you think about the work.