tldr: Spec-driven development (SDD) has you write a detailed spec, then an AI agent turns that spec into code. It is the serious answer to vibe coding. The gap almost nobody talks about: the spec says what the code should do, and no step in the workflow checks that it did.
A year ago the fashionable way to build software with AI was to type a rough prompt and accept whatever came back. Vibe coding. It produced working demos and unmaintainable codebases in roughly equal measure.
Spec-driven development is the correction. Instead of a loose prompt, you write a structured spec: the requirements, the acceptance criteria, the constraints. An AI agent reads the spec and generates the implementation. Tools like AWS Kiro, GitHub Spec Kit, and Tessl have turned this into a real workflow with real adoption.
It is a real improvement. A spec forces you to think before you generate, and it gives the agent something precise to build against. The output is more consistent and easier to reason about than vibe-coded sprawl.
But read the guides and you notice where they all stop. They cover writing the spec and generating the code. They go quiet on the question that decides whether any of it worked: how do you know the generated code actually matches the spec? That question is the entire subject of this post.
What is spec-driven development?
Spec-driven development is a workflow where a written specification, not a prompt and not the code itself, is the source of truth. You author the spec. An AI agent generates the implementation from it. When requirements change, you change the spec and regenerate, rather than editing the code directly.
The spec typically has three parts: what the feature should do, the acceptance criteria that define "done," and the technical constraints the implementation must respect. A good spec reads like a precise requirements document, because that is what it is.
The pitch is control. Vibe coding gives you speed and no structure. Spec-driven development keeps most of the speed and adds a document you can review, version, and reason about. The spec becomes the artifact the team argues over, instead of the code.
Lesser-known open-source spec-driven development tools
Kiro and Tessl get the headlines, and both are commercial. GitHub Spec Kit is the open-source name everyone repeats. But the open-source side of spec-driven development is wider than that short list, and some of the more interesting tools are the ones the roundups skip. If you want a spec-driven workflow you can read, fork, and self-host, start here.
- OpenSpec. The lean one. Instead of writing a whole spec up front, you write delta specs that describe only what is changing, and completed changes archive into a growing source-of-truth document. Its strict three-phase flow, propose then apply then archive, makes it a strong fit for brownfield work on an existing codebase.
- BMAD-METHOD. The heavyweight. MIT-licensed, it orchestrates a team of specialized AI agents, analyst, architect, product owner, and more, across the full lifecycle rather than a single spec-to-code step. It suits complex greenfield projects where you want structure around every phase.
- Spec Kitty. A repo-native CLI that runs the whole loop, spec to plan to tasks to review to accept to merge, with a Kanban dashboard and git worktrees built in. It drives Claude Code, Cursor, Gemini, Codex, and Copilot, so you are not locked to one agent.
- Specs CLI. An agentic command-line tool built around traceability. It turns an idea into a spec, a plan, and tasks while keeping a link from each piece of code back to the requirement it came from. That traceability is the part most tools drop.
Notice what none of these fully solve. Every one of them is good at getting from a spec to code. Not one of them closes the loop the other way, from running software back to the acceptance criteria you wrote. That missing half is the same across the whole category, open source or commercial, and it is the subject of the rest of this post.
Why spec-driven development replaced vibe coding
Vibe coding broke down as projects grew, for one reason: there was no durable record of intent. The prompt was thrown away. The code was the only artifact, and code tells you what it does, not what it was supposed to do. Six weeks later nobody could say whether a behavior was a feature or an accident.
A spec fixes that. It persists. It is reviewable before a line is generated. Two engineers can disagree about the spec and settle it in the spec, which is far cheaper than settling it in a pull request after the code exists.
This is a real advance, and we have written before about why AI-generated code needs a different testing posture than hand-written code (how to test AI-generated code before it ships). Spec-driven development is the most disciplined version of AI coding yet. Which is exactly why its one remaining blind spot stands out so sharply.
The blind spot: a spec is an assertion nobody verifies
Look closely at the structure of the workflow. The spec is a set of claims about how the software should behave. The agent generates code it believes satisfies those claims. And then, in most teams, the code ships.
Look at what did not happen. Nobody checked that the running software actually meets the acceptance criteria the spec laid out. The spec asserted "a user can reset their password and receive an email within one minute." The agent wrote code that looks like it does that. Whether it does that, in a real browser, against a real mail flow, is untested.
This is not a hypothetical failure mode. It is the same gap that AI code review leaves open, which we have covered separately (AI code review isn't enough). A model reading a diff can tell you the code looks correct. It cannot tell you the checkout flow works, because that only exists when the software runs.
Spec-driven development makes the gap sharper, not smaller. The more precise your spec, the more explicit your acceptance criteria, the more glaring it is that nothing is confirming those criteria against the real, running product. You wrote down exactly what "working" means and then never measured against it.
How to test spec-driven development output
The fix follows directly from the shape of the problem. The spec already contains acceptance criteria. Those criteria are test cases. They just need to be executed against the running software instead of assumed.
Every acceptance criterion in a spec is a behavioral assertion: given this state, when the user does this, then that should happen. That is the exact form of an end-to-end test. The spec that drives code generation can also drive test generation. Same source, two outputs: the implementation and the suite that proves the implementation meets the spec.
The tests have to be behavioral, not structural. Unit tests that the agent also generated prove the code does what the agent thinks it does, which is circular. What closes the loop is a test that drives the actual UI, completes the actual flow, and asserts the actual acceptance criterion. If the spec says a password reset email arrives within a minute, the test resets a password in a browser and checks the inbox.
Run those tests on every regeneration. The moment you change a spec and regenerate code is the moment behavior can drift. A behavioral suite tied to the acceptance criteria catches the drift in the pull request, not in production.
Where testing fits in an SDD workflow
The clean version of the workflow has four steps, not three. Write the spec. Generate the code. Generate behavioral coverage from the same acceptance criteria. Verify the running software against it before merge.
The fourth step is what turns a spec from a hopeful document into a checked one. This is agentic testing applied to spec-driven development: AI that reads intent and confirms it against a live application, rather than a model that reads a diff and guesses (what agentic testing actually means).
It is also where Bug0 fits. A forward-deployed engineer takes the acceptance criteria from your spec and authors end-to-end coverage on Passmark, our AI testing engine. The engine runs that coverage on every change and self-heals it when the UI shifts, and the engineer verifies each result. Your spec stops being a promise about the code and becomes a claim the product is measured against on every deploy.
Spec-driven development got one thing exactly right. It made intent explicit. The next step is obvious once you see it: measure the software against the intent you were careful enough to write down.
FAQs
What is spec-driven development?
It is an AI coding workflow where a written specification is the source of truth. You author a spec with requirements and acceptance criteria, an AI agent generates the code from it, and you regenerate from the updated spec when requirements change rather than editing code directly. Tools include AWS Kiro, GitHub Spec Kit, and Tessl.
How is spec-driven development different from vibe coding?
Vibe coding uses a loose prompt and keeps only the code, so intent is lost. Spec-driven development uses a structured, persistent spec that can be reviewed and versioned before any code is generated. It trades a little speed for a lot of control and traceability.
Does spec-driven development remove the need for QA?
No. A spec describes what the code should do, but nothing in the generation step confirms the running software actually does it. The acceptance criteria in the spec still have to be verified against the live application, which is a testing job, not a generation job.
Who verifies that AI-generated code matches the spec?
Nobody, by default, which is the blind spot. Closing it means turning the spec's acceptance criteria into behavioral end-to-end tests and running them against the running product on every regeneration. A managed service like Bug0 does this by authoring and maintaining that coverage for you.
What tools support spec-driven development?
The commonly cited ones are AWS Kiro and Tessl, which are commercial, and GitHub Spec Kit, which is open source. Beyond them, the open-source options worth knowing include OpenSpec, BMAD-METHOD, Spec Kitty, and Specs CLI. They differ in how they structure the spec and drive the agent, but they share the same core idea: a specification, not a prompt, drives code generation.
Can the same spec be used to generate tests?
Yes, and it should be. The acceptance criteria in a spec are already behavioral assertions in the form "given, when, then." That is the shape of an end-to-end test. Generating coverage from the same criteria that drove the code is what verifies the two actually agree.
