Blog

Spec-first, spec-anchored, spec-as-source: where TrueBDD stands

Diagram: spec-driven development branches into three levels, Spec-First, Spec-Anchored and Spec-as-Source.

A behavioural spec plus an architectural contract are meant to be the source of truth, and the code gets regenerated. That's the idea behind TrueBDD, a CLI I'm building.

AI can generate code faster than any of us, but while code stays the source of truth, an engineer still has to review everything it produces β€” responsibility stays human. Move the truth to the spec and there's less to review by hand in the first place.

"Spec-driven development" gets used as one label for three different bets. The SDD literature (arXiv 2602.00180) splits it into three levels, and only one of the boundaries between them matters. πŸ—ΊοΈ

Spec-First.

The spec kicks off the work, then the code takes over as the source of truth and you hand-edit it from there. Cursor-with-rules, early Spec Kit.

Spec-Anchored.

The spec is a living contract: CI validates the code against it, the spec updates through review. But the code is still the source of truth β€” you edit it by hand and the spec follows. Most of the serious tools live here today: Spec Kit, Kiro, BMAD, OpenSpec, current Tessl.

Spec-as-Source.

The spec is the source of truth, the code is derived, and editing the code directly is forbidden β€” you change the spec and regenerate. The one tool that's really reached this is Tessl, historically, via tessl build and current Tessl has settled back at Anchored.

The test that separates Anchored from Source is blunt: delete all the code, regenerate from the spec, check the new build passes every behavioural assertion. If yes, you're at Source. If "well, mostly", you're still Anchored and the code is quietly still in charge.

TrueBDD is at Spec-Anchored today. The us subcommands already work: they manage the spec lifecycle, and Claude drives checklists over the user stories against the spec. The build subcommands, where regeneration is supposed to live, are stubs.

So the whole distance between what TrueBDD is and what it's aiming at is those build stubs. Generating code so behaviour holds across rebuilds, deterministically enough that you can delete the previous build β€” that's the part nobody has cleanly shipped.

I haven't shipped this either. I'm convinced it's possible though, and figuring out how to get there is where my time goes. If you're working the same problem and want to talk it through, I'd be glad to.