The code is not the territory

I’ve been watching a very interesting cultural side effect of AI engineering: the real engineers are having the biggest adoption problem. They’ve spent their whole career caring deeply about the code itself, in the way that a meticulous craftsperson cares about how the work gets done as much as they care about what the finished product is¹.

Whether you’re on a Mac, Windows, iPhone, Android, or even Linux device, your device’s processor — its brain — only understands tiny, primitive instructions like “add two numbers” or “move this value to that memory slot.” When humans write code in a “human-readable”² language like C or Swift, a program called a compiler translates it into those raw processor instructions and packages them into an executable file — a .exe on Windows or a binary inside a .app on MacOS. The formats and system libraries differ between operating systems, which is why you can’t just run a Mac app on Windows, but the idea is the same: translate human-readable logic into processor-native instructions, then let the Operating System (OS) load it into memory and run it. Some languages, like Python and JavaScript, skip this step and instead run through an interpreter that translates on the fly, which is slower but means the same code works on any OS that has the right interpreter installed.

Back in the way-back times, when computers had a fraction of the memory and processing power of today’s beasts, and my Dad was doing a degree in Computer Science while my mom was in labour with yours truly, you were forced to care because of the limitations. He has some great stories about mapping out where he was going to store variables on graph paper to fit them into the tiny jigsaw puzzle of memory he had available. Today, we don’t care at all. We write little programs that do very little except be extremely inefficient with memory and processors because we live in a time of almost absurd abundance.

My life writing code has never included graph papering out memory space or, even, really caring what machine-level assembly or bytecode came out of a compiler. I got to write in higher-order languages like Java or Python and not care what was happening below them.

And now, in this new Agentic Age, I write prompts in English, and I get code out the other end, and I don’t care what the code looks like either.

We’ve gone up another full level of abstraction, and I’m totally here for it. I used to obsessively format my HTML to make it as human-readable as possible, not because it mattered to the web browser, or that the end user would ever even see it, but because I was signing the inside of the case. Some other web developer, back in the less-way-back, was going to View Page Source on my sites and marvel at the care that went into tab-indenting and commenting, and in that very human moment, we would share a connection.

But you know who does?

Lifetime engineers. They can’t help it. They’ve been forever responsible for what the code looked like. They work on teams where they peer review each other’s code. They’ve had to debug code that some long-departed developer wrote one night on a caffeine-fuelled 3 am coding binge that made no sense to anyone else but was somehow the only thing holding the entire app together. One team I worked with had a giant banner in the engineering room that said:

Code like the person who has to maintain it is an axe murderer and knows where you live.

A bit extreme, yes, but it made the point.

So now, they’re having an existential crisis. Imagine being the fine Italian shoemaker whose father was a shoemaker and whose father’s father was a shoemaker, and who has inherited the fifth-generation store, and then sees someone walk by in Sketchers³. Here’s Cassidy Williams explaining this way better than I can:

This all brings to mind an old expression:

“The map is not the territory.” — Alfred Korzybski

He also said, perhaps less famously, “the word is not the thing,” both of which are relevant here. These ideas are crucial to general semantics, a system he originated. The map is an abstraction of the territory, but it is not the territory itself.

Before we wander off too far into abstraction land (without a handy map — ha, ha), the point I’m trying to make is that the code isn’t the final product. The critical thing is the ideas that go into it. The craft has shifted from meticulously formatting HTML to carefully crafting prompts. I care about as much about the code that gets produced as I used to care about the assembler my code was compiled into, mostly because I know that Claude will run a whole bunch of tests against it and can fix any bugs in a fraction of the time it would have taken me to even find them.

Today that’s 100% true for personal projects, proofs-of-concept, prototypes, and internal tools. It’s probably mostly true for real products, other than the most critical parts of them. Pretty soon, it will be true for all code. Many engineers I know have stopped writing lines of code, but are still reviewing it before it goes live. How much longer before they stop doing that?

Steve Jobs famously had the original Mac team sign the inside of the case because they were real craftspeople putting their signature on their work. Maybe the craftspeople care so much because how the work gets done is the biggest driver of the quality of the work. ↩
Human-readable is a relative term. It’s much less readable than, say, English or French, but it’s much more readable than, say, assembly, which looks like:

mov rax, 5 mov rbx, 3 add rax, rbx

Or, even less poetically, hexadecimal bytecode, which is even closer to what the processor understands:

48 C7 C0 05 00 00 00 48 C7 C3 03 00 00 00 48 01 D8 ↩
Apologies to Sketchers, I guess. You’re just … not the nadir of shoemaking craft. ↩

Footnotes