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
- The prerequisites and cautions to consider before an AI-DLC pilot
The Roles of People and AI in AI-DLC
AI-DLC is a way of developing software in which AI supports planning and execution while people make decisions at key points. This article covers the AI-Driven Development Life Cycle introduced by AWS in 2025.[1]
For example, asking AI to “add this feature” does not tell it who needs the feature, how much it may change, or what evidence would show that the work is complete.
AI-DLC separates such a request into planning, approval, execution, and verification. AI prepares a plan and questions, a person supplies the purpose and constraints and approves the plan, AI performs the approved work, and a person reviews the resulting artifacts.
Using the official tutorial and an enterprise case, this article explains that flow and the relationship between AI-DLC and an existing development process. It also identifies the assumptions and cautions that affect adoption. It does not provide a rollout plan or detailed adoption procedure.
Distinguish the AI System Lifecycle from AWS’s AI-Assisted Development Method
Understanding AI-DLC requires distinguishing it from the development lifecycle of an AI system itself. The latter concerns the work of producing AI models and systems, including development, evaluation, and operation.[7] AWS AI-DLC instead refers to a way of developing software with AI helping to plan and perform the work.[1]
Among the primary sources reviewed for this article through September 21, 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 phases: Inception for planning and architecture, Construction for design and implementation, and Operations for deployment and monitoring.[1][3] 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.
Account for the Version When Evaluating Operation
The 2025 official tutorial completes its workflow after code generation, build, and testing; it does not demonstrate the specific work of release and monitoring.[3] Workflows 2.0 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. Those connections gave its AI-DLC environment access 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 modernization of more than 350,000 lines of legacy Java code, a productivity increase of up to 25%, and a 54% reduction in code vulnerabilities.[6] This is an AWS-published customer case, not an independent study isolating the effect of AI-DLC. An organization cannot assume the same outcomes; it must first determine whether the way those figures were measured and compared fits its own environment.
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 name the decisions that people retain? |
| 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.
Prerequisites and Cautions for a Pilot
Before trying AI-DLC, an organization needs to distinguish the business problem from the work that is out of scope and decide what the functions, performance, and security must satisfy. Without that foundation, a detailed AI-generated plan still leaves people without a basis for approval or verification.
The information AI may access also changes the adoption decision. Existing code, tests, design material, and work items can provide useful context, but confidential or personal information cannot be exposed without limits. The organization needs to separate the information each AI tool and connected system may read from the operations it may perform.
Human review and enforceable prevention are different controls. In addition to assigning responsibility for reviewing plans and artifacts, the organization needs to connect permissions, tests, CI, change approval, and restoration after a problem to its existing development and operations process. Existing procedures must cover any stages that the public implementation does not support.
Elapsed time alone is not enough to evaluate the result. Requirement rework, review revisions, test failures, defects, and missing audit records also indicate quality and control. No single set of metrics or measurement period fits every project. Unless project size, existing tools, and differences in team experience are accounted for, it is difficult to isolate the effect of AI-DLC.
Summary: AI-DLC Adoption Depends on Designed Human Judgment 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 example because its method, public workflow, official tutorial, and enterprise case can be traced through primary sources.
Adoption therefore depends on more than tool features. An organization needs to connect who approves what, which criteria people use to verify artifacts, and which controls stop a problematic action to its existing development and operations process. Separating the method, workflow, public implementation, and organizational controls makes it easier to judge what must be prepared and which existing procedures should remain in place.
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
- National Institute of Standards and Technology, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, July 26, 2024
For the latest releases and updates, check the official website and official documentation.