mini-cascades. a way of building software with humans and agents in the loop.
steerdev's methodology is a small set of opinions about how software gets shipped when implementation is no longer the bottleneck. it is not a framework, a certification, or a religion. it is a working draft — the shape that produced good results for us, written down so others can try it, push back, and improve it.
the bottleneck moved. the methods didn't.
most of the rituals on a modern engineering team — the standups, the story-pointing, the sprint cadences, the line-by-line code reviews — were designed for a world where writing the code was the slow, expensive step. that world is fading. capable agents now write usable code in minutes. the new slow steps are different ones: deciding what to build, decomposing it cleanly, and proving it works.
we tried bolting agents into the old rituals. it didn't work. PRs got bigger. reviews got worse. specs stayed in slack. agents shipped confidently wrong code that humans rubber-stamped because there was too much of it. the rituals were optimizing for the wrong thing.
mini-cascades are our attempt at rituals optimized for the new bottleneck — judgment over typing.
writing code was never the real bottleneck. understanding what to build and proving it works were always the hard parts. AI shifted where the effort lands — less of it on typing, more of it on the parts that always mattered. generate ten times the code and you need ten times the clarity upfront, ten times the rigor afterward.
three converging, one diverging, one converging again.
a mini-cascade is one trip through these five phases. iterations are scoped by risk, not the calendar — small low-risk changes can run a whole cycle in an afternoon; big architectural shifts get the time they need. the shape, though, is always the same.
agree on what to build, before anyone writes anything.
a PRD captures intent — a problem, a constraint, a definition of done. it's authored by humans, often with an agent helping draft. the artifact is small and reviewed; it is not a placeholder for a slack thread.
expand intent into feature specs.
each problem decomposes into one or more feature specs: bounded units of behavior with explicit interfaces and known unknowns. AI helps draft and pressure-test. humans approve. the cost of a bad spec compounds; we pay it here, on purpose.
turn feature specs into implementation specs and task waves.
features become implementation specs (the contract for the change) and tasks (the work). tasks declare their dependencies on each other. independent tasks run as a wave. blocked work is visible, not pretended-around.
the only diverging phase. parallel agents execute.
this is the only phase where breadth matters more than alignment. an agent picks up a task, executes against the implementation spec, produces evidence. multiple agents work the wave in parallel. they don't need to agree on style or approach — only on the contract their task declared.
collapse parallel work into a reviewable PR with evidence.
the cycle closes here. evidence is assembled: tests, screenshots, traces, the agent's own narration of decisions. humans review the evidence, not the diff. low-risk waves get a quick approval; high-risk ones get an explicit verification plan written before phase 04 even started.
what one cascade actually looks like. ten working days, day by day.
the shape is universal but the rhythm matters. here's how a typical cascade unfolds for a team of four engineers, a product manager, and a product owner. roughly forty-five percent of the cycle goes to planning, thirty to implementation, twenty-five to verification — the opposite of how most agile teams allocate time.
two notes. first: the cadence is not sacred. low-risk changes can run the whole loop in an afternoon; an architectural shift might take three weeks. the shape stays. second: the build phase is the only one where humans aren't doing the typing. that's the point.
we review specs hard. we focus on the code that matters.
traditional teams review code obsessively and treat specs as a formality. when an agent produces eight hundred lines in twenty minutes, that ratio stops working. we redistribute the effort: significant review happens before any code exists, we read core and high-risk code closely, and the rest is reviewed through evidence — tests, traces, screenshots.
traditional · agile/scrum
most effort lands at the end, after the code is writtenmini-cascade · steerdev
effort spread across the cycle, weighted to where it pays offcascades overlap. the team is always shipping while always planning the next thing.
a single cascade is a closed loop, but a team running cascades back-to-back would idle half the staff during build phases and the other half during planning. so cascades pipeline. while cascade A is in build, cascade B starts its PRD. while A verifies, B is writing specs. the org runs two to three cascades in flight at any time, staggered so the work never bunches.
the practical effect: the team is always shipping while always planning. no two-week ceremony stalls. no end-of-sprint crunch. the engineer who finished steering wave two on cascade A spends day ten writing the PRD for cascade C.
not anti-agile. post-agile.
we keep what worked: short cycles, iterative improvement, frequent shipping, retros that change behaviour. we drop what doesn't survive contact with agents in the loop: ceremony overhead, synchronous coordination as the primary mechanism, the article-of-faith that documentation is bureaucratic drag.
the question isn't whether agile dies. it's whether what replaces it still deserves the name. when sprint planning becomes intent design, standups become shared agent context, and code review becomes evidence review — that's a different methodology with the old branding.
seven commitments. not a framework, just the load-bearing ones.
specs are first-class artifacts.
PRDs, feature specs, and implementation specs are versioned and linked, not pasted into slack. agents read them. humans review them. they are the substrate the rest of the work runs on.
agents diverge. humans converge.
parallelism happens during build. judgment — what to build, whether it works — stays with humans. structure the workflow so neither party is doing the other's job.
risk sets the cadence.
a copy tweak ships in two hours. a payments refactor takes a week. let the work's risk drive the iteration length, not a fixed sprint.
prefer reviewing evidence, not diffs.
when an agent produces 800 lines of code, auditing every line breaks down. the agent must produce evidence — tests, traces, screenshots, an explanation. lean on that, while still reading core and high-risk code closely.
be agent-agnostic on purpose.
the agent landscape will keep shifting. the methodology shouldn't. structure your workflow so swapping agent vendors is a configuration change, not a re-architecture.
the spec is the api between humans and agents.
when communication is fuzzy, agents make confident wrong decisions. specs make the contract explicit. write them well; revise them when they fail.
agents should be proactive, not reactive.
if a human has to command every step, the human becomes the bottleneck. proactive agents take initiative — pick up the next task, run verification, surface evidence — guided by workflows and tools that let them act whenever they can.
things we used to do. things we stopped doing.
treating an agent like a faster typist.
if you're prompting an agent the same way you'd ask an intern to bang out a feature, you're wasting most of its leverage and absorbing all of its risk. specs first.
one giant PR with 4,000 lines of "AI did it".
no human can review that meaningfully. either decompose into smaller waves with their own evidence, or accept that "review" became "trust".
fixed two-week sprints for AI-driven work.
sprints calibrate humans against humans. with agents in the loop, batch sizes are wrong by an order of magnitude in either direction. let risk drive the cycle.
one "agent of record" lock-in.
the model that's best today probably isn't in six months. methodology should outlast any specific vendor.
PRDs as slack threads.
if the spec lives in chat, the agent can't read it, the next engineer can't find it, and the conversation is the artifact. unsustainable.
we don't have all the answers.
this methodology has produced good outcomes on real work. it has also raised questions we haven't fully answered. a few we're still chewing on:
- how big should a wave be? we have heuristics, not a formula. teams running larger waves (10+ tasks) report different failure modes than smaller ones (3–5).
- what's the right cadence for refactoring an agent's output? agents leave a particular flavor of inelegance. we're learning when to refactor inline vs. accept the debt vs. discard the work entirely.
- how do you onboard humans into this? engineers joining a steerdev team don't have a 20-year tradition of tutorials to lean on. the apprenticeship is being figured out cycle by cycle.
- what does this look like beyond software? we suspect the same shape — converging specs, diverging execution, converging evidence — generalizes. we haven't proven it.
if you have answers, opinions, or war stories, we'd love to hear them. this page will be revised as we learn — that's part of the methodology.
one methodology. three ways to start.
all three flow through the same mini-cascade methodology. pick the one that fits your team's shape.