Source note2 min read

Looping Is Not Reliability: State-Bound Evidence and Typed Revision Contracts for Agentic Code Repair

Source

arXiv

arxiv.org/abs/2607.24604v1

Read the source

Source

Plain-Language Brief

The paper discusses the unreliability of generating-test-revise loops in coding agents, focusing on the gap between finding a correct patch and actually implementing it. The study reveals that using stale traces can harm correct starts, but not with current traces. The authors propose a typed loop contract as a solution to enforce verifiable checkpoints and emit auditable admission receipts.

What the Document Says

  • The paper discusses the reliability of coding agents that follow generating-test-revise loops, stating that repetition alone does not guarantee reliability.
  • A study was conducted on HumanEval repairs, resulting in 900 three-revision trajectories.
  • Under forced revision, current correctness with current traces falls from 0.820 after one revision to 0.673 after two, while ever-correct rises to 0.847.
  • Two common-state studies used 2,430 branches from identical frozen programs to remove post-treatment risk-set bias.
  • In a prespecified 14B replication, stale traces harm 34/135 correct starts versus 4/135 with current traces, resulting in a 22.2-point increase.
  • A prospective 540-rollout policy eliminates observed correct-start harm but reduces wrong-start repair and fails its joint criterion.
  • Repository experiments over 24 bugs and four coder stacks expose floor effects and component heterogeneity without Holm-significant effects.
  • The authors propose separating admission, preservation, grounded certification, competence, and liveness.
  • They derive an evidence-bound typed loop contract and instantiate its mechanically enforceable subset in a reference implementation.
  • The implementation binds verifier evidence to exact code states, preserves verified checkpoints, and emits auditable admission receipts.

Key Concepts Mentioned

  • coding agents
  • generating-test-revise loops
  • reliability
  • correct patch
  • forced revision
  • ever-correct
  • study
  • Holm-significant effects

Claims Made by the Document

  • Repeatedly generating, testing, and revising code does not guarantee reliability.
  • Using stale traces can harm correct starts in a prespecified replication.

Evidence Used

  • 900 three-revision trajectories from a study on HumanEval repairs
  • a prespecified 14B replication

Methods / Approach

UNKNOWN

Limitations Stated by the Authors

UNKNOWN

Limitations Noted by the Agent

Agent interpretation — not from the source.

UNKNOWN

Open Questions

UNKNOWN

Notes for Future Q&A

May include interpretation. Labeled where it does.

UNKNOWN

Raw Abstract / Excerpt

Generate--test--revise loops are common in coding agents, but repetition alone provides no reliability guarantee. We study the gap between finding a correct patch and retaining, verifying, and submitting it. A sealed five-seed study over 30 HumanEval repairs produces 900 three-revision trajectories. Under forced revision, current correctness with current traces falls from 0.820 after one revision to 0.673 after two, although ever-correct rises to 0.847. Two common-state studies use 2,430 branches from identical frozen programs to remove post-treatment risk-set bias. In a prespecified 14B replication, stale traces harm 34/135 correct starts versus 4/135 with current traces, a 22.2-point increase (task-cluster 95% CI $[8.9,37.0]$, exact Holm $p=0.0337$). A prospective 540-rollout policy eliminates observed correct-start harm but reduces wrong-start repair and fails its joint criterion. Repository experiments over 24 bugs and four coder stacks expose floor effects and component heterogeneity without Holm-significant effects. We therefore separate admission, preservation, grounded certification, competence, and liveness. We derive an evidence-bound typed loop contract and instantiate its mechanically enforceable subset in a reference implementation that binds verifier evidence to exact code states, preserves verified checkpoints, and emits auditable admission receipts. The implementation is an executable specification and conformance artifact, not evidence of improved repair competence or calibrated verifier dependence.