What is spec-driven development?
Spec-driven development is a way of working where the specification — a concrete, testable description of desired behaviour — is the source of truth for a product. Every implementation, every test, every design decision points back to it. Instead of writing throwaway prompts, you write durable specs.
It combines three ideas the software industry already trusts: story mapping to structure the problem space, jobs-to-be-done to capture user context and outcomes, and behaviour-driven development to describe behaviour in a format that both people and machines can verify.
If you've been writing PRDs and wondering why they keep going stale, here's why the PRD alone falls short in an AI-built world.
Why spec-driven development matters now
AI coding agents amplify whatever you feed them. If you feed them a vague prompt, they'll produce vague — but confident — code. If you feed them a precise specification, they'll build exactly what you specified. The faster agents get at writing code, the more the bottleneck moves upstream to defining what should be built.
Martin Fowler, GitHub, Microsoft, IBM, and Red Hat have all published on SDD in the last year. The industry has agreed: prompting doesn't scale. Specification does.
The three-part SDD toolkit
1. Structure — story mapping and product taxonomy
Every requirement needs a place. A product taxonomy — capabilities, features, journeys, scenarios — gives you a map. New behaviour slots into the map instead of scattering across tickets, docs, and Slack threads.
2. Context — jobs-to-be-done
A specification without context is a list of features nobody asked for. JTBD anchors each capability in a real situation, motivation, and desired outcome — the why behind the behaviour.
3. Verification — behaviour-driven development
BDD-style Given / When / Then scenarios turn behaviour into something that can be executed and checked. If the code passes the scenario, it matches the spec. If it doesn't, you know exactly where.
What changes when you adopt SDD
- Requirements stop being interpreted differently by every reader.
- Ambiguity gets caught before code is written, not after.
- AI agents produce code that matches intent, because the intent is precise.
- Tests aren't an afterthought — they're the same artefact as the spec.
- QA, engineering, and product read the same source of truth.
How Executable implements spec-driven development
Executable is a spec-driven development workflow for product teams. You define capabilities in a structured taxonomy, describe user context with jobs-to-be-done, and specify behaviour with BDD-style scenarios. AI skills help fill gaps and suggest missing coverage. GitHub integration syncs feature files. An MCP endpoint exposes the whole spec to your coding agent as context.
Frequently asked questions
What is spec-driven development?
Spec-driven development (SDD) is a workflow where the specification — a concrete, testable description of desired behaviour — is the source of truth that both humans and AI coding agents build against. The spec drives the code, the tests, and the acceptance criteria, instead of ad-hoc prompts.
How is spec-driven development different from prompting?
Prompting is one-shot: a natural-language request that the AI interprets differently each time. Spec-driven development is durable: a structured artefact that describes intent, context, and verification once, and any agent — or teammate — can build against it reliably.
Do I need to write Gherkin to do spec-driven development?
No. Gherkin (Given/When/Then) is one useful format for behaviour, but SDD is broader. Executable combines story mapping, jobs-to-be-done, and BDD-style behaviour into one structured spec.
How does spec-driven development work with Cursor, Claude Code, or other AI coding tools?
SDD sits upstream of the coding agent. You write the spec in Executable; your agent reads it as context, builds against it, and generates tests that verify the same behaviour. The spec is the interface between product and agent.