WHAT IS SDD?

Spec Driven Development has roots in formal specification, design-by-contract, and the broader shift toward treating specifications as executable artefacts. StrongDM, Anthropic, and others are already building production software from specs using AI agents.

This presentation introduces a practical method for putting SDD into practice.

The unique contribution is provenance — the mechanism that makes specification-driven workflows auditable, traceable, and verifiable. How agents communicate through documentation. How reasoning is captured as a byproduct of building. How that creates compliance-ready evidence without additional effort.

NOT ALL AI CODING IS EQUAL.

Dan Shapiro's Five Levels of Vibe Coding maps where teams actually operate — vs where they think they are.

← 90% of developers are here

SDD GETS YOU
TO LEVEL 3–4.

Level 5 — the fully autonomous dark factory — that's a whole different problem set. Different tooling, different organisational structure, different economics.

But the method described in this deck can move you from L0–2 to L3–4 today. Write specs. Delegate to agents. Verify through provenance. That's the transition from writing code to directing agents.

IT'S ALL
ABOUT
THE SPEC.

With agentic AI, the spec you hand the agent is the implementation instruction. The agent reads your spec and builds the software. If the spec is structured well enough, it also defines the verification scenarios — not as a side effect, but inherently.

The spec is the single source of truth for what the software does, how it gets built, and how it gets verified.

THE INFINITY LOOP

The spec sits at the top. Scenarios sit at the bottom. Provenance is the crossing point where the two agents communicate. Code is the canonical context — the reality everything else orbits.

THE SPEC SPECIFIES
EVERYTHING.

The spec defines both the product and the process that produces the product. Not just what to build — but who does the work, what each worker is responsible for, and how they communicate.

BUILD AND
SHOW YOUR
WORKING.

The builder doesn't just write code. It produces evidence of how it interpreted the spec — every assumption, every ambiguity, every decision. It's not marking its own homework. It's handing in its homework with its working shown.

CHALLENGE
EVERY
ASSUMPTION.

A separate agent because the builder has blind spots. If the builder misunderstood the spec, it will write code that reflects the misunderstanding and tests that confirm it. Everything passes. Everything's wrong. The testing agent reads the spec and provenance — never the code — and finds the daylight between them.

THE REASONING
RECORD.
NOT A MAP.

Code is self-describing — any agent can read a codebase and understand its structure, patterns, and dependencies. What the code can't tell you is why. Why is the timeout 30 minutes? Why this library and not that one? Why does this module exist at all? That's the provenance. The reasoning layer that answers the questions code can't answer about itself.

THE CROSS-
EXAMINATION.

The testing agent never sees the code. It has two inputs: the spec (what was intended) and the provenance (what the builder says it did). Its job is to find the daylight between those two documents.

A separate agent because the builder has blind spots. If the builder misunderstood the spec, it will write code that reflects the misunderstanding and tests that confirm it. Everything passes. Everything's wrong.

PROSE FIRST.
CODE SECOND.

The testing agent writes a markdown scenario — plain language explaining what's being tested and why — before it writes a single line of test code. The code is derived from the prose, not the other way around.

A product owner can read the scenario. A regulator can read it. A client who knows nothing about code can say "yes, that's the right question to ask" or "actually, don't test for that — update the spec."

FAILING TESTS ARE
WORK ORDERS,
NOT BUG REPORTS.

A failing test with provenance is a diagnosis. The builder doesn't get "line 47 assertion failed." It gets the prose scenario, the gap between spec and provenance, and a recommendation for what to fix.

No human touched the code. No human wrote a test. No human triaged a bug. A human wrote a spec. Everything else is derived.

FIVE ARTEFACTS.
FIVE PURPOSES.
COMPLETE LINEAGE.

The spec describes what the code should be. The code describes itself. The provenance explains why the code is the way it is. The scenarios challenge the code based on the gap between spec and provenance. The tests execute against the code.

Code is the reality every other artefact exists in relation to. Provenance is the reasoning that makes the code navigable.

MARKDOWN AND
A PROCESS.

THAT'S IT.

No SDK. No framework. No vendor lock-in. No orchestration engine. Anyone with access to an AI agent and a markdown editor can implement SDD today. The entire methodology fits in three templates.

WHAT SDD
GIVES YOU.

WHAT SDD DOES
NOT GIVE YOU.

These technologies solve real problems. But they solve advanced problems. SDD sharpens the thinking that makes every other tool more effective.

Start with the spec. Graduate to complexity when the problem demands it.

SDD in action. One spec. Two agents. Provenance, scenarios, and tests — generated live.

One spec. Two agents. Five artefacts. Complete traceability from intent to verification.
No framework required. Start today.

Provenance, audit, and regulation — why SDD is a compliance
asset for SOC 2, ISO 27001, and the EU AI Act.

SOC 2 ISO 27001 EU AI ACT AUGUST 2026

YOUR AUDITOR'S AI
IS GOING TO ASK
HOW THIS WAS BUILT.

When a human builds software, the reasoning exists in their head, in Slack threads, in PR comments. You can reconstruct it — badly — after the fact. When an agent builds software, the reasoning exists in the context window. The session ends. The reasoning evaporates. Unless you capture it.

You cannot retrospectively create provenance for decisions that were never documented. SDD means you never have to.

COMPLIANCE
AS A BYPRODUCT.
NOT A PROJECT.

Most organisations will try to bolt compliance documentation onto AI-built systems after the fact. They will hire consultants to retrospectively construct the design history that auditors and regulators demand. SDD produces that documentation as an inherent part of the build. You don't retrofit it. It already exists.