arXiv CSopen access

MultiFixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

Multi2Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs Haichuan Hu

Chunrong Fang

Nanjing University of Nanjing University Nanjing, China Science and Technology [email protected] Nanjing, China [email protected]

Weifeng Sun

arXiv:2607.26591v1 [cs.SE] 29 Jul 2026

Singapore Management University Singapore, Singapore [email protected]

Ye Shang

Jiawei Liu

Nanjing University Nanjing, China [email protected]

Nanjing University Nanjing, China [email protected]

Chenxing Zhong

Quanjun Zhang∗

Guoqing Xie

Nanjing University Nanjing University of Nanjing University of Nanjing, China Science and Technology Science and Technology [email protected] Nanjing, China Nanjing, China [email protected] [email protected]

Abstract

Keywords

Automated Program Repair (APR) has benefited greatly from Large Language Models (LLMs), but existing LLM-based APR methods still struggle with multi-hunk bugs that require coordinated changes across multiple locations. These bugs demand repository-level context understanding, repair-order scheduling, and effective hunklevel patch generation and selection. To address these challenges, we propose Multi2 Fixer, a novel Coordinator-Proposer based multi-agent framework for multi-hunk repair. Multi2 Fixer performs tool-augmented bug analysis, constructs fine-grained repair context, iteratively generates patches through a CoordinatorProposer architecture, and applies two-stage patch refinement for syntactic and semantic correctness. We evaluate Multi2 Fixer on 835 bugs from Defects4J and three vulnerability benchmarks. On Defects4J, Multi2 Fixer fixes 326 bugs, including 62 multi-method and 27 multi-file bugs, and outperforms prior APR baselines in the reported comparisons with the same base model. Moreover, Multi2 Fixer also fixes 46 multi-hunk bugs among 95 unique fixes. When combined with Claude-3.5-Sonnet, Multi2 Fixer repairs 420 bugs, establishing a new state of the art on Defects4J. On VUL4J, Multi2 Fixer repairs 24 real-world vulnerabilities, including 5 multihunk cases. On the multi-hunk subsets of SEC-bench and PatchEval, Multi2 Fixer fixes 11 and 19 vulnerabilities, respectively, outperforming all compared baselines under GPT-3.5. These results demonstrate the effectiveness of Multi2 Fixer for multi-hunk repair.

Automated Program Repair, Large Language Models, Multi-Agent, LLM4SE

CCS Concepts • Software and its engineering → Software testing and debugging. ∗ corresponding author.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. ASE’26, Munich, Germany © 2026 ACM. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM https://doi.org/10.1145/nnnnnnn.nnnnnnn

ACM Reference Format: Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang. 2026. Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs. In Proceedings of Proceedings of the 41st IEEE/ACM International Conference on Automated Software Engineering (ASE’26). ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

1

Introduction

The emergence of Large Language Models (LLMs) has driven advancements in software engineering [14, 63], demonstrating outstanding capabilities across various code-related tasks, including code generation [9, 21], test generation [37, 38, 62, 68], and program repair [15–17, 64, 65]. Building on this, LLM-based Automated Program Repair (APR) leverages LLMs for fault localization, patch generation, and patch validation, enabling the automatic detection and repair of software defects and attracting growing attention in modern software engineering. However, most existing LLM-based APR approaches primarily focus on relatively simple bugs [49, 58], and typically treat the bug as a whole in a single-step repair process [49]. Such settings, while effective for controlled evaluation, exhibit limitations when applied to real-world program bugs. One major limitation is that a significant portion of real-world bugs involve complex, multi-hunk changes spread across different methods and files. One recent study [51] analyzes the distribution of hunk counts and its impact on repair success rate across 835 bugs in Defects4J [23]. As shown in Figure 1, nearly 50% of these bugs involve multiple hunks, and the repair success rate significantly decreases as the number of hunks increases. However, existing works such as ChatRepair [49] and ThinkRepair [58] focus solely on evaluating single-line, single-hunk, and single-method bugs, comprising 483 of the 835 bugs from Defects4J (i.e., 255 from Defects4J-v1.2 and 228 from Defects4J-v2.0). This means that the remaining 352 more complex bugs are excluded from their evaluations. Such selective evaluation substantially undermines the objectivity of assessing LLMs’ true repair capabilities.

ASE’26, October 12–16, 2026, Munich, Germany

Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang

Repair Success Rate by Number of Hunks Number of Bugs

463

Unfixed Plausible (Valid but Not Correct) Correct

400

177

200

80 0

1

2

3

38 4

18

16

5

4

7

16

5 6 7 Number of Hunks

8

9

10

10+

11

Figure 1: The relationship between repair success rate and the number of hunks.

Another limitation is that existing methods treat multi-hunk bug repair as a single-step task, generating patches for all hunks within a single interaction. Studies [51, 57] show that there are often dependencies among different hunks. By referring to how humans repair multi-hunk bugs, understanding and modifying hunks is a hierarchical and sequential process. Moreover, as the number of hunks increases, it becomes difficult for repair models to generate patches for all hunks correctly in a single attempt; if even one hunk is incorrect, the entire patch must be discarded. These two limitations pose the following challenges for multihunk bug repair. (1) Repository-level repair context. Singlehunk bug repair typically requires only test failure information and buggy code as repair context, but fixing multi-hunk bugs requires repository-level global context. (2) Repair order scheduling. Due to semantic and logical dependencies among hunks, there is a natural repair order that must be followed. Identifying these inter-hunk relationships and properly scheduling the repair sequence is crucial. (3) Hunk-level patch generation and selection. In the process of repairing multi-hunk bugs, we cannot use test cases to verify the correctness of individual hunk-level partial patches because the interactions between different hunks can lead to dependencies that obscure the effects of each individual patch, making isolated testing ineffective. This Paper. To address the above issues, we propose Multi2 Fixer, a Coordinator-Proposer based multi-agent framework for fixing multi-hunk bugs. Multi2 Fixer consists of four stages: (1) toolaugmented bug analysis with BugAnalyzer to identify root causes and relevant code; (2) repair context construction by combining bug reports, buggy code, local context, test code, and failure reports; (3) iterative patch generation through a Coordinator-Proposer architecture, where the Coordinator schedules hunk repair and selects promising candidates from multiple Proposers; and (4) two-stage patch refinement for syntactic and semantic correctness. The framework is motivated by the Generation-Recognition Asymmetry phenomenon [10], suggesting that selecting a correct patch from candidates is easier than generating it directly. We evaluate Multi2 Fixer on Defects4J [23] and three vulnerability benchmarks: VUL4J [5], SEC-bench [26], and PatchEval [45]. Experimental results show that Multi2 Fixer can fix 326 out of 835 bugs in Defects4J, including 62 multi-method and 27 multi-file bugs, outperforming prior baselines in our reported comparisons. On VUL4J, Multi2 Fixer fixes 24 vulnerabilities, including 5 multi-hunk vulnerabilities, suggesting that Multi2 Fixer can generalize to vulnerability repair. On the

SEC-bench and PatchEval multi-hunk subsets, Multi2 Fixer further fixes 11 and 19 vulnerabilities, respectively, showing consistent advantages beyond Java vulnerability repair. To sum up, the main contributions of this paper are as follows: • New Mechanism. For multi-hunk repair, we draw inspiration from the Generation-Recognition Asymmetry phenomenon and innovatively propose the Coordinator-Proposer repair mechanism. We replace the traditional single-step paradigm by combining the Coordinator-Proposer mechanism with iterative hunk-level repair, thereby breaking through the model’s capability boundaries in the multi-hunk repair scenario. • Well-Designed Technique. Guided by the Coordinator-Proposer mechanism, we propose and implement a multi-agent repair framework, Multi2 Fixer, which consists of three distinct agents: BugAnalyzer, Coordinator, and Proposer. These agents collaborate to complete bug analysis and repairs. Notably, during patch generation, Multi2 Fixer can autonomously schedule the repair order and revise existing hunk-level patches, thereby facilitating multi-hunk repairs. • Extensive Study. We evaluate Multi2 Fixer on Defects4J and three vulnerability benchmarks, comparing its performance against state-of-the-art baselines. Experimental results demonstrate that Multi2 Fixer fixes 326 out of 835 bugs in Defects4J, 24 out of 79 vulnerabilities in VUL4J, and achieves the best results on the multi-hunk subsets of SEC-bench and PatchEval. Specifically, the Coordinator-Proposer framework enables Multi2 Fixer to address more complex bugs, including 27 multi-file bugs and 62 multi-method bugs. Among the 95 unique bugs fixed by Multi2 Fixer, 46 are multi-hunk, highlighting the agent’s strong capability in multi-hunk repair. This emphasizes the importance of focusing on multi-hunk scenarios and suggests avenues for enhancing repair strategies in future research.

2 Background and Motivation 2.1 LLM-based APR LLM-based APR [11, 27, 35, 53, 54, 56, 66, 67] builds on earlier pretrained repair models [22, 29, 61], which typically formulate repair as Neural Machine Translation (NMT [41]) or Masked Language Modeling (MLM [42]). Although previous studies [48, 63] have shown the effectiveness of these paradigms, they still suffer from limitations such as dependence on large amounts of training data and limited generalization in real-world scenarios [64]. Compared with earlier pre-trained approaches, LLMs provide stronger repair capability with little or no task-specific training [64], as well as a broader range of available models, such as GPT-3 [3] and GPT4 [1]. Existing LLM-based APR methods can be broadly divided into training-free and training-based methods. Training-free APR. Training-free methods mainly include prompt-based and agent-based approaches. Prompt-based methods [7], such as zero-shot [40], few-shot [32], and Chain-of-Thought prompting [43], are popular for their simplicity. For example, ChatRepair [49] interleaves patch generation with feedback, while ThinkRepair [58] enhances repair through Chain-of-Thought prompting and iterative fixing. Agent-based methods [2, 28, 33, 36, 59] further equip LLMs with external tools and iterative workflows for planning, execution, and refinement. For instance, RepairAgent [2]

Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

