Compilers Are Cached Reasoning

I. The Heresy

There is an idea circulating in the technology world that sounds, on first hearing, like something people say after one keynote too many. It goes like this: programming languages are a temporary arrangement. Python, Java, C — all of it is scaffolding, put up for the benefit of human beings, who need words like while and return because they cannot think in voltages. Once artificial intelligence is good enough, the argument runs, it will dispense with the scaffolding. It will skip the source code, skip the compiler, and write the binary directly: the raw ones and zeros the processor actually eats.

My first instinct was to dismiss this. Then it occurred to me that “this sounds wrong” is not the same thing as “this is wrong,” and that the first is often just the sensation of a familiar world being threatened. So I did what has become a slightly strange habit of mine. I argued about it with an AI.

The machine began, as I had, with the textbook rebuttal. Compilers are deterministic; language models are probabilistic. Feed a compiler the same source twice and you get the same binary twice. Feed a model the same prompt twice and you may get two different programs. Source code can be reviewed, diffed, and audited, while a binary blob emitted by a neural network is about as opaque as an artifact gets. Four decades ago, in his Turing Award lecture “Reflections on Trusting Trust,” Ken Thompson warned that we can never fully trust code we did not write ourselves, not even when it passes through a compiler. An unauditable AI compiler would be his nightmare at planetary scale.

All of that is true. But as we picked it apart, the most famous objection — determinism — turned out to be weaker than it looks. You can make a language model deterministic. Fix the random seed, set the temperature to zero, engineer away the floating-point noise inside the GPU, and the same prompt yields the same bytes every time. What you would have then is a machine that is deterministically wrong: it would hand you the identical subtle bug on every run.

Determinism was never the property we cared about. It was a stand-in for two deeper ones. The first is semantic preservation. A compiler is built to carry the meaning of a program, intact, from one representation to another. It honors a contract — the specification of the language — and when it breaks that contract, we call it a bug and fix it. (Some researchers went further and built CompCert, a C compiler whose correctness is mathematically proven.)

The second is stability. Change one line of source and, roughly speaking, one region of the binary changes. That locality is invisible infrastructure. It is what makes incremental builds, caching, reproducible builds, and the patient archaeology of git bisect possible. A model that writes binaries could reshuffle an entire program in response to a one-word change in its instructions.

So the honest version of the objection is not “AI is random.” It is this: compilers are stable, meaning-preserving functions, and AI, by default, is neither.

That is a strong objection. But it is an objection about AI as it exists today. What I wanted to know was whether it was an objection to the idea itself. So we tried an experiment.

II. A Genie in 1955

Imagine it is 1955. Among the most important computers in the world is the IBM 704, a room-filling machine fed by punch cards. There are no programming languages in the modern sense. There is machine code, and there is assembly, a thin mnemonic veneer over it. Now drop a single anachronism into this world: a superintelligence that can listen to what you want and write flawless machine code to do it.

Does anyone invent FORTRAN?

To answer, you have to remember why FORTRAN was invented. It was not born of an aesthetic. It was born of a budget. When John Backus proposed it at IBM, the problem was that programmers had become the expensive part of computing. Backus later recalled that programming and debugging could account for as much as three-quarters of the cost of running a computer. The machines were fast. The people were slow, error-prone, and forgetful.

What strikes me now is how much resistance the idea faced. Early compilers went by the name “automatic programming,” and many experts doubted that a machine could ever write code as good as a skilled human’s. Grace Hopper, whose A-0 system was among the very first compilers, later described being told that computers could only do arithmetic, not write programs. Backus’s team obsessed over optimization precisely because they knew programmers would reject anything slower than hand-written assembly. If that skepticism sounds familiar, it should. We are having the same argument again, one floor up.

Every language since FORTRAN has been, at bottom, a prosthetic for some human limitation. Named variables exist because we cannot remember what lives at a given memory address. Loops and functions exist because we lose the thread after a few dozen instructions. Type systems exist because we make mistakes we cannot see. Readable syntax exists because programmers work in teams and must understand one another. Portable languages exist because rewriting a program for each new machine was ruinously expensive in human labor.

