AI-DLC in Practice: Running AWS's AI-Driven Lifecycle
- AI-DLC inverts the usual AI-assistant flow: the agent proposes plans and asks questions, and humans move to the approval gates.
- The headline "10–15×" numbers are AWS's own, from engagements with AWS engineers in the room. Treat them as an upper bound, not a forecast.
- The method lives or dies on gate quality. Rubber-stamped approvals are worse than no gates, because they produce false audit evidence.
- The open-source
awslabs/aidlc-workflowsproject now runs the same workflow in Claude Code, Kiro, Codex CLI, Cursor, opencode and Copilot.
Introduction
Most teams that adopt AI coding assistants see a modest bump: a faster autocomplete here, a quicker test scaffold there. AWS’s own framing is that this “AI-assisted” pattern, where senior engineers orchestrate everything and use AI to fill gaps, tends to yield roughly 10–15% productivity gains. The process around the tool stays the same: same sprints, same handoffs, same ceremonies built for a world where humans type every line.
The AI-Driven Development Life Cycle (AI-DLC) is AWS’s attempt to rebuild the process itself. Raja SP published the founding post on the AWS DevOps blog in July 2025, and the workflow rules were open-sourced that November. By October 2026 the project has grown into a multi-harness toolkit with a native aidlc CLI, a 33-stage workflow model, and releases landing almost daily.
This article explains the method, shows how to wire it into a real project with Claude Code, and spends serious time on where it breaks, because the failure modes are more instructive than the pitch.
You should be comfortable with Git, a terminal, and at least one agentic coding tool (this guide uses Claude Code). You also need to be able to write a clear specification: AI-DLC assumes your team already knows how to state intent precisely enough for an agent to act on it. A greenfield or small brownfield repo is the best place to try it first.
"AI-DLC" is overloaded. This article covers the AWS-originated AI-Driven Development Life Cycle (Inception, Construction, Operations). Other vendors use the same abbreviation, or the near-identical "AIDDLC," for different frameworks, including a seven-phase standard and generic "AI-SDLC" guides. When someone says they "do AI-DLC," ask which one.
Core Concept 1: The Inversion
In ordinary AI-assisted work, you start the conversation. You write a prompt, the AI helps with a task, and your existing process absorbs the result. In AI-DLC, the AI starts. You give it an intent; it breaks the intent into a plan, comes back with questions about edge cases, integrations and undocumented rules, and then stops for approval before each consequential step.
Two terms matter here:
- Mob Elaboration (Inception): the whole team (product, engineering, security, operations) reviews the AI’s questions and proposed requirements together, in real time.
- Mob Construction (Construction): the team validates AI-proposed architecture, code and tests live, rather than reviewing a pull request days later.
The core rule is simple: the agent proposes, the human approves. The human did not leave the loop; they moved to the gates.
The loop in the diagram repeats once per bolt, AI-DLC’s replacement for the sprint. Bolts are measured in hours or days, and epics become Units of Work.
Core Concept 2: New Vocabulary, Same Problems
AI-DLC deliberately renames Agile concepts, partly to signal that the economics have changed: when an AI drafts artifacts, plans and tests in seconds, the sensible batch size shrinks.
The renaming is not cosmetic fluff, but it is also not magic. As one analysis put it, rebranding sprints achieves nothing unless you change what you demand from the AI and from your reviewers.
How the workflow engine models it
The open-source implementation (AI-DLC Workflows 2.x) breaks the lifecycle into five phases and 33 stages: Initialization, Ideation, Inception, Construction and Operations. Initialization stages run automatically. Every other stage ends with an approval gate where you answer Approve or Request Changes in your own words, and nothing moves until you do.
You rarely run all 33. The tool selects a workflow profile from your request: there are 11, covering features, bug fixes, infrastructure, security work, proofs of concept and enterprise delivery. A “Classic” profile runs 18 of the 33 stages, a full “Feature” profile runs all 33, and one maintainer’s analysis of a small bug-fix request shows 9 stages with 6 approval gates.
If your task fits no built-in profile, the /aidlc compose command asks a composer agent to propose a custom route, which still waits for your approval before running.
Practical Implementation: AI-DLC with Claude Code
aidlc command and every harness runtime.aidlc config --harness claude from the project root, then aidlc doctor to verify the setup./aidlc with a concrete goal. The agent selects a workflow, asks for missing decisions, and stops at gates.Install and configure
# Install the native aidlc command (Linux/macOS)
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh | sh
# If your shell can't find `aidlc`, follow the PATH hint the installer prints,
# or open a new shell.
# From your project root, pick the harness you use
cd /path/to/your-project
aidlc config --harness claude # also: kiro, kiro-ide, codex, cursor, opencode, copilot
aidlc doctor # verifies the install and hook setupOn Windows, the repository documents a PowerShell installer (install.ps1) at the same release path. Codex CLI users invoke the workflow with $aidlc instead of /aidlc, and Kiro IDE users first select the aidlc agent in the chat panel.
Start a workflow
Open Claude Code in the configured project and describe the work:
/aidlc Build a REST API for inventory managementA vague intent like this one (taken from the project’s quick start) works as a demo, but production intents should name constraints. Here is a template I would use; the structure is my suggestion, not an AI-DLC requirement:
/aidlc Add idempotent order cancellation to the orders service.
Context: Postgres 16, FastAPI, existing outbox pattern for events.
Constraints: no schema changes that need downtime; cancellation must be
safe to retry; emit exactly one OrderCancelled event.
Out of scope: refunds, partial cancellations.
Done when: contract tests pass and the runbook is updated.Stating out-of-scope items and a “done when” condition gives the agent something to generate completion criteria from, and gives your approver something concrete to check.
Give approvers a checklist
A repo cannot tell you who is allowed to approve, and it does not try. You need to supply that. A lightweight gate checklist (again, a template of mine, adapt freely) keeps approvals from degrading into reflexive clicking:
# gate-checklist.yaml: attach to every Unit plan approval
approver: "<named human, not the person who wrote the intent>"
check:
- data_classification_touched: "" # PII? secrets? payment data?
- blast_radius: "" # what breaks if this is wrong?
- rollback_path: "" # how do we undo it?
- deviations_from_steering_rules: "" # anything the plan bends?
- tests_cover_stated_out_of_scope: "" # boundaries respected?
decision: approve | request_changesWhat’s New in the 2.x Releases
The project moves quickly. A few recent milestones worth knowing before you pin a version:
- 2.7.0 (September 1): existing PRDs and vision documents can serve as workflow input; Classic and Express scopes give shorter paths; Domain Design and Contract Design sharpen boundaries between units; Testing Posture carries into Code Generation.
- 2.9.0: adds commit provenance, intent archiving, and a native preview release channel.
- 2.10.0 (September 24): Construction is reviewed at verified Unit and batch checkpoints, guards separate agent execution boundaries from human-held gates, and compatible harnesses can coexist in one project.
- Preview builds: as of today (October 3, 2026) the latest is
2.10.1-preview.20261003.1, with fixes for workspace detection, Copilot output and Windows PowerShell handling.
Nightly preview builds ship almost daily. The quick start installs the latest stable release. For team rollouts, pin a stable version and upgrade deliberately; replace the whole dist/<harness>/ tree while no AI-DLC process is running, then run /aidlc plugin sync.
What the Numbers Do and Don’t Say
AWS presenters at re:Invent 2025 cited 10–15× productivity gains from AI-DLC engagements, and described Wipro compressing roughly three months of planned work into about 20 hours (five days of four-hour mob sessions). The same talk reportedly acknowledged that unstructured AI-assistant adoption lands closer to 10–15%.
Independent commentators are blunt about the caveat: these results come from controlled, often greenfield environments with AWS engineers present. Brownfield enterprise codebases under normal team conditions should expect lower numbers. Measure your own cycle time, defect rate and developer satisfaction before and after.
AI-DLC vs. Scrum
- Two-week sprints, estimated in story points
- Humans write code; peer review happens asynchronously
- Human decisions spread across execution
- Mature tooling, familiar roles
- Best for: stable teams with predictable, well-understood work
- Bolts of hours to days, scoped as Units of Work
- AI generates code; humans validate in mob sessions
- Human decisions concentrated at approval gates
- Requires strong specs and disciplined reviewers
- Best for: teams with agent tooling and clear intent
AI-DLC replaces the rituals, not the values. It also builds on spec-driven development rather than replacing it: write specifications an agent can execute first, and only then give agents more autonomy.
Common Pitfalls and Troubleshooting
One practitioner who followed a rollout reported that approvals after roughly the first hour of reading generated documents stopped being real decisions. Every later approval is worth less than the audit log claims. Keep approval sessions to about an hour, pause between gates (state is persisted, so pausing is free), and have approvers summarize what they approved in their own words.
If the same person writes the intent and approves the plan, you have removed separation of duties. Require a named approver per Unit who did not write the prompt, and record them in the audit trail. AI-DLC 2 records who approved what, but it cannot decide who should.
Gates stop vibe coding at phase boundaries, but teams still slide back into prompting-until-it-works at the keyboard in between. Keep Units small enough to review honestly (a three-hundred-change review is a rubber stamp), get second opinions from a fresh context rather than the agent that wrote the code, and clear context at each gate after committing and pushing approved artifacts.
Pilots found that the engineers and product people with the deepest domain knowledge took longer at gates, because they spotted more. That inverts the usual assumption that AI helps juniors most. Give juniors onboarding time first, and pair them with a senior reviewer for their first gates.
A small bug fix can stop you six times. An open RFC on the project (#1643, filed today) proposes a "keep going" mode. Until then, pick a lighter profile (Express or a bug-fix route) rather than forcing the full Feature lifecycle onto small changes.
Other honest limitations: large codebases still strain agent context windows, governance (audit trails, compliance checks) adds overhead small teams may not have bandwidth for, and one analysis cited AI-generated pull requests carrying around 1.7× more issues than human ones, which is exactly why the review culture is the point and not a formality.
Adoption Path
Conclusion
AI-DLC’s real contribution is not the vocabulary or the headline multiplier. It is the claim that when agents do the production work, the scarce resource becomes human judgment, so the process should be organized around protecting and spending it well. The open-source tooling makes that practical today, in the harness you already use.
The honest summary: the method is real, the tooling is maturing fast, and the benefits will be proportional to how seriously your team treats the gates.
Install the CLI on a throwaway repo, run aidlc doctor, and drive one small bug-fix workflow end to end. Notice how many gates fire and how long you stay attentive. That experience will tell you more about your team's fit than any benchmark. Then write down your approver rules before you scale.
References:
- Raja SP, “AI-Driven Development Life Cycle: Reimagining Software Engineering” - https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle - Founding post: phases, bolts, Units of Work, rituals.
- AWS DevOps Blog, “Building with AI-DLC using Amazon Q Developer” - https://aws.amazon.com/blogs/devops/building-with-ai-dlc-using-amazon-q-developer/ - Practical walkthrough of the workflow.
- awslabs/aidlc-workflows (GitHub) - https://github.com/awslabs/aidlc-workflows - Install steps, supported harnesses, workflow profiles.
- awslabs/aidlc-workflows releases (2.7.0, 2.10.0, 2.10.1-preview.20261003.1) - https://github.com/awslabs/aidlc-workflows/releases - Release notes and changelog.
- AI-DLC Workflows docs, “Phases and Stages” - https://awslabs.github.io/aidlc-workflows/guide/04-phases-and-stages/ - Stage and approval-gate model.
- exploreagentic.ai, “AI-DLC Explained: What AWS’s AI-Driven Development Lifecycle Changes” - https://www.exploreagentic.ai/insights/ai-dlc/ - re:Invent claims, Wipro case, governance gaps.
- Michael Forrester, “Deep Dive: AWS AI Development Life Cycle” - https://michaelrishiforrester.com/2026/03/11/deep-dive-aws-ai-development.html - Context and caveats on the productivity numbers.
- Felipe Fontoura, “What Is AI-DLC?” and “AI-DLC Approval Gates” - https://felipefontoura.com/articles/what-is-ai-dlc/ - Rollout experience, 33-stage map, gate fatigue.
- Felipe Fontoura, “AI-DLC Roles” and “Six Rules Against Vibe Coding” - https://felipefontoura.com/articles/ai-dlc-roles/ - Roles, ownership, and vibe-coding countermeasures.
- Carly Taylor, “Everything You Need to Know About AI-DLC” - https://carlytaylor.substack.com/p/everything-you-need-to-know-about - Critical perspective, AI-generated PR quality data.
- awslabs/aidlc-workflows issue #1643 - https://github.com/awslabs/aidlc-workflows/issues/1643 - Approval overhead for small work.