What is spec-driven development? An AI-assisted workflow where a structured specification — not a one-off prompt — is the source of truth for what an agent builds. It is a real improvement. But a spec governs what gets built, not which architectural decisions must survive the build. That second layer is architectural governance, and AI coding agents still need it.

From prompt-to-code to intent-to-code

Spec-driven development (SDD) has crossed from a tool-specific feature into a durable category term. AWS positions Kiro around it, 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 ecosystem now includes active open-source projects such as OpenSpec and cc-sdd.

The shared move is the same: stop going straight from a prompt to code, and route the work through an explicit, reviewable sequence.

The shift
Before
Prompt → Code
After
Intent → Spec → Plan → Tasks → Code

This is genuinely good. It narrows ambiguity, makes agent work decomposable, and gives reviewers something more durable than a chat log. The criticism that follows is not that spec-driven development is wrong — it is that it solves one half of the problem and is sometimes sold as solving both.

The gap a spec does not close

A specification defines what the agent should build. It does not, on its own, define which architectural decisions must remain true while the agent builds it. An agent can satisfy a feature spec completely and still:

  • introduce a forbidden dependency
  • bypass an approved abstraction
  • use a deprecated service pattern
  • violate an ADR the team already ratified
  • apply the right pattern in one directory and the wrong one elsewhere
  • lose prior decisions across sessions or coding tools

A spec answers “what should the agent build?” It does not answer “which architectural decisions must remain true while it builds?” Those are different questions, and only the second one prevents architectural drift.

The gap is structural, not a maturity problem with any particular spec tool. A spec is scoped to a feature or task. Architecture is scoped to the system, and it persists across every feature, session, and agent that touches the repository.

The mature workflow

The fix is not to abandon spec-driven development. It is to insert a governance step between planning and execution — constraints retrieved and injected before the agent generates code, and proven afterward with verification contracts.

The pipeline
Intent
the goal
Spec
what to build
Plan and tasks
decomposition
Governance
constraint retrieval and injection
Agent execution
the agent writes code
Verification
verification contracts prove compliance
Merge
only after the line held

This extends spec-driven development rather than competing with it. The spec still drives what gets built. Governance just makes sure the implementation stays inside the architectural decisions the team has already made — and keeps doing so on the next agent, in the next session, in a different IDE.

Specs and governance are complementary

Stacked side by side, the two layers answer different questions, and a verification layer closes the loop:

Layers
Specification
What should the agent build?
Architectural governance
Which decisions and invariants must constrain the implementation?
Verification
How do we prove the output complied?

Specs improve generation. Governance preserves architecture.

If you are adopting spec-driven development, that is the right direction. Just budget for the layer underneath it. For the durable definition and where it sits in the wider ontology, see the concept page on spec-driven development; for where it fits in the broader lifecycle, see what is the AI SDLC?

FAQ

What is spec-driven development?
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 write code directly, the work moves through requirements, design, an implementation plan, task decomposition, and code generation. Tools like AWS Kiro and GitHub Spec Kit popularized the approach.
Does spec-driven development replace architectural governance?
No. A specification defines what an agent should build. Architectural governance defines which decisions and invariants must constrain how it is built. An agent can satisfy a feature spec and still introduce a forbidden dependency, bypass an approved abstraction, use a deprecated service pattern, or violate an ADR. The two are complementary layers, not competing ones.
How do spec-driven development and Mneme work together?
Spec-driven development structures intent into a spec, a plan, and tasks. Mneme injects architectural constraints before the agent generates code and verifies the output against pre-registered verification contracts. SDD answers what to build; governance answers what must remain true while building it. The mature workflow runs spec, then plan, then governance retrieval and constraint injection, then agent execution, then verification.
Is spec-driven development only a fix for vibe coding?
It is one of the healthiest responses to unstructured vibe coding, but its value is broader: it makes agent work reviewable and decomposable. The remaining gap is architectural. Specs improve generation; governance preserves architecture across repositories, sessions, and agents.