Does repository history improve agentic automated program repair?

History helps, but mostly for weaker models

The paper asks whether, how much, and under what conditions repository history improves agentic automated program repair beyond the single-line setting where the last commit touching a buggy line is often the bug-introducing one. The authors build HAFixAgent, an agent that injects blame-derived repository context into its repair loop, and evaluate it on all 854 Defects4J (Java) bugs and all 501 BugsInPy (Python) bugs.

The headline result is conditional. Under perfect fault localization, the best history heuristic beats the no-history configuration by only 4.4% on Defects4J (545 versus 522 bugs) and 1.1% on BugsInPy (377 versus 373) with DeepSeek-V3.2-Exp, and neither difference is statistically significant (p=0.12 and p=0.79). On the two smaller models the same comparison is large and significant: +51.4% on Defects4J and +35.6% on BugsInPy for Devstral-Small-2, and +64.3% and +31.9% for Qwen3-Coder-Next, all with p<0.01.

That split is the paper's central practical message: history is not a uniform upgrade, and its value grows as the underlying model's baseline repair rate falls.

What blame-derived context actually contains

The history signal comes from git blame, which annotates lines in the buggy snapshot with the commit that last changed them. The study first checks whether such history is even available: a preliminary study on the 854 Defects4J and 501 BugsInPy bugs shows bug-relevant history is widely available across both benchmarks.

The authors then define three heuristics that turn a selected blame commit into prompt context. fn_all supplies the names of functions changed in that commit, fn_pair supplies a function's before-and-after form, and fl_diff supplies the fine-grained edit itself. Bugs are also split by blame availability: blameable bugs have at least one existing line that fault localization can point to and git blame can annotate, while blameless bugs only insert new lines or files and fall back to a nearest-line strategy. Blameless bugs make up 28.9% of Defects4J and 12.6% of BugsInPy, so the fallback is not a marginal case.

The history profiles differ sharply between benchmarks: Defects4J blame is almost entirely concentrated in a single commit, while BugsInPy is often multi-commit for complex categories (49.0% of SFMH and 71.4% of MFMH bugs). For multi-commit cases the agent uses an LLM-as-a-judge to pick the single most relevant commit.

Plausible@1 and the fault-localization setting

Success is measured with Plausible@1, the share of bugs whose single generated patch compiles and passes all tests, with temperature set to 0.0. The paper also reports #Pass, the absolute count of bugs passing, and #Unique Pass, the number of bugs a history configuration repairs that its no-history counterpart does not. These are different quantities: a percentage change and a count of uniquely rescued bugs cannot be substituted for one another.

The default setting is perfect fault localization, where the agent is given the lines modified or deleted by the oracle fix. This isolates the effect of historical context from localization error, but it is optimistic. The paper therefore reruns all four configurations under realistic spectrum-based fault localization using GZoltar for Java and FauxPy for Python with the Ochiai formula at line granularity, taking the top-10 ranked lines. That localization is noisy: at least one developer-patched line appears in the top-10 for only 30% of Defects4J bugs (245 of 827) and 30% of BugsInPy bugs (107 of 361).

Three heuristics repair different bug sets

The most decision-relevant finding is not any single heuristic's average gain but their complementarity. On DeepSeek, each history heuristic uniquely repairs 106 to 111 Defects4J bugs and 59 to 67 BugsInPy bugs that the no-history configuration misses, while no-history in turn repairs a comparable number that history misses. On BugsInPy SFMH, the four configurations share 89 bugs, yet each history heuristic repairs 22 to 31 that no-history misses.

Because each heuristic rescues a different subset, the union of the three repairs significantly more bugs than no-history. Pooled across all bugs, the hybrid repairs 684 of 854 Defects4J bugs (80.1%) versus 522 (61.1%) for no-history, and 463 of 501 BugsInPy bugs (92.4%) versus 373 (74.5%), with p<0.001 on both benchmarks using McNemar's exact test with a Bonferroni correction. The authors attribute this to the heuristics capturing different signals: fine-grained edit patterns, before-and-after function semantics, and co-evolutionary patterns across functions.

The complementarity survives the move to realistic spectrum-based fault localization, where the hybrid still beats no-history on both benchmarks. That matters because it means the union result is not merely an artifact of idealized localization.

Beating baselines is not evidence for history

HAFixAgent also outperforms two prior repair techniques on the strongest model: its best configuration repairs 545 Defects4J bugs versus 348 for RepairAgent (+56.6%) and 175 versus 119 for BIRCH-feedback on the 371 multi-hunk bugs BIRCH evaluates (+47.1%). The authors are explicit that this margin cannot be read as evidence for history, because HAFixAgent's own no-history configuration already repairs 522 bugs, beating RepairAgent by +50.0% (p<0.001), and 172 multi-hunk bugs, beating BIRCH-feedback.

The paper attributes that gap to framework differences: HAFixAgent lets the model act through free-form bash commands, whereas RepairAgent drives a fixed tool set with a finite-state machine. On the two smaller models the baselines stay competitive — RepairAgent matches HAFixAgent's best configuration on Qwen (207 versus 212, p=0.80) and BIRCH-feedback matches it on both Qwen (60 versus 54, p=0.58) and Devstral (80 versus 75, p=0.70) — which the authors link to those models' native tool-calling interfaces. The history comparison itself is run within a fixed interface, so it is not confounded by this difference.

The hybrid costs about twice a single run

An individual history heuristic is generally no more expensive than no-history in agent steps or tokens, under both perfect and realistic fault localization. The hybrid is the exception: realized as a cascade that runs the heuristics in a fixed order and stops at the first test-passing patch, it costs roughly twice a single run, or 1.4 to 2.0 times an individual heuristic. The authors judge this still feasible given the improved performance, and note that a brute-force variant reaches the same 684 and 463 repairs.

Cost is also stratified by outcome in the paper, and the statistical comparison uses the Friedman test with pairwise Wilcoxon signed-rank tests and a Bonferroni correction, since the same bugs are run under different configurations and the distributions are not assumed normal.

Extra history can dilute the prompt

History is not uniformly beneficial. On Defects4J the authors observe 32 cases where a history configuration underperforms no-history or misses fixes no-history finds. In MFMH, for example, no-history attains 50 while fn_all, fn_pair, and fl_diff reach 47, 43, and 48, even though each contributes 12 to 13 unique fixes no-history does not solve.

The paper's explanation is that extra historical snippets can dilute salient context, consistent with evidence that models are distracted by irrelevant additions and that performance declines when relevant facts sit deeper in long prompts. This is an author interpretation rather than a measured mechanism, but it identifies the condition under which adding history is a net loss: bugs that do not need historical context.

Agents reason from the commit, not replay it

To check that gains are not memorization, the authors read saved trajectories for the 194 Defects4J and 99 BugsInPy bugs that only a history configuration repairs. In most sampled bugs the agent does not revert the blame commit; the injected history points to the faulty function or reveals the earlier change behind the fault, and the agent writes its own fix. For Cli_37, the commit lists the unified parser's functions, showing which internals to edit; for Jsoup_60, it names the selector-evaluator functions holding the bug.

The clearest exception is pandas_59 under fn_pair, where the injected before-and-after form of corr() shows that the earlier version set pairwise to True when other is None, a default the buggy code had dropped, and the agent reinstates it. Because the agent never sees the developer's fix, these traces are the paper's evidence against simple memorization.

A separate check addresses the metric itself: the authors manually verify a stratified random sample of 144 plausible patches and find 59.7% are correct (95% confidence interval 52% to 67%), and report that the history advantage holds under correctness scoring as well as test-passing.

Where the history benefit is worth paying for

The study covers two languages and 34 projects, and the authors note results may not transfer to ecosystems where project size, test adequacy, and repository practices differ; the history profiles already differ between their own two benchmarks. Evaluation on repository-level benchmarks such as SWE-bench is left as future work, and the agent uses one loop, a narrow bash tool set, and fixed step, cost, and time guards.

Within that scope, the paper's priority ordering is specific. If the base model is strong, a single history heuristic buys little and is not statistically distinguishable from no-history, so the case for history rests on the hybrid's union of complementary fixes rather than on any one heuristic's average gain. If the base model is weaker, an individual heuristic already delivers large, significant gains on both benchmarks. The hybrid's roughly doubled cascade cost is the price of collecting the bugs each heuristic uniquely rescues, and the paper's evidence supports paying it when the goal is maximizing repaired bugs rather than minimizing per-bug cost.

Sources used in this answer