Compiling Intent

Compiling Intent

Spec-based AI development - why the specification, not the code, is the thing you actually build.

The claim of the talk in a single line: in 2026 the artifact in your repo that carries the value is not the code. The code is what the loop generates. The thing you author, version, review and protect is the specification - intent plus guarantees, written precisely enough to be testable.

We have been backing up the wrong file.

When you prompt an AI coding agent, what do you keep, and what do you throw away?

You keep the code. You commit it, review it, back it up. The prompt - the actual capture of what you wanted - scrolls out of the terminal and dies. That is backwards. We have been versioning the build artifact and discarding the source.

The spec is the source of truth. The code is a build artifact.

Two lines. Everything else in the talk is a consequence.

The compiler analogy is meant literally. You do not hand-edit the assembly that gcc emits and forget where it came from - you change the C and rebuild. Treat generated code the same way. If you are afraid to regenerate a file, that fear is a signal: there is intent living in the code that should be in the spec instead.

What spec-based development is

A disciplined loop: SPEC → PLAN → TASKS → BUILD.

SPEC captures intent plus guarantees, written to be testable. PLAN is the architecture and approach, human-approved. TASKS are atomic and independently checkable. BUILD generates code, tests and documentation together. The invariant: everything below SPEC is regenerable. The spec is the only thing a human edits by hand.

This is not a fringe idea anymore

Eight vendors, one direction.

GitHub Spec Kit, AWS Kiro, OpenSpec, BMAD-METHOD, Claude Code, Cursor rules, Tessl, Google Antigravity. The first numbers from teams using these tools are landing - roughly an order of magnitude fewer “regenerate from scratch” cycles, and forty-hour features collapsing toward eight when authored as a spec first.

One test to keep in your head

If you can regenerate it, it is a build artifact.

Build artifact - do not hand-edit: generated source code, unit and integration tests, API reference docs, scaffolding, wiring and config. Source - this is what you own: the specification itself, architecture decision records, acceptance criteria and the judgement calls behind them.

Symphony, in one slide

A senior principal makes every meaningful decision. The engine does the mechanical work.

Symphony is the open-source delivery engine Released uses to ship client software. It is spec-governed (one WORKFLOW.md file holds config and the prompt template), isolated by issue (each GitHub issue gets a contained workspace), tests-and-docs-always (the engine refuses to call an issue done without them) and model-agnostic (runs against any OpenAI-compatible model through Codex CLI).

The six-stage loop

Brief → Shape → Build → Review → Release → Iterate.

The principal owns Brief (frame the problem as a living spec), Shape (sign off the architecture the agents propose) and Review (every material change). The engine owns Build, Release and Iterate. The loop never has a “final” build, only a current one - feedback flows from Iterate straight back into the spec at Brief.

One GitHub issue, end to end

Symphony polls GitHub, claims an issue, reads SPEC.md, generates code + tests + docs, opens a PR.

The live demo shows Symphony claim issue #214 (“add an idempotency key to POST /payments”), cut an isolated workspace, read SPEC.md rather than the existing code, generate the implementation, test file and documentation update in the same turn, run the tests, and open a pull request for human review. Zero human edits in the run shown.

The payoff is the pull request

Quality is structural, not cultural. You cannot forget what the system refuses to skip.

Every PR Symphony opens contains four things: Code implementing the change against the spec, Tests covering it, Docs updated in the same commit (the API reference is never the lie everyone stopped trusting), and a full Trail of decisions and reviews. Nobody has to remember to write the tests. A change without them is, by definition, unfinished.

Now the requirement changes

Mid-build, a new rule: payments over $10,000 need dual approval.

Ad hoc, that’s a frantic patch - new prompt, hope it touches every relevant file, discover next week it missed the docs and one test. Spec-based, it’s a two-line diff in SPEC.md. The engine then re-plans, generates the approval state machine, writes the “same submitter cannot approve” test, updates the OpenAPI spec and the /payments reference page - all consistent, because they all descend from the same edited spec.

  rules:
    - idempotent POST /payments
+   - payments > $10,000 require
+     dual approval before settle
  # plan, tasks, code, tests, docs → regenerated from here

Compiling a 45-year-old idea

Microsoft BASIC for the 6502, recovered into a spec and regenerated on .NET.

Demo 1 was the sensible production version of spec-based development. Demo 2 is the one that makes the idea click. 1976. Bill Gates and Paul Allen. Microsoft BASIC for the 6502 - the chip in the PET, the Apple II, the VIC-20. Seven kilobytes of hand-written assembly, publicly available, still runs, and crucially: no spec.

Exhibit A - Microsoft BASIC, 6502

Roughly 7 KB of dense, hand-optimised 6502 assembly. Public. Iconic. Unreadable today.

Load accumulator, set carry, subtract, store, jump-subroutine, branch on carry. This is the implementation that ran an entire generation of programmers and that almost no working developer in 2026 wants to read. We have an implementation, no spec, and we are going to run the loop backwards first.

