Direct answer
Spec-driven development (SDD) is a workflow where a written, version-controlled specification, not the code is the source of truth: teams write down what a system should do, derive a plan, break it into tasks, and only then let an AI agent generate the implementation. In Scrum, the detailed spec belongs closer to execution written during the Sprint, at the moment work is pulled rather than buried in the Product Backlog. In Kanban, the spec becomes a visible stage on the board, alongside "in progress" and "in review," rather than an invisible artifact nobody tracks.
Why agile teams are revisiting specs in 2026
For most of the last decade, "write the spec first" sounded like the exact habit agile was invented to move away from. That's changed, and the reason isn't process fashion, it's what happens when the thing implementing the ticket stops being a person.
A developer handed a vague requirement fills the gap with judgment and, often, a clarifying question. An AI agent fills the same gap with its best guess, delivered fluently enough that the guess is easy to mistake for a decision someone made on purpose. Sonar's 2026 developer survey found 88% of developers report at least one negative impact from AI on technical debt, with 53% specifically pointing to code that looks correct but introduces hidden defects (Sonar, 2026). Separate reporting on the 2026 Stack Overflow developer survey found a majority of developers using AI tools have generated code they didn't fully understand at least some of the time, a pattern that shows up in experienced engineers, not just beginners (DEV Community, 2026).
Spec-driven development is the response: make the contract explicit before the agent starts, because the agent isn't going to ask.
Where does the spec live in Scrum?
The common mistake is trying to force the full, agent-executable spec into Backlog Refinement or Sprint Planning. That turns refinement into a monologue, one person shows up with the whole spec pre-decided, and the rest of the team has nothing left to contribute.
A more workable altitude split, echoed across recent agile writing on the topic, looks like this:
| Ceremony | What lives there |
|---|---|
| Product Backlog | Intent, rough acceptance criteria, context, enough to prioritize |
| Backlog Refinement / Sprint Planning | Goal-level discussion; commitment to a Sprint Goal |
| During the Sprint | The detailed, agent-executable spec, written by whoever pulls the item |
| Definition of Done | "Spec reviewed and approved," added alongside existing quality gates |
Yuval Yeret describes the spec as becoming a higher-level programming language: humans hold intent, constraints, and acceptance criteria at that layer, while the agent handles implementation from there (Yeret, 2026). That framing explains why pushing the detailed spec earlier in the cycle tends to backfire, nobody has enough context to write it well until the work is actually about to start.
Where does the spec live in Kanban?
Kanban doesn't need a new framework to accommodate this, it needs a new lane. Boards that already visualize "queued," "in progress," and "in review" can add a stage for spec status: drafted, approved, agent building, human reviewing output. That's a direct extension of Kanban's core discipline, limit work in process, make blockage visible applied to an artifact that's easy to let rot silently in someone's editor if it isn't tracked on the board at all.
What the tooling landscape looks like right now
The tools built around SDD converge on the same basic move: generate a written requirements artifact before any code, and treat that artifact, not the chat history, as the reference for what gets built.
-
GitHub Spec Kit, open-sourced in September 2025, is a model-agnostic CLI with slash commands (
/specify,/plan,/tasks,/implement) that work across several AI coding assistants (GitHub Spec Kit). - AWS Kiro takes a stricter approach: no code generation until a requirements document, written in EARS notation, has been produced and approved (Kiro documentation).
- Multi-agent build platforms, including 8080.ai, apply the same principle at the application level, a single prompt produces a full requirements document and an architecture diagram, gated for human approval, before specialist agents begin writing frontend, backend, and infrastructure code in parallel.
None of these are solving a code-generation problem. They're solving a coordination problem: keeping a literal-minded, fast collaborator aligned with intent that used to live informally in a senior engineer's head.
A worked example: one backlog item, two workflows
Without spec-driven development: a backlog item reads "add CSV export to the reporting dashboard." It gets refined, estimated, pulled into a sprint. A developer opens the codebase and starts implementing, making a series of small unwritten calls along the way, which columns to include, how to handle rows with missing data, what happens on a 500,000-row export. None of those decisions are documented anywhere. If an AI agent is doing the implementation instead of a developer, it makes the same calls, but nobody notices until the missing-data case breaks in production.
With spec-driven development: the backlog item is identical. The difference starts when the item is pulled into active work. Before any code is generated, someone writes a short spec: which columns export, what happens to rows with missing fields, a size threshold for streaming versus batch export, and what "done" means in testable terms. That spec gets a fast review, then goes to the agent. The resulting code can be checked against the spec directly and six months later, when someone needs to modify the export logic, the spec still explains why it behaves the way it does.
The backlog item didn't change. What changed is that a set of decisions that used to live only in a developer's head now lives in a document the whole team and every future agent working on that code can read.
Frequently asked questions
Does spec-driven development replace Scrum or Kanban?
No. It changes what gets documented and when, not the framework itself. Most of Scrum's and Kanban's core mechanics Sprint Review, Retrospective, WIP limits, flow visualization hold up fine; what changes is where detailed technical specification happens.
Is this just waterfall with extra steps?
Not if it's scoped correctly. The failure mode teams should watch for sometimes called "SpecFall" happens when a full spec gets written months in advance and then treated as unchangeable, recreating the rigidity agile was meant to avoid (InfoQ, 2026). Scoped to "written at the moment of building, editable as understanding improves," it isn't.
What happens to story points and task breakdown?
They're increasingly optional. If an agent decomposes a spec into tasks as part of generating the implementation plan, manually re-deriving the same breakdown in Sprint Planning is often redundant.
Why is this happening now instead of years ago?
Because the cost of ambiguity changed. A human filled gaps with judgment; an agent fills them with a guess delivered as confidently as a correct answer and the resulting rework is well documented across recent developer surveys.
Is spec-driven development the same thing as vibe coding?
No, it's the corrective. Vibe coding is prompting an agent loosely and shipping whatever it returns. Spec-driven development requires an explicit, reviewable contract before code generation starts, which is the step vibe coding skips.
Does spec-driven development slow teams down?
Not in aggregate, according to teams using it, the time spent writing a short spec is typically smaller than the time spent later debugging or rewriting code built from an ambiguous prompt. The cost shows up earlier and smaller instead of later and larger.
Top comments (0)