Spec-driven development

Spec-driven development (SDD) is a software engineering methodology where a formal, machine-readable specification serves as the authoritative source of truth^[1] and the primary artifact from which implementation, testing, and documentation are derived.^[2][3] Unlike traditional development where documentation is often retrospective, spec-driven development mandates that system intent be explicitly defined in a structured format—such as OpenAPI or Markdown—before implementation begins.^[4] In the context of AI-assisted engineering, spec-driven development serves as a rigorous framework that transforms specifications into executable blueprints for coding agents, preventing the inconsistencies associated with ad-hoc "vibe coding".^[5]

The roots of spec-driven development trace back to 1960s NASA workflows and early formal methods that prioritized logic verification before coding. The methodology was academically formalized in 2004 as a synergy between test-driven development (TDD) and design by contract (DbC), before seeing a 2020s renaissance driven by LLM-powered agentic workflows.^[6]

Modern spec-driven development typically follows a four-phase lifecycle:

• Specify (defining functional requirements),
• Plan (translating intent into technical architecture),
• Task (decomposing the plan into atomic units), and
• Implement (automated code generation and human validation).^[7]

Proponents argue this approach represents a shift toward architecture as an executable control plane, where implementation code is treated as a transient byproduct of the maintained specification—a concept sometimes referred to as "spec-as-source".^[8]

While complementary, spec-driven development is often distinguished from similar practices by its focus on high-level intent:

• Test-driven development (TDD): Focuses on correctness at the implementation level; SDD uses the specification to generate initial tests.^[9]
• Behaviour-driven development (BDD): Focuses on user-facing scenarios; SDD provides the structural and architectural invariants that BDD scenarios must satisfy.^[10]

• Model-driven engineering
• Behavior-driven development
• Formal methods