What Is AI-DLC? The AI-Driven Development Life Cycle, From Inside a Rollout

In AI-DLC the AI drives and the human decides. Every other part of the method exists to keep the second half of that sentence honest.

AI-DLC, the AI-Driven Development Life Cycle, is a method for building software in which an AI agent plans the work, asks the questions, and writes every artifact, from requirements to code, while humans approve or reject the result at gates between the steps. AWS published it in July 2025. In September 2026 it shipped AI-DLC 2, an installable workflow engine that runs inside Claude Code, Kiro, Codex, Cursor, opencode, and GitHub Copilot.

That is the definition. The rest of this guide is the part the documentation leaves out.

I have been writing about Spec-Driven Development for a year, and I built a 13-app fintech in 70 days by specifying before generating. For the last few months I have also been inside a large engineering organization where AI-DLC moved from pilot squads to a training program for the people who will spread it to every team. I sat in the sessions. I watched what broke. Everything below comes from the public method, the current release, and that rollout, with the names taken out.

AI-DLC is a method, not a tool

Start with the thing people get wrong first. AI-DLC is a way of organizing software work around an AI agent. AWS describes it as a methodology, and the independent analyses agree. TT PSC’s writeup put it in one line: the contribution of AI-DLC “is not code generation itself”, it is “a controlled operating model where AI participates throughout Inception, Construction, and Operations, while humans remain accountable for decisions.”

The tool came later. The original release in November 2025 was a set of rules files for Amazon Q and steering files for Kiro. AI-DLC 2 turned it into an engine with its own command, aidlc, that installs the workflow into the coding agent you already use. AWS calls each of those agents a harness: Claude Code is one, Cursor is another. You can practice the method without the engine. You cannot get value from the engine without the method.

AI-DLC 2 at a glance

5

phasesInitialization to Operation

33

stageseach with a lead agent

14

agents11 experts, 2 reviewers, 1 composer

7

harnessesClaude Code, Kiro, Codex, Cursor and more

The AI asks the questions and you decide

The core of the method is one inversion. In ordinary AI-assisted work, you start the conversation. You write the prompt, the AI helps with a task, and the process around it stays the one your team already had. In AI-DLC the AI starts. You give it an intent, and it proposes the plan, asks what it needs to know, drafts the artifact, and stops for your approval before it moves on.

The whitepaper uses a navigation app to explain it. You set the destination. The app gives you the turns. You still watch the road and you can take another street, but you stopped reading the map.

AI-assisted development

1. 01You write the prompt and the AI answers
2. 02The AI helps on one task at a time
3. 03The process is the one built for humans
4. 04Decisions live in chat history

AI-DLC

1. 01You state an intent and the AI asks the questions
2. 02The AI proposes the plan and the decomposition
3. 03The process is rebuilt around the AI's speed
4. 04Decisions live in versioned files in the repo

This changes what good work looks like for you. You no longer win by writing the perfect prompt. You win by answering the right questions with the right context, and by refusing to approve what you cannot explain.

Why AWS says you cannot bolt AI onto Scrum

The first principle in the whitepaper is to reimagine rather than retrofit. The argument is simple and I think it is correct. Scrum was built for a team of humans who need two weeks to produce a working increment, so it has rituals sized to that pace: planning, dailies, reviews, retros. An agent produces the same increment in hours. Keep the two-week rituals and the agent spends most of its life waiting for a meeting.

The paper names the two failure modes on either side. AI-assisted development keeps the old process and adds autocomplete, so it never changes the structure of the work. AI-autonomous development lets the agent build alone, which does not work yet, because context and critical decisions still depend on a person. AI-DLC is the middle: the AI drives, the human approves.

The vocabulary: Intent, Unit, Bolt

AI-DLC renamed the parts of the work on purpose. The whitepaper’s seventh principle says a practitioner should be able to start in a single day, so every new term maps to an old one.

Old words, new words

Bolt is not a rebranded sprint. It is shorter because the AI compresses the time to produce an artifact from days to minutes.

