The Cascade

The cascade

Section 2 of the method. A cheap model drafts, a cheap critic reviews, the strong model sees only what stays open.

The cheap model drafts every tier. Before a change is opened, the preflight script runs the holdout check: the change description names the production hunk each new test depends on, the script holds that hunk out and rebuilds, and the named tests must fail. A test that passes either way is a gate failure, not a nit.

Read section 10 before you trust that paragraph. It described a script I had not written for two weeks, and the critic below answered question 1 yes over a revert that never happened.

It answers the question when the hunk can be removed without breaking a reference to it. Holding a hunk out is a revert, so the tree has to still compile afterwards or no test runs and the answer is inconclusive. That rules out a file the change adds outright, and it rules out a new method other code already calls. It does not rule out large hunks: one 197 line hunk held out cleanly, because what it replaced was self-contained, while a 41 line new method failed because the file called it three lines later. Size is not the predictor. Whether anything else refers to the code is.

In practice that means a change to code that already existed, which is most bug fixes and most hardening work, and not a greenfield feature. Six runs on one repository: three passed, three were inconclusive, and every inconclusive was a hunk something else referred to.

A second cheap agent, fresh context, reviews every change in a checked-out copy it can build and run. Six questions, each answered yes or no with the line that proves it:

1. Did the holdout check run, and is its output on the change? Not "was the hunk reverted", which an agent can answer from the description alone.
2. Is every new route in every inventory, with the gate the issue asked for?
3. Does every session and raw query in the change name its tenant?
4. Does every new document, event or index have a migration or an upcaster?
5. Does anything from an exception, a request or a user string reach a log or a response unexamined?
6. Does any read-then-write on a shared row, or any outbound call to a URL that is not a constant, name its lock or its bound?

One more question is asked of every change, outside the six: for each rule in the diff that branches on a type or a value, which kinds can it meet (value type, string, class, interface, abstract class, nullable, a member with a non-null initializer), and was each one checked? It was added after three defects of one shape reached the review bots in two of three changes: a rule tested with one kind of type and broken on another.

The expensive model takes the branch and the critic's list only when a no is not fixed in one round, or when a tier 2 answer is unsure. It does not start over.

Which model is which is a setting, so the cascade outlives any one model release:

Step	Model
Spec review of a bigger ticket (0)	cheap
Locate the code a draft or spec review needs	fast
Draft, every tier	cheap
Critic: hunt, then refute	cheap, two fresh agents
First fix round (5)	cheap, the same drafter resumed
Run the gates and paste their output (preflight, holdout, tests, a CI log)	fast
Retro fact collection (lean-stats collect and report, retro-signals.sh)	fast
A no not fixed in one round, or an unsure tier 2 answer	strong

LEAN_MODEL_CHEAP defaults to sonnet, LEAN_MODEL_STRONG to opus and LEAN_MODEL_FAST to haiku, which Claude Code resolves to its current Sonnet, Opus and Haiku. Swap or replace them in the env block of your settings. They cover the agents a session starts; the session itself runs on whatever /model says.

The fast model only reads and reports. A gate agent pastes what the script printed, and a pass or fail is whatever the script said. A small model that wrongly refutes a finding drops a real defect with no trace, so nothing that answers a yes or no about code runs on it. Anything a fast agent cannot answer by quoting output goes to the cheap model.

Your continuous integration and whatever code review bot you use still run. They confirm. They do not decide.

---

Previous: Triage inline, no agents | Home | Next: The diff decides whether a critic runs