# Show HN: Agile AI Development Lifecycle > Source: > Published: 2026-08-22 08:08:59+00:00 [Agentic Development Survival Guide](/agentic-development-survival-guide) [#development](/tags/development), [#genai](/tags/genai), [#devx](/tags/devx) A practical guide to navigating identity crisis and poor developer experience while trying to stay ahead of the curve of coding with AI agents. [[read more]](/agentic-development-survival-guide) At the end of 2025, AWS open-sourced their [AI-DLC](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/) 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](https://every.to/guides/compound-engineering) and [superpowers](https://github.com/obra/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. 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](https://tag-app-delivery.cncf.io/whitepapers/platforms/), [Spotify's Golden Paths](https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem) 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](https://teamtopologies.com/key-concepts) 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). 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: And examples of deterministic checks are: Agile AI-DLC, as the name suggests, follows the ground rules of [Agile Development](https://agilemanifesto.org/) and can be described as the following cycles: 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](https://www.wandoosystems.com/articles/agentic-xp): 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"](https://valeriavg.dev/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. 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](https://dora.dev/guides/dora-metrics/) and [SPACE](https://space-framework.com/). 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: And finally, every path should be monitored for **costs** it incurs in the form of cost budgets and alerts. 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**. 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. 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](https://valeriavg.dev/the-sunset-of-arrogance-as-a-service) might hold. A practical guide to navigating identity crisis and poor developer experience while trying to stay ahead of the curve of coding with AI agents. An essay about the past AI-promises-era and how we got here in the first place Transitioning from an individual contributor to a leader is not easy. Why would it be? One day you are the hero doing all the work, the next day you are expected to guide others to do it for you. I wish I had the knowledge I have now when I was starting out as a manager. Perhaps this article will help you avoid some pitfalls I dug myself into.