Toward the end of the summer vacation season, while browsing through the vast body of AI-related news and knowledge, I repeatedly came across a seemingly new concept called spec-driven development (SDD). After some reading, I could not help but notice that I had already dipped my toes into the topic without realizing it.
Doing the right thing
When I developed Grotto, the runtime reference implementation for the Neander language (for more details read my related blog post series), I took the liberty, as a certified software architect, of first creating a full-blown arc42 architecture specification accompanied by a C4 model of Grotto. Since this was my own project, it was one of those rare opportunities where project management could not tell me that this was exactly the right thing to do, only not right now, given the current circumstances. It was just me and my agent. Claude knew all the standards and best practices, helped me write the spec, then created a technical design document from the architecture, and finally developed the software following the design. Old school. By the book. Heaven!
And, apparently, not entirely different from all-new spec-driven development.
What is SDD?
So, what is spec-driven development, actually? Well, this is where the honeymoon phase ends and the problems start.
Even among the most respectable sources in the industry, there is no broad agreement on a single, concise definition of the term. As with most things AI, it is early days, and everything is still up in the air.
GitHub Spec Kit (September 2025, unchanged through v1.0.4)
Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the "real work" of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.
Thoughtworks (December 2025)
[Liu Shangqi's] understanding of spec-driven development (SDD) is that it’s a development paradigm that uses well-crafted software requirement specifications as prompts, aided by AI coding agents, to generate executable code.
Red Hat engineers on InfoQ (January 2026)
The name Spec Driven Development may suggest a methodology, akin to Test Driven Development. However, this framing undersells its significance. SDD is more accurately understood as an architectural pattern, one that inverts the traditional source of truth by elevating executable specifications above code itself.
[...] Traditional architectures rely on source code as the canonical control surface. In SDD, that control surface moves upward into a specification control plane. This control plane formally allows us to define artifacts such as:
- Interface contracts (capabilities, inputs/outputs, behavioural guarantees)
- [...]
- Security boundaries (identity, trust zones, policy enforcements)
- [...]
- Resource and performance constraints (latency, throughput, costs)
IBM (May 2026)
Spec-driven development (SDD) is a software methodology in which a detailed specification of implementation details is authored and agreed upon before development begins.
[...] These [specs] are similar to the functional specs product managers write, but scoped tightly to what the implementation must include, or its acceptance criteria, and how to handle edge cases gracefully.
Microsoft (June 2026)
Spec-Driven Development (SDD) is a spec-first approach. Teams define common guardrails, requirements, constraints, acceptance criteria, and edge cases up front, then use AI to generate code, tests, and supporting artifacts from that shared context.
To sum up: It is a mess.
Meanwhile, the terminology is growing faster than the agreement. The Red Hat article cited above calls a system built this way a spec-native system, and the operational discipline around it SpecOps.
The history of SDD
Where does this confusion stem from? Is it really just early days, or is there more to it? Time to ask Claude to research the history of the term and what it was actually supposed to mean. It turns out the term has had three separate lives.
The agile beginning (2004)
The first one was academic. In 2004, at the XP conference in Garmisch-Partenkirchen, Jonathan Ostroff, David Makalsky and Richard Paige presented a paper titled Agile Specification-Driven Development. It proposed combining Test-Driven Development with Bertrand Meyer's Design by Contract, on the grounds that tests and contracts are both specifications.
Specification-driven development entered the literature as an agile idea, twenty-two years ago.
The coinage of the exact term (2014)
The second one belonged to the API people. In November 2014, Mike Stowe at MuleSoft published API Best Practices: Spec Driven Development, arguing that one of the quickest ways to kill an API is to define it in the code instead of coding to its definition. Write the contract first, in RAML or Swagger, generate a mock from it, put that mock in front of real client developers, and only then implement the server, without deviating from the spec.
The API community has used the term continuously ever since, mostly as a synonym for design-first.
The re-coinage (2025)
The third one is what everybody means today, and it arrived without a backward glance at either of the other two. Sean Grove's talk The New Code at the AI Engineer World's Fair in June 2025 is the usual starting point. His argument: a developer prompts a model, then discards the prompt and version-controls the output, which is like shredding the source and carefully versioning the binary. The specification is the artifact worth keeping. AWS Kiro followed in July, GitHub Spec Kit in September, and by the end of the year Thoughtworks had the technique on its Technology Radar.
Timeline
| Year | What happened | What a spec was |
|---|---|---|
| 1986 | Bertrand Meyer builds Design by Contract into Eiffel | Preconditions, postconditions, invariants |
| 2002 | Kent Beck, Test Driven Development: By Example | A test |
| 2004 | Ostroff, Makalsky and Paige, Agile Specification-Driven Development | A test and a contract, both counted as specification |
| 2006 | Dan North introduces Behavior-Driven Development | A described behavior |
| 2007 | RSpec 1.0 ships | The test file, which is literally called a spec |
| 2011 | Gojko Adzic, Specification by Example | Acceptance criteria as living documentation |
| 2014 | Mike Stowe, API Best Practices: Spec Driven Development | The API contract, in RAML or Swagger |
| 2015 | Swagger is donated and becomes the OpenAPI Specification | An OpenAPI document as the source of truth |
| 2025 | Sean Grove, The New Code, at the AI Engineer World's Fair | A prose document as the durable artifact |
| 2025 | Kiro and Spec Kit ship | A folder of Markdown files |
| 2025 | Thoughtworks puts SDD on the Technology Radar, in Assess | A document, a set of documents, or structured artifacts |
To sum up: Four decades, one term, and a different spec almost every time.
Where to go from here
In light of these findings, I have decided to start this new open-ended blog post series According to Plan: spec-driven development, spec-native systems, and whatever it all ends up being called. I strongly believe in the overall concept (as my earlier post Speccing Is the New Coding already suggested) and I also plan to throw my own hat into the ring instead of just observing.
One thing that clearly needs fixing is the definition of SDD. I do intend to tackle it sooner rather than later, but I am not putting a date on it, given the intricacies of the task.
In any case, I am pleasantly surprised and relieved to learn that having a plan is considered relevant instead of old-fashioned in this day and age. The state of software development projects on the ground sometimes made me wonder whether that was still the case.
Let's make plans.
Top comments (0)