Is there still a place for agile in the age of AI-DLC?

The case against agile

For some months now, a thesis has been doing the rounds in development teams: agile has had its day, and AI has made it obsolete. Not all of its arguments are wrong, and they deserve to be taken seriously.

A method built for a different pace

The Agile Manifesto dates back to 2001. It was written for developers who typed every line of code by hand. The sprint itself and its ceremonies (planning, the daily stand-up, the review, then the retrospective) are built around a human tempo. Today, when an AI agent can produce a working increment in a few hours, that work sits idle until the next ritual: the stand-up revisits work that is already done, and the sprint review makes people wait two weeks for a demo that could have happened the same day.

AWS makes the same observation. On 31 July 2025, Raja SP introduced the AI-Driven Development Life Cycle (AI-DLC) on the AWS DevOps blog. He notes that product owners, developers and architects spend most of their time on planning, meetings and rituals rather than on the core of their work. Bolting AI onto these traditional methods as a mere assistant, he concludes, constrains its capabilities and reinforces outdated inefficiencies.

Mastery remains rare

Forrester's figures seem to prove the critics right. According to its report "The State of Agile Development, 2025", 61% of respondents have practised agile for more than five years, yet only 7% of teams have fully mastered its practices.

The same report nonetheless concludes that agile remains relevant: 95% of the professionals surveyed consider it critical to their operations, and generative AI is presented as an opportunity to amplify its impact. Read properly, these figures say something other than the end of agile: most organisations never truly practised it. They mostly adopted its calendar.

What AI-DLC really changes

In this new lifecycle, AI does more than complete code: it drafts the requirements, proposes the architecture, writes the code and the tests, then prepares the infrastructure. The team, for its part, reviews and approves every step.

Three phases, one loop

The lifecycle has three phases: Inception, where business intent becomes detailed requirements; Construction, where the architecture, code and tests are produced; and Operations, where infrastructure and production running are handled. All three phases follow the same five-step loop:

1. A human states an intent.

2. The agent drafts a plan and asks clarifying questions.

3. The human answers, corrects and approves the plan.

4. The agent executes.

5. The human checks the result, and the loop starts again.

AWS thereby avoids two pitfalls: AI confined to simple code completion, and an autonomous agent that nobody controls. Its rule fits in one line: "AI proposes, humans decide".

A new vocabulary

The method renames familiar Scrum concepts. AWS itself gives the first two correspondences below; the other two are our own reading of the method, by analogy.

The same collective approach applies to construction: in "Mob Construction", the team settles the agent's proposals in real time. On a greenfield project, the first bolt can deliver a "Walking Skeleton", the thinnest version of the application that already runs through every layer. AWS has also released an open-source implementation of the method, aidlc-workflows, which runs in Claude Code, Cursor and Kiro, among others.

More code does not mean more delivery

If AI writes code faster, why are companies not shipping faster? The question comes up as soon as an organisation moves from experimentation to real-world deployment. Our reading comes down to one idea: the gain is won across the whole delivery chain, not in writing code. That is why our engagements start with a maturity assessment of the whole lifecycle, before any choice of tool. The figures published in 2025 bear this out:

Both reports point the same way: speeding up code production is not enough; work has to flow through the whole system. That is exactly the problem agile set out to solve.

Related readAI-generated code: why “it works” does not mean “it is maintainable”Coding agents quickly produce code that passes the tests. But code that works is not necessarily healthy code. What research on design smell detection teaches us, and how to keep technical debt under control.Read the article

Rituals go, values stay

The gap between the speed of agents and the cadence of ceremonies cannot be closed by shortening meetings. It calls for rethinking the organisation itself: rituals must follow the real pace of delivery, not the other way round. In AI-DLC, the sprint itself changes in nature.

Principles that do not change

Agile was not born with sprints. One of its founding principles already calls for delivering "working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale". The bolt does not contradict it: it takes it to its logical conclusion.

