Stop Nursing Your AI Outputs

Two-Stage Compilation: How the Pattern Works

Every effective AI-assisted system is a two-stage compiler — most people only run stage 2.

The Pattern Most People Miss

The common approach looks simple: take a task, give it to AI, get an output, ship. This is "Stage 2" only. You provide task requirements, AI generates an artifact, done.

But there's a fundamental piece missing: the worldview that should shape the output.

Why this matters: Stage 2 alone produces generic outputs shaped by internet averages. Stage 1 + Stage 2 produces "you-shaped" outputs that apply your judgment to specific contexts. The difference is brand coherence, judgment application, and compounding quality.

Stage 1: Compile You

In Stage 1, you encode your worldview into a generator or builder. The generator becomes "biased" toward your philosophy—not in a negative sense, but deliberately aligned with your values, frameworks, and approach.

This is the "value-biased compiler" concept. The builder inherits your philosophy about risk, quality, what counts as "good work," and what to reject. It becomes capable of producing outputs that feel like you wrote them—because it's applying the judgment you've encoded.

Stage 2: Compile Them

In Stage 2, you apply the now-biased builder to specific contexts. The builder brings your worldview; the context brings their situation.

The inputs to Stage 2 are situational: client data, company financials, project requirements, industry specifics, organizational context. The builder ingests their information, applies your frameworks, and generates outputs shaped by both.

The outputs might be proposals, code, content, workflows, reports—any generated artifact. But the critical difference is this:

The Shallow Take vs. Deep Take

The shallow take: "Use design docs before writing code." Everyone nods, nobody changes behavior. Design docs remain afterthoughts.

The deep take: "Every AI-assisted system is a two-stage compiler. Stage 1 compiles your worldview into a generator. Stage 2 applies the generator to specific contexts. Most people are only running Stage 2 and wondering why their outputs lack coherence."

Design Documents as Gospel

The industry is shifting. As documented in "A Blueprint for Future Software Teams," the design document is no longer an afterthought. It's the input. The specification. The source of truth.

"Production code still matters. It runs. It's tested. It's deployed. It serves customers. What 'ephemeral' means is: code can be regenerated from design if needed."

Spec-Driven Development: The Industry Recognizes the Pattern

As Martin Fowler documents, "Spec-driven development means writing a 'spec' before writing code with AI. The spec becomes the source of truth for the human and the AI."

This isn't just one practitioner's opinion—the industry is converging on this pattern independently. Multiple sources arriving at the same conclusion: "Specs should live longer than the code. Code becomes a by-product of well-written specifications."

The Workflow Contrast

The deeper pattern: "Spec-driven development flips the script: write specifications before code. Your spec becomes the single source of truth defining what you're building and why, without dictating how."

Infrastructure as Code: The Same Pattern

This pattern isn't new—it's been proven at massive scale through Infrastructure as Code (IaC). Terraform, AWS CloudFormation, and similar tools have demonstrated the economic and operational advantages of treating configuration as durable and infrastructure instances as ephemeral.

Infrastructure as Code is "the practice of managing and provisioning IT infrastructure using machine-readable configuration files instead of manually configuring hardware." Configuration files are the recipe; infrastructure instances are the ephemeral output.

"When you change certain arguments in a Terraform resource, it can't just update the existing component. It has to destroy the old one and create a new one. It forces replacement."

The declarative approach is key: "You write code that describes your infrastructure, and Terraform makes it happen. It's declarative, meaning you define the end state you want, not the steps to get there."

The kernel describes desired end state. AI figures out how to get there. This is the same pattern scaled across domains.

Why Two Stages, Not One?

A reasonable question: why not just encode everything in a single prompt and generate outputs directly?

Applying the Pattern Beyond Code

This isn't just about software. Any AI-generated system benefits from two-stage compilation. The pattern is domain-agnostic—it's about the economics of encoding judgment once and applying it many times.

The unifying insight: prior "ephemeral code" coverage focused on software development. This extends the principle to ANY AI-generated system. The economics are the same; the domains vary.

The Mistake: Compiling Without the Kernel

The builder didn't know the worldview — so the outputs lacked brand DNA.

Content Pipelines: Kernels for Ebooks and Articles

The same two-stage compilation applies to content production — kernel + context = output.

The Same Pattern, Different Domain

Everything we've discussed about ephemeral code and durable kernels applies beyond software. Content production faces exactly the same economics: regeneration versus patching, specifications versus outputs, kernels versus artifacts.

The mapping is direct:

Many readers produce content, not code. The doctrine transfers completely.

The Ebook Flywheel as Compilation

The content production workflow is a series of compilation stages, each narrowing and refining:

Each stage is a compression step: raw thought → structured thought → researched thought → published thought. And crucially, outputs become inputs to future outputs. Articles become frameworks. Frameworks improve future articles.

"That is now a framework, that next document. I feed that into the framework list, and then... I'm also trying to increasingly give it a list of articles that it can read directly."

What Lives in the Content Kernel

The content kernel is your durable asset. It's where you encode judgment about how to produce content. Four main components:

The Pre-Think as Design-Time Compilation

Pre-think is "thinking about the thinking" — a meta-cognitive step that happens before main content generation. It's your design document for the content piece.

Why this is design-time compilation: it happens before the main generation, encodes judgment about this specific piece, and creates an audit trail of decisions. Explicit rejections before execution.

The output of pre-think is a "brief" for the content generation: narrowed scope, clear intent, documented exclusions. Then the main workflow can execute without thrashing.

"The pre-think just does thinking about the thinking, and thinking about what to reject and what to use, and what voice, and many different things like that."

Frameworks Influence Voice Without Being Quoted

There's a subtle but important distinction in how frameworks and external sources are used:

The principle: we don't quote ourselves because quoting yourself lacks gravitas. Your frameworks shape how the content is written — the analysis, the structure, the voice — but they're not presented as citations.

External authorities (McKinsey, BCG, research papers, industry data) provide the formal citations. Your frameworks shape the analysis; their authority validates conclusions.

Content as Ephemeral

The same principle applies: content can be regenerated from a better kernel when frameworks update. The kernel is durable; the content is regenerable.

When to regenerate content:

• Frameworks have significantly evolved — your thinking has sharpened, old pieces feel stale
• New research invalidates old conclusions — better data available, claims need updating
• Voice/style has matured — early pieces don't match current brand
• Better model available — new AI capabilities produce richer outputs from same kernel

The practical reality: you probably won't regenerate every article. But high-value pieces can be refreshed, and NEW content benefits from improved kernels automatically. That's the compounding advantage.

The Meta-Editor Pattern

Conversations are braided — multiple frameworks, examples, tangents all intermingled. The meta-editor solves the decomposition problem.

The architecture: Python owns the loop (enumerate topics, call workflow per topic). AI owns judgment (extract relevant bits, classify, outline). Markdown files are interfaces between stages.

Why this matters: single conversation → multiple clean articles. No value lost to "intermingled ideas." Systematic extraction rather than manual cherry-picking.

The Worldview Compression at Work

This is recursive compression in action: take a view, compress it into a framework, use that framework as input to the next cycle.

Why frameworks beat raw research: you could tell an LLM "go research the latest thinking on X, then advise." But it pulls a small slice of the internet, averages the tone and ideas, mixes in its older baked priors. Result: generic consultant soup.

Your frameworks do three things raw research can't:

"Without the frameworks... 'do a chatbot'. With frameworks... ideas of replacing processes and augmenting humans and a whole bunch of different stuff, which is just the absolute spot on right answers."

The frameworks are the difference between generic and stellar. They're your compressed worldview, applied at scale.

The Self-Reference Phenomenon

Something interesting happens when you write about AI frameworks using those frameworks: the AI starts referencing the frameworks and noting that the writing process itself proves the point.

This is valid — carefully. It's not circular reasoning ("this is good because I say it is"). It's demonstration: "this article is produced by a system that uses these principles — you are experiencing the argument being enacted."

The medium can embody the message. Just don't let it slip into pure circularity.

Applying the Doctrine to This Ebook

This ebook is itself a content pipeline output. Let's make the structure explicit:

What makes it work:

• Pre-think defined scope and exclusions (no software details, no Markdown OS architecture)
• Frameworks shaped the structure and voice (two-stage compilation, crossover point, ephemeral outputs)
• Research provided external validation (GitClear data, McKinsey economics, Anthropic benchmarks)
• The kernel + context = output pattern executed as described

