Not Agile. Not Waterfall. With AI It's Cascades.

LLMs have changed software development. They can generate features in minutes that once took days, and large amounts of code that’s subtly wrong.

In the age of AI, our software development methodologies need to change along with our tools, taking advantage of the positives of LLMs while guarding against the downsides.

Waterfall was about writing comprehensive specs upfront, Agile is about building incrementally with minimal documentation.

AI-assisted development requires something in-between. Something that fosters good context engineering, utilizes LLM abilities to do things we could never do before, and pragmatically surfaces the dangers of probabilistic code generation.

This post describes how I think we should develop software in the age of AI. Not Agile. Not Waterfall. I call it Cascades.

cascade: /ˈkæskeɪd/; noun; a series of small waterfalls flowing from one to another.

Cascades are rapid AI-driven micro-waterfall development cycles that flow from detailed specifications through interactive prototypes to production code, with verification gates that scale based on business risk tolerance. They’re designed to give LLMs the context they need to work effectively while mitigating the quality risks of probabilistic code generation.

To adopt Cascade Methodology means embracing and understanding both the benefits and the dangers of AI-assisted development, and using it to your greatest advantage.

Waterfall and AI

Traditional Waterfall specs are too large and rigid for the rapid iteration that AI-assisted development enables. A major advantage of LLM code generation is the speed of iteration, and Waterfall simply doesn't take advantage of that.

Agile/Scrum and AI

Agile's intentionally minimal "just enough documentation" user stories can be poor context for an AI. An LLM needs guardrails and detailed specifications to avoid velocity-killing hallucinations and incorrect output.

At the same time, LLMs let you potentially implement far more features than you'd typically constrain a Scrum sprint to. However Agile has no metric to define how much LLM generation you can tolerate within a sprint, nor how much time verifying AI-generated code you can spare.

Agile is about quickly learning what does and doesn't work for your users, and AI-assisted development lets you learn more in an iteration. You can deploy bigger chunks of functionality with an LLM and thus get more feedback. But you also need spec details and code safeguards that Agile doesn't explicitly provide.

Cascade Methodology

With Cascade Methodology you iterate in development cycles. Each cycle is a micro-waterfall called a Cascade. With AI-assisted development I find it more useful to think in terms of specs instead of sprints, so a Cascade is the work done from spec to deployment.

The guiding principles of Cascade Methodology are:

Understand the underlying user and business problems the software should solve.
Build the least amount of software possible to solve those problems.
Everyone has a seat at the table in writing specs.
Prototyping and user research are first-class citizens.
AI-generated code is not to be trusted.
The density of code quality checks needed to deploy code is a function of the entropy tolerance of the business process the code is supporting.
Scope and timelines are functions of entropy tolerance and understanding the problems to be solved.

We will delve into each of these as we talk about the 5 phases of Cascade Methodology.

Phase 1: Spec

In Cascades, feature specs are detailed enough to give the AI clear context, but small enough to iterate quickly and adapt as you learn.

A good spec should include the usual business rules, data requirements, etc. But they should also include the why, not just the what. Those writing specs, via user interviews and observation, stakeholder meetings, and more should be good at getting to the "why" of the underlying problems that need to be solved.

Specs, especially those being written for LLM consumption, need to include constraints: design, functional, and technical requirements. That means more spec work up-front. But the speed-up that comes from providing good context to an LLM outweighs the time it takes to write a good spec.

Spec creation is good for your team. It should be a silo-breaking activity. It's the perfect place for multiple disciplines to have "seats at the table". Spec creation requires the cross-disciplinary work of requirements gatherers, designers, software architects, and more to arrive at well-engineered context for both the LLM and the team itself.

As Cascades are micro-waterfalls, specs should be for targeted features, usually not the entire app. However AI-assisted development in general let's you include more features in a spec than you might historically have included in a two-week sprint.