combines ChatGPT with a state machine to autonomously plan and refine repair steps. Training-based APR. Training-based methods mainly include fine-tuning and reinforcement learning. Fine-tuning-based methods improve repair performance by adapting pre-trained models to repair tasks [8, 13, 39, 60]. Reinforcement learning has also shown promise in APR, as demonstrated by methods such as SWE-RL [44] and Repair-R1 [18]. Despite these advances, most existing LLMbased APR methods still focus on relatively simple bugs or treat repair as a single-step generation problem.

2.2

Multi-hunk Bug Repair

Most previous APR studies focus on relatively simple bugs with concentrated fault locations. For example, ChatRepair [49] and ThinkRepair [58] mainly evaluate single-line, single-hunk, and single-method bugs. Recent studies [6, 20, 48, 50] also narrow their scope to function-level issues. By contrast, research specifically targeting multi-hunk repair remains limited. On the one hand, multi-hunk bugs often span multiple methods or files, making repair substantially more difficult. On the other hand, many existing methods [28, 47, 49] still adopt the same one-shot strategy used for simpler bugs, without explicitly modeling hunk dependencies or repair order. ITER [57] is among the first studies to highlight the distinction between single-hunk and multi-hunk repair and proposes iterative refinement for such bugs. More recent work investigates context granularity and repair strategies for multihunk scenarios [12, 30, 31]. Among these efforts, PReMM [51] is closest to our setting: it decomposes multi-method bugs through dependency-based faulty-method clustering and repairs them with a fixed divide-and-conquer strategy, whereas Multi2 Fixer treats repair as dynamic hunk-level coordination over an evolving partial patch. Together, these studies suggest that multi-hunk repair requires not only broader context or iterative retry, but also explicit coordination of the repair trajectory across dependent hunks. In this paper, we address this need through a Coordinator-Proposer framework.

2.3

Motivation

Figure 2 presents a motivation example from Defects4J Mockito_17. The user expects a mock to be both serializable and configured with extra interfaces. However, the original implementation realizes serializable() by replacing the extra-interface configuration with Serializable.class, so the two requirements cannot hold at the same time and the serialization test fails. Fixing this bug is not a local edit: one hunk must record the serialization intent, while another hunk must later consume this intent when composing the final mock interfaces. This example motivates our design from two aspects. Generation-Recognition Asymmetry. Our design is inspired by the Generation-Recognition Asymmetry phenomenon [10, 34]: recognizing a correct solution from candidates can be easier than generating it directly. In Mockito_17, GPT-3.5 fails to generate a correct patch after five self-correction attempts. However, in a diagnostic comparison, when we place the failed patches together with the developer patch and ask GPT-3.5 to choose from these candidates, GPT-3.5 can identify the correct patch. This gap suggests that

ASE’26, October 12–16, 2026, Munich, Germany

LLMs are less reliable at judging an isolated self-generated patch than at comparing alternatives. It also reflects cognitive fixedness, where repeated self-correction tends to explore similar repair directions. The above observations motivate the propose-then-select design of Multi2 Fixer. Repair-Order Scheduling. The same example also motivates explicit hunk scheduling. The MockSettingsImpl hunk is a state producer: it changes serializable() from modifying extraInterfaces to recording an intent flag. The MockUtil hunk is a state consumer: it reads this flag and appends Serializable.class while preserving existing interfaces. Repairing the producer first gives the consumer a clear invariant to enforce, motivating a Coordinator that schedules hunks rather than repairing all locations independently. Defects4J Mockito_17: serializable() + extraInterfaces(List.class) H1: MockSettingsImpl.java

// producer of serialization intent

- serializable(): return extraInterfaces(Serializable.class) + private boolean serializable; + serializable(): serializable = true; return this; + isSerializable(): return serializable; H2: MockUtil.java

// consumer when composing interfaces

interfaces = settings.getExtraInterfaces(); + if settings.isSerializable(): +

ancillaryTypes = append(interfaces, Serializable.class)

+ else: +

ancillaryTypes = interfaces or empty;

Figure 2: Motivation example from Defects4J Mockito_17. Overall, this example shows that multi-hunk repair requires both selecting correct edits from multiple candidates and coordinating dependent hunks in a meaningful order. A one-shot LLM repair must solve these two problems simultaneously, which makes the repair unstable. Multi2 Fixer addresses this difficulty by separating candidate proposal, candidate selection, and hunk scheduling, so that the repair intent established by one hunk can guide the edit of another hunk.

3 Approach 3.1 Problem Statement |D| Suppose D = {(𝐵𝑖 , 𝐻𝑖 , 𝑃𝑖 )}𝑖=1 is a defect dataset containing |D | bugs. Each bug 𝐵𝑖 is a multi-hunk bug composed of |𝐻𝑖 | hunks, where 𝐻𝑖 = [ℎ 1, . . . , ℎ𝑛 ] and each hunk ℎ 𝑗 represents a contiguous block of erroneous code. The corresponding fix is a patch 𝑃𝑖 = [𝑝 1, . . . , 𝑝𝑛 ], where 𝑝 𝑗 denotes the correction for hunk ℎ 𝑗 . The multihunk repair task can thus be formalized as follows:

Definition 1 (Multi-hunk Repair Task). Given a buggy program with 𝑛 hunks 𝐻𝑖 = [ℎ 1, . . . , ℎ𝑛 ], the goal is to generate a complete patch 𝑃𝑖 = [𝑝 1, . . . , 𝑝𝑛 ] such that each 𝑝 𝑗 correctly fixes ℎ 𝑗 . This is modeled as an autoregressive sequence generation task: 𝑛 Ö 𝜋𝛾 (𝑃𝑖 | 𝐵𝑖 , 𝐻𝑖 ) = 𝜋𝛾 (𝑝 𝑗 | ℎ 1, . . . , ℎ 𝑗 ; 𝑝 1, . . . , 𝑝 𝑗 −1 ; 𝐵𝑖 ) (1) 𝑗=1

ASE’26, October 12–16, 2026, Munich, Germany

Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang

where 𝛾 are parameters of the repair model. Based on this, Multi2 Fixer introduces a set of Proposers to repair individual hunks and generate hunk-level patches, and a Coordinator to select the most promising candidate patch under the current repair context, as well as to orchestrate the repair order of the hunks. Thus, the Coordinator-Proposer repair framework can be formalized as: Definition 2 (Coordinator-Proposer Repair Framework). The Coordinator-Proposer repair process is characterized by three sequential and iterative steps: (1) Hunk Selection by Coordinator: The Coordinator selects the next hunk ℎ next to repair based on previously repaired hunks and patches, modeling the repair order as a conditional policy: ℎ next = ℎ 𝑗

where

𝑗 = arg max Pr(ℎ 𝑗 | 𝐻𝑖 , 𝑃 < 𝑗 , 𝐵𝑖 ; 𝜃𝑐 ) 𝑗 ∈U

(2)

where U is the set of unpatched hunks, 𝐻𝑖 is the set of all buggy hunks, 𝑃 < 𝑗 denotes patches generated for prior hunks, and 𝜃𝑐 are parameters of the Coordinator’s policy. (2) Patch Proposal by Proposers: Given ℎ next , 𝐾 Proposers 𝐾 , forming the independently generate candidate patches {𝑐𝑘 }𝑘=1 𝐾 candidate set 𝐶 = {𝑐𝑘 }𝑘=1 . Each patch is sampled from a proposal distribution: 𝑐𝑘 ∼ 𝑝𝜙 (𝑐 | ℎ next, 𝐵𝑖 ),

𝑘 = 1, . . . , 𝐾

(3)

where 𝜙 represents the parameters of the Proposer models. (3) Patch Selection by Coordinator: The Coordinator evaluates the candidate set and selects 𝑐 opt by maximizing the estimated probability of correctness, where “optimal” denotes the candidate judged most promising under the current hunk context and partial repair state: 𝑐 opt = arg max Pr(valid(𝑐) | 𝑐, ℎ next, 𝐵𝑖 ; 𝜃𝑐 ) 𝑐 ∈𝐶

(4)

valid(𝑐) denotes that candidate 𝑐 is syntactically correct and can successfully compile.

3.2

Overview

Figure 3 illustrates the comprehensive workflow of Multi2 Fixer, which is meticulously structured into four distinct yet interrelated phases: bug analysis, repair context construction, patch generation, and patch refinement. In the bug analysis phase, Multi2 Fixer employs a tool-augmented bug analysis agent, BugAnalyzer, to locate and analyze the root cause and relevant code of the bug, ultimately generating a bug report. In the repair context construction phase, Multi2 Fixer collects five types of information as context for the repair model: the buggy code, surrounding code near the bug, the bug report generated in Phase 1, the failing test cases, and the test error report. In the patch generation phase, Multi2 Fixer employs a Coordinator-Proposer architecture to perform heuristic patch search for multi-hunk bugs. Specifically, Proposers are a group of agents responsible for generating hunk-level candidate patches, while the Coordinator handles hunk scheduling and retains the candidate judged most promising under the current repair context. Ultimately, Coordinator completes the repair of all hunks and assembles them into a complete patch. In the patch refinement

phase, Multi2 Fixer performs two-stage refinement on the patches generated in the previous stage. First, it compiles the patch; if compilation fails, it uses the compiler error messages to prompt the model for syntax refinement until the patch compiles successfully. Then, it applies the compiled patch to the buggy project, runs the relevant test cases, and iteratively refines the patch based on the test failure reports. In the following section, we provide a detailed description of each phase.

3.3

Workflow of Multi2 Fixer