The meta-insight: you're reading an example of the pattern being described. The ebook about kernels was generated using a kernel. Not proof, but demonstration.

Model Upgrades as Free Value

Same Recipe, Better Outputs

When the recipe is durable and outputs are ephemeral, model upgrades become compounding advantages. This is the payoff — the reason why treating outputs as disposable isn't just a maintenance strategy, it's a growth strategy.

The Data From Anthropic

When Anthropic released Claude Sonnet 4.5, they published specific performance improvements. These aren't marketing claims — they're measurable benchmarks from production use cases.

"Claude Sonnet 4.5 reduced average vulnerability intake time for our Hai security agents by 44% while improving accuracy by 25%, helping us reduce risk for businesses with confidence."

At the same price. That's the key part. This isn't an upsell to a premium tier. This is a drop-in replacement that delivers meaningfully better performance for the exact same cost.

The Drop-In Replacement Reality

Anthropic describes Sonnet 4.5 as "a drop-in replacement that provides much improved performance for the same price." What does that mean practically?

• → No code changes required
• → No prompt rewrites required
• → Just switch the model endpoint

Pricing remains stable at $3 per million input tokens and $15 per million output tokens — identical to Claude Sonnet 4. You get meaningfully better real-world coding performance, stronger long-horizon autonomy, improved system and tool use, and ASL-3 safety guarantees, all without changing Sonnet-tier pricing.

This is compounding value. Your kernel stays the same. Your work required is zero. The outputs get better automatically.

Why This Only Works With Ephemeral Outputs

The upgrade economics only deliver if you can actually regenerate. If outputs are precious, you're locked out of the compounding loop.

The Version Upgrade Benefit

When architecture is right, model upgrades are smooth. The new model reads the same design document and produces better code. The kernel is the constant; model capability is the variable that keeps improving.

"The design document persists across changes that would normally require major rework: Model upgrades — New model reads the same design doc, produces better code."

Your investment compounds. Time spent on kernel quality is fixed (with occasional updates). Model improvements are continuous (vendor investment). Quality trajectory moves upward without your effort.

Contrast: The Patch-Nursing Approach

What happens when outputs are precious? When you've invested heavily in patching and can't afford to regenerate?

• ✗ Accumulated patches don't transfer to new models — The judgment is encoded in old outputs, not in reusable kernel files
• ✗ You can't just "regenerate" — Because you'd lose the patches and all the work that went into them
• ✗ Model upgrade becomes a migration project — Manual transfer, rewriting, testing against new behavior
• ✗ You're locked to the capability ceiling — Stuck at 2024 quality in 2025 and beyond

The migration problem is real. Old patches are encoded in old outputs. The new model doesn't know about those patches. You must manually transfer or re-create them. The work that was supposed to be "done" becomes work again.

The Strategic Implication

If model upgrades deliver free value — but only when outputs are ephemeral and kernels are rich — then the strategic move is clear:

Real Numbers on Quality Improvement

Beyond the headline 44% and 25% improvements, the benchmarks show meaningful gains across the board:

What this means practically:

• → Same spec → better code
• → Same proposal kernel → better proposals
• → Same content kernel → better articles

The improvement is measurable, not theoretical. And the trajectory is clear: these improvements happen every few months. Each release compounds on the last. If you can capture them (ephemeral outputs), you keep improving. If you can't (precious outputs), you fall behind.

The Early Adopter Advantage

The teams that adopt the ephemeral output doctrine early don't just get better quality today. They get compounding quality improvement over time.

The competitive gap widens with each model generation. Teams treating outputs as ephemeral are iterating 3–5x faster than teams nursing patched outputs. And every new model release widens that gap further.

Closing the Loop

This chapter connects everything we've covered:

• Ch 1: Regeneration is now cheaper (the economic inversion)
• Ch 2: Kernel is the durable asset (where to invest)
• Ch 3: Two-stage compilation (the mechanism)
• Ch 4-6: Flagship example (proof it works in practice)
• Ch 7: When to rebuild (practical threshold)
• Ch 8: Content pipelines (the pattern in another domain)
• Ch 9: Model upgrades (why it compounds — the strategic reason to adopt the doctrine)

Key Takeaways