We Replaced the Build Layer, Not the Runtime

Guillermo Rauch wrote that everyone is now a programmer, because the present and future programming language is your natural language: if you can write or speak, you can build. He calls it the most important evolution in our field since its creation, a tsunami that has just started. A claim that sweeping — from someone with that much to gain by making it — deserves some critical thinking, not a reflexive nod. The real part is smaller than the sentence sounds: you can now build software by writing or speaking. What I want to argue with is the slide from you can build to everyone is a programmer — not the same claim, and the gap between them is this whole essay.

Let’s be honest about where this is coming from. Rauch runs a company whose business is selling shovels for exactly this gold rush, and “everyone is now a programmer” is about the most comfortable sentence a person in that chair can say. So yes — some of this is hype, a marketing weather report from someone with product to move. Andrej Karpathy reached for the same image earlier and more bluntly — “the hottest new programming language is English”¹, later naming the practice vibe coding, where you describe what you want, accept what the model produces, and mostly forget the code even exists² — and he has his own share of boosterism to answer for too. Discount the whole chorus for the sales pitch. Skepticism is the right posture to open with.

And then, having discounted it all the way down, notice that something real is still sitting at the bottom of the claim.

It works. I’ve watched people who have never opened a terminal produce something that runs — a landing page, a script that renames a thousand files, a small tool that solves a real problem in their day. That is not nothing. It is, genuinely, one of the largest expansions of who gets to make software in the history of the field. The barrier that kept most of humanity out of building was never a lack of ideas. It was syntax, tooling, the thousand small hostilities of the environment. Natural language dissolves a lot of that.

So yes: anyone can now build. That much I’ll grant without a fight — it’s true, it’s new, and it’s one of the best things to happen to the field in my lifetime.

What I won’t grant is the word Rauch reaches for to describe it. Build and programmer are not synonyms, and the distance between them is the rest of this essay.

Everyone can now ask for a program that runs. Not everyone can tell you why it runs — or fix it when it stops. In the thread where I first made this argument, Kelvin Meeks put the dividing line better than I could:

If the person can’t debug the source code, they are just a dabbler — not a programmer.

That sounds gatekeep-y until you’ve been the one paged at 3am. “It runs” is a statement about a single execution, on one machine, with one input, at one moment. Programming is everything that statement leaves out: why it runs, what it assumes, when it will stop running, and what you do at that moment. A model can hand you the first. The rest is still, stubbornly, understanding — and understanding does not come bundled in the output.

Here’s the objection that deserves an answer, because it’s the strongest one against everything I’m about to say: the same model that writes the code will also explain it. Paste the stack trace and get a root-cause hypothesis; ask why the query is slow and get a paragraph about indexes. If generation got cheap, didn’t comprehension get cheap right along with it?

Partly. And that part is real — I use it every day. But a machine can hand you a theory; it cannot make you hold one. The explanation arrives as fluent, confident prose, and fluent-and-confident is exactly the trap: you cannot tell a correct explanation from a plausible wrong one unless you already understand the thing being explained. Comprehension you didn’t earn doesn’t transfer, doesn’t compound, and isn’t there in the one moment you actually need it — the novel failure the model has never seen, where its explanation is as wrong as its code and just as self-assured. So the honest version of the asymmetry is this: generation fell to almost nothing, and real understanding got cheaper too, but far more slowly — and it stops being free precisely when the stakes go up. When those two curves diverge, you get an enormous amount of software that works and that no one — the person who prompted it, or the model that wrote it — can actually account for.

Here’s the framing I keep coming back to, and it’s the whole point of this post.

We did not replace the runtime. We replaced the layer where programs get authored.

Think about what an LLM actually does when it “programs.” It sits where a human used to assemble the instructions — choosing the function, wiring the call, naming the variable. It automates authoring. I’m calling that the build layer, with one caveat for the engineers reading: I don’t mean the toolchain you normally attach to that phrase — the compiler, the bundler, CI. I mean the human act of composing the program in the first place. That is the part the model now does for you.

But the thing it authors still has to descend through every layer beneath it: the language runtime, the operating system, the network, the database, the distributed system with its partial failures and its clock skew and its retries. Plenty of that has been abstracted away too — it’s most of what two decades of cloud and managed services did, and it’s the same move at a lower altitude: hand people a runtime they can operate without understanding it. But abstracting a runtime is not abolishing it. The laws underneath don’t change. The database still has to do the work the query asked for; the network still partitions; the CPU still stalls on a cache miss. The understanding didn’t become unnecessary — it just moved out of sight. Which is a very different thing, and the whole source of the risk.

