“Waterfall strikes back”: our response, point by point

225 points and 191 comments: the Hacker News thread accusing spec-driven development of reviving waterfall made an impression. Three precise criticisms, a quantified response, with no evasion.

A Hacker News thread titled ‘Spec-Driven Development: The Waterfall Strikes Back’ received 225 points and 191 comments (news.ycombinator.com/item?id=45935763). The accusation: writing a specification before code brings back the evil that agile had driven out. Three precise criticisms emerge. Here is our response, without dismissing any of them.

Criticism 1: ‘the spec becomes a mess as the project progresses’

True for a single spec that grows indefinitely. At Maestro, nothing is written in one block: the brief, specification, architecture and story breakdown are short, separate documents, each approved before the next through a human approval, the ‘Looks good to me’. A document that grows too large is reworked before proceeding; it is never piled onto the earlier ones. That principle produced a ratio of around ten between our method and BMAD-METHOD for injected methodological context: restraint is not an extra, but the starting constraint.

Criticism 2: ‘hours without seeing code, no iterative feedback’

This is the fairest criticism of classic big design upfront. Our response is structural: after the breakdown, development and verification run story by story, never across the whole product at once. Feedback arrives at story scale, a few minutes to a few hours, not at the end of weeks of work. In our measurement campaigns, a complete product crosses the finish line for a few dozen dollars in a handful of hours, rather than days without news.

Criticism 3: ‘the LLM is a non-deterministic compiler’

This hits the mark and cannot be solved through rhetoric. Our response: bound non-determinism with tests written BEFORE the code, the verification contract is fixed at the breakdown stage, and flag any test the agent alters during repair, including pre-existing ones. The model remains probabilistic; what it must satisfy no longer is. It is the same measurement principle that led us to derive every method version from a defect found by a jury, never an intuition.

What the generic defence leaves out

Martin Fowler compared Kiro, Spec-Kit and Tessl without choosing between them (martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html), and the github/spec-kit repository shows 130,054 stars (api.github.com/repos/github/spec-kit, checked August 18, 2026): spec-driven development is a movement, not yet an architecture proven against its own criticisms. Defending the thesis without measuring what changes in practice leaves the HN thread's counterattack without a concrete response.

What our figures say

In campaigns between our method and BMAD-METHOD, the open reference closest to classic document-heavy waterfall, large PRD, numerous stories, thin delivered code, the gap widens precisely where the thread's three criticisms point: less dead context, story-by-story feedback, and code that passes its own tests rather than documents describing an intention.

What we concede

A spec-as-source that is never broken down or approved in small pieces does deserve to be charged with waterfall. Ours escapes only because every stage is small, disposable and judged on what it produces rather than what it promises. The HN thread was right to distrust a specification becoming a project in itself; it had not anticipated slicing it thinly enough that no slice ever becomes a project.