Waterfall is dead — it was killed by Agile. At least, that’s what people believed for the last 15–20 years.

Intrigued? I was too, when I caught myself going back to it.

With modern LLMs, Waterfall is becoming relevant again; not as a heavyweight ceremony with endless approvals, but as a practical control structure for managing a fast, probabilistic generator. A single iteration no longer takes months of team effort — it can take hours or a couple of days with one skilled engineer.

I call it Waterfall 2.0. The classical engineering sequence is preserved, but each stage now runs through an LLM at orders of magnitude higher speed. The outcome is controlled generation of everything needed to develop or evolve a system — from high-level vision all the way to working, tested code.

Why did Waterfall Disappear?

Classic Waterfall emerged when the industry needed more structure around large software projects. It used clear milestones and artifacts: Requirements → architecture → implementation → testing → release. The big problem was slow feedback and extremely expensive fixes when errors surfaced late — as Frederick Brooks illustrated in The Mythical Man-Month.

Agile and its variants (XP, Scrum, Kanban, SAFe, etc.) solved the late truth problem by shrinking batch sizes and accelerating feature-level feedback. It works brilliantly for incremental delivery.

But in complex environments — meshes of interdependent services, shared data platforms and globally imposed constraints — purely incremental approaches can lead to fragmented architecture and compounding technical debt. At architectural scale, you still need a structured way to align everything into one coherent design.

The Capability Stack That Changed Everything

In 2025, four developments converged and made a fast, controlled Waterfall practical:

• Long-Context Windows: Modern models handle up to a million tokens. That’s enough to load an entire project’s artifacts and let the model reason across them at once.
• High-Reasoning Modes: Extended-thinking models turned spend more time thinking into reliable, production-grade behavior. They maintain coherence across large interdependent sets far better than fast text generators.
• Tool Connectivity and MCP: LLMs can invoke tools, query live data and generate measurement scripts. The model context protocol (MCP) provides a standardized, secure way to connect models to data sources and tools.
• Whole-Corpus Reasoning: Together, these let a single LLM session behave like a small, well-coordinated engineering team.

I’ve used this setup repeatedly on real integration programs. What once required weeks of synchronization now happens inside one extended session with good context management.

Waterfall 2.0: The Five-Stage Pipeline

When models were smaller, LLMs were mostly useful as smart autocomplete. With million-token contexts becoming available in late 2025, the limitation shifted from “Can the model do it?” to “How do I control and direct the generator?”

That’s when I found myself using the Waterfall process again — only now it looks very different. Most of the heavy lifting happens in interaction with the LLM. The engineer manages context and validates outputs rather than writing everything manually.

Here are the five concrete stages with realistic timing for a bounded but meaningful slice of work:

1. Vision (~30–60 minutes): A concise document describing what matters about the system: The core problems it solves, key constraints and success criteria. Feed raw notes or stakeholder input to the LLM and ask it to synthesize a structured vision. Keep it focused.
2. ADR (~2–3 hours): Generate architecture decision records (ADRs) for the major components. ADRs are compact, decision-focused and LLM-friendly. Prompt the model to derive ADRs from the vision, then review, challenge gaps and iterate (usually 2–3 cycles in high-reasoning mode, 15–30 minutes each). The validated version becomes the artifact.
3. Prototypes (~1–2 days): Prototyping is now nearly zero-cost, so it becomes an essential phase. Build quick experimental code to validate library compatibility, architectural ideas and feasibility. Keep everything in a separate folder. Review what works and what feels off, then ask the LLM for targeted fixes. I also ask it to generate supporting automation scripts or rules.
4. Architectural Skeleton (~2 hours): Combine the scattered prototypes into a unified project structure: Modules, packages, folder layout and high-level guidelines. Ask for several variants if needed and pick the strongest. Review and regenerate as required. This stage usually moves quickly because modern tech stacks are quite standardized.
5. Code + Tests (~0.5–2 days): With validated artifacts accumulated in context, commission the final codebase. Pay special attention to testing. I strongly recommend the diamond model: Minimal unit tests (only where they add unique value), heavy emphasis on integration tests for broad coverage and end-to-end tests only on critical paths. At this point, source code itself is somewhat transient — it can be regenerated reasonably quickly. The automated tests become the primary guarantee of stability.

Bubble-Sort Backtracking: The Real Differentiator

<………………….. roll back to any previous stage …………………..>

In classic Waterfall, backtracking was painful and discouraged. In Waterfall 2.0, it’s encouraged and cheap — like bubble sort swapping elements until everything falls into order.

Found a fundamental flaw during prototyping? Roll back to vision, update it, regenerate the ADRs and re-prototype. The whole cycle might take a few hours instead of weeks. This completely flips the economics: You’re rewarded for discovering problems, because the cost of correction is no longer prohibitive.

This fearless, low-cost backtracking is what makes the approach fundamentally different from its rigid ancestor while still giving you a clear mental scaffold.

Building the Knowledge Corpus

Everything rests on a single, well-managed knowledge corpus — usually one directory or repository containing all relevant materials (requirements notes, prior ADRs, code snippets, schemas, diagrams, telemetry, etc.). LLMs handle messy input surprisingly well, but light preparation helps.

Quantitative Grounding: Let the LLM Find the Data

When you need hard numbers (data volumes, cardinality skew, retention, throughput, tail latency), don’t prescribe every query yourself. Give the model tool access via MCP or ask it to generate the right SQL, PromQL, k6 script or log parser. Then run what it produces and feed the results back into context.

The part that surprised me: You don’t need to figure out the measurement approach yourself. The LLM often comes up with clever ways I wouldn’t have thought of. Your job is simply to make sure real measurements — not assumptions — end up in the knowledge corpus. That’s the practical anti-hallucination mechanism.

Parallel Analysis: Keeping ‘Should’ Separate From ‘Is’

Some steps can run in parallel when dependencies allow. A pattern I’ve found valuable is running independent business and system analysis passes.

• Business analysis synthesizes goals, user needs, functional and non-functional requirements and assumptions. Karl Wiegers’ approach can serve as a useful framework, but the specific notation doesn’t matter. What matters is that you, the engineer, understand what was generated and why.
• System analysis examines the existing codebase, services, schemas and constraints to document what is actually there today.

These two outputs then feed into architecture synthesis, where the LLM reconciles requirements with real capabilities and highlights the interesting contradictions — exactly where real design decisions live.

The Engineer’s Evolving Role: Return of the Combi-Shaper

About 30 years ago, almost every software engineer was what we’d now call a combi-shaper — someone who lived with the customer’s problems and led the development from start to finish. They knew low-level details such as endianness, ELF formats, the difference between a jump and a call and even the benefits of a single-byte NOP on x86.

The web era, with its pressure for rapid delivery, created more specialization: Broad full-stack engineers on one side and deep specialists (security, performance, etc.) on the other.

In the LLM era, I believe we’re swinging back toward combi-shaping, but at a higher level of abstraction. Generation has become so fast that the real bottleneck is validation and decision-making. Splitting roles too narrowly breaks the learning loop and reduces long-term productivity.

With Waterfall 2.0, the work shifts from writing artifacts to curating the corpus, orchestrating the LLM’s roles and making final trade-off decisions. LLMs don’t replace business analysts, system analysts, architects, developers or QA — they remove the excuse to stay limited to just one of those roles. One skilled engineer can now carry out the full requirements-to-code loop for a bounded scope while keeping the completeness of a stage-gated process.

The Abstraction Ladder

This shift is simply the next rung in a long progression:

• Machine code → assembly
• Assembly → C (compilers handle optimization)
• C → higher-level languages and frameworks
• Hand-written code → libraries and open ecosystems
• Now: LLM-assisted engineering (mental models → artifacts → code, with heavy automation)

Each step moves engineers further from implementation details and closer to system intent. Artifacts become more transient and regenerable. What remains constant is the need for rigorous validation — a sloppy mental model now produces convincing but wrong outputs at scale. That’s exactly why the stage-gated checkpoints still matter.

Conclusion

LLMs do not replace programmers. They shift the level of abstraction at which we work.

Agile excels at handling uncertainty through fast feedback. Waterfall 2.0 addresses complexity by providing a clear structural scaffold for consistent, verifiable generation in interdependent systems.

The method isn’t limited to code — it generalizes to any domain where outputs must stay coherent, traceable and grounded in reality.

Waterfall wasn’t dead; it was just waiting for machines that could write (and rewrite) code fast enough.

Key Takeaways

• Waterfall 2.0 uses classical Waterfall stages as a lightweight control structure for LLM-driven generation, enabling a single engineer to complete a full requirements-to-code cycle in hours or days rather than months.
• The five-stage pipeline — vision, ADR, prototypes, architectural skeleton, code + tests — builds a cumulative knowledge corpus that gives the LLM enough context for coherent system-wide generation.
• Unlike classic Waterfall, backtracking is now cheap. Like bubble sort rearranging elements, you can roll back to any previous stage and re-run. The near-zero cost of iteration makes this practical.
• The engineer’s role shifts to a combi-shaper: Context manager, validator and trade-off decision-maker across the full stack. LLMs handle most generation, while the humans ensure quality and coherence.