AI-DLC vs Spec-Driven Development: Why You Need SDD First

AI-DLC asks a human to judge a spec at every gate. A team that has never written a spec cannot judge one.

People search “AI-DLC vs Spec-Driven Development” as if they had to pick one. That is the wrong question, and answering it as asked is how a team ends up running a 33-stage lifecycle it cannot operate.

Spec-Driven Development (SDD) is a practice: before an agent builds anything, you write down what it must do, and you verify the result against what you wrote. AI-DLC, the AI-Driven Development Life Cycle that AWS published in 2025 and shipped as an installable engine in 2026, is a whole lifecycle: phases, rituals, agents, and human approval gates, from the first idea to production. One is a habit. The other is an organization built on that habit.

I have been writing specs for agents for over a year, including the 13 apps I built in 70 days. For the last few months I have also been inside a large engineering organization watching AI-DLC move from pilot squads to the people who will spread it to every team. The teams that struggled were not the ones with the wrong tool. They were the ones that had skipped the habit.

SDD is a practice, AI-DLC is a lifecycle

The fastest way to see the difference is to put them side by side on the things a team actually does.

Two layers, not two choices

SDD fits inside AI-DLC. AI-DLC does not fit inside SDD.

Dimension	Spec-Driven Development	AI-DLC
What it is	A discipline for one piece of work: specify, generate, verify.	A full lifecycle for a team: 5 phases, 33 stages, gates between them.
Who drives	You write the spec. The agent builds from it.	The AI proposes the plan and asks the questions. You decide at gates.
Main artifact	Requirements, design, and tasks, versioned next to the code.	A per-intent record: requirements, stories, ADRs, Units, plans, state, audit log.
Rituals	None required. A gate per document is enough.	Mob Elaboration, Mob Construction, approval gates, verification gates.
Scope	Works for one developer and one feature.	Pays when the work needs decisions from several people.
Smallest useful start	Three markdown files and an agent.	An installed engine, an agent-readable repo, and a team that already specifies.

Read the last row twice. SDD is something you can start this afternoon. AI-DLC is something you can start once SDD is normal, and not before.

Every AI-DLC gate is a spec review

Walk through the stops in an AI-DLC run and count how many of them are a human reading a specification and deciding whether it is right.

In Inception, the phase where the work gets defined, the agent writes the requirements, and you approve them. It drafts user stories, and you approve them. It proposes a domain design with architecture decisions, and you approve it. It splits the work into Units, the independently buildable pieces, and you approve the split. In Construction, the phase where it gets built, it writes a plan for each Unit before it writes a line of code, and you approve the plan. Every one of those gates is the same act: judging a spec.

That act is a skill. It means noticing a requirement that has no acceptance criterion, a story that hides two features, a design that is right locally and wrong for the rest of the system, a plan that touches files it should not. Nobody is born with it. People learn it by writing specs and watching agents build the wrong thing from the vague ones.

What happens when a team skips SDD

The failure is quiet, which is why it is common. Here is the mechanism I watched more than once.

The team installs the workflow and starts a feature. The agent asks its questions. Nobody on the team is used to answering in specifics, so the answers are short and vague. The agent fills the gaps with the most likely assumption, which is the statistical average of everything it has read. The requirements document comes out long, well formatted, and generic. The team approves it, because it looks like a requirements document. The design follows the same pattern. Then Construction produces code that runs, passes its tests, and does not quite solve the problem.

So a developer opens the code and fixes it by hand. The execution the agent was supposed to carry lands back on a person, and now that person is fixing code they did not write, against a spec they did not really read. That is slower than writing the code in the first place, and the team concludes that AI-DLC does not work.

The model will satisfy any specification you give it, good or bad. Statistically it lands anywhere between the best and the worst version of what you meant. I said this in one of the rollout sessions, and I keep saying it because it is the whole argument: the only lever that moves the agent toward the best version is the quality of the spec, and the quality of the review that approved it.

AI-DLC without the spec habit

1. 01Vague answers to the agent's questions
2. 02Generic requirements approved because they look finished
3. 03Code that passes tests and misses the point
4. 04Developers patching generated code by hand
5. 05"AI-DLC doesn't work for us"

AI-DLC on top of SDD

1. 01Answers with numbers, edge cases, and negative scope
2. 02Requirements a reviewer can test line by line
3. 03Code built against a spec someone actually read
4. 04Fixes go back to the spec, not the code
5. 05The gates catch errors where they are cheap

The ladder from copilot to AI-DLC

