Spec-driven development went from a niche idea to a category in about a year. AWS built an entire IDE around it with Kiro. GitHub open-sourced Spec Kit. A row of frameworks (BMAD, GSD, SpecDD) now compete to sell you the one true format, Martin Fowler's site has a piece on it, and ThoughtWorks named it a defining engineering practice of 2025.
What people actually mean by it
The idea itself is simple. You articulate what you are building and why, as a structured artefact, then you build from that artefact instead of from a one-off prompt or someone's memory.
It is worth being precise, because the term has narrowed. As Kiro and Spec Kit have defined it, spec-driven development is specifically a coding workflow: a structured spec drives an agent through phases, specify, plan, tasks, implement, to generate the code. The spec is the architecture made explicit: features with acceptance criteria, solution designs for how they will be built, the decisions that constrained them, and the tests that verify them. The genuinely new part is not writing things down first. It is the second reader, an AI agent that takes the spec completely literally and fills any gap with a guess rather than a question.
How the loop runs
In its tool form, spec-driven development is a sequence, not a single document. The shape Spec Kit and Kiro both use is roughly specify, plan, tasks, implement. You write the specification of what you want. The agent turns it into a technical plan. The plan is broken into discrete tasks. Then the agent implements the tasks, checking back against the spec as it goes. Each stage is reviewable, and the point is that a human signs off on the thinking before any code is generated, instead of reviewing a wall of code after the fact.
The tools differ mostly in packaging. Kiro is a full IDE built around the loop, Spec Kit is a CLI that drives whatever coding agent you already use, and Tessl pushes furthest toward treating the spec itself as the source. The move underneath all of them is the same as writing a test before the implementation, one level up: you pin down the intended behaviour first, so the generation step has something concrete to satisfy and something concrete to be checked against.
How literally you take it
Not everyone means the same thing by "build from the spec", and Birgitta Böckeler's write-up draws a useful line through three levels. Spec-first is the lightest: you write a spec to get a good first generation, then the code becomes the source of truth and the spec is allowed to fall away. Spec-anchored keeps the spec around as a living document maintained alongside the code, so it stays useful for the next change. Spec-as-source is the strongest claim: the spec is the primary artefact and the code is treated as a generated output, the way compiled binaries are today.
Most teams in practice sit at spec-first or spec-anchored. Spec-as-source is the ambitious end, and it only holds up if the spec can genuinely be trusted as the source, which is exactly where the hard problems live.
How we got here
Spec-first thinking is not new. Writing the expectation down before you build has a long lineage, and the recent surge is less a new idea than an old one meeting a new reader: an AI agent that takes whatever you write completely literally. A short timeline shows how it arrived.
- Early 2000s. Test-driven and behaviour-driven development popularise writing the expectation, a test or a described behaviour, before the code.
- 2021 to 2022. GitHub Copilot, then ChatGPT, make AI code generation mainstream. "Vibe coding", prompting your way to software, arrives with them.
- 2023 to 2024. Agentic tools like Cursor and Claude Code mature. The ceiling of prompt-only work becomes obvious: the model is capable, but it is guessing at everything you did not say.
- July 2025. AWS previews Kiro, an IDE built around spec-driven development.
- September 2025. GitHub open-sources Spec Kit, formalising the specify, plan, tasks, implement loop for any agent.
- November 2025. Kiro reaches general availability. ThoughtWorks writes spec-driven development up as a key practice of the year.
- 2026. The category crowds in: Tessl, BMAD, GSD, SpecDD, a Martin Fowler piece, Spec Kit past ninety thousand GitHub stars. The backdrop is the 2025 Stack Overflow survey, where AI-tool use kept climbing while trust in the output fell. Producing code got cheap. Knowing whether it is correct did not.
The pattern is clear enough. The idea is two decades old. AI agents are what made the cost of skipping it suddenly, painfully visible.
"Isn't this just waterfall?"
This objection deserves a straight answer, because done badly it is exactly waterfall. Write a 200-page requirements document, freeze it, and throw it over the wall to whoever or whatever implements it, and you have rebuilt every failure mode that killed waterfall the first time. ThoughtWorks warns about precisely this: heavy up-front specification and big-bang releases wearing a new name.
The difference is not whether a spec exists. It is whether it is frozen or living. A living spec is a connected graph: a decision gets superseded and the record says so, a feature changes and the tests linked to it surface for review, the architecture moves and the affected designs are right there beside it. Big Design Up Front fails because reality changes faster than the document. The answer is not to stop writing things down. It is to make the written version cheap to change and connected enough that a change is visible everywhere it lands.
The honest failure mode: stale specs
Here is the part most posts on the subject skip. The strongest argument against spec-driven development is not waterfall, it is rot. A stale spec is worse than no spec at all. A human reading an out-of-date design doc is sceptical and cross-checks it. An agent reads it literally, executes a plan that no longer matches reality, and does it with total confidence and no signal that anything is wrong.
We have watched this happen. A spec that everyone can edit and nobody owns drifts within weeks. An AI that defaults to exhaustive, plus an engineer who defaults to cautious, will between them produce thousands of lines of documentation almost by accident, and most of it is dead on arrival.
There is no magic fix, but the problem has a shape. Specs stay alive when they are small, linked, and owned. Linked, so a change in one place surfaces what it affects instead of leaving it silently wrong. Owned, so reconciling concurrent edits is actually someone's job. A single frozen document rots. A connected graph, tied to the features and tests it describes, at least tells you when it has drifted.
Where spec-driven and test-driven development meet
Test-driven development is not going anywhere, and the two are not rivals. They are the same instinct at two different altitudes.
Test-driven development works bottom-up: a failing test for a unit of behaviour, then the code that makes it pass. Spec-driven development works top-down: the feature, its acceptance criteria and the decisions around it, then the build that satisfies them. The gap TDD cannot close on its own is intent. A test proves the code does what the test says, not that the test checks the thing the business actually needed. We have all seen a green suite on a feature that still shipped wrong.
That gap is what the spec fills. When tests are derived from a feature's acceptance criteria and linked back to it, TDD stops checking implementation trivia and starts validating intent. The spec gives the tests their targets. The tests give the spec teeth, because a linked, executable test is the one part of your documentation that fails loudly when reality drifts from it. A passing test tied to a feature spec is also the cheapest answer we know to the stale-spec problem: it is a piece of the specification that cannot quietly go out of date without something going red. So it is not spec instead of tests. It is the spec first, and the tests as the most durable thing you build from it.
The shift
The change in mindset is to stop treating specifications as documentation you produce after the real work, and start treating them as the architecture itself, captured so people and machines can both build from it. The sceptics are right that this fails when the spec is frozen, bloated, or unowned. It works when the spec is small, connected, and alive.
Whichever spec-driven tool you reach for, that last part is the hard bit, and it is the part the tooling tends to assume rather than solve. The code generators are genuinely good now; the open question is always the spec underneath them: is it current, is it owned, can the next person or agent actually trust it?
That underneath layer is where Specsource sits, and to be clear it is not a spec-driven development tool itself. It is not an IDE and it does not generate code, which is what Kiro and Spec Kit are for. It is adjacent to that loop: the source of truth those tools, and any AI agent, can read from, with features, designs, decisions and tests kept connected and alive. Spec-driven development is only ever as good as the spec underneath it, and keeping that spec trustworthy is the part we work on. Get the source right and everything downstream, generated or hand-written, has a better chance of being correct.