For two years the default way to get code out of a model was to talk to it. Describe the change, read the diff, correct it, repeat. "Vibe coding" named the mood: you steer by feel, the prompt is disposable, and the only durable record of what you wanted is the code that came out the other end. It works, right up until you need to change something big, or a second agent inherits the repo, or you reread your own work in three weeks and can't reconstruct why it does what it does.
Spec-driven development is the structured counter-move. Write the specification first — goals, constraints, a plan, a task list — review that, and let the agent implement against it. The spec lives in the repo, in git, diffable like any other file. As of mid-2026 three tools have planted flags on this idea at three different altitudes, and the differences between them are really differences about how much of your workflow you're willing to hand over.
The three bets
GitHub Spec Kit is the thinnest and the most popular — an open-source (MIT) CLI that bolts an SDD workflow onto whatever agent you already use. You run a sequence of commands — constitution, specify, plan, tasks, implement — and it scaffolds a folder of markdown: a project constitution.md of non-negotiables, then per-feature spec.md, plan.md, and tasks.md, down to data models and contracts. Crucially it is agent-agnostic: the README claims support for 30-plus coding agents, from Copilot and Claude Code to Cursor, Gemini CLI, and Codex. It rode that portability to one of the fastest star curves GitHub has seen. The catch is right there in the design: Spec Kit is a methodology scaffolder, not an agent. The code is only as good as whatever model you point at the spec, and the multi-file ceremony is absurd overhead for a typo fix.
Kiro, from AWS, makes the opposite trade. It bakes SDD into a full agentic IDE: a "spec session" produces a stack of requirements.md (user stories with acceptance criteria in formal EARS notation), design.md, and tasks.md before a line of code is written, and the editor's own agent — with a menu of frontier and open-weight models — does the implementing. It went generally available in 2026 as Amazon's successor to the retiring Q Developer. Turnkey, rigorous, and locked in: you adopt a new IDE, a credit-based bill, and Kiro's idea of what a requirement looks like.
Tessl, founded by Snyk's Guy Podjarny and funded like it intends to win, makes the purest and most ideological bet. In Tessl's telling the spec isn't a planning step you discard — it is the program. Specs live in the codebase as long-term memory, paired with tests as guardrails, and a companion Spec Registry distributes version-accurate "usage specs" for thousands of libraries so agents stop hallucinating APIs. The Framework is still in closed beta, which makes it the highest-conviction and least-proven of the three.
The thing the pitch keeps burying
Read the marketing and you'll be told SDD gives you better code. That's the weakest version of the claim, and it isn't really true — code quality is bounded by the agent, and a spec doesn't make a mediocre model good. The real product is something the demos rush past.
Once intent lives in git instead of a chat transcript, a pivot stops being a rewrite and becomes a regeneration. The spec is the asset. The code is an expression of it.
Spec Kit's own manifesto says it without flinching: "Specifications don't serve code — code serves specifications." That is the load-bearing idea, and it has nothing to do with elegance. It's about durability of intent. A coding agent's context window is amnesiac by construction; the chat where you negotiated the design scrolls offscreen and is gone. Move that negotiation into a versioned file and three things change at once: a second agent can inherit the why and not just the what, a human reviewer can approve the plan before tokens get spent implementing the wrong thing, and a major change becomes "edit the spec, regenerate" instead of "manually unpick the code." This is also the precise gap that plain plan mode leaves open. Claude Code and Cursor's plan modes will happily draft a plan before executing — but that plan is ephemeral. It isn't an artifact; it's a transient that dies with the session. SDD's whole move is to persist it.
When the ceremony is a tax
Here's the part the converts won't tell you: a spec you don't maintain rots faster than the code it describes. The moment the implementation drifts and nobody updates the spec, you've manufactured a confident, official-looking lie — documentation debt wearing the costume of engineering discipline. One skeptical read, The Limits of Spec-Driven Development, makes the case that for small, fast changes the overhead simply costs more than it saves.
So the honest decision axis isn't "always spec." It's task size times longevity. Spec the work you'd be genuinely annoyed to have the agent guess wrong on, or the work that has to survive across sessions, agents, and people — the same instinct that makes you keep an AGENTS.md rather than re-explaining the project every time. Skip it when a follow-up prompt would be faster than opening a file. Spec Kit is the right starting point if you want that discipline without leaving your current agent; Kiro if you want it handed to you whole; Tessl if you believe the spec should outlive the code entirely. The mistake is treating any of them as a moral position instead of a tool with a cost.