AI-DLC term	What it replaces	What it means
Intent	Business epic	A statement of what needs to be achieved and why. The starting point the AI decomposes.
Unit	Technical epic	A self-contained piece of the solution that delivers measurable value and can be built and deployed on its own.
Bolt	Sprint	A delivery slice measured in hours or days, not weeks. In AI-DLC 2, a planned slice over one or more dependent Units.
Mob Elaboration	Planning and refinement	The team and the AI in one session: the AI proposes stories and Units, the team corrects them.
Mob Construction	Coding, review, testing	The AI generates design, code, and tests; engineers approve or request changes at each step.
Deployment Unit	Release candidate	Code, configuration, and infrastructure tested for function, security, and non-functional requirements.

Two of these deserve a second look. The Intent is the one input a human must get right, and the method says almost nothing about how to get it right. That gap is big enough that it gets its own article. And Mob Elaboration is where most of the value and most of the pain live. It is a ritual, with rules about who sits in the room, and it has its own guide.

Five phases and 33 stages in AI-DLC 2

The first version of AI-DLC had three phases: Inception, Construction, and Operations. AI-DLC 2 has five. It added Initialization, which sets up the workspace in under a second with no human involved, and Ideation, which turns a vague request into an approved initiative before any requirements are written.

The AI-DLC 2 lifecycle

1. 0.1 to 0.3

   Initialization

   Scaffolds the workspace, detects the project, creates state. Automatic.

   • Workspace Scaffold
   • Workspace Detection
   • State Initialization
   ↓→
2. 1.1 to 1.7

   Ideation

   Is this worth building, and what exactly is it?

   • Intent Capture and Framing
   • Market Research
   • Feasibility
   • Scope Definition
   • Team Formation
   • Rough Mockups
   • Approval and Handoff

   ◆ Gate: Verification gate 1

   ↓→
3. 2.1 to 2.9

   Inception

   Requirements, design, and the Units of work.

   • Reverse Engineering
   • Practices Discovery
   • Requirements Analysis
   • User Stories
   • Refined Mockups
   • Domain Design
   • Units Generation
   • Contract Design
   • Delivery Planning

   ◆ Gate: Verification gate 2

   ↓→
4. 3.1 to 3.7

   Construction

   Design, code, and tests, one Unit at a time.

   • Functional Design
   • NFR Requirements
   • NFR Design
   • Infrastructure Design
   • Code Generation
   • Build and Test
   • CI Pipeline

   ◆ Gate: Verification gate 3

   ↓→
5. 4.1 to 4.7

   Operation

   Deploy, observe, and feed what you learn back into Ideation.

   • Deployment Pipeline
   • Environment Provisioning
   • Deployment Execution
   • Observability Setup
   • Incident Response
   • Performance Validation
   • Feedback and Optimization

Two kinds of checkpoints run through that map, and the difference matters. At the end of every stage there is an approval gate: you answer Approve or Request Changes, in your own words, and nothing moves until you do. Between phases there is a verification gate: an automated check that every requirement maps to a story, nothing is orphaned, and the artifacts agree with each other. The first catches bad judgment. The second catches broken links.

Each stage has a lead agent. AWS ships 14 of them: 11 domain experts (product, design, delivery, architect, AWS platform, compliance, DevSecOps, developer, quality, pipeline and deploy, operations), two reviewers that judge requirements and technical design, and a composer that assembles custom routes. The design principle is “Small Mob, Broad Agents”: a few broad agents instead of dozens of narrow specialists, because a chain of narrow specialists is just waterfall handoffs with better marketing.

Most stages run inline, in your conversation with the agent. Four do not. Reverse Engineering is a two-step pipeline (a developer agent scans the code, an architect agent writes the synthesis). Practices Discovery and Code Generation run as dispatched subagents. User Stories runs as a mob, with the design, developer, and quality agents writing in parallel. Everything gets written to a per-intent folder in your repo, with a state file and an append-only audit log that records 108 kinds of events.

