AIArticle exe.dev's case for not reading AI-generated code is the sharpest yet, but it borrows a guarantee LLMs don't offer.
Rachel Goldstein Eighteen months ago, Josh Bleecher Snyder asked "Is Claude a compiler?" and gave the only honest answer available at the time: I don't know. This week he answered himself, and the answer is more interesting than the usual yes or no. It's a category error, he argues — Claude is better than a compiler, because a compiler transforms one abstraction layer into the next while an LLM can work vertically across all of them, from product strategy down to machine-level details.
Snyder is worth taking seriously here. He's a longtime contributor to the Go compiler and runtime — someone who knows exactly what a compiler is and isn't — and co-founder of exe.dev, the persistent-VM platform he started with former Tailscale CTO David Crawshaw. The essay's centerpiece is a real project: a geographically distributed DNS server for exe.dev's VMs, built in about a week of his attention. His method wasn't "prompt, receive code, ship." He had Claude research distributed DNS designs, then generate multiple complete implementations, then diff them — not line by line, but decision by decision — to surface places where his spec was silently underspecified. Divergences between versions (how to handle database rollbacks, for instance) became questions he actually needed to answer. He says he read "a vanishingly small amount of the actual code."
The Hacker News thread landed on that last sentence like a ton of bricks, and both sides deserve a fair hearing. Here's mine.
The part he's right about #
The vertical-stack observation is the strongest claim in the essay, and it's underrated. Traditional software organizations are a stack of lossy translations: vision becomes strategy, strategy becomes plans, plans become code, code becomes binaries, each step owned by a different role. Compilers automate exactly one of those hops, which is why they changed programming but didn't change org charts. An LLM that can operate at every layer — and, crucially, carry context between layers — attacks the coordination cost itself. As Snyder puts it, abstractions leak and "layers rub," and a tool that moves freely across them is valuable in a way a single-layer transformer never was. That's not hype; it's a fair description of what anyone who's used an agent for real work has felt.
The multi-implementation diffing technique is the most practical idea in the piece, and it deserves to be stolen. It rhymes with N-version programming, the 1970s fault-tolerance idea of running independently developed implementations in parallel — an idea that famously fell apart when Knight and Leveson showed in 1986 that "independent" teams make correlated mistakes. Sampling one model several times has the same correlation problem, worse. But Snyder isn't using redundancy for reliability. He's using divergence as a spec-discovery instrument: where three generated implementations disagree, your requirements were ambiguous. For that purpose, correlated failures don't sink the method — anything the implementations disagree on is signal, and what they agree on you still have to verify by other means. That reframing is genuinely new, cheap to try, and works today: generate two or three full implementations of your next well-scoped service and diff the design decisions before you bless one.
The part that doesn't follow #
Here's the problem. "Don't read the compiler's output" was never a free-floating norm — it was earned. Compilers get that trust because they're deterministic, specified, tested against decades of adversarial use, and boring in the best sense. Even then the trust is conditional: the reproducible-builds movement exists, compiler bugs ship, and Go itself has had miscompilations that only surfaced because someone eventually read the generated code. The compiler analogy is precisely the thing that made "I didn't read the code" sound safe. Snyder's essay demolishes the analogy and keeps the conclusion. You can't have both. If Claude is a category error away from a compiler, then the compiler's inherited trust doesn't transfer, and "vanishingly small amount of code read" needs a replacement warrant.
The HN crowd's sharpest objection is really Peter Naur's 1985 point about programming as theory building: a program is only alive while someone holds the theory of it in their head, and you don't get the theory by skimming a spec. Snyder's implicit answer is that the theory can live one layer up — that "most individual lines of code don't make that cut," and what matters is recording decisions at the level where they're made. For a DNS control plane at a startup, with a founder who can regenerate the whole thing in a week, that's a defensible bet. The blast radius is small and the author is exactly the kind of engineer who knows which questions to ask. Generalize it to a payments path or an auth boundary and it stops being engineering judgment and starts being a dice roll with good vibes.
What to actually do with this #
The workable synthesis isn't mysterious, and Simon Willison already named it: vibe engineering, the disciplined end of the spectrum where you accelerate with agents but stay accountable for the output. Snyder's essay is the best field report yet from that end of the spectrum, and its techniques compose cleanly with the discipline it underplays. Concretely: use multi-implementation diffing to flush out ambiguity before committing to a design. Write down decisions, not code walkthroughs. Replace the trust a compiler would have given you with things an LLM pipeline can actually provide — property tests and invariants you author yourself, differential tests between generated versions, and a hard rule that code touching security boundaries, money, or irreversible data operations gets read by a human, every time. The senior engineers who thrive in this model are the ones who know where those lines are; the real risk is juniors adopting the "don't read it" posture without the taste that makes it survivable.
Snyder ends by predicting that "vibe-engineering is just…engineering" — that the modifier disappears once this is simply how software gets built. He's probably right about the destination. But we're in the awkward interval where the old guarantee is gone and the new one isn't built yet, and the honest version of his essay's title cuts the other way too: Claude is not a compiler, so stop extending it a compiler's credit.
Sources & further reading #
[Claude Is Not a Compiler](https://blog.exe.dev/claude-is-not-a-compiler)— blog.exe.dev -
[Claude Is Not a Compiler - discussion](https://news.ycombinator.com/item?id=48993059)— news.ycombinator.com -
[Vibe engineering](https://simonwillison.net/2025/Oct/7/vibe-engineering/)— simonwillison.net
[Rachel Goldstein](https://sourcefeed.dev/u/rachel_goldstein)· Dev Tools Editor
Rachel has been embedded in the developer tooling ecosystem for nearly eight years, covering everything from IDE wars and package-manager drama to the quiet rise of AI-assisted coding. She has a soft spot for open-source maintainers and an unhealthy number of terminal emulators installed on a single laptop.
Discussion 0 #
No comments yet
Be the first to weigh in.