I’ve been thinking about software development methodology for a long time. When I founded AgilityFeat in 2010, I was traveling the US coaching and training teams in Agile practices, principally Scrum and Kanban. Many people were still just learning about the Agile Manifesto, even though it was approaching a decade old at that time, and there was still real resistance to overcome.
Too many leaders still genuinely believed that if you just wrote requirements precisely enough up front, you could throw those requirements “over the wall”, and software projects would succeed.
We know how that story ends.
Eventually I pivoted AgilityFeat from consulting toward building a nearshore software development agency, because I missed something consulting couldn’t give me: building great teams, working directly with clients on application ideas, and seeing software actually ship. That shift turned out to be a good bet. For over 15 years now, applying Agile methodologies to nearshore teams has been core to how we operate, and it’s a model that works well.
But something new is in the air, and I’ve been watching it carefully.
The Weekend-Build Promise, and Why It Worries Me
The AI development tools space is moving incredibly fast. And with it has come a particular kind of hype: the idea that if you can just craft the perfect specification, AI agents can build your software application in a weekend.
Some people call the low-rigor version of this “vibe coding“, where users prompt AI tools in natural language and see what comes out. Others may apply the term to a more rigorous type of AI-driven development. For the purposes of this blog post, I’ll use vibe coding to refer to low-rigor development where the user has limited knowledge or personal experience with software engineering and best practices. This means they can generate code using modern tools, but they don’t have the expertise to know if that generated code is well formed or filled with bugs.
For a simple website, a personal project or a demo, vibe coding is fine. For production software serving real customers at scale? It’s a recipe for technical debt, security holes, and the 3am incident you didn’t see coming.
But my concern runs deeper than code quality. When I hear “just write a perfect spec and AI does the rest,” I hear waterfall thinking with a new coat of paint. And after years of watching waterfall-style projects fail early in my career, that’s a pattern I don’t want to see repeated in our industry.
Those projects often failed not because teams were incompetent, but because requirements written months before delivery are always wrong in ways you can’t anticipate.
The specific risk I worry about isn’t if AI development is inherently waterfall. It’s that organizations with latent waterfall instincts will use these new tools in a waterfall way. They’ll treat AI-assisted spec generation as a license to front-load all their requirements work, skip customer validation, and assume that a more sophisticated document equals a better outcome. It doesn’t.
I’m certainly not unique in this perspective. Martin Fowler, one of the founders of the Agile Manifesto, is among the agile thought leaders saying similar things. Martin recently had an in-depth interview on the Pragmatic Engineer podcast where he shares similar thoughts. He says:
“Vibe coding is good for explorations, it’s good for throw-aways, for disposable stuff, but you don’t want to be using it for anything that’s going to have any long term capability. When you are using vibe coding, you are actually removing a very important part of something, which is the learning loop.”
Agile methods have always been all about learning loops with our users. In our excitement about AI tools, it’s very important we don’t lose our ability to have learning loops with our users.
The Promise of AI-Driven Software Development
Despite the concerns I’ve raised above, there is real value in AI tooling for software development. Our teams at AgilityFeat embrace these tools and use them daily.
AI allows developers to deliver new features more quickly, AI tools are very helpful in analyzing legacy code (though not always good at refactoring it), and they broaden the capability of full stack developers. With the help of AI tools, a full stack developer doesn’t have to be an expert in any particular language or tech stack. The tools can help them to be effective across a wider range of technologies, while still able to apply their software engineering expertise to validate the output that an AI tool may provide.
So yes, we should all be using AI to enhance the skills and delivery of our software development teams. But we need to be careful in how it’s applied. An updated version of Agile methodologies could be very helpful.
One Option: The AI-Driven Development Life Cycle
I attended WebSummit Vancouver recently and caught a presentation by AWS on something they’re calling AI-DLC – the AI-Driven Development Life Cycle. It was the first formalized methodology I’ve encountered that explicitly tries to thread this needle.
AI-DLC was introduced by Raja SP, a Principal Solutions Architect at AWS who has worked with over 100 large enterprise customers on software delivery. The methodology describes itself as “an AI-centric transformative approach” built on two core dimensions:
- AI-powered execution with human oversight. Rather than having AI generate entire applications autonomously, AI-DLC positions AI as a planner that creates detailed work proposals, actively seeks clarification, and defers critical decisions to human judgment. The underlying argument is that only humans possess the contextual understanding of business requirements needed to make informed choices. AI can structure and execute, but it shouldn’t be the one deciding what matters.
- Dynamic team collaboration. As AI handles execution, teams collaborate in real time on problem-solving and decision-making. The shift isn’t from teamwork to solo AI output; it’s from isolated individual work to high-energy collaborative sessions focused on the decisions that actually require human judgment.
What I find genuinely interesting about this framing is that it maps reasonably well to something Agile practitioners already know: the most valuable thing a development team does isn’t typing code. It’s figuring out what to build, in what order, and for whom. Crucially, agile practitioners then build it in small enough increments that customers can tell you when you got something wrong, before you overinvest in the full application.
For more information on the AI-DLC, these are the links they provided in the session at WebSummit Vancouver:
- AWS Whitepaper: AI-Driven Development Life Cycle: Reimagining Software Engineering
- aidlc-workflows
- AI Driven Development Lifecycle Knowledge Badge Readiness Path (self-paced learning)
- Hands on workshops
My Underlying Assumption
My premise is that even if AI can dramatically speed up software development, there are many other parts of the business process around the actual code that still require significant investment by businesses in time, money, and focus. It’s also still very expensive to deploy software at scale in production. The heavy use of tokens that an AI-driven application may use only drives these expenses up.
Given that, it is wasteful to build too much functionality before you validate it with real users, because there is still a cost in deploying and supporting that functionality with users that cannot be measured in mere token spending.
The Three Phases of AI-DLC (and Where I Have Questions)
AI-DLC organizes work into three phases:
- Inception: AI transforms business intent into requirements and user stories through “Mob Elaboration,” where the full team actively validates AI’s questions and proposals.
- Construction: AI proposes architecture, domain models, code, and tests through “Mob Construction,” where team members provide real-time guidance on technical decisions.
- Operations: AI applies accumulated context from the prior phases to manage infrastructure as code and deployments, with team oversight.
The terminology is intentionally updated: traditional sprints or iterations become “bolts”, which are shorter, more intense cycles measured in hours or days rather than weeks.
Mob Programming and Mob Planning are well-established Agile techniques. Grounding the AI-DLC rituals in collaborative, real-time team validation is the right instinct. It means requirements don’t just live in a document; they get pressure-tested against the people who understand the business context.
I also like the “bolts” concept, for the same reason I liked short sprints: velocity creates accountability, and accountability creates honest feedback. Although I admit I’m not fond of the term “bolts” for the same reason I’ve always preferred the term “iteration” over “sprints”: words like bolt and sprint imply that you should always be running at top speed. While working at top velocity might sound great to business leaders, tech teams know it’s not sustainable. Teams need time to pause, learn and reflect. This is hard to do when you’re always running.
I’ll leave the terminology alone for the moment, because I have other open questions about the three-phase structure.
If teams treat Inception as something that must be fully completed before Construction begins (even if each phase internally uses bolts), then that sequential feel could slide toward mini-waterfalls. The customer validation question is critical: do customers get to see working software and respond to it throughout the bolt cycle, or only at phase transitions? That’s the question I’d be pressing AWS on in their hands-on workshops, and which you should seriously consider if you are implementing AI-DLC.
Other AI-Native Software Engineering Methodologies
AI-DLC isn’t the only AI-native framework attempting this balance. A few others worth knowing:
Spec-Driven Development (SDD)
Spec-Driven Development (SDD) has emerged as an influential practice in 2025–2026, with tools like AWS Kiro and GitHub Spec Kit (now at 93,000+ GitHub stars) operationalizing it. The core idea is to write a formal specification before AI generates code, separating the design and implementation phases with a human review step in between.
- Done at the feature level, this is entirely compatible with Agile. It’s essentially a more disciplined version of writing acceptance criteria, with AI helping you think through edge cases you might otherwise miss.
- Done at the project level, it’s waterfall.
At AgilityFeat, we have engineers working with Kiro and a number of other toolchains. We don’t have a single toolset across our company since our client teams often bring their own preferences and we adapt to each client’s requirements. The tooling matters less than the discipline of keeping the human review loop intact.
If you want to see an example of Kiro used for both software development and other creative practices like music production, I had my colleague Hector Zelaya as a guest on the Scaling Tech Podcast to discuss “Spec Driven Creativity: AI Collaboration in Music and Software.”
BMAD (Breakthrough Method for Agile AI-Driven Development)
BMAD (Breakthrough Method for Agile AI-Driven Development) is a community-built, open-source framework for the orchestration of agents that explicitly grounds itself in Agile. It uses a set of specialized AI agent personas: Analyst, Product Manager, Architect, Scrum Master, Developer, QA. Together, these personas contribute to structured workflows that produce specs, code, tests, and documentation in a traceable chain. Its explicit Agile lineage makes it worth evaluating for individuals that want to simulate human teams while staying close to the practices they know. There is an interesting analysis of the project on Medium: What is BMAD-METHOD™? A Simple Guide to the Future of AI-Driven Development.
Agentsway
Agentsway is an academic framework from a 2025 paper. It takes a principled look at where traditional Agile and Kanban fall short for AI-augmented teams and proposes a lifecycle designed from the ground up for human-AI collaboration. It’s more theoretical than practical today, but it’s the kind of work that may influence the industry frameworks that come later.
BMAD and Agentsway both are focused on agent teams with a human supervisor. In my first take, they would be susceptible to the bias of a single human leading the work. While some are speculating that we will have many “one person billion dollar companies” in the future because a single founder can control an army of agents, I find it hard to believe that the perspective of any single human being can be so visionary that they can build a large company without the additional feedback that a team of humans provides. If those people exist, they are surely few and far between, and most businesses will not work well in that model.
As evidence for that, I need only point out how many times ChatGPT or Claude has told me that I had a really great idea when I know it’s not that unique. LLMs are very useful, but they don’t substitute for customer feedback or the collaborative creativity of groups of humans.
The benefit of human-driven teams is that we gain the perspective of a diverse group of humans with different experiences and expertise. This is one of the most impactful parts of agile methods: Scrum’s focus on the team instead of specific job titles encourages everyone to have a voice in user story creation, estimation, and prioritization of the work to be done, all while maintaining a focus on the value delivered to a human user.
What I like about the AI-DLC is its mob approach to continuing to gather that human experience and expertise in a human team setting, but in a style that fits AI-driven lifecycles and AI-tooling.
A New Agile Manifesto for the AI age?
Thus far I have not seen a consensus view from the agile community on how agile methodologies should adapt to AI driven software development. But there are many thought leaders considering it.
Here again, I’ll reference efforts by Thoughtworks and Martin Fowler. In February 2026, also the 25th anniversary of the Agile Manifesto, Thoughtworks put together a workshop on the Future of Software Development. Their report summarizing the discourse is worth a read. As they noted, “The retreat did not produce a single, unified vision of the future, but instead produced something more useful: a map of the fault lines where current practices are breaking and new ones are forming.”
These fault lines include security, technical rigor, and most interesting to me, identification of a new “middle loop” in software development.
Traditional agile methods often have two iteration loops. The inner loop is what an engineer does every day in a Test-Driven-Development style: Write automated tests, write code to pass those tests, refactor as needed, and repeat. The outer loop is what teams do every sprint: Plan user stories, build code to implement that story, test it, and deploy it to real users for their feedback.
The new middle loop is around human oversight of AI agentic development, as shown in the following diagram.
This is one of the most unique concepts that came out of the workshop. Thoughtworks describes this middle loop this way:
“This middle loop involves directing, evaluating and fixing the output of AI agents. It requires a different skill set than writing code. It demands the ability to decompose problems into agent-sized work packages, calibrate trust in agent output, recognize when agents are producing plausible-looking but incorrect results and maintain architectural coherence across many parallel streams of agent-generated work.” – from the Thoughtworks summary of the future of software development retreat, February 2026
This is a fascinating insight, and makes a lot of sense to me about how the role of the software developer is not going to go away, but it will certainly change. It also fits nicely within our new model at AgilityFeat of Builder Pods. Our Builder Pods are small teams using the latest AI development techniques to build products for our clients in short iterations.
The principles of the Agile Manifesto have survived many other technological advances because it was designed to be flexible and to put customer value first. These concepts are timeless.
Faster Customer Feedback Loops, Not Fewer Ones
Here’s where I land. AI is genuinely compressing implementation time for many use cases. Features that took days are taking hours. That gap will likely widen for most software development.
The right response is not to eliminate the customer feedback loop. It’s to shorten it.
If your sprint was two weeks because that’s how long development took, and now development takes two days, your feedback loop should be two days. Not a months-long “Inception phase” that ends with a big reveal to the customer of all the functionality at once.
It’s also not the right response to use AI tooling as a reason to eliminate humans from the product development process. Instead, use these shorter iterations to gather more user feedback and retrain your team to think more like technical builders, and not just as traditional software engineers.
Because even if development cycles are shorter, we cannot forget about or neglect the many challenges that come with deployment, scaling, and security of applications, even if these factors increase the time it takes to deliver value to our users.
The best of what I’m seeing in AI-DLC and the writings of other thought leaders all point in this direction. The question is whether the organizations adopting these tools will combine the lessons of the past with the tools of the future, or if they will use the new spec-generation capabilities as a reason to front-load more work and defer customer contact longer. That’s a culture problem, not a methodology problem … but methodology choices can either reinforce or resist those tendencies.
I’ll keep watching this space, and if you’re navigating the same questions, I’d love to compare notes.
AI-driven development
Further Reading:
