Spec-driven development has a maturity map, and the most useful thing about it is permission: permission to not be at the top. The map comes from Birgitta Böckeler, writing in Martin Fowler's Exploring Gen AI series, and it splits the practice into three levels that answer one question differently: what happens to the spec after the build?
Spec-first: you write a spec to guide the build, and often discard it afterward. The spec is scaffolding. It sharpens intent, constrains the agent, then falls away.
Spec-anchored: the spec stays alive and governs the feature as it evolves. Change requests go through the spec, and the spec and code move together.
Spec-as-source: the human only ever edits the spec and never touches the generated code. Intent is the source; code becomes a build artifact, regenerable on demand.
The dishonest way to present this is as a ladder every serious team should climb. Böckeler's own read is the opposite, and it's worth quoting the substance of it. Spec-first is where nearly everyone actually is. Her assessment of the tooling: Kiro is essentially spec-first, Spec Kit aspires to spec-anchored but in practice still branches per change rather than per feature, and only Tessl is reaching for spec-as-source, and it's still in beta. The frontier tools have not caught the top rung. Nobody should feel behind for standing where the ecosystem actually stands.
So how do you choose? By cost of drift. Drift is the gap that opens between what the spec says and what the code does, and the levels are three different prices paid to control it.
If drift is cheap, stay spec-first. A prototype, an internal tool, a feature you'll rewrite in six months: when the code drifts from the discarded spec, nothing bad happens, because the spec's job ended at birth. Paying anchoring costs here is ceremony without a customer.
If drift is expensive, anchor. A design system's component contracts. A checkout flow. Anything where "the code quietly stopped matching the agreed behavior" turns into incidents or audit findings. Spec-anchored means every change re-passes through intent, which is bureaucracy exactly proportional to how much you fear silent divergence.
If drift is intolerable and the domain is narrow, spec-as-source becomes thinkable. Note both conditions. The teams reaching for it aren't doing it across sprawling apps; it works where inputs and outputs can be exhaustively specified. And the skeptics' case is serious. Böckeler herself, who drew the map, warns that spec-as-source could inherit the worst of both worlds: the inflexibility of old model-driven development plus the non-determinism of LLMs. When the mapmaker flags the summit, believe her.
Whatever level you pick, the spec itself has to be written so an agent cannot misread it, and there's a thirty-year-old tool for exactly that. Alistair Mavin's EARS notation gives you a handful of sentence patterns (ubiquitous, event-driven, state-driven, unwanted-behavior, optional) that turn fuzzy requirements into testable statements. "While the form has unsaved changes, when the user navigates away, the system shall prompt to confirm." Every clause is checkable. Boring sentences, unambiguous intent: the same trade tokens make, applied to requirements. The tooling around all this is moving fast (GitHub Spec Kit at v0.8.7, AWS Kiro, OpenSpec, BMAD), but the sentence patterns are the part that transfers regardless of tool.
Two honest costs to price in before you anchor anything. Maintenance: practitioners doing this seriously, Romina Kavcic among them, put ongoing spec maintenance at something like a third of the effort. A living spec is a product; anyone selling it as free isn't running it. And brownfield: specs on existing, messy code are still immature territory. Writing a spec for what a tangled system currently does is archaeology plus negotiation, and the industry is honestly still working out the method.
The quiet takeaway sits underneath the levels: the human job shifts from writing syntax to verifying logic. That's the actual change, more than any tool. Pick the cheapest level that controls your drift, write specs in patterns a machine can't misread, and let the rigor grow only where the cost justifies it.
The free starter kit at tokenstoagents.ai/kit includes an EARS spec template with the five patterns and worked examples.