What Is AI-DLC? Understanding AWS's Proposed Approach Through Examples
What you’ll learn
- The difference between AI-DLC and similarly abbreviated AI system development lifecycles
- How the original three phases evolved into the five phases in Workflows 2.0
- The order in which people and AI work in the official tutorial
- A four-layer view that separates the method, workflow, public implementation, and organizational controls
- A decision checklist to use before piloting AI-DLC with a team
AI-DLC Lets AI Plan While People Make the Decisions
AI-DLC reorganizes software development around AI while keeping people responsible for critical decisions.
Asking an AI tool to implement a feature does not decide who needs it, what may change, how a person will review it, or how it will be operated. Separating the request into planning, approval, execution, and verification makes the boundary between human judgment and delegated AI work explicit.
By the end of this article, you will have practical criteria for answering “In what order do people and AI work in AI-DLC, and what must be decided before adoption?” in your own context.
Distinguish the AI System Lifecycle from AWS’s AI-Assisted Development Method
The abbreviation AI-DLC has at least two meanings. One is the sequence for planning, training, evaluating, and operating an AI system. The other is a sequence for developing software with AI helping to plan and carry out work. This article covers the latter, the AI-Driven Development Life Cycle introduced by AWS in 2025.[1]
Among the primary sources reviewed for this article through August 29, 2026, I did not identify a public study comparing adoption rates across AI-assisted development methods. I therefore do not describe AWS AI-DLC as the market-share leader. I selected it as a representative example because its official approach, publicly inspectable work process, step-by-step tutorial, and enterprise case can all be examined by a third party.[2][3][4][6]
GitHub Star counts, supported-tool counts, and article counts indicate interest.
They do not establish how many organizations use a method continuously. During adoption, check whether the team can reproduce the workflow and its evidence in its own development process.
The Core Loop Is Plan, Approve, Execute, and Verify
AWS AI-DLC does not place every decision under autonomous AI control. AI creates a plan and questions, people provide business context, AI executes after approval, and people verify the artifacts (saved outputs such as requirements, plans, code, and test results). The loop repeats throughout the lifecycle.[1][2]
A normal chat request such as “add this feature” can move directly into implementation. AI-DLC uses the same loop for requirements, design, implementation, testing, and other activities, and it stores decisions and artifacts in files. This design makes it easier to create an audit trail (a record of who reviewed what and why work proceeded).[3]
Rule files written as headings and lists cannot guarantee security or quality by themselves. Enforceable controls still require permissions, tests, CI (automated checks for changes), and approval procedures that can stop an unsafe or incorrect action.
The Current AI-DLC Adjusts Work from Preparation Through Operations by Project
The method published in 2025 used three stages: planning what to build, building it, and operating it.[1] The currently published AI-DLC Workflows 2.0 defines 33 work stages across preparation, idea development, requirements planning, construction, and operation.[4][5]
| Workflows 2.0 phase | Question | Main work supported by AI | Decisions owned by people |
|---|---|---|---|
| Initialization (preparation) | Where should work begin? | Prepare the storage location AI will use and a record of progress | Confirm that the starting location and target are correct |
| Ideation (idea development) | Is the initiative valuable and feasible? | Organize the purpose, research, constraints, scope, team, and initial idea | Decide whether to proceed and what is in scope |
| Inception (requirements planning) | What should be built, and why? | Examine the current system and propose required functions, overall structure, and work plan | Decide the purpose, completion conditions, and priorities |
| Construction (building) | How should it be built? | Create the functions, speed and security requirements, code, and tests | Judge the overall structure, constraints, review results, and quality level |
| Operation | How should it be released and maintained? | Support release preparation, monitoring, incident response, performance checks, and improvement | Decide whether to release, who can operate it, and how to restore the earlier state after a problem |
Not every project passes through every stage at the same depth. The public workflow examines whether a codebase exists, the type of request, and complexity, then proposes the stages and depth that add value. A small defect and a new service do not need the same amount of design documentation. This is the purpose of the Adaptive Workflow.[2][4][5]
The Official Tutorial Moves to Implementation After Requirements Are Agreed
The 2025 official AWS tutorial uses a new web application for solving a river-crossing puzzle. The simple subject keeps the focus on the AI-DLC workflow instead of application-specific technology.[3] The tutorial covers the original three-phase workflow, but Workflows 2.0 retains the core loop in which AI plans and people approve.[4]
Turn a Short Request into Buildable Work During Inception
The initial request only asks AI-DLC to build the puzzle application. The workflow recognizes that no existing code is present, classifies the project as greenfield, skips reverse engineering, and moves to requirements analysis.[3]
AI asks which puzzle variant to use, how interaction should work, whether scores should persist, and whether the application needs a leaderboard. After people answer, AI checks for contradictions and missing answers and proposes the stages to run next. It can skip user-story creation when the application is simple enough.
AI converts ambiguity into choices that people can evaluate. Inception produces agreed requirements, acceptance criteria, and an execution plan before code.
Review the Plan Before Generating Code During Construction
During Construction, AI creates a code-generation plan covering business calculations and decisions, connections to outside services, data, tests, documentation, and release files. The plan is stored as a Markdown checklist, using a simple text format for headings and lists. Implementation begins after a person edits or approves it.[3]
The completed code is therefore not the first review surface. A reviewer can separately examine what AI intends to build and what it eventually built. Finding a misunderstood requirement before implementation is the reason for keeping this planning step.
Check the Version Before Evaluating Operation
The initial public workflow left release and monitoring as future work. Workflows 2.0 now defines seven Operation stages: automated steps to release, preparation of the operating environment, release execution, visibility into current operation, incident response, performance checks, and improvement based on results.[4][5]
Defining those stages does not make a particular organization’s live environment safe by itself. A team must confirm its version and implementation scope and connect the workflow to its automated tests and release process, monitoring, incident response, and change approval.
The Altisource Case Connects Existing Code, Work Items, and Design Materials
An AWS customer case reports that Altisource connected Amazon Q Developer to Jira, Bitbucket, Figma, and database servers, then formalized an AI-DLC that could refer to existing code, project information, and design documents. Developers used it to analyze whole applications, document processing rules, and propose changes spanning the screens users see and the processing behind them.[6]
The case illustrates why the value of AI-DLC is not determined by code generation alone. It connects existing-system constraints, design material, and work items to a shared context that can support planning and review.
The case also reports updates to more than 350,000 lines of legacy Java code and changes in productivity and vulnerability counts. This is an AWS-published customer case, not an independent study isolating the effect of AI-DLC.[6] A team should not assume the same outcomes. It should define metrics and comparison conditions before starting a pilot.
Separate AI-DLC Method, Workflow, Public Implementation, and Organizational Controls
This article separates AI-DLC into four layers. This is an author-created classification, not an official AWS model. Its purpose is to prevent the method from being confused with a product feature.
| Layer | What to examine | Adoption question |
|---|---|---|
| Method | AI plans and executes; people decide and verify | Can the team define where human judgment is required? |
| Work process | Five stages, work performed only under certain conditions, and work units | Can the team vary the amount of checking by type of project? |
| Published instructions | Rule files, documents created during work, and supported stages | Can the team’s chosen AI follow the same process? |
| Organizational management | Access permissions, automatic checks, human review, records, and maintainers | Can the organization test an AI proposal and stop execution when necessary? |
Adopting only the public implementation can produce ceremonial approvals if acceptance criteria and ownership are missing. Conversely, a team with an effective development process may adopt only part of the method, such as stronger requirement questions and pre-implementation planning.
Limit the Scope for Small Fixes and Incident Response
AI-DLC is well suited to uncertain feature work, changes that require analysis of an existing system, and projects that connect decisions across several roles. Applying every stage can cost more than it returns under the following conditions:
- A small change has a known location and a clear correct result
- Immediate recovery takes priority during an incident
- No automated tests or reviewers are available to verify artifacts
- The permitted scope for confidential information has not been defined
- Operational ownership and release responsibility are unclear
The Adaptive Workflow is designed to omit unnecessary stages, but people remain responsible for deciding what can be omitted. During an incident, the existing response procedure should take priority. A post-incident review can then return relevant decisions to AI-DLC artifacts.
Use This Checklist Before a Pilot
Start with one project with a limited blast radius instead of making AI-DLC an organization-wide standard. If an item below cannot be checked, treat it as prerequisite work for the pilot.
- The business problem and excluded scope fit in one paragraph
- Acceptance criteria exist for functional and nonfunctional requirements
- Reviewers and review time are available for AI-generated plans and artifacts
- Access boundaries are defined for code, tests, design material, and issue data
- Permissions, tests, CI, and review can stop execution
- Metrics and a measurement period are defined before the pilot
- Rollback steps and an accountable owner are identified
- Existing processes can cover stages missing from the public implementation
Do not limit the evaluation to time spent. Track requirement rework, review revisions, test failures, defects, and missing audit records as well. Defining comparison conditions in advance makes it easier to separate the effect of AI-DLC from a tool change or differences between team members.
Summary: Pilot AI-DLC on a Small Project with Human Approval and Verification
AWS AI-DLC is not a mechanism for delegating all software development to AI. AI handles planning, questions, and execution, while people retain business context, approval, verification, and accountability. Workflows 2.0 uses Initialization, Ideation, Inception, Construction, and Operation to connect the decision to begin with post-release feedback.
Public evidence does not establish a number-one AI-driven development framework by adoption rate. AWS AI-DLC is still a useful representative framework because its method, public workflow, official tutorial, and enterprise case are traceable. Before adoption, separate the four layers, check the scope of the public implementation and organizational controls, and measure a small pilot.
The related design of a harness—the rules, procedures, and checks supplied to AI—is covered in What Is Harness Engineering? and The Spec-First Principle.
References
- Amazon Web Services, AI-Driven Development Life Cycle: Reimagining Software Engineering, July 31, 2025
- Amazon Web Services, Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC), November 29, 2025
- Amazon Web Services, Building with AI-DLC using Amazon Q Developer, November 29, 2025
- AWS Labs, AI-DLC — one core, many harnesses, AI-DLC Workflows 2.0
- AWS Labs, Phases and Stages, AI-DLC Workflows 2.0
- Amazon Web Services, Altisource boosts developer productivity by 25% with Amazon Q Developer
For the latest releases and updates, check the official website and official documentation.