This is why the “everyone can build” story feels magical and reads as risky at the same time. Magic is the correct word for the experience — you speak, and a working thing appears. But magic, in the honest sense, is just an abstraction whose internals you’ve agreed not to look at. And abstractions have a law, stated by Joel Spolsky more than twenty years ago and undefeated since:

All non-trivial abstractions, to some degree, are leaky.

The vibe holds right up until the abstraction leaks — the query that’s fine at a hundred rows and melts at a million, the race condition that only shows up under load, the dependency with a CVE, the bill that arrives because nobody understood what “serverless” was actually invoicing.³ And when the leak happens, natural language is no help at all, because the leak is happening at a layer natural language never touched. Fixing it requires exactly the skill the tsunami promised you didn’t need: knowing how the runtime works.

The deepest version of this argument is forty years old and was never really about AI. In 1985, Peter Naur — the N in BNF — wrote a short, stubborn essay called Programming as Theory Building.⁴ His claim: the real program is not the source code. The real program is the theory living in the minds of the people who wrote it — their understanding of the problem, of why the code is shaped the way it is, of which parts are load-bearing and which are incidental.

The text is a shadow of the theory. And here is the unsettling part: Naur argued that when the team holding the theory disperses, the program dies, even if every line still compiles and runs. New maintainers can read the code perfectly and still make it worse, because they patch the shadow without holding the thing that cast it. The code runs; the understanding is gone; decay follows.

Now extend that — and let me be clear the next step is mine, not Naur’s; he was writing about teams dispersing, not about machines. If a program’s life is the theory in a human mind, then code generated by a model and accepted without comprehension is a shadow with nothing casting it. It runs on day one, and there is no one who holds why it is the way it is. The first serious change starts from zero, or worse than zero.

The fair objection is that none of this is new. Copy-pasted Stack Overflow, inherited legacy nobody remembers writing, the dependency you imported and never read — theory-free code is as old as code reuse, and we’ve shipped it for decades. True. What’s new is that the cheapest, default, most frictionless way to make software now produces theory-free code by construction, at a volume and speed the copy-paste era could never reach. We didn’t invent the theory gap. We industrialized it.

This is the part my instinct reached for in that thread, and I still think it’s the right instinct.

I kept thinking of Asimov’s Foundation.⁵ On the kingdoms of the Galactic Periphery, atomic technology still runs — but the science behind it is gone, and the reactors are tended by a priesthood that works them through memorized ritual, with no idea what the rituals actually do. It works, generation after generation, exactly as long as nothing new breaks. The Foundation’s entire strategy rests on a simple bet: whoever understands the machine controls the people who can only worship it. When the knowledge became religion, the power moved to whoever kept the knowledge.

🏊 Why this keeps happening — from the Bronze Age to the build pipeline

A caveat first: what follows is an image, not evidence. Asimov’s worlds are invented to prove his point, and real history is messier than any thesis. But the image earns its keep. Around 1200 BCE, a whole interlocking network of Late Bronze Age Mediterranean civilizations came apart within a couple of generations — the causes still argued over: drought, the Sea Peoples, earthquakes, and the brittleness of systems too specialized to bend. One casualty in Greece was Linear B, the script the palace scribes used to run the economy. It was never mass literacy — it was a narrow administrative skill held by a handful of people — and when the palaces fell, that handful was a small enough bottleneck that the skill died with them. Writing didn’t return to Greece for centuries.

Notice the direction of causation, because it matters and cuts against the tidy reading: the lost knowledge was mostly a symptom of the collapse, not its trigger. But the bottleneck is the part that travels to us. When a capability lives in very few heads — because it curdled into ritual, or because it was never really learned in the first place — the system has no margin. One shock it wasn’t rehearsed for, and the capability is simply gone. Asimov dramatized that with reactors; Naur described it with software teams. Same shape, wildly different scales — and, to be honest, not three independent proofs of anything. Just one recurring worry, told three ways.

Asimov made the literal version even sharper in a 1958 short story, The Feeling of Power, where a future humanity has forgotten how to do arithmetic by hand — machines do all of it — and rediscovering long multiplication is treated as an astonishing, almost dangerous breakthrough. Swap arithmetic for “how a database index works” and you have a Tuesday.

We are building our own priesthood, and mostly we’re enjoying it. Every layer of abstraction we adopt without understanding buys real leverage and quietly adds a little fragility — one more thing that works until it doesn’t, tended by people who can run the ritual but not explain it. The danger was never abstraction itself; abstraction is how engineering makes any progress at all. The danger is fascination — mistaking the gift of the machine for comprehension of it, treating the whole stack as magic that floats on nothing, and forgetting that under every abstraction there is a runtime that will, sooner or later, need someone who knows why.

None of this is a case against the tsunami. I’m not going to stand on the beach telling people to stop building because they can’t yet read the assembly. That would be both wrong and useless — the water is already here, and most of what it brought is good. More people making software is a gift.

The correction I want to make is smaller and, I think, harder to argue with. Reach for the obvious analogy — everyone with a phone is a photographer — and you can feel exactly where it strains. Cheap cameras did flood the world with images, and they did make the people who genuinely understand light and composition and the physics of the sensor more valuable, not less, because now they are rare in a sea of output. That half transfers cleanly. What doesn’t transfer is the stakes: a bad photo just looks bad, while a bad program nobody understands pages someone at 3am or empties an account. Democratizing the making is pure upside when the worst case is a boring picture. It is something more double-edged when the worst case is running in production.

And let me be honest about my own dividing line, because it’s softer than the Meeks quote makes it sound. Understanding isn’t a wall with programmers on one side and dabblers on the other. Nobody understands all the way down — the senior engineer who can debug the slow query can’t debug the CPU’s branch predictor, and Spolsky’s law guarantees every one of us is standing on abstractions we’ve quietly agreed not to open. It’s a gradient, and the only question that matters is which direction you’re moving on it. So the value doesn’t disappear; it moves down the stack, toward the people willing to push their competent layer one rung lower than they strictly had to:

• If you’re building with these tools: use them, ship with them, enjoy the leverage — and keep learning the layer underneath the one you’re working at. You don’t need to write the runtime. You need to be able to read it when the abstraction leaks, because it will.
• If you run a team or a company: you can absolutely generate more software than ever. Just don’t confuse volume with an asset. Code no one understands is a liability with a delay on it. Keep — and pay — the people who hold the theory.
• If you’re just getting in: the fundamentals didn’t get less important because a model can skip them for you. They got more important, because understanding them is now the thing that separates you from everyone who can only ask.

We forget how much the basics and the infrastructure matter, right up until the moment the reactor stops and there’s no one left who knows why. We are replacing the build layer, not the runtime. The runtime is still down there, running the world, obeying its own laws, indifferent to how eloquently we asked.

Someone always has to understand how the runtimes work.

Or pay someone who does.

---

Footnotes

Section titled Footnotes

1. Andrej Karpathy, on X, January 2023: “The hottest new programming language is English.” The line predates the current wave of natural-language coding tools and reads, in hindsight, like a weather report for the storm Rauch is describing. ↩

2. Andrej Karpathy coined “vibe coding” in a February 2025 post: “you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He meant it partly as delight and partly as a warning — the whole point is that you stop reading the code. That’s exactly the move this essay is nervous about when the stakes rise above throwaway toys. ↩

3. The serverless bill is not a hypothetical. The recurring genre of “our $40-a-month side project suddenly cost $72,000” postmortems is almost always a story about an abstraction — pay-per-request, auto-scaling, a recursive trigger — doing precisely what it said it would, to someone who never looked under it. ↩

4. Peter Naur, Programming as Theory Building, 1985. Naur co-created Backus–Naur Form, so this isn’t a skeptic sniping from outside the field — it’s one of its architects arguing that the code is the least durable part of what a programmer makes. The essay is short and worth reading in full; it has aged into one of the most quietly radical things ever written about software. ↩

5. Isaac Asimov, Foundation (1951) — verified against the source, since I first cited it from memory. In “The Mayors,” the kingdoms of the Galactic Periphery (chiefly Anacreon) have lost atomic power and regressed toward coal and oil. The Foundation reintroduces the technology wrapped in a religion it calls Scientism: technician-priests are trained in the operation of the reactors — the rituals — but pointedly not in the theory, which keeps the kingdoms dependent on Foundation-trained specialists to keep the machines running. Salvor Hardin’s whole strategy rests on it: when knowledge becomes ceremony, power flows to whoever still understands the machine. It’s Asimov’s dramatization of exactly the failure mode this post is about — the artifact keeps humming while comprehension drains out of it, until something breaks that no ritual covers. ↩