Manu's Vault

Spec-Driven-Development

3 min readStatus:Seedling

Spec-Driven Development

Spec-Driven Development (SDD) is a methodology where structured specifications precede and guide AI-assisted code generation — making specs, not code, the primary artifacts that developers author and maintain.

The Core Inversion

Traditional development starts with code; SDD inverts this. A developer writes a specification first, an AI agent generates code to satisfy it, and if that code is ever deleted or regenerated, the spec is sufficient to recreate it. This positions specifications as causal inputs rather than descriptive documents — they don’t describe what exists, they produce it.

This inversion matters because AI coding agents are highly effective at translating structured intent into implementation. The spec captures the what and why; the agent handles the how.

Three Implementation Levels

SDD exists on a spectrum of commitment:

  • Spec-first: A spec is written before implementation and discarded after the task completes. Reduces rework but leaves no trail.
  • Spec-anchored: The spec persists through the feature’s lifecycle, evolving alongside the implementation as a living audit trail.
  • Spec-as-source: Specs become the only artifact humans author directly; code is entirely generated and treated as disposable. Maximally regenerative — analogous to how compiled binaries are treated today.

Each level builds on the previous. Most current tooling (Kiro, GitHub spec-kit) operates at spec-first or spec-anchored.

What Makes Something a Spec?

A spec is “a structured, behavior-oriented artifact written in natural language that expresses software functionality and serves as guidance to AI coding agents” (Boeckeler, 2026). This distinguishes specs from:

  • Memory banks: cross-session context documents not tied to specific features
  • Requirements docs: intended as input to a human process, not directly machine-executable
  • Unit tests: code-level assertions rather than behavior-level specifications

Historical Parallel: BDD and MDD

SDD has two important predecessors:

  • Behavior-Driven Development (BDD) (North, 2006): Given/When/Then scenarios specified behavior before implementation. SDD extends this by using AI as the implementation engine rather than a human developer.
  • Model-Driven Development (MDD): Attempted to raise abstraction above code through models and generators. LLMs provide a more flexible “generator,” but introduce non-determinism as a tradeoff against MDD’s deterministic transformations.

Closing the Loop: Property-Based Testing

A spec without verification is documentation. Property-based testing addresses this by validating that a property holds across a broad (potentially infinite) range of inputs — creating direct traceability from textual requirement to executable assertion. This answers the fundamental question: “How do we know the tests actually verify what the specification demands?”

Sources

  • Kiro (2026). “Property-Based Testing — The Importance of Specification.” kiro.dev. https://kiro.dev/blog/property-based-testing/#the-importance-of-specification

    • Kiro’s three-step SDD workflow (requirements → design → tasks); property-based testing as spec validation; executable specifications

  • Boeckeler, Birgitta (2026). “Spec-Driven Development — 3 Tools: Kiro, spec-kit, and Tessl.” martinfowler.com. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

    • Three SDD implementation levels; definition of “spec”; tool comparison; MDD historical parallel; practical limitations

  • Leaflet (2026). “AI Coding — Regenerative Software and Spec-as-Source.” aicoding.leaflet.pub. https://aicoding.leaflet.pub/3mbrvhyye4k2e

    • Specs as executable intent and causal inputs; version control inversion; specification graph as source of truth

  • North, Dan (2006). “Introducing BDD.” dannorth.net. https://dannorth.net/introducing-bdd/

    • Origin of behavior-driven specifications; Given/When/Then syntax as precursor to SDD; specification-first thinking in software development

  • Schmidt, Douglas C. (2006). “Model-Driven Engineering.” IEEE Computer, Vol. 39, No. 2, pp. 25–31. DOI: 10.1109/MC.2006.58

    • Historical foundation of model-driven approaches; raises abstraction above code; lessons applicable to SDD’s spec-as-source level

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks