What is SDD?
Spec-Driven Development (SDD) is a form of AI prompting for software development. Instead of starting with code and documenting later, SDD starts with documentation and then generates code. In this technique, the documentation uses one or more files called specifications (“specs”) that define basic criteria for a desired outcome, such as:
- What the system should do (features, behaviors, user stories)
- How it should behave (acceptance criteria, edge cases, instrumentation)
- Why it matters (user goals, experience outcomes)
The specs become the source of truth for both humans and AI agents, guiding code generation, testing, and validation throughout the software development lifecycle. This means a human only needs to review specs and completed code, they do not need to be part of the code generation process.
Why SDD Matters
Software developers who delegate tasks to AI agents increasingly rely on specs to articulate intent and validate outcomes. SDD is a learned behavior, shaped by tools like Claude, GitHub Copilot, and internal frameworks. It’s not always intuitive, especially when design and architecture documents aren’t always the engineer’s domain, but it’s becoming essential as AI becomes a core collaborator in creating software.
There are two main ways to leverage SDD:
- High-trust developers use specs to guide AI agents toward outcomes and then “peace out” until code generation is done.
- Low-trust developers use specs to break down and scrutinize tasks and code generated by the AI.
Specs serve as both anchors for collaboration and contracts for automation.
The SDD Process
SDD typically has four stages:
- Specify: Define the software product or feature in natural language, including personas, user stories, and success criteria.
- Plan: Translate the spec into technical contexts, research tasks, and architectural constraints.
- Tasks: Break down the plan into categorized tasks (setup, core, tests, polish).
- Code & Validate: Use AI agents to generate code, run tests, and validate against the spec.
How is this different than prompt engineering?
SDD vs. Prompt Engineering
| Aspect | SDD | Prompt Engineering |
| Goal | Structured, testable specs guiding the software development lifecycle | Precise prompts for LLM outputs |
| Focus | System-level planning, automation | Task-level interaction with LLMs |
| Output | Living documents (contracts) | Immediate responses (text, code, etc.) |
SDD is all about system-level planning and automation, while Prompt Engineering focuses on crafting inputs for specific outputs from language models.
Methodology & Workflow
- SDD: Write specs (user stories, constraints, validation), generate code via agents, validate outputs, track progress.
- Prompt Engineering: Design effective prompts, iterate on structure and tone, refine outputs using specialized tools.
Cognitive Model
- SDD: Treats LLMs as collaborators executing against a spec.
- Prompt Engineering: Treats LLMs as tools responding to instructions.
Use Cases
- SDD: Building products, features, or agentic systems, coordinating multi-agent workflows, ensuring traceability and testability.
- Prompt Engineering: Rapid prototyping, exploratory analysis, enhancing LLM reliability.
Hybrid Approaches
Advanced teams blend both SDD and prompt engineering:
- Use prompt engineering to bootstrap specs.
- Feed specs back into prompts for better grounding.
- Create feedback loops where LLMs validate and refine their own outputs.
Tools like Kiro IDE or Lovable bridge the gap, analyzing requirements in “spec mode” before generating code.
Summary Table
| Feature | Spec-Driven Development | Prompt Engineering |
| Scope | System-level | Task-level |
| Artifacts | Specs, plans, tests | Prompts, completions |
| Validation | Automated tests, metrics | Human-in-the-loop |
| Tools | GitHub Spec Kit, Kiro, SDD frameworks | Copilot Playground, T-Prompt, Prompt Report |
How does SDD compare with traditional product design processes?
One common method for defining and delivering a new product or feature is to use a Product Requirements Document (PRD). PRDs are foundational artifacts in product development that outlines what a product should do, why it matters, and what features or capabilities must be included in a release.
These documents are a shared reference for teams—product, engineering, design, and QA—ensuring alignment on goals, user needs, and success criteria. By clearly defining the “why” and “what” (but not the “how”), a PRD helps teams build the right solutions efficiently and avoid miscommunication or scope creep.
SDD vs. Traditional Product Requirements Documents (PRDs)
| Dimension | PRD (Product/Design) | SDD (Engineering/QA) |
| Audience | Product/design | Engineering/QA |
| Focus | Experience outcomes | Executable behavior |
| Detail | Lightweight | Deep, testable |
| Validation | Usability/playtesting | Automated tests |
| Change Management | Flexible | Guardrails, traceability |
| Outcome | Shared understanding | Living, testable contract |
SDD complements PRDs by offering stronger technical rigor and automation, while PRDs remain more accessible for non-technical stakeholders.
Example
GitHub open-sourced a spec kit that provides an overview and samples for getting started with SDD. Click this link or use the direct URL: https://github.com/github/spec-kit
There are 4 samples in the kit:
- Spec template: this is for specifying details about the technical and functional implementation of the product, such as how the system flow works, what pieces it has (backend, frontend, etc.), user scenarios and testing requirements, and acceptance criteria.
- Plan template: this outlines technical choices (e.g. programming languages and versions, dependencies, target platforms, performance goals, etc.), defines the product structure and source code formats, and defines the overall research, testing, and task planning approach.
- Tasks template: this spec is where the Spec and Plan documents get converted into specific, technical tasks that result in code generation, testing, and validation.
- Agent Tile template: this spec defines what AI technologies (e.g. LLMs, coding platforms, etc.) are use, how they are used, and what commands/actions they can perform.
Final Thoughts
Spec-Driven Development is rapidly gaining traction as a robust, automation-friendly approach to software creation. By centering the process around detailed, testable specs, SDD enables human developers to use AI tools with clarity, rigor, and traceability. While PRDs and prompt engineering remain valuable, SDD offers a source of truth, or a “living contract” that drives quality, reliability, and repeatability in modern development workflows.