Spec-Driven Development: Who Executes a Spec? (Part 4 of 4)

This is the fourth and final part of my attempt at a definition of spec-driven development (SDD), following part 1, part 2, and part 3.

As before, the requirement-level key words follow RFC 2119 and RFC 8174.

What is spec-driven development?

After having dissected the term into its constituents, it is time to put it all back together and take a final look at the big picture. We now know the shape of a spec in terms of format, language, content, and lifecycle. We understand that different specs employ different levels of abstraction and sit behind the wheel no matter what.

Anything missing?

Well, there is one aspect that we can really only discuss now, when looking at the term as a whole, knowing that it stands for a development method.

A method for whom, actually?

Levels of human involvement

So far, we have talked about the artifacts and the procedures, but not the actors. While every description of SDD I have read mentions AI, coding, and agents, the precise interaction patterns with human developers are often only briefly touched upon or merely implied.

The entire chain from intent to execution described in part 3 could be processed fully autonomously by an AI agent, semi-autonomously with a human in the loop at every step, fully manually, or anything in between.

Does a team of human developers using AI assistants to manually translate a spec to source code perform spec-driven development?

I suspect we all imagine something a little different when we think of SDD. So let's make it explicit:

The translation of the spec (together with the design) to source code MUST be performed fully autonomously by AI coding agents (or a comparable future technology).

This is what I consider the soul of SDD.

Note that this definition does not mandate that the resulting source code remain untouched. Manual modifications (after human review, for example) are in scope as long as the spec remains in the driver's seat. It follows that code adjustments have to be structural rather than behavioral, with bug fixes to make the code spec-compliant as the obvious exception.

Manual code changes MUST NOT introduce behavior the spec does not prescribe.

Nor does this definition require that the entire source code be rewritten every time the (possibly modified) spec is translated. AI coding agents can be instructed to take existing source code into account and adapt their output accordingly. This makes manual modifications durable and therefore practical.

For all other steps in the chain, human involvement is allowed and in scope to various degrees. I suggest defining the overall level of human involvement as a second degree of freedom within the definition of SDD where various forms of SDD are positioned on an axis ranging from "fully manual" (wherever allowed) to "fully autonomous" (at every step).

What about validation?

So far, none of this requires validation. Whether the deliverable still conforms to its spec is a question of quality, not of classification; a team that never checks is still doing SDD, just not doing it well. But validation is why "testable" matters in the definition. A spec that cannot be checked cannot stay in the driver's seat for long.

The conformance of the deliverable to its spec SHOULD be validated.

The definition

Time to collect what we have established over the four parts, step by step, and put it in one place. Here is my attempt at a definition of SDD, in full:

Spec-driven development (SDD) is an umbrella term for system development methods with the following properties:

1. A spec prescribes the testable behavior of a deliverable: the "what", not the "how", not the "why". It is text, written primarily in nonfiction prose. It MAY adhere to a spec style, which SHOULD mandate a specific spec language.
2. The spec MUST exist continuously and prescribe its entire deliverable until that deliverable reaches its end of life. It MUST NOT be abandoned or turned into documentation.
3. The spec MUST be in the driver's seat: a spec change MUST cause a code change, not the other way around. Manual code changes MUST NOT introduce behavior the spec does not prescribe.
4. The translation of the spec (together with the design) to source code MUST be performed fully autonomously by AI coding agents (or a comparable future technology).
5. The conformance of the deliverable to its spec SHOULD be validated.

Forms of SDD are characterized by two degrees of freedom: their abstraction level, ranging from "software" (concrete) to "system" (abstract), and their overall level of human involvement, ranging from "fully manual" (wherever allowed) to "fully autonomous" (at every step).

And this is where something had to give: requirements documents standing in for specs, specs that cover only a change, are left to decay, or are demoted to documentation, and teams translating specs to code by hand are not SDD by this definition.

It will be interesting to see whether and how tools and techniques will populate this two-dimensional space as we move forward.

I think the single biggest risk for the long-term success of SDD is our industry's complicated relationship with details. We have developed a bit of a habit of either glossing over them or simply ignoring them whenever it is convenient for us. But while specs do operate on a higher level of abstraction, they really are all about the details. This is engineering, after all. My sense is that we still underestimate the level of detail we must consistently provide across the board to make SDD work.

In the end, specs always lead to the most inconvenient question of them all:

What do you want?