Most teams do not need to choose between SDD and AI-DLC. They need to know which step they are standing on. This is the ladder I use with engineering leaders, and it came out of a conversation about why a full AI-DLC rollout was arriving too early for most teams.

From copilot to AI-DLC

1. 1

   Scrum with a copilot

   "Autocomplete and chat inside the process you already run."

   → Faster typing. The structure of the work does not change.

2. 2

   Scrum with SDD inside the task

   "Keep the sprint. When you pick up a task, spend more time specifying, let the agent build, check the result."

   → The team learns to write and judge specs without changing anything else.

3. 3

   SDD with a supervised agent

   "The spec is the contract. The agent builds from it, you verify against it, and fixes go back to the spec."

   → Specs stop being paperwork. Review moves before the code.

4. 4

   Agentic management and execution

   "The agent plans, decomposes, and asks. Humans decide at gates."

   → This is where AI-DLC starts to pay for its ceremony.

5. 5

   Full agentic, in bolts

   "Work moves in slices of hours instead of two-week packages."

   → The cadence AI-DLC was designed for.

The step that matters is two. It costs almost nothing: the sprint stays, the board stays, the ceremonies stay. The only change is inside the task. And it builds the exact skill that steps four and five depend on.

Most teams I meet are at step one and think they are near the top, because they ship faster than they did last year. Faster typing feels like progress. It is not the same as being able to delegate a whole unit of work.

How to tell which step you are on

Skip the self-assessment survey. Look at what the team does when a feature starts.

Ready for AI-DLC?

• ✓Required:
  Every feature starts with a written spec before any code.Not a ticket title. A document with requirements, acceptance criteria, and what is out of scope.
• ✓Required:
  Specs are reviewed before implementation, not after.If the first time anyone reads the spec is during code review, you are at step one with extra files.
• ✓Required:
  When the agent builds the wrong thing, the team fixes the spec first.Patching the generated code and moving on means the spec was never the contract.
• ✓Required:
  A reviewer can explain in one sentence why an approved spec is right.This is the exact act AI-DLC asks of every gate. If people cannot do it on their own specs, they cannot do it on the agent's.
• ✓Required:
  The repo is readable by an agent.An AGENTS.md or CLAUDE.md with the stack, the patterns, and the forbidden libraries. Without it the agent guesses, and the questions it asks are trivia.
• ✓Required:
  Someone owns the decision of when not to use the method.A one-line fix does not need a lifecycle. A team that runs everything through the full ritual is not ready, it is performing.

What SDD gives AI-DLC that AI-DLC cannot give itself

AI-DLC is a container. The quality of what goes in is not its job. Three ideas from SDD are what fill it.

The first is that the spec is external memory. An agent lives in an eternal present: it remembers nothing between sessions, so the only thing that carries a decision from Monday to Tuesday is the document it reads every time. SDD treats the spec as that memory. AI-DLC industrialized the same idea. Every intent gets its own folder in the repo with the requirements, the decisions, a state file, and an append-only audit log, and AI-DLC 2 adds a learning loop that turns your corrections into rules for the next run. It is the same principle at the scale of a team. I wrote the short version in Don’t Code, Specify.

The second is the Smart Kid Principle: write the spec for a very smart twelve-year-old who asks good questions but has none of your context. The agent has exactly that handicap, and so does the teammate who reviews the spec at the gate. A team that writes for the smart kid produces artifacts that can be judged. A team that writes for itself produces artifacts that can only be approved. How to write a spec is the full method, including requirements written in EARS, a fixed grammar for “when this happens, the system shall do that”.

The third is rigor on a spectrum. Deepak Babu Piskala’s paper on Spec-Driven Development lays out a range: code-first, ad hoc, spec-first (the spec guides the first build and may be abandoned), spec-anchored (the spec stays in sync with the code and tests enforce it), and spec-as-source (the spec is the only thing humans edit and the code is regenerated). AI-DLC sits at spec-anchored by design: artifacts persist in the repo and the verification gates check that every requirement still traces to a story and a Unit. Its working rule against editing generated code by hand, always going back to the design instead, leans toward spec-as-source. A team that has never felt the difference between spec-first and spec-anchored will not understand why that rule matters. The spectrum is explained in what Spec-Driven Development is.

Where AI-DLC goes further than SDD

None of this makes AI-DLC redundant. It does things SDD never tried to do, and those are the reasons to climb the ladder at all.

What SDD covers

1. 01One feature, from spec to verified code
2. 02A gate per document, usually a pull request
3. 03Specs written by the person who owns the task
4. 04Works for one developer and one agent

