Most harness engineers focus on the wrong artifact. They version the generated code, debate which model wrote cleaner TypeScript, and treat a model swap as a migration risk. Ryan Lopopolo has a different frame, one that cuts through all of that. At the AI Engineer Europe 2026 keynote [11], he put it directly: “I think like using LLM as fuzzy compiler is like an interesting mental model to have” [1]. The LLM is a compiler backend. The generated code is machine code: it runs, it is correct, and it is disposable.
This is Part 3 of the 3-part OpenAI Lopopolo sub-series. Garbage Collection Day: A Weekly Ritual for Reducing Agent Slop established how you improve the spec week by week. Token Billionaire Economics: Where 1B Output Tokens Per Day Actually Go showed why the economics force you to treat harness quality as primary work. This article names the mental model that ties both of those together.
Figure 1 - The Fuzzy Compiler Pipeline: The classic compiler transforms source code through static analysis and optimization passes into machine code. The harness does the same thing: spec and docs as the source language, lints as static-analysis passes, reviewer-agent prompts as optimization passes, the LLM as the codegen backend, generated source as the output. The parallel is deliberate and precise [1].
Code Is Free, Code Is Disposable
Lopopolo opens his keynote with a premise that shapes everything that follows: “Implementation is no longer the scarce resource of what it means to do the job of software engineering. Code is free. We have an abundance of code to solve the problems that we come across in our day-to-day” [1].
If you accept that premise, a great deal follows. If code is free to produce, it is also free to throw away. Refactors that used to be blocked by maintenance-cost concerns are now free to launch. Migrations that sat open for six months because the last few packages were too tedious to touch are now completable in a day with fifteen parallel agents. The arithmetic that made “we can’t afford to rewrite this” a reasonable engineering position no longer holds.
The audience at AIE Europe pushed on this directly during the fireside Q&A. Was code really a disposable build artifact? Lopopolo’s answer was yes. That is not a rhetorical position. It is an operational one. At a one-million-line codebase being driven by a three-engineer team generating three to five PRs per engineer per day [1][10], you cannot afford to treat generated code as precious. The model wrote it; the model can rewrite it. What you maintain is the spec, a practice Lopopolo also documents in OpenAI’s engineering writeup on harness engineering [9].
Figure 2 - Two Mental Models of What You Actually Maintain: In the conventional model, code is the primary artifact and specs are documentation written around it. In the fuzzy-compiler model, the spec is the primary artifact and generated code is an ephemeral output, regeneratable at any time from the same spec with any compliant backend. The choice of which mental model you hold determines every subsequent architectural decision [1].
The Compiler Analogy, Enumerated
The analogy works because it maps to a complete, well-understood system. We will walk through every row, because the brief framing in the keynote repays close reading.
Source language (Rust, C) maps to the spec, docs, and ADRs. This is the durable artifact. In a conventional compiler, you do not maintain the x86 machine code, you maintain the Rust source. In a harness, you do not maintain the generated TypeScript or Python, you maintain the spec, the architecture decision records, and the persona-oriented documentation that describes what acceptable output looks like. Lopopolo frames this as “leaving breadcrumbs, documentation, ADRs, persona oriented documentation around what a good job looks like” [1].
Static analysis passes map to lints. In LLVM’s pipeline, static analysis catches undefined behavior, type violations, and structural problems before any code is generated. In a harness, bespoke ESLint rules, package-privacy lints, and source-code tests that enforce the 350-line file cap play the same role. They run on every push and reject output that violates the structural constraints of the codebase [1].
Optimization passes map to reviewer-agent prompts. LLVM’s optimization passes transform the intermediate representation to make the output more efficient, eliminating dead code, inlining hot paths, vectorizing loops. Reviewer agents (front-end architect, reliability engineer, scalability engineer) do the same work at the harness level: they examine the generated output against discipline-specific standards and surface the P2-or-above issues that would degrade quality [1]. Their prompts are the optimization pass definitions.
The codegen backend (LLVM, Cranelift) maps to the LLM. This is the heart of the analogy. The backend takes the intermediate representation and produces machine code. The LLM takes the spec-and-context prompt and produces source code. You swap the backend, you get different machine instructions. You swap the model, you get different source code. In both cases, the output is still valid if the spec constraints are met.
Generated machine code (x86 instructions) maps to generated source code (TypeScript, Python, Elixir). The x86 instructions are not the thing you care about, the correct execution of the program is. The generated TypeScript is not the thing you care about, the correct implementation of the spec is. Both are build artifacts.
Compiler output correctness guarantee maps to spec constraints. The compiler guarantees that valid Rust source, processed through valid passes, produces valid machine code for the target architecture. The harness guarantees that a spec-conforming prompt, processed through lints and reviewer agents, produces acceptable source code. Lopopolo says this directly: “all of the rules around what acceptable Rust code looks like produce valid sound machine code out the back, even if the generation process is different and you end up with different x86 instructions” [1].
KEY INSIGHT: The spec constraints are the correctness guarantee, not the model. If your spec constraints are weak, the model will produce inconsistent output regardless of which model you use. If your spec constraints are tight, any compliant backend produces acceptable output. Model selection is a performance decision, not a correctness decision.
Figure 3 - The Full Compiler-to-Harness Mapping: Each classical compiler concept maps to a precise harness-engineering counterpart [1]. The mapping is not loose metaphor; it is a design prescription. If you treat each row as an engineering decision, you get a complete harness architecture: spec documents to maintain, lints to enforce structural constraints, reviewer agents to enforce discipline-specific quality standards, model selection as a backend choice, generated code as ephemeral output, and spec constraints as the correctness contract.
The LLVM-to-Cranelift Beat
The keynote’s most specific analogy is the swap from LLVM to Cranelift as the Rust compiler’s codegen backend. It is worth holding onto precisely because the precision matters.
The Rust compiler uses LLVM as its production codegen backend. LLVM is approximately 20 million lines of code, extraordinarily mature, and produces highly optimized machine code [2]. Cranelift is a newer alternative maintained by the Bytecode Alliance, approximately 200,000 lines of code, built in-tree with the Wasmtime WebAssembly VM [2]. The rustc_codegen_cranelift project, maintained under the rust-lang organization, integrates Cranelift as an optional backend for the Rust compiler [3].
Here is the caveat the article must state clearly: Cranelift is experimental and nightly-only for rustc. It is distributed in Rust nightly builds for Linux, macOS, and x86_64 Windows as an optional component. It is not production-recommended for Rust builds as of 2026. SIMD support is incomplete; panic unwinding in the Cranelift path is still experimental [3]. You cannot drop it in as a production swap today.
What you can observe is that the principle holds. Compile the same Rust source with LLVM and with Cranelift, and you get functionally equivalent programs. The generated x86 instructions differ, sometimes substantially. Cranelift compiles roughly 30% faster than LLVM in debug mode, but produces output that runs approximately 14% slower [2]. The spec constraints, meaning the Rust type system, the borrow checker, and the target ABI, guarantee correctness for both backends even though neither backend’s output is identical to the other’s.
The analogy maps cleanly to model swaps. Swap GPT-5.2-Codex for Claude Sonnet 4.6 in the same harness, and you get different generated source code. Different functions, different variable names, different structural patterns. The harness’s spec constraints (lints, reviewer agents, structural tests) guarantee that both outputs are still acceptable. Neither output is identical to the other. Both pass the correctness contract.
The Cranelift caveat also maps. Just as Cranelift produces less-optimized output in exchange for faster compilation, a weaker or smaller model may produce less elegant code in exchange for lower cost or faster latency. The spec’s job is to define “acceptable,” not “identical.” A Cranelift-compiled Rust program that runs 14% slower is still correct. A lower-tier model’s generated code that has more verbose patterns is still mergeable if it passes the lints and reviewer-agent checks.
KEY INSIGHT: Model selection is a backend tradeoff, not a correctness decision. A less capable model (faster, cheaper, less optimized output) is the Cranelift option. A more capable model (slower, more expensive, more optimized output) is the LLVM option. What guarantees correctness in either case is the spec constraints, not the model.
Figure 4 - Same Source, Different Instructions, Spec-Guaranteed Correctness: The same Rust source compiled with LLVM (production, optimized) versus Cranelift (experimental/nightly, faster compile, ~14% slower runtime) produces functionally equivalent but instruction-different output [2][3]. Both outputs satisfy the correctness contract because the Rust type system and borrow checker define correctness, not the backend. The same principle applies to LLM model swaps: different source code out the back, spec constraints as the correctness guarantee.
Symphony: The Mental Model Made Real
Lopopolo does not leave the fuzzy-compiler framing as abstract theory. He names a concrete project that embodies it at the library level. Immediately after introducing the analogy, he references the OpenAI agent orchestrator he and his team open-sourced: “We can publish a library that’s actually a super well-defined spec that the code is a compiled artifact of” [1].
That library is Symphony.
OpenAI open-sourced Symphony in April 2026 [4][5]. The release structure itself demonstrates the mental model. Symphony is not primarily a code release. It is primarily a SPEC.md. The SPEC.md is a language-agnostic, language-neutral behavioral specification that describes how Symphony works: the architecture, the contracts, the expected behaviors, the orchestration model. The Elixir code (95.6% of the repository by language) is one compiled artifact of that spec [4].
The InfoQ coverage from May 17, 2026 captures the framing precisely: “Symphony is not a complex supervision system, but rather a SPEC.md file describing the problem and its solution that every organization can use to create its own orchestrator” [6]. The SPEC.md invites teams to implement Symphony in their own language. Each implementation is a different compilation of the same spec. OpenAI’s Elixir implementation is the reference compilation, the LLVM-optimized binary if you like, but any language that satisfies the spec produces a valid Symphony.
The GitHub repository description reinforces this: “Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents” [4]. At 25,000-plus stars and 2,500 forks, the community has clearly engaged with the SPEC.md-first approach. The spec is the artifact that travels; the Elixir code is the example of what it compiles to.
This is not a coincidence of naming. Lopopolo designed Symphony to be a spec-as-source-of-truth project and released it that way deliberately. The mental model predicts the release format, and the release format validates the mental model.
Figure 5 - Symphony: SPEC.md as Source of Truth, Implementations as Compiled Artifacts: OpenAI open-sourced Symphony as a SPEC.md plus an Elixir reference implementation [4][5]. The SPEC.md is the durable artifact. The Elixir code is one compiled instantiation. Any team implementing Symphony from the SPEC.md in any language is producing a different compiled artifact of the same spec. This is the fuzzy-compiler mental model applied at the library level.
Practical Consequences
Three operational changes follow from taking the fuzzy-compiler model seriously.
Maintain the spec, not the code. If generated code is a build artifact, your engineering investment goes into the source: the spec documents, the ADRs, the persona-oriented documentation, the lints, the reviewer-agent prompts. These are the components that make up an agent harness [12], and they are the things that persist across model swaps, across refactors, across complete rewrites. The code that satisfies those constraints is regeneratable at any time. The constraints themselves are what you need to protect.
Our companion article on Garbage Collection Day covers the weekly ritual that keeps the spec improving. Every lint Lopopolo’s team adds on a Friday afternoon is a new static-analysis pass. Every reviewer-agent prompt update is a new optimization pass. The GCD ritual is the spec’s maintenance schedule. Without it, the spec drifts, and the model’s output drifts with it.
Distrust intuitions that depend on code being precious. If your mental model puts generated code at the center, a lot of reasonable-sounding engineering decisions follow: avoid large refactors because they risk breaking things, be conservative about model swaps because the existing code was hard to get right, never delete code you might need later. The fuzzy-compiler model dissolves all of these. Code is free to produce and it is free to discard. A refactor that improves the spec’s static-analysis coverage is worth the generated output that follows.
Plan for model swaps. A new model arrives. Your spec constraints are well-defined. You run it through the harness and check whether the lints pass, whether the reviewer agents surface blockers, whether the structural tests hold. If they do, you have a new backend. The generated code will look different. That is expected and fine. If the spec constraints are your correctness guarantee, the new model’s output is acceptable by construction. Our companion article on token economics covers why the cost incentive for model swaps will only grow: the arithmetic of a billion daily output tokens makes backend selection a significant dollar decision, and the fuzzy-compiler frame makes it a clean engineering decision rather than a migration risk.
KEY INSIGHT: Harness quality is portable across models in a way that generated code is not. The spec, the lints, and the reviewer-agent prompts you build today will work with models that do not exist yet. The generated code you are proud of today will be regenerated by those future models.
Figure 6 - Three Practical Consequences of the Fuzzy-Compiler Model: Maintaining the spec rather than the code means the durable artifact is always the spec. The Garbage Collection Day ritual keeps the spec’s static-analysis and optimization passes current [7]. Model swaps become backend switches: the spec constraints define what is acceptable, and any compliant model produces acceptable output [1].
Closing the Sub-Series
This is the third article in the OpenAI Lopopolo sub-series, and the three pieces form a complete picture that is worth seeing all at once.
Garbage Collection Day established the mechanism: once a week, convert observed agent failures into durable lints, structural tests, and reviewer-agent prompt updates. The GCD ritual is how the spec improves over time [7]. In the fuzzy-compiler frame, it is your static-analysis and optimization pass development cadence.
Token Billionaire Economics established the scale and the economics: a billion daily output tokens, a third on planning, a third on documentation, a third on implementation and CI [8]. The two non-implementation thirds are investments in the spec, not overhead. In the fuzzy-compiler frame, that spend is your source-language maintenance budget.
This article names the mental model: the LLM is a codegen backend, the spec is the source language, generated code is a build artifact [1]. It is the framing that makes sense of both the GCD ritual (you are writing better passes) and the token allocation (you are investing in the source, not the binary).
The three together give a concrete engineering program. Write good specs. Improve them continuously via the GCD ritual. Budget tokens for that investment. Expect model swaps and design for them. The generated code is what comes out the back.
Figure 7 - The Lopopolo Sub-Series as a Complete Engineering Program: The Garbage Collection Day ritual [7] improves the spec’s static-analysis and optimization passes. Token Billionaire Economics [8] explains why the two-thirds non-implementation spend is the compounding investment. The fuzzy-compiler mental model [1] names what the spec is (source language) and what generated code is (build artifact), making the GCD and economics arguments structurally coherent.
The Model Swap in Practice
One implication of the fuzzy-compiler framing deserves its own treatment, because it changes how you evaluate a model swap proposal.
The conventional argument for staying on a model once it is working well sounds like this: the existing code was generated with this model’s particular patterns, and switching models will produce different patterns, and that inconsistency will confuse the next model in the context window. This argument treats the generated code as load-bearing. It is a reasonable concern if you believe the generated code is the primary artifact.
The fuzzy-compiler model says this concern is misplaced. The spec constraints, meaning the lints, the structural tests, and the reviewer-agent prompts, enforce a canonical form regardless of which model generated the code. The 350-line file cap applies to every file, regardless of which backend wrote it. The package-privacy lint applies to every import edge, regardless of which model defined it. The front-end-architect reviewer surfaces the same issues whether GPT-5.2-Codex or Claude Sonnet 4.6 wrote the component.
If the spec constraints are tight enough, the “inconsistency” concern dissolves. The next model in the context window reads code that looks the same because the lints and tests enforced a canonical form, not because the same model wrote everything.
This is why Lopopolo frames model swaps as “the same sort of mindset” [1] as changing your codegen backend. If you have tight spec constraints, changing backends is routine. If you do not, changing backends reveals that your correctness guarantee was always the model, not the spec. In that case, swapping models is genuinely risky, but the risk is a symptom of weak spec constraints, not of model incompatibility.
Figure 8 - Why Spec Constraints Are the Prerequisite for Clean Model Swaps: Without tight spec constraints, generated code takes on the idiomatic patterns of the model that wrote it. A model swap introduces inconsistency the next model cannot normalize. With tight spec constraints (lints, structural tests, reviewer-agent prompts), any compliant model produces code in the same canonical form, making backend selection a performance and cost decision rather than a migration risk [1][3].
Conclusion
The fuzzy-compiler framing is, at its core, a restatement of something compiler engineers have known for decades: you maintain the source, not the binary. In the LLM context, the restatement has teeth because the intuition runs the other way. Generated code looks like handwritten code. It lives in the repository alongside the lints and tests and specs. It is easy to start treating it as the primary artifact.
The compiler analogy corrects the intuition. The LLM is a backend. The generated source is machine code. You maintain the spec.
The six-row mapping from compiler concepts to harness-engineering practices is not decoration. Each row is a design decision. Weak static-analysis passes (lints) mean the backend produces inconsistent output. Missing optimization passes (reviewer agents) mean the output is structurally correct but does not meet quality standards. A spec that is never improved means the backend’s output quality deteriorates as the codebase grows. The GCD ritual is your pass-development cadence. The token allocation toward planning and documentation is your source-language maintenance budget.
Symphony is the clearest available demonstration that the mental model is operational, not theoretical. OpenAI released a SPEC.md. They also released an Elixir implementation. Anyone who understands what a compiled artifact is will read that release structure and recognize the mental model at work [4][5].
When the next model arrives and the generated code looks different, the question is not whether the code matches what came before. The question is whether the lints pass, whether the reviewer agents are satisfied, whether the structural tests hold. If they do, you have a new backend. That is expected, routine, and fine.
The Series
This is Part 3 of the 3-part OpenAI Lopopolo sub-series:
- Garbage Collection Day: A Weekly Ritual for Reducing Agent Slop. The Friday slop-elimination ritual, the three durable artifact types (lints, structural tests, reviewer-agent updates), and the throughput flywheel they create.
- Token Billionaire Economics: Where 1B Output Tokens Per Day Actually Go. The cost structure and token allocation of operating at extreme agent throughput, and why two-thirds of the spend is not writing code.
- Code as Disposable Build Artifact: LLMs as Fuzzy Compilers (this article). The mental model that ties the sub-series together: treat the LLM as a codegen backend, the spec as the source language, and generated code as a disposable build artifact.
References
[1] R. Lopopolo, “Harness Engineering: How to Build Software When Humans Steer, Agents Execute,” AI Engineer Europe 2026 keynote, April 8-10, 2026, London. https://www.youtube.com/watch?v=am_oeAoUhew
[2] Bytecode Alliance, “Cranelift: A fast, secure, relatively simple and innovative compiler backend,” Cranelift project home. https://cranelift.dev/
[3] rust-lang, “rustc_codegen_cranelift: Cranelift based backend for rustc,” GitHub. https://github.com/rust-lang/rustc_codegen_cranelift
[4] OpenAI / R. Lopopolo and A. Kotliarskyi, Symphony GitHub repository, Apache License 2.0. https://github.com/openai/symphony
[5] OpenAI, “An open-source spec for Codex orchestration: Symphony,” OpenAI, April 2026. https://openai.com/index/open-source-codex-orchestration-symphony/
[6] S. De Simone, “OpenAI Open-Sources Symphony, a SPEC.md for Autonomous Coding Agent Orchestration,” InfoQ, May 17, 2026. https://www.infoq.com/news/2026/05/openai-symphony-agents/
[7] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Garbage Collection Day: A Weekly Ritual for Reducing Agent Slop,” dotzlaw.com, 2026. /insights/claude-code-08-garbage-collection-day/
[8] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Token Billionaire Economics: Where 1B Output Tokens Per Day Actually Go,” dotzlaw.com, 2026. /insights/claude-code-09-token-billionaire-economics/
[9] R. Lopopolo, “Harness engineering: leveraging Codex in an agent-first world,” OpenAI, February 11, 2026. https://openai.com/index/harness-engineering/
[10] R. Lopopolo, “Extreme Harness Engineering: 1M LOC, 1B toks/day, 0% human code or review,” AI Engineer follow-up talk. https://www.youtube.com/watch?v=CeOXx-XTYek
[11] AI Engineer Europe 2026, Queen Elizabeth II Centre, London, April 8-10, 2026. https://www.ai.engineer/europe/2026
[12] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “What Is an Agent Harness, Really? Nine Components Most Builders Miss,” dotzlaw.com, 2026. /insights/claude-code-01-agent-harness/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.