Spec-driven development puts a written spec in charge of what the coding agent builds. The tooling that popularised it, GitHub's Spec Kit and AWS Kiro, hands the spec to the agent and stops. What checks the result against that same spec is left to you.
The short version: in spec-driven development the spec is the source of truth for the build. It should be the source of truth for the test too, and in the current tooling it isn't. Spec Kit only generates test tasks "if explicitly requested"; Kiro generates property-based tests for bug fixes and its docs describe no test generation for features. The tests that do get written come from the agent's own reading of the spec, so they inherit its misreadings. Spec-driven verification means a check that reads the spec independently, runs the shipped product against it, and reports pass, fail or unable to verify.
What spec-driven development is
The term is less than two years old and already has three dialects. GitHub's Spec Kit launched in September 2025 with a four-phase loop: specify ("user journeys, experiences, and what success looks like"), plan (stack, architecture, constraints), tasks ("small, reviewable chunks") and implement. AWS Kiro keeps three files per feature: requirements.md with user stories and acceptance criteria in EARS notation, design.md, and tasks.md. Tessl's version, which Birgitta Böckeler on martinfowler.com calls spec-as-source, treats the spec as the artifact you maintain and the code as something regenerated from it.
Böckeler's definition is the plainest: writing a spec before writing code with AI, where "the spec becomes the source of truth for the human and the AI." The Thoughtworks Radar put the technique in Assess in November 2025 and described the workflows as "elaborate and opinionated."
The idea underneath it is older and simpler: the agent builds faster than you can read, so you move your effort upstream into saying what you want, precisely, once.
Where the tooling stops
Read the Spec Kit methodology document and you will find a constitution article titled Test-First Imperative. It says TDD is "NON-NEGOTIABLE" and that "acceptance scenarios become tests." Then open the actual tasks command template the agent runs. The instruction there is "Only generate test tasks if explicitly requested in the feature specification." The only test type it names is a contract test. Browser tests, end-to-end tests, anything that opens the product, do not appear.
Kiro is more candid. Its concepts page says EARS requirements "can be directly translated into test cases," which is true, and which leaves the doing to you. The one place the best-practices page says Kiro generates tests is bug-fix specs, where it writes property-based tests. For a new feature, validation is a question you ask the chat: "does my current implementation meet the acceptance criteria for task 7.1?"
GitHub's own launch post says where the check lives: "Crucially, your role isn't just to steer. It's to verify." Anthropic's Claude Code best practices say the same thing from the other side. The most useful specs "end with an end-to-end verification step that proves the feature works," and without a check the agent can run, "'looks done' is the only signal available, and you become the verification loop."
So the spec drives the build, and the test is opt-in, or a contract or property test, or you.
We have tried spec-as-test before
Dan North's Introducing BDD is from 2006. Given, When, Then. Developers "started to write test methods that were real sentences," and the word behaviour replaced the word test. Cucumber still says Gherkin's keywords "give structure and meaning to executable specifications." Twenty years of teams have tried to make the spec and the test one document, and most of them ended up with a Gherkin layer that nobody reads sitting on top of a step-definition layer that everybody maintains.
The reason it half-worked is that a human still had to turn each Then into code against a specific DOM. The spec was executable only in the sense that there was a translator in the middle, and the translator was a person with selectors.
That part has changed. An agent can read "the user can pay with a saved card and sees the receipt" and go and try to pay with a saved card. The spec stayed prose. What changed is that the executor can now read it.
Why the agent's own tests don't close the loop
The obvious fix is to have the coding agent derive tests from the spec as it builds. Spec Kit's constitution asks for exactly that. It is better than nothing and it has a specific failure: the agent that misread the spec writes tests for its misreading.
Vilhelm von Ehrenheim, our co-founder and Chief AI Officer, told this about our own pipeline in an AlphaSignal webinar in September. A constraint, one result type that must never be offloaded, was written into the RFC and into the spec the agent was implementing. "The agent shipped the violation anyway." Every scripted check stayed green, because the only thing that broke was an interactive path nothing in the suite exercised. When the agent was asked to look at its own failure afterwards, it wrote, in his words, "I had the answer written down twice and I shipped the bug anyway."
Böckeler reached the same place in her April 2026 piece on harness engineering: "This approach puts a lot of faith into the AI-generated tests, that's not good enough yet." The measured version of that, agents stubbing evaluators and writing tests against mocks, is in agent evals vs testing what the agent shipped.
There is a second failure on top of that. Specs drift. SpecStory defines spec drift as "a mismatch between a software specification and its code, caused by one of them changing without the other," and notes that "a spec with drift still reads as correct." A test derived once from a spec, then maintained as code, drifts with the code. The spec stays where it was.
And an engineering lead at one of our longer-standing customers put the human version of it on a call with Daniel Mauno Pettersson, our co-founder and CEO, translated from Swedish: "They think the requirements are the truth, not what we have in our product."
What spec-driven verification means
Take the same spec the agent built from. Hand it to a second agent that did not write the code. Have that agent open the product, attempt what the spec says a user can do, and report what it saw.
That differs from "generate tests from the spec" in a few ways that matter.
The test is a goal. Daniel's working definition of a test case is "a goal, an expected result, and it might have steps related to this." A scripted test, by contrast, is "very tightly coupled to a specific implementation of a feature, and it usually relies on a lot of mocked data and mocked interfaces, as well as very deterministic selectors." A goal written in the spec's language survives a redesign, which a selector won't.
The verdict is against intent. In Vilhelm's words, judge the outcome "against the intent, the RFC and the spec. Not against a script. It needs to be three word verdicts, not two. It can be pass, fail, with evidence attached and unverified." The third verdict matters. It means the test cases ran but never touched the change, and the review says so instead of posting a green that means nothing.
The verifier is independent of the builder. Regulated software has required this for decades; the DO-178C and NASA IV&V versions are in verification vs validation. An agent grading its own homework is not independent, whatever the spec said.
Take a spec line like "after checkout the user sees a receipt with the saved card's last four digits." A contract test checks the receipt endpoint returns 200. A spec-derived unit test checks the component renders a string. Neither opens the product and reads the four digits, which is the only thing the spec promised.
How we run it
The check we run won't tell you whether the interface feels right, only whether the spec's outcome was reachable. Within that limit, a change review on QA.tech weights the pull request's inputs in a fixed priority, PR description first, then linked tickets, then changed files, then commits (docs), and "acceptance criteria from the ticket stack with the PR description." It picks existing test cases that cover the user-facing change, writes goal-based test cases for what is missing, runs them against the preview environment and posts pass, fail or unable to verify on the PR through the GitHub PR integration (overview). The check can be required in branch protection (GitHub App docs).
The other limit is the path. Two runs of the same goal can take different routes to the same verdict, which Daniel calls out himself: "It's not going to be 100% deterministic, and that's the drawback of this."
Making your spec verifiable
Most of this costs nothing in the spec itself.
End the spec with the check. Anthropic's advice holds for any agent: the last section of a feature spec should say what a user does and sees when it works. Write it the way the receipt line above is written, as something a user sees.
Put the never-do constraints where a verifier will read them as well as the builder. Vilhelm's violation was written down twice, both times in documents addressed to the builder.
Keep out-of-scope explicit. A verifier that doesn't know a flow is out of scope will try it, fail, and cost you a false red.
In the Stack Overflow 2026 Developer Survey, nearly half of respondents said they trust AI when they can verify its work, and only 6.6% are prepared to trust it for important decisions. That verifying is the part the spec tooling leaves to you, and the spec you already wrote is the place to start it from.
FAQ
What is spec-driven development? A workflow for AI coding agents where a structured specification, written before any code, is the source of truth the agent builds from. GitHub Spec Kit, AWS Kiro and Tessl are the main tools; each adds a plan and task breakdown between the spec and the implementation.
Does Spec Kit generate tests? Only when the feature spec asks for them. The tasks template says "Only generate test tasks if explicitly requested in the feature specification," and the test type it names is a contract test. End-to-end or browser tests are not part of the workflow.
Does Kiro generate tests from acceptance criteria? For bug-fix specs, Kiro generates property-based tests. For feature specs, its docs say requirements "can be directly translated into test cases" but describe no automatic generation.
What is spec-driven verification? Checking the shipped product against the same spec the agent built from, using an independent verifier that reads the spec, exercises the running application, and reports pass, fail or unable to verify. The difference from "spec-derived unit tests" is that the test is a user-level goal and the verifier did not write the code.
Isn't this just BDD? Same intent, different executor. Gherkin made specs executable through hand-written step definitions bound to the DOM. A verifying agent reads the Given-When-Then in prose and operates the product itself, so the spec does not need a code layer underneath it.
What does spec drift do to tests? A test derived from a spec and then maintained as code drifts with the code; the spec stays unchanged and "still reads as correct." A check that re-reads the spec on every run drifts with the spec instead, which is the one you meant to keep.