The most important design choice in AI-DLC 2 is not on that map. The route through it is decided by a deterministic engine, plain code, and not by the model. The model does the thinking inside each stage. The engine decides which stage runs next, a Unit only counts as verified through a check command a human approved, reviewers are separate agents, and the model’s tools cannot rewrite the workflow state. Version 1 trusted the agent to follow prose rules, and slop comes from exactly that trust: a model that routes itself and grades its own work. Version 2 took those powers away.

The details of what changed between the versions, and which homegrown workarounds AI-DLC 2 made obsolete, are in AI-DLC 2: what changed.

A bugfix does not need 33 stages

The tenth principle of the original whitepaper is the one I would keep if I could keep only one: no hard-wired workflows. A bug fix does not need domain modeling. A new feature does. The AI should propose how deep to go, and the human should adjust.

AI-DLC 2 turned that principle into 11 workflow profiles. You name one, or you describe the work and the engine suggests one.

Workflow profiles in AI-DLC 2

For anything that fits none of them, /aidlc compose asks the composer agent for a custom route and waits for your approval.

Profile	Stages	Use it for
Classic	18 / 33	Version 1 ceremony: Inception and Construction, one approval per stage. The default when you name nothing.
Express	10 / 33	Requirements already clear. Shortest path to code and tests.
Feature	33 / 33	A production feature through the whole lifecycle.
Enterprise	33 / 33	Regulated or high-risk work. Comprehensive depth and the strictest guards.
MVP	23 / 33	A real first increment, without the Operation phase.
Proof of concept	8 / 33	Can this work at all?
Bugfix	9 / 33	A known defect, a focused fix, a regression test.
Refactor	10 / 33	Change the structure, keep the behavior.
Infrastructure	13 / 33	Environments, IaC, pipelines, cost.
Security patch	10 / 33	A CVE or a narrow vulnerability.
Workshop	26 / 33	A facilitated training session.

And there is a twelfth answer the table does not list: do not use AI-DLC at all. In the rollout I followed, one engineer ran the full ritual to change a single line of code. The internal playbook soon got a new rule, contributed by someone from the pilot: if you already know exactly what to type, type it. AI-DLC pays when the work needs decomposition and decisions from more than one person. Below that, the ceremony costs more than it saves.

The gates are the method

Strip AI-DLC to its skeleton and what remains is a loop. The AI produces an artifact. A human checks it. The next step uses the checked artifact as its input. The whitepaper calls each human check a loss function: it catches a wrong decision where reversing it is cheap, before it multiplies through everything downstream.

That framing is right, and it hides the method’s weakest point. The gate is only as good as the person standing at it, and the AI produces artifacts faster than a person can read them with care. What I saw break, in order of frequency:

How gates fail in practice

• ✗Anti-pattern:
  The artifact looks complete and says nothing.A well-formatted requirements document reads like a real one. A PM in the rollout compared it to a phishing email from your bank: the familiar format switches off your skepticism.
• ✗Anti-pattern:
  The reviewer is tired.After an hour of reading generated documents, people approve without reading. Sessions longer than an hour turned gates into rubber stamps.
• ✗Anti-pattern:
  The reviewer does not know the domain.Seniors interrogated every claim and took longer. Juniors accepted the first output. The less you know, the more you trust.
• ✗Anti-pattern:
  The tenth approval of the day.Trust calibrates on history. The agent was right nine times, so the tenth gets a glance.

The fix is mostly about pace, not tooling. Keep sessions to an hour. Pause between gates; the state file means pausing costs nothing. Have the manager sit in the first few mobs to stop the rush to approve. And adopt one rule for every reviewer: before you approve, say in one sentence what the artifact does and why it is right. If you cannot, you are not done reading. The whole argument, with the countermeasures, is in gates are a loss function.

AI-DLC needs Spec-Driven Development first

Here is my main disagreement with how AI-DLC usually gets introduced. Teams hear about it, get excited by the agents and the phases, and try to jump from autocomplete to a 33-stage lifecycle. It does not work, and the reason is not the tool.

