https://www.thoughtworks.com/en-in/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices
Spec-driven development may not have the visibility of a term like vibe coding, but it’s nevertheless one of the most important practices to emerge in 2025. It also highlights how quickly software engineering has evolved in recent months as it has adapted to new AI tools and found new ways of leveraging them.
But as with any new term or practice, understanding exactly what it is is difficult. And there are also questions about how effective a technique where everything is seemingly defined up front really is: can we really consider it agile? In this blog post I'll dive into my take on what it is and discuss how it's being done.
My 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.
It’s worth noting though that there are different opinions within the industry about what a spec is and its role in SDD. At the more radical end of the spectrum, there’s an argument that we can now discard code and treat specs as the sole source of truth that needs maintenance. In this view, code is a kind of byproduct, an intermediate product between requirements and compiled binaries. In contrast, more old-school technologists — like me — believe specs are merely elements that drive code generation, as it does in test-driven development. Executable code remains the source of truth you need to maintain.
Part of the reason for this disagreement is how approaches have evolved over the last two years since the industry began using generative AI to produce code. When we were first exploring serious programming using ChatGPT, we found that code generated by setting technical specifications (technology stack, architectural style, coding style) using chain-of-thought and few shot prompting greatly was of higher quality compared to plain-text requirements. More recently, though, as AI coding tools have improved, it has become easier to bring functional requirements into the picture.
While this clearly has benefits, we can’t rely on functional requirements alone: we need to pay attention to the technical details.
Manipulating computers with natural language that represents business has always been the holy grail of software development and programming language theory. In fact, attempts at spec-driven code generation pre-date the LLM era — they’ve just never reached the level of actual development.
Specs have been used in a number of different ways in software engineering. In distributed computing and RPC communication, for example, specs act as communication contracts between different heterogeneous systems. This usually involves a lot of tedious cross-cutting layer work, including cross-language data type validation, routing, interceptors and observability.
In behavior-driven development (BDD), meanwhile specs are used as a vehicle to facilitate collaboration with business users. They’re typically written as scenarios and examples and treated as living documents of system behavior. This is supported by automated testing and continuous integration mechanisms.
However they’re used, they’re ultimately text-based instructions — and given LLMs ability to manipulate text, it’s unsurprising that specs may play so nicely with the growth of AI in software engineering.
Of course, early coding assistants like GitHub Copilot were focused only on generating code snippets. It’s only as the context windows of foundation models have grown that it’s become easier to write code and build software directly from natural language requirements.
To facilitate this, the latest AI coding agents generally separate the planning and implementation phases of the development process in some form. The planning phase focuses on understanding requirements, designing constraints and better curating prompts for subsequent stages. This is essentially the process of creating the specification, which ultimately forms the foundations for spec-driven development.
A specification is definitely more than just a product requirements document (PRD). Even simply applying a more structured prompt and more explicit technical constraints can produce better code than a plain PRD.
Technically, a specification should explicitly define the external behavior of the target software — things like input/output mappings, preconditions/postconditions, invariants, constraints, interface types, integration contracts and sequential logic/state machines.
In the past, specifications were often written in highly formalized, machine-readable formats. Today, with the help of LLMs, we can describe them using natural language. Essentially, though, a specification still defines the behavior of the target software; it doesn’t just describe business requirements.