Josh Bleecher Snyder publishes a post with an explicit title: “Claude is not a compiler.” The argument is that Claude belongs to a different category, superior in some respects. A compiler takes source code and produces binaries deterministically: same input, same output. An LLM takes a natural language description and makes decisions at every level of the stack, from strategy to implementation. Treating it like a compiler means expecting reproducibility that the nature of the tool doesn’t guarantee.

For those running agents in production, the point is practical. If you delegate a complex task to an agent and expect it to produce identical results the next time, you’ll be disappointed. The LLM makes under-specified decisions, like an architect or PM, and the value lies in the number and quality of those decisions, not their predictability. As we covered on July 20 when three papers converged on the same point, the architecture with which you circuit and verify an agent matters more than model power.

Snyder shows this with a real case: his team built a distributed DNS server using Claude for research, design, and implementation. The model worked vertically across the stack, something a compiler doesn’t do. The price is accepting that the same prompt will always give a slightly different result.

In detail

The category mistake.

Snyder had already posed the question in 2025: “Is Claude a compiler?” His answer then was “I don’t know.” Now he’s sure: it belongs to a different category. A compiler operates at a single level, that of translating from source to binary, and does so with deterministic precision. The decisions it makes (inlining, register allocation, warnings) are internal to that level and reliable by construction. The engineer doesn’t have to think about it.

An LLM operates at all levels simultaneously. It can discuss product strategy, system architecture, implementation details, machine code. This is the advantage: as Snyder notes, citing the construction of the Empire State Building, the best projects are those where people working at different levels talk to each other. The LLM does this by itself, without having to schedule meetings.

The price of verticality.

Verticality costs reproducibility. A compiler gives the same output for the same input, always. An LLM doesn’t, and playing with zero temperature or fixed seeds doesn’t change the nature of something making under-specified decisions. When you ask “write me a distributed DNS server,” there are a thousand implicit decisions the model must make, and it will make them slightly differently each time.

Snyder shows this with a real case. His team (exe.dev) had a DNS latency problem: servers started so fast that DNS propagation became the bottleneck. They wrote a custom DNS server, then added regions, and DNS became the problem again. The solution was a geographically distributed and consistent DNS server. Instead of building it by hand level by level, they used Claude for research on distributed designs, DNS protocol quirks, implementation alternatives, down to code. The model worked through the entire stack in a single session.

What it means for builders.

If you’re putting agents in production, the implication is twofold. First: stop expecting the same prompt to produce the same output. It’s the nature of the tool. Second: design for verification, not reproducibility. As three convergent papers showed on July 20, the quality of an agentic system depends on how you circuit your checks, not how predictable the model is.

Snyder doesn’t present a paper with data, but an experience. The limit is this: it’s one person recounting their practice, with a sample size of one. The conceptual point though is solid and converges with what the field is learning from its own mistakes: treating LLMs as compilers leads to frustration, treating them as cross-layer decision makers produces results a compiler couldn’t.