Spec-Driven Development (SDD) is an AI software development methodology that replaces ad hoc prompts with a structured specification guiding the agent throughout the entire code generation. It appears in the Technology Radar 2025 as an emerging technique.
SDD exists because teams that use GitHub Copilot, Claude Code or Cursor without a method get inconsistent results: the same problem is solved in three different ways by three different developers. The specification eliminates the variability.
Your team uses GitHub Copilot or Claude Code. They write a prompt, get code, review it, adjust it, integrate it. It works... sometimes. Other times the generated code doesn't understand the context, ignores the existing architecture, or solves a different problem than the one posed. The problem isn't the AI. It's how you're using it.
Spec-Driven Development (SDD) is an emerging methodology that already appears in the Technology Radar 2025. It's not another AI tool. It's a fundamental shift in how development teams interact with AI agents to write code. If you arrive here from outside the agentic context, it's worth first reviewing what agentic AI is and how it's transforming software development.
The problem: ad hoc prompts = unpredictable results
Most teams use AI to code this way:
- The developer has a task
- They write a prompt describing what they need
- The AI generates code
- The developer reviews, adjusts, integrates
- Repeat for the next task
Problem: Each prompt is independent. There's no shared context. There's no "memory" of the project. The result depends on the developer's skill at writing good prompts.
Typical consequences:
- Scope creep: the AI solves more (or less) than what's asked
- Lack of context: code that doesn't respect the existing architecture
- "Black box": hard to understand why the AI generated what it generated
- Inconsistency: the same problem solved in 3 different ways by 3 developers
In practice, the quality and monitoring gap that appears when AI agents reach production is where most projects break. SDD exists precisely to close it from the design phase.
What Spec-Driven Development is
Spec-Driven Development inverts the flow. Instead of writing ad hoc prompts, you start with a structured specification that guides the entire code generation process.
The core idea: a detailed functional specification acts as a "North Star" for the AI agents, instead of relying on improvised prompts. Functional analysis paying off again does not mean going back to waterfall: we explain why in the best of waterfall and agile with SDD.
The SDD workflow
1. SPECIFICATION
- Structured document with requirements, intent, constraints
- Acts as the "source of truth" for the project
- Versioned alongside the code
2. DECOMPOSITION
- The spec is broken down into smaller tasks
- Each task is manageable by an AI agent
3. GENERATION
- AI agents generate code based on the spec
- Context comes from the document, not the instant prompt
4. HUMAN REVIEW
- Developers review at each step
- Adjustments are documented to improve the system
5. ITERATION
- Feedback is incorporated into the spec
- A knowledge base is built over time
This pipeline becomes critical in multi-stage workflows with AI agents where a failure at step N propagates to N+1 and N+2 until it amplifies in the final result. The structured specification acts as a contract between stages and limits that propagation.
Why SDD is different (and better)
1. Control and predictability
With ad hoc prompts, the result depends on the quality of the prompt in that moment. With SDD, the result depends on a well-thought-out spec that has been reviewed by the team.
Result: Fewer surprises. More consistent code. Less "what did this code do?" three months later.
2. Structured collaboration
The spec becomes a versioned document that the team can review, discuss and improve. It's the project's source of truth.
Result: Better communication between product, development and QA. Everyone speaks the same language.
3. It overcomes AI's limitations
AI agents have limited context. With SDD, that context comes from the spec, not from the chat history that gets lost between sessions.
Result: Code that respects the existing architecture. Less refactoring afterwards.
4. Full traceability
Every line of generated code can be traced back to a specific requirement. When something fails, you know exactly where to look.
Result: Faster debugging. Simpler maintenance.
For regulated sectors (banking, healthcare, public administration), compliance-first design for agents with audit traceability stops being optional — it's the difference between an architecture that passes the EU AI Act audit and one that doesn't.
3 tools that implement SDD
There are currently three main approaches to SDD, each with a different focus:
1. Amazon Kiro
Guides users through three phases: requirements, design and task creation. A structured but traditional approach.
2. GitHub spec-kit
A three-step process with richer orchestration. Includes configurable prompts and a "constitution" that defines the project's immutable principles.
Key insight: The "constitution" is revolutionary. It defines rules the AI can never violate: architecture patterns, naming conventions, forbidden dependencies. This solves the "the AI ignores our standards" problem.
3. Tessl Framework
The most radical approach: the specification itself becomes the maintained artifact, not the code. The code is a derivative of the spec.
Choosing one of the three is the easy part. What none of them includes is the team's method: when to specify, how much and who decides, as we explain in SDD templates are now free.
How we implement SDD at onext
At onext, SDD is the foundation of our AI-Accelerated Development method. It's not theory: it's how we work with development teams, in a Quick-start of 4–8 weeks. If you want to know what you would need in place before starting, tell us how your team generates code today.
Our proven workflow
Phase 1: Spec documentation (Week 1)
- Project audit: We understand architecture, patterns, conventions
- Creating the "constitution": Immutable rules the AI must respect
- Spec template: A standard format for new features
Phase 2: Tool integration (Week 2)
- Agent configuration: Claude Code, Copilot or similar with project context
- Prompt playbook: Proven templates for common tasks
- Code review flow: A specific checklist for AI-generated code
Phase 3: Team adoption (Weeks 3-4)
- Hands-on workshop: The team learns by writing real specs
- Pair programming: Experienced developers guide juniors
- Tracking metrics: Time saved, code quality, consistency
Phase 4: Continuous optimization (Weeks 5-6)
- Spec refinement: We learn from what works and what doesn't
- Use case expansion: We apply SDD to more types of tasks
- Team autonomy: The team maintains and improves the system without us
Example: how a team's work changes with SDD
An illustrative example, without figures: the development team of a B2B SaaS that uses AI to code, but each person in their own way.
Before (without SDD)
- Each developer used Copilot "their own way"
- Generated code ignored the project's conventions
- A good share of the time went into adjusting generated code
- Three developers solved the same problem in three different ways
After (with SDD)
- A shared specification with the project's patterns
- A "constitution" that defines architecture and conventions
- Specification templates for features, bugs and refactoring
- Generated code consistent across developers
An important nuance: constructive caution
The Technology Radar places SDD in the "Assess" category (explore with caution). The assessment is realistic:
"Although the space is fascinating, the workflows are still elaborate and full of decisions made by personal judgment. The tools generate extensive specifications that are hard to review."
Our interpretation: Generic SDD tools can be complex. But when the methodology is adapted to your specific context (your architecture, your team, your conventions), the benefits outweigh the learning curve.
That's why at onext we don't sell a tool. We implement the methodology adapted to your team.
And when an agent writes the code, the specification is also where someone signs off what gets built. We cover it in Specs and agents: the specification is where you sign off.
Key SDD principles to start today
You don't need complex tools to start with SDD. These are the principles you can apply from today:
1. Write before you ask
Before writing a prompt, write 3-5 lines describing:
- What problem this solves
- What constraints it has
- How it should integrate with the existing code
2. Define your "constitution"
Document your project's immutable rules:
- Architecture patterns you always use
- Naming conventions
- Allowed and forbidden dependencies
- Folder structure
3. Create spec templates
A simple template for new features:
## Feature: [Name]
### Problem
[Which user problem it solves]
### Solution
[How we solve it at a high level]
### Constraints
- [Architecture to respect]
- [Patterns to use]
- [What it must NOT do]
### Acceptance criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
### Integration
[How it integrates with the existing code]
4. Review with the spec in hand
In code review, don't just review the code. Review whether the code meets the spec. If there's no spec, that's the first problem.
Conclusion: From "using AI" to "integrating AI"
Spec-Driven Development isn't just another tool. It's a mindset shift:
- From: "AI is a smart autocomplete"
- To: "AI is an agent that executes specifications"
Teams that adopt SDD don't write less code. They write better code, faster, with more consistency. And most importantly: the generated code is maintainable in the long run.
The question isn't whether your team will use AI to code. The question is whether they'll use it chaotically (ad hoc prompts) or in a controlled way (spec-driven).
Frequently asked questions about Spec-Driven Development
What is Spec-Driven Development (SDD)?
Spec-Driven Development is an AI software development methodology that replaces ad hoc prompts with a structured specification that describes what the code must do, under which architecture and with which constraints. The AI agent (Claude Code, Copilot, Cursor) generates code against that spec, not against a loose prompt. The result: the same problem solved the same way by different developers.
How is SDD different from TDD or BDD?
TDD (Test-Driven Development) writes the tests first; BDD (Behavior-Driven Development) writes the expected behavior in natural language first. SDD writes the complete functional and architectural specification first, which the AI agent then uses to generate all the code. TDD and BDD are disciplines for people writing code; SDD is a discipline for people directing AI agents that write code.
How do you apply SDD with Claude Code or GitHub Copilot?
The spec is materialized as a structured document (Markdown or YAML) that
the agent reads as context before generating. In Claude Code you use
CLAUDE.md or dedicated spec files; in Copilot you use
.github/copilot-instructions.md; in Cursor you use project
rules. The spec describes product context, architecture, code conventions,
edge cases and acceptance criteria.
Does SDD work for teams maintaining legacy code?
Yes, and that's precisely where it pays off most. In legacy code the spec acts as a map: it defines the real existing architecture, the safe extension points and the zones that must not be touched. The AI agent stops "inventing" because the spec gives it the context that the legacy code doesn't document by itself.
When is SDD NOT worth applying?
Exploratory prototypes where the goal is to discover what to build, not to build it well. In those cases a premature spec kills your speed. SDD fits when you already have production, a defined architecture and a multi-developer team. If you're working solo on a 2-week MVP, you don't need it.
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and a person who decides where there is risk— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →