What Is AI-DLC? The AI Delivery Lifecycle for Governed Software Delivery
A Director of Sales hit me with “AI-DLC” last week like I should already know it. I nodded. Then I went and looked it up.
AI-DLC is the term your leadership has started using, and it is worth understanding before you adopt it.
This guide defines AI-DLC, names its AWS origin plainly, and then goes past the acronym to the harder question underneath it: how do you build an AI Delivery Lifecycle that turns intent into dependable production outcomes, with evidence, cost controls, and accountable human decisions at every stage.
It draws on TestGuild podcast conversations with Andy Knight, Matt Wynne, and Jason Arbon, engineers running AI-driven development in production right now.
If you own AI strategy, platform engineering, risk, or quality, the sections on verification and cost are the ones that matter.
What Is AI-DLC?
AI-DLC stands for AI-Driven Development Life Cycle.
It is a methodology that positions AI as the primary executor across the software development lifecycle, with humans acting as validators and decision makers. AWS introduced it publicly in 2025 through a DevOps blog post by Raja SP, then expanded it with a method definition paper, open source adaptive workflow scaffolds, and integration into Amazon Q Developer.
The AWS framing rests on two dimensions.
AI-powered execution with human oversight, where the AI systematically creates work plans, asks clarifying questions, and defers critical decisions to humans. And dynamic team collaboration, where teams shift from isolated work toward real time problem solving as agents absorb routine tasks.
The lifecycle runs in three phases: Inception, Construction, and Operations.
Two things follow from that origin.
AI-DLC is a real methodology with real implementation guidance behind it, and it is an emerging, vendor-originated one whose implementation varies by platform. IBM now presents it as an AWS-coined concept implementable beyond AWS tooling.
Treat the acronym as a useful entry point, not a settled industry standard.
Take the 2027 State of Automation Survey Now
AI-DLC vs. an AI Delivery Lifecycle
AI-DLC is the emerging label for AI-first development. The practical challenge for most enterprises is broader than any one vendor’s method definition: building an AI Delivery Lifecycle that turns intent into dependable production outcomes, with evidence, cost controls, and accountable human decisions at every stage.
The distinction matters because AI-DLC as published concentrates on how work gets executed.
An AI Delivery Lifecycle asks a different question: what has to be true, at each stage, for the organization to stand behind what shipped.
Those overlap, but they are not the same, and the gap between them is where most AI adoption programs are currently struggling.
Matt Wynne, who has been building with agentic AI on real products, described the underlying shift better than any framework document.
“The engineering that we’re doing now is we’re engineering the system that produces the code rather than engineering the code itself.”
Once that is true, the quality of your guardrails determines the quality of everything downstream, and your delivery lifecycle becomes the product.
The Five Stages: Intent, Generate, Verify, Release, Learn
AI now touches every stage of software delivery, not just coding. A useful vendor-independent way to structure it:
Intent
Someone expresses what should be built and why. This is where prompt engineering has given way to intent-based development. The unit of work is no longer an individually authored script but a specification, a set of reusable guardrails, and organization-specific steering files.
Generate
Agentic AI produces requirements, design artifacts, code, and tests. AWS’s own material places code and tests together in Construction, which is correct and important.
Verify
Executable checks, evidence collection, and human review establish whether the generated output is trustworthy enough to proceed. This is the stage every published methodology underspecifies.
Release
Deployment, rollback capability, and the traceability record showing who approved what and on what basis.
Learn
Outcomes feed back into the guardrails, the skills, and the intent layer so the next cycle starts better than the last.
Scripts and automation do not disappear in this model. The claim that they do is too absolute and will not survive contact with anyone running a real suite. What changes is their status: they become governed components inside a larger delivery system rather than the primary artifact engineers hand-author.
Why Verification Is the New Constraint
Published AI-DLC guidance embeds AI testing.
What it gives teams much less help with is the harder question: what evidence is sufficient when AI output outpaces human review capacity?
Andy Knight, an engineering manager running this model on a real team, described what actually changes in episode 599 of my Test Automation podcast. “People are spending more time doing reviews and less time like doing the hands-on coding, which is fair because you’re writing spec, the code just happens as a side effect.” His team is shipping its largest releases ever. The constraint moved from authorship to review.
That constraint has a hard ceiling, and Andy named it.
“If you’re trying to push product code at the speed of AI, you can’t have another separate test team doing N plus one sprint automation. Not gonna happen.”
A downstream QA group validating last quarter’s output is mathematically incompatible with agentic coding. His answer is parallel generation: one thread implements product code, another implements unit, integration, and end-to-end tests, and the human reviews spec, code, and tests together as one artifact.
Matt Wynne in episode 596 put the executive version of the question most sharply.
“If we’re going to have the machines generating the code, we can’t be expected to have to read it all. We have to give ourselves tools to allow us to trust that code.” Then the operative question: “I’m not gonna read that code, but I need to ship it to prod. What do I need to know about that code so that I could trust that I could ship it to prod? What are all of the questions I need to ask?”
Three practices are emerging from teams answering it.
Automate the trust questions themselves, since as Matt notes,
“you’d be surprised how many of those checks you could automate with an LLM.”
Run those checks across multiple fresh sessions rather than once, turning non-determinism into a sampling strategy. And use models from different vendors as diverse reviewers, an Anthropic model, a GPT model, and a Gemini model reviewing the same artifact, because they are trained differently and fail differently.
At the far end sits the question Jason Arbon has been raising and finding few takers for.
“How do you test a system that’s smarter than you, that’s deceitful? How do you validate such a system?”
His frustration is telling:
“I can’t find anyone in the testing community that cares enough to talk to me more than ten minutes about this topic.”
But I think it’s the testing problem of our lifetime.” You need not accept the strongest version of that argument to see its practical edge. As agents take on more of the lifecycle, the gap widens between what the system did and what a human can independently confirm it did.
Join our Free Training Sessions
Why AI Does Not Automatically Reduce Delivery Cost
The assumption underwriting most enterprise AI programs is that AI reduces the cost of software delivery. That assumption needs challenging, and the field data is already challenging it.
AI can lower the cost of producing a first draft while raising the cost of operating delivery. Model inference, agent retries, CI capacity, test execution, cloud environments, human supervision, rework, and incident exposure all rise when output volume rises faster than decision quality. Organizations are now hitting token allowances and blocking AI usage mid-quarter, not because the technology failed but because consumption scaled faster than proficiency.
Teams were pushed to adopt before they were ready to use it well, and the bill reflects that.
Test generation is a clear instance. Andy was direct about the failure mode:
“If you just let raw AI go to the hilt, you’re gonna get a lot of good tests, but you’re gonna get some that perhaps aren’t worth it. You have X amount of hours in the day to run your test, X amount of dollars to pay for the compute resources. Do you really need to check that the button is yellow?”
Unconstrained generation converts straight into compute spend and pipeline time with no corresponding business value.
His fix is to codify testing guidance as reusable agent skills so the constraint is baked in on every run rather than re-prompted each time.
The measurement frame worth adopting is cost per trusted change: the combined cost of generation, verification, infrastructure, review, rework, and release incidents, divided by the number of changes that reach production within your quality and risk thresholds. Not cost per generated line. Not cost per agent run. Those metrics reward volume, which is precisely the behavior driving the overrun.
The same discipline applies to velocity.
Define it as time from validated intent to dependable production outcome, bounded by quality, risk, and cost. Any definition that stops at generation speed will report success while delivery gets slower.
The New Buying Committee for AI Delivery
AI is no longer a feature of a testing tool. It runs through planning, construction, verification, deployment, and operations, and that has changed who owns the decision.
Four roles now sit on the same committee, each asking a different question.
- The Chief AI Officer or VP of AI Strategy owns the enterprise operating model, governance, adoption, and AI spend. Their question: how do we scale AI-assisted delivery without scaling unmanaged risk and cost?
- The VP of Engineering or platform engineering lead owns developer workflow, CI/CD, standards, and reliability. Their question: what delivery system lets agents move faster while preserving control and observability?
- The security, risk, or compliance leader owns policy controls, traceability, and approval evidence. Their question: what proof exists that an AI-produced change is safe, compliant, and reversible?
- The quality or test leader owns evidence quality, coverage, test economics, and release confidence. Their question: how does verification keep pace when agents generate more change than people can read?
Those four questions are the same question viewed from four seats.
Testing in this model is not a downstream QA activity. It is the verification and evidence system inside software delivery, and it is what every one of those roles is implicitly asking about.
Three Questions to Ask Before Scaling
- Whose methodology is it, and what does that vendor sell? AI-DLC is AWS-originated and its reference implementation assumes AWS tooling. That does not disqualify it, but adopting a vendor’s method definition without adapting it means inheriting assumptions you did not choose.
- What happens at the checkpoint when review volume exceeds human capacity? Every version of AI-DLC depends on a human validation gate. Ask who has the authority to slow the pipeline, what evidence they need, and what happens when the queue outruns them. If nobody can answer, the gate is decorative.
- What is your evidence standard for shipping something no human fully read? Write it down before you need it. That document, more than any framework, is your actual AI Delivery Lifecycle.
TestGuild’s State of Automation survey has tracked AI adoption in testing from 2 percent in 2018 to more than 72 percent by 2025.
Adoption was never the bottleneck.
Trust is.
Key Things to Remember
- AI-DLC stands for AI-Driven Development Life Cycle, introduced publicly by AWS in 2025 and structured into Inception, Construction, and Operations with human approval gates.
- It is an emerging, vendor-originated methodology whose implementation varies by platform, not a ratified industry standard.
- AI-DLC is the search term. The durable idea is an AI Delivery Lifecycle where intent, generation, verification, release, and learning are governed as one system.
- Published guidance embeds testing but underspecifies the harder question: what evidence is sufficient when AI output outpaces human review capacity.
- Scripts do not disappear. The unit of work shifts from authored scripts toward intent, reusable guardrails, agent skills, executable checks, and evidence of outcome.
- Generate tests in parallel with code. A separate downstream test team cannot keep pace with agentic coding.
- AI can lower the cost of a first draft while raising the cost of operating delivery. Token allowances are being blocked because consumption outran proficiency.
- Measure cost per trusted change, not cost per generated line or agent run. Define velocity as time from validated intent to dependable production outcome.
- The buying committee now spans AI strategy, platform engineering, security and risk, and quality, all asking one question from four seats.
- Before scaling, establish whose methodology you are adopting, who can slow the pipeline, and what evidence justifies shipping code no human fully read.
Joe Colantonio is the founder of TestGuild, an industry-leading platform for automation testing and software testing tools. With over 25 years of hands-on experience, he has worked with top enterprise companies, helped develop early test automation tools and frameworks, and runs the largest online automation testing conference, Automation Guild.
Joe is also the author of Automation Awesomeness: 260 Actionable Affirmations To Improve Your QA & Automation Testing Skills and the host of the TestGuild podcast, which he has released weekly since 2014, making it the longest-running podcast dedicated to automation testing. Over the years, he has interviewed top thought leaders in DevOps, AI-driven test automation, and software quality, shaping the conversation in the industry.
With a reach of over 400,000 across his YouTube channel, LinkedIn, email list, and other social channels, Joe’s insights impact thousands of testers and engineers worldwide.
He has worked with some of the top companies in software testing and automation, including Tricentis, Keysight, Applitools, and BrowserStack, as sponsors and partners, helping them connect with the right audience in the automation testing space.
Follow him on LinkedIn or check out more at TestGuild.com.
Related Posts
Your developers are shipping more code than they were a year ago. Probably a lot more. And your test coverage […]
I’ve talked to a lot of people who claim their tool does “agentic testing.” Most of the time it’s a […]
What is Model Context Protocol (MCP) Model Context Protocol (MCP) is an open standard that lets AI agents — Cursor, […]
Look, I’ll be straight with you. I’ve been vibe coding in Cursor for about a year and a half, and […]