The AI-Driven Development Life Cycle Is Not New
AWS gave AI-led software development a name and three phases. Earlier methods arrived with similar promises, and the numbers so far tell a familiar story.
In July 2025 Raja SP, a principal solutions architect at AWS, published the AI-Driven Development Life Cycle, AI-DLC for short. It puts AI at the centre of building software, splits the work into three phases, and replaces sprints with bolts, work cycles measured in hours or days. The post says tasks that took weeks can finish in hours or days. It gives no measured benchmark for that.
Our team went through the research on it this summer, then went further back, to the methods that made the same kind of promise before. AI-DLC is a sensible way to organise the work. It is also the latest in a long line of named methods, and those methods delivered gains that were real, conditional and harder to pin down than their launches suggested. Plan for the same here.
What AI-DLC actually is
AI-DLC is a method, not a product. It has three phases:
- Inception. AI turns a business goal into requirements, stories and units of work, and the team checks them together in a session AWS calls Mob Elaboration.
- Construction. AI proposes the architecture, domain models, code and tests, and the team works through them in Mob Construction.
- Operations. AI uses what the earlier phases produced to manage infrastructure and deployments, with the team overseeing it.
The argument underneath is fair. Today's methods were designed for long processes run by people, and adding AI as an assistant limits what it can do. The question is what happens when that argument meets a real team, and software has run this experiment before.
We have read this story before
Test-driven development
A 2008 study followed four industrial teams at IBM and Microsoft. Pre-release defect density fell by 40 to 90 percent against similar projects, and the teams felt that initial development took 15 to 35 percent longer. A serious gain at a serious price.
A later experiment took the practice apart to see which piece mattered. Writing the test first, the part that gave the method its name, had "no important influence". Working in small, even steps did. The ritual got the credit and the discipline did the work.
Behaviour-driven development
A 2018 survey of 75 practitioners in 26 countries found the method in active use, with real benefits such as better communication between the people involved. It also found the bill: 61 percent said duplication in the specifications makes them hard to extend and change, and 49 percent said it makes the test suites take longer to run. Some teams found parts of their system effectively frozen. A specification you can execute is still something somebody has to maintain.
Model-driven development
In our reading this is the closest relative. You describe the system in a model and a tool generates the code. Swap the tool for a language model and you are most of the way to the Construction phase. A 2008 review of 25 studies of the approach in industry found better quality and both productivity gains and losses, mostly in small studies, and concluded there was too little evidence to generalise.
What the numbers say about AI so far
Google's DORA team surveyed nearly 5,000 technology professionals for its 2025 report. AI adoption now goes with higher delivery throughput, which it did not a year earlier, and it still goes with lower delivery stability. Teams ship more and break more. DORA's explanation is the most useful idea in this debate: AI amplifies whatever a team already is. Without strong automated tests, mature version control and fast feedback, more change turns into more instability. And 30 percent of respondents reported little or no trust in the code AI generates.
The number most people quote comes from METR, which ran a randomised trial in 2025 with 16 experienced open-source developers on 246 real tasks in code they knew.
Do not stop reading there, because METR did not. Its February 2026 update covers 57 developers and more than 800 tasks. Returning developers came out 18 percent faster and new recruits 4 percent faster, and both ranges of uncertainty include no change at all. METR also says the study has become harder to run: more developers will not work without AI, and some held back tasks for that reason. It thinks developers are likely faster now than in early 2025, and calls its own data very weak evidence for how much.
So the slowdown is no longer a headline to repeat. What we take from the first study is narrower and more useful: people who had just been slowed down still felt faster. A team's feeling about AI is not a measurement of it.
Then there is what the code looks like afterwards. GitClear, a company that sells code analytics, looked at 623 million changes from 2023 to 2026:
A trend over a period is not proof of a cause, and a vendor's data deserves a second look. It does point the same way as DORA: more output, less tidying.
What this means if you are paying for software
None of this is a reason to avoid building with AI. We use these tools ourselves. It is a reason to spend your attention on the parts that decide whether they pay.
- Measure before you change anything. How long a change takes to reach users, how often one breaks something, how much gets redone. Without a baseline you only have a feeling, and the METR developers show what that is worth.
- Fix the checks first. Automated tests, version control and quick feedback are what DORA names as the difference. Without them, faster output means faster breakage. We have written about what that costs in review time and in security.
- Keep the steps small. Short cycles are the best idea in AI-DLC, and in our view the part with the oldest evidence behind it.
- Budget for the paperwork. Generated requirements, stories and models need upkeep, as behaviour-driven specifications did. Decide who owns them before there are hundreds.
- Ask your supplier for numbers. Who reads the code before it ships? How do they know AI helped? Who can explain a part of the system when it breaks? We keep a longer list of questions for buyers.
Where we land
AI-DLC is a fair way to organise the work, and its name will not do the work for you. The methods before it paid off where teams kept the discipline, and the upkeep came due either way. The early AI numbers read the same.
Take the small steps and the shared review sessions. Measure what happens. Treat any promise of weeks becoming hours as a claim until your own numbers agree.
If you are planning an app or an AI system and want to talk through how it should be built and checked, tell us what you are trying to do.