The Claude Compiler Is Dead. Long Live the Claude Compiler

What happened

Now I have all the article content I need. Let me write the article based on the source material by Shmuel Berman on The Best Worst Case (published September 4, 2026). The key facts from the article:

- Author: Shmuel Berman, ML Researcher - Publication: The Best Worst Case (Substack) - The "Claude-as-compiler" paradigm: treat the LLM like a compiler — write a spec, get code out, treat it as disposable - Why this paradigm failed: LLMs make mistakes and contradict the spec, unlike provably-correct compilers (CompCert reference) - The new paradigm: write a human-readable reference implementation, then ask Claude or GPT to make it more performant — generating kernels and optimizations that can speed up training or inference over 10x - The output is verified with bit-equality tests - More accurately called "transpiling" but author argues to think of it as compilation - The HOPE architecture from the Nested Learning paper (arxiv 2512.24695) — a bug surfaced during a long training run - Current models mentioned: Anthropic's Fable, OpenAI's Astra - Requires pro-level plan or abundance of tokens - Author is a PhD student - There are startups trying to make the original paradigm viable (YC launch mentioned)

A widely shared analogy in developer circles held that giving Claude a natural-language specification and treating its code output as a disposable artifact — the way a programmer treats compiled bytecode — was the right mental model for agentic coding. Shmuel Berman, an ML researcher writing on The Best Worst Case, published a post on September 4, 2026, arguing that this framing has failed as originally conceived and proposing a narrower, more durable version that works with current models.

How it works

This piece covers Berman's argument, the mechanism he uses in practice — asking Claude or GPT to transpile a human-readable reference implementation into a faster optimized version — and the conditions under which the approach holds up today. It is aimed at developers and researchers who use frontier coding agents and want a principled workflow rather than ad-hoc prompting.

During the early wave of agentic coding tools, practitioners popularized the idea of treating LLM-generated code the way one treats compiled binary output: as a temporary, non-portable artifact that can be discarded and regenerated at will, with the natural-language spec serving as the true source of truth. Berman's post traces references to this paradigm across several essays and repository post-mortems, noting that Cloudflare's Claude-generated commit history was a prominent example of developers leaning into this model. The analogy gained enough traction that it shaped how many teams structured their prompting and review processes.

The paradigm did not survive contact with reality in its original form. Compilers are either battle-tested or sometimes formally verified — Berman cites CompCert as an example of a provably correct compiler — and they make well-understood hardware assumptions when optimizing. LLMs contradict the specification, make silent wrong assumptions, and do so in ways that are not predictable in advance. That difference is enough to break the compiler mental model, because a compiler's output being unreadable does not matter; an LLM's output being wrong and unreadable is a serious problem.

Why it matters

Berman's proposed replacement keeps the compiler attitude — treat the generated code as disposable — but changes what the model is asked to do. Instead of specifying a program in natural language and asking an LLM to produce a working implementation, the developer first writes a clean, human-readable reference implementation themselves, then asks Claude or GPT to produce a more performant version of that same logic. The model generates low-level kernels and optimizations that Berman reports can speed up training or inference by more than 10x.

The correctness check is explicit and mechanical: the optimized version must produce bit-equal outputs to the reference for the same inputs. Berman notes this is more accurately called transpiling than compiling, but argues the compiler frame is still useful because it trains the developer to treat the fast output as a disposable artifact rather than code to be read and maintained. He encountered a concrete failure when reimplementing the HOPE architecture from the Nested Learning paper (arXiv 2512.24695): a bug surfaced mid-training-run, which he describes as an acceptable failure rate given current model capability.

The original paradigm asked developers to stop writing code and trust the model end-to-end, which was premature given the error rates of even today's frontier models, including Anthropic's Fable and OpenAI's Astra. Berman's reformulation keeps the developer in the loop at the design stage — they write the reference — and delegates only the performance-engineering step to the model. That division of labor matches what frontier models are actually good at today: finding non-obvious low-level optimizations, not reliably translating an underspecified English description into correct complex behavior.

Who is affected

The practical stakes are real. A 10x improvement in training or inference throughput can meaningfully change the economics of running experiments, especially for PhD students and small research teams who do not have access to large compute budgets. Getting there without spending weeks on manual kernel tuning is valuable. The approach also creates a natural regression harness: the bit-equality tests that verify the optimized version are reusable every time the model is asked to re-generate a faster variant.

Berman is explicit that this workflow is not universal. It requires either a pro-level plan or an abundance of available tokens, because the model needs enough context to understand the reference implementation and generate several candidate optimizations. Researchers and developers working on numerically intensive code — machine learning training loops, inference kernels, simulation backends — stand to benefit most. The approach is least useful for application code where correctness is hard to test with bit-equality and where the performance ceiling is low.

Berman positions himself as a representative user: a PhD student whose code is mostly transitory or demonstrative, where iterating quickly matters and the long-term maintainability of the optimized artifact is not a concern. Teams shipping production services, where the generated code would need to be read, debugged, and extended by multiple engineers, would need to weigh the approach differently. The disposable-artifact attitude only holds if the reference implementation is truly the maintained source of truth and the optimized version is genuinely regenerated rather than edited in place.

What to watch next

Berman closes by noting that the original, more ambitious version of the paradigm — specify in natural language, compile to production code, trust the output — remains theoretically viable and that there are startups actively trying to make it so, including at least one YC-backed company working on trustworthy-by-default coding. The trajectory depends on whether model error rates drop far enough that treating their output as a compiler artifact becomes safe in practice, not just aspirational. CompCert-style formal verification of LLM outputs would be one route; sufficiently comprehensive automated test generation would be another.

For builders using this approach now, the verification step is the load-bearing piece. Before treating any LLM-generated optimization as a drop-in replacement, verify that your test harness actually catches the class of bugs your reference implementation could contain — silent numerical divergence, branching on uninitialized state, or hardware-specific assumptions the model may import without signaling them. Berman's HOPE-architecture experience is a reminder that a long training run is a costly place to discover that the bit-equality tests did not cover the relevant edge case.