The fastest way to watch an AI coding agent fail is to type "add login" and hit enter. The model does something. It picks a session strategy, a password policy, a redirect flow, all reasonable, none of them the thing your team actually decided. The output looks right, compiles clean, and quietly diverges from intent. Do that a hundred times across a codebase and you get the 2025 problem everyone hit at once: plausible code that drifts, hallucinates APIs, and decays as the project grows.
Spec-driven development is the correction. The idea is simple and, once you see it, hard to unsee. The written specification becomes the primary, executable artifact of the project, and code becomes a regenerable output produced from that spec. The spec is no longer a document you write once and abandon. It is the source of truth, versioned like code, that agents build against and check themselves against on every cycle.
From passive doc to build gate
The shift that matters is what the spec does. In the old world a spec was documentation: written before the work, ignored during it, stale by the end. In SDD the spec is a gate. It encodes the behavior, the constraints, and the acceptance checks, and nothing counts as done until the output satisfies it. Researchers describe this as moving specifications "from code to contract", and the word contract is the point. A contract is enforced, not filed away.
That enforcement is what tames the agent. A generator pointed at a vague prompt invents intent. A generator pointed at a precise spec has far less room to wander, which is why controlled studies have found human-refined specs cutting error rates by up to half, and why early adopters at GitHub and AWS report first-pass success rates on non-trivial tasks jumping several fold.
The tooling caught up fast
SDD went from idea to ecosystem in about a year. By 2026 nearly every major coding tool ships its own flavor. GitHub Spec Kit is the most adopted open-source option, a CLI past 90,000 stars that sets up the spec structure and drives it through slash commands across 30-plus agents. AWS Kiro puts specs at the center of the IDE and documents customer cases where features that would have taken 40 hours shipped in under 8 hours of human time when authored spec-first. Claude Code, Cursor, OpenSpec, BMAD, and Tessl each have their own take. The convergence is the signal: this is not one vendor's bet, it is where the field landed.
Why specs make agents scale
There is a second, quieter reason specs matter, and it shows up when you run more than one agent. A good spec breaks a problem into modular pieces that fit an agent's context window, which means you can partition work at the spec level and let several agents build non-overlapping components at once without stepping on each other. The spec is not just a better prompt. It is the coordination layer that makes parallel agentic work possible at all.
Some teams push this further with self-spec workflows, where the agent drafts a specification from a high-level prompt, a human reviews and corrects it, and only then does generation begin. The human stays in the loop where judgment matters, at the spec, and steps out of the part machines do well, the typing.
Specs and bolts are the same move
Spec-driven development and the bolt are two halves of one idea. The spec is the contract; the bolt is the cycle that builds against it. You write a tight spec, an agent generates, and a verification gate confirms the result, all inside a loop measured in hours. That is the whole agentic development model in one sentence.
For how to write specs an agent can actually build, see the practical guide. For how the spec and the bolt connect end to end, see the spec-to-bolt loop, and for the method around both, the AIDLC page.
Vibe coding asked the model to guess your intent. Spec-driven development writes it down first.