Step 1 - lift a spec out of the assembly

Assembly in; specification out.

The agent is pointed at m6502.asm and asked, not to translate, but to explain. What does BASIC actually do? What comes back is not code. It is a short specification: expression evaluation, operators and precedence (^ beats * / beats + -, left-associative), 40-bit float as the numeric model, division by zero halts with the canonical error, parentheses override precedence. The agent decompiled the 6502 into intent.

Step 2 - regenerate it on .NET

From the recovered spec, the agent builds a clean BASIC interpreter in C#.

The loop now runs forward again, the normal direction: spec to code. The agent does not transliterate the 6502 - it goes back to the spec and writes an idiomatic .NET implementation, with tests derived from the spec’s own examples. Cross-platform, IEEE doubles, a real test suite, a debugger - none of that was specified; it is just what the modern target gives you for free.

How do we know it is right?

The original is still running. Make it the test oracle.

A cycle-accurate 6502 emulator runs the real 1976 assembly on the left. The generated C# interpreter runs the identical BASIC programs on the right. The outputs are diffed token by token. 847 out of 847 programs match. The spec is verified against 45-year-old ground truth.

Step 3 - change one line of the spec

The interpreter works. Don’t touch the code. Watch the spec.

The single most important moment of the talk. The execution model section originally said: “The AST is walked and evaluated directly” - that is an interpreter. Delete that line, replace it with: “The AST is lowered to .NET IL and JIT-compiled to a managed assembly before execution.” That is a compiler.

  # Execution model
  A BASIC program is parsed into an AST.
- The AST is walked and evaluated directly.       # interpreter
+ The AST is lowered to .NET IL and JIT-compiled
+   to a managed assembly before execution.        # compiler
  # everything below SPEC regenerates from this line

One line deleted, two lines added. No parser written. No code generator. No IL emitter. No JIT bridge. The definition of what “execute” means was changed, and the loop was handed back to the agent.

Same spec. Now it is a compiler.

Roughly 112× faster than the 1976 original, and not a single code file was opened.

The agent regenerated the entire back end: a .NET IL emitter and a JIT path. 1976 BASIC compiling to managed code. Relative throughput across the benchmark suite, with the 6502 normalised to 1×: the .NET interpreter sits around 38×, the compiled version around 112×. What we wrote was not a compiler. It was a sentence. The compiler is what the loop produced when the sentence changed.

One spec outlived two implementations and an entire instruction set

Recovered. Verified. Re-targeted. Code was never precious.

Track one spec through the demo. Recovered - from 45-year-old assembly nobody wanted to read; code became spec. Verified - against the original running as a test oracle; 847 of 847 programs matched. Re-targeted - from interpreter to compiler with a one-line edit; spec became code, again. Two complete implementations, zero hand-edits. The spec carried all the value.

Four habits that make this work

What separates spec-based development from a really long prompt with crossed fingers.

1. Write testable specs. If a line can’t become a check, it’s decoration. “Payments should be reliable” is a wish; “a retried POST with the same key settles exactly once, 50 concurrent, one ledger row” is testable. 2. Keep one living spec, in version control. Reviewed like code. The only door change comes through. 3. Humans own decisions; agents own mechanics. Architecture, trade-offs, “what done means” - still you. Scaffolding, wiring, tests - the agent. 4. Treat code as a build output. Afraid to regenerate? That fear is a metric.

What this makes the AI engineer

The job is moving one level up the stack - from writing implementation to authoring intent.

From the engineer who writes the code (value measured in lines shipped; output is implementation; change means rewriting) to the engineer who compiles intent (value measured in clarity of intent; output is a verified spec; change is an edit). The skill that appreciates is saying precisely what you want, knowing what you want, and knowing how you will know it worked. That has always been the hard part of engineering. Now it is the whole job.

Where this still bites

Spec-based development is a real improvement, not a free lunch.

Thin specs still fail - garbage in, garbage out; the bottleneck moved to how well you think. Non-determinism - two regenerations differ; pin versions, lock tests, treat the build as reproducible. Specs rot too - a spec can drift from reality just like a comment; review and prune it. Review still matters - the agent is fast and confident, including when wrong. Hot paths need hands - perf-critical or exotic code still wants a human; know which 5% to keep hand-written.

Stop shipping code. Start shipping intent.

The spec is the program. Everything else compiles.

The code is a build artifact - let the agent compile it. The specification is the program. Write that with the precision you used to spend on the code, verify it against something real, and let the implementation be whatever the loop builds today.

Questions - and try it yourself

Symphony is open source. Pick a spec-first tool. Spec a small feature this week.

Three concrete next steps from the close of the talk. First, Symphony is MIT-licensed on GitHub - run the installer, point it at a repo, watch it work. Second, pick one of GitHub Spec Kit, AWS Kiro or OpenSpec and spec a small feature this week. Third, ask the question from earlier - could you delete the code and rebuild it from the spec? If the answer is no, you have just found something worth writing down.