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 that the prompt sits inside.

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. PR count used to be vanity. With agents it is the load that verification has to keep up with.

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

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 is what Flow-Next builds - 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.

The verification gap

The industry’s own numbers describe the paradox: 96% of developers do not fully trust that AI-generated code is functionally correct, yet only 48% always verify it before committing (Sonar, 1,100+ developers surveyed). Everyone knows generated code needs checking; half of everyone actually checks. The gap between the two is where production incidents come from.

The answer here is structural rather than motivational. The harness does not remind you to verify, it refuses to advance without proof. A task cannot complete without evidence, a review cannot pass without a verdict artifact, and a merge cannot happen on narration alone. How work gets proven walks that system stage by stage.

The lineage

Bias towards verification did not appear from nowhere. It sits on a line of thought the field has been converging on:

• Jason Wei’s verifier’s law - the observation that tasks easy to verify get solved by AI first, because verification asymmetry is what makes training and trusting a system tractable. Flow-Next applies the law in reverse: make every stage of engineering easy to verify through receipts, numbered criteria, and evidence files, and agents become trustworthy on it sooner.
• Andrej Karpathy’s generation-verification loop - his framing that humans and agents alternate generation and verification, and the product’s job is to make verification fast, plus his autonomy slider: give up autonomy only as fast as verification keeps up. The autonomy dial below is that slider made concrete, with the same gates at every rung.
• Werner Vogels’ “verification debt” - his re:Invent 2025 warning that AI generates code faster than teams comprehend it, and the unreviewed remainder accrues like technical debt. Receipts and evidence JSON are amortization: the debt is paid per stage, never rolled over.
• Simon Willison’s “code proven to work” - his rule that your job is to deliver code you have proven to work, because shipping unproven code shifts the real work onto whoever reviews it. Flow-Next generalizes the rule from the person to the pipeline: every handover ships with its proof attached.

The diagnosis belongs to them, along with SlopCodeBench’s measurements above. What is built here is the working system: a pipeline where the verifying is done by construction.

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

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

• 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

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 hold

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

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 you are actually installing

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.