PaperlayerView exact revision on arXiv

Source-linked AI summary

HAFixAgent: History-Aware Program Repair Agent

Yu Shi, Hao Li, Bram Adams, Ahmed E. Hassan

arXiv:2511.01047v3cs.SEcs.AI

TL;DR

Agentic APR systems typically use current snapshots, while reliably repairing complex bugs remains a challenge. HAFixAgent injects blame-derived repository context into an observe-act-verify agent loop for single- and multi-hunk bugs. On Defects4J, HAFixAgent outperforms RepairAgent (+56.6%) and BIRCH-feedback (+47.1%); historical context further improves repair by +4.4%.

  • Problem

    Agentic APR systems typically use current snapshots, while reliably repairing complex bugs remains a challenge.

    Source: §1 · p. 2

  • Method

    HAFixAgent injects blame-derived repository context into an observe-act-verify agent loop for single- and multi-hunk bugs.

    Source: §10 · p. 20

  • Results

    On Defects4J, HAFixAgent outperforms RepairAgent (+56.6%) and BIRCH-feedback (+47.1%); historical context further improves repair by +4.4%.

    Source: §10 · p. 21

  • Takeaways & Limitations

    Historical gains are largest on SFMH bugs, including +190.7% on BugsInPy.

    Source: §10 · p. 21

    The tested positive line shifts do not capture all real-world fault-localization errors, including entirely wrong file predictions.

    Source: §8 · p. 19

Abstract

from arXiv · show

Automated program repair (APR) has recently shifted toward large language models and agent-based systems, yet most systems rely on local snapshot context, overlooking repository history. Prior work shows that repository history helps repair single-line bugs, since the last commit touching the buggy line is often the bug-introducing one. In this paper, we investigate whether repository history can also improve agentic APR systems at scale, especially for complex multi-hunk bugs. We present HAFixAgent, a History-Aware Bug-Fixing Agent that injects blame-derived repository heuristics into its repair loop. A preliminary study on 854 Defects4J (Java) and 501 BugsInPy (Python) bugs motivates our design, showing that bug-relevant history is widely available across both benchmarks. Using the same LLM (DeepSeek-V3.2-Exp) for all experiments, including replicated baselines, we show: (1) Effectiveness: HAFixAgent outperforms RepairAgent (+56.6\%) and BIRCH-feedback (+47.1\%) on Defects4J. Historical context further improves repair by +4.4\% on Defects4J and +38.6\% on BugsInPy, especially on single-file multi-hunk (SFMH) bugs. (2) Robustness: under noisy fault localization (+1/+3/+5 line shifts), history provides increasing resilience, maintaining 40 to 56\% success on SFMH bugs where the non-history baseline collapses to 0\%. (3) Efficiency: history does not significantly increase agent steps or token costs on either benchmark.

1 Introduction

HAFixAgent combines agentic repair with blame-derived repository history to address complex bugs that snapshot-based systems struggle to repair. The paper evaluates this approach on two benchmarks and reports gains in effectiveness and resilience without significant cost increases.

1 Introduction

  • Agentic APR systems typically use current code snapshots, while reliably repairing complex bugs spanning multiple lines and locations remains difficult.The paper asks whether repository history can scale to complex multi-hunk repairs without overwhelming the agent with noisy blame signals.Source: §1 · p. 2
  • HAFixAgent integrates history heuristics inspired by HAFix [59] into an autonomous agent that uses bash tools during repair.The approach combines historical context with iterative agent reasoning and tool use.Source: §1 · p. 2
  • The evaluation covers all 854 Defects4J bugs and all 501 BugsInPy bugs, using the same LLM for experiments and replicated baselines.The experiments compare HAFixAgent with two baselines and include a controlled history-versus-no-history ablation.Source: §1 · p. 2
  • Historical information is available for 71.1% of Defects4J bugs and 87.4% of BugsInPy bugs; 99.5% of blameable Defects4J bugs map to one commit, versus 58.4% in BugsInPy.BugsInPy has more scattered blame, particularly for complex bug categories.Source: §1 · p. 2
  • HAFixAgent outperforms RepairAgent (+56.6%) and BIRCH-feedback (+47.1%) on Defects4J; history adds +4.4% on Defects4J and +38.6% on BugsInPy.Under noisy fault localization, history provides increasing resilience, and it does not significantly inflate cost.Source: §1 · p. 2
  • The paper contributes three blame-derived heuristics, an automated history-construction method, and a fallback strategy intended for agentic APR systems.Its evaluation also examines resilience to noisy fault localization and repair costs across both benchmarks.Source: §1 · p. 3

