Spec-driven development (SDD) is an approach to AI-assisted software development in which a structured specification of what to build is written and validated before any code is generated. The specification, with its business rules and acceptance criteria, becomes the reference point for both engineers and the AI tools that take on part of the implementation. The term is new, but the problem behind it is familiar: AI produces code faster than people can review it.
How does spec-driven development affect the choice of a development partner?
For companies comparing custom enterprise software development services (https://www.merixstudio.com/services/enterprise-software-development), the way a provider controls AI-generated code has become part of due diligence. This article is most useful for CTOs and product leaders who want to understand spec-driven development before they evaluate a partner’s delivery process.
In a nutshell:
- In SDD, every task starts with a written specification and acceptance criteria, and code generation comes afterwards.
- Birgitta Böckeler describes three levels of adoption: spec-first, spec-anchored, and spec-as-source.
- Enterprise projects benefit most, because their integrations, shared codebases, and audits make ambiguity expensive.
Why did spec-driven development emerge?
Spec-driven development gained attention as AI made code cheap to write and harder to verify. According to the 2025 report by DORA, Google Cloud’s DevOps Research and Assessment program, 90% of surveyed technology professionals use AI at work. The same report found that AI adoption still has a negative relationship with software delivery stability.
With short, open-ended prompts, a model fills the gaps with its own assumptions, which in a large codebase surface later as bugs. SDD moves these decisions to the start of the work, where they are easiest to correct.
Engineering leaders see the same gap from the delivery side:
“AI is fantastic at executing specific, well-defined tasks.”
Miłosz Kusiciel, Head of Technology at Merixstudio
The weak spots, he adds, are business logic, user nuance, and long-term architectural strategy. A specification is the tool that turns those open questions into tasks AI can handle well.
How does spec-driven development work in practice?
SDD splits each piece of work into three stages, and each stage produces something a person can review:
- Specify. The team describes the feature: user goals, business rules, edge cases, and the acceptance criteria that define when the work is done.
- Plan. The specification becomes a technical approach covering affected components, data changes, integrations, and security or performance constraints.
- Implement. The plan is divided into small tasks. AI tools generate code for each one, and engineers review the output against the acceptance criteria.
Dedicated tools follow this pattern. Amazon’s Kiro guides users through requirements, design, and task creation. GitHub’s Spec Kit uses a similar process and adds a “constitution”, a set of fixed principles that every change has to respect. When it released the toolkit as open source in September 2025, GitHub named feature work in existing systems as the scenario where spec-driven development is most useful, with legacy modernization among the others.
Spec-first, spec-anchored, spec-as-source: what are the three levels?
In an October 2025 article on martinfowler.com, Birgitta Böckeler, a Distinguished Engineer at Thoughtworks, described three levels of SDD. They differ in what happens to the specification once the code exists.
| Level | What happens to the specification | Who edits the code |
| Spec-first | Written before the task and used to guide AI-assisted implementation | Engineers, supported by AI |
| Spec-anchored | Kept after the task and updated as the feature evolves | Engineers, supported by AI |
| Spec-as-source | Becomes the main source file, and code is generated from it | Generated by AI; people edit only the specification |
Böckeler notes that all the approaches she found are spec-first, but not all of them aim to be spec-anchored or spec-as-source. She also questions whether the higher levels might combine the inflexibility of older model-driven development with the non-determinism of language models. For most enterprise teams, spec-first is therefore the realistic starting point, with specifications kept for features that change often or carry high risk.
Why does spec-driven development matter in enterprise software development?
Enterprise systems raise the cost of ambiguity, and four of their typical features explain why.
Changes ripple across connected systems
One change can affect integrations with an ERP, a CRM, or a data warehouse. When the specification lists affected components and expected behavior, reviewers can check AI-generated code against that intent before integration testing.
Many teams share one codebase
A written specification gives product owners, engineers, and QA a shared reference that survives handovers and changes in team composition.
Regulated industries need a record of decisions
In finance, healthcare, or manufacturing, auditors ask why a system behaves the way it does. Specifications with acceptance criteria keep that answer on record.
Legacy code needs clear boundaries
When AI works inside an existing system, the specification defines what must stay unchanged. In modernization projects, it protects business logic that was never documented.
Spec-driven development in an AI-augmented delivery model
Some software companies have already built SDD into their standard process. At Merixstudio, it is part of the AI-augmented delivery model: every feature starts with a validated specification and acceptance criteria, and engineers act as architects and reviewers of AI output. The company tracks the impact through DORA metrics. Based on feedback from its engineering team, AI can speed up selected tasks such as code generation, debugging, refactoring, and test automation by up to 25%. AI tools are vetted by technical and legal teams, and project data is not used to train external models.
When does a specification become overhead?
SDD has limits. When Böckeler asked Kiro to fix a small bug, the tool turned it into four user stories with 16 acceptance criteria. For a one-line fix, a full specification can take longer than the change itself, so its depth should match the risk: two acceptance criteria may be enough for a contained change, while a new integration deserves the full process. Specifications also need maintenance, so teams aiming for the spec-anchored level should include updating them in their definition of done.
Summary
Spec-driven development responds to code that is now fast to produce and slow to verify. Starting each task with a specification gives engineers and AI tools a shared reference, which matters most in enterprise projects. The approach works best when each specification matches the risk of the change and stays up to date.
FAQ
What is spec-driven development?
Spec-driven development is an AI-assisted development approach in which a structured specification of a feature is written and validated before code is generated. Engineers then review AI-generated code against the specification’s acceptance criteria.
How is spec-driven development different from test-driven development?
Test-driven development starts with automated tests that define expected behavior at the code level. Spec-driven development starts one step earlier, with the feature’s purpose, rules, and acceptance criteria. The two work well together, because acceptance criteria often become test cases.
Does spec-driven development slow teams down?
Writing a specification adds time at the start of a task. The aim is to save more of it later by reducing rework, which is why teams use lighter specifications for small, contained changes.
Is spec-driven development useful for legacy systems?
Yes. In legacy and modernization work, the specification describes what the existing system does and what must stay unchanged. Engineers can then review AI-generated changes against it and lower the risk of breaking undocumented logic.
Sources
- GitHub, Spec-driven development with AI: Get started with a new open source toolkit, 2 September 2025: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
- Birgitta Böckeler, Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, martinfowler.com, 15 October 2025: https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
- Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development, September 2025: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- Merixstudio, How We Integrate AI into Software Development Process in Merixstudio, November 2025 (quote by Miłosz Kusiciel): https://www.merixstudio.com/insights/how-we-integrate-ai-into-software-development-process-in-merixstudio
- Merixstudio, custom enterprise software development services (AI-augmented delivery, Spec Driven Development): https://www.merixstudio.com/services/enterprise-software-development
