Claude Is Not a Compiler

A July 2026 post by Josh Bleecher Snyder on blog.exe.dev, returning to a question he'd left open in early 2025 on commaok.xyz ("Is Claude a Compiler?", answer at the time: I don't know). The answer now is that the question was wrong: "it's a category error, it's better than a compiler."

Why the compiler analogy was tempting

Programs are precise; there is no "wave hands" CPU instruction. High-level goals are the opposite — deeply underspecified. In the standard stylized picture, software gets built in layers that each add specification and hide detail: vision to strategy, product plans to coding plans, code to binaries, with a different role at each step (executive, VP, PM, architect, engineer, compiler).

Every one of those steps is decision-making, because adding specification is making decisions. He notes in passing that this is why one of his two hiring criteria for engineers is judgment (the other is comity).

A compiler is the bottom layer, and it makes real decisions — inlining, register allocation, whether to warn or reject — that drive performance, stability, and failure modes. A compiler engineer's job is arranging for those decisions to be consistently good, and a trusted compiler means the engineer above never has to think about them. Most engineers have no idea how compilers work and don't need to.

So in 2025, with LLMs producing smallish chunks of code, the natural fit was a new layer between engineer and compiler, compiling natural language into code. Its value would then be proportional to reliability times the size of decisions it can absorb.

Why the picture is false

Abstractions leak, layers rub, and we poke holes in them even when they don't. Working across layers is valuable; mechanical sympathy matters.

His illustration is the Empire State Building — under a year, under budget — partly built by systematically ignoring the layer boundaries. On the chrome-nickel steel cladding, nobody involved felt competent to decide alone, so they convened one meeting with the owner, architects, builders, the subcontractors rolling the material, the metal workers fabricating it, the erectors, and the inspectors. He calls this obvious when said out loud, and notes we systematically fail to do it: partly ignorance of what's even worth asking, partly dismissiveness ("what could a line metalworker have to tell me?"), but mostly communication and organizational overhead. Layers exist for a reason — information hiding is what lets organizations scale.

An LLM has none of that overhead. It talks strategy, product, architecture, code, and machine code, and it does so without scheduling a meeting or asking permission. It can't yet match an experienced specialist on any individual task, but it can do all of them. That's the actual advantage, and a single-layer compiler analogy hides it.

The DNS server

The worked example is exe.dev's own infrastructure, and the escalation is worth following because each fix creates the next problem.

exe.dev VMs get names at vm-name.exe.xyz, which means adding CNAME records at VM creation. But their VMs boot fast enough that users ended up waiting on DNS propagation — sometimes minutes. So they wrote their own DNS server, keeping DNS always consistent with the source of truth. Then latency pushed them to add regions, and DNS became the long pole again because it was all served from Oregon; deployments also caused small DNS outages. What they now needed was a geographically distributed but fully consistent DNS server.

Humans settled the top of the stack in person: a general-purpose DNS server with their behavioral tweaks layered on, hub-and-spoke, append-only replication, persistence at the edges.

Everything below that went to agents, and the process is the interesting part — see differential-spec-analysis for the method in general form. He had LLMs research standard distributed-DNS designs, teach him DNS internals and quirks, surface historic security failures, explore alternatives (AXFR/IXFR — "no thanks"), survey open-source options, game out failure modes, and plan testing. Then he prompted multiple concurrent agent loops to build the entire thing, tests and adversarial review included. The agents asked questions at every level, from structural to line-level; answering them (and reverting the answers he regretted) got distilled into terse written guidance.

Then he had fresh agents compare the finished implementations for divergences. His reaction: "It was shocking how many important decisions the agents never asked about but simply made — and made differently."

The concrete case: replication catches up by requesting everything since the last known entry, then long-polls. Database rollbacks are rare but do happen, and they break the append-only contract. Every agent noticed; every agent solved it differently. The design he kept gives each row a randomly generated timeline field — "which timeline are you living in?" — and every "entries since row N" request carries the edge server's timeline value for N. A mismatch means history was altered, and the edge falls back to a full clean re-sync.

There were style differences too. Claude and Codex both agreed Claude's system was more elegant and Codex's more thorough.

He worked through the divergences, experimented, wrote more guidance, and then ran the whole cycle twice more — citing Brooks ("plan to throw one away; you will, anyhow") and Craig Zerouni's follow-up ("if you plan to throw one away, you will throw away two"). What accumulated was a scar-tissue document: empirically sufficient guidance to walk an agent through the decisions that mattered, from goals through architecture down to occasional specifics like the exact data type for a load-bearing concurrent cache.

The keeper shipped with unit tests, end-to-end tests, a shadow mode for de-risking the production rollout, and a written-by-and-for-agents doc suite. Total cost: about a week of his attention. He read a vanishingly small amount of the code.

The validation is social and operational rather than a metric. He presented it to the team before going on vacation, got peppered with "how does X work, what happens in condition Y", and could answer all of it confidently. He took the vacation. DNS incidents in the month after: zero.

Vibe-coding vs vibe-engineering

The distinction he draws is about who makes the decisions, not about how much code you read. Handing off a task and letting the agent reduce it to practice is vibe-coding. What happened here is that Claude acted as "a vertically integrated resource, a multi-compiler," accelerating his decision-making at every level — including the meta-decision of which decisions were important. Most individual lines don't make that cut. He calls that vibe-engineering; vibe-engineering has the concept in full.

His claim to understanding is deliberately scoped: hand-editing the code now would mean a real learning curve, but he won't have to. What he retains is the ability to reason about the system, share that reasoning with colleagues, and steer agents on future work — plus a durable artifact recording the intentional parts of the design across all layers, which should outlive bug fixes and churn.

The closing question

"What do software engineers need to understand about the systems they work on?"

His answer is that well-chosen layers provide understanding, and that's the survival criterion. Fundamental physics is more all-encompassing than classical mechanics but worse at explaining why you'd rather be in a bus than a car in a crash. Layers that only provide convenience are dying — he names Tailwind, with regret. Layers that let us express important decisions comprehensibly will stay.

Attention shifts up the stack without fully letting go of the bottom. Agents are not a free pass to abandon understanding of the deeper layers: most of the Go standard library is Go, but a few key routines are assembly, and there you can't rely on the compiler. He ends on engineers being stretched — "exhilarating and exhausting" — and the prediction that "in the near future, vibe-engineering is just…engineering."

Where it sits

This is the constructive counterpart to agent-principal-agent-problem from the same company: Crawshaw diagnosed why review broke and described the compensating machinery abstractly; this post is a full worked instance of that machinery on a real system, with the artifact (the scar-tissue doc) named.

On the read-the-code question it lands near control-the-ideas-not-the-code — antirez also owns the design and skips line-by-line review — but the mechanism differs. antirez interrogates one model about its design to check his mental model; Bleecher Snyder gets the same information by building the system several times in parallel and diffing the results. Both are opposed by reviewing-ai-code and cult-of-vibe-coding, and danluu-ai-coding-testing is the third position (heavy testing substitutes for review).

Cross-references

• vibe-engineering — the concept and its boundary against vibe-coding
• differential-spec-analysis — build N times, diff, codify; the reusable method
• exe-dev-blog, crawshaw-blog — the company blog and the co-founder's personal one
• agent-principal-agent-problem — the problem this is a worked answer to
• control-the-ideas-not-the-code, reviewing-ai-code, danluu-ai-coding-testing — the three positions on reviewing agent code
• peril-of-laziness-lost — the counterweight on unconstrained generation