2 Background

The background motivates repository history as a source of repair context and describes agentic APR as an iterative, tool-using approach. HAFixAgent brings these directions together by adding historical context to agent workflows.

2.1 Mining Repository History for APR

  • Some history-based agent approaches rely on similar past bugs or issue-resolution trajectories in the repository, whereas blame offers a more direct heuristic.History-based context can be drawn from a relevant change even without a similar prior issue.Source: §2.1 · p. 3
  • Git blame associates each existing line with the commit that last changed it, while SZZ treats changes to lines modified or deleted by a fix as likely bug-introducing commits.The identified commit's diff and message can offer clues about code evolution and developer intent.Source: §2.1 · p. 3
  • Prior history-based repair work used repository changes and blame information; HAFix [59] found that blame-derived context improves repair for single-line bugs.The paper investigates whether this focused context can extend to complex, multi-location repairs in an agentic workflow.Source: §2.1 · p. 4

2.2 Agentic Software Engineering

  • Agentic APR systems use tools and iterative reasoning, but typically rely on the current code snapshot and test feedback rather than historical context.HAFixAgent addresses this gap by adding actionable version-control history to the agent loop.Source: §2.2 · p. 4

3 Preliminary Study (RQ0): To What Extent Is Historical Information Available in Real-World Bugs?

The preliminary study examines whether blame history is available and concentrated enough to inform repairs across bug types and benchmarks. It finds broad availability in both datasets, with blame more dispersed in BugsInPy than in Defects4J.

3.1 Motivation

  • The study asks whether complex bugs have blame commits and how many unique commits their buggy lines trace to, given that combining many sources could overwhelm an agent.Blameless insertion-only fixes cannot be traced with git blame, so they require a workaround to use history.Source: §3.1 · p. 5

3.2 Approach

  • The study analyzes buggy lines identified from benchmark developer patches, runs git blame on those lines, then counts unique blame commits by bug category.It uses Defects4J v3.0.1 and BugsInPy to examine availability and distribution across languages.Source: §3.2.1 · p. 5

3.2.1 Dataset.

  • The datasets comprise 854 Java bugs from 17 Defects4J projects and 501 Python bugs from 17 BugsInPy projects.BugsInPy complements Defects4J with a dynamically typed language and different development practices and commit patterns.Source: §3.2.1 · p. 5

3.2.2 Bug Category Terminology.

  • Bugs are divided into SL, SH, SFMH, and MFMH by the number and location of fix hunks; the study keeps all four categories separate for finer granularity.It also distinguishes blameable fixes, which modify or delete existing lines, from blameless fixes consisting only of insertions.Source: §3.2.2 · p. 6

3.3 Results

  • Historical blame is available for 71.1% of Defects4J bugs and 87.4% of BugsInPy bugs, including 69.2% of Defects4J SFMH and 91.6% of BugsInPy SFMH bugs.For MFMH, availability is 80.5% in Defects4J and 92.3% in BugsInPy; SH has the lowest availability in both datasets.Source: §3.3 · p. 6
  • Defects4J blame is highly concentrated: 70.7% of bugs map to one unique blame commit and 0.4% to two or more, while 36.3% of BugsInPy bugs map to two or more.In BugsInPy, the multi-commit share rises from 0% for SL to 71.4% for MFMH; among blameable bugs, 58.4% are single-commit versus 99.5% in Defects4J.Source: §3.3 · p. 7

