What Is the AI-Driven Development Lifecycle (AI-DLC)? Phases, Principles & Best Practices

Autonomous agents now open 48% of pull requests at the companies furthest along with AI, according to Jellyfish data from more than 1,000 organizations. AI agents write the code, open the PR, and wait for a human to look at it.

The share of pull requests opened by autonomous agents, by percentile. The p90 line reached 48% by mid-2026, up from close to zero eighteen months earlier.

But the process around them has barely moved. Sprint planning, backlog grooming, and review queues still run on a cadence teams set back when people wrote every line themselves.

AWS took a swing at the problem in 2025 with AI-DLC. The AI-driven development lifecycle gives AI the work across planning, design, build, and operations, and it holds humans responsible for context, validation, and the decisions that carry weight.

This guide explains how AI-DLC works, where it departs from traditional models, and what it asks of engineering teams.

What Is the AI-Driven Development Lifecycle (AI-DLC)?

AI-DLC is a software development methodology where AI leads execution, and humans hold decision rights. The AI produces requirements, proposes architecture, writes code, and generates tests. People supply business context, answer the AI’s questions, and approve the work before it moves forward.

AWS introduced the methodology in July 2025 and open-sourced the workflow definitions later that year. To explain what makes it different, AWS positions AI-DLC against two approaches teams already know:

1. AI-assisted development: In a typical AI-assisted workflow, the developer still directs the process. They decide what needs to happen, ask AI for help with individual tasks, and review the output. AI may speed up parts of the work, but the surrounding development process largely stays intact.
2. AI-autonomous development: AI owns the whole chain from prompt to application, including the decisions a person should be making. Teams that work this way find the wrong assumptions late, usually in production, and usually in the parts of the domain that were never documented.

AI-DLC claims the ground between them. AI leads the work across the full software development lifecycle, and humans keep authority over context and every consequential decision.

AI-DLC occupies the middle ground, with AI leading execution and humans holding decision rights.

That difference is easiest to see in how work starts. A team gives the AI a statement of business intent, and the sequence goes like this:

• The AI breaks the intent into a plan and comes back with questions about edge cases, existing integrations, and the rules nobody documented.
• The team answers and hands over context the AI has no way to infer.
• The AI executes the step it proposed.
• The team validates the output before the next step starts.

Step one does the heavy lifting. AWS built the methodology around the premise that people hold the business context, so the AI stops and asks for it. Teams that run this well find their ambiguities on day one, in a room, before anyone writes code.

Persistent context is the other half of the model. AI-DLC stores plans, requirements, and design artifacts as work moves through each phase, so an architecture decision made on Monday reaches the agent writing code on Wednesday. Traditional lifecycles scatter that context across tickets, wikis, and Slack threads, where most of it goes stale inside a sprint.

How Does AI-DLC Differ From the Traditional SDLC?

Agile’s rituals exist for a reason. Sprint planning, backlog grooming, and standups batch work into chunks big enough to justify the coordination around them.

Human attention is expensive, and handoffs are slow, so teams group work to keep the overhead per unit low. Two weeks became the default because it balanced planning cost against the risk of building the wrong thing for too long.

Agents break that logic. An agent can move from requirements to architecture proposals and tests far faster than teams could produce each artifact manually. The batch no longer saves anyone time, so AI-DLC drops it and rebuilds the lifecycle around a much smaller unit of work.

Here is how the two models compare across different parts of delivery:

The vocabulary follows the model. Once a cycle takes hours, calling it a sprint stops making sense, so AWS calls it a bolt. Epics give way to units of work, each one a self-contained deliverable the AI carves out of a single intent.

Mob Elaboration covers the ground grooming used to, and then some. The AI drafts requirements, stories, and units of work from a business intent, and the whole team validates its questions in one live session.

One caveat worth mentioning ❗ → AI-DLC does not ask teams to abandon the principles behind Agile. Short feedback loops, frequent validation, and working software all survive. What changes is the container around them, since execution cycles compress and the workflow adapts to the complexity of the task.

Core Principles of the AI-DLC Framework

AI-DLC comes down to four principles. Teams that adopt the vocabulary without them end up with a renamed sprint, which defeats the point. The principles determine whether the shorter cycle produces working software or a faster path to rework.

