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, without slowing the work down. Across more than 170 full end-to-end runs, each case run several times, the change comes back in about the time plain Claude Code, or your harness, takes, often less. The result is better than the plain agent’s even before any review; the optional stages (cross-model review, live QA) widen the gap to up to 25% better outcomes, especially on large and long-horizon work. /flow-next:flow picks the route and adds a stage only where the risk calls for it.

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 reviewer from another model family on every change whose risk calls for it, 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 risky change so uncorrelated blind spots cancel.

The Flow-Next answer

• Spec-driven work: anything beyond a small local fix belongs to a durable .flow/specs/<id>.md
• Re-anchoring: every task starts by rereading spec, task, and git state
• Fresh context: on a spec with several tasks, worker subagents avoid contamination from previous attempts
• Cross-model review: a second model family reviews each change by its risk, and the plan when you ask or a design risk is named
• Receipts: state transitions are backed by artifacts, not promises
• PR briefing: 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 reviews each risky change automatically, attended and inside the autonomous drivers (flow --auto and land), 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:refine --biz (refine, the interview)
Technical design chat	/flow-next:refine --tech
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. One /flow-next:flow --auto run on a ready spec runs the same stages, the same configured reviews, and the same receipts as one attended /flow-next:flow run at the keyboard, because both read the same routing references. Land merges only PRs whose CI is green and whose review threads have converged. The evidence JSON at task completion, the review verdict from the backend you configured, and the green receipt keyed to the exact commit apply whether you are watching one task or a hundred. Review is configured, never unconditional. Its independence holds only when review.backend names a model family that did not write the diff, and every skip is recorded rather than silent: skipped(config: review=none), a qualifying flowctl triage-skip receipt, or the single-task completion-review skip.

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

Set the autonomy boundary in project policy. flow --auto works the ready backlog without asking, records every decision it made in the PR, and opens PRs ready for review unless they carry open items. You can review and merge those yourself, or authorize land to finish them under your CI and review rules. Unresolved product decisions still come back to you. Unattended operation explains readiness and stop conditions. One conductor sits at both ends of the dial, attended at the keyboard and --auto when nobody is there; what shipped and what comes next is on Flow and the road ahead.

Where this sits next to ATDD and BDD

Flow-Next records acceptance criteria as numbered prose in the spec and asks review to judge them against evidence. That evidence can include executable tests, compatibility checks, a live QA pass, or inspection of release notes. Each criterion keeps an identity that the tasks and PR can reference.

Teams using Given/When/Then criteria can keep that format in their spec template and attach the corresponding tests as evidence. Criteria that need human or model judgment remain visible alongside them. Writing specs explains the template and requirement mapping.

What you are actually installing

Flow-Next is a plugin inside your coding agent. The plugin supplies skills and a bundled CLI; your repository holds specs, tasks, memory, and receipts under .flow/. Your agent provider runs the models, and your existing Git host and CI handle pull requests and checks.

You keep product judgment, risk tolerance, merge policy, and production responsibility. The spec names the intended behavior; the PR brings the evidence for your decision. See installation for prerequisites and uninstall instructions for removing the plugin while preserving project history.