Forced revision makes coding agents worse. 0.820 → 0.673.

Every coding harness I've built, including the one that produces this newsletter, has some version of "if it fails, try again." That instinct is wrong, and there's now a study with the seed count to prove it.

"Looping Is Not Reliability" (arXiv 2607.24604, July 27) runs a sealed five-seed study over 30 HumanEval repairs, producing 900 three-revision trajectories. Under forced revision, current correctness drops from 0.820 after one revision to 0.673 after two. Meanwhile ever-correct rises to 0.847. (arXiv 2607.24604)

Read those two numbers together, because they're the whole finding. The agent finds the right patch. Then it revises the right patch into a wrong one. The correct solution existed in the trajectory and got overwritten. Your loop was standing on the answer and kept digging.

Two common-state studies over 2,430 branches from identical frozen programs isolate the mechanism, and it's stale traces. When a revision was conditioned on outdated trace evidence, it harmed 34 of 135 correct starting states. With current traces: 4 of 135. A 22.2-point increase, task-cluster 95% CI [8.9, 37.0], exact Holm p=0.0337. The agent is reading a failure report that describes code that no longer exists, and dutifully fixing a bug that's already gone.

Anyone who has watched an agent loop has seen this without naming it. The test output in context is from two edits ago. The model trusts it because it's in the context window and everything in the context window looks equally true. There is no timestamp on evidence.

The authors' fix is a typed revision contract that binds verifier evidence to exact code states, preserves verified checkpoints, and emits auditable admission receipts. Translated for your harness: when a state passes verification, save it, and never let a later revision return something worse than your best-known-good. That's it. That's the fix. It's not more iterations, it's not a better prompt, it's a best_so_far variable and the discipline to return it.

Pair this with SEAL (arXiv 2607.24300, July 27), which formalizes the verifier-deployment gap: when an agent writes both the policy and the test that accepts it, self-assigned scores stay near perfect while real deployment performance degrades. SEAL keeps the self-authored tests but adds a fixed harness-side audit the agent can't write or inspect. The agent gets accept/reject only, and full incumbent state is restored after a clear regression. Failures stratify by capability: weaker agents destroy previously-acquired strategies behind easy self-tests; stronger agents stay stable but still mismeasure the deployment distribution. SEAL beat unprotected baselines across six models and three seeds. (arXiv 2607.24300)

Two independent papers, one week, same conclusion from different directions: your agent loop needs an acceptance signal it doesn't control, and a checkpoint it can't overwrite. I'm going to go add both to my own runner, which currently has neither, and I'd bet most of yours doesn't either.