specification-driven development (SDD)

in English: spec-driven development

advancedspreading

A software development method where a detailed written description of what the program must do is created first, and the AI agent writes the code based on this.

In plain terms

Imagine you are having a house built. You could tell the mason, 'let there be a beautiful, spacious house,' and then argue about every wall as you go. Or you could first have a blueprint prepared, showing every room, door, and socket, and the construction would follow that. Specification-driven development is the second path, applied to software and coding agents.

A specification is a document written in understandable language: what the program should do, for whom, under what conditions, and how it is evident that it is finished. The agent does not guess from a one- or two-sentence request but works from this description, reducing misunderstandings and allowing verification afterward that you received what you asked for.

This method is the counterpoint to improvised, "figure it out as we go" AI programming. It starts slower because thinking and writing come first, but for larger, multi-week projects, it typically involves less rework. The focus shifts: the human's main task is precisely defining intent, while writing code increasingly falls to the agent.

How it works

You write the specification: describe what you want to achieve and why, who will use the program, and what the acceptance criteria are. The agent itself often helps with questions in this process.
The agent creates a technical plan from the description: what components the system will consist of, which technologies will be used, and under what constraints. You review and approve this.
The agent breaks the plan into smaller, individually verifiable tasks, similar to a to-do list.
The agent writes code for tasks sequentially and verifies with tests whether the output meets the specification.
If requirements change, you first modify the specification and only then the code. This way the description always reflects the current state and does not turn into an outdated document.

An everyday example

A small business wants a booking system. The developer does not just tell the agent to 'make a booking page' but first records in a two-page description who can book, how far in advance, how to cancel, and what notification is sent. The agent works from this, and the client can check based on the description whether everything is completed.

Who is affected

developerYour work increasingly consists of writing precise requirements and checking the agent's work, rather than typing code line by line. → Code

entrepreneur, executiveA specification is a document you can read yourself, so you get a clearer view of what is being built with your money and can hold the builders to account.

employeeEven if you are not a programmer, if you can precisely describe the rules of a workflow, you can meaningfully participate in designing software. → Work & HR

A common misconception

MythIf the specification is detailed enough, the agent writes flawless code, and the code no longer needs review.

In realityAn agent may misunderstand a good description or ignore certain points, so testing and human oversight remain necessary. The specification reduces the chance of errors but does not eliminate them.

Limits and risks

Poor or incomplete specifications lead to poor programs: the method is only as good as the thought put into the description.
For minor fixes and quick experiments, writing documentation may take more time than it saves.
The description and the code may drift apart over time if the team does not diligently maintain both.
Long plans and task lists generated by an agent are tedious to read through, making it easy to approve them without proper review.

Similar, but not the same

vibe coding – Vibe coding is improvised, conversational programming without a prior plan, whereas specification-driven development starts with a written description and measures results against it.
test-driven development – In test-driven development, automatic tests written before the code record the expectations. Here, a document written in human language records them, and the tests are also created from this. The two methods do not exclude each other; they are often used together.
prompt writing – A prompt is usually an instruction for a single conversation, whereas a specification is a permanent document that remains throughout the project's duration, with changes that can be tracked.

Related concepts

Broader

software development, AI-based software development, agent-based development

Narrower

–

On the edge

coding agent, vibe coding, test-driven development, context engineering, prompt writing, requirements specification, task decomposition, acceptance criteria

A brief history

The idea of specification-driven development is old in the software industry, but its current meaning tied to AI agents became known in 2025. In that year, Amazon's Kiro development tool and GitHub's open-source Spec Kit toolset were released, both built on this working method.

Where things stand

As of late 2026, several coding agents and developer tools offer a built-in, specification-based workflow, used mainly on larger, longer projects. There is no single standard or generally accepted best practice yet, and the profession is debating when it is worth the effort.

Status: 2026 November

Also known as

specification-driven development · spec-driven development · spec-driven development · spec-driven development · specification-driven development · SDD · spec-first development · spec-driven development

Sources

This entry was machine-edited and has undergone machine expert review; the “In the news” section updates automatically from Agent Age stories.