Now hand all of that work to the genie. Its working memory is not limited to a handful of items. It does not make typos. It does not need colleagues to read its code, because it has no colleagues. Every pressure that produced FORTRAN, then C, then Java and Python, simply evaporates. In the genie timeline, I suspect, the lineage of programming languages as we know it never begins.

The consequences do not stop at software. Our hardware, too, was shaped by human programmers and their compilers. In the late 1970s, researchers at IBM led by John Cocke noticed that compilers used only a small fraction of the elaborate instructions processors offered. That observation helped launch the RISC architectures that now sit inside nearly every phone. Decades later, Intel’s Itanium bet on a design that needed compilers to schedule instructions with near-clairvoyant foresight; the compilers never quite delivered, and the chip became one of the industry’s costliest disappointments. Sony’s Cell processor, inside the PlayStation 3, was an engineering marvel that developers famously dreaded.

In the genie timeline, those failures become triumphs. If the programmer is superintelligent, “hard to program” stops being a design constraint. Chip designers can optimize for raw speed and efficiency alone: exposed pipelines, hand-managed memory, exotic dataflow machines.

Push further, and even the instruction set — the sacred contract between hardware and software that has kept x86 alive since 1978 — begins to dissolve. Backward compatibility exists because rewriting software is expensive. If regenerating every program for a new chip costs almost nothing, each generation of silicon can speak its own tongue. Eventually the genie might design the chip and the program together, as a single object.

Software itself would change texture. Today we maintain programs: we patch them, refactor them, and accumulate technical debt over decades. In the genie timeline, software is not maintained but re-derived. You do not fix it. You restate what you want, and a new one appears.

At this point in the thought experiment, the bold idea looks not merely plausible but correct. Then the genie starts causing trouble.

III. What the Genie Can’t Fix

The first trouble is the oldest one in folklore. Genies give you what you say, not what you mean.

Imagine a bank in 1962 whose payroll system has been written by the superintelligence from a manager’s spoken description. One day it does precisely what the manager said and not at all what he intended. There is a lawsuit. Lawyers argue over what a sentence meant; so do engineers. And slowly, painfully, the society realizes it needs a way of stating intent that admits exactly one reading.

That is to say: it invents a language. Not a language for telling the machine how to do something, but one for stating what must be done and what must never happen. Our own timeline has such languages — specification languages like TLA+, proof assistants like Lean — but they live at the margins of the profession, used mostly by mathematicians and by engineers building systems where failure is unthinkable. In the genie timeline, I would bet they arrive decades before anything like C, and become the only programming most humans ever do. The craft shifts from instructing the machine to articulating desire with precision. Programmers become something closer to legislators.

The second trouble is trust. Suppose the genie writes the control software for a 1960s missile-defense system. No human can read it. No one can inspect how the genie thinks. Why should anyone believe the binary does what the specification says?

One option is simply to trust the genie, which is the AI-alignment problem in period costume. The other is to demand proof. And here, again, our timeline has already sketched the answer. In the late 1990s, the computer scientists George Necula and Peter Lee proposed what they called proof-carrying code: a program that arrives bundled with a mathematical proof that it obeys a given policy, checkable by a small and simple verifier.

The elegance of this arrangement lies in what it removes from the circle of trust. You no longer need to trust the compiler. You no longer need to trust the genie. You need to trust only the proof checker, a piece of software small enough for a human being to read line by line, the way one might audit a constitution. Everything between the specification at the top and the binary at the bottom can be alien, unreadable, even produced by a process that makes different choices every time. If every binary arrives with a valid proof, randomness stops mattering. The genie can hand you a thousand different programs, and each will be provably correct.

Notice what has happened. The objection we started with — AI is random, compilers are deterministic — has not been refuted so much as made irrelevant. Trust has moved from the process to the artifact.

IV. Cached Reasoning

There is one more turn in the story, and it is the one that gives this essay its title.

Suppose the genie has been at work for a decade. It has written millions of programs, and many of them resemble one another: sort these records, parse this file, draw this window, move money from one account to another. Every time, it reasons from first principles all the way down to the voltages.

