When the Compiler Becomes an AI Model

Compiler Becomes an AI

8:06

Elon Musk said something last week that sounds outrageous until you actually zoom out: AI is going to make source code obsolete.

Not "programming gets easier." Not "AI writes your code for you." Obsolete. The thing 70-plus years of software engineering has been built around — human-readable source code — stops being the primary output.

My first reaction was the same as everyone else's: no way. My second reaction, after sitting with it for a minute, was less comfortable. He might not be wrong about the direction. He's probably wrong about the timeline. And the gap between those two things is where the interesting argument actually lives.

WHAT MUSK IS ACTUALLY SAYING

He's not saying "programmers disappear." He's saying the artifact changes. For 70 years, the pipeline has looked like this: Human → Source Code → Compiler → Binary

A person writes something readable. A compiler translates it into something a machine can execute. The source code is the intent, expressed in a form humans can read, argue about, and fix. The binary is just the compiled output — nobody reads binaries for fun.

But if an AI fully understands what you want a piece of software to do, why does it need to generate millions of lines of readable text first, just so a second program can translate that text into machine instructions? That's an extra step that exists because humans need something they can read. Take the human reader out of the loop, and the chain gets a lot shorter:

Human Intent → AI → Binary

No intermediate artifact. No text for a compiler to parse. Just intent going in and executable behavior coming out. The compiler doesn't get better. The compiler becomes unnecessary, because the AI is doing what the compiler used to do, minus the part where it needs human-readable input.

THE HISTORY MAKES THE ARGUMENT LOOK LESS CRAZY

This isn't the first time the "artifact" of programming has changed shape. In the 1950s, you flipped switches and wired plugboards. In the 1960s, assembly language gave you something closer to human syntax, but still tied tightly to the machine. From the 1970s through today, high-level languages — C, then Java, then Python, then Rust — kept adding layers of abstraction between what a human writes and what a machine actually executes.

Each step moved the "real" work further away from the metal and closer to human intent. Assembly programmers used to write everything by hand. Now assembly is a specialist skill — still there, still occasionally necessary, but not something 99% of working software engineers touch in a given year.

Musk's bet is that source code itself — Python, JavaScript, whatever you're writing in — takes the same path assembly took. Still there. Still important for the people who need to go that deep. But no longer the default surface most software gets built on.

THE PART MUSK'S PREDICTION GLOSSES OVER

Here's where I get skeptical, and it's not a small thing. Source code isn't just an instruction set for a machine. It's a shared surface for a half-dozen other functions that have nothing to do with execution:

Humans need to review it before it ships. Security teams need to audit it for vulnerabilities. Version control systems need to track what changed and why. Engineers need to debug it when something breaks in production at 2 AM. Regulators need to inspect it for compliance in finance, healthcare, aviation, anywhere software carries real-world consequences. And teams need to collaborate on it — hand code between people, understand what someone else built six months ago, argue about the right way to solve a problem.

Take away human-readable source code, and you don't just lose "how the sausage gets made." You lose the audit trail. You lose the ability to explain what a system did, and why, after the fact.

I spent a long stretch of my career doing digital forensics and incident response — reconstructing what happened inside a system from whatever evidence survived. That work is only possible because systems leave a legible trail. If the "trail" becomes a black box that goes straight from human intent to compiled binary, with no readable intermediate step, you haven't just changed how software gets written. You've removed the thing forensics, security audits, and regulatory compliance were built to examine.

For an AI-generated binary to replace source code as the primary artifact, the AI can't just write correct software. It has to be able to prove correctness, explain its own reasoning, and regenerate an identical binary on demand when someone needs to verify what shipped six months ago actually matches what's running today. That's a fundamentally harder problem than "generate working code." It's closer to "generate working code, plus carry the entire audit and compliance function that used to live in the readable artifact itself."

That's a much taller order than people repeating Musk's tweet seem to appreciate.

WE'RE ALREADY SEEING THE FIRST HINTS OF THIS

Here's the part that makes the prediction less crazy than it sounds on first read: modern AI coding tools are already starting to treat generated code less like a deliverable and more like an intermediate representation.

You describe what you want. The tool generates code. You almost never read all of it. You review the behavior — does it work, does it pass the tests, does it do the thing — far more than you review the implementation. The code exists, technically, but its status has quietly shifted from "the thing you're building" to "the byproduct of building it."

That's a meaningful shift even without going all the way to binaries. The product is becoming behavior. The code is becoming plumbing.

THE REAL QUESTION ISN'T WHETHER CODE DISAPPEARS

I wouldn't bet on source code becoming obsolete anytime soon — especially not for operating systems, safety-critical software, aviation, medical devices, or core infrastructure. The stakes in those categories are exactly the stakes that make "prove correctness and explain your reasoning" a requirement, not a nice-to-have. Nobody's shipping a binary-only flight control system anytime soon, no matter how good the model behind it gets. But I'd absolutely bet that, over the next decade, a growing share of software gets created without a human ever touching the underlying code. Internal tools. Scripts. Automations. The long tail of software that exists to solve one specific problem for one specific team and was never going to get a code review from anyone outside it anyway. That category is enormous, and it's exactly the category where "does it work" matters more than "can I read it."

So the interesting question isn't "does code disappear." It's this: does code become to AI what assembly language became to modern software engineers? Still there. Still important. But something only specialists work with day to day, while everyone else operates one layer up, at the level of intent.

If that's the trajectory, the scarce skill doesn't disappear. It moves. Writing code was never really the valuable part — understanding what needs to exist, specifying it precisely enough for someone (or something) else to build it, and verifying that what got built actually does what you wanted, was always the harder problem. Code was just the medium we used to do all three at once, because it was the only medium available.

Separate those functions, hand the writing to a model, and what's left is judgment, specification, and verification. That's not a smaller job. It might be a harder one — because now you're doing it without being able to just read the thing and check.

That's the part of this prediction that actually matters. Not whether the compiler becomes an AI. Whether we build the verification infrastructure fast enough to trust what it produces.

---

Ad: Use code: RICH99 for a discount

Rich Washburn is a technologist and strategist working at the intersection of AI, infrastructure, and capital. He is Managing Partner and Chief AI Officer at Eliakim Capital.