1. The workflow adapts to the work: AI-DLC has no fixed sequence. Each phase decides how deep to go based on the complexity in front of it, and the AI returns an execution plan showing which stages it will run, which it will skip, and why. A small backend service might skip user stories and NFR design entirely.
2. AI proposes, humans decide: Every consequential step stops at a checkpoint. The AI presents a plan, the team approves or redirects it, and execution starts after that. These checkpoints keep human judgment in the loop as AI takes on more of the work.
3. Specs move with the work: Plans, requirements, and design artifacts reconcile against the codebase at every phase. The AI reads from them before it acts and writes back to them once a step clears. The spec stays accurate long after the sprint that produced it.
4. Quality checks never stop: Agents write tests, audit security, and review code while the work happens. Every unit clears a gate on its way through, so nothing waits for a testing phase that arrives two weeks later.

What this asks of a team → All four principles concentrate on the same group of people. Engineers who used to write first drafts now set context, approve plans, and validate output. That work carries more leverage per hour, and teams that plan for it deliberately get more out of AI-DLC than teams that let it happen by accident.

The Three Phases of Software Development in AI-DLC

AI-DLC organizes work into three phases, and each one hands the next a set of artifacts. Read them with different expectations, though, since Inception is thoroughly specified and the Operations phase is barely sketched.

Business intent enters at the Inception phase, work moves through three phases, and production feedback returns to the context every phase reads from. AWS still marks Operations as evolving, shown here with a dashed border.

Inception turns a one-line intent into units of work. The AI reads the workspace, works out whether it faces a new project or an existing codebase, and comes back with clarifying questions in multiple-choice form. The team answers them together in a Mob Elaboration session, with product, engineering, security, and operations reacting to the AI’s proposals live. The phase ends with requirements, user stories, acceptance criteria, and a decomposition into units of work that each carry their own dependencies.

Example 🔎 → A team states the intent as “let customers submit warranty claims online.” The AI returns questions about warranty validation rules, supported document formats, notification channels, and data retention, then decomposes the product into units like customer identity, claim submission, document upload, and admin dashboard.

Construction handles one unit at a time, and the plan changes with the work. The AI proposes which stages to run and which to skip, with a reason attached to each decision, so a simple backend service skips the stages a complex system would need. The team approves the plan, and the AI designs the APIs, domain entities, and validation rules for the first unit, then writes the code. Checkpoints along the way are where a team catches what the AI assumed about the domain.

Example 🔎 → The team picks claim submission for the first bolt. The AI proposes a state machine for claim status, a storage model, validation rules, and error handling. The team rejects its first pass at the rejection flow. A denied claim can be appealed twice, and nobody had written that down anywhere.

Operations is the least developed of the three. The AI applies context from the first two phases to manage infrastructure as code, monitor deployments, and track system health, and no autonomous change reaches production without human oversight. That is the design. AWS marks the phase as evolving in its own repository, and the documentation gives teams much less to work with here. Expect to fill in the operational practices yourself.

Example 🔎 → Once claim submission runs in production, timeout errors on document upload feed back into the context store. The next inception cycle starts with that failure already documented, so the AI accounts for large-file handling when it plans the next unit of work.

What makes it a lifecycle: The three phases close into a loop. What production teaches the system flows back into the context store, so the fourth bolt against a service starts with the failures from the first three already documented. Each cycle costs less to plan than the one before it.

Where Spec-Driven Development Fits into AI-DLC

Spec-driven development means giving an agent structured intent before it writes any code. The work typically follows a structured sequence:

• Requirements state what the system does, written as testable statements.
• Design covers the architecture, data model, and interfaces the implementation follows.
• Tasks break the work into pieces the agent executes one at a time.

Vibe coding works the other way. A developer prompts loosely, the agent infers what it can, and the gaps get filled with whatever the model considers reasonable.

That kind of structured context fits naturally into AI-DLC. Inception hands over requirements, user stories, acceptance criteria, and units of work, and Construction checks its output against them at every gate.

The difference in one line → Spec-driven development is a technique for telling an agent what to build. AI-DLC is a methodology for organizing the whole lifecycle around that kind of structured context, including who validates it, when AI-powered execution stops for approval, and how the specification stays accurate as the system changes.

Where to start → Spec-driven development fits inside an existing process. A team can adopt it this quarter without changing how it plans, staffs, or reviews anything. AI-DLC asks for all three, which makes specs the lower-risk entry point and the fastest way to find out whether a team can write intent an agent handles well.

