Why Flow-Next
AI agents drift when the work surface is a prompt plus a chat scrollback. They forget requirements, overfit to recent context, and produce diffs that are expensive to review.
Flow-Next fixes the operating model, not just the prompt.
The bottleneck moved
Section titled “The bottleneck moved”AI makes code cheaper to produce. That shifts pressure to requirements, review, verification, and coordination. Traditional Agile touchpoints were designed for human-paced implementation, where unclear work could be corrected during a two-week cycle.
Agentic work does not have that safety valve. The spec must carry the weight.
flowchart TB Old["Human-paced delivery"] --> Loose["Loose ticket"] Loose --> Touchpoints["Standups, refinement, design review, PO chats"] Touchpoints --> Corrected["Corrected implementation"] New["Agent-paced delivery"] --> Precise["Precise spec"] Precise --> Fast["Fast implementation"] Fast --> Reviewable["Reviewable receipts and PR"]
The measured problem
Section titled “The measured problem”SlopCodeBench (Orlanski et al., Mar 2026) measures what happens when an agent extends its own prior code across 93 checkpoints. Each checkpoint hands the agent a specification that fixes external behavior only, hides the tests, and carries nothing over from the conversation before it. That is the shape of maintenance work.
Across 11 models, no agent solved a single problem end to end. The best strict pass rate was 17.2%, and it fell to 0.5% by the final checkpoint. Code quality degraded in 80 to 90% of trajectories. Cost per checkpoint grew 2.9x and bought no correctness. Against a panel of 48 maintained open-source repositories, the agent code ran 2.2x more verbose, and the gap widened every iteration while the human repositories stayed flat.
The paper then tested the cheapest available fix and ruled it out. Quality-aware prompts lowered initial verbosity by about a third, changed the rate of decay not at all, left every pass-rate subtype statistically unchanged, and cost up to 48% more. Better instructions do not survive iteration.
The authors name one intervention they did not test: enforcing structural discipline across checkpoints, through training or through tooling. That sentence describes Flow-Next. Gates the agent cannot skip, a different model reviewing every handover, and a receipt keyed to the commit behind every claim of done. The paper does not test Flow-Next, and nothing here claims it does. It establishes something narrower and still decisive: the decay is real, and the cheap fix for it does not work.
Setup, results, and the full boundary between what the paper shows and what we claim: Evidence.
Non-determinism makes precision non-optional
Section titled “Non-determinism makes precision non-optional”LLMs are non-deterministic. Give an agent a vague or inaccurate description and you do not get one wrong result, you get a different wrong result every run. Precision is what makes the output stable: a reviewed, source-tagged spec that the agent rereads each time is how the same intent produces the same work twice, instead of a fresh guess.
Agents forget, and one model has blind spots
Section titled “Agents forget, and one model has blind spots”No matter how good the model or the harness, agents drop things. They forget to update the docs you asked for, half-finish a task, or quietly skip a step. And every model family has blind spots in planning and implementation that same-family review tends to miss twice. Flow-Next answers both: enforced completion with receipts so nothing is silently dropped, and a different model reviewing each artifact so uncorrelated blind spots cancel.
The Flow-Next answer
Section titled “The Flow-Next answer”- Spec-driven work: every task belongs to a durable
.flow/specs/<id>.md - Re-anchoring: every task starts by rereading spec, task, and git state
- Fresh context: worker subagents avoid contamination from previous attempts
- Cross-model review: a second model checks plan and implementation
- Receipts: state transitions are backed by artifacts, not promises
- PR-as-cognitive-aid: reviewers get acceptance coverage and focus paths
Cross-model review itself is not new; people have paired one model against another as a reviewer for a while. What Flow-Next did early was wire autonomous adversarial cross-model review into the loop: a different model challenges every plan and implementation automatically, at each handover and inside the autonomous modes (pilot, land, and Ralph), rather than as a manual pass someone has to remember to run. That is what lets you ship the loop’s output with confidence.
The touch-point collapse
Section titled “The touch-point collapse”Before agents, a rough ticket could survive because the team finished the requirement during implementation. Daily conversation, pairing, Slack threads, design review, and ad-hoc product clarification filled in what the ticket missed.
When an agent can ship the task in one sitting, those touchpoints are gone. That does not make collaboration less important. It means collaboration has to move into explicit artifacts before the run starts:
| Missing touchpoint | Flow-Next replacement |
|---|---|
| Refinement meeting | /flow-next:interview --scope=business |
| Technical design chat | /flow-next:interview --scope=technical --strategy --docs |
| Developer breakdown | /flow-next:plan |
| Senior review of approach | /flow-next:plan-review |
| Pairing and course correction | Re-anchored /flow-next:work tasks |
| Human pre-review | /flow-next:impl-review |
| PR explanation | /flow-next:make-pr |
The artifact chain is not bureaucracy. It is the conversation that would otherwise be missing.
The dial goes all the way, and the gates never move
Section titled “The dial goes all the way, and the gates never move”Teams adopt agents in a predictable order. One engineer pairs with one agent and reads every line it writes, because nothing else has checked it yet. Once a self-verifying loop earns enough trust, that same engineer runs several agents at once across separate worktrees and reviews the diffs instead of the keystrokes. Eventually a long-running loop drains a whole backlog on its own, and the engineer sets the targets and looks only at what needs a human.
Flow-Next runs at every point on that path with one property that stays fixed: the gates. /loop driving pilot across a ready backlog fans out the same workers, the same cross-model reviews, and the same receipts as a single interactive /flow-next:work. Land merges only PRs whose CI is green and whose review threads have converged. The evidence JSON at task completion, the SHIP verdict from a different model, the green receipt keyed to the exact commit: all of it fires whether you are watching one task or a hundred.
| As you climb | What changes | What holds |
|---|---|---|
| One agent, supervised | You read every diff | spec, receipts, cross-model review |
| Several agents in parallel | You review diffs instead of keystrokes | same gates, per stream |
| A loop draining the backlog | You set intent and check the exceptions | same gates, per tick |
The failure teams hit is turning the dial past what their loop has earned: more agents feeding a review process nobody trusts, which becomes a queue, then a rubber stamp, then defects in production. Flow-Next’s answer is that climbing the dial changes how much you watch. It does not change how much gets verified. Even at the top of the range the human keeps the parts that are theirs: a spec is picked up only once someone marks it ready, the judgment stages never run themselves, and every autonomous run ends at a draft PR for a person to merge. You get full autonomy at the same quality bar as the first supervised pair.
Where this sits next to ATDD and BDD
Section titled “Where this sits next to ATDD and BDD”Acceptance-test-driven development also anchors work to acceptance criteria written before any code, so the two get confused. The difference is what a criterion is allowed to be. ATDD requires each criterion to exist as an executable test up front: the suite is the contract, and done means green. Flow-Next keeps the criterion as prose in the spec (an R-ID) and has a reviewing model judge it against evidence: focused tests, receipts, review verdicts, a QA pass against the live app. Tests are evidence for acceptance, never the definition of it.
That choice is deliberate. Many real acceptance criteria have no executable form (“the public API stays backward compatible”, “the release notes lead with the user outcome”). A judged criterion carries those; a test-only contract silently drops them. Where a criterion does have an executable shape, write the test, and the evidence JSON records it. Teams that want Given/When/Then criteria can bake that into their spec template: see writing specs.
What it is not
Section titled “What it is not”Flow-Next is not a hosted dashboard, SaaS tracker, Jira replacement, or CI runner. Everything lives in the repo under .flow/. Uninstall is rm -rf .flow/.
It also does not remove human ownership. Humans still own product judgment, risk tolerance, merge decisions, and production responsibility. Flow-Next makes those decisions easier to verify because the evidence is structured.