What Is AI-DLC,

Key Takeaways

• AI-DLC is a software delivery methodology created by AWS.

• Adding AI as an assistant to an unchanged sprint process caps what AI can deliver. The lifecycle itself has to change.

• The current official version, AI-DLC Workflows, has five phases and 33 stages: Initialization, Ideation, Inception, Construction, and Operation.

• Mob Elaboration and Mob Construction replace long handoff chains with live, cross-functional review.

• Work happens in short bolts, measured in hours or days, instead of two-week sprints.

• Humans decide and AI executes. Every stage a project runs ends with an approval gate, except the automatic setup stages in Initialization.

• The open-source workflows run in Kiro, Amazon's agentic IDE, and in other coding tools, including Claude Code, Cursor, and GitHub Copilot.

Most teams already use AI to write code. However, far fewer have changed how work moves from idea to production.

AI-DLC, the AI-Driven Development Lifecycle, is a software delivery methodology created by AWS. The usual fix is to add AI assistants to the same sprint process. That's the wrong fix. AI-DLC rebuilds the lifecycle around AI agents and people working together. AI does more of the work. People make the decisions.

Why does AI-DLC start with the process instead of the tools?

Agile sprints were built for a world where writing code was the slow part. It isn't anymore. AI agents can now draft requirements, propose architecture, and generate code and tests in a fraction of the time those steps used to take.

The process around the code hasn't kept up. In the enterprise work I see, a lot of the delay is waiting. Teams wait for approvals, for process reviews, and for a specialist to become available to weigh in on a decision.

Waterfall and Agile Scrum were both designed for people working with people. When they became standard, no automation could work across disciplines, so teams organized around specialist silos and sequential handoffs. Those handoffs and reviews are where time goes.

AI-DLC starts from that problem. If you add AI as an assistant to an unchanged, human-driven process, you cap what AI can deliver. The handoffs stay, the reviews stay, and the gains stay small. To get more, the lifecycle itself has to change.

How did AI in software development get here?

The way I see it, teams have moved through a few shifts in how they work with AI.

Early on, developers mostly used web-based chatbots. They copied prompts and code back and forth between a browser window and their development environment.

Then AI moved into the development environment. Teams added vector databases for context, agents that could call tools, and extra system instructions and prompts. That cut down on copying and pasting, but each tool still worked inside a narrow slice of the job.

AI-DLC is built for what comes next. Agents can work across domain boundaries, with less interface friction, and quality standards still have to hold. That kind of agent needs a lifecycle designed for it, instead of one designed for handoffs between specialists.

What are the three pillars of AI-DLC?

When I explain AI-DLC, I start with three pillars.

Process. This is the methodology itself. It reorganizes the phases, artifacts, and flow of software work from the first statement of intent through production deployment.

Tooling and environment. The methodology needs tools that can carry context across tasks and serve different roles on a team. The current open-source version runs in several coding tools, including Kiro, Amazon's agentic integrated development environment (IDE).

Organizational adoption. This one is about how your team changes the way it works, including how you structure the team when you put AI-DLC into practice.

What is the partner model in AI-DLC?

The core of AI-DLC is a shift from treating AI as an assistant to treating it as a partner.

Earlier AI tools were technically capable but worked in isolation. They knew nothing about the business, the product, or the decisions the team had already made.

In the partner model, AI takes an active role in the work. It breaks tasks down, makes suggestions, and builds alongside the team.

Partner doesn't mean equal authority. You keep strategic control. AI plans, asks for clarification, and does the work. You approve it at set checkpoints. Humans decide and AI executes, and that split runs through the whole methodology.

What are the five phases of AI-DLC?

If you look up AI-DLC today, the official version is AI-DLC Workflows, an open-source project AWS Labs publishes on GitHub. Its v2 guide, current as of the latest stable release (v2.11.3, published November 4, 2026), organizes the lifecycle into five phases: Initialization, Ideation, Inception, Construction, and Operation. Those five phases contain 33 stages.

Each phase builds on what the last one validated, so work doesn't restart from scratch when it moves to the next phase.

The current official version of AI-DLC has five phases and 33 stages. A verification gate sits between Ideation and Inception, between Inception and Construction, and between Construction and Operation.

Initialization: how does the work get set up?

Initialization sets up the workspace and the record of the work. Its three stages run automatically and have no approval gates.

Ideation: is this worth building?

Ideation is where you validate the initiative before requirements work starts. Its seven stages run from capturing the intent to approval and handoff. Along the way, the team defines scope and, where the work calls for it, checks feasibility and sketches rough mockups.

Inception: what are we building and why?

Inception elaborates the requirements. Its nine stages include user stories, domain design, breaking the work into units, and delivery planning. When you're changing a system that already exists, Inception starts by reverse engineering the existing code.

The point is to work out how to design a product that delivers real benefits to users before anyone builds it. That keeps the code generated later tied to business goals you've already checked.

Construction: how will technology solve it?

Construction builds the solution in seven stages. The first five repeat for each unit of work: Functional Design, NFR Requirements, NFR Design, Infrastructure Design, and Code Generation. NFR is short for nonfunctional requirements, like performance, security, and scalability. Build and Test and CI Pipeline then run once for the whole solution.

Because each unit's design work comes before its code, the AI isn't generating code without direction. That's the difference I see between AI-DLC and ad-hoc AI coding, which tends to produce brittle results.

Operation: how does it get deployed and run?

Operation takes the work from deployment through feedback. Its seven stages cover the deployment pipeline and environments, the deployment itself, monitoring, incident response, performance validation, and a feedback step that loops back to Ideation. Every Operation stage is conditional.

How the phases connect

You'll find a verification gate between Ideation and Inception, between Inception and Construction, and between Construction and Operation. It checks that the work from one phase is complete and still connects, for example that every requirement maps to a story, before the next phase builds on it.

