Why Claude Is Not a Compiler but Something Far Better

The argument being made here is really incredible when you unpack it.

1) The construction of the Empire State Building was particularly effective due to the depth of human-to-human collaboration.

2) Isn't it great that we can burn a bunch of dinosaur blood to convince ourselves that we don't need other humans?

Headline true, article false.

AI exists at the boundary of codification. When you understand something well enough to express it in a deterministic way, it is no longer worthwhile to keep asking AI for that thing over and over - you should codify it.

But wait, I hear you say? AI has knowledge! And we can rely on that knowledge and sprinkle on top some brief instructions and it'll get things right and work out the details itself!

That is spec driven development.

And this is great one single time. Except, knowledge shifts. You are outsourcing part of what you've codified to society as a whole, in the form of language model knowledge. You're also trusting current and future models to always produce something that meets the requirements, and never be quantized under you, and produce the same result next time despite being a probabilistic system with no memory, and and and.

Better to freeze everything in place in your codebase so you get predictable results - in other words, codify it! Let's store the desired state of that button in code in a very complicated thing that's existed for decades called a string, so it always says "Finish" and never says "Done" - even if we regenerate the app.

That's pretty unexciting and doesn't justify tens of billions of investment. Which means you won't hear it from anyone with tokens to sell. But it's what you have to do to make something people want.

I've heard something along the lines of "Claude is like a compiler: source code is the new object code, you don't look at that anymore" many times.

And I don't really think this is true. Compilers are usually deterministic, and whilst we can find edge cases, it's nothing like an AI agent writing all the code for you.

I think you have two choices, given the Claude is a code generator and not a compiler: (a) you review most or all of code to make sure it makes sense, or (b) you trust but verify via a strong test suite, potentially also created by Claude.

The problem with (a) is that you lose a lot of the speed-up. The problem with (b) is that you have no human oversight and the code may be incomplete, badly designed, or plain wrong.

Currently we review all code because correctness is extremely important to what we do, but that comes at a cost.

I don't know what the answer is here, in general. Does trust build over time? Do the models just get so good we can trust them to make zero mistakes?

I really like what exe.dev is doing. And their philosophy of how cloud services could work is amazing. I have a monthly subscription and it's really cool to just vibe code a little website with Shelley and have it running in minutes. I feel like I have so much fun using their service, and spend so much less time thinking about what things will cost, or what cloud service to use. It's just so much simpler and the friction is so much less compared to other cloud services.

Specs might become one solution for coping with the need to review increased volume of code. A spec is a higher level of abstraction than code, which is a higher level of abstraction than machine code. The industry made the transition to higher-level once, paradigm is changing so it might happen again.

The workflow I imagine is either deriving specs from the conversation or reverse engineering the code to spec, review and edit the spec which should be tighter and much more compressed, then deterministically compile to code. Of course we don't want to be spec-first only, that would be going back waterfall, but doing iterations back and forth.

Now, Claude is not a compiler because it is closed and non-deterministic (they do opaque processing on server, hiding reasoning tokens), but LLMs might be. We refer to a piece of code from npm/pip by name to get some code by downloading it. We then have lockfiles with hashes to ensure integrity. Currently we are vibing it, but in the future we could refer to a piece of code by prompt/spec and getting the code by inferring it. To ensure integrity, the lockfile would be hashes of open weights and inference code (and ironing out implementation details like non-determinism due to GPU scheduling, etc.).

> Claude wasn’t just a compiler here. I never handed off a task and let an agent make a bunch of decisions in order to reduce it to practice.

> I’d say that, in all the ways that matter, I understand the code.

I think the dissonance here is really important, and not a bad thing at all. A lot of the decision _were_ handed off the the AI, but they weren't the decisions the author cared about. This is a big selling point of AI! If something is doable with a computer, it’ll figure it out. 30 minutes and 200m tokens later, it’ll take any idea and declare “the feature is fully implemented.”

The hard part is figuring out where to inject that friction, so you can see where it's making decisions for you that matter. The author approached this by incrementally building the thing, reviewing and poking and prodding at every step. A week of attention following a bunch of design discussions is fast, but that's still not trivially cheap.

I want to see us talk more about the decision exhaust of agents, because the better the models get, the more decisions we'll want them to make.

I wrote a bit more here: https://tern.sh/blog/compiler-never-says-no/

> I read a vanishingly small amount of the actual code.

This sentiment kind of saddens me. I'm all for burning tokens to write throwaway code just to prototype a solution, but I don't get not reading (or at least familiarizing yourself with) the code that you will deploy to prod.