Insights
Spec-driven development, explained for people who buy software
What spec-driven development means for scope, quotes, review and risk when your partner builds with AI, plus the questions to ask before you sign.
Key takeaways
Spec-driven development means a written, agreed specification comes before code, and AI coding agents build from it.
The spec is a living document. Writing it first is not the same as freezing it.
For buyers, the spec becomes the thing you review and sign off: scope you can read, estimates with a basis, and an audit trail of every decision.
On a healthcare platform we built on AWS, working this way lifted features shipped per sprint by 66%, with fewer defects and higher test coverage.
Spec-driven development is turning up in delivery proposals, usually in a sentence about AI. Most of what is written about it is for developers choosing tools. This piece is for the person signing the contract: what it is, what changes when your delivery partner works this way, where it doesn’t fit, and what to ask before you commit.
What is spec-driven development?
Spec-driven development is a way of building software where a written specification of what to build is agreed before any code is written, and AI coding agents generate the code from it. The specification covers requirements, design and a breakdown of tasks. It stays current as the work changes, so it remains the single source of truth.
In practice the spec is a small set of plain documents: what the feature must do and how you’ll know it works, how it will be designed, and the tasks needed to build it. An engineer, or an AI agent supervised by one, works through the tasks. When something changes, the spec changes first.
Thoughtworks’ Birgitta Böckeler describes three levels of the practice:
Spec-first: a spec is written for a piece of work, then set aside once it’s built.
Spec-anchored: the spec is kept and updated as the feature evolves.
Spec-as-source: the spec is the main artefact, and people rarely edit the code by hand.
For most organisations, spec-anchored is the sensible target: the spec outlives the build and stays useful.
Why it showed up now
Spec-driven development showed up because AI made writing code fast, which moved the bottleneck to deciding what to build. When a well-specified feature can be built in a day, a vague requirement becomes the most expensive thing in the room. The spec is how teams keep the speed without paying for it in rework.
The evidence backs this up. Google’s 2025 DORA report found around 90% of software professionals now use AI, and for the first time AI is lifting delivery throughput. It also found delivery instability rising alongside it: more rollbacks, hotfixes and unplanned work. DORA’s conclusion is that AI amplifies whatever is already there. Clear intent gets built faster. So does confusion.
The opposite of spec-driven development is what developers call vibe coding: describing what you want in a prompt, accepting what comes back, and fixing it as you go. That works for a prototype. It does not work for a system your customers, staff or regulator depend on.
How spec-driven development works, step by step
Spec-driven development runs as a loop: agree the intent, design it, break it into tasks, build against the spec, then feed what you learn back into it. AWS formalises this as the AI-Driven Development Lifecycle (AI-DLC), with three phases: Inception, Construction and Operations. Each step ends with a person approving the output.
Intent and requirements (Inception). The business and the delivery team agree what the feature must do and the acceptance criteria that prove it works. AI drafts and asks clarifying questions; people decide.
Design. Architecture, data and interface decisions are written down and reviewed before build starts.
Tasks. The work is split into small units that can each be built and checked in hours or days.
Build and review (Construction). AI agents generate code against the tasks. Engineers review it against the spec and the acceptance criteria, with automated tests doing the line-by-line checking.
Run and learn (Operations). What happens in production, from bugs to usage, goes back into the spec for the next cycle.
AWS describes the model on its DevOps blog and publishes the AI-DLC workflow rules as open source. AWS’s Kiro development environment follows the same pattern: it produces requirements, design and task documents before it writes code.
Is spec-driven development just waterfall?
No, as long as the spec can change. Waterfall locked requirements at a phase gate and found out months later whether they were right. Spec-driven development writes the spec first but revises it every cycle, and those cycles take hours or days rather than quarters. The order of work looks familiar. The pace and the feedback loop do not.
The risk is real, though: hand a frozen spec to a team and wait, and you have rebuilt waterfall with faster typing. We made the longer argument in Is AI making waterfall right again?.
What changes when you’re the one buying
When your delivery partner works spec-driven, the spec becomes the thing you buy, review and sign off. That changes how scope is agreed, how estimates are made, how change is handled and what you own at the end. Most of these changes favour the buyer, provided you ask for them in the contract.
Scope you can read
The detailed spec is a working document for the delivery team. What the business approves is a plain-language summary of it, not a backlog only engineers understand. If you can’t read what you’re asked to approve, you can’t really approve it, and that’s a problem to raise early.
Estimates with a basis
Quotes come from agreed requirements and a task breakdown rather than a guess at a feature list. That gives fixed-price or capped engagements firmer footing and fewer surprises late in the build.
Change requests become spec changes
When priorities move, the spec is updated first and you can see exactly what changed, why, and what it does to cost and timeline.
Review shifts from code to intent
Nobody on your side can review every line an AI agent writes, and you shouldn’t need to. Your people check that the spec says the right thing. Engineers and automated tests check that the code does what the spec says.
An audit trail by default
The spec’s history records who approved what and when. For organisations answering to a risk function, APRA’s CPS 230 or Privacy Act obligations, that is a record you would otherwise have to reconstruct.
Ownership at handover
Make the spec a named deliverable alongside the code. A system that comes with its spec is far easier for the next team, or the next AI agent, to change safely.
What it looked like on our project
On a recent project for a healthcare client, building a cloud platform on AWS, we moved the team to spec-driven delivery. Our product owner and engineers wrote the specs alongside our experience design team, and engineers built against them with AI coding agents. The client approved a plain-language summary of each spec, then the features as they shipped, rather than reviewing code.
The team shipped 66% more features per sprint than it had before the switch. Quality went up with the pace, not down: defects fell and test coverage increased. That follows from how the work is set up. Every spec carries acceptance criteria, and those criteria become automated tests before the feature is called done. In a sector where a defect can reach a patient or a clinician, that mattered more to the client than the speed.
Where it doesn’t fit
Spec-driven development is not the right tool for everything. It adds little when you don’t yet know what problem you’re solving, when a change is small enough that the spec would take longer than the work, or when a team treats the spec as a sign-off gate rather than a living document. Use it where the cost of building the wrong thing is high.
Early discovery work is better served by research, prototypes and conversations with users, which then feed the first spec. The Thoughtworks Technology Radar also cautions against over-specifying: a spec that tries to settle every detail up front slows the loop it is meant to speed up.
Questions to ask a delivery partner
Before you sign with a partner who says they work spec-driven, ask them to show rather than tell. Six questions separate teams that have done it from teams that have read about it:
Who writes the spec, and who on our side signs it off?
Can we see a spec from a past engagement?
How is the spec kept current once the build starts?
How do spec changes flow through to cost and timeline?
How is AI-generated code checked against the acceptance criteria?
Do we own the spec at handover, and which AWS region do the code and data run in?
How Honest Fox works this way
Our process has always run Hunt, Leap, Track: discovery, then design and build, then optimisation. Spec-driven delivery maps onto it directly, as Inception, Construction and Operations. Our product owners, engineers and experience designers write the spec together; our AWS-certified engineers build from it with AI agents. You approve a summary of what will be built and the features as they ship, not lines of code.
We’re an AWS Partner at Select Tier Services, so AWS certifies our engineers and reviews the work we deliver. We also publish Kit, a free, open-source starter kit for building AI agents on AWS, built the same way.
Frequently asked questions
What does SDD stand for?
SDD stands for spec-driven development: a way of building software where an agreed, written specification of requirements, design and tasks comes before code, and AI coding agents build from it. The spec is updated as the work changes, so it stays the single source of truth for what the system should do.
Who writes the spec in spec-driven development?
The spec is written jointly. The delivery team’s product, design and engineering people draft it, often with AI assistance, and the business owner on the client side approves it. The approver should be someone who can say whether the requirements are right, not only someone who can read code.
Does spec-driven development cost more up front?
It shifts effort earlier. More time goes into agreeing requirements and design before build, and less goes into rework afterwards. On most projects that means fewer surprises and steadier delivery overall, but the discovery and spec work should be scoped and paid for properly rather than treated as a formality.
What is the difference between spec-driven development and AI-DLC?
Spec-driven development is the practice of building from an agreed specification. AI-DLC, the AI-Driven Development Lifecycle, is AWS’s model for running a whole delivery lifecycle around AI, across Inception, Construction and Operations. AWS doesn’t use the term itself, but the two fit together: AI-DLC’s Inception phase produces the spec (requirements, user stories and units of work, validated by the team), and Construction builds from it.
You approve the spec, not the code.
Dillon Bailey, Honest Fox
Planning a build?
Talk to us about what its spec would look like, and how we'd deliver it on AWS.