The Core Benefits of the AI-DLC Methodology

Four benefits come up in most accounts of AI-DLC. They are worth taking separately, since the evidence is stronger for some than others:

• Cycle time compresses, but only with the practice change: AWS studied more than 50 internal teams and found that the 25 that changed both their tooling and their working practices outperformed the ones that added AI to an existing workflow. In structured pilots at Amazon Stores, run by ordinary teams against their regular backlogs, the median productivity gain reached 4.5x, with some teams above 10x. Worth noting who published that and what it covers, since AWS measured AI-native development broadly and has an obvious stake in the result. The independent read looks similar, since Jellyfish data across 1,000+ companies puts top-quartile adopters at 1.7x the PR throughput of low adopters.
• Unclear requirements come out at the start: Traditional planning splits them across grooming, refinement, and design review, with days of waiting between each. AI-DLC compresses that into Mob Elaboration, where the AI reports what it cannot determine on its own and the team answers with product, engineering, security, and operations all present. The same questions get answered in any project. This handles them before implementation starts.
• Traceability comes as a by-product: Every clarifying question, answer, and architectural decision gets written into an artifact, since the process depends on those artifacts to work at all. A team can explain why a validation rule exists and who approved it without digging through Slack. Regulated environments get the most from this, because the audit trail usually gets assembled after the fact by someone reading old tickets.
• Developers spend their time differently: Boilerplate, test scaffolding, and syntax work move to the agent, which leaves architecture, domain reasoning, and validation for people. That work carries more leverage per hour and takes more out of a person, so review capacity becomes something a team has to plan around.

What the numbers do not cover → The largest figures above come from AWS or from teams AWS selected, and early adopters self-select for strong engineering practice. No independent study has measured AI-DLC outcomes at scale. Any team piloting the methodology will need its own baseline to know whether the benefits arrived.

Risks and Limitations of AI-DLC

Every risk below traces to the same thing, which is a process that produces work faster than a team can check it. That is also the point of the methodology, so the risks arrive alongside the benefits.

• Approval decays into rubber-stamping: The validation gate holds for the first few bolts. Then approvals get faster, the execution plans start looking similar, and eventually someone clicks through a plan they skimmed. AWS made the checkpoints mandatory partly to prevent this. The gate only works when someone reads what they are approving, and nothing in the process enforces that.
• The bottleneck moves to review. Agents produce faster than people validate, so the constraint moves from writing code to checking it. Jellyfish research puts AI-assisted pull requests at roughly 18% larger than human-written ones, with the extra volume coming from more verbose code covering the same functionality. Reviewers read more to approve the same amount of change. A team that adopts AI-DLC without planning for review capacity moves its queue downstream and leaves the total unchanged.
• A wrong specification scales: A bad requirement in a traditional lifecycle produces one bad feature. In AI-DLC, the AI decomposes that requirement into units of work and builds against it consistently, so a single wrong assumption reaches every piece of work derived from it. The error also happens earlier, at the point where correcting it costs the most.
• Cost tracks agent activity: Token spend scales with the thing the methodology is designed to increase. Teams running multiple agents in parallel across a full lifecycle face a bill that grows with adoption, and most engineering organizations have no established way to attribute that spend to a team, a project, or an outcome.

Why measurement carries more weight here → Most of these risks accumulate gradually and never produce a single obvious incident. Without instrumentation, a team notices them late, usually through longer reviews, rising AI spend, or delivery metrics moving the wrong way.

How Should Engineering Leaders Measure AI-DLC Performance?

AI-DLC makes engineering activity easy to inflate. Agents generate more code, open more pull requests, and consume more tokens without moving delivery at all. What a leader needs to know is whether the extra execution reached customers.

Four groups of signals give a clearer read:

1. Adoption and contribution: Who uses AI, how often, what share of shipped work involves it, and how much comes from autonomous agents.
2. Delivery performance: Throughput, cycle time, merge rate, and how quickly work moves from intent to production.
3. Quality and review burden: Review time, reverted PRs, code churn, and whether faster generation creates a longer queue downstream.
4. Cost: Seat licenses, token usage, and agent spend measured against the outcomes they produce.

Jellyfish is built for this reading. A leader asking whether AI-DLC worked needs adoption depth, agent contribution, delivery outcomes, and cost read against each other, and those four come from four different systems.