What defines agile comes down to three moves: iterate, get fast feedback, adjust. At Adservio, we design bolts the same way: short iterations to get feedback, adjust the product and feed that feedback into the next iteration. The loop is shorter, but it is the same loop.

What DORA's data confirms

Google's DORA team points in the same direction. In September 2025, it published a model of the capabilities that amplify the effect of AI on team performance. Two of the seven capabilities it identifies are long-standing agile principles:

• Working in small batches: it strengthens the positive effect of AI on product performance and reduces friction for teams.
• A user-centric focus: it increases the positive effect of AI on team performance. Without it, according to DORA, adopting AI can actually harm performance: teams move fast, but in the wrong direction.

The bottleneck moves: requirements and review

When producing code costs next to nothing, the constraint shifts upstream and downstream of production.

Upstream: clear requirements

In an AI-DLC project, the first risk is not the AI: it is the clarity and completeness of the requirements. A vague requirement produces, faster than ever, software that does not answer the question asked. If the design is not watertight, AI does not prevent misalignment: it accelerates it. The collective elaboration session is therefore the decisive moment, when the business and the team agree on what should be built before the AI builds it.

Downstream: review and the rubber-stamp risk

Review time grows almost as fast as the volume produced, and the temptation is familiar: approve quickly without really reading. Picture a stadium entrance where tens of thousands of fans arrive in front of a handful of stewards: either the checks become symbolic or the queue grows. Speeding up production without widening review changes nothing about final throughput: the narrowest point sets the pace.

Reliable tests and an available team

For the loop to hold, the team cannot read everything line by line. It relies on automated tests derived from the expected behaviour, not from the code produced: they let the agent fix its own mistakes before submitting its work. Finally, a bolt only makes sense if feedback comes quickly. If the business can only sign off once a fortnight, the short loop turns back into a two-week sprint.

Related readAI-Generated Test Cases from User StoriesA controlled experiment measures AI test case generation: 80% time saved, 27% ambiguity, and what the autonomous coding agents of 2026 change for QA teams.Read the article

What we recommend

Before bringing in an agent, we recommend assessing the maturity of the development lifecycle, stage by stage. Our framework has five levels, from absent to piloted, and each level assumes the previous one is in place: AI accelerates what is already structured, and amplifies what is not.

The weakest stage sets what AI can accelerate without causing damage. That is where to start, before adding tools to the others.

In an AI-DLC orchestration, the human sets the intent and validates; the orchestrator breaks down the work. To know whether the organisation is working, we recommend keeping the four delivery metrics defined by DORA: lead time, deployment frequency, change failure rate and time to restore. These are not new criteria: they are the ones that already mattered before AI. The question remains the same: was the expected feature delivered, how fast, and how reliably?

Where to start

Without waiting for the end of the series, five steps will tell you where your organisation stands:

1. Measure before changing: track these four metrics on one project, so you know your starting point.

2. Place every stage: fill in the grid above with the team rather than alone, then strengthen the weakest stage before adding tools.

3. Shorten the loop: run a pilot with bolts of a few days and a business team able to sign off at that pace.

4. Review rituals one by one: keep those that produce a decision or feedback, lighten those that merely report progress.

5. Watch the review queue: if it grows, that is where to invest, not in more production.

Our approach to AI-DLC and augmented testing is set out on our dedicated page.

Related readAgile at scale: beyond the Spotify modelThe "Spotify model" (Squads, Tribes, Chapters, Guilds) dominated large-scale agile discussions for years. But here's a secret: even Spotify no longer follows the Spotify model.Read the article

Our answer: testing it in public

The research cited measures thousands of teams from the outside. None of it shows what happens, step by step, inside a project run with AI-DLC. That is what we are going to do.

In the coming weeks, we will show AI-DLC at work on a project built for the purpose and run end to end with the method. We will publish every step: the questions the agent asked, the plans we rejected, the bolts run in parallel, the mistakes and the measurements. The case is constructed for the occasion; the execution and the figures will be real. At the end of the series, we will say, with measurements to back it up, what became of our rituals, and what is left of agile.