Executable specs as the program

Natural language fails the goals and techniques of a programming language, so version-controlling the prompt does not reproduce the result. The answer is to version-control a specification shaped tightly enough — use cases with pre- and postconditions, an entity model, machine-checkable acceptance criteria — that code becomes a regenerable projection of it. The most formally-shaped report on offer uses system use cases plus an entity model as the whole spec, deletes the plan and task phase entirely, and reports generation near enough to deterministic that you can delete the output and regenerate: “two weeks for the specification, then five minutes for the code.”

Peer review shifts left onto the spec because reviewing agent-authored code at volume is not fun and not sustainable — some organizations have already dropped mandatory review. The framing that holds it together: unread code is a signal that the review discipline itself must change, not a failure of discipline. There is also a renewable-energy effect once teams learn that agents consume the specs, it encourages them to write better ones.

Specifications must cover non-visible behaviours — performance, security level — because those are contextual and cannot be inferred from the functional description. And a spec alone is a snapshot of intent: verifying a feature is not the same as verifying code, and comparing code to code is not the answer. The unsolved half is named openly on one panel — if AI is the next level of abstraction, the field needs a language for reviewing systems above code and below prose, and nobody claims to have it.

Also: Kiro, GitHub Spec Kit, BMAD, arc42, Spring Initializr, Nwave, Glamorous Toolkit.

A brief is a versioned, reviewed specification with a Definition of Done, and code is what a worker produces against it. Assay is a spec-driven methodology by construction, so these talks are peer field reports rather than a new direction. Shipped.

The refinement worth taking is that a Definition of Done should read as an executable specification — at least one example-input to expected-behavior pair per deliverable — enforced by a lint alongside the statusgen checks that already run. That closes the gap between a spec that describes and a spec that decides. Designed here, unbuilt. A framing change follows for the review role: diff review is best described as assurance and adversarial check rather than as behavior verification, since behavior verification belongs to the verify rows — a reframe that must never be extended into “don’t read the code” on the high-consequence surfaces where reading the diff is the control.

Deleting the plan and task phase outright is defensible for a single vertical with one or two humans, and is not transferable to Assay, where parallel agents need dependency waves to prevent collisions — the plan phase is what makes fan-out safe. Recorded as a deliberate non-adoption, not an oversight. The unaddressed gap is non-visible behaviours: briefs carry risk and gate annotations, but a brief is not required to state a performance or security level, and the whole point is that those cannot be inferred. Not addressed.

• Someone closing the review-language gap — an actual language for reviewing systems, above code and below prose. It is the missing piece the whole concept leans on, and nobody at either conference claimed to have it.
• A reproducibility number for spec-to-code regeneration. “Near deterministic” is an experience report; a published regeneration-diff measurement decides whether “code as a projection of the spec” is literal or aspirational.