Spec-Driven Development: Why the Spec Is Becoming the Source Code

Spec-driven development (SDD) is an engineering workflow in which a structured, version-controlled specification — not the code — is the primary artefact a team writes and maintains, while AI coding agents generate the implementation, tests and documentation from it. The approach moved from idea to mainstream practice during 2025, propelled by Amazon's Kiro IDE (public preview, July 2025) and GitHub's open-source Spec Kit (September 2025). For engineering leaders the significance is simple: when agents can produce code faster than humans can review it, the specification becomes the thing you actually engineer.

The shift is a direct response to the dominant failure mode of AI-assisted coding. Conversational 'vibe coding' produces plausible software quickly, but the requirements live in an ephemeral chat history: intent is never written down, so it cannot be reviewed, versioned or re-run. Agents drift from what was meant, hallucinate APIs, and the codebase decays as it scales. The November 2025 edition of the Thoughtworks Technology Radar placed spec-driven development in its Assess ring precisely because these workflows 'begin with a structured functional specification, then proceed through multiple steps to break it down into smaller pieces, solutions and tasks' — restoring predictability and maintainability that chat-based prompting lacks.

What is spec-driven development?

In an SDD workflow, a feature starts life as a written specification: what the software must do, expressed as user stories and testable acceptance criteria. From that spec, a technical plan is derived, then a set of small, verifiable tasks, and only then does an agent write code. GitHub's framing is instructive: coding agents should be treated as literal-minded pair programmers, excellent at pattern recognition but dependent on unambiguous instructions. The spec is not throwaway documentation written after the fact — it is a living artefact that evolves with the project and serves as the shared source of truth for humans and agents alike.

GitHub's Spec Kit, open-sourced in September 2025, packages this into a concrete four-phase loop driven by its Specify CLI: specify (capture the what and why), plan (constrain the how — stack, architecture, compliance requirements), tasks (decompose into small, independently testable units) and implement. It also introduces a 'constitution' — a set of immutable project principles the agent must never violate — and works across GitHub Copilot, Claude Code, Gemini CLI and more than a dozen other agents, which matters for teams that do not want their requirements format welded to one vendor.

Amazon's Kiro, launched in public preview in July 2025, builds the same discipline into the IDE itself. According to Kiro's documentation, each feature is formalised in three artefacts — requirements.md (user stories with acceptance criteria), design.md (technical architecture) and tasks.md (executable implementation tasks) — with the agent analysing task dependencies so independent work can run in parallel 'waves'. Event-driven hooks then keep the generated assets honest: tests regenerate when a component changes, documentation updates when an API does.

Why is the spec becoming the source code?

The strongest articulation of the underlying argument came from OpenAI's Sean Grove at the AI Engineer World's Fair in June 2025. In his talk 'The New Code', Grove argued that the code a developer writes represents only 10–20% of the value they deliver; the rest is structured communication — understanding the problem, distilling requirements, verifying the solution. His sharpest observation was about waste: developers prompt a model, keep the generated code and discard the prompt, which is like 'you shred the source and then very carefully version control the binary'. The durable statement of intent — the spec — is the thing worth keeping.

The compiler analogy is doing real work here: we stopped hand-writing assembly when compilers became reliable enough that the high-level language could be trusted as the source of truth. Spec-driven development bets that agents are approaching the same threshold for natural-language specifications. Some tooling takes the logic to its conclusion — Thoughtworks notes that the Tessl Framework, in private beta as of late 2025, treats the specification itself as the maintained artefact and the code as regenerable output. Most teams are not there yet, and need not be: even with humans still reviewing every diff, moving the authoritative statement of behaviour from code comments and tickets into a versioned spec changes what the team optimises.

What problem does this actually solve?

The 2025 DORA State of AI-assisted Software Development report, published by Google Cloud's DORA research programme in September 2025, quantified the tension SDD addresses: roughly 90% of developers now use AI in their daily work, yet about 30% report little or no trust in the code it generates. Teams adopt AI for speed, then re-spend the savings auditing output they do not trust. DORA's central finding — that AI acts as an amplifier, 'magnifying an organisation's existing strengths and weaknesses' — is the case for SDD in one sentence: organisations with disciplined requirements and verification get compounding returns from agents; organisations without them get faster-arriving defects.

Review moves up a level: instead of inspecting a 4,000-line generated diff for hidden intent errors, a senior engineer reviews a two-page spec for correctness of intent, then verifies the implementation mechanically against its acceptance criteria. That is a far better use of scarce senior attention, and it is the review model that scales when agents produce most of the code.

Verification falls out of the artefact: because acceptance criteria are written before implementation, they convert directly into tests. Grove pointed to OpenAI's own Model Spec as the pattern — a versioned Markdown document where every clause has a unique ID and associated test prompts, making the specification itself executable as a test suite. A well-formed feature spec gives you the same property: the definition of done is machine-checkable, not a matter of reviewer judgement.

Where does spec-driven development struggle?

The honest caveats matter. Thoughtworks kept SDD in Assess, not Adopt, observing that current workflows 'remain elaborate and opinionated': specs balloon in length, it is not always clear who the spec is for, and handcrafting detailed rules for agents may not scale. Critics also hear an echo of waterfall — big design up front, dressed in new tooling. The rebuttal is that SDD loops in hours rather than quarters: the spec is amended and re-derived continuously, not signed off once. But the criticism lands for genuinely exploratory work, where writing acceptance criteria before understanding the problem is theatre. For prototypes and spikes, conversational coding remains the right tool; SDD earns its overhead where software must be maintained, audited and extended.

How should engineering teams adopt SDD in 2026?

Start with one bounded feature, not a process mandate. Write the spec, derive the plan and tasks with whichever agent stack you already use — Spec Kit is agent-agnostic and free — and measure review time and post-merge defects against your baseline. Keep specs short enough to review in one sitting; a spec nobody reads is worse than none. Put the spec in the repository and treat drift between spec and code as a build failure, not a documentation chore. And staff spec authorship with senior engineers: distilling ambiguous stakeholder intent into unambiguous, testable criteria is the highest-leverage engineering skill of this cycle, and the one agents cannot supply.

For regulated sectors the appeal is sharper still. In defence and healthcare delivery, the question is rarely 'can you build it faster' but 'can you show your working'. A spec-driven pipeline yields a native audit trail — requirement, acceptance criterion, design decision, task, code, test — that maps cleanly onto clinical-safety and security-assurance documentation, rather than being reconstructed at accreditation time. At Turing Labs this is how our senior engineers direct AI systems day to day: the specification is the contract between human intent and agent output, and it is why AI-accelerated delivery does not have to mean lower rigour. The teams that will win with AI agents in 2026 are not the ones prompting fastest — they are the ones specifying best.