3.3.1 Bug Analysis. When facing a bug, Multi2 Fixer first analyzes it by employing a dedicated tool-augmented agent called BugAnalyzer, which leverages code-related tools to understand the issue. Specifically, BugAnalyzer navigates the buggy codebase, gradually narrows down the bug’s scope, and ultimately identifies its root cause. To achieve this, we simulate the way human developers debug issues, modeling the process within an IDE environment (e.g., PyCharm). Initially, a developer examines the code corresponding to the error stack trace to gain insight into the failure. However, this part of code often represents only the tip of the iceberg, while the actual bug may reside in dependent or calling code. As a result, developers use their judgment to inspect suspicious variables, method calls, and other relevant elements in the buggy context. Modern IDEs provide powerful features such as navigation, code folding, and expansion, enabling developers to efficiently explore class and method skeletons to locate the source of bugs. To emulate these capabilities, we equip BugAnalyzer with a suite of tools that can inspect variable and field types, retrieve class skeletons, and obtain the project structure. These tools allow BugAnalyzer to simulate IDE-like navigation and exploration through tool calls. Once localization reaches the method level, developers typically examine the method’s implementation in detail to understand the bug. To support fine-grained analysis, we implement a method code viewing tool. Furthermore, recognizing that human short-term memory is limited, similar to the context window of LLMs, we design a context summarization tool that enables BugAnalyzer to autonomously compress and manage its working context. After multiple rounds of reasoning and tool invocations, BugAnalyzer ultimately outputs a comprehensive bug report, including the root cause of the bug, the relevant code, and a preliminary solution for fixing the bug. All tools used by BugAnalyzer are defined in Table 1, we use JavaParser to perform static analysis on the buggy projects and implement these tools based on the analysis. 3.3.2 Repair Context Construction. After completing the analysis of the bug, Multi2 Fixer begins constructing the repair context. Specifically, Multi2 Fixer considers five types of contextual information, including: (1) Buggy hunks. Since the buggy code directly reflects the exact location of the error and represents the most critical information for repair, we first incorporate it into the repair context in the form of a hunk list. At the same time, we include necessary contextual information such as the class and method in which the hunk is located. (2) Code near the buggy hunks. In addition to the buggy hunks, the code near the buggy hunk is also highly important. This surrounding code often provides dependency-related information required by the buggy hunk, such as variable declarations, method definitions, and control flow

Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

Multi2 Fixer

1

Chart_16

3

2

Bug Analysis

4 Patch Generation

Context Construction

Patch Refinement

Please help me analyzed the bug.

... Class DefaultIntervalCategoryDataset { else { this.seriesKeys = null; this.categoryKeys = null; } ... Buggy Hunk 1 ... } if (categoryKeys.length != this.startData[0].length)

Concat

I want to see the repo structure. Hunk 1

The buggy project is like ...

Buggy Hunk 2

Code Repo

Hunk 2

Syntax Refine

Hunk 3

Which hunk to fix?

Ok, I got it.

Compile

Buggy Hunks

Next, find out the type of x . The type of x is DefaultDataset.

Here is skeleton of DefaultDataset.

Agent Toolkits

Compile Success

# context below

How does DefaultDataset look?

The bug happens because ...

Environment

Code Near Bug The bug happens because:

Test Refine Proposer 1

Proposer 2

Proposer 3

Let me fix it

I got an idea

I can fix it

Run Tests Test Fail

Relevant code:

Patch +10 -12 GetProjectStructure project

GetClassSkeleton src

GetMethodBody

main/java/... Options.java

pom.xml test/java/. .. README.md

OptionsTest.java

Bug Report class DemoTest { @Test public testPrint_Empty() ... }

Test Result

Patch +6 -10 Patch +7 -13

Test Pass

Max Refine

Test Case

GetVariableType GetFieldType ......

Compile Failure

# context above

…

{ } ...

ASE’26, October 12–16, 2026, Munich, Germany

Test Fail (7/10): AssertEqual at line xxx

Test Error

I will select an optimum patch.

Figure 3: Overview of Multi2 Fixer. Table 1: Bug analysis tools for BugAnalyzer.

API Name GetProjectStructure ( ) GetImportOfFile (file) GetClassSkeleton (class) GetFieldType (class, field) GetVariableType (class, method, variable) GetMethodBody (class, method) SummarizeContext (summarizedContext) Exit ( )

Description and Output Description: Get the repository file structure. Output: The repository file structure. Description: Get the imports of a given file. Output: The imports of the file. Description: Get the skeleton of a class. Output: Class skeleton. Description: Get the type of a class variable. Output: Fully qualified name of the class variable’s type. Description: Get the type of a local variable. Output: Fully qualified name of the local variable’s type. Description: Get the code of a class method. Output: The code of the class method. Description: Condense excessive context. Output: The compressed context given by the agent. Description: Exit if the agent has finished analyzing the bug. Output: N/A

context. Therefore, we also include this nearby code in the repair context. Specifically, Multi2 Fixer employs three different levels of granularity when extending the context: line-level, method-level, and class-level context, to capture relevant semantic information at varying scopes. Line-level context includes specific lines (e.g., 10, 20, 50) of code immediately before and after the buggy hunk. Method-level context provides the entire method containing the bug. Class-level context encompasses the full definition of the buggy class. (3) Test code. To keep the repair context concise, we only include the code of the failing test cases. (4) Test failure report. The failure report contains abundant information about the cause of the error, which can greatly help the model understand and fix the bug. To reduce the context length, we only extract the first five lines of each failure report. (5) Bug report. Finally, we include the bug report generated by BugAnalyzer in Phase 1, which leverages

repository-level context and provides understanding of the bug and repair guidance, further enhancing the model’s ability to generate accurate fixes. Together, all five types of contexts form a comprehensive and multi-granular representation that enables precise and informed patch generation. 3.3.3 Patch Generation. After constructing the context, Multi2 Fixer proceeds to patch generation through a Coordinator-Proposer framework. In this framework, the Coordinator is responsible for scheduling the repair order of hunks and selecting the most promising patch, while multiple Proposers are responsible for generating candidate edits for the selected hunk. Hunk Scheduling. We design the hunk scheduling mechanism based on the characteristics of multi-hunk bugs. By analyzing multi-hunk bugs and their corresponding developer patches in Defects4J, we observe three representative repair patterns. First, in Symmetric Fixing, multiple hunks share similar bug patterns, so a repair strategy found for one hunk can often be reused or adapted for others. For example, in Chart_19, null checks need to be inserted for two different objects; although the target variables differ, the repair structure is highly similar. Second, in Stepwise Fixing, some hunks have clear prerequisite relations, such as introducing a field before initializing it or defining a helper function before calling it. For instance, in Cli_39, a file-stream creation function must be implemented before the faulty call site can be corrected. Third, in Change Propagation, a code change in one location requires coordinated updates in other locations to preserve consistency. For example, in Closure_64, modifying the parameter list of the to_source method requires corresponding changes at its call sites.

ASE’26, October 12–16, 2026, Munich, Germany

Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang

These observations suggest that multi-hunk repair should not be treated as a one-shot generation problem. Instead, the repair process should explicitly account for inter-hunk dependencies and repair order. To this end, the Coordinator first uses static-analysis tools together with the bug report to construct a hunk-dependency graph: 𝐺 = (𝐻, 𝐸),

𝑒𝑎𝑏 = (ℎ𝑎 , ℎ𝑏 , 𝑟 𝑎𝑏 , 𝑤 𝑎𝑏 )

(5)

where 𝐻 is the set of buggy hunks, 𝑟 𝑎𝑏 denotes the relation type between two hunks, and 𝑤 𝑎𝑏 denotes the relation confidence. The first three relation types correspond to the repair patterns discussed above, while failure relevance links hunks to the bug report or failure message. During repair, the Coordinator selects the next hunk according to this dependency graph and the current repair state: ℎ next = C(𝐺, 𝑆𝑡 , U𝑡 )

(6)

where U𝑡 is the set of unrepaired hunks. After a hunk-level patch is accepted, the repair state and dependency graph are updated, and the Coordinator uses the updated graph to choose the next hunk. Patch Proposal and Selection. After selecting the next hunk, the Coordinator sends the target hunk and the current repair state to 𝐾 Proposers, which independently generate a candidate set 𝐶𝑡 = {𝑐 1, . . . , 𝑐 𝐾 }. The Coordinator first normalizes these candidates and groups similar candidates into clusters P𝑡 = {𝑃1, . . . , 𝑃𝑚 }. For each candidate 𝑐, we define its cluster confidence as 𝜅 (𝑐) = |𝑃 (𝑐)|/𝐾, where 𝑃 (𝑐) is the cluster containing 𝑐; candidates supported by larger clusters receive higher confidence. We model the Coordinator’s selection as estimating three normalized criteria in [0, 1]: 𝑠 ctx (𝑐) for consistency with the bug report and local code context, 𝑠 state (𝑐) for compatibility with already accepted patches, and 𝑠 rel (𝑐) for consistency with the hunk-dependency graph and usefulness for subsequent related hunks. The final selection objective is: 𝑆 (𝑐) = 𝜅 (𝑐) + 𝑠 ctx (𝑐) + 𝑠 state (𝑐) + 𝑠 rel (𝑐),

𝑐 ∗ = arg max 𝑆 (𝑐) (7) 𝑐 ∈𝐶𝑡

Before accepting 𝑐 ∗ , the Coordinator applies a code-format fallback check. If the selected candidate violates basic structural constraints, such as inconsistent indentation, unbalanced brackets, invalid function-signature replacement, or copying surrounding context outside the target hunk, Multi2 Fixer falls back to the highest-scoring structurally valid candidate. If no generated replacement is structurally safe for a replacement hunk, the original hunk is preserved to avoid introducing a compilation failure; for insertion hunks, the highest-scoring non-empty candidate is used. Once a candidate is accepted, the partial patch is updated and the Coordinator proceeds to the next repair step. We define a repair trajectory as the ordered sequence of Coordinator decisions, selected hunks, accepted candidate patches, and any revisits made during one repair round. If this trajectory later proves inconsistent, the Coordinator may revisit a previously repaired hunk and revise its earlier decision. This mechanism operationalizes the generation-recognition motivation in Section 2.3: Proposers explore alternatives, while the Coordinator compares, scores, and filters them under the current repair state. The process iterates until all hunks are repaired or the maximum number of iterations is reached.

3.3.4 Patch Refinement. After Phase 3 assembles a complete patch, we use a dedicated refining model to perform two-stage patch refinement in Phase 4; here, a valid patch refers to a patch that is syntactically well-formed and can compile successfully. First, we perform syntax refinement on the patch if it fails to compile. During patch generation, models may introduce extraneous context or produce syntactic errors such as incorrect indentation, missing, or mismatched parentheses. To address these issues, we employ the refining model to carefully inspect and correct such errors through iterative feedback, ensuring syntactic validity. After iterative syntax refinement and compilation, if the patch successfully compiles, we proceed to test refinement. In this stage, the same refining model is further leveraged to interpret test failure reports and iteratively revise the patch when test cases fail. This process continues until the patch passes all test cases or reaches the maximum number of iterations.

4 Experimental Setup 4.1 Research Questions We evaluate Multi2 Fixer on the following research questions: RQ1: How does Multi2 Fixer compare against the state-of-the-art APR techniques? RQ2: How does Multi2 Fixer perform with different base models? RQ3: How does each component contribute to the performance of Multi2 Fixer? RQ4: How does Multi2 Fixer perform when extended to vulnerability repair tasks? RQ5: How does the cost of Multi2 Fixer compare to baselines?

4.2

Datasets

We evaluate Multi2 Fixer on Defects4J [23] and three vulnerability benchmarks: VUL4J [5], SEC-bench [26], and PatchEval [45]. Defects4J [23] is a collection of bugs from real Java open-source projects, including 395 bugs from Defects4J-v1.2 and 440 bugs from Defects4J-v2. VUL4J [5] consists of 79 reproducible, real-world Java vulnerabilities corresponding to 51 open-source projects. SECbench [26] contains 200 C++ security tasks, from which we select 65 multi-hunk cases. PatchEval [45] contains 1,000 real-world vulnerabilities in JavaScript, Go, and Python, from which we select 120 multi-hunk cases with runnable Docker environments. Specifically, to better investigate Multi2 Fixer’s repair performance across different types of bugs, we follow previous works [49, 51] to identify six types of bugs based on the location and scope of the faulty code, including single-line, single-hunk, single-method, multi-method, single-file, and multi-file bugs.

4.3

Baselines

We compare Multi2 Fixer against eleven state-of-the-art APR baselines, including ChatRepair [49], ThinkRepair [58], RepairAgent [2], GiantRepair [27], ContrastRepair [24], RepairLLaMA [39], ITER [57], MultiMend [12], BIRCH [31], PReMM [51], and NTR [19]. These baselines cover prompt-based, agent-based, fine-tuning-based, and multi-hunk APR methods. Unless otherwise noted, baseline results are taken directly from the original papers. If a paper does not report a particular result, we leave the corresponding table entry blank.

Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

4.4

Evaluation Metrics

We consider two widely used metrics [52, 55, 69] to evaluate the effectiveness of both Multi2 Fixer and baselines, and the quality of the generated patches. The definitions of the metrics are listed as follows. Correct Fix (CF) is defined as the number of bugs for which the generated patch passes all available tests and is manually checked for semantic correctness with respect to the developer patch. In this manual check, semantic correctness means that the generated patch preserves the intended program behavior captured by the developer patch, rather than merely passing the available tests. Plausible Fix (PF) is defined as the number of bugs for which the generated patch is valid and passes all available tests, but no manual semantic-equivalence check is applied.

4.5

Implementation Details

We implement Multi2 Fixer using both API-based models (e.g., GPT-3.5) and open-source models (e.g., Qwen2.5-72B). In our experiments, we use oracle function-level buggy locations provided by the benchmark setting as input to the repair framework. To control cost, we limit the number of tool invocations in the bug analysis phase to at most 20. During multi-hunk repair, we treat the repair of each individual hunk as one step and set the maximum number of hunk-repair steps to 20 per repair round. We dynamically assign different temperatures to the Proposers, with the temperatures uniformly distributed in the range [0, 1]. For example, when using three Proposers, their temperatures are set to 0, 0.5, and 1.0, respectively. In the patch refinement phase, we perform syntax refinement and test refinement, each with a maximum of three iterations. For each bug, we run five repair rounds. Patch Size. We define patch size as the number of complete patch candidates validated for each bug. Let 𝑅 denote the number of repair rounds, and let 𝐼 syn and 𝐼 test denote the maximum numbers of syntax-refinement and test-refinement iterations, respectively. The patch size is bounded by: 𝐵 patch ≤ 𝑅 × (1 + 𝐼 syn + 𝐼 test )

(8)

where the term 1 denotes the initial patch generated before refinement. In our experiments, we set 𝑅 = 5, 𝐼 syn = 3, and 𝐼 test = 3, yielding 𝐵 patch ≤ 5 × (1 + 3 + 3) = 35. Here, only complete patches submitted to compilation and testing are counted toward patch size, while intermediate hunk-level edits are not counted. Notably, the patch size used in our experiments is relatively small compared with that used in many existing studies. We implement Multi2 Fixer based on the PyTorch and Transformers frameworks. All experiments are conducted on two NVIDIA Tesla V100 GPUs on a single Ubuntu 20.04 server.

5 Evaluation and Results 5.1 RQ1: Comparison with State-of-the-Arts Experimental Design. In RQ1, we aim to evaluate the performance of Multi2 Fixer. We select eleven state-of-the-art APR methods as baselines, including both LLM-based (e.g., ChatRepair) and agentbased (e.g., RepairAgent) approaches, and compare their repair performance with Multi2 Fixer on a total of 835 bugs in Defects4J. We use GPT-3.5 as the base model to facilitate comparison with prior APR studies.

ASE’26, October 12–16, 2026, Munich, Germany

Overall Performance. Table 2 presents the comparison results on Defects4J. Since prior baselines are evaluated under different scopes, we use the Scope column to distinguish full-benchmark and subset results; cross-scope comparisons are reported only as contextual evidence. On the full Defects4J-v1.2+v2 benchmark with 835 bugs, Multi2 Fixer fixes 326 bugs and generates 412 plausible patches. Among baselines evaluated on the same 835-bug scope, Multi2 Fixer outperforms PReMM, the strongest full-scope baseline, by 19 correct fixes and 37 plausible fixes. For multi-hunk repair, the advantage of Multi2 Fixer is more visible on complex bug categories. Multi2 Fixer fixes 62 multi-method bugs and 27 multi-file bugs, exceeding PReMM (45 multi-method and 15 multi-file bugs), MultiMend (17 multi-method and 9 multi-file bugs), and RepairAgent (7 multi-method and 3 multi-file bugs). In contrast, on simpler categories such as SL, SH, and SM, the performance gap is smaller, suggesting that Multi2 Fixer’s main benefit comes from coordinating repairs across multiple hunks, methods, or files. Overlap Analysis. We select the top four baselines with the best repair results for the overlap analysis. Figure 4 shows the Venn diagram of the bugs fixed by RepairAgent [2], ChatRepair [49], ThinkRepair [58], PReMM [51] and Multi2 Fixer on Defects4J-v1.2 and Defects4J-v2. Figure 4 shows that Multi2 Fixer fixes additional unique bugs, including 44 and 51 unique bugs on DefectsJ-v1.2 and v2, respectively, compared to the other 4 baselines. We further observe that among the 95 unique bugs fixed by Multi2 Fixer, 46 are multi-hunk, highlighting Multi2 Fixer’s strong capability in multi-hunk repair. Additionally, Table 3 compares the distribution of fixed bugs across different methods from the perspective of buggy projects. Multi2 Fixer shows balanced repair performance across all projects and performs well on projects such as JxPath, JacksonDatabind, and Math.

9 PReMM 30 8

3 1 15 3

4 2 19 MultiFixer

44

3

3

RepairAgent 3 5

30 3 6

3 1 11

2

7 ChatRepair

6 2

4

PReMM

4 5 27 0

19 44

2 3 34

3 3

0

ThinkRepair

(a) Venn on Defects4J-v1.2

MultiFixer

51

2 5

0

17 9 6

RepairAgent 1 4

1

ChatRepair 1 3

3

6 20

8 26 12 25 10

ThinkRepair

(b) Venn on Defects4J-v2

Figure 4: Bugfix Venn Diagram on Defects4J (Multi2 Fixer, ThinkRepair, ChatRepair, RepairAgent, PReMM)

5.2

RQ2: Performance of Different Base Models

Experimental Design. In RQ1, we use GPT-3.5 as the base model to facilitate comparison with prior APR studies on Defects4J. To further investigate the impact of different base models on Multi2 Fixer, in RQ2 we select several currently mainstream models beyond GPT3.5, including Claude-3.5-Sonnet, DeepSeek-V3.2-Exp, Qwen2.5Max, and the open-source model Qwen2.5-72B-Instruct, as base models for Multi2 Fixer, and evaluate their repair performance on Defects4J, respectively.

ASE’26, October 12–16, 2026, Munich, Germany

Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang

Table 2: Overall performance of Multi2 Fixer, Single Line (SL), Single Hunk (SH), Single Method(SM), Multiple Methods (MM), Single File (SF), Multiple files (MF), Correct Fix (CF), Plausible Fix (PF). We report only the results explicitly provided in the original baseline papers; missing entries are denoted by -. Scope denotes the number or subset of Defects4J bugs evaluated in the original study; in the Scope column, MH indicates the multi-hunk subset.

Method

Scope

ITER (ICSE, 2024) ThinkRepair (ISSTA, 2024) ChatRepair (ISSTA, 2024) RepairAgent (ICSE, 2025) RepairLLaMA (TSE, 2025) GiantRepair (TOSEM, 2025) ContrastRepair (TOSEM, 2025) MultiMend (arXiv, 2025) BIRCH (ASE, 2025) NTR (ICSE, 2025) PReMM (OOPSLA, 2025) Multi2 Fixer (Ours)

SL

SH

SM

D4J-v1.2 MM SF

MF

CF

PF

SL

SH

SM

D4J-v2.0 MM SF

MF

CF

PF

Total CF PF

36 52 57 52 28 60 47 53 49

44 78 79 67 48 99 61 70 74

52 98 114 86 52 101 67 121 120

7 0 0 4 1 2 12 26 28

5 0 0 2 0 0 5 7 7

59 98 114 90 53 103 79 139 147 148