AI Impact pulls them into one view. The platform separates access from depth, tracks what autonomous agents contributed to merged code, attributes token spend, and measures all of it against throughput and revert rate. The pairing is the point, since both numbers climb as adoption deepens and only one of them counts as good news.

Jellyfish AI Impact brings AI adoption, delivery speed, throughput, and developer sentiment into one dashboard.

What changes in measurement → AI activity becomes an input. The outcome is whether AI-DLC improves delivery speed, quality, cost, and developer capacity, or whether it moves the bottleneck somewhere else and leaves the total where it was.

When and How to Transition to AI-DLC

No organization flips from Agile to AI-DLC in a quarter. The methodology depends on conditions most teams have to build first, and the order of that build decides whether a pilot produces anything.

Start with four questions about the conditions already in place:

• Can an agent trust your tests? Continuous verification only works with automated coverage mature enough that a passing suite means something.
• Is the domain complex enough to be worth the ceremony? AI-DLC pays off when a system carries business rules an agent cannot infer. Simple systems get the overhead without the payoff.
• Does anyone need the audit trail? Regulated environments get the traceability free, which changes the cost-benefit considerably.
• Will your team read the plans? Every checkpoint depends on someone doing the reading, and teams that rubber-stamp code review will rubber-stamp this.

The worst candidates for a first pilot are legacy monoliths without automated tests and teams where review is already a formality. Both can get there, but both need the foundations first, and the methodology will not build them.

Assuming those conditions hold, the sequence usually goes like this:

1. Start with spec-driven development. Teams practice writing intent an agent can execute before anyone gives an agent autonomy. Nothing structural changes, and a team finds out quickly whether it can state what it wants.
2. Build agent context before writing production code. Steering files, coding conventions, testing standards, and a repository an agent can reason over. AWS found this step separated the teams that saw gains from the teams that did not, and it takes weeks.
3. Pilot on one bounded project. A single service or an internal tool, with a small team given explicit permission to restructure how they work. A pilot that keeps the existing rituals tests the tooling and nothing else.
4. Change the human role deliberately. Engineers need coaching to stop writing first drafts and start questioning what the agent proposes. Most teams underestimate how long this takes.

Expect the first weeks to feel slower → Teams in AWS’s study consistently produced less at the start while they built steering files, restructured repositories, and worked out what the models handle well. That work has no output of its own. Set the evaluation window long enough to cover it, and record the baseline numbers before the pilot begins.

PRO TIP 💡: Step three depends on knowing what step two produced. Enablement Insights shows which engineers get the most from AI and what they do differently, which is how a team works out which practices from the pilot are worth spreading.

What AI-DLC Means for Engineering Leadership

AI-DLC reaches past the development process into how teams are built, staffed, and governed. Five decisions come with it, and each one changes what a leader is responsible for.

Where ISO 42001 and NIST fit → Neither defines AI-DLC. ISO/IEC 42001 is an AI management system standard for responsible development and use. NIST’s AI Risk Management Framework is voluntary and built around Govern, Map, Measure, and Manage. AI-DLC covers how AI participates in delivery. Those frameworks cover how an organization controls and documents that participation, which is where AWS’s guidance stops.

AI-DLC Tools and Implementation Options

AI-DLC is a methodology, not a product. AWS open-sourced the workflow definitions as markdown files describing stages, gates, and execution logic, and the workflow can be implemented across multiple coding agents and IDEs that support project-level instructions or rules.

That said, the AWS-native path has changed, and a team evaluating tooling now needs to know which direction it moved.

• Kiro is now AWS’s preferred path for new users. It is built around executable specs, which makes spec-driven development part of the tool’s default working model instead of a discipline a team has to maintain on its own.
• Amazon Q Developer was the original reference implementation and is on its way out. New signups closed in May 2026, and IDE plugins and paid subscriptions reach end of support on April 30, 2027. AWS points existing users toward Kiro as the transition target.
• Claude Code, Cursor, Cline, GitHub Copilot, and OpenAI Codex all have documented implementation paths in the awslabs workflows repository. A team can pilot AI-DLC without changing vendors, which lowers the cost of finding out whether the methodology suits them.

What tool support does not cover → Running the workflow files means an agent can execute the stages. The human checkpoints stay a process discipline, and no tool enforces that someone read the plan before approving it. The methodology depends on that reading, and the tooling has no opinion about whether it happened.

