AWS AI-DLC · AWS Labs (Amazon Web Services) · as of September 30, 2026
AWS AI-DLC lets the AI run the meeting, and makes people sign off every step
Most AI methods try to need people less. AI-DLC gives the AI the asking, the drafting and the building, and keeps people for the decisions: an approval at every stage, and a record of each one in the approver’s own words.
This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.
Two philosophies at a glance
AWS AI-DLC
You decide, the AI executes, through an audited lifecycle with a person’s approval at every stage.
The Enso Method
Keep the build moving on researched proposals, and let the people who decide confirm or correct them on their own schedule.
Where they differ
- You steer each step It runs on its own AWS AI-DLC sits at the “You steer each step” end; the Enso Method sits at the “It runs on its own” end.
- Stops and asks Decides, records it, keeps going AWS AI-DLC sits at the “Stops and asks” end; the Enso Method sits at the “Decides, records it, keeps going” end.
- Specs serve one change Specs live as long as the system AWS AI-DLC sits toward “Specs serve one change”; the Enso Method sits at the “Specs live as long as the system” end.
- Light, few gates Heavy: roles and approvals AWS AI-DLC sits at the “Heavy: roles and approvals” end; the Enso Method sits in the middle.
What they share
- One change at a time The whole body of work up front AWS AI-DLC sits toward “The whole body of work up front”; the Enso Method sits at the “The whole body of work up front” end.
- Starts from a prompt Intent written down first AWS AI-DLC sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.
Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.
The AI asks, people decide, and it’s all on the record
“Humans serve as approvers, validating, selecting options, and confirming decisions at critical junctures.” That line from AWS’s method paper reverses the usual arrangement: instead of a developer prompting an AI, the AI “initiates & directs the conversations with humans”.
The AI drafts requirements, designs and code at speed, but “only humans possess the contextual understanding and knowledge of business requirements needed to make informed choices.” AWS also names the opposite failure, “process atrophy”: developers who drift into “allowing AI to ‘decide everything.’”
So every stage ends at a human approval, enforced by tools rather than trusted to the model: AI-DLC won’t record an approval unless a person has replied since the last one. AWS doesn’t see this as the end state; its 2.0 specification calls the heavy human involvement “a starting condition to optimize”, to shrink as checks a program can run take over.
One lifecycle, sized to the change
- Describe the work. AI-DLC proposes one of eleven workflow profiles, from Express (10 stages) to Enterprise (all 33), and you approve the route.
- Inception. Specialist agents (a product manager, an architect, a delivery lead) study any existing code, then draft requirements, a design, units of work and “Bolts”, work cycles of hours or days. Each stage asks its questions in a file you answer, often has a reviewer check the result, and waits for your approval.
- Construction. For each unit: a code plan you approve, then code, tests and a verified checkpoint.
- Build and test across all units, with every measurable target marked Met, Not Met or Unverified.
- Operation, in the fuller profiles: deployment, monitoring, incident runbooks, and feedback into the next idea.
Even “Continue automatically” will “still ask for plans, enabled summaries, verification command selection, and failures.”
Built for teams that have to show their decisions
AWS wrote AI-DLC for “multiple teams working cohesively within large and/or regulated organizations”, and runs multi-day workshops where product owners, developers and QA work through it together. The open-source workflow is solo-first: one person can run it end to end, and several teams can split one plan’s construction. It fits work where an unrecorded decision is expensive and operations matter as much as code, especially on AWS.
The price is attention, and AWS’s own issue tracker names it. The load teams cite first is “a structured-question checkpoint at every stage” and “one human approval gate per stage”. A full Feature run has 29 or 30 approval gates. Express trims the ceremony, but not for “ambiguous, cross-team, regulated, or architecture-heavy work.” It suits you less if you want to hand over a plan and walk away.
Where the Enso Method made a different call
Both methods define the whole piece of work before any code, trace every requirement to evidence, and forbid weakening a test or target to get to green. They part ways on three things.
When the build waits for a person
AWS AI-DLC
Every stage ends at a human approval, and “AUTONOMY IS NEVER INFERRED”. In construction, routine checkpoints can pass on their own; plans and failures still wait for you.
The Enso Method
No stage waits for sign-off. Business questions get a researched proposal and a confidence level, and the build continues while their owners confirm or correct them.
Choose by situation: if a decision must be approved before anything is built on it, AI-DLC’s gates are the point. If the deciders can’t sit with the build, and redoing a corrected assumption costs minutes, the Enso Method keeps it moving.
Who answers the questions
AWS AI-DLC
Each stage writes its questions to a file with lettered options, won’t go on with partial answers, and says “Default to asking, not assuming.”
The Enso Method
The agent researches each question against the real code, data and APIs and picks the best answer; it asks only when the evidence favors no option.
Choose by situation: AI-DLC keeps every design choice yours. The Enso Method brings you only what research can’t settle.
What the documents are for
AWS AI-DLC
Each piece of work keeps its own record of questions, answers and approvals; a shared map of the codebase and the team’s practices carry forward.
The Enso Method
One set of requirements and design per area, amended before every change, so it always says what the system should do now.
Choose by situation: AI-DLC’s record answers “who approved this, and when?” The Enso Method’s answers “what is this system supposed to do?”
Where AWS AI-DLC shines
- Quality designed in. Performance, security, reliability and observability are designed in stages of their own, with numbered targets checked at build time. The Enso Method has no such stages; this is a real gap in ours.
- It goes past the code. Deployment, environments, monitoring, incident runbooks and load testing are part of the method. The Enso Method stops at a reviewed commit.
- A record an auditor can read, kept by a workflow engine that won’t let a gate be skipped. The Enso Method keeps no equivalent.
- Sized to the work. Eleven profiles, from a one-line bug fix to a regulated initiative, in seven agent tools to the Enso Method’s two.
How the Enso Method differs, and why
AWS AI-DLC and the Enso Method both want the people who decide involved; they differ on when. AI-DLC asks them at every stage, and nothing moves on until they approve. The Enso Method lets the build run ahead on researched proposals, each with a stated confidence, and gathers their confirmations and corrections afterwards, on their schedule rather than the build’s.
Get started
AI-DLC is free and open source (MIT No Attribution) and runs in Claude Code, Kiro, Codex, Cursor, opencode and GitHub Copilot. Install it with its native installer and aidlc config; instructions are in the README at github.com/awslabs/aidlc-workflows.