Automatic program repair can be a challenging task, especially when resolving complex issues at a repository-level, which often involves issue reproduction, fault localization, code repair, testing and validation. Issues of this scale can be commonly found in popular GitHub repositories or datasets that are derived from them. Some repository-level approaches separate localization and repair into distinct phases. Where this is the case, the fault localization approaches vary in terms of the granularity of localization. Where the impact of granularity is explored to some degree for smaller datasets, not all isolate this issue from the separate question of localization accuracy by testing code repair under the assumption of perfect fault localization. To the best of the authors' knowledge, no repository-scale studies have explicitly investigated granularity under this assumption, nor conducted a systematic empirical comparison of granularity levels in isolation. We propose a framework for performing such tests by modifying the localization phase of the Agentless framework to retrieve ground-truth localization data and include this as context in the prompt fed to the repair phase. We show that under this configuration and as a generalization over the SWE-Bench-Mini dataset, function-level granularity yields the highest repair rate against line-level and file-level. However, a deeper dive suggests that the ideal granularity may in fact be task dependent. This study is not intended to improve on the state-of-the-art, nor do we intend for results to be compared against any complete agentic frameworks. Rather, we present a proof of concept for investigating how fault localization may impact automatic code repair in repository-scale scenarios. We present preliminary findings to this end and encourage further research into this relationship between the two phases.
Figures & tables
Figure 1. A modified version of the Agentless framework ( Xia et al., 2025 ) was designed to conduct the experiments. The file localization and patch validation phase from the original work were bypassed such that a replacement script derives perfect localization data from the ground truth patches to produce the raw generated patches for SWEBench evaluation in order to concentrate the study on the effect of localization granularity.
Figure 2. Fault localization at various levels of granularity, demonstrated in a hypothetical repository containing two sorting methods. The actual fault is in the mergeSort method of merge_sort.py , where n should be replaced with m . At line-level granularity, only these two code lines are provided as context for the repair phase, indicated by the yellow highlight. At function-level, the entire function is provided. And at file-level, the entire merge_sort.py is provided.
Figure 3. Box plot of resolve rate achieved for different granularities of perfect fault localization as reported in table 1
Granularity
Resolved
Unresolved
Completed
Resolved Rate (%)
σ (Rate)
Line
21.8
26.8
48.6
43.6
2.6
Function
22.8
27.2
50.0
45.6
1.5
File
21.3
27.5
48.8
42.6
1.6
Table 1. Resolved rates and corresponding standard deviation ( σ ) for code repair using Qwen3-Coder under the Agentless framework on the SWE-Bench-Mini dataset. Repair prompts are derived from ground-truth fault localization at different granularities. Results are averaged over 10 trials.
Figure 4. Mean resolution rate by problem difficulty tier and localization granularity. Difficulty is inferred from human annotator resolution time as provided in the SWE-Bench Verified metadata. Results are averaged over 10 trials per granularity.
Automated program repair (APR) struggles to scale from isolated functions to full repositories, as it demands a global, task-aware understanding to locate necessary changes. Current methods, limited by context and reliant on shallow retrieval or costly agent iterations, falter on complex cross-file issues. To this end, we propose RepoRepair, a novel documentation-enhanced approach for repository-level fault localization and program repair. Our core insight is to leverage LLMs to generate hierarchical code documentation (from functions to files) for code repositories, creating structured semantic abstractions that enable LLMs to comprehend repository-level context and dependencies. Specifically, RepoRepair first employs a text-based LLM (e.g., DeepSeek-V3) to generate file/function-level code documentation for repositories, which serves as auxiliary knowledge to guide fault localization. Subsequently, based on the fault localization results and the issue description, a powerful LLM (e.g., Claude-4) attempts to repair the identified suspicious code snippets. Evaluated on SWE-bench Lite, RepoRepair achieves a 45.7% repair rate at a low cost of 0.44perfix.OnSWE−benchMultimodal,itdeliversstate−of−the−artperformancewitha37.10.56 per fix, demonstrating robust and cost-effective performance across diverse problem domains.
Zhongqiang Pan, Chuanyi Li, Wenkang Zhong +3
State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China · Human Language Technology Research Institute, University of Texas at Dallas, Richardson, Texas, USA
Repository-grounded automated repair is often reported as a single end-to-end capability, which hides distinct failure modes such as poor file targeting, incorrect patch synthesis, and failed iterative debugging. We present Loc2Repair, a modular evaluation framework for controlled analysis of repository-grounded repair pipelines, and use it to isolate file-level issue localization as an upstream variable. Loc2Repair decouples localization and repair under a shared runtime, artifact schema, and evaluation harness, allowing researchers to combine different localization models and repair backbones under matched conditions. Using three repair backbones on SWE-bench Verified, we compare baseline repair without explicit localization, repair guided by predicted localization from two localizers, and repair guided by gold modified-file sets. Explicit localization consistently improves resolved rate across all backbones: pooled performance increases from 44.7% for baseline repair to 48.9% and 49.1% with predicted localization, and to 52.4% with gold localization. Localization also reduces mean elapsed time overall: in pooled paired analysis, mean elapsed time decreases by 100.94 s and 52.25 s for the two predicted-localization settings, and by 154.45 s with gold guidance, although token effects remain heterogeneous across models. Overall, Loc2Repair shows file-level localization is a consistent repair lever, improving effectiveness and mean latency in pooled analysis, while gold-guided failures expose headroom beyond localization.
Automated program repair at repository scale requires an agent to locate a fault among thousands of files and synthesize a correct patch. Existing graph-based agents represent how a repository is organized into files, classes, and functions, but they do not model how variable values flow within a procedure, which leaves the agent without the semantic precision that function-level and line-level localization demand. We present ARISE (Agentic Repository-level Issue Solving Engine), a framework-agnostic toolset that builds a multi-granularity program graph, extending structural relationships down to statement-level nodes connected by intra-procedural definition-use edges, and exposes it through a three-tier tool API that mounts on any tool-use agentic framework. The central primitive is data-flow slicing, a queryable agent tool that traces in a single call which statements define or consume a variable of interest. On SWE-bench Lite (300 real GitHub issues across 11 Python repositories) with the open-source Qwen2.5-Coder-32B-Instruct backbone, mounting ARISE on SWE-agent as the host resolves 22.0% of issues (66/300), a 4.7 percentage-point gain over the unmodified SWE-agent baseline under the identical backbone and host. We show this gain is largely attributable to sharper localization, with Function Recall@1 (R@1) rising from 0.43 to 0.60 (a 40% relative gain) and Line R@1 from 0.26 to 0.41 (a 58% relative gain). Controlled ablations attribute the improvement to the data-flow graph rather than the tool schema, and we further mount the same toolset on a second host framework to study its portability. Decoupled from any single scaffold, the graph builder and slicing API form a drop-in toolset for future repair research.
Shahd Seddik, Fahd Seddik, Amirrezza Esmaeili +2
FARD Lab, University of British Columbia, Kelowna, Canada