At all times, the underlying principle of building the least amount of software necessary should be front-of-mind. At times, once the underlying problem is understood, the solution may be no software at all, but a process change elsewhere.

Your spec is stored with your code (likely via a .md file) and is written for and provided to your LLM during prototype and production code generation. The first version of the spec is the entry point, but unlike Waterfall it's only a start.

The spec is a hypothesis, and thus doesn't have to be perfect. Once prototyped it becomes an experiment. Once verified, implemented, and deployed it becomes a source of truth.

Phase 2: Experiment

A lot has been said about how LLMs have impacted getting code to production. But the effects of LLMs on prototype creation is an absolute game-changer.

In a Cascade the "experiment" phase means prototyping and research.

Being able to generate true interactive prototypes (with locally stored data) for user research and usability testing is a true LLM superpower. Since you don't have to care about prototype code quality, designers and developers can vibe code their way through a spec, review free.

Quality context from the spec will enable the LLM to generate realistic data and scenarios, further enhancing the value of user testing.

The results of prototyping then feed back into the spec. You can have the LLM update the spec as the designer iterates on ideas, responding rapidly to the results of cognitive walkthroughs and user testing.

The SPEC -> EXPERIMENT -> SPEC loop should be fast. There's no need to spend time on code reviews. Ideate away.

Time spent on designing, testing, and iterating on prototypes is often the first thing to be neglected when teams are trying to move fast. But a good user experience is an important differentiator in the AI age, and with LLM generation, velocity is no longer an excuse not to research.

In fact, prototyping and research ultimately save time because prototypes can be purely vibe coded, no code quality required.

In the AI age building something is easy, but building something good is still hard. That's why prototyping and user research are first-class citizens in Cascade Methodology.

While it is preferable that prototypes be focused on a single Cascade, designers need to have a holistic view of software. Thus a single prototype may include features from multiple Cascades.

From a project management standpoint, this means the prototyping phase of a Cascade can be a cross-reference to a separate UI/UX task. In this way designers, through iteration and user research and testing, can ensure that various specs work together to form cohesive software workflows.

However, design should not be a bottleneck to learning, and perfect is the enemy of good. Designers can continue to easily experiment, but their priority should be solving user problems in some way, and getting that solution moved forward to implementation.

Phase 3: Implement

A combination of spec and prototype form fantastic context for both an LLM and developers.

Implementation choices is not a concern of Cascade Methodology. The guiding principle to keep in mind, again, is to build the least amount of software needed to satisfy the problems to be solved.

That doesn't mean devs should skip writing tests or best practices. Remember AI-generated code is not to be trusted.

Rather, it means everyone keeps in mind that the assumptions of the requirements and the design of the software are experiments that will be tested in the laboratory of actual code. So devs shouldn't get attached and shouldn't try too hard to predict the future.

At the end of implementation you should have a working software.

A Reality Check...

LLMs are statistical probability machines. AI-generated code may have edge case bugs, performance problems, security issues, regressions, and more.

Code needs to be verified before being deployed. But verification is nuanced, so before we can describe the next phase we need to pause and talk about Entropy Tolerance and Verification Gates.

Verification Gates

Cascades are a metaphor. We imagine a series of micro-waterfalls, each feeding into the other.

At the bottom of each micro-waterfall, we add a Gate. A Verification Gate is the quality checks on the AI-generated (and human) code prior to deployment.

In our metaphor, you should imagine a mesh gate, which can vary in its fineness. You can have a porous gate or a dense gate.

With AI-assisted development we measure the density of checks needed as a function of the feature's Entropy Tolerance.

Entropy Tolerance

Entropy Tolerance is how much uncertainty (or AI-generated 'guesswork') a software-supported process can handle.

LLMs are powerful, but inherently unreliable, probabilistic guessing machines. "Entropy" in this context is the uncertainty in a probability distribution.

The core question for any Cascade is: what is the Entropy Tolerance of this feature? The lower the Entropy Tolerance the denser the Verification Gate must be, the higher the Entropy Tolerance the more porous it can be.