Not every project runs every stage. The scope you pick decides what runs. Enterprise and feature work runs all seven Ideation stages, for example. A minimum viable product or a proof of concept runs only part of Ideation and may skip Operation entirely.

Why some sources describe three phases

You may still see AI-DLC described with three phases: Inception, Construction, and Operations. That's the structure in the July 2025 AWS blog post that introduced the methodology. The current workflows version keeps Inception and Construction, adds Initialization and Ideation in front of them, and calls the last phase Operation.

What is Mob Elaboration?

Mob Elaboration is how AI-DLC handles requirements. It replaces the long chain of documents, reviews, and sign-offs that usually sits between an idea and a backlog.

It starts with a simple statement of intent: what the business wants to achieve. The AI asks questions to fill in the gaps, then drafts requirements, user stories, and units of work.

Then product, engineering, security, and operations review those drafts together, live, in the same session. The team corrects what's wrong, adds what's missing, and rejects what doesn't belong.

The value, for me, is who is in the room. Security and operations weigh in during requirements instead of finding problems after the code is written. Decisions that used to travel through several handoffs get made once, with everyone present.

What is Mob Construction?

Mob Construction applies the same idea to building the software.

The AI proposes the architecture, the code, and the tests. The team reviews each decision in the room, clarifying it or overriding it on the spot.

You know the usual pattern. A developer writes code, opens a pull request, and waits. A reviewer gets to it days later, leaves comments, and the cycle repeats. By then, the context behind the decision has faded for both of them.

In Mob Construction, review happens while the decision is being made, which moves it to the point where it costs the least.

What is a bolt, and how is it different from a sprint?

A bolt is AI-DLC's unit of work cycle. It's short, measured in hours or days instead of the usual two weeks of a sprint.

Each bolt follows the same loop. The AI proposes a plan. People verify and approve it. The agent builds and tests. Then the cycle repeats.

The name signals a real change in pace. A two-week sprint made sense when building was slow and the team needed time to finish a meaningful amount of work. When an agent can build and test in hours, a two-week cycle mostly adds waiting.

Even the vocabulary changes. Sprints become bolts. Epics become units of work. They reflect a process where planning, building, and checking happen in much tighter loops, with a person approving each one.

How does context carry forward between phases?

In a traditional process, context leaks at every handoff. Requirements live in one tool, designs in another, and the reasoning behind decisions in someone's head or a meeting nobody recorded. Each new group starts by rebuilding an understanding the last group already had.

AI-DLC keeps plans and artifacts in the project repository. What you decided in Ideation and Inception is still there in the phases that follow, for both the people and the agents working on it.

With AI in the loop, this matters more, because an agent can only work from the context it has. When requirements, domain models, and architecture decisions sit next to the code, the agent works from the same record the team does. Nothing gets lost in a handoff, because the record doesn't move.

Who makes the decisions in AI-DLC?

People do. AI-DLC hands more of the work to AI, and the authority stays with you.

The AI plans, asks for clarification, and executes. In the current version, every stage ends with an approval gate. The exception is Initialization, whose three setup stages run automatically. A gate put to the team doesn't pass until a person approves it. Teams can let some routine Construction checkpoints pass automatically. However, a failure always stops for a person.

That's what makes this usable for business-critical software. Cycles get faster, and each bolt, each phase, and each major decision still has a human checkpoint.

It also changes what your team spends its time on. Less time goes to writing first drafts of documents and code. More goes to judgment: whether the requirement is right, whether the architecture fits, and whether the result is good enough to ship.

Where does Kiro fit in AI-DLC?

Kiro is Amazon's agentic IDE. The open-source workflows run in more than one tool. The official docs list them as running natively in Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, and GitHub Copilot, and the phases, stages, and gates are the same in each. Kiro is one of them. Your team can run AI-DLC in Kiro or in a coding tool you already use.

What does AI-DLC mean for a team considering it?

The main lesson I take from AI-DLC is that the gap isn't the coding assistant. It's the lifecycle around it.

If you're considering it, start by looking honestly at where work waits today. Coding is rarely the slowest step anymore. In our own work, the bottleneck is usually discovery: recruiting users, running interviews, and agreeing on what to build. AI helps with synthesis, but people still have to do that work.

AI-DLC asks for fewer handoffs and more time in the same room, making decisions together. That's a real change for teams used to passing work between specialists. It needs product, engineering, security, and operations to commit time to joint sessions.

It also rewards teams that do the early work well. For example, on COI Dash, our certificate of insurance product, the team used Figma and AI to prototype concepts quickly before agents wrote much production code. AI-DLC asks for the same order, with what to build settled before the build scales up. The current version can include rough mockups in Ideation, before requirements work starts in Inception.

Where to start

If your team has added AI tools and delivery hasn't changed much, I'd look at the lifecycle before buying another tool. Map where work waits for approvals, reviews, and specialists. Those waits are what AI-DLC is designed to remove.

Sources

• Raja SP, "AI-Driven Development Life Cycle: Reimagining Software Engineering," AWS DevOps & Developer Productivity Blog, July 31, 2025: https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/

• AWS Labs, AI-DLC Workflows documentation: https://awslabs.github.io/aidlc-workflows/

• AWS Labs, AI-DLC Workflows guide, "Phases and Stages" (v2): https://github.com/awslabs/aidlc-workflows/blob/v2/docs/guide/04-phases-and-stages.md

• AWS Labs, aidlc-workflows repository on GitHub: https://github.com/awslabs/aidlc-workflows

• AWS Labs, AI-DLC 2.11.3 release notes, November 4, 2026: https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.3

• Jason Moccia, LinkedIn post on AI-DLC: https://lnkd.in/p/eYxZ5a33