Spec-driven development (SDD) is an AI-assisted software engineering workflow in which a structured specification becomes the source of truth for implementation. Instead of prompting an agent to generate code directly, the workflow moves through requirements, design, implementation planning, task decomposition, and code generation.
Why the term crossed into a category
Spec-driven development has moved from a tool-specific feature into a durable category term. AWS positions Kiro around spec-driven development, describing specs as structured artifacts that turn high-level ideas into implementation plans with tracking and accountability. GitHub has published its own Spec Kit methodology, in which specifications generate implementation rather than merely informing it. JetBrains has covered the workflow for AI coding agents, and the wider ecosystem now includes active open-source projects such as OpenSpec and cc-sdd.
The shared idea across these tools is the same: the specification is promoted from a document you read into an artifact the system acts on.
The workflow
Spec-driven development replaces loosely prompted generation with a structured sequence. Rather than going straight from prompt to code, the work flows through explicit stages:
Each stage narrows ambiguity before the agent writes code. The specification is the contract for what the system should do, and the plan and tasks decompose that contract into work an agent can execute.
Specs solve generation ambiguity. They do not solve architectural governance.
This is the part worth being precise about, and the page is not dismissive of SDD: structured specs are one of the healthiest responses to unstructured “vibe coding.” A spec can define what an agent should build. It does not, on its own, answer a separate question:
Which architectural decisions must remain true while the agent builds it? A change can satisfy its feature spec and still introduce a forbidden dependency, bypass an approved abstraction, use a deprecated service pattern, or violate an ADR.
Specification and governance are complementary layers, not competing ones:
- Specification — what should the agent build?
- Architectural governance — which decisions and invariants must constrain the implementation?
- Verification — how do we prove the output complied?
Read top to bottom, that composes cleanly: intent becomes a specification, the specification becomes a plan and tasks, governance constrains the implementation, the agent executes, and verification contracts prove the result held the line.
Where it sits in the Mneme ontology
Spec-driven development is an important development paradigm around Mneme, but Mneme does not own the term. The owned concepts in this ontology remain architectural governance, governance before generation, verification contracts, enforcement provenance, and architectural drift. SDD is the spec-surface neighbor that governance plugs into:
- It depends on governance before generation — constraints injected before the agent acts on the spec, not after the diff exists.
- It produces and validates verification contracts — the spec says what to build; the contract proves the build complied.
- Without it, architectural drift still accumulates — a spec-conformant change can drift the architecture.
- It relies on decision continuity — decisions must survive across the sessions and tools that execute a spec.
- It is the spec-surface peer of agentic IDE governance, which constrains the same agents at the IDE-execution surface.
Specs improve generation. Governance preserves architecture.