For example, suppose scroll animations are being added to static web pages on a large website. The Entropy Tolerance may be quite high. If the AI-code isn't perfect, it won't have great impact on the underlying process the software is supporting as long as the feature "works".

It may be sufficient for human review of a portion of the site, not every line of code. In this case, an LLM agent may be given the task of updating all the pages, and the Verification Gate can be "porous", meaning few or cursory human checks of the code.

The more porous the Gate, the more "vibe coded" a feature may be. Things are allowed through the gate more easily. Of course Cascades are like a river with a series of waterfalls. That same code will still be there in later iterations, so code quality is still a concern. That's why good specs are so important.

You might have automated code reviews in your process via LLM. But until there is a human in the loop, you should still consider your gate porous.

On the other hand, a feature that involves personally identifiable information of users has a low Entropy Tolerance. Bugs or security holes would have a large impact on the underlying processes the software is supporting (like user's lives and business health).

Thus the Verification Gate in this case would need to be dense. Human-in-the-loop checks of code are required. AI-generated code is not trusted. Less vibes, more PR reviews.

You should determine the Entropy Tolerance of a feature during the spec phase of a Cascade. This is a great opportunity to involve both your domain and security experts in the spec process.

That all said, we can define the final two phases of Cascade Methdology.

Phase 4: Verify

The feature implementation is verified according the Entropy Tolerance of the process it supports.

This could range from QA-style checks of the running software to human-in-the-loop complete code reviews.

In reality, the implementation and verification phases are often in a loop across multiple code merges.

You shouldn't waste much time isolating which code is AI-generated (though running agents that make PRs may make this obvious).

The Verification Gate being porous or dense applies as much to human code as AI-generated. The point is that you are aware of the needs of and dangers inherent to deploying the feature.

Phase 5: Deploy

Deploy via whatever methodology works for your team. I recommend Continuous Deployment, but only integrate code that passes the Verification Gate, whether porous or dense. CI/CD in a gated context.

You aren't really doing anything you didn't do before if you are reviewing code before merging and engage in CI/CD. You are just more explicitly aware of AI-generated code as a danger to quality.

To recap, then, the phases of a Cascade cycle are:

1. SPEC ←──────────────┐
   ↓                   │
2. EXPERIMENT ─────────┘
   ↓
3. IMPLEMENT ←─────┐
   ↓               │
4. VERIFY ─────────┘
   [porous or dense]
   ↓
5. DEPLOY

This lays out the complete methodology. But any experienced team will ask two questions: how do you maintain a reasonable scope in Cascade Methodology and how do you control the timeline?

Scope

Avoiding scope creep is an issue of defining the problems to be solved in a development cycle, rather than specific features (features are just solutions to problems). You should avoid the flawed concept of MVPs and focus releases on MSPs (Minimum Solved Problems).

An MSP set is a subset of user and business problems that need to be solved by the software in some way. This approach allows for cross-disciplinary and mental flexibility in what features really need to be built.

You don't get attached to a feature idea in an MSP set, or blindly implement solutions users and stakeholders suggest. You get attached to solving the real underlying problems with the least amount of software possible.

For example, an MVP for a todo app might be framed as a list of features: "add tasks, mark tasks complete, delete tasks, send email reminders for due dates." An MSP, on the other hand, starts with a list of problems: "users need a way to remember tasks, know what's done vs. not done, and need to know when tasks are due."

Once you frame it this way, the scope can shrink dramatically. The third requirement might be satisfied in an MSP release, not by building a custom email reminder system, but by simply giving users the option to add a task as an event to their existing calendar. By defining problems instead of features you build less software, move faster, and avoid locking yourself into unnecessary complexity.

AI-assisted development makes it easy to quickly create huge amounts of code. This can augment scope creep, security threat surface size, technical debt, and more. The mindset of building the least amount of software possible is an important counterpoint to the dangers of AI-assisted development.

That said, scope is variable in Cascade Methodology. Scope is a function of Entropy Tolerance and the chosen "problems to be solved" by the software.

Why a function of Entropy Tolerance? Because AI-assisted velocity changes depending on the bottleneck of needed human verification. A dense Gate necessarily slows down the waterfall.

In our previous example, the scope of adding scroll animations to an existing site could be quite large. An LLM agent could update hundreds of pages. Since the Gate is porous, letting more "AI slop" through, the Cascade can handle a larger scope.

For denser verification requirements, the scope is constrained by what humans can reasonably check. This may also vary depending on the complexity of the feature. Straightforward CRUD pages may be human-checked more quickly than complex business rules.

What about "problems to be solved"? They influence the scope by shrinking it. You build only what you need (if anything) to solve the user and business needs.

Thus solving problems with the least amount of software possible, combined with AI-assisted developer velocity, can result in a massive scope of "solved problems" for each release.

Your users and stakeholders don't care about how many lines of code you deployed this week. They don't actually care about how many features you've deployed. They care about how many of their problems you've solved.

Timelines

Experience has shown that the amount LLMs increase velocity of implementation is dependent on how good the specs you give them are. Thus the upfront focus on cross-disciplinary spec creation and rapid prototyping and research.

In general the stakeholder question of "how long will this take" is a function of the supported process' entropy tolerance and and how well the underlying problems being solved have been flushed out.

If you understand the underlying problems each Cascade's features are solving you can prioritize your Cascades by business need and, as we said before, minimize the scope to as small a feature as possible that solves the problem.

Minimizing the scope reduces the timeline.

For example, a stakeholder may ask for a way to automate emailing data in a web app. You flush out that the underlying problem is quickly sharing data. So you design a Cascade to ensure your UI's URLs are unique and shareable and add a Share button to your screens. The spec is detailed, the feature itself is far smaller than requested.

It turns out that LLMs do a decent job of identifying these kind of alternative solutions if you give them the complete context of a feature request. You should use AI to brainstorm and help you minimize the amount of code needed for a solution. It may dramatically improve your velocity.

I find that some teams use Scrum sprint timelines as an attempt to artificially compensate for poor understanding of underlying user and business problems. Some might say that's the point.

But a lack of user research followed by building bigger-than-needed, or outright not-needed, software in a sprint does not mean you're more efficient or flexible.

If you understand the underlying problems well, you end up writing less software, timelines naturally shrink, and stakeholder and user satisfaction increases. That's why Cascade Methodology doesn't have explicit timeboxed sprints like Scrum.

You can have multiple Cascades running in parallel where each sits at different phases in the process. Coordinate them however makes sense for your team. But if you prioritize understanding over timeline, and keep your Cascades sized according to Entropy Tolerance, velocity will stay high.

You don't aim to control the timeline. You aim to control the software.

Learning

Like Agile, Cascade Methodology embraces learning as-you-go, but utilizes AI to expand the scope of learning by expanding the scope of the release when possible.

Even after deployment, the spec is both a source of truth and living documentation of a continuing education in what the software needs truly are.

You should then respond to what you learn. The ability to pivot is also a key feature of Agile, and one that Cascades encourages as well. You learn a lot in the experiment phase. You learn even more when the feature is live.

A Cascade is just a moment in time. Don't consider its results permanent. The river keeps flowing.

Methodology for the Modern Era

The age of AI has changed software development in many ways. But LLM marketing hype has also clouded the impact of their downsides.

Cascade Methodology aims to be a practical, realistic approach to modern AI-assisted software development that takes advantage of LLM positives and mitigates LLM negatives, balancing good software with high velocity.

I hope these concepts help you and your team successfully build something great.

If you have questions or thoughts, feel free to drop me an e-mail. If you'd like to discuss, contribute, or support with a star, I've started a GitHub repo.

Happy coding!