What AI-DLC adds

1. 01Ideation: is this worth building at all, before requirements exist
2. 02Mob rituals that bring product, design, and engineering into one session
3. 03Decomposition into Units and bolts with a dependency graph
4. 04An Operation phase that feeds production back into the next intent
5. 05A learning loop, reviewer agents, and workflow profiles sized to the work

The jump between them is coordination. SDD solves the problem of one person and one agent agreeing on what to build. AI-DLC solves the problem of a product manager, a designer, three engineers, and a dozen agent runs agreeing on what to build, in what order, and who approved it. That second problem is real, it is what most companies actually have, and SDD alone does not solve it. I covered the team version of SDD in Spec-Driven Development for teams, which is roughly step three on the ladder.

Moving from SDD to AI-DLC

If the checklist above came out well, the move is not a rewrite of how you work. It is one more step.

From SDD to a first AI-DLC run

Input

A team that already specifies before it builds

↓

1. KEEPKeep the spec habit exactly as it is

   The requirements, design, and task documents you already write become the input AI-DLC expects. Nothing gets thrown away.

   ↓
2. INVERTLet the agent ask the questions

   Instead of writing the whole spec yourself, give the agent the intent and answer what it asks. Your SDD instincts tell you when an answer is too vague.

   ↓
3. GATETreat each AI-DLC gate as the spec review you already do

   Same act, more often, on artifacts you did not write. Keep sessions to an hour so the reviews stay real.

   ↓
4. SCOPEStart with the Classic profile on one feature

   Classic is the version 1 ceremony: Inception and Construction, one approval per stage. The full 33 stages can wait.

↓

Output

An AI-DLC run where every gate is judged by people who know what a good spec looks like.

The setup itself is in AI-DLC with Claude Code. And before you install anything, read why I would not adopt the whole method in one go: don’t adopt AI-DLC, steal from it.

The tools blur the line, the order does not change

One reason the question keeps coming up is that the tools mix the two. Kiro is a spec-driven IDE and was also the first home of AI-DLC’s steering files. GitHub Spec Kit runs a spec, plan, and tasks flow that looks like a small Inception. AI-DLC 2 itself writes requirements and design documents that any SDD practitioner would recognize.

Ignore the branding. Ask what the people on the team can do. If they can write a spec that an agent builds correctly, and review a spec they did not write, they are ready for a lifecycle. If they cannot, no lifecycle will do it for them. The lifecycle assumes the skill. It does not teach it.

FAQ

Is AI-DLC a form of Spec-Driven Development?+

In spirit, yes. AI-DLC persists requirements, designs, and plans as versioned artifacts, and the agent builds from what humans approved. That is SDD's core loop.

But AI-DLC is much more than that loop: phases, rituals, agents, team roles, and operations. Think of SDD as the unit of work and AI-DLC as the organization around many units.

Can I use AI-DLC without doing SDD first?+

You can install it. You will struggle to run it. Every gate asks someone to judge a specification, and people who have never written one tend to approve whatever looks complete. Teams that skip the habit usually end up patching generated code by hand and blaming the method.

Which comes first, SDD or AI-DLC?+

SDD. Start by specifying inside the tasks you already do, keep your sprints and your board, and let the team get good at writing and reviewing specs. When specs are normal and reviewed before code, try AI-DLC on one real feature.

Is Kiro spec-driven development or AI-DLC?+

Kiro is a spec-driven IDE from AWS, and it was the first place AI-DLC's workflow rules ran. AI-DLC 2 treats Kiro as one of seven supported harnesses (the coding agents its engine installs into), alongside Claude Code, Codex, Cursor, opencode, and GitHub Copilot. Using Kiro does not mean you run AI-DLC, and running AI-DLC does not require Kiro.

Do GitHub Spec Kit or pi-sdd-kit compete with AI-DLC?+

Not really. They are SDD toolkits: they help one developer or one team specify, plan, and build a feature with an agent. AI-DLC is the larger lifecycle. A team that runs Spec Kit or pi-sdd-kit well is building exactly the skill AI-DLC depends on.

Does AI-DLC 2 change this answer?+

It makes it stronger. AI-DLC 2 adds an Ideation phase, more stages, reviewer agents, and a learning loop. More artifacts means more gates, and more gates means more moments where a human has to judge a spec.

Where to go next

SDD and AI-DLC are not rivals. One is the habit, the other is the house you build once the habit holds. Start where your team actually is, climb one step at a time, and do not let anyone sell you step five while you are still on step one.