Spec-Driven Development: A Production Workflow for AI Coding Agents
How spec-driven development turns AI coding from prompting into a reviewable workflow: specify, plan, break into tasks, implement, test, review and ship.
Quick answer
Spec-driven development is the production alternative to vibe coding. Instead of prompting an AI until something works, you write a specification of what to build and why (user journeys, constraints, acceptance criteria), have the coding agent produce a technical plan, break it into small tasks, and implement and test each task as a reviewable change. People approve the spec, the plan and each merge. The spec becomes durable documentation, and every line of code traces back to a stated requirement. GitHub's open-source Spec Kit and AWS's Kiro both formalize this workflow, but it works with any capable coding agent and plain Markdown files.
Why prompts are not enough for production
Prompts are ephemeral. The intent behind a feature lives in a chat history nobody will read again, the agent fills gaps with assumptions, and large AI-generated changes are hard to review. Google's DORA 2025 research found AI adoption associated with higher throughput but lower delivery stability, and among the capabilities it identifies as amplifying AI's benefits are working in small batches and strong version control. Spec-driven development is a practical way to get both: intent written down, work broken into small, reviewable pieces.
The workflow
| Stage | Who leads | Output | Human approval? |
|---|---|---|---|
| 1. Requirement | Product owner | Problem, users, outcome | — |
| 2. Specify | Agent drafts, people refine | Spec: user journeys, rules, edge cases, acceptance criteria | Yes: product and engineering |
| 3. Plan | Agent proposes from stack and constraints | Architecture, data model, interfaces, risks | Yes: tech lead or architect |
| 4. Tasks | Agent | Small, independently testable tasks | Light check |
| 5. Implement + test | Agent, developer supervising | Code and tests per task on a branch | — |
| 6. Review + CI | Developers + automated checks | Merged changes | Yes: code review |
| 7. Security | Automated scans + reviewer for sensitive areas | Findings resolved | Yes for auth, payments, data |
| 8. Deploy + monitor | Pipeline + owners | Released feature, monitoring | Release approval as usual |
Key takeaway
The spec is where business intent is reviewed; the plan is where architecture is reviewed; the pull request is where code is reviewed. Each gate checks a different thing, so none of them should be skipped.
What a good spec contains
- The problem and the users affected, in plain language
- User journeys and the outcome each should produce
- Business rules and edge cases (refund limits, time zones, permissions)
- Non-functional requirements: performance, accessibility, security, privacy
- Out of scope, stated explicitly
- Acceptance criteria that can become tests
- Constraints: stack, libraries, patterns to follow, systems not to touch
Tools: Spec Kit, Kiro and plain Markdown
GitHub introduced Spec Kit on 2 September 2025 as an open-source toolkit that structures the work into specify, plan, tasks and implement phases, with templates and commands for agents including GitHub Copilot, Claude Code and Gemini CLI. AWS's Kiro is an agentic development environment built around specs, requirements and task lists, and has since become generally available with a CLI. Many teams simply keep spec and plan files in the repository and point their coding agent at them through repository instructions (AGENTS.md or equivalent). The discipline matters more than the tool.
Making it work in a team
Keep specs in the repository next to the code, versioned and reviewed like code. Size tasks so each pull request is small enough to understand in one review. Make acceptance criteria executable as tests before implementation where possible. Update the spec when requirements change, then regenerate the affected plan and tasks rather than patching code ad hoc. For security-relevant changes, add the checks from AI-generated code security, and for how agents fit into daily work, see AI coding agents.
Want AI-assisted delivery without the vibe-coding risk?
ZSpace Labs builds web and mobile products with coding agents inside a spec-driven, reviewed and tested workflow. See web development and mobile app development.
When to use it, and when not
| Work | Approach |
|---|---|
| New feature or product | Full spec-driven workflow |
| Significant change to existing behaviour | Spec update + plan + tasks |
| Legacy modernization | Spec of current behaviour first (see AI legacy code modernization) |
| Small bug fix | Short task description with acceptance test |
| Throwaway prototype | Vibe coding is fine; specify before productionizing (see vibe coding vs production software) |
Conclusion
Spec-driven development keeps what makes AI coding fast and adds what production needs: written intent, reviewed architecture, small changes and traceability. Approve the spec, approve the plan, review every merge, and let the agent do the implementation in between. For how team roles change around this workflow, see what an AI-native software team looks like.
Common questions.
A way of building software with AI coding agents in which a written specification, not a chat prompt, is the source of truth. The agent turns the spec into a technical plan and small tasks, implements them, and every change can be traced back to the spec and reviewed.