AI-DLC assumes your people already know how to specify. Every gate asks a human to judge a spec: requirements, stories, design, the plan for each Unit. A team that has never practiced writing a spec cannot judge one. So the agent produces plausible artifacts based on its own assumptions, the humans approve them because they look fine, and the code that comes out the other end needs to be fixed by hand. The execution the agent was supposed to carry lands back on the people. That is slower than writing the code yourself.

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. Specifying well is the only lever that moves that distribution, which is why I see Spec-Driven Development as the step before AI-DLC, not its competitor.

The path from copilot to AI-DLC

1. 1

   Scrum with a copilot

   "Autocomplete inside the process you already have."

   → Faster typing. Same structure.

2. 2

   Scrum with SDD inside the task

   "Keep the sprint, but specify before you let the agent build."

   → The team learns to write and judge specs.

3. 3

   SDD with a supervised agent

   "The agent builds from the spec; you verify against it."

   → Specs become the contract, not paperwork.

4. 4

   Agentic management and execution

   "The agent plans and decomposes; humans decide at gates."

   → This is where AI-DLC starts to pay.

5. 5

   Full agentic, in bolts

   "Hours per slice, not two-week packages."

   → The cadence the method was designed for.

Most teams I meet are at step one or two and believe they are near the top, because they already ship faster than last year. The full argument, and how to tell which step you are on, is in AI-DLC vs Spec-Driven Development.

Do not adopt AI-DLC as a block

AI-DLC is the most complete public framework for building with agents. I would still not tell a team to adopt it.

Adopting it as a block means announcing “we do AI-DLC now”. People go read the paper and watch the talks, and they try to reproduce a method designed by a company with a different scale, a different culture, and a different stack. They study instead of building. And when it does not fit, they blame themselves or the method.

Treat it like a supermarket shelf. Take what solves a problem you actually have: artifacts that persist in the repo, gates between steps, slices measured in hours, the habit of letting the AI ask. Leave the rest. Write down what you took, what you left, and why.

AI-DLC 2 is the proof that this is the right posture. Teams that adopted version 1 built layers on top of it: state files, retrospectives, parallel construction, custom rules. AI-DLC 2 shipped most of that as native features. The homegrown plumbing became obsolete in one release. What survived was the judgment those teams had encoded: their rules against vibe coding, their ritual for shaping an intent, their sense of when not to use the method at all. The argument is in don’t adopt AI-DLC, steal from it.

What happens when a real team runs it

The docs describe the method. Here is what the rollout added.

Throughput goes up from day one and cycle time gets worse first. The agent produces code immediately, so merged changes per developer jump. But nobody redesigned code review for the new volume, so changes pile up waiting for a human, and the time from first commit to deploy goes up before it comes down. That J-curve is the most predictable thing in an AI-DLC rollout, and the most common reason managers kill it too early. More in why AI-DLC makes you slower first.

The context window is a design constraint, not a detail. An Inception on a real repository fills a large part of a one-million-token window. Teams learned to clear the context at every gate, never in the middle of a phase, and to resume from the state file. Quality dropped noticeably once the window passed three quarters full. Brownfield code makes it worse, because the agent has to reverse-engineer what exists before it proposes anything. All of that is in AI-DLC in brownfield.

Product does not need to sit in the whole mob. The agent asks a long list of questions after reverse engineering, and most of them are technical. The pattern that worked: engineers answer the technical ones, and product joins for the business questions. The Mob Elaboration guide has the rest of the ritual.

The rules that held quality up were small and specific. Never edit generated code by hand; go back to the design. Prefix exploratory questions with “Do not update any documents.” Ask for a critique in a fresh context, because the agent defends what it wrote. They are collected in six rules against vibe coding inside AI-DLC.

And the job changes. Squads shrink toward pods of an engineer and a PM. Backend engineers ship front-end work. The engineer still owns the code in production, because when it breaks at night the agent is not the one paged. Competency matrices that reward writing code start rewarding the wrong thing. That is from squad to pod, and the measurement side is after story points.

How to start without wasting a quarter

A first AI-DLC run that teaches you something

Input

A team that already writes specs and wants to try AI-DLC

↓

1. REPOMake the repository readable by an agent

   A short AGENTS.md or CLAUDE.md with the stack, the patterns, the forbidden libraries, and one example of each. Brownfield code without this produces guesses.

   ↓
