Software engineering has a habit of rediscovering good ideas, giving them new names and presenting them as revolutions. Spec-Driven Development (SDD), one of the more interesting developments emerging from AI-assisted software engineering, has some of those characteristics. But this time there may be a genuinely important difference.
Around twenty years ago, Dan North (in conjunction with Liz Keogh and Chris Matts) were developing the ideas that became Behaviour-Driven Development (BDD). His work challenged the distinction between requirements and testing, arguing that software development should begin with a shared understanding of the behaviour we expect from a system. Rather than treating tests as something engineers write after implementing functionality, BDD encouraged teams to describe expected behaviour in language that business people and developers could both understand.
Around the same period, I was working with Richard Watt on Acceptance Test-Driven Development (ATDD). We were exploring a closely related principle: define what successful software looks like through acceptance tests before writing the code. Those tests become a contract between the business and engineering, providing an objective means of establishing whether the requirement has been satisfied.
The underlying ambition was to reduce the ambiguity and misunderstanding that so often occur between someone describing a business problem and someone writing the software to solve it.
These approaches worked, but they required considerable discipline. Writing meaningful acceptance criteria took effort, automating tests required engineering expertise, and maintaining the relationship between requirements, tests and implementation was often difficult. Under delivery pressure, the process could easily deteriorate into writing user stories followed by conventional development and testing.
AI may fundamentally change the economics of this approach.
What is different about SDD?
Spec-Driven Development takes the idea of defining intended behaviour and extends it across the software development lifecycle, using AI agents to undertake much of the implementation.
Microsoft’s engineering ecosystem, including GitHub’s Spec Kit, provides a practical illustration. The process begins with a specification describing what the software should do and why. AI agents help clarify the requirements, develop an implementation plan, break it into tasks and generate the software. They can also create tests, review code and check the implementation against the specification.
The resulting lifecycle looks something like this:
Customer need > Specification > Acceptance criteria > Technical plan > Agent implementation > Automated verification > Deployment > Customer feedback.
The important change is not simply that AI writes code. It is that a specification can become the central artefact around which development is organised, with much of the translation into software performed automatically.
In conventional development, requirements are interpreted by engineers who make hundreds of small implementation decisions. In SDD, many of those decisions can be delegated to agents operating within established architectural, security and quality constraints.
Engineers remain responsible for the design, integrity and operation of the resulting system, but their work increasingly involves directing, reviewing and improving the output of agents rather than writing every line themselves.
The return of executable requirements
This is where the connection to BDD and ATDD becomes particularly interesting.
A specification written in natural language is useful, but it is not necessarily precise. An AI agent can misunderstand a requirement just as easily as a human developer, and may produce an impressively complete implementation of entirely the wrong thing.
Acceptance tests provide an important safeguard.
Consider a requirement stating that customers should receive a discount when their annual subscription exceeds a certain value. That sounds straightforward until someone asks whether the discount applies to the entire subscription, only the amount above the threshold, or whether existing customers retain their previous pricing.
BDD and ATDD encouraged us to resolve precisely these questions through concrete examples of expected behaviour. SDD can use the same approach, with AI helping generate scenarios, identify inconsistencies and turn agreed acceptance criteria into executable tests.
There is an important qualification. If the same agent generates the specification, implementation and tests, all three may share the same misunderstanding. Human validation of business intent remains essential, as does independent verification where the risks justify it.
Do we still need Scrum?
SDD also raises some uncomfortable questions about how we organise software development.
Scrum emerged in a world where software engineering was relatively expensive and coordination between specialists was necessary. Product owners maintained backlogs, developers implemented stories, testers verified functionality and Scrum Masters helped teams manage the process.
If AI agents substantially reduce implementation and testing effort, the balance of work changes.
I suspect we will see smaller, more multidisciplinary teams in which domain experts, product leaders and engineers collaborate directly on specifications, with agents undertaking much of the subsequent development.
This doesn’t eliminate the need for product management, engineering expertise or delivery coordination. It does, however, challenge the assumption that the organisational structures developed around human coding capacity remain optimal.
The interesting question becomes how many people are needed to take a customer problem from initial understanding through to a reliable production solution, rather than how many developers are required to implement a backlog of stories.
Iteration still matters
One danger is that organisations interpret SDD as a return to exhaustive upfront requirements.
That would be a mistake.
We learned through Agile that requirements evolve as people see and use working software. SDD should accelerate that learning rather than attempt to eliminate it.
A team might develop an initial specification, ask an agent to implement a small part of it, review the working result and refine its understanding. The cycle could repeat several times in a day.
Specifications should be sufficiently detailed to establish intent and verify behaviour, but no more elaborate than the problem requires.
Indeed, one of the most promising aspects of agentic development is the possibility of reducing the cost of experimentation. When producing working software becomes cheaper, teams can explore alternatives and learn from them much earlier.
The business value is not in writing code faster
There is a temptation to measure the success of SDD through developer productivity, lines of code generated or reductions in engineering headcount. Those measures miss much of the opportunity.
The more important question is whether an organisation can respond to customer needs more quickly and economically.
If SDD reduces the time between identifying a valuable product opportunity and getting working functionality into customers’ hands, that could accelerate adoption, improve retention or bring forward revenue. Equally, if the organisation produces more unwanted functionality, faster development achieves very little.
We should therefore measure the entire journey from customer need to commercial outcome, not simply the speed of code generation.
Perhaps we were right all along
Looking back at the work Dan North was doing with BDD and the work Richard Watt and I were doing with ATDD, I am struck by how little the fundamental problem has changed.
We wanted business people and engineers to agree what software should do before spending time building it. We wanted requirements to be testable, misunderstandings to be discovered early and working software to be demonstrably correct.
Those remain sensible ambitions.
What has changed is the technology available to realise them. AI agents can now help translate specifications into implementations, generate tests and repeatedly refine software at a speed that would have seemed extraordinary twenty years ago.
SDD is not simply BDD or ATDD with an AI agent attached. It extends specification-led thinking into architecture, implementation and delivery, and raises new questions about governance, quality and accountability.
But I find it rather satisfying that some of the most promising ideas in modern AI-assisted software engineering have their roots in work we were doing two decades ago.
Perhaps the real breakthrough isn’t that machines can finally write software. It’s that we might now be able to spend more of our time deciding what software is actually worth writing.