PRO TIP 💡: Every AI vendor reports favorably on its own usage, which makes an honest comparison hard for a team running three of them. Multi-tool comparison measures Kiro, Claude Code, Cursor, and the rest on one vendor-neutral model. Jellyfish integrates directly with Kiro, so teams on the AWS-native path get adoption and impact data without extra setup.

Maintaining Visibility and Control in the AI-DLC Era

AI-DLC moves execution to agents and decisions to people. Those decisions only hold up when the people making them can see what agents produced, what the work cost, and whether delivery improved. And that visibility does not come with the methodology.

Jellyfish is a software engineering intelligence platform that measures how AI tools, version control activity, and planning data connect to what a team ships. Its AI Impact capabilities cover the specific questions AI-DLC raises, from who adopted what through to whether agent output reached production.

Here are the six that apply:

• Adoption insights answer the first readiness question, which is whether a team adopted AI-DLC or installed the tooling around it. System signals identify who uses AI, where, how, and with which tool, so the picture comes from behavior.
• Impact insights connect AI usage to throughput, quality, and delivery speed. The measurements come from SDLC signals, not vendor reporting. A team can compare its delivery numbers before and after a pilot on the same basis.

• AI workflow insights measure the flow of work across a team’s process. It combines agent performance data with system signals and developer feedback, which covers both what the tooling did and what the people absorbing it experienced.
• AI token spend dashboard attributes token usage and spend across tools, teams, and initiatives. Most organizations have a single monthly figure and no breakdown. This turns cost into a metric a team can compare against what it delivered.

• Multi-tool comparison benchmarks every AI tool a team runs against the same set of measurements. That applies to AI-DLC directly, since the methodology is tool-agnostic and most teams will evaluate more than one option.
• Enablement insights cover what separates a team’s power users from everyone else, along with the gaps holding others back. Scaling a pilot depends on knowing which practices produced the result.

Whether a team adopts AI-DLC wholesale or takes pieces of it, the measurement question stays the same. Book a demo to see how Jellyfish answers it for your organization.

FAQs

Does AI-DLC work for existing legacy applications or only new projects?

Both, though brownfield systems ask more of the team. Greenfield is easier, since the AI proposes an architecture with no history to respect and no undocumented decisions to work around.

On an existing codebase, Inception does the heavy lifting. The AI analyzes the workspace and asks about constraints the code does not explain, which forces tribal knowledge into writing. Mature CI/CD pipelines matter more here than on a new project, because continuous verification needs a test suite an agent can trust before it changes anything.

Two conditions decide the outcome. Automated test coverage strong enough to rely on, and steering documents carrying the architectural context nobody wrote down. Teams that skip both find the AI builds around existing technical debt and adds to it.

Is AI-DLC the same as AIDDLC or AI-SDLC?

No, and the naming has fragmented fast. AWS uses AI-DLC for the three-phase methodology this guide covers.

A separate initiative uses AIDDLC for an AI-Driven Development Lifecycle Standard with seven phases, which is a different framework. Microsoft describes an AI-led SDLC, and IBM applies AI-DLC to a broader enterprise operating model.

The terms all describe the same general direction, which is generative AI and agentic AI taking a larger role across software delivery. They differ on structure, phase count, and how much autonomy an agent gets. Check which one a source means before you compare them.

What happens during Mob Construction?

Mob Construction is the working session in the construction phase where the team validates what the AI produces for a single unit of work. The AI proposes a logical architecture, domain model, and interfaces, then moves to code generation once the team approves the design.

The human-in-the-loop structure is what separates this from an agent working alone. Engineers check that the AI followed the organization’s design patterns, caught the business rules it could not infer, and produced something the team wants to maintain. Quality gates apply at each step, with the AI writing tests and auditing security as the work happens.

How does AI-DLC change developer experience?

The daily work looks different. Boilerplate, test scaffolding, and syntax work move to the agent, which leaves requirements analysis, architecture, and validation for people. Many developers prefer that split, since the remaining work is the part most of them find interesting.

The trade-offs are also there, though. Judgment work takes more sustained attention than typing does, and developer experience suffers when review capacity gets treated as unlimited.

A risk assessment before a pilot should cover this alongside the technical prerequisites. Teams that plan for review load protect the gains. Teams that ignore it end up with a queue nobody can clear.