The Waterfall Trap
439 stars for a framework that moves in one direction. Software doesn't.
The Waterfall Trap
You have seen this before. Five boxes. Five arrows. All pointing down.
Specification. Pseudocode. Architecture. Refinement. Completion. S, P, A, R, C. A framework with 439 GitHub stars, a working pip install, and a bold claim: bring structure to the chaos of AI-assisted development.
The problem is not the structure. The problem is the direction.
Familiar Ground
The impulse is understandable. AI coding tools are powerful and undisciplined. You open a chat, describe a feature, and the model generates code. Some of it works. Some of it contradicts what you built yesterday. There is no plan, no sequence, no architecture. You are improvising with a collaborator who has no memory.
So someone builds a framework. “Do these five things in this order.” Specify first. Write pseudocode second. Design architecture third. Refine fourth. Deploy fifth. Each phase produces documentation. Each phase includes reflection. The chaos gets a spine.
This is not a new invention. This is the waterfall model, published by Winston Royce in 1970, dressed in LLM-provider flags and a Python CLI.
Counter-Signal
SPARC, standing for Specification, Pseudocode, Architecture, Refinement, and Completion, is an open-source framework by Reuven Cohen. It has 320 commits, 10 contributors, support for Anthropic, OpenAI, and OpenRouter, and a “cowboy mode” for autonomous execution. It even claims “quantum-coherent complexity management” and a “pseudo consciousness integration.”
Strip away the quantum terminology (which has no implementation behind it) and you find a linear process model applied to AI coding. Phase S feeds Phase P. Phase P feeds Phase A. Phase A feeds Phase R. Phase R feeds Phase C.
What is missing? The arrow from C back to S. The feedback loop. The thing that makes a system alive.
Software revealed 25 years ago that the waterfall does not work. The Agile Manifesto was a direct rejection of phase-gate thinking. Not because structure is bad, but because linear structure assumes you know the destination before you begin. AI-assisted development makes that assumption even less tenable, because the model discovers the architecture through prototyping, not before it.
⚛️ The Fusion
Three ideas collide here.
The waterfall model assumed that each phase of development could be completed before the next begins. That requirements could be fully specified, architecture fully designed, code fully refined, all in sequence. Royce himself, in the very paper people cite, called this approach “risky and invites failure.” He recommended feedback loops. The industry heard only the cascade.
AI coding frameworks like SPARC inherit the linearity. They add LLM orchestration, multi-provider support, and real engineering value. But the cognitive model underneath is unchanged: think first, then code, then refine, then ship. The AI executes within phases. It does not reshape them. The framework tells the AI what to think about, not when to question the plan.
Living cognitive systems work differently. They move in circles, not lines. Explore a problem, forge a solution, audit the result, learn from the gap, explore again. The output of one cycle reshapes the input of the next. Goals shift. Architecture emerges. The system adapts because the structure permits adaptation.
What if you could see a coding framework not as a sequence of phases, but as a compass? Not “do S, then P, then A, then R, then C,” but “where are you now, and which cognitive verb do you need next?”
| Waterfall Framework | Living Framework |
|---|---|
| 5 phases, one direction | Circular verbs, any direction |
| Specification precedes architecture | Architecture emerges through exploration |
| Refinement is a phase before completion | Refinement is continuous, never “done” |
| Feedback loops are implicit (or absent) | Feedback loops are the architecture |
| AI fills in boxes | AI reshapes the map |
| Completion is the destination | Learning is the destination |
The New Pattern
The pattern is not “SPARC is wrong.” SPARC contributes something real: the idea that methodology can be installable. pip install sparc is a genuine innovation. One command, and you have a structured approach to AI-assisted development. That is worth studying.
The pattern is: linearity is the wrong geometry for intelligence.
A system that can only move forward cannot recognise when the specification was wrong. Cannot loop back to redesign after the refinement reveals a flaw. Cannot learn from deployment and feed that learning into the next specification.
SPARC’s real contribution, its CLI engineering and multi-provider orchestration, deserves to live inside a circular model. The tools are good. The direction needs to turn.
Every framework you adopt shapes how you think. A linear framework trains you to think in sequences. A circular framework trains you to think in cycles. Choose the geometry that matches your problem.
Software development is not a river flowing downhill. It is weather: patterns forming, dissolving, reforming. The compass, not the cascade, is the instrument you need.
The Open Question
If your framework cannot tell you when to go backwards, how do you know you are moving in the right direction?
This fusion emerged from a STEAL on ruvnet/sparc (GitHub, March 2026). The research that grounded it lives in frameworks/sparc-framework/research.md.