# What Is Spec-Driven Development? Kiro and Spec Kit Explained
The spec becomes the thing you maintain. Two tools, three levels of commitment, and the part no tool decides for you.
7 min read · Beginner · Lesson 5 of 7 in Methods decoded · Updated 2026-10-02 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/what-is-spec-driven-development/
> **In short.** Spec-driven development (SDD) means writing a specification before any code and keeping it as the
> artefact that AI agents build from. AWS's **Kiro** does it by keeping requirements, design and tasks
> files, and **GitHub Spec Kit** by moving work from a constitution through specify, plan and tasks to
> implementation. Either way the spec, not a chat history, is what people review and what the agent
> reads.
**In this lesson** you'll learn:
- what spec-driven development is, and its three levels of commitment;
- how Kiro and GitHub Spec Kit each put it into practice;
- the honest critiques, and the parts of a spec that a tool cannot fill in.
## Sound familiar?
- The agent built something plausible and wrong, because the only "spec" was a chat thread it half-remembered.
- Six months later nobody knows why the code behaves as it does, because the reasoning lived in a conversation.
- A spec tool generated four long markdown files for a one-line bug fix, and nobody read them.
The first two are the problem spec-driven development solves. The third is the problem it can
create, and the reason depth matters.
## What is spec-driven development?
Spec-driven development is writing a spec before writing code with AI (documentation first) and
treating that spec as the authoritative reference for both people and agents. Birgitta Böckeler,
writing on Martin Fowler's site in October 2025, distinguishes three levels of commitment:
| Level | What happens to the spec | Commitment |
| --- | --- | --- |
| **Spec-first** | Written before the task, then discarded when it is done | Low |
| **Spec-anchored** | Kept after the task, and evolved with the feature | Medium |
| **Spec-as-source** | The primary artefact; people edit only the spec and the code is generated | High |
This manual asks for **spec-anchored** on every change: the spec is the one artefact that survives
the code, and a change with no spec change is a change nobody can review.
*Spec-first throws the spec away when the task is done. Spec-anchored keeps it and changes it with the feature, on every change.*
## How the tools do it, step by step
### Step 1 · Kiro: requirements, design, tasks
Kiro, AWS's agentic IDE released in public preview in July 2025, keeps three files per feature.
`requirements.md` holds user stories with acceptance criteria in **EARS** (*WHEN … THE SYSTEM
SHALL …*), the requirements syntax developed at Rolls-Royce. `design.md` holds the architecture,
data flow and testing strategy. `tasks.md` is the implementation plan, each task traceable to a
requirement. You can start from requirements or from design.
### Step 2 · GitHub Spec Kit: constitution, specify, plan, tasks, implement
GitHub Spec Kit, open-sourced on 2 September 2025, is a toolkit of templates and commands that work
inside coding agents such as GitHub Copilot, Claude Code and Gemini CLI. It moves work through a
**constitution** of project-wide principles, then **specify**, **plan** and **tasks**, and finally
**implement**, with checklists that serve as the definition of done at each step.
### Step 3 · Choose the level of commitment per change
Neither tool decides how much of this a change needs. A defect fix may need one updated acceptance
line; a new feature needs all of it. Pick the level, and the depth, from the risk of the change, not
from the tool's default. [How much process a change needs](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/how-much-process-does-a-change-need/).
### Step 4 · Fill in what the tool cannot
A spec tool gives you the places to write things down. It does not know how accurate the agent in
your product must be, which of its actions need a person, or where a limit must be enforced. Those
are the five agentic fields of this manual's [eight-field spec](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/p1-design-and-spec/#step-2--write-the-eight-field-spec)
(the model's role, autonomy per action, the bar per slice, the fallback and the records), and they
belong in the requirements file whichever tool holds it.
## The honest critiques
Böckeler's review is worth reading before you adopt either tool. Her main points:
- **Workflow mismatch.** The tools do not scale their process to the size of the problem, so small
bugs get elaborate treatment.
- **Review burden.** Long generated markdown files can be more tedious to review than the code.
- **An illusion of control.** Agents still ignore or over-interpret instructions, however full the spec.
- **An old echo.** Spec-as-source recalls model-driven development, with the risk of combining
inflexibility with non-determinism.
Each critique is an argument for **depth by change** and for **checks that do not depend on the agent
reading the spec**: the harness, the tool signatures and the tests.
## Where you'll use it
- **On every change**, at the depth it needs: at minimum, the spec is updated and reviewed.
- **As the input a coding agent builds from**, in place of a chat thread.
- **As the record an auditor or a new engineer reads** to find out why the system behaves as it does.
## Why it matters
A coding agent builds whatever it understands. Spec-driven development moves the understanding out
of a conversation and into a file that people review, version and keep, which is what makes the
agent's output reviewable, and the system maintainable, after the conversation is gone.
## Try it
A team uses Spec Kit. Its specify step produced a thorough feature spec for a refund assistant, with
user stories and acceptance criteria. **What should the architect check is in the spec before the
work crosses into the build?**
Show the answer
**The five agentic fields.** The model's role (which steps the model decides and which are exact
code), autonomy per action (which refunds may be issued alone and which need an approver), the
acceptance bar per slice derived from what a wrong refund costs, the fallback when the model cannot
decide, and what every refund must record. Spec Kit provides the structure; these decisions are the
team's, and the refund limit must also exist in the refund tool's signature, not only in the spec.