Agile AI Development Lifecycle

At the end of 2025, AWS open-sourced their AI-DLC methodology. At first it looks like an easy-to-adopt (just drop markdown files into your repository) framework that should take one from pre-AI software development lifecycle to the AI-native future. In its nature it is very similar to compound engineering and superpowers - all of them are a collection of skills in markdown prose that rely on human-in-the-loop review. Notably both of them were introduced to the public a few months before AWS released AI-DLC, but it's hard to compete with AWS in terms of visibility.

The AWS AI-DLC is designed to guide users through 30+ stages of development in total, grouped into 5 phases: initialization, ideation, inception, construction and operation. Every stage requires thorough mob-review of AI-generated artifacts.

The pros of this approach are ease of adoption and the fact that it is designed by AWS. The cons are that it is essentially an automated waterfall (4 out of 5 phases produce documentation) with quality being defined by how thorough and knowledgeable the reviewers are. So unless your company is staffed by superhumans who enjoy reading tons of AI-generated documentation, you too might look for something else, especially if you need to scale the AI methodology outside of one engineer's machine working with a handful of repositories.

Platform Engineering

The second camp of AI adopters at scale doesn't have a single shared name for the methodology, because they didn't invent something new. They evolved their existing workflows and integrated them with AI capabilities. Notable publications include CNCF Platforms White Paper, Spotify's Golden Paths and Netflix's "paved roads".

The core idea is to standardize their processes and tools to make it easier for the teams to execute on business initiatives without needing to reinvent the wheel. The maintenance of these "paved paths" would fall on the platform engineering teams, popularized by Team Topologies alongside stream-aligned teams.

When all the processes are standardized, transitioning from a mature engineering organisation to an AI-enabled engineering organisation is a matter of writing agentic workflows on top of the existing processes and platform capabilities.

I suggest we finally give this methodology a proper name (and hope that a cloud juggernaut would adopt it).

Agile AI-DLC

The key difference between AI-DLC and Agile AI-DLC is that the stages of development produce prototypes and their evolutions, not documentation, and the quality is assured by deterministic checks, rather than human review.

Agile AI-DLC is built on the concept of "paved paths": interconnected, standardized processes that guide the development from varying starting points to production deployment across the whole organisation, not just engineering teams.

Examples of paved paths can include:

• A designer creates a prototype in Figma and triggers a build of an interactive prototype
• A product manager tags a Slack bot to evolve the designer's prototype with full-stack capabilities
• An engineer brings an internal platform from idea to production utilising existing system components

And examples of deterministic checks are:

• Opinionated design system and abstractions
• Strict linter code checks and type systems
• Scorecards and CI/CD pipelines enforcing them

Ceremonies of Agile AI-DLC

Agile AI-DLC, as the name suggests, follows the ground rules of Agile Development and can be described as the following cycles:

• Proof of Concept: a quick, exploratory prototype is developed as the team collaboratively explores the problem space and validates the feasibility of the solution. The paved path used to develop the PoC is defined by the problem space and team's composition. This stage requires domain experts' involvement and the expected outcome is a decision on whether to proceed with the project or not.
• Prototype: validated PoC is evolved into a prototype. The paved path depends on the team's composition (e.g. design-first, API-first, etc). Domain experts are involved to a lesser degree and the expected outcome of this stage is to define the scope and requirements for the MVP version.
• Executable Specification: the requirements gathered during previous stages are translated into executable specifications: unit, integration, end-to-end or visual tests, contracts or strict machine-enforced rules as much as possible. Requirements that cannot be validated automatically are documented and stored in a manner that is accessible to team members, stakeholders and agents. Domain experts are involved on-demand and the outcome of this stage is a suite of test automation and executable specifications.
• Implementation Loop: agents are tasked with evolving the prototype into a working implementation one requirement at a time until all the requirements are met and all the checks are passing.
• Evaluation: the working implementation is validated against a broader set of requirements and checks, including manual checks, if needed, and demonstrating the solution to the stakeholders. Domain experts are involved on-demand and the outcome of this stage is a set of additional requirements that need to be addressed in the next iteration.
• Retrospection: the team reflects on the implementation and makes adjustments to the paths, processes and requirements for the next iteration. Domain experts are involved on-demand and the outcome of this stage is a set of commitments that kicks off the next cycle.