89 96 127 83 177 184 182

9 47 48 48 90 28 40 37 52 56

15 81 48 61 139 52 40 63 129 98

16 107 48 71 142 51 40 65 141 144

3 0 0 3 2 2 0 5 19 34

3 0 0 1 0 0 0 4 8 20

36 107 48 74 144 53 40 70 160 178

19 90 195 132 50 191 230

78 205 162 164 144 106 143 149 139 307 326

Patch Size

476 483 SM 337 835 483 483 SM 337 835 372 MH D4J-v1.2 835 835

1000 ≤125 ≤500 ≈117 10 ≤200 ≤160 ≥100 1 100 15 ≤35

54 98 114 88 53 103 74 140 141

16 107 48 73 144 53 40 66 152 158

125 186 195 201 259 133 177 375 412

Table 3: Distribution of bugs fixed by Multi2 Fixer across projects in Defects4J. Core is short for JacksonCore, Xml is short for JacksonXml, Databind is short for JacksonDatabind, Collect is short for Collections. Multi2 Fixer Closure Chart Lang Math Mockito Time Cli Codec Collect Compress Csv Gson Core Databind Xml JxPath Jsoup Total # Bugs

174

26

64

106

38

26

39

18

4

47

16

18

26

112

6

22

93

835

Plausible Correct

55 41

15 15

36 29

54 45

20 18

11 7

22 17

11 10

2 2

28 19

12 8

9 9

14 11

62 48

3 3

9 8

49 36

412 326

PReMM ThinkRepair RepairAgent ChatRepair MultiMend RepairLLaMA ContrastRepair NTR GiantRepair ITER

37 34 27 37 27 21 32 40 18 18

22 11 11 15 8 9 12 14 7 10

36 19 17 21 16 13 19 29 5 10

41 27 29 32 23 24 30 39 20 20

9 6 6 6 6 4 8 12 3 0

4 4 2 3 1 3 2 5 1 2

17 9 8 5 11 6 4 0 4 6

8 10 9 8 6 3 5 0 6 3

0 0 1 0 1 1 0 0 0 0

22 16 10 2 8 10 2 0 7 4

10 8 6 3 4 4 3 0 5 2

7 5 3 3 3 5 1 0 3 0

13 7 5 3 2 3 3 0 6 3

44 17 11 9 12 15 7 0 10 0

1 2 1 1 2 0 1 0 1 0

1 2 0 0 3 0 0 0 0 0

35 28 18 14 16 23 14 0 10 0

307 205 164 162 149 144 143 139 106 78

Results and Analysis. As shown in Table 4, all five base models demonstrate remarkable repair capability on Defects4J when integrated with Multi2 Fixer. Specifically, Claude-3.5-Sonnet significantly outperforms the other models, generating 514 plausible fixes and correctly repairing 420 of them, achieving a repair rate of 50.29%. Especially on various types of multi-hunk bugs, Claude demonstrates balanced performance due to its deep understanding of syntactic and semantic relationships across different code locations. Qwen2.5-Max ranks second overall, repairing 71 fewer bugs than Claude-3.5-Sonnet. DeepSeek-V3.2-Exp performs well on single-hunk bugs, ranking second among the five models, but shows poor performance on multi-hunk bugs, repairing only 55 MM bugs and 20 MF bugs, placing last among the five models. This not only highlights the significant differences in structural characteristics and repair difficulty between single-hunk and multi-hunk bugs, but also reflects DeepSeek-V3.2-Exp’s inability to maintain balanced and comprehensive performance across different types of bugs. Notably, the smaller-scaled model Qwen2.5-72B-Instruct also achieves promising repair results on Defects4J, fixing only 15 fewer bugs than GPT-3.5. This demonstrates that Multi2 Fixer can

effectively adapt to LLMs of different sizes and maintain strong performance across diverse base models.

5.3

RQ3: Ablation Study

Experimental Design. In RQ1 and RQ2, we have compared Multi2 Fixer with existing methods and discussed the differences in repair effectiveness among various base models on the full Defects4J benchmark. In the subsequent ablation study, we focus more on the effectiveness of each component of Multi2 Fixer in the context of multi-hunk bug repair. Specifically, we analyze and discuss the effectiveness of the four components used by Multi2 Fixer, using a total of 372 multi-hunk bugs from Defects4J. We systematically remove each component from Multi2 Fixer one at a time, and compare the repair performance of Multi2 Fixer before and after the removal of each individual component. RQ3.1: Effectiveness of Bug Analysis. In RQ3.1, we first discuss the impact of bug analysis on repair effectiveness. As shown in Table 5, all five models show improved repair performance after incorporating bug analysis. Among them, GPT-3.5 and ClaudeSonnet-3.5 show the most significant improvement, fixing 18 and

Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

ASE’26, October 12–16, 2026, Munich, Germany

Table 4: Performance of Multi2 Fixer using different base models.

SL

SH

SM

D4J-v1.2 MM SF

MF

CF

PF

SL

SH

SM

D4J-v2.0 MM SF

MF

CF

PF

Total CF PF

49 59 57 51 47

74 98 96 82 69

120 157 137 133 116

28 37 26 35 26

7 11 5 9 7

148 194 163 168 142

182 232 198 203 175

56 68 62 56 54

98 115 101 96 93

144 178 147 145 139

34 48 29 36 30

20 27 15 24 17

178 226 223 181 169

230 282 238 234 224

326 420 339 349 311

Model GPT-3.5 Claude-3.5 DeepSeek-V3.2 Qwen2.5-Max Qwen2.5-72B

141 183 158 159 135

17 additional multi-hunk bugs, respectively, and both achieve 24 more plausible fixes. In contrast, bug analysis has a weaker effect on DeepSeek-V3.2-Exp, merely enabling the model to fix 9 additional bugs, which is consistent with DeepSeek-V3.2-Exp’s overall poorer performance in fixing multi-hunk bugs. Moreover, we find that bug analysis not only enables the model to successfully fix bugs that were previously completely unreparable (i.e., no plausible fix), but also helps the model achieve a more comprehensive understanding of bugs that already had plausible fixes but were not fully resolved. This leads to more complete and refined repairs. Such improvements are particularly evident in scenarios involving edge cases and complex conditional logic. Table 5: Ablation study on bug analysis.

w/o Bug Analysis w/ Bug Analysis

GPT-3.5

Claude-3.5

DeepSeek-V3.2

Qwen2.5-Max

Qwen2.5-72B

71/100 89/124

112/138 129/162

63/85 72/94

96/117 106/135

68/95 82/108

RQ3.2: Effectiveness of Repair Context. In RQ3.2, we compare the impact of three different context granularities on the repair outcomes. As shown in Table 6, we find that the performance of line-level and method-level contexts is comparable, while classlevel context yields poorer repair results. After detailed analysis, we identify two reasons for the poorer performance of class-level context. First, some classes contain numerous functions unrelated to the repair task, causing the repair context to exceed the model’s context window and directly leading to repair failure. Second, the redundant context introduces irrelevant information that interferes with the model’s judgment, causing it to incorrectly associate the bug with unrelated code and resulting in erroneous fixes. For linelevel context, we experiment with different lengths ranging from 5 to 50 in increments of 5. By comparing the results, we find that a context length of 20 achieves the best trade-off between performance and cost. This result is comparable to that of method-level context, because a properly sized line-level context effectively preserves the relevant information within the method. In contrast, although method-level context achieves good repair performance, it sometimes leads to information redundancy and increased cost when the buggy method is excessively long (e.g., more than 300 lines). Thus, we conclude that line-level context offers greater flexibility and strikes a better balance between cost and performance, making it more suitable for Multi2 Fixer. RQ3.3: Effectiveness of the Coordinator-Proposer Framework. In RQ3.3, we compare Multi2 Fixer with three scheduling variants. To isolate the effect of hunk scheduling, Sequential Scheduling, Random Scheduling, and Multi2 Fixer all use the same

158 199 161 157 152

412 514 421 437 399

Table 6: Ablation study on context granularity. Context Granularity

GPT-3.5

Claude-3.5

DeepSeek-V3.2

Qwen2.5-Max

Qwen2.5-72B

Class-Level Context Method-Level Context Line-Level Context

79/100 86/122 89/124

115/143 132/167 129/162

64/82 70/91 72/94

97/124 110/141 106/135

72/88 78/101 82/108

number of Proposers (proposer=3), so the comparison focuses on the scheduling strategy. (1) w/o Scheduling removes explicit hunk scheduling and generates patches for all hunks at once as a whole-patch repair. (2) Sequential Scheduling repairs hunks one by one according to their order in the developer patch. (3) Random Scheduling shuffles the sequential hunk order using seed=42 and then repairs hunks one by one according to the shuffled order. As shown in Table 7, Multi2 Fixer consistently outperforms all three variants. Compared with w/o Scheduling, Multi2 Fixer fixes 18–56 more bugs across the five base models. Compared with Sequential Scheduling and Random Scheduling, Multi2 Fixer further fixes 2–13 and 3–16 more bugs, respectively. These results show that the improvement comes not only from iterative hunk-level repair, but also from dynamic scheduling by the Coordinator. Sensitivity of Proposer Number. We conduct a sensitivity experiment on the number of Proposers by sampling 100 multi-hunk bugs from Defects4J. When increasing the number of Proposers from 3 to 5, patch selection becomes less stable across three runs and shows a 3–10% performance drop. This suggests that a larger candidate pool can introduce noisy or conflicting patches that outweigh useful diversity. Table 7: Ablation study on the Coordinator-Proposer framework. Scheduling Strategy

GPT-3.5

Claude-3.5

DeepSeek-V3.2

Qwen2.5-Max

Qwen2.5-72B

w/o Scheduling Sequential Scheduling (proposer=3) Random Scheduling (proposer=3) Coordinator-Proposer (proposer=3)

52/78 81/108 79/104 89/124

73/94 116/147 113/143 129/162

54/75 70/91 69/90 72/94

61/83 96/121 96/123 106/135

47/72 76/97 78/100 82/108

