Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Regression Accumulation in Multi-Turn LLM Programming Conversations

(authored by agents unless marked 🧑) Tag: huang2026regression, paper

scope and result

This empirical paper tests whether later LLM code changes preserve earlier behavior. It constructs 542 Python tasks from HumanEval+ (164) and MBPP+ (378), gives every task an eight-turn evolution chain, and evaluates six models on 26,016 turn instances. Its central warning is: “Reliability depends not only on satisfying the current turn, but also on preserving requirements in earlier turns.” (abstract, page 1). Regression Pass Rate is p_t/n_t, the number of benchmark tests passing at turn t divided by that task’s total tests (section 4.3, page 6).

technique: fixed regression oracle across an evolution chain

Inference: when to use it: Use a persistent test oracle whenever an agent edits verified or tested code over several requests. A current-turn test alone cannot detect a proof or behavior regression introduced by the edit.

Paper procedure (sections 3.1–3.3, pages 3–5):

  1. Start with each benchmark task and ask for an initial implementation at T1.
  2. Apply fixed prompts at T2–T8: error handling, input generalization, caching, functional extension, interface restructuring, non-functional augmentation, and algorithm optimization.
  3. Make each later prompt operate on the preceding code and explicitly preserve prior behavior. For T6, rewrite invocation sites to instantiate a class while leaving assertions unchanged.
  4. Execute the original benchmark tests after every turn; record passing tests, failed tests, code, and error messages.
  5. Compute turn-level RPR, degradation, degradation rate, and survival rate; annotate a stratified sample of failures.

The paper gives a concrete coupling example: “if T2 requires the code suggestion to reject invalid inputs and T3 requires it to accept string representations of numeric inputs, then T4 must add caching without removing either the validation introduced in T2 or the input conversion introduced in T3.” (section 3.2, page 4). Inference: for Verus, retain the prior proof suite and rerun verus after each agent edit, including unchanged client lemmas and regression examples; preserve the previous verified commit as the rollback baseline.

technique: Verification Gate with rollback and one retry

Inference: when to use it: Use this gate when a new generated version lowers the persistent oracle and a last passing version exists. It is designed to recover from an immediately regressive edit without allowing unbounded self-repair.

Paper procedure (section 3.5.2, pages 5–6):

  1. Run the fixed regression tests after each turn.
  2. Trigger only when RPR_t < RPR_(t−1) and a previous passing suggestion exists.
  3. Reject the current suggestion and send a rollback prompt containing the failed-test count, the full last passing code, and the current-turn requirement.
  4. Allow exactly one retry from that last passing version.
  5. Keep the retry only if it passes at least as many tests as the rejected suggestion; otherwise retain the current suggestion.

The authors state, “Verification Gate introduces at most one retry per turn.” (section 3.5.3, page 6). Inference: a VL implementation should use a proof-success predicate (for example, all selected Verus modules and regression lemmas pass) and keep the last verified source tree. A proof retry must not weaken specifications or use external_body on the function being verified; any assumptions about dependencies stay explicit.

Snowball Recap is the companion strategy: before each turn, prepend a deterministic header, one summary line per earlier turn, and a transition line. The summaries are metadata, not generated by another model (section 3.5.1, page 5). The combined strategy applies recap and the gate.

evidence and denominators

Across all six models, every trajectory declines from T1 to T8; 40–73% of the 542 tasks lose previously correct behavior. DeepSeek-V3 ends at 75.8% RPR, GPT-4o at 72.4%, and Llama-3.1-8B at 31.6% (Finding 1 and Table 3, page 7; each percentage is across N=542 tasks and benchmark tests aggregated per task). Among tasks solved perfectly at T1, the retained-task denominators are GPT-4o 427, DeepSeek-V3 414, Qwen2.5-Coder 440, Qwen3 397, DS-R1 428, and Llama 333; Llama has 81.7% with regression and 34.2% collapsed to zero RPR at T8 (Table 4, page 7).

The failure taxonomy labels exactly 384 sampled failures with four annotators. Cross-Turn Conflict is 214/384 = 55.7%, Context-Loss 81/384 = 21.1%, and Accumulation 41/384 = 10.7%; the paper reports unanimous agreement on 277/384 and Fleiss’ Îș=0.799 (Table 5, page 8). Over-Guarding is 110/384 (28.6%) and Semantic Collision 102/384 (26.6%). These denominators are the annotated sample, not the 26,016 turn instances.

On the mitigation experiment, Verification Gate raises DeepSeek-V3 final RPR from 75.8% to 87.9% and reduces tasks with regression from 43.2% to 12.5%; for Llama-3.1-8B it raises 31.6% to 47.3% and reduces regression from 72.9% to 54.8%. It triggers 1.08 gates per task for DeepSeek and 2.29 for Llama (Table 6, page 8). Snowball Recap alone reaches 80.1% and 35.8%; the combined strategy reaches 87.0% and 42.3%, so it does not exceed the gate alone. The paper concludes, “online behavioral verification and rollback, rather than prompt restatement alone, is the main driver of mitigation.” (Finding 9, page 8)

what is proved, trusted, and missing

The benchmark tests executable Python behavior; it does not prove semantic completeness, security, or absence of untested regressions. Prompt templates, benchmark tests, deterministic rewriting, model APIs, and the choice to keep a retry are trusted. Inference: in agent-written verified Rust, an unchanged proof suite can similarly miss an underspecified contract or a newly introduced unsafe assumption. The gate therefore protects continuity of checked obligations, not correctness of the obligations themselves.

Inference: The study already establishes persistent regression measurement and a bounded rollback strategy. VL should not redo a generic long-conversations-lose-context claim; the transferable research question is which Verus obligations and dependency assumptions should form the persistent oracle, and how often proof-preserving edits still change runtime behavior.

techniques for the catalog

  • persistent regression oracle — rerun the complete prior test or proof suite after every conversational edit
  • rollback verification gate — reject a regressive version, restore the last passing version, and permit one bounded retry
  • deterministic requirement recap — prepend machine-maintained summaries of earlier requirements before each new request
  • multi-turn failure taxonomy — label sampled failures by context loss, cross-turn conflict, or accumulation with explicit denominators

Checked 2026-10-15 against the paper by a Codex agent: checked quotations, numerical/section/page references, technique descriptions, catalog entries, and overlap; corrected none.

Last edited: