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.
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.
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.
How we implement SDD at onext
At onext, SDD is the foundation of our AI Centers of Excellence. It's not theory: it's how we transform development teams in 4-6 weeks.
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
Real case: From 2 hours per feature to 30 minutes
Client: B2B SaaS Series A, 8 developers
Problem: Inconsistent AI-generated code, a lot of time spent refactoring
Before (without SDD)
- Each developer used Copilot "their own way"
- The generated code ignored the project's conventions
- 60% of the time spent adjusting generated code
- 3 developers solved the same problem in 3 ways
After (with SDD)
- A shared spec with the project's patterns
- A "constitution" defining architecture and conventions
- Spec templates for features, bugs, refactoring
- Consistent generated code across developers
Results (6 weeks):
- Time per feature: 2h -> 30min (-75%)
- Time on refactoring: 60% -> 15% (-75%)
- Code consistency: measured by linter, +40% fewer warnings
- Team satisfaction: 3.2/5 -> 4.6/5
"Now the generated code looks like it was written by us, not by a generic bot"
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.
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.