Concept 8 min read

# Spec-Driven Development

A structured specification becomes the source of truth for what an AI agent builds. But a spec defines what to build — not which architectural decisions must remain true while the agent builds it.

By Theo Valmis·May 2026

Definition

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:

Requirements Design Implementation plan Task decomposition Code generation

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.

Related concepts

- Governance Before Generation

  Constraints evaluated before the agent writes code — the enforcement point a spec alone does not move.

- Verification Contracts

  Pre-registered, machine-evaluable assertions that prove an agent-generated change complied.

- Architectural Drift

  What accumulates when spec-conformant changes still diverge from intended architecture.

- Decision Continuity

  Decisions stay enforced across the sessions, agents, and tools that execute a spec.

Related operational essays

- Spec-Driven Development Still Needs Architectural Governance

  The market-context companion piece — why structured specs still leave the architectural layer open.

- What Is the AI SDLC?

  Where spec-driven workflows fit in the AI-native software delivery lifecycle.

- Goal-Driven Agents Need Architectural Governance

  When the unit of work shifts to an objective, the agent becomes an optimizer that needs constraints.