Insights
Is AI making waterfall right again?
AI has made building software faster than ever. That moves the bottleneck to deciding what to build, and AWS’s AI-Driven Development Lifecycle shows what up-front discipline looks like when delivery cycles shrink to hours or days.
Key takeaways
AI coding tools compress build time dramatically, so the cost of ambiguity now outweighs the cost of code.
The disciplines agile moved away from, such as clear intent, signed-off plans and traceability, matter again. The long timelines don’t come back.
AWS’s AI-Driven Development Lifecycle (AI-DLC) formalises this: AI proposes plans and asks clarifying questions, and people approve before anything is built.
Sprints become “bolts” measured in hours or days, so up-front clarity no longer means slow delivery.
For buyers, it changes what to pay for, what to sign off and what to ask a delivery partner.
Agile won the argument. Then the economics changed.
For two decades, “waterfall” has been shorthand for everything wrong with software delivery: long requirement documents, big-bang releases, and projects that arrived late and missed the point. Agile won that argument for good reason. When writing code was slow and expensive, the smartest move was to build a little, learn a lot and change course often.
But the economics that made agile the default are shifting fast. AI-assisted engineering, from coding assistants to agents that can scaffold, refactor and test whole features, has collapsed the time it takes to turn a clear idea into working software. What used to take a sprint can now take an afternoon.
When building is fast, the expensive part moves. It’s no longer the code. It’s the thinking that comes before it.
The new bottleneck is clarity
AI tools are extraordinarily good at doing what they’re told. They’re far less good at working out what you meant. Give an agent a vague user story and you’ll get plausible-looking code that solves the wrong problem, quickly and at scale.
That makes ambiguity the most expensive thing in a modern delivery team. Every unclear requirement, undocumented business rule or hand-wavy acceptance criterion gets multiplied by the speed of the tools. Teams that iterate their way to an answer through code are now paying for rework at machine speed.
The teams getting the most out of AI are doing something that looks surprisingly old-fashioned: they’re investing heavily up front in understanding the problem, agreeing the plan and writing it down precisely.
So is waterfall back?
Not quite. What’s coming back is the discipline waterfall was trying to enforce: explicit intent, plans that are reviewed and signed off, and a clear line from requirement to release. What isn’t coming back is the timeline. Nobody is proposing 18-month programmes or 300-page specifications that no one reads.
The difference is speed. When a well-specified piece of work can be built in hours, you can afford to be rigorous about what you ask for, check it properly and still move faster than a traditional sprint cycle. Structure and speed stop being a trade-off.
AWS has a name for it: AI-DLC
In July 2025, AWS published the AI-Driven Development Lifecycle (AI-DLC), a model for software delivery with AI at the centre and people firmly in charge. Its core loop is simple: AI creates a plan, asks clarifying questions to fill in context, and only implements once a person has validated the plan. That loop repeats for every activity, from requirements to infrastructure.
This fits a wider shift some now call spec-driven development: write the specification precisely first, then have AI build and validate against it.
AI-DLC runs in three phases:
Inception. AI turns business intent into requirements, and the team validates its questions and proposals together in what AWS calls “Mob Elaboration”.
Construction. AI proposes architecture, code and tests, and the team resolves technical decisions in real time through “Mob Construction”.
Operations. AI helps manage infrastructure and deployment, with the team providing oversight.
It also renames the units of work. Sprints become “bolts”: shorter cycles measured in hours or days rather than weeks. Epics become units of work. Read the phases on their own and they look a lot like waterfall. Read them alongside the bolts and it’s clear this is something new: sequential discipline, run at a pace agile never could.
AWS’s own coding tool, Kiro, is built the same way: it turns a prompt into a structured specification, then checks the resulting code against it before anything ships.
Why this works better with AI, not despite it
The plan becomes the source of truth
In an AI-driven lifecycle, a well-written plan does double duty. It aligns stakeholders, and it becomes the instruction set for the tools doing the build. Good plans produce good code. Vague plans produce confident nonsense.
Review shifts from code to intent
When AI writes most of the code, reviewers can’t read every line. They can review intent: is the plan right, and does the output meet it? Approval points built into every cycle give reviewers a clear place to do that work.
Governance gets easier
For regulated industries, government and enterprise buyers, traceability isn’t optional. An AI-driven lifecycle makes it natural: every feature traces back to an approved decision, and every release to validated requirements. That’s a far easier conversation with risk, security and audit teams than “the agent wrote it”.
What it looks like in practice
Take a typical modernisation programme: an ageing customer portal that needs to move to a modern, cloud-native platform without disrupting the people who rely on it every day.
Rather than starting with a backlog and a first sprint, the team starts with Inception. Researchers and designers map how customers actually use the service today. Engineers document the existing behaviour, integrations and data. With AI drafting requirements and surfacing questions, the team agrees the target architecture, the business rules that must be preserved and the acceptance criteria for each capability. Stakeholders sign off a plan they can genuinely read.
Then Construction moves quickly. Each capability, such as account management, billing or notifications, is delivered in its own bolt. AI produces the bulk of the code and tests against the agreed plan, while engineers focus on architecture, edge cases and review. Every bolt ends with automated tests, a walkthrough against the acceptance criteria and a clear go or no-go decision.
The result is less time spent in ambiguity, far less rework and a delivery record that shows exactly what was built, why, and how it was validated.
Where it fits, and where it doesn’t
This way of working is strongest where the problem can be understood up front:
Platform modernisation and re-platforming, where existing behaviour defines much of the plan.
Regulated or high-assurance environments such as financial services, health, education and government.
Integration-heavy programmes with many systems, vendors and data flows.
Well-defined products and services scaling to new markets or channels.
It’s less suited to genuinely new products where the core question is whether anyone wants the thing at all. There, lightweight experimentation still wins, and AI makes those experiments faster to run too. Most organisations will use both: explore to find the right problem, then use an AI-driven lifecycle to deliver it well.
What it means for how you buy software
If delivery now runs on plans, approvals and short bolts, the way you scope and buy it should change too:
Pay properly for Inception. It’s where most of the value is decided, not a formality before the real work.
Sign off plans, not just outcomes. Make approval points part of the engagement, with named decision-makers on your side.
Scope by capability. Short bolts make it practical to agree, deliver and accept work one capability at a time.
Ask for traceability. You should be able to see how each release maps back to approved requirements.
And when you talk to delivery partners, “we use AI” tells you very little. Better questions are:
How much of the engagement is spent on Inception before build starts?
What does a plan look like, and who approves it?
How do you validate AI-generated code against requirements?
How do you keep traceability from requirement to release for our risk and audit teams?
How do you decide when to explore and when to commit?
The answers will tell you whether a partner is using AI to go faster in the right direction, or just to go faster.
How Honest Fox approaches it
We’ve always believed great digital products start with understanding people and the problem. AI hasn’t changed that. It’s made it more important. Our strategy, design and technology teams work together from day one to understand the problem and agree the plan, then use AI-accelerated engineering to build it in short, validated cycles.
As an AWS Select Tier Services Partner, we pair that approach with cloud architecture built for security, scale and governance from the start. The result is delivery that moves at the speed AI makes possible, with the clarity and control enterprise teams need.
When building is fast, the expensive part moves. It’s no longer the code. It’s the thinking that comes before it.
Thinking about AI-DLC for your next build?
We’ll help you work out where an AI-driven lifecycle fits, where it doesn’t, and what it means for how you scope and buy the work. Tell us what you’re planning.
