Two of the biggest names in developer tooling spent the last year making the same bet. In September 2025, GitHub open-sourced Spec Kit, an MIT-licensed CLI that turns a written specification into the thing your AI coding agent builds against. On May 7, 2026, AWS launched Kiro internationally as a ground-up replacement for Amazon Q Developer, an IDE built entirely around writing the spec before the code. Both are selling the same idea under the same three letters: SDD, spec-driven development.
The pitch is that this is the successor to prompt engineering, the discipline that finally makes agentic coding reliable. Part of that is true. Part of it is a 40-year-old idea wearing a hoodie and running up a token bill. If you build software with AI agents, the useful question is not whether to adopt SDD. It is at what altitude, and when the overhead actually pays for itself.
What spec-driven development actually is
Strip away the branding and SDD is one move: you write a structured, versioned specification first, and the agent generates, tests, and validates code against it instead of against a chat prompt. The spec, not the code, is the source of truth.
Spec Kit makes this concrete with a sequence of slash commands that work across 30-plus coding agents, including GitHub Copilot, Claude, and the Codex CLI. The workflow runs through named phases:
- Constitution (
/speckit.constitution): aconstitution.mdfile of non-negotiable project principles, the tech and quality rules the agent must never violate. - Specify (
/speckit.specify): the “what” and “why,” written as requirements, user stories, and acceptance criteria, with no implementation detail. - Clarify (
/speckit.clarify): resolve the underspecified corners before any planning happens. - Plan (
/speckit.plan): the “how,” where you commit to a tech stack and architecture. - Tasks (
/speckit.tasks): the plan broken into small, testable units. - Implement (
/speckit.implement): the agent executes the tasks.
There is also /speckit.analyze for cross-artifact consistency checks and /speckit.converge to grade an existing codebase against its spec and append the work still missing. The whole design is built on what GitHub calls “multi-step refinement rather than one-shot code generation.”
Kiro lands the same methodology inside the editor with slightly different plumbing. Its specs live in three markdown files, requirements.md, design.md, and tasks.md. The requirements use EARS syntax, the Easy Approach to Requirements Syntax developed at Rolls-Royce, where every requirement takes the form WHEN [condition] THE SYSTEM SHALL [behavior]. Kiro also reads “steering” files in .kiro/steering/ before every action, project-level context that pins your naming conventions, folder structure, and stack so the agent stops reinventing them each session.
If you have ever written a requirements document, none of this is new. That is the point, and also the catch.
The failure it fixes is real
The reason SDD went mainstream in 2026 is not fashion. It is that agents are excellent at writing code and terrible at guessing intent. Microsoft’s engineering team frames the core problem as translation loss: as work moves from stakeholder need to requirement to architecture to implementation, meaning degrades at every handoff. “Without a shared artifact that preserves intent, every handoff becomes an interpretation step.” Point an agent at a vague prompt and you have not removed the interpretation step, you have automated it and made it faster.
Anyone who has watched an agent run knows the tax this produces. A prompt like “add login” is wildly underspecified, so the model picks reasonable defaults that rarely match what the team wanted. The result is architectural drift, where requirements live only in scattered chat history with no durable source of truth, and inconsistent implementations, where two people get two different systems from the same intent. There is a harder, quieter cost too: when agents implement a spec, they typically complete only 80 to 90 percent of what they were told, and you cannot see what is missing until you QA the software. A real specification gives you something to QA against. A prompt gives you a memory of what you think you asked for.
This maps directly onto the same reliability wall that shows up in long-running agent context and in multi-agent orchestration, where most failures are coordination and specification failures, not model failures. A durable spec is the artifact that survives a compaction, an agent handoff, or a new engineer three months later. That is genuine information gain over vibe coding, and it is why the discipline stuck.
Where the token bill hides
Here is the part the demos skip. SDD is not free, and the cost is not small.
The tooling itself is heavy. In head-to-head tests, Spec-Kit burned up to twice the tokens of leaner alternatives like OpenSpec, and much of that spend went into the agent reasoning about its own rules rather than executing the task. There is a lossy-compression problem baked into the format: a workflow can spend 50,000 tokens eliciting precise requirements and then summarize them into 15,000 tokens of markdown, throwing away detail on the way to the file that is supposed to preserve it.
Then there is the maintenance tax. Keeping specs synchronized with code is real work that grows with system complexity. Done badly, SDD does not cut overhead, it doubles it, because now you maintain the software and the document that claims to describe it. And there is a failure mode at the far end: over-specification. When a spec hardens into pseudo-code, you have written the program twice and gained nothing but a slower path to the same result.
The sharpest critique of 2026 is that SDD is “largely waterfall and contract-design rebranded,” and that “the value is the thinking you do while writing the spec, not the tooling around it.” I think that is right, and it is the most useful sentence in the entire discourse. The clarifying conversation, the moment you are forced to decide what “done” means before the agent runs, is where almost all the value lives. The constitution.md and the task-list ceremony are packaging around that moment. Sometimes the packaging earns its keep. Sometimes a well-written instructions.md gets you comparable output at a fraction of the cost.
A decision rule that survives contact
After twenty years running IT operations, I have shipped enough systems to distrust any methodology sold as universal. Requirements discipline is not new to me, and neither is the failure of treating every task as if it needs a change-control board. The honest read on SDD is that it is altitude-dependent. Here is the rule I would give a team.
Reach for full SDD when the work has consequences that outlive the session. Integration-heavy systems, regulated or audited code, anything with multiple maintainers, and greenfield distributed platforms are exactly where a versioned spec earns its token bill. Microsoft cites a brownfield onboarding that dropped from two or three weeks to days because the spec carried the intent instead of a departed engineer’s memory. When the cost of a wrong assumption is a production incident or a compliance finding, paying tokens to pin the assumption down is cheap insurance.
Skip the ceremony when the work is small, exploratory, or subjective. A throwaway script, a prototype you will rewrite, a task with a fuzzy goal you are still discovering: these do not benefit from a constitution and a task list, and several practitioners found in 2026 that a plain instructions.md beat a full SDD tool on both speed and cost for exactly this class of work. If you cannot yet write the acceptance criteria, you are not ready to spec, you are ready to experiment.
In the middle, go lightweight. Most real work is neither a compliance system nor a throwaway. For that broad center, a short principles file plus a project context file (a constitution.md or an AGENTS.md that pins your stack, structure, and standards) captures 80 percent of the value at 20 percent of the overhead. You do not need the whole seven-phase lifecycle to stop your agent from reinventing your folder layout every morning.
How to run it without drowning
If you do adopt SDD, a few practitioner habits keep it from becoming the thing it was meant to prevent.
Keep the spec at the altitude of “what” and “why.” The second it starts specifying every function signature, you are writing pseudo-code and paying twice. Let the plan phase own the “how,” and let the agent own the keystrokes.
Put a real gate between spec and merge. The 80-to-90-percent completion problem is why /speckit.analyze and a validation pass exist. Treat the spec as your code-review artifact: you review the diff against the spec, not against your recollection of a prompt. This is the single change that converts SDD from documentation theater into a quality control.
Route the phases by cost. The specify and clarify phases are where a strong reasoning model pays off, because that is where intent gets decided. The implement phase, once tasks are small and testable, can often run on a cheaper tier. This is the same cost-map thinking that separates AI buyers who control their bill from those who get surprised by it, applied to a coding workflow instead of an API.
Version the spec like code and keep it in sync, or do not keep it at all. A stale spec is worse than no spec, because it lies with authority. If you cannot commit to maintaining the artifact, use the lightweight path and skip the ceremony.
The tools will keep multiplying. Spec Kit, Kiro, OpenSpec, and whatever ships next quarter are all circling the same insight, and it is older than any of them: the expensive part of software was never the typing. It was deciding what to build. Agents made the typing nearly free, which is precisely why the deciding is now the whole job. The spec is not the new code. It is the new code review, the place where you catch the wrong build before the agent spends a weekend building it. Whether you run the full lifecycle or a single markdown file, that is the part worth paying for.