Evidence & evals
Flow-Next is faster on the actual work than a plain agent and better on the result, and both halves are measured. This page gives our benchmark first, then the field record, then the published research that explains why verification matters, then the evals we ran on our own changes.
Flow-Next against a plain agent
Section titled “Flow-Next against a plain agent”Measured over more than 170 full end-to-end runs against plain Claude Code, or your harness, on the same model, each case run several times: a simple bug, a hard bug, a small feature and a large feature, attended and unattended, plus a held-out large feature from a repository and stack the tuning never touched. Hidden tests the agent never sees check every result, and a blind judge scores the handoff.
On the actual work, the change comes back in about the time the agent alone takes, often less, and large features in about half the time. The result is better than the plain agent’s even before any review: on the simple bug, where review is skipped by risk and there is no QA, the blind judge still scores Flow-Next about 10% higher. 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.
Large feature
up to 1.9×faster than the default harness
+25%better result, blind-judged
Three cross-model reviewers
Plain Claude Code shipped a data-integrity bug in every run. Flow-Next's reviewers caught it every time, before the pull request.
Held-out large feature (Rust)
1.2×faster than the default harness
+48%better result, blind-judged
Three reviewers, then the repo's full test suite
Four real bugs fixed, including a race condition. Flow-Next passed every hidden test; plain Claude Code failed one run in three.
Hard bug
about 2×faster than the default harness
+9%better result, blind-judged
Three cross-model reviewers
Found the real cause and fixed it there, instead of loosening the flaky test.
Simple bug
1.2×faster than the default harness
+10%better result, blind-judged
No review: a small, local fix
Better even without review: a failing test first, a fix at the cause, then a check that it works for the user.
Small feature
1.1–1.3×faster than the default harness
+8%better result, blind-judged
One cross-model reviewer
The reviewer caught a setup check the new option broke. Fixed before handoff.
Against the default harness (plain Claude Code, or yours) on the same model. Speed is time to the working change, before any review or QA. More than 170 full end-to-end runs, each case run several times. Hidden tests the agent never sees check every result; a blind judge scores each handoff.
Why the work is fast
Section titled “Why the work is fast”Agents lose most of their time waiting. Flow-Next runs the focused tests for the code it changed while it works, runs the full suite only when your repo or you ask for it, and leaves regressions to CI. Focused tests keep the loop tight, and in the benchmark the hidden full-suite check passed on every Flow-Next run.
You get the working change back first. The cross-model review runs in the background, and any fixes it asks for come after.
When a change has a spec, the discovery has already happened. Capture and refine settle what to build, where it goes and what proves it before anyone writes code, so the build reads the spec and gets to work instead of exploring the codebase from scratch.
The feature map points the agent at the right place. When QA drives the app, or a bug report names a screen like “the export button on the reports page”, the map ties that screen or route to the code behind it, so the agent starts in the right files.
It reads less and asks less. /flow-next:flow picks the route in seconds. A small local fix goes straight to the change with no spec, and a spec with one task is built right in your conversation. Workers only start when a spec has several tasks or you send a task to a chosen model.
And it does only what the evidence asks for: the smallest change that fixes the problem, one fix pass and one re-review of the fixes when you’re there, and the heavier bug-hunting steps (bisect, base and head proof) only when the cause isn’t clear.
Where the quality comes from
Section titled “Where the quality comes from”- The way it works, before any review. It writes the failing test first, fixes the cause and the sibling cases the same cause breaks, tries each error case you named the way you would, and marks every claim in the handoff as measured, inferred or a guess.
- Cross-model review, by risk. A reviewer from another model family checks the change. Risky changes (persisted or shared state, concurrency, security, data layout or migrations, multi-file features) get three reviewers, small ones one, and a change to output, wording or display none, with the reason recorded. After fixes, the same reviewer looks only at what changed.
- Live QA in the running app, where the acceptance describes something you can see.
Unattended. With flow --auto --until=merge, a large feature and a hard bug both went from spec to a merged pull request with nobody watching and no stops, the large feature in about half the time plain Claude Code took. Every decision the run made on your behalf is written into the pull request.
The release notes carry the same table: 7.0.0.
Field standing
Section titled “Field standing”As of September 2026. Flow-Next is the framework at the heart of the engineering methodology used across the portfolio of one of the largest private-equity funds: 1,000+ developers, 100+ product owners and product managers, and 30+ QA engineers onboarded. Teams running that methodology report a 3x speed-up on average across the entire R&D organisation, from discovery to merged code, at a higher quality of output. That figure is self-reported by the teams running it, not an instrumented measurement we can publish, and it is stated here with that bound. The estates behind it: CAD and construction software, proptech, education; modern monorepos and hundred-repo microservice estates beside a thirty-year-old legacy stack migrated on these rails; GitHub Enterprise, GitLab, Jira; Windows in the field.
One unattended run, 38 PRs landed (5 September 2026). A Linux desktop app in a private repo was built through 38 merged pull requests, steered by a single paragraph of standing policy with nobody in the loop. Each item was planned or worked directly by judgment, reviewed by another model family, QA’d in the running app, CI-green, and merged with a receipt. The same policy steered the pipeline shape per item and the model per job. Details: Field case.
Why verification matters: the research
Section titled “Why verification matters: the research”Agent code quality decays under iteration, and the cheapest fix for it has been tested and does not work. Both of those are measured by an independent benchmark.
What the benchmark measures
Section titled “What the benchmark measures”SlopCodeBench (Orlanski et al., Mar 2026) chains an agent across 93 checkpoints of extending its own prior code. It is the closest published proxy for maintenance work: the agent inherits its own decisions and has to keep building on them.
| Element | Setup |
|---|---|
| Task shape | Extend the agent’s own prior code, one checkpoint at a time |
| Checkpoints | 93 |
| Models evaluated | 11 |
| Specification | Fixes external behavior only |
| Tests | Hidden from the agent |
| Context carried between checkpoints | None |
| Human comparison panel | 48 maintained open-source repositories |
What it found
Section titled “What it found”| Measure | Result |
|---|---|
| Problems solved end to end | None, across all 11 models |
| Best strict pass rate | 17.2%, falling to 0.5% by the final checkpoint |
| Trajectories with degrading code quality | 80 to 90% |
| Cost per checkpoint | 2.9x growth, with no gain in correctness |
| Verbosity against the human panel | 2.2x, widening every iteration |
| Human panel across the same span | Flat |
The cost line is the one that reframes the problem. Spending more per checkpoint buys more output and does not buy more correctness, so the decay is not a budget question.
The cheap fix, tested
Section titled “The cheap fix, tested”Telling the model to write better code is the obvious first answer, and it is the one the paper closes off.
| Quality-aware prompting | Effect |
|---|---|
| Initial verbosity | Down by about a third |
| Rate of decay | Unchanged |
| Pass-rate subtypes | Statistically unchanged |
| Cost | Up to 48% higher |
Better instructions improve the first checkpoint and do not survive iteration.
What the paper shows, and what we claim
Section titled “What the paper shows, and what we claim”The authors name one intervention they did not test: enforcing structural discipline across checkpoints, through training or through tooling. Flow-Next is the tooling half of that sentence. Gates the agent cannot skip. A reviewer from another model family on every change whose risk calls for it. A receipt keyed to the exact commit behind every claim of done. Specs, decisions, and evidence as files in the repository, so the next checkpoint inherits a record instead of a scrollback.
The paper does not test Flow-Next, and nothing here claims it does. It establishes two things: the decay is real and measured, and the cheapest alternative to a verification system does not work. The verification spine describes what we built on top of that.
Our own evals
Section titled “Our own evals”The same standard applies to every change we ship. Three results worth publishing, two of them because they went against the design.
The rolling scheduler, chosen against a faster arm. A pre-registered three-arm eval compared work-loop architectures on the same specs. Rolling admission with an isolated worktree per task saved 52.1% of work-phase wall clock at quality parity, with zero uncontained correctness incidents, and shipped. A shared-checkout arm was faster still at 69.2% and failed quality parity: part of its speed was bought with roughly 30% thinner test artifacts, because making the declared-paths list the commit boundary structurally disincentivized new test files and constrained verify windows made test iteration costly. The per-task worktree pool removes both pressures, so the speed is not bought with under-testing. After a field window on three hosts it graduated into /flow-next:work’s default scheduler. Details: work.
PR bodies, judged blind. The make-pr body format was evaluated by blind judging against the previous format: the old body scored 7/10 on reviewer effort and 5/10 on trust; the shipped format scored 9 and 9. Details: make-pr.
The plan-sync skip gate we removed. When planSync.enabled is on (it is off by default), /flow-next:work spawns a plan-sync agent after each wave of completed tasks, to check whether the implementation invalidated a downstream plan. Each spawn costs 70 to 90 thousand tokens. We designed, built, and fully tested a deterministic gate that would skip the spawn when a task provably could not have affected anything downstream.
Cross-repo validation replayed 27 completed-task scenarios from three external repositories against ground truth from the real plan-sync agent. The gate produced a false skip: a change that altered a downstream task’s meaning while touching no file and no symbol that task referenced. Its skip rate was 1 in 15, against a design threshold of 50 percent.
The gate was removed from the shipped CLI. The decision record says not to try again.
Reading the evidence in your own repo
Section titled “Reading the evidence in your own repo”Everything the pipeline produces is inspectable in any repo that runs it: specs with numbered criteria under .flow/specs/, review receipts under .flow/review-receipts/, and evidence JSON on every completed task. How work gets proven explains the system; a week of running it produces your own numbers.