Even for a superintelligence, that is wasteful. Thinking costs something — time, energy, computation. And any intelligent agent that solves the same kinds of problems again and again eventually does the same thing: it builds a tool. A clever person who keeps doing a tedious task by hand writes a script. The script is a record of thinking already done, reusable for almost nothing.

So the genie, left to its own devices, would build itself compilers. Not because it needs readable code, but because reasoning is expensive and caching is cheap. It would develop intermediate representations, translation rules, and libraries of verified patterns, all tuned to its own purposes and quite possibly incomprehensible to us. For novel problems, one-off tasks, or programs where every nanosecond matters, it would still write machine code directly. For everything routine, it would reach for its cache.

That reframes what a compiler is. We tend to think of compilers as translators, machines that turn one language into another. A compiler is better understood as cached reasoning: decades of human thought about how to turn intent into efficient instructions, frozen into a procedure you can run a billion times for the price of electricity. Every optimization pass in a modern compiler is an insight some engineer had once, so that no one would ever need to have it again.

This, I think, is where the “AI will just emit binaries” idea goes wrong — not in its ambition, but in its economics. In his influential essay “The Bitter Lesson,” the AI researcher Rich Sutton observed that, across the history of the field, general methods powered by computation keep defeating human-engineered cleverness. It is tempting to read programming languages and compilers as exactly the kind of cleverness the lesson predicts will be swept away.

But look at what the Bitter Lesson actually swept away: handcrafted vision features, rule-based speech pipelines, expert-written chess heuristics. In each case, the human-built thing was an approximation of something messy, and learning approximated it better. A compiler is not an approximation. It is an exact transformation that runs in milliseconds. Replacing an exact, cheap procedure with an approximate, expensive one runs against the Bitter Lesson, not with it.

It is the same reason a modern AI model, asked to multiply two large numbers, reaches for a calculator rather than predicting the digits one by one. It could predict them. Nothing would be gained.

The deeper point is that reasoning and caching are not rivals. Intelligence produces insight; caching makes insight cheap. A world full of superintelligences would not have fewer compilers. It might have vastly more, most of them written by machines, for machines.

V. Language Lives at the Border

Step back, and the whole thought experiment resolves into a single principle. Language is what you need when two parties must agree on something and cannot share a mind.

Inside a single mind, there is no need for language; thought simply happens. Between minds, language is unavoidable. Programming languages sat on two such borders: between humans and machines, and between humans and other humans — the teams who had to read and extend one another’s work. Remove humans from the labor of implementation, and those particular languages collapse. But language does not vanish. It migrates to every border that remains.

Between human and superintelligence, it becomes the specification: the precise statement of what we want. Between the superintelligence and the verifier, it becomes the proof. Between one program and another, it becomes the protocol, the file format, the interface, because systems built independently must still agree on what a message means. And between one superintelligence and another, built by different companies or in different decades, there must be some shared representation too. Even gods need treaties.

So was the bold idea right? Partly, and in a deeper way than its champions usually mean. Rewind to 1955 and add a superintelligence, and I believe most software would be written as machine code, by machine. The C, Java, and Python era would never happen. The idea is right about implementation languages. Where it overreaches is in imagining that language itself disappears. Language moves: up into specification, sideways into proofs and protocols, inward into the private compilers of the machines themselves.

Which brings us back to the present, and to an uncomfortable suggestion. Our programming languages — the ones we teach, argue about, and build careers on — may be, in part, a fossil of an era when humans were the bottleneck. They resemble the conventions of the medieval scriptorium: the abbreviations, the ruled margins, the careful hands that made sense when every book was copied by a person, and that lingered long after the printing press had made them unnecessary.

We will not shed them quickly. We carry decades of legacy code, toolchains, institutions, and habits that the 1955 timeline never had to carry. But if the thought experiment points anywhere, it points here: toward a future in which the human contribution to software is not instruction but intention, stated precisely enough to be proved; in which trust rests on small, readable checkers rather than on our ability to read everything; and in which the machines, whatever else they become, keep building tools for themselves, because even the most powerful mind would rather remember an answer than derive it twice.

The compiler, in that world, does not die. It is revealed for what it always was: not a translator, but thought, saved for later.