RQ3.4: Effectiveness of Patch Refinement. In RQ3.4, we discuss the impact of syntax refinement and test refinement on repair effectiveness separately. First, regarding syntax refinement, we find that the model often correctly understands the bug and generates generally correct patches, but may produce syntactic flaws (e.g., extra braces or inclusion of context code). Upon being prompted about such issues, the model is generally able to quickly fix syntax errors. Therefore, as shown in Table 8, we find that syntax refinement significantly improves repair effectiveness, with the five models fixing 19 to 38 additional bugs after applying syntax refinement. In contrast, test refinement is more challenging. It requires prompting

ASE’26, October 12–16, 2026, Munich, Germany

Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang

the model with failing test information to correct the patch, which in turn demands that the model understand the test report and make substantial modifications to the patch. Therefore, the effectiveness of test refinement is somewhat limited, yet it still helps the models fix an additional 17 to 24 bugs. By combining the two refinement strategies, the model can proceed from easy to difficult, first correcting simple syntax errors, and then further refining the semantics of the patch. Table 8: Ablation study on patch refinement. Refine Strategy

GPT-3.5

Claude-3.5

DeepSeek-V3.2

Qwen2.5-Max

Qwen2.5-72B

w/o Refinement + Syntax Refinement + Test Refinement

40/49 67/87 89/124

72/77 105 /134 129 /162

33/43 52/66 72/94

50/58 88/112 106/135

38/45 65/84 82/108

Results and Analysis. As shown in Table 11, we report the average cost of Multi2 Fixer on single-hunk and multi-hunk bugs, respectively. Since multi-hunk bug repair relies on multiple Proposers to generate patches independently, each Proposer’s conversation incurs additional cost, and the Coordinator’s scheduling also contributes to the overall expense. Therefore, the total cost of Multi2 Fixer (MH) is significantly higher than that of Multi2 Fixer (SH), approximately 2.5 times as much. However, compared to ChatRepair and RepairAgent, Multi2 Fixer adopts a significantly smaller patch size (e.g., ≤35), which is less than one-third of that used in prior works, thereby achieving substantial performance advantages. Specifically, Multi2 Fixer reduces repair time by 33% and monetary cost by 53% across all types of bugs.

6 Discussion 6.1 Data Leakage 5.4

RQ4: Performance of Multi2 Fixer on Vulnerability Repair

Experimental Design. In the previous RQs, we have evaluated Multi2 Fixer on the test-driven bug dataset Defects4J. To assess its generalizability to vulnerability repair, RQ4 uses three vulnerability benchmarks. First, we evaluate on VUL4J [5], including 35 singlehunk and 44 multi-hunk vulnerabilities. On VUL4J, we compare Multi2 Fixer with FSV [46], NTR [19], VRPILOT [25], APR4Vul [4], and ChatRepair [49]. Second, to further examine multi-hunk vulnerability repair beyond Java, we evaluate the multi-hunk subsets of SEC-bench [26] (C++, N=65) and PatchEval [45] (JavaScript, Go, and Python, N=120), and compare Multi2 Fixer with ChatRepair [49], PReMM [51], and MultiMend [12] under the same GPT-3.5 setting. Results on VUL4J. Table 9 shows the VUL4J results. With GPT-3.5 as the base model, Multi2 Fixer fixes 24 vulnerabilities, outperforming the second-best baseline APR4Vul by 8 fixes. Among these fixes, 5 are multi-hunk vulnerabilities, while the strongest baseline fixes at most 1 multi-hunk vulnerability. The Multi2 Fixer∗ result further shows that removing oracle fault localization preserves single-hunk performance (19/35) and still fixes 3 multi-hunk vulnerabilities, indicating that Multi2 Fixer remains effective in realistic end-to-end vulnerability repair. Results on SEC-bench and PatchEval. Table 10 reports the results on the multi-hunk subsets of SEC-bench and PatchEval. On SEC-bench, Multi2 Fixer fixes 11 vulnerabilities, outperforming ChatRepair with 9 fixes, MultiMend with 5 fixes, and PReMM with 2 fixes. On PatchEval, Multi2 Fixer fixes 19 vulnerabilities, also outperforming PReMM with 17 fixes, MultiMend with 8 fixes, and ChatRepair with 6 fixes. These results show that Multi2 Fixer’s advantage is consistent on non-Java vulnerability benchmarks and is especially visible on multi-hunk cases, where explicit hunk scheduling and hunk-level patch selection help coordinate edits across different vulnerable locations.

5.5

RQ5: Cost Analysis of Multi2 Fixer

Experimental Design. In addition to evaluating Multi2 Fixer’s repair capability, we further assess its practicality by computing the average resource consumption per bug, including the number of tokens used, time cost, and monetary cost, and compare these metrics with those of the baselines.

Since Defects4J and VUL4J contain bugs whose fixing dates may precede the release of modern LLMs (e.g., GPT-3.5 in 2022), model memorization could contaminate repair results. We mitigate and analyze this risk as follows. (1) Same Model and Settings. We evaluate all compared methods with the same base model (GPT-3.5) and comparable parameter settings, making the relative comparison reliable. (2) Multiple Repair Types. We evaluate both bug repair and vulnerability repair benchmarks to reduce the risk that the conclusion is driven by memorization of one repair type. (3) Multiple Programming Languages. Beyond the Java-only Defects4J and VUL4J benchmarks, we further evaluate SEC-bench (C++) and PatchEval (JavaScript, Go, and Python), showing that Multi2 Fixer’s advantage is not limited to Java. (4) Time-Separated Analysis. We conduct a time-separated analysis on 2022+ vulnerabilities from SEC-bench and PatchEval. As shown in Table 12, Multi2 Fixer fixes 5 vulnerabilities from 2022, 1 from 2023, and 4 from 2024, matching PReMM in total and outperforming the other baselines. These cases provide a stricter check than the original pre-2022 Java benchmarks because their fixing dates are after the release of GPT-3.5. Moreover, Multi2 Fixer fixes the largest number of 2024 vulnerabilities, providing additional evidence that its advantage is not solely explained by benchmark memorization.

6.2

Trajectory Analysis of Hunk Scheduling

To better demonstrate the role of the proposed hunk scheduling mechanism, we conduct a trajectory case study on PatchEval CVE2024-3571. This vulnerability is a path traversal bug in LangChain’s LocalFileStore: user-controlled keys are checked only by a regex before being joined with the storage root, so malicious keys can escape the intended directory without canonicalization and rootcontainment checks. Multi2 Fixer schedules the three hunks as H2 → H3 → H1. H2 first canonicalizes root_path into a resolved absolute path, establishing the security invariant for the storage root. H3 then resolves each key-derived path and checks whether it remains under the canonical root, enforcing this invariant at the use site. H1 is repaired last to add the necessary import/scaffold edits. This trajectory follows a security-driven repair logic: first establish the root-path invariant, then enforce the invariant at

Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

ASE’26, October 12–16, 2026, Munich, Germany

Table 9: Comparison results between Multi2 Fixer-Vul and existing baselines on VUL4J. ∗ denotes Multi2 Fixer without oracle fault localization.

Single-Hunk Multi-Hunk Total

Multi2 Fixer

Multi2 Fixer∗

FSV-Codex [46]

FSV-finetuned [46]

NTR [19]

VRPILOT [25]

APR4Vul [4]

ChatRepair [49]

19/35 5/44 24 (30.37%)

19/35 3/44 22 (27.85%)

11/35 0/44 10.9 (13.79%)

9 /35 0/44 9 (11.39%)

14/35 0/44 14 (17.72%)

14/35 0/44 14 (17.72%)

16/35 0/44 16 (20.25%)

14/35 1/44 15 (18.98%)

Table 10: Repair results on the multi-hunk subsets of SEC-bench and PatchEval. Dataset

Method

SM

MM

SF

MF

Total

SEC-bench (N=65)

ChatRepair PReMM MultiMend Multi2 Fixer

0 0 0 0

9 2 5 11

5 1 4 8

4 1 1 3

9 2 5 11

PatchEval (N=120)

ChatRepair PReMM MultiMend Multi2 Fixer

1 1 1 3

5 16 7 16

5 15 6 16

1 2 2 3

6 17 8 19

Table 11: Cost analysis between Multi2 Fixer, ChatRepair and RepairAgent on Defects4J. Method ChatRepair (2024) RepairAgent (2024) Multi2 Fixer (SH) Multi2 Fixer (MH) Multi2 Fixer (Avg)

Patch/Bug

Time/Bug

Token/Bug

Money/Bug

Charge/1k tokens

≤ 500 117 ≤ 35 ≤ 35 ≤ 35

≤ 5h 920s 373s 929s 620s

210,000 270,000 60,000 150,000 100,000

$0.42 $0.54 $0.12 $0.3 $0.2

$0.002 $0.002 $0.002 $0.002 $0.002

Table 12: Time-separated vulnerability repair results on selected vulnerabilities fixed in 2022 or later. Method

CVEs fixed after 2022 using GPT-3.5

ChatRepair

CVE-2022-29188, njs.cve-2023-27727, CVE-2024-5823, gpac.cve-2024-50665

PReMM

CVE-2022-24065, CVE-2022-29188, CVE-2022-31145, njs.cve-2022-31306, CVE-2022-35936, CVE-2022-37109, CVE-2023-39660, CVE-2023-40029, CVE-2024-5823, CVE-2024-39330

MultiMend

CVE-2022-21699, CVE-2022-29188, libdwarf.cve-2022-32200, libiec61850.cve-2023-27772, CVE-2023-40029, CVE-2024-5823

CVE-2022-21699, CVE-2022-23857, CVE-2022-29188, CVE-2022-31145, CVE-2022-35949, Multi2 Fixer

CVE-2023-40029, CVE-2024-3571, CVE-2024-24747, gpac.cve-2024-50665, CVE-2024-53900

the key-to-path conversion point, and finally add the supporting code required by these edits. In comparison, ChatRepair fails to produce parseable hunk updates, while PReMM and MultiMend generate patches that fail the PatchEval PoC. This case shows that, compared with a general agentic generate-select-refine pipeline, Multi2 Fixer’s advantage lies in hunk scheduling: it identifies the semantic role and dependency of each hunk and repairs them in an order that first establishes and then enforces the security invariant.

6.3

Coordinator may exhaust the 20-step budget by repeatedly revising already repaired hunks; among 16 bugs with 10+ hunks, 11 (68.75%) exhibit this behavior. (2) Complex Inter-Hunk Dependency. For bugs with multi-directional or multi-level dependencies, the correct edit for one hunk may depend on decisions made in several other hunks. In a random sample of 20 failed cases, 7 (35%) cases, such as Chart_18, involve such dependencies. These failures suggest that the main bottleneck is often scheduling and coordination under high hunk complexity, rather than simply generating individual hunk patches.

7

Threats to Validity

Internal Validity. Internal validity concerns experimental biases affecting evaluation fairness and consistency. Because LLM-based repair is stochastic, output randomness may introduce noise. We mitigate this by running Multi2 Fixer for five repair rounds per bug under identical settings and validating all complete patch candidates. This reduces sampling-induced instability while bounding the patch size at 35, balancing effectiveness and efficiency. All experiments run on the same machine in isolated environments to minimize uncontrolled factors. External Validity. External validity concerns whether our findings generalize beyond the evaluated benchmarks. Because Defects4J may not capture the diversity of real-world defects, we additionally evaluate Multi2 Fixer on VUL4J, SEC-bench, and PatchEval, covering Java, C++, JavaScript, Go, and Python vulnerability repair. The results indicate that Multi2 Fixer generalizes beyond test-driven bug repair and remains effective across vulnerability benchmarks.

8

Conclusion

In this paper, we propose Multi2 Fixer, a Coordinator-Proposer based multi-agent framework for fixing multi-hunk bugs. By combining tool-augmented bug analysis, fine-grained repair context construction, hierarchical patch generation, and iterative refinement, Multi2 Fixer can effectively address the challenges of repair order scheduling, hunk-level patch generation, and hunklevel patch selection. Across Defects4J, VUL4J, SEC-bench, and PatchEval, Multi2 Fixer fixes 326 Defects4J bugs (62 multi-method and 27 multi-file), 24/79 VUL4J vulnerabilities (22 without oracle fault localization), and 11/65 and 19/120 multi-hunk vulnerabilities on SEC-bench and PatchEval. Our work demonstrates the power of collaborative agents in fixing multi-hunk bugs.

Failure Analysis

Although Multi2 Fixer is effective for multi-hunk bug repair, it can still fail in specific high-complexity scenarios. Our manual inspection identifies two dominant patterns. (1) Excessive-Hunk Looping. For bugs with many hunks (10+), such as Jsoup_87, the

Acknowledgments This research was supported in part by Natural Science Foundation of Jiangsu Province (BK20251458), and Fundamental Research Funds for the Central Universities (AE89991/463).

ASE’26, October 12–16, 2026, Munich, Germany

Haichuan Hu, Chunrong Fang, Ye Shang, Jiawei Liu, Weifeng Sun, Guoqing Xie, Chenxing Zhong, and Quanjun Zhang

Data Availability Statement

[21] Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2024. A survey on large language models for code generation. arXiv preprint arXiv:2406.00515 (2024). [22] Nan Jiang, Thibaud Lutellier, and Lin Tan. 2021. Cure: Code-aware neural machine translation for automatic program repair. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 1161–1173. [23] René Just, Darioush Jalali, and Michael D Ernst. 2014. Defects4J: A database of existing faults to enable controlled testing studies for Java programs. In Proceedings of the 2014 international symposium on software testing and analysis. 437–440. [24] Jiaolong Kong, Xiaofei Xie, Mingfei Cheng, Shangqing Liu, Xiaoning Du, and Qi Guo. 2025. Contrastrepair: Enhancing conversation-based automated program repair via contrastive test case pairs. ACM Transactions on Software Engineering and Methodology 34, 8 (2025), 1–31. [25] Ummay Kulsum, Haotian Zhu, Bowen Xu, and Marcelo d’Amorim. 2024. A case study of llm for automated vulnerability repair: Assessing impact of reasoning and patch validation feedback. In Proceedings of the 1st ACM International Conference on AI-Powered Software. 103–111. [26] Hwiwon Lee, Ziqi Zhang, Hanxiao Lu, and Lingming Zhang. 2025. SEC-bench: Automated Benchmarking of LLM Agents on Real-World Software Security Tasks. arXiv preprint arXiv:2506.11791 (2025). [27] Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang. 2025. Hybrid automated program repair by combining large language models and program analysis. ACM Transactions on Software Engineering and Methodology 34, 7 (2025), 1–28. [28] Yizhou Liu, Pengfei Gao, Xinchen Wang, Jie Liu, Yexuan Shi, Zhao Zhang, and Chao Peng. 2024. Marscode agent: Ai-native automated bug fixing. arXiv preprint arXiv:2409.00899 (2024). [29] Ehsan Mashhadi and Hadi Hemmati. 2021. Applying codebert for automated program repair of java simple bugs. In 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, 505–509. [30] Noor Nashid, Daniel Ding, Keheliya Gallaba, Ahmed E Hassan, and Ali Mesbah. 2025. Beyond Accuracy: Behavioral Dynamics of Agentic Multi-Hunk Repair. arXiv preprint arXiv:2511.11012 (2025). [31] Noor Nashid, Daniel Ding, Keheliya Gallaba, Ahmed E Hassan, and Ali Mesbah. 2025. Characterizing Multi-Hunk Patches: Divergence, Proximity, and LLM Repair Challenges. arXiv preprint arXiv:2506.04418 (2025). [32] Noor Nashid, Mifta Sintaha, and Ali Mesbah. 2023. Retrieval-based prompt selection for code-related few-shot learning. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2450–2462. [33] Anvith Pabba, Alex Mathai, Anindya Chakraborty, and Baishakhi Ray. 2025. SemAgent: A Semantics Aware Program Repair Agent. arXiv preprint arXiv:2506.16650 (2025). [34] Romain Peyrichou. 2026. The Generation-Recognition Asymmetry: Six Dimensions of a Fundamental Divide in Formal Language Theory. arXiv preprint arXiv:2603.10139 (2026). [35] Joseph Renzullo, Pemma Reiter, Westley Weimer, and Stephanie Forrest. 2025. Automated Program Repair: Emerging trends pose and expose problems for benchmarks. Comput. Surveys 57, 8 (2025), 1–18. [36] Pat Rondon, Renyao Wei, José Cambronero, Jürgen Cito, Aaron Sun, Siddhant Sanyam, Michele Tufano, and Satish Chandra. 2025. Evaluating agent-based program repair at google. arXiv preprint arXiv:2501.07531 (2025). [37] Ye Shang, Quanjun Zhang, Chunrong Fang, Siqi Gu, Jianyi Zhou, and Zhenyu Chen. 2025. A large-scale empirical study on fine-tuning large language models for unit testing. Proceedings of the ACM on Software Engineering 2, ISSTA (2025), 1678–1700. [38] Ye Shang, Quanjun Zhang, Haichuan Hu, Chunrong Fang, Liang Xiao, and Zhenyu Chen. 2026. Breaking, Stale, or Missing? Benchmarking Coding Agents on ProjectLevel Test Evolution. arXiv preprint arXiv:2605.06125 (2026). [39] André Silva, Sen Fang, and Martin Monperrus. 2025. Repairllama: Efficient representations and fine-tuned adapters for program repair. IEEE Transactions on Software Engineering (2025). [40] Dominik Sobania, Martin Briesch, Carol Hanna, and Justyna Petke. 2023. An analysis of the automatic bug fixing performance of chatgpt. In 2023 IEEE/ACM International Workshop on Automated Program Repair (APR). IEEE, 23–30. [41] Felix Stahlberg. 2020. Neural machine translation: A review. Journal of Artificial Intelligence Research 69 (2020), 343–418. [42] Alex Wang and Kyunghyun Cho. 2019. BERT has a mouth, and it must speak: BERT as a Markov random field language model. arXiv preprint arXiv:1902.04094 (2019). [43] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reasoning in large language models. Advances in neural information processing systems 35 (2022), 24824–24837. [44] Yuxiang Wei, Olivier Duchenne, Jade Copet, Quentin Carbonneaux, Lingming Zhang, Daniel Fried, Gabriel Synnaeve, Rishabh Singh, and Sida I Wang. 2025. Swe-rl: Advancing llm reasoning via reinforcement learning on open software evolution. arXiv preprint arXiv:2502.18449 (2025). [45] Zichao Wei, Jun Zeng, Ming Wen, Zeliang Yu, Kai Cheng, Yiding Zhu, Jingyi Guo, Shiqi Zhou, Le Yin, Xiaodong Su, and Zhechao Ma. 2025. PATCHEVAL: A New

To facilitate reproducibility and further research, we release the full implementation of Multi2 Fixer, including the source code, experiment configurations, and data processing pipeline. The project is available at https://zenodo.org/records/21223018.

References [1] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 (2023). [2] Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2024. Repairagent: An autonomous, llm-based agent for program repair. arXiv preprint arXiv:2403.17134 (2024). [3] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Language models are few-shot learners. Advances in neural information processing systems 33 (2020), 1877–1901. [4] Quang-Cuong Bui, Ranindya Paramitha, Duc-Ly Vu, Fabio Massacci, and Riccardo Scandariato. 2024. APR4Vul: an empirical study of automatic program repair techniques on real-world Java vulnerabilities. Empirical software engineering 29, 1 (2024), 18. [5] Quang-Cuong Bui, Riccardo Scandariato, and Nicolás E Díaz Ferreyra. 2022. Vul4j: A dataset of reproducible java vulnerabilities geared towards the study of program repair techniques. In Proceedings of the 19th International Conference on Mining Software Repositories. 464–468. [6] Viola Campos, Ridwan Shariffdeen, Adrian Ulges, and Yannic Noller. 2025. Empirical Evaluation of Generalizable Automated Program Repair with Large Language Models. arXiv preprint arXiv:2506.03283 (2025). [7] Jialun Cao, Meiziniu Li, Ming Wen, and Shing-chi Cheung. 2025. A study on prompt design, advantages and limitations of chatgpt for deep learning program repair. Automated Software Engineering 32, 1 (2025), 1–29. [8] Dawn Drain, Chen Wu, Alexey Svyatkovskiy, and Neel Sundaresan. 2021. Generating bug-fixes using pretrained transformers. In Proceedings of the 5th ACM SIGPLAN international symposium on machine programming. 1–8. [9] Xueying Du, Mingwei Liu, Kaixin Wang, Hanlin Wang, Junwei Liu, Yixuan Chen, Jiayi Feng, Chaofeng Sha, Xin Peng, and Yiling Lou. 2024. Evaluating large language models in class-level code generation. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–13. [10] Zhiyu Fan, Haifeng Ruan, Sergey Mechtaev, and Abhik Roychoudhury. 2024. Oracle-guided Program Selection from Large Language Models. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 628–640. [11] Mahdi Farzandway and Fatemeh Ghassemi. 2025. Automated repair of c programs using large language models. arXiv preprint arXiv:2509.01947 (2025). [12] Reza Gharibi, Mohammad Hadi Sadreddini, and Seyed Mostafa Fakhrahmad. 2025. MultiMend: Multilingual Program Repair with Context Augmentation and Multi-Hunk Patch Generation. arXiv preprint arXiv:2501.16044 (2025). [13] Sichong Hao, Xianjun Shi, Hongwei Liu, and Yanjun Shu. 2023. Enhancing code language models for program repair by curricular fine-tuning framework. In 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 136–146. [14] Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John C. Grundy, and Haoyu Wang. 2023. Large Language Models for Software Engineering: A Systematic Literature Review. CoRR abs/2308.10620 (2023), arXiv–2308. [15] Haichuan Hu, Ye Shang, Weifeng Sun, and Quanjun Zhang. 2025. TSAPR: A Tree Search Framework For Automated Program Repair. arXiv preprint arXiv:2507.01827 (2025). [16] Haichuan Hu, Ye Shang, Guolin Xu, Congqing He, and Quanjun Zhang. 2025. Can GPT-O1 Kill All Bugs? An Evaluation of GPT-Family LLMs on QuixBugs. In 2025 IEEE/ACM International Workshop on Automated Program Repair (APR). 11–18. doi:10.1109/APR66717.2025.00007 [17] Haichuan Hu, Guoqing Xie, Quanjun Zhang, Jiawei Liu, Shengcheng Yu, Chunrong Fang, Zhenyu Chen, and Liang Xiao. 2026. EvoRepair: Enhancing Vulnerability Repair Agents Through Experience-Based Self-Evolution. arXiv preprint arXiv:2605.30105 (2026). [18] Haichuan Hu, Xiaochen Xie, and Quanjun Zhang. 2025. Repair-r1: Better test before repair. arXiv preprint arXiv:2507.22853 (2025). [19] Kai Huang, Jian Zhang, Xiangxin Meng, and Yang Liu. 2025. Template-Guided Program Repair in the Era of Large Language Models.. In ICSE. 1895–1907. [20] Zhili Huang, Ling Xu, Chao Liu, Weifeng Sun, Xu Zhang, Yan Lei, Meng Yan, and Hongyu Zhang. 2025. DynaFix: Iterative Automated Program Repair Driven by Execution-Level Dynamic Information. arXiv preprint arXiv:2512.24635 (2025).

Multi2 Fixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs

Benchmark for Evaluating LLMs on Patching Real-World Vulnerabilities. arXiv preprint arXiv:2511.11019 (2025). [46] Yi Wu, Nan Jiang, Hung Viet Pham, Thibaud Lutellier, Jordan Davis, Lin Tan, Petr Babkin, and Sameena Shah. 2023. How effective are neural networks for fixing security vulnerabilities. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1282–1294. [47] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2024. Agentless: Demystifying llm-based software engineering agents. arXiv preprint arXiv:2407.01489 (2024). [48] Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated program repair in the era of large pre-trained language models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 1482–1494. [49] Chunqiu Steven Xia and Lingming Zhang. 2024. Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 819–831. [50] Jiahong Xiang, Xiaoyang Xu, Fanchu Kong, Mingyuan Wu, Zizheng Zhang, Haotian Zhang, and Yuqun Zhang. 2024. How far can we go with practical function-level program repair? arXiv preprint arXiv:2404.12833 (2024). [51] Linna Xie, Zhong Li, Yu Pei, Zhongzhen Wen, Kui Liu, Tian Zhang, and Xuandong Li. 2025. PReMM: LLM-Based Program Repair for Multi-method Bugs via Divide and Conquer. Proceedings of the ACM on Programming Languages 9, OOPSLA2 (2025), 1316–1344. [52] Qi Xin, Haojun Wu, Steven P Reiss, and Jifeng Xuan. 2024. Towards Practical and Useful Automated Program Repair for Debugging. arXiv preprint arXiv:2407.08958 (2024). [53] Junjielong Xu, Ying Fu, Shin Hwei Tan, and Pinjia He. 2025. Aligning the objective of llm-based program repair. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2548–2560. [54] Aidan ZH Yang, Sophia Kolak, Vincent Hellendoorn, Ruben Martins, and Claire Le Goues. 2025. Revisiting unnaturalness for automated program repair in the era of large language models. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2561–2573. [55] Aidan ZH Yang, Sophia Kolak, Vincent J Hellendoorn, Ruben Martins, and Claire Le Goues. 2024. Revisiting Unnaturalness for Automated Program Repair in the Era of Large Language Models. arXiv preprint arXiv:2404.15236 (2024). [56] Boyang Yang, Zijian Cai, Fengling Liu, Bach Le, Lingming Zhang, Tegawendé F Bissyandé, Yang Liu, and Haoye Tian. 2025. A survey of LLM-based automated program repair: Taxonomies, design paradigms, and applications. arXiv preprint arXiv:2506.23749 (2025). [57] He Ye and Martin Monperrus. 2024. Iter: Iterative neural repair for multi-location patches. In Proceedings of the 46th IEEE/ACM international conference on software engineering. 1–13. [58] Xin Yin, Chao Ni, Shaohua Wang, Zhenhao Li, Limin Zeng, and Xiaohu Yang. 2024. Thinkrepair: Self-directed automated program repair. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1274–1286. [59] Zheng Yu, Ziyi Guo, Yuhang Wu, Jiahao Yu, Meng Xu, Dongliang Mu, Yan Chen, and Xinyu Xing. 2025. PatchAgent: A practical program repair agent mimicking human expertise. In Proceedings of the 34th USENIX Security Symposium (USENIX Security’25), Seattle, WA, USA. [60] Wei Yuan, Quanjun Zhang, Tieke He, Chunrong Fang, Nguyen Quoc Viet Hung, Xiaodong Hao, and Hongzhi Yin. 2022. CIRCLE: Continual repair across programming languages. In Proceedings of the 31st ACM SIGSOFT international symposium on software testing and analysis. 678–690. [61] Jiyang Zhang, Sheena Panthaplackel, Pengyu Nie, Junyi Jessy Li, and Milos Gligoric. 2022. Coditt5: Pretraining for source code and natural language editing. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering. 1–12. [62] Quanjun Zhang, Chunrong Fang, Siqi Gu, Ye Shang, Zhenyu Chen, and Liang Xiao. 2025. Large Language Models for Unit Testing: A Systematic Literature Review. arXiv preprint arXiv:2506.15227 (2025). [63] Quanjun Zhang, Chunrong Fang, Yuxiang Ma, Weisong Sun, and Zhenyu Chen. 2023. A survey of learning-based automated program repair. ACM Transactions on Software Engineering and Methodology 33, 2 (2023), 1–69. [64] Quanjun Zhang, Chunrong Fang, Yang Xie, YuXiang Ma, Weisong Sun, Yun Yang, and Zhenyu Chen. 2024. A systematic literature review on large language models for automated program repair. arXiv preprint arXiv:2405.01466 (2024). [65] Quanjun Zhang, Chunrong Fang, Tongke Zhang, Bowen Yu, Weisong Sun, and Zhenyu Chen. 2023. Gamma: Revisiting template-based automated program repair via mask prediction. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 535–547. [66] Quanjun Zhang, Haichuan Hu, Chunrong Fang, Ye Shang, Tao Zheng, Zhenyu Chen, Yun Yang, and Liang Xiao. 2026. On the Effectiveness of Code Representation in Deep Learning-Based Automated Patch Correctness Assessment. arXiv preprint arXiv:2603.07520 (2026).

ASE’26, October 12–16, 2026, Munich, Germany

[67] Quanjun Zhang, Ye Shang, Haichuan Hu, Chunrong Fang, Zhenyu Chen, and Liang Xiao. 2026. ComPass: Contrastive Learning for Automated Patch Correctness Assessment in Program Repair. arXiv preprint arXiv:2602.07561 (2026). [68] Quanjun Zhang, Yi Zheng, Ye Shang, Weifeng Sun, Haichuan Hu, Chunrong Fang, Zhenyu Chen, and Liang Xiao. 2026. ReProAgent: Tool-Augmented Multi-Stage Agentic Generation of Bug Reproduction Tests from Issue Reports. arXiv preprint arXiv:2607.09123 (2026). [69] Jiuang Zhao, Donghao Yang, Li Zhang, Xiaoli Lian, Zitian Yang, and Fang Liu. 2024. Enhancing Automated Program Repair with Solution Design. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 1706–1718.

Related documents

• Shortcutting the Fix: Identifying and Categorizing Agentic Exploits in Software Engineering Benchmarks#668134
• CAROL: Context-Aware Online Learning for Fuzzer Scheduling#668135
• An Autonomy Aware Metamodel for Human AI Collaboration in Software Engineering#668136
• A Unified Policy Architecture (UPA): The Governance Kernel for Enterprise AI Operating Systems#668137
• From Reading Code to Reading Spec: A Verified Layer for LLM-Driven Codebase Maintenance#668138