Executable Specification

The concept of requirements as executable specifications rather than documentation deserves a deeper dive as it is load-bearing for the AI development lifecycle. The concept is well-described in Agentic XP: Moving Rigour Left in the Age of AI:

Extreme Programming (XP) is often remembered for its rituals: pair programming, test-driven development (TDD) and small batch delivery. Its core insight was far more fundamental: correctness is established continuously during creation rather than inspected after the fact (Beck, 2004). XP was about maintaining alignment so that correctness emerged during development rather than being inferred later.

In practice that entails turning the agreements, ways of working and architecture into abstractions and the requirements into automated checks and tests.

Predictable codebases and processes are easier to adopt for a human, but we can and have been tolerating a far greater level of ambiguity than AI can handle. Therefore having one and only one correct way of doing the same thing is crucial for maintaining high quality of AI-generated solutions.

This predictability can come from the use of specialised tools, such as static code analysis and automated testing, strict compilers (such as the one Rust has, for example), but also from specifications enforced by design systems, API catalogs and policies.

Agile overall, and XP in particular, accepts that humans make mistakes and shifts the responsibility to ensure correctness on automation. Which becomes even more important if the work is executed by AI agents.

In the "Agentic Development Survival Guide", I insisted on following the principle of "More Power - More Guardrails" which holds for the organisation-wide adoption as well.

It's okay to set loose rules (e.g. in the form of skills.md) for non-critical tasks, such as brainstorming or creating a throw-away prototype. But for anything that carries risks to main operations or company reputation, it is important to make sure that paths have concrete walls, preventing people and agents from accidentally or intentionally straying from it.

And that is almost everything that touches production.

Agile AI-DLC relies on test automation, continuous integration and deployment (CI/CD) pipelines and only resorts to documentation and human review when it isn't possible or feasible to automate it.

Metrics

While Agile AI-DLC can be adopted at any level of maturity, it is recommended that the organisation commits to increasing their engineering maturity that can be measured by metrics such as DORA and SPACE.

In addition to these fundamental metrics, it is recommended to track adoption of each "paved path" and continuously iterate on their adoption, error and re-run rates, where:

• Path Adoption Rate: is a measure of how many unique users are using this path daily, weekly and monthly.
• Path Error Rate: is a percentage of failed path executions over the total number of executions.
• Path Re-run Rate: is a percentage of executions with the same request over the number of unique requests.

And finally, every path should be monitored for costs it incurs in the form of cost budgets and alerts.

Desired Team Topology

Agile AI-DLC can be adopted by teams of any size and structure, but it works best with the combination of Platform Teams and Stream-Aligned Teams.

• Platform Teams: are responsible for the maintenance of the paved paths and evolution of platform capabilities. They can be organised around a cluster of paths, a domain or a technology. They absorb complexity of the platform.
• Stream-Aligned Teams: are responsible for driving an outcome stream, such as a set of specific business goals or revenue streams. They focus on solving business problems, shedding the complexity.

It is important that all teams feel ownership over both goals and the platforms: platform teams should work closely with and anticipate the needs of stream-aligned teams to proactively build required capabilities and stream-aligned teams should make suggestions and even improvements to platform capabilities that they need or will need in the future.

Depending on the organisation, domain experts can be part of platform teams or exist as independent satellite teams, being pulled in by stream-aligned teams to provide expertise and guidance.

Agile AI-DLC Adoption

The overall maturity of Agile AI-DLC is measured in a similar way to engineering maturity: the more actively used paved paths the company has and the better the outcomes become - the higher the maturity. But the company can consider the methodology adopted the moment the first path is paved.

In its core, Agile AI-DLC is an agile and flexible methodology, allowing companies to enhance their existing strengths and ways of working and iteratively improve them.

It is recommended to dedicate at least 20% of time allocated to each project to reflect and improve daily work and processes. The time that would be freed as a result of adopting Agile AI-DLC and such improvements should be dedicated to their reflections and improvements rather than scaling the amount of work whenever possible.

Following the Agile AI-DLC methodology, you're ensuring that your organisation is focusing on the outcomes, collaboration between humans and strategic thinking, rather than reviewing AI-generated documentation.

And these qualities are prerequisites for long-term success, no matter what the future might hold.