Stage Gates Got Cheap Again, And That Is The Whole Argument For "Waterfall 2.0"

A devops.com essay argues that waterfall is becoming useful again in the LLM era, not as heavyweight ceremony with endless approvals but as a lightweight control structure for fast AI-generated work ^[1]. The part that should interest operators is economic rather than methodological: the author says a single iteration no longer takes months of team effort and can instead take hours or a couple of days with one skilled engineer ^[2].

The proposed pipeline is the familiar sequence with new tooling behind it: vision, architecture decision records, prototypes, an architectural skeleton, then code plus tests ^[3]. The author gives timings for a bounded but meaningful slice of work: roughly 30 to 60 minutes for the vision document, and two to three hours to generate ADRs for the major components ^[4][5]. Taken together, that puts the first two gates at about two and a half to four hours ^[6]. Under those numbers, discarding a vision and its ADRs and regenerating both costs less than a working day, which is the actual mechanism at work here. Stage gates were never disliked because they were wrong. They were disliked because the artifacts behind them were expensive to produce and ruinous to redo.

That is why the author treats backtracking as a strength rather than a failure: LLMs can regenerate earlier artifacts quickly, making it practical to revisit assumptions without weeks of rework ^[7]. Contrast the original failure mode. Classic waterfall ran requirements to architecture to implementation to testing to release, and its problem was slow feedback and extremely expensive fixes when errors surfaced late, as Frederick Brooks illustrated in The Mythical Man-Month ^[8]. Agile addressed that late truth by shrinking batch sizes and accelerating feature-level feedback ^[9]. The essay's counterpoint is that in meshes of interdependent services, shared data platforms and globally imposed constraints, purely incremental approaches can produce fragmented architecture and compounding technical debt ^[10].

Two dependencies carry the weight. The first is a shared knowledge corpus that brings requirements, ADRs, source code, schemas, diagrams and telemetry into one context ^[11]. The second is the human: the engineer's role shifts toward orchestration and validation, managing context, checking outputs and making trade-off decisions ^[12]. The author credits four 2025 developments for making this practical, including context windows of up to a million tokens, extended-thinking reasoning modes, and tool connectivity via the model context protocol, which together let one LLM session behave like a small, well-coordinated engineering team ^{[13][14][15][16]}.

Note what the evidence is. The author reports using the setup repeatedly on real integration programs, where weeks of synchronization now happen inside one extended session with good context management ^[17], and describes each stage running through an LLM at orders of magnitude higher speed ^[18]. That is practitioner experience, not comparative measurement, and the cost curve it implies cuts both ways: artifacts cheap to regenerate are also cheap to produce wrong, and the only stated defence is the validating human ^[12].

Watch three things. Whether the corpus stays current, because telemetry and schemas rot faster than vision documents ^[11]. Whether validation throughput, not generation throughput, becomes the constraint once one engineer owns all five gates ^[12]. And whether anyone publishes timings for the last three stages to match the 30-to-60-minute and two-to-three-hour figures given for the first two ^[4][5].