2. PICKPick one real feature, not a one-line fix

   Something that needs decomposition and decisions from more than one person. Small enough to finish in a week.

   ↓
3. INSTALLInstall the engine in the agent you already use

   aidlc config for your harness, then aidlc doctor. The full Claude Code setup is in its own guide.

   ↓
4. RUNRun the Classic or Feature profile

   Classic is the version 1 ceremony and the gentlest start. Keep sessions to one hour and clear context at gates.

   ↓
5. MEASURERead throughput next to cycle time

   Expect the J-curve. Decide after about four weeks whether you are learning or stuck.

↓

Output

One feature shipped through the method, and an honest list of what to keep, change, or drop.

The concrete setup, with the commands, is in AI-DLC with Claude Code. If your team is not specifying yet, start one step earlier with how to write a spec, or with a lighter kit like pi-sdd-kit, and come back when writing and judging specs feels normal.

What the independent analyses add

AWS wrote the method, so read the people who did not. Augment Code’s guide to AIDLC maps the competing names for the same shift (AWS’s AI-DLC, Forrester’s agentic software development, Cycode’s ADLC) and frames the real choice as human in the loop against human on the loop. Wiz reads it as a security problem: the speed is the asset and the risk at once, with roughly a fifth of AI-suggested packages pointing to dependencies that do not exist. Mission Cloud adds the idea of a living spec, kept in sync with the code by an agent. Anthropic’s AI-native SDLC playbook describes the same chain of versioned artifacts from a different vendor. They converge on the same point the rollout taught me: the AI is not the hard part. The people at the gates are. My own field version of the whole lifecycle, written in the order you adopt it, is the agentic SDLC playbook.

FAQ

What does AI-DLC stand for?+

AI-Driven Development Life Cycle. It is a software development method published by AWS in July 2025, in which an AI agent plans the work and produces the artifacts while humans approve or reject them at gates. The open-source implementation lives at github.com/awslabs/aidlc-workflows.

Is AI-DLC only for AWS?+

No. The method is provider-independent, and AI-DLC 2 runs inside Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, and GitHub Copilot with the same engine.

AWS fingerprints remain: one of the 14 agents is an AWS platform specialist, and optional AWS MCP servers ship with it. On another cloud you ignore them or replace them.

Does AI-DLC replace Scrum or Agile?+

It replaces the rituals, not the values. Sprints become bolts measured in hours, planning becomes Mob Elaboration, and the daily shrinks to a few minutes. Kanban fits better than sprints.

Teams that tried to keep two-week sprints around an agent found the agent waiting on the calendar.

What is the difference between AI-DLC and Spec-Driven Development?+

Spec-Driven Development is a practice: write the spec, let the agent build from it, verify against it. AI-DLC is a full lifecycle that assumes your team already does that, and adds phases, gates, agents, and team rituals around it. SDD is the prerequisite, not the alternative.

What is a Bolt in AI-DLC?+

A Bolt is the delivery slice that replaces the sprint: work measured in hours or days instead of weeks. In AI-DLC 2 it is a planned slice over one or more dependent Units, and the build order follows the dependency graph between Units.

Do I need Kiro to use AI-DLC?+

No. Kiro was the first home for AI-DLC's steering files, but AI-DLC 2 treats seven harnesses as first-class, including Claude Code, Cursor, and Codex.

Is AI-DLC free?+

Yes. The workflows are open source under the MIT-0 license. You pay for the model your agent uses, and an AI-DLC run reads and writes a lot of context, so watch the token bill on the first runs.

When should I not use AI-DLC?+

When you already know exactly what to change. A one-line fix, a typo, a config bump. The method pays when the work needs decomposition and decisions from more than one person. Below that, use a lighter profile like Bugfix or Express, or just write the code.

Where to go next

AI-DLC is the clearest public answer so far to the question every engineering leader is asking: how do we build software with agents without losing control of what we ship. The answer is not the agents. It is the gates, the artifacts, and the people who can judge them. Get your team specifying first, take from the method what fits, and measure honestly when the curve dips.