{"id":4891,"date":"2026-08-21T12:13:40","date_gmt":"2026-08-21T12:13:40","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/21\/waterfall-2-0-controlling-llm-driven-software-development-with-stage-gated-discipline\/"},"modified":"2026-08-21T12:13:40","modified_gmt":"2026-08-21T12:13:40","slug":"waterfall-2-0-controlling-llm-driven-software-development-with-stage-gated-discipline","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/08\/21\/waterfall-2-0-controlling-llm-driven-software-development-with-stage-gated-discipline\/","title":{"rendered":"Waterfall 2.0: Controlling LLM-Driven Software Development with Stage-Gated Discipline"},"content":{"rendered":"<div><img data-opt-id=90452229  fetchpriority=\"high\" decoding=\"async\" width=\"770\" height=\"330\" src=\"https:\/\/devops.com\/wp-content\/uploads\/2026\/06\/waterfall_2_0_770x330.jpg\" class=\"attachment-large size-large wp-post-image\" alt=\"\" \/><\/div>\n<p><img data-opt-id=954946779  fetchpriority=\"high\" decoding=\"async\" width=\"150\" height=\"150\" src=\"https:\/\/devops.com\/wp-content\/uploads\/2026\/06\/waterfall_2_0_770x330-150x150.jpg\" class=\"attachment-thumbnail size-thumbnail wp-post-image\" alt=\"\" \/><\/p>\n<p><span>Waterfall is dead \u2014 it was killed by Agile. At least, that\u2019s what people believed for the last 15\u201320 years.<\/span><\/p>\n<p><span>Intrigued? I was too, when I caught myself going back to it.<\/span><\/p>\n<p><span>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 \u2014 it can take hours or a couple of days with one skilled engineer.<\/span><\/p>\n<p><span>I call it <\/span><i><span>Waterfall 2.0. <\/span><\/i><span>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 \u2014 from high-level vision all the way to working, tested code.<\/span><\/p>\n<h3><span>Why did Waterfall Disappear?<\/span><\/h3>\n<p><span>Classic Waterfall emerged when the industry needed more structure around large software projects. It used clear milestones and artifacts: Requirements \u2192 architecture \u2192 implementation \u2192 testing \u2192 release. The big problem was slow feedback and extremely expensive fixes when errors surfaced late \u2014 as Frederick Brooks illustrated in <\/span><i><span>The Mythical Man-Month<\/span><\/i><span>.<\/span><\/p>\n<p><span>Agile and its variants (XP, Scrum, Kanban, SAFe, etc.) solved the <\/span><i><span>late truth<\/span><\/i><span> problem by shrinking batch sizes and accelerating feature-level feedback. It works brilliantly for incremental delivery.<\/span><\/p>\n<p><span>But in complex environments \u2014 meshes of interdependent services, shared data platforms and globally imposed constraints \u2014 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.<\/span><\/p>\n<h3><span>The Capability Stack That Changed Everything<\/span><\/h3>\n<p><span>In 2025, four developments converged and made a fast, controlled Waterfall practical:<\/span><\/p>\n<ul>\n<li><span>Long-Context Windows: Modern models handle up to a million tokens. That\u2019s enough to load an entire project\u2019s artifacts and let the model reason across them at once.<\/span><\/li>\n<li><span>High-Reasoning Modes: Extended-thinking models turned <\/span><i><span>spend more time thinking<\/span><\/i><span> into reliable, production-grade behavior. They maintain coherence across large interdependent sets far better than fast text generators.<\/span><\/li>\n<li><span>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.<\/span><\/li>\n<li><span>Whole-Corpus Reasoning: Together, these let a single LLM session behave like a small, well-coordinated engineering team.<\/span><\/li>\n<\/ul>\n<p><span>I\u2019ve used this setup repeatedly on real integration programs. What once required weeks of synchronization now happens inside one extended session with good context management.<\/span><\/p>\n<h3><span>Waterfall 2.0: The Five-Stage Pipeline<\/span><\/h3>\n<p><span>When models were smaller, LLMs were mostly useful as smart autocomplete. With million-token contexts becoming available in late 2025, the limitation shifted from \u201cCan the model do it?\u201d to \u201cHow do I control and direct the generator?\u201d<\/span><\/p>\n<p><span>That\u2019s when I found myself using the Waterfall process again \u2014 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.<\/span><\/p>\n<p><span>Here are the five concrete stages with realistic timing for a bounded but meaningful slice of work:<\/span><\/p>\n<ol>\n<li><span>Vision (~30\u201360 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.<\/span><\/li>\n<li><span>ADR (~2\u20133 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\u20133 cycles in high-reasoning mode, 15\u201330 minutes each). The validated version becomes the artifact.<\/span><\/li>\n<li><span>Prototypes (~1\u20132 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.<\/span><\/li>\n<li><span>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.<\/span><\/li>\n<li><span>Code + Tests (~0.5\u20132 days): With validated artifacts accumulated in context, commission the final codebase. Pay special attention to testing. I strongly recommend the <\/span><i><span>diamond model<\/span><\/i><span>: 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 \u2014 it can be regenerated reasonably quickly. The automated tests become the primary guarantee of stability.<\/span><\/li>\n<\/ol>\n<h3><span>Bubble-Sort Backtracking: The Real Differentiator<\/span><\/h3>\n<table>\n<tbody>\n<tr>\n<td><span>Vision <\/span><\/td>\n<td><span>ADR <\/span><\/td>\n<td><span>Prototypes <\/span><\/td>\n<td><span>Arch Skeleton<\/span><\/td>\n<td><span>Code + Tests<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>30\u201360 minutes<\/span><\/td>\n<td><span>2\u20133 hours<\/span><\/td>\n<td><span>1\u20132 days<\/span><\/td>\n<td><span>~2 hours<\/span><\/td>\n<td><span>0.5\u20132 days<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span>&lt;\u2026\u2026\u2026\u2026\u2026\u2026\u2026.. roll back to any previous stage \u2026\u2026\u2026\u2026\u2026\u2026\u2026..&gt;<\/span><\/p>\n<p><span>In classic Waterfall, backtracking was painful and discouraged. In Waterfall 2.0, it\u2019s encouraged and cheap \u2014 like bubble sort swapping elements until everything falls into order.<\/span><\/p>\n<p><span>Found a fundamental flaw during prototyping? Roll back to <\/span><i><span>vision<\/span><\/i><span>, 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\u2019re rewarded for discovering problems, because the cost of correction is no longer prohibitive.<\/span><\/p>\n<p><span>This fearless, low-cost backtracking is what makes the approach fundamentally different from its rigid ancestor while still giving you a clear mental scaffold.<\/span><\/p>\n<h3><span>Building the Knowledge Corpus<\/span><\/h3>\n<p><span>Everything rests on a single, well-managed <\/span><i><span>knowledge corpus <\/span><\/i><span>\u2014 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.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><i><span>Artifact<\/span><\/i><\/td>\n<td><i><span>How to Prepare<\/span><\/i><\/td>\n<td><i><span>Why it Matters<\/span><\/i><\/td>\n<\/tr>\n<tr>\n<td><span>User Requirements\/Discussions<\/span><\/td>\n<td><span>Markdown or plain text; preserve original stakeholder wording<\/span><\/td>\n<td><span>Model can spot contradictions and hidden needs<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>ADRs<\/span><\/td>\n<td><span>Collect in one folder, chronologically<\/span><\/td>\n<td><span>Provides decision history and constraints<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>Source Code<\/span><\/td>\n<td><span>Repo tree + key files\/README<\/span><\/td>\n<td><span>Helps reconstruct current architecture<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>API Contracts<\/span><\/td>\n<td><span>OpenAPI\/Proto with examples and error semantics<\/span><\/td>\n<td><span>Turns integration talk into enforceable contracts<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>Database Schemas<\/span><\/td>\n<td><span>DDL, indexes, relationships<\/span><\/td>\n<td><span>Enables accurate data flow analysis<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>Diagrams<\/span><\/td>\n<td><span>Mermaid\/PlantUML preferred; or images + text<\/span><\/td>\n<td><span>Reduces misinterpretation<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>Metrics\/Telemetry<\/span><\/td>\n<td><span>Aggregates or example queries<\/span><\/td>\n<td><span>Grounds assumptions in reality<\/span><\/td>\n<\/tr>\n<tr>\n<td><span>MCP\/Tool Connectors<\/span><\/td>\n<td><span>Boundaries, auth, safe patterns<\/span><\/td>\n<td><span>Enables live measurements<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><span>Quantitative Grounding: Let the LLM Find the Data<\/span><\/h3>\n<p><span>When you need hard numbers (data volumes, cardinality skew, retention, throughput, tail latency), don\u2019t 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.<\/span><\/p>\n<p><span>The part that surprised me: You don\u2019t need to figure out the measurement approach yourself. The LLM often comes up with clever ways I wouldn\u2019t have thought of. Your job is simply to make sure real measurements \u2014 not assumptions \u2014 end up in the knowledge corpus. That\u2019s the practical anti-hallucination mechanism.<\/span><\/p>\n<h3><span>Parallel Analysis: Keeping \u2018Should\u2019 Separate From \u2018Is\u2019<\/span><\/h3>\n<p><span>Some steps can run in parallel when dependencies allow. A pattern I\u2019ve found valuable is running independent business and system analysis passes.<\/span><\/p>\n<ul>\n<li><i><span>Business analysis<\/span><\/i><span> synthesizes goals, user needs, functional and non-functional requirements and assumptions. Karl Wiegers\u2019 approach can serve as a useful framework, but the specific notation doesn\u2019t matter. What matters is that you, the engineer, understand what was generated and why.<\/span><\/li>\n<li><i><span>System analysis<\/span><\/i><span> examines the existing codebase, services, schemas and constraints to document what is actually there today.<\/span><\/li>\n<\/ul>\n<p><span>These two outputs then feed into architecture synthesis, where the LLM reconciles requirements with real capabilities and highlights the interesting contradictions \u2014 exactly where real design decisions live.<\/span><\/p>\n<h3><span>The Engineer\u2019s Evolving Role: Return of the Combi-Shaper<\/span><\/h3>\n<p><span>About 30 years ago, almost every software engineer was what we\u2019d now call a <\/span><i><span>combi-shaper<\/span><\/i><span> \u2014 someone who lived with the customer\u2019s 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.<\/span><\/p>\n<p><span>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.<\/span><\/p>\n<p><span>In the LLM era, I believe we\u2019re 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.<\/span><\/p>\n<p><span>With Waterfall 2.0, the work shifts from writing artifacts to curating the corpus, orchestrating the LLM\u2019s roles and making final trade-off decisions. LLMs don\u2019t replace business analysts, system analysts, architects, developers or QA \u2014 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.<\/span><\/p>\n<h3><span>The Abstraction Ladder<\/span><\/h3>\n<p><span>This shift is simply the next rung in a long progression:<\/span><\/p>\n<ul>\n<li><span>Machine code \u2192 assembly<\/span><\/li>\n<li><span>Assembly \u2192 C (compilers handle optimization)<\/span><\/li>\n<li><span>C \u2192 higher-level languages and frameworks<\/span><\/li>\n<li><span>Hand-written code \u2192 libraries and open ecosystems<\/span><\/li>\n<li><span>Now: LLM-assisted engineering (mental models \u2192 artifacts \u2192 code, with heavy automation)<\/span><\/li>\n<\/ul>\n<p><span>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 \u2014 a sloppy mental model now produces convincing but wrong outputs at scale. That\u2019s exactly why the stage-gated checkpoints still matter.<\/span><\/p>\n<h3><span>Conclusion<\/span><\/h3>\n<p><span>LLMs do not replace programmers. They shift the level of abstraction at which we work.<\/span><\/p>\n<p><span>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.<\/span><\/p>\n<p><span>The method isn\u2019t limited to code \u2014 it generalizes to any domain where outputs must stay coherent, traceable and grounded in reality.<\/span><\/p>\n<p><span>Waterfall wasn\u2019t dead; it was just waiting for machines that could write (and rewrite) code fast enough.<\/span><\/p>\n<h3><span>Key Takeaways<\/span><\/h3>\n<ul>\n<li><span>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.<\/span><\/li>\n<li><span>The five-stage pipeline \u2014 <\/span><i><span>vision, ADR, prototypes, architectural skeleton, code + tests<\/span><\/i><span> \u2014 builds a cumulative knowledge corpus that gives the LLM enough context for coherent system-wide generation.<\/span><\/li>\n<li><span>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.<\/span><\/li>\n<li><span>The engineer\u2019s role shifts to a <\/span><i><span>combi-shaper<\/span><\/i><span>: Context manager, validator and trade-off decision-maker across the full stack. LLMs handle most generation, while the humans ensure quality and coherence.<\/span><\/li>\n<\/ul>\n<p><a href=\"https:\/\/devops.com\/waterfall-2-0-controlling-llm-driven-software-development-with-stage-gated-discipline\/\" target=\"_blank\" class=\"feedzy-rss-link-icon\">Read More<\/a><\/p>\n<p>\u200b<\/p>","protected":false},"excerpt":{"rendered":"<p>Waterfall is dead \u2014 it was killed by Agile. At least, that\u2019s what people believed for the last 15\u201320 years. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4892,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[5],"tags":[],"class_list":["post-4891","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4891","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=4891"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/4891\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media\/4892"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=4891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=4891"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=4891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}