4 HAFixAgent

HAFixAgent augments an iterative repair agent with blame-derived repository history while keeping its tools and execution loop deliberately simple. Its history pipeline selects a relevant commit, handles blameless bugs with a fallback, and prepares one of three history representations for the agent.

4 HAFixAgent

  • HAFixAgent combines iterative, multi-step repair with blame-derived history, using a compact agent architecture and a git blame tool.When multiple blame commits exist, an LLM judge selects the most relevant; a fallback retrieves history for blameless bugs.Source: §4 · p. 8

4.1 Context Builder

  • The Context Builder combines the bug report, failing tests, and fault-localization metadata with history extracted and formatted into the prompts.Metadata includes the buggy files and lines; fault-localized lines are used to obtain blame commits.Source: §4 · p. 8, §4.1.1 · p. 8, §4.1.2 · p. 8

4.1.2 History Extractor.

  • For blameless add-only bugs, the fallback blames the nearest executable code line within the five lines preceding insertion, assuming new code is added near related logic.A single commit is associated with 99.5% of blameable Defects4J bugs; BugsInPy bugs more frequently have multiple commits.Source: §4.1.2 · p. 9

4.1.3 Historical Context.

  • The agent receives one of three blame-derived history representations: co-changed function names, before-and-after code for the buggy function, or the commit’s file-level diff.These are named fn_all, fn_pair, and fl_diff; the diff exposes fine-grained changes across files.Source: §4.1.3 · p. 9

4.2 Agent Execution Loop

  • The execution loop repeatedly sends the current conversation state to the LLM, executes its bash action in a sandbox, and feeds back tool and test results.It stops on success or when a step, cost, or timeout guard is reached.Source: §4.2 · p. 9

4.3 Tools

  • History is prepared before the loop rather than exposed as an interactive tool, keeping the agent’s toolset focused on repair operations.The authors describe this as decoupling history retrieval from agent actions.Source: §4.3 · p. 10
  • The toolset supports file inspection and editing, project compilation, and relevant tests, with simple command chaining for repair iterations.The agent self-terminates after successful tests or halts when a guard is reached.Source: §4.3 · pp. 10–11

5 Case Study Design

The case study prepares bug, test, fault-location, and blame-derived history context, then compares HAFixAgent with replicated baselines on a shared LLM. It evaluates patch success and repair efficiency across Defects4J and BugsInPy.

5.1 Prompt Context Preparation

  • The study prepares bug reports, failing tests, fault locations, and history for the benchmark bugs; it assumes perfect fault localization based on developer fixes.BugsInPy descriptions are omitted to avoid commit-message leakage, and 18 Chart descriptions use manually checked fixing commit messages.Source: §5.1 · p. 11
  • For bugs with multiple blame commits, an LLM judge selects one relevant commit; blameless bugs use the nearest-line fallback, and the selected commit supplies the three history configurations.BugsInPy has 182 cases with two or more blame commits; Defects4J has three.Source: §5.1 · p. 11

5.2 Baselines

  • RepairAgent and BIRCH-feedback are replicated with DeepSeek-V3.2-Exp for comparison; BIRCH-feedback is evaluated on the same 371 overlapping multi-hunk bugs.RepairAgent is evaluated on all 854 Defects4J bugs using the plausible, test-passing-patch metric.Source: §5.2 · pp. 11–12

5.3 Metrics

  • The study measures Plausible@1 and absolute passing-patch counts, plus unique fixes from history configurations; efficiency measures include agent steps and token-derived cost.Paired context configurations are compared with Friedman tests and, when significant, pairwise Wilcoxon tests with Bonferroni correction.Source: §5.3 · p. 12

5.4 Implementation

  • HAFixAgent is implemented with a lightweight execution loop and benchmark-specific Docker environments, with runs capped at 50 steps, $1, and one hour per bug.All three experimental systems use DeepSeek-V3.2-Exp at temperature 0.0.Source: §5.4 · pp. 12–13

6 Results

Section 6 presents the motivation, approach, and results for each research question.

6 Results

  • The section organizes its discussion around the motivation, approach, and results for each research question.Source: §6 · p. 13

6.1 RQ1: How Effective Is HAFixAgent at Fixing Real-World Bugs?

The evaluation compares HAFixAgent with same-LLM baselines and tests history against non-history configurations across bug categories and two benchmarks. HAFixAgent surpasses both baselines, while history adds fixes on both datasets, particularly for SFMH bugs.

6.1.1 Motivation.

  • The study tests whether blame-derived context benefits single- and multi-hunk bugs across Java and Python, motivated by differing blame concentration between benchmarks.Defects4J blame is reported as 99.5% single-commit, while BugsInPy has 41.6% multi-commit cases.Source: §6.1.1 · p. 13

6.1.2 Approach.

  • The comparison uses the same LLM for replicated baselines and evaluates four history configurations across SL, SH, SFMH, and MFMH categories.The history configurations are non-history, fn_all, fn_pair, and fl_diff.Source: §6.1.2 · p. 13

6.1.3 Results.

  • Using DeepSeek-V3.2-Exp across methods, HAFixAgent improves repairs by 56.6% over RepairAgent; on 371 BIRCH-feedback multi-hunk bugs, fn_pair repairs 175 versus 119, a 47.1% gain.Source: Table 2 · p. 14, §6.1.3 · p. 14
  • +4.4% on Defects4J (545 vs 522) and +38.6% on BugsInPy (377 vs 272): the best history configuration exceeds non-history on both benchmarks.The best configurations are fl_diff on Defects4J and fn_all on BugsInPy.Source: §6.1.3 · p. 14, Table 3 · p. 15
  • +190.7% on BugsInPy SFMH: fl_diff repairs 157 bugs (77.7%) versus 54 (26.7%) for non-history; Defects4J SFMH reaches 254 versus 141.On Defects4J, fl_diff also performs best on SL with 140 fixes (83.8%).Source: §6.1.3 · p. 14
  • History configurations solve overlapping but distinct bugs; their union fixes 684 Defects4J bugs versus 522 without history, and 463 BugsInPy bugs versus 272.The reported union gains are +31.0% and +70.2%, respectively.Source: Figure 3 · p. 15, §6.1.3 · pp. 15–16

6.2 RQ2: Efficiency and Robustness

RQ2 evaluates whether historical context adds repair cost and whether its benefits persist under imprecise fault localization. History does not significantly increase costs or steps, and its repair advantage is most pronounced under noisy localization for multi-hunk bugs.

6.2.1 Motivation.

  • The study addresses whether adding history inflates cost and whether its repair benefit persists under noisy fault localization.The motivation notes that inaccurate fault locations can retrieve irrelevant commits.Source: §6.2.1 · p. 16

6.2.2 Approach.

  • Noisy-FL robustness was tested on 100 stratified Defects4J bugs, with 25 bugs per category and shifts of +1, +3, and +5 lines.The shift affected the fault locations supplied to the agent and the lines used to compute blame; this produced 1,200 additional runs.Source: §6.2.2 · p. 16

6.2.3 Results.

  • 40 to 56% of SFMH bugs remain repaired with history at shift=+5, while non-history falls from 64% at shift=0 to 0%.The figure evaluates 100 stratified Defects4J bugs across line shifts; shift=0 uses perfect fault localization.Source: Figure 4 · p. 17, §6.2.3 · pp. 17–18
  • History does not significantly increase agent steps or cost on either benchmark.Defects4J costs are statistically comparable for SH, SFMH, and MFMH; no BugsInPy category shows significant cost differences.Source: §6.2.3 · p. 17
  • On Defects4J SL, fn_pair + fl_diff reaches 90.4% success at $0.041, while the four-configuration union reaches 95.2% at $0.086.Across both datasets, two or three configurations provide the best success per dollar; adding a fourth yields small extra gains at substantially higher cost.Source: §6.2.3 · p. 17
  • At shift=+3, fn_all and fn_pair each reach 88% on SH, versus 68% for non-history.At shift=+5, all configurations degrade, though history still leads.Source: §6.2.3 · p. 18

7 Discussion

The discussion connects distinct heuristic strengths to their complementarity, while noting that added historical context can hurt some repairs. It also distinguishes plausible-patch results from verified correctness.

Performance Regressions

  • In MFMH, non-history fixes 50 bugs, versus 47 for fn_all, 43 for fn_pair, and 48 for fl_diff, despite each heuristic adding unique fixes.Each history heuristic contributes 12 to 13 unique fixes not found by non-history.Source: §7 · p. 18
  • Extra historical snippets can dilute salient prompt context and reduce Plausible@1 on bugs that do not need history.The discussion notes that some bugs are repaired better without additional historical context.Source: §7 · p. 18

Heuristics Complementarity

  • The three historical heuristics are complementary, with each repairing distinct bugs; combining two or three yields the most cost-effective performance.fl_diff captures fine-grained edit patterns, fn_pair function evolution, and fn_all co-evolution across functions.Source: §7 · p. 18
  • The strongest historical-context benefits appear on SFMH bugs, where a blame commit often captures the full change context.The paper links this pattern to single-commit concentration in RQ0.Source: §7 · p. 18

Plausible vs. Correct Patches

  • Success is measured by plausible patches passing the full test suite, not manually verified correctness; verifying over 3.5k patches was prohibitively expensive.The evaluation therefore focuses on relative improvement rather than absolute correctness.Source: §7 · p. 18

8 Threats to Validity

The paper identifies boundaries in benchmark coverage, fault-localization noise, and agent configuration. It also notes that pretraining exposure to benchmark bugs cannot be verified.

Internal Validity

  • The authors cannot verify whether Defects4J projects or bugs appeared in DeepSeek-V3.2-Exp’s pretraining corpus.The corpus is not disclosed.Source: §8 · p. 18
  • The evaluation emphasizes relative effectiveness of historical heuristics rather than absolute performance.The paper attributes fixes unique to a history configuration to historical-context benefit regardless of whether the LLM had seen the bug.Source: §8 · pp. 18–19
  • The noisy-FL experiment uses uniform positive line shifts and does not capture errors such as predicting an entirely wrong file.The study evaluates shifts of +1, +3, and +5 lines.Source: §8 · p. 19

External Validity

  • The study covers Defects4J and BugsInPy, spanning two languages and 34 projects, so results may not transfer to ecosystems with different project or repository practices.The benchmarks have different history profiles: 99.5% single-commit in Defects4J versus 58.4% in BugsInPy.Source: §8 · p. 19
  • Repository-level benchmarks such as SWE-bench remain future work.Source: §8 · p. 19

Internal Validity

  • The evaluation uses one agent loop, a narrow bash tool set, specific prompts, and one LLM, so different configurations may change absolute results.Baselines were replicated using the same LLM to reduce this threat.Source: §8 · p. 19

9 Related Work

Related work traces APR from search, constraint, and template-based methods through LLM-driven and agentic repair. It identifies limited use of commit history inside agent workflows as the gap HAFixAgent addresses.

9.1 Traditional Automated Program Repair

  • Traditional APR spans search-, constraint-, template-, and code-reuse-based repair, but coverage is constrained by operator or pattern design and search scalability.Learning-based systems also frame repair as code translation or edit prediction; recurring limitations include computation cost, low accuracy, and overfitting to tests.Source: §9.1 · p. 19

9.2 LLM and Agent based Automated Program Repair

  • LLM-based APR ranges from single-shot generation to tool-using agents, while agent research has given limited study to commit history as first-class context inside the loop.Agent designs include repository tools, specialized repair tools, multi-agent collaboration, and memory from prior repair trajectories.Source: §9.2 · p. 20

9.3 In-context Learning for Automated Program Repair

  • In-context APR studies bug facts, local code context, bug reports, execution traces, and broader context curation, while realistic repository-level tasks remain challenging.Prior work also reports blame-derived commit data as a lightweight historical signal for fixing more bugs [59].Source: §9.3 · p. 20
  • HAFixAgent builds on HAFix [59] by bringing blame-driven history into agentic workflows and quantifying its effect on single- and multi-hunk bugs.The related-work discussion frames commit history as a first-class context inside the agent loop as the focus of this paper.Source: §9.3 · p. 20, §9.2 · p. 20

10 Conclusion and Future Work

HAFixAgent injects blame-derived repository context into an observe-act-verify repair loop. Experiments report stronger repair results with history, resilience to noisy fault localization, and future directions for multiple blame commits and specialized agents.

10 Conclusion and Future Work

  • Blame history is available for 71.1% of Defects4J bugs and 87.4% of BugsInPy bugs, with single-commit concentration of 99.5% and 58.4%, respectively.The study covers 854 Defects4J bugs and 501 BugsInPy bugs.Source: §10 · pp. 20–21
  • +56.6% versus RepairAgent and +47.1% versus BIRCH-feedback on Defects4J; history adds +4.4% on Defects4J and +38.6% on BugsInPy.The largest reported history gain is +190.7% on BugsInPy single-file multi-hunk bugs.Source: §10 · p. 21
  • Under noisy fault localization, history maintains up to 56% success on SFMH bugs while the non-history baseline falls to 0%.The paper also reports that history does not significantly inflate agent cost on either benchmark and that the three heuristics solve distinct bug subsets.Source: §10 · p. 21
  • Combining context from multiple blame commits is a future direction for BugsInPy, where 41.6% of bugs have multiple blame commits.The current agent uses an LLM judge to select a single blame commit.Source: §10 · p. 21
  • A specialized multi-agent design with History, Fixer, and Reviewer agents is proposed for complex MFMH bugs where one agent’s context window is easily overwhelmed.This is presented as a future direction.Source: §10 · p. 21

A HAFixAgent Prompt

The prompt directs a Java debugging agent to inspect bug evidence, diagnose root cause, plan a minimal fix, and verify it with tests. It also instructs the agent to use blame history and coordinate fixes across multi-hunk locations.

Prompt setup

  • The prompt targets Java debugging in Defects4J and requires the final response to contain one bash code block with a command or chained commands.It describes a Linux environment with the project checked out at the repository path.Source: A HAFixAgent Prompt · p. 25

Understand, analyze, and design

  • The agent should read the bug description, fault locations, failing tests, and surrounding code, then trace failures to identify the root cause.It is prompted to design minimal changes, consider effects elsewhere, and avoid breaking existing functionality.Source: A HAFixAgent Prompt · p. 26

Implement and verify

  • Implementation guidance favors precise edits followed by immediate testing, error analysis, and refinement until tests pass.Simple edits may use sed; complex changes may use head/tail reconstruction, and defects4j test -r runs relevant tests.Source: A HAFixAgent Prompt · p. 26

Multi-Hunk Strategy

  • For multi-hunk bugs, the prompt asks the agent to relate fault locations, fix them in dependency order, and test them together.The agent should verify all locations work together with defects4j test -r.Source: A HAFixAgent Prompt · p. 26

Historical Context

  • The prompt makes git blame history available to help explain prior changes, identify similar fixes, avoid regressions, and recognize architectural dependencies.It advises treating historical context as a source of the rationale behind code decisions.Source: A HAFixAgent Prompt · pp. 26–27

Related papers

Loading 2511.01047v3…