Paper deep dive
AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair
Z. C. Luo, J. C. Guo, W. J. He, S. Y. Wang, J. C. Yu, F. M. Zhao, Y. Chen, T. Cao, L. Q. Liu, N. Zheng, W. Xu, J. Jiang, Z. M. Zhao
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 9/19/2026, 1:27:31 AM
Summary
The paper introduces AdaRepair-Mem, an adaptive experience retrieval framework for repository-level automated program repair (APR) using Large Language Models. It addresses three limitations in existing memory-augmented systems: imbalanced memory distribution across repositories, the non-monotonic relationship between memory volume and repair success, and phase-misaligned memory accumulation. The framework employs three mechanisms: Coverage-Aware Retrieval (CAR) to expand search scope when local memory is scarce, Quality-Aware Selection (QAS) to rank memories by relevance, utility, specificity, and redundancy, and Stage-Aware Routing (SAR) to deliver stage-specific memories (reproduction, localization, patch generation, refinement, validation). Evaluated on SWE-Bench-Lite and SWE-Bench-Verified, AdaRepair-Mem improves repair performance, particularly for under-covered repositories, and reduces noisy retrieval.
Entities (9)
Relation Signals (9)
AdaRepair-Mem → evaluatedon → SWE-bench Lite
confidence 99% · Evaluated on SWE-Bench-Lite and SWE-Bench-Verified
AdaRepair-Mem → evaluatedon → SWE-bench Verified
confidence 99% · Evaluated on SWE-Bench-Lite and SWE-Bench-Verified
AdaRepair-Mem → containsmodule → Stage-Aware Routing
confidence 95% · Our framework introduces... stage-aware routing
AdaRepair-Mem → containsmodule → Coverage-Aware Retrieval
confidence 95% · Our framework introduces coverage-aware retrieval... quality-aware selection... and stage-aware routing
AdaRepair-Mem → containsmodule → Quality-Aware Selection
confidence 95% · Our framework introduces... quality-aware selection... and stage-aware routing
Coverage-Aware Retrieval → addressesproblem → Imbalanced Memory Distribution
confidence 90% · coverage-aware retrieval, which falls back to cross-repository or repair-type-based memories when same-repository memory is insufficient
Quality-Aware Selection → addressesproblem → Memory Quality and Redundancy
confidence 90% · quality-aware selection, which ranks memories by relevance, historical utility, specificity, and redundancy
Stage-Aware Routing → addressesproblem → Phase-Misaligned Memory
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Recent memory-augmented repository-level program repair methods reuse historical repair experiences to improve LLM-based issue resolution. However, our analysis reveals three limitations in existing repository-level memory retrieval. First, episodic memory is highly imbalanced across repositories, leaving low-resource repositories with little effective support. Second, more memory does not monotonically lead to higher repair success, suggesting that relevance, quality, and redundancy matter more than raw memory volume. Third, memory accumulation is phase-misaligned: repositories may contain many reproduction experiences but few patch or refinement experiences. To address these problems, we propose an adaptive experience retrieval framework for repository-level program repair. Our framework introduces coverage-aware retrieval, which falls back to cross-repository or repair-type-based memories when same-repository memory is insufficient; quality-aware selection, which ranks memories by relevance, historical utility, specificity, and redundancy; and stage-aware routing, which separates and retrieves memories for reproduction, localization, patch generation, patch refinement, and validation. Evaluated on SWE-Bench-Lite and SWE-Bench-Verified, the proposed framework improves repair performance on under-covered repositories, reduces noisy memory retrieval, and better supports failed-to-fixed patch refinement. Our results show that the key to memory-augmented repair is not simply accumulating more experiences, but retrieving the right experiences for the right repair context.
Tags
Links
- Source: https://arxiv.org/abs/2609.20130v1
- Canonical: https://arxiv.org/abs/2609.20130v1
Trouble viewing inline? Open PDF directly →
Full Text
63,550 characters extracted from source content.
Expand or collapse full text
AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair Zichen Luo 1,† , Jiachen Guo 1,2,† , Wenjun He 1,2 , Siyu Wang 1 , Jiongchi Yu 1 , Fangming Zhao 1 , Yuan Chen 2 , Te Cao 2 , Liqun Liu 2 , Ning Zheng 2 , Wei Xu 2 , Jie Jiang 2 , Ziming Zhao 1,* 1 Zhejiang University 2 Tencent Abstract—Recent memory-augmented repository-level pro- gram repair methods reuse historical repair experiences to im- prove LLM-based issue resolution. However, our analysis reveals three limitations in existing repository-level memory retrieval. First, episodic memory is highly imbalanced across repositories, leaving low-resource repositories with little effective support. Sec- ond, more memory does not monotonically lead to higher repair success, suggesting that relevance, quality, and redundancy mat- ter more than raw memory volume. Third, memory accumulation is phase-misaligned: repositories may contain many reproduction experiences but few patch or refinement experiences. To address these problems, we propose an adaptive experience retrieval framework for repository-level program repair. Our framework introduces coverage-aware retrieval, which falls back to cross- repository or repair-type-based memories when same-repository memory is insufficient; quality-aware selection, which ranks mem- ories by relevance, historical utility, specificity, and redundancy; and stage-aware routing, which separates and retrieves memories for reproduction, localization, patch generation, patch refinement, and validation. Evaluated on SWE-Bench-Lite and SWE-Bench- Verified, the proposed framework improves repair performance on under-covered repositories, reduces noisy memory retrieval, and better supports failed-to-fixed patch refinement. Our results show that the key to memory-augmented repair is not simply ac- cumulating more experiences, but retrieving the right experiences for the right repair context. Index Terms—Automated Program Repair, Large Language Model, AI Agents, Memory I. Introduction Repository-level automated program repair (APR) treats issue resolution as an end-to-end software engineering task: given a natural-language issue report and a code repository, the goal is to localize faulty code, generate a patch, and validate the fix against existing tests. The emergence of large language models (LLMs) [1]–[6] and benchmarks such as SWE-Bench [7], [8] has driven rapid progress on this task, with recent agent- based and pipeline-based systems achieving increasingly strong results [9]–[13]. Despite these advances, most non-memory systems solve each issue independently, without retaining knowledge acquired from previous repair attempts. Human developers, however, routinely draw on prior debugging and repair experience when addressing new issues. Motivated by this observation, recent work has introduced memory mechanisms into LLM agents [14]–[22], and ExpeRepair [23] has extended this idea to repository-level † These authors contributed equally. * Corresponding author.Email: zhaoziming@zju.edu.cn APR by storing repair demonstrations and distilled insights from prior trajectories. Its results show that historical repair experience can provide valuable guidance for issue reproduction and patch generation, establishing memory-augmented APR as a promising direction. Fig. 1. Illustration comparing the traditional unified memory mechanism and our AdaRepair-Mem adaptive experience retrieval pipeline, which enables full utilization of high-value stage-matched repair memories. While prior work has established the value of repair mem- ories, how such memories should be organized and retrieved remains poorly understood [24]. Existing approaches typically maintain memories within repository boundaries, retrieve them based primarily on lexical or semantic similarity [25]–[27], and use a shared memory pool throughout the repair process. These design choices are largely heuristic, and their implica- tions have not been systematically studied. Our analysis of repair memories in existing memory-augmented systems reveals several recurring limitations. Repair memories are unevenly distributed across repositories. Some repositories accumulate a large number of repair experiences, while others contain only a few. Because retrieval is typically restricted to the current repository, repositories with limited historical data receive little benefit from memory augmentation. The effectiveness of memory-assisted repair therefore depends heavily on repository- specific memory availability [28]–[31]. Beyond coverage, a larger memory pool does not necessarily lead to better repair performance [21], [24], [31], [32]. Our anal- arXiv:2609.20130v1 [cs.SE] 17 Sep 2026 DjangoSymPy Matplotlib Astropy 0 50 100 150 200 250 Memory Count 205 66 31 19 (a) Repository Memory Distribution Reproduce Memory Patch Memory Cap-5Cap-15Full Same-repo Episodic Memory Cap 30 40 50 60 70 Overall Resolve Rate (%) 41.7% (10/24) 45.8% (11/24) 66.7% (16/24) +25.0 p (b) Coverage → Performance Django (Mem=205) SymPy (Mem=66) Matplotlib (Mem=31) 0 2 4 6 8 10 Resolved Tasks (out of 8) 3 5 1 6 5 2 7 5 3 Δ=+4 Δ=+2 (c) Per-Repository Sensitivity Cap-5Cap-15Full Fig. 2. Motivational study of repository-level memory retrieval. (a) Imbalanced memory stock across different projects; (b) Repair performance grows with the upper bound of available same-repository memory; (c) Low-memory repositories are more sensitive to memory capacity restrictions, motivating our coverage-aware retrieval module. ysis shows that retrieval quality depends not only on similarity, but also on factors such as utility, specificity, and redundancy. Highly similar memories can still be unhelpful or misleading, while redundant memories consume context without providing additional guidance. Selecting useful memories is therefore at least as important as accumulating more of them. Repair memories are also unevenly distributed across repair stages. In many repositories, reproduction-related experiences are abundant, whereas experiences for patch generation or patch refinement are scarce. Moreover, different stages require differ- ent forms of knowledge. For example, issue reproduction often relies on environment configuration and testing procedures, whereas patch refinement benefits from examples that capture how incorrect patches were revised into successful fixes. Using a single memory pool throughout the repair process therefore fails to account for the differing requirements of individual repair stages [12], [33]–[36]. These observations suggest that repository identity alone is insufficient for effective memory retrieval. Successful memory- augmented repair requires selecting experiences that are appro- priate for the repository, the repair task, and the current stage of the repair process [21], [24], [31], [34], [37]. Based on this insight, we propose AdaRepair-Mem, an adaptive experience retrieval framework for repository-level program repair. AdaRepair-Mem addresses the limitations identified above through three complementary mechanisms. When repository- specific memories are insufficient, coverage-aware retrieval expands the search space to include related experiences from other repositories [28], [29]. Quality-aware selection ranks candidate memories using multiple signals beyond similarity, including historical utility, specificity, and redundancy [31], [32]. Stage-aware routing organizes memories according to dif- ferent repair stages and retrieves stage-relevant experiences for reproduction, localization, patch generation, patch refinement, and validation [12], [34]. The framework is modular and can be integrated into existing memory-augmented repair systems without requiring changes to their underlying repair pipelines. We evaluate AdaRepair-Mem on SWE-Bench-Lite and SWE- Bench-Verified [7], [8], [38]. The results show that AdaRepair- Mem consistently improves repair performance on repositories with limited memory coverage, reduces ineffective memory retrieval, and achieves better token efficiency than the base system. Overall, we makes the following contributions: • We analyze repair memories in repository-level APR and identify three limitations of existing memory retrieval strategies. • We propose AdaRepair-Mem, a novel adaptive experience retrieval framework for memory-augmented program re- pair. Different from existing works that focus on expanding memory sources, our work innovates from the perspective of precise memory utilization: it unifies coverage-aware retrieval, quality-aware selection and stage-aware routing into one coherent pipeline, delivering high-value, stage- matched repair experiences. • We evaluate AdaRepair-Mem on SWE-Bench-Lite and SWE-Bench-Verified and show that it improves repair effectiveness, particularly for repositories with limited his- torical experiences, while achieving better token efficiency than the base system. I. Background and Motivation A. Repository-Level Program Repair Repository-level automated program repair (APR) resolves natural-language issues in the context of an entire software repository, requiring file localization, project-specific reasoning, patch generation, and validation [7], [9]. Recent LLM-based systems address this task through agentic interaction or staged repair pipelines [12], [39], [40], but most solve each issue independently and discard prior repair experience. Since human developers routinely reuse debugging knowledge from similar issues, memory-augmented repair stores historical trajectories and retrieves them as contextual guidance for future repairs [23], [33]. B. Repair Memories In this work, a repair memory denotes a structured record extracted from a previous repair attempt [23], [33]. A memory Fig. 3. System overview of the proposed AdaRepair-Mem framework. Given a new bug issue from the target repository, the coverage-aware retrieval (CAR) module dynamically expands the candidate memory pool with cross-repository and same-type repair experiences when local memories are scarce. The quality-aware selection (QAS) module scores and filters high-value memories by jointly measuring relevance, repair utility, specificity and redundancy. Finally, the stage-aware routing (SAR) module distributes screened memories to the corresponding stage partition matching the current repair phase, and the selected stage-specific memories are injected into the original prompt to assist the repair agent. After patch execution and validation, new repair trajectories are updated back to the memory pool for future retrieval. may include the issue description, retrieved code context, generated reproduction scripts, candidate patches, validation feedback, and the final successful repair artifact. These records are useful because they capture both project-specific knowledge and task-level repair patterns. For example, a reproduction memory may describe how to construct a minimal failing test under a specific project configuration, while a refinement memory may record how an initially incorrect patch was revised after receiving test feedback. Existing memory-augmented repair systems typically organize these records by repository and retrieve memories using lexical or semantic similarity between the current issue and past repair cases [23], [25], [33]. This design is intuitive because same-repository memories often encode local APIs, naming conventions, and architectural assumptions. However, repository identity and surface-level similarity alone are insufficient to determine whether a memory is useful for the current repair context. A retrieved memory can be similar but unsuccessful, correct but too generic, or relevant to a different repair stage. As a result, memory retrieval should be viewed not merely as nearest-neighbor search, but as a policy for selecting which prior experiences should be exposed to the repair agent, from where they should be retrieved, and at which stage they should be used. Such a policy can prioritize memories that are not only similar to the present issue, but also demonstrably effective and actionable under comparable debugging conditions. C. Motivating Observations Our motivational study reveals three limitations in existing repository-level memory retrieval strategies. Observation 1: Repository-level memory coverage is imbalanced. As shown in Fig. 2, repair memories are un- evenly distributed across repositories. Some projects accumulate abundant historical repair experiences, whereas others contain only a small number of usable memories. A retrieval strategy restricted to the current repository therefore gives strong memory support to high-resource repositories but provides limited assistance to low-resource ones. This imbalance makes the effectiveness of memory-augmented repair depend heavily on repository-specific memory availability rather than on the intrinsic usefulness of historical repair knowledge. Observation 2: More memories do not necessarily im- ply better repair. Increasing the memory pool can improve coverage, but it can also introduce noisy or redundant context. Similar memories may correspond to failed repair attempts, and multiple retrieved records may describe nearly identical repair steps. Since LLM repair agents operate under a limited context budget, injecting low-utility memories can distract the agent, waste tokens, and reduce the chance of generating a correct patch [31], [32]. This suggests that retrieval quality is at least as important as memory quantity. A useful memory selection policy should consider not only relevance, but also historical repair utility, specificity of repair artifacts, and redundancy among retrieved records. Observation 3: Repair memories are stage-dependent. Repository-level repair is a multi-stage process [12], [34]. Issue reproduction, fault localization, patch generation, patch refinement, and validation require different forms of histor- ical knowledge. Reproduction often benefits from prior test construction and environment setup, localization benefits from examples of where similar symptoms were previously mapped in the codebase, and refinement benefits from failed-to-fixed patch trajectories. A unified memory pool ignores these stage- specific requirements and may deliver memories to stages where they provide limited actionable guidance. Therefore, effective memory retrieval should be aligned with the current repair stage. I. Method Fig. 3 illustrates the overall framework of AdaRepair-Mem, a novel adaptive memory construction and retrieval method for repository-level automatic program repair. Instead of adopting a simple unified memory pool and single similarity-based retrieval strategy, AdaRepair-Mem systematically redesigns the full pipeline of historical repair experience management. This design is motivated by three key observations from Section I: uneven distribution of repair memories across repositories, significant variance in memory quality, and stage-specific demands for repair experience. Repository-level repair proceeds through five stages: issue reproduction, fault localization, patch generation, patch refinement, and validation. Before prompt construction for the repair agent at each stage, AdaRepair-Mem executes an adaptive retrieval module in three consecutive steps. The three modules jointly ensure coverage adequacy of the candidate pool, memory quality of selected entries, and stage appropriateness of the final delivered context. The selected memories are injected into the current stage prompt without altering the core repair workflow. As a general retrieval enhancement framework, AdaRepair-Mem can be integrated into existing memory-augmented repair systems with minimal engineering overhead. We elaborate on the three components in the following subsections. A. Coverage-Aware Retrieval (CAR) Existing memory-augmented repair systems retrieve repair experiences only from the current repository. Such a design implicitly assumes that every repository has accumulated sufficient historical repair experiences. However, as shown in Section I, repair memories are highly imbalanced across repositories. While some repositories contain abundant repair histories, others contain only a few usable memories. Restricting retrieval to the current repository therefore limits the available repair context for repositories with sparse historical experience. Coverage-aware Retrieval (CAR) addresses this problem by adaptively expanding the retrieval scope according to memory availability. The design follows a simple principle: repository- specific repair experiences should always be preferred because they capture project-specific implementation patterns and de- velopment conventions. Broader repair knowledge is introduced only when repository-specific memories are insufficient to provide adequate retrieval coverage. Given an issue 푞 from repository 푟 , let 푀 푟 denote the repair memories belonging to repository 푟 , 푀 푐 denote repair memories retrieved from other repositories, and 푀 푡 denote repair-type-based memories that share similar repair patterns. In Algorithm 1, we additionally use 푠 to denote the current repair stage, 푡 to denote the repair type of 푞, M to denote the constructed memory bank, 퐵 to denote the maximum number of cross-repository candidates, and 퐴 푠 to denote the stage-specific admission rule. CAR progressively constructs a candidate memory pool by expanding the retrieval scope until a sufficient number of candidate memories is obtained. Unlike subsequent retrieval stages, CAR does not determine which memories will ultimately be used. Its objective is to construct a candidate pool with adequate coverage for later quality-aware selection. Formally, let 푘 denote the minimum number of candidate memories required for subsequent retrieval. The candidate poolC is constructed as C= 푀 푟 ,|푀 푟 | ≥ 푘, 푀 푟 ∪ 푀 푐 , |푀 푟 | < 푘∧|푀 푟 ∪ 푀 푐 | ≥ 푘, 푀 푟 ∪ 푀 푐 ∪ 푀 푡 ,otherwise. (1) This progressive expansion strategy preserves repository- specific repair knowledge whenever possible while avoiding the coverage limitations caused by repositories with sparse repair histories. The resulting candidate pool is subsequently passed to the Quality-aware Selection module for ranking and filtering. Algorithm 1 summarizes the overall retrieval procedure. Repository-specific memories are first collected. If the candidate pool does not satisfy the retrieval threshold, CAR expands the search to cross-repository memories and then to repair-type- based memories. The resulting candidate pool is forwarded to the next retrieval stage. B. Quality-Aware Selection (QAS) Coverage-aware Retrieval enlarges the candidate memory pool to improve memory coverage. However, as shown in our empirical study, increasing the number of retrieved memories alone does not necessarily improve repair performance. Can- didate memories often differ substantially in their usefulness. Highly relevant memories may correspond to unsuccessful repair attempts, while multiple retrieved memories may contain nearly identical information or provide only generic repair guidance. Selecting memories solely according to lexical or semantic similarity therefore introduces noisy retrieval contexts and limits the effectiveness of memory-augmented repair. To address this problem, we propose Quality-aware Se- lection (QAS), which systematically evaluates the quality of candidate repair memories using multiple complementary signals rather than similarity alone. Given the candidate memory pool constructed by CAR, QAS estimates the usefulness of each candidate memory from four perspectives: relevance, repair utility, specificity, and redundancy. These signals are lightweight Algorithm 1 Coverage-Aware Retrieval (CAR) Require: issue 푞, repository 푟 , repair stage 푠, repair type 푡 Require: memory bank M, coverage threshold 푘 , global cap 퐵, admission rule 퐴 푠 Ensure: candidate memory poolC 1: 푀 푟 ← LoadSameRepoMemory(M,푟, 푠) 2: 푀 푟 ← FilterAdmitted(푀 푟 , 퐴 푠 ) 3: C ← 푀 푟 4: if |C| < 푘 then 5: 푀 푐 ← LoadCrossRepoMemory(M,푟, 푠, 퐵) 6: 푀 푐 ← FilterAdmitted(푀 푐 , 퐴 푠 ) 7: C ←C∪ 푀 푐 8: end if 9: if |C| < 푘 then 10: 푀 푡 ← LoadRepairTypeMemory(M,푡, 푠, 퐵) 11: 푀 푡 ← FilterAdmitted(푀 푡 , 퐴 푠 ) 12: C ←C∪ 푀 푡 13: end if 14: C ← RemoveDuplicateMemory(C) 15: returnC to compute and are directly derived from information already maintained during the repair process. Relevance measures how well a repair memory matches the current repair context. Since different repair stages require dif- ferent information, QAS adopts stage-specific retrieval queries following the original retrieval strategy of ExpeRepair. For ex- ample, patch generation emphasizes the similarity between issue descriptions and historical patches, whereas issue reproduction places greater emphasis on issue descriptions and historical test cases. Relevance is computed using BM25 [25] over the corresponding retrieval fields for each repair stage. Repair utility reflects whether a repair memory corresponds to a successful repair outcome. Rather than treating all memories equally, QAS gives higher priority to memories that successfully reproduce issues, generate valid patches, or pass subsequent verification. These signals are directly obtained from the repair outcomes stored in each memory entry. Specificity estimates the amount of concrete repair infor- mation contained in a memory. Memories with detailed issue descriptions, test cases, or code patches generally provide richer repair context than short or generic records. QAS therefore favors memories containing more informative repair artifacts. Redundancy measures the overlap between candidate mem- ories. QAS first removes exact duplicate memories and further filters highly similar candidates using token-level Jaccard similarity, encouraging the retrieved memories to provide complementary rather than repetitive repair information. The overall quality score of a candidate memory 푚 is computed as 푄(푚)= 푅(푚)+푈(푚)+ 푆(푚)− 퐷(푚),(2) where 푅(푚), 푈(푚), 푆(푚), and 퐷(푚) denote the relevance, repair utility, specificity, and redundancy scores, respectively. Candidate memories are ranked according to their quality scores, and the highest-ranked memories are retained for subsequent stage-aware routing. C. Stage-Aware Routing (SAR) Coverage-aware Retrieval determines where candidate mem- ories are retrieved from, while Quality-aware Selection de- termines which memories should be retained. The remaining question is when these memories should be used during repository-level program repair. Existing memory-augmented repair systems retrieve all memories from a unified memory store, regardless of the repair stage in which they are consumed. However, our empirical study shows that repair memories are unevenly distributed across different repair stages, and memories that are useful for one stage are often less informative for another. To address this problem, we propose Stage-aware Routing (SAR), which organizes repair memories according to the five repair stages of ExpeRepair and dynamically routes stage- specific memories to the corresponding repair stage. Rather than treating repair memory as a single shared resource, SAR maintains separate memory partitions for issue reproduction, fault localization, patch generation, patch refinement, and patch validation. As the repair process proceeds, each stage retrieves memories only from its corresponding memory partition. Formally, let M= 푀 rep , 푀 loc , 푀 gen , 푀 ref , 푀 val denote the five stage-specific memory partitions. Given the current repair stage 푠, SAR routes the quality-ranked memories to the corresponding stage by 푀 ∗ = 푓(푠,M)= 푀 푠 ,(3) where 푀 푠 denotes the memory partition associated with stage 푠. The selected memories are then incorporated into the prompt of the current repair stage. This stage-specific organization enables different repair stages to focus on the repair experiences that are most relevant to their own objectives. For example, issue reproduction primarily benefits from historical test construction and environment configuration, whereas patch generation relies more on successful code modifications, and patch refinement benefits from failed-to-fixed repair trajectories. By routing different memories to different repair stages, SAR reduces interference between heterogeneous repair experiences and provides stage-appropriate repair context throughout the repair pipeline. Together, CAR, QAS, and SAR form a unified adaptive experience retrieval framework. CAR expands the retrieval scope when repository-specific memories are insufficient, QAS selects high-quality memories from the candidate pool, and SAR delivers the selected memories to the repair stage where they are most useful. The framework integrates with ExpeRepair’s repair pipeline, which includes test execution [41] and validation [42] components to verify generated patches. IV. Experiments A. Setup 1) Benchmarks: We evaluate AdaRepair-Mem on two widely used repository-level program repair benchmarks, SWE-Bench- TABLE I Main comparison results on SWE-Bench Lite and SWE-Bench Verified benchmarks. Baseline results are taken from the corresponding papers and the official SWE-Bench leaderboard. MethodLLM SWE-Bench LiteSWE-Bench Verified pass@1 (%) AVG Cost ($)pass@1 (%) AVG Cost ($) SWE-agentClaude 3.5 Sonnet23.01.6233.61.59 AiderGPT-4o + Claude 3 Opus 26.3--- AutoCodeRoverGPT-4o30.7--- SpecRoverClaude 3.5 Sonnet + GPT-4o31.00.6546.2- Agentless-1.5Claude 3.5 Sonnet40.71.1250.81.19 OpenHandsCodeAct v2.141.71.3353.00.78 PatchPilotClaude 3.5 Sonnet45.30.9753.60.99 DARSClaude 3.5 Sonnet + DeepSeek R147.012.24-- ExpeRepairClaude 3.5 Sonnet + o4-mini48.31.8957.21.74 AdaRepair-MemClaude 3.5 Sonnet + o4-mini51.01.6763.21.52 Lite and SWE-Bench-Verified [7]. SWE-Bench-Lite contains 300 real GitHub issues sampled from popular Python reposito- ries and has been widely used for evaluating LLM-based repair systems. SWE-Bench-Verified contains 500 human-validated issues from SWE-Bench. Compared with SWE-Bench-Lite, SWE-Bench-Verified provides a more reliable evaluation setting because each issue has been manually checked to ensure that the problem description is clear and that the associated test patch is suitable for judging correctness. Recent analysis [38] has shown that repository-level benchmarks like SWE-Bench present substantially greater challenges than earlier function- level repair benchmarks [43], requiring deeper code understand- ing and multi-file reasoning. 2) Baselines: We compare AdaRepair-Mem with represen- tative open-source repository-level program repair methods on SWE-Bench-Lite and SWE-Bench-Verified 1 . These baselines are grouped into three categories according to their repair paradigm. Agent-based methods. These methods rely on autonomous tool use and iterative interaction with the repository. SWE- agent [39] equips an LLM with a general agent-computer interface for repository inspection, file editing, and test ex- ecution. Aider [44] is an interactive coding assistant that builds repository-aware context and performs Git-integrated code edits, following the paradigm of AI-assisted programming tools. AutoCodeRover [40] combines LLM reasoning with code search to localize and repair bugs in large repositories. SpecRover [11] extends this line by extracting specification and intent information from the codebase to improve autonomous repair. OpenHands [10] is a general software engineering agent framework with sandboxed execution and solution ranking. DARS [13] improves agentic repair through inference-time search, branching, and long-horizon feedback. Pipeline-based methods. These methods decompose repository-level repair into staged procedures rather than a fully autonomous agent loop. Agentless [9] separates localization, patch generation, and validation in a procedural repair pipeline. PatchPilot [12] follows a five-stage workflow that includes reproduction, localization, patch generation, validation, and refinement. Memory-augmented repair. This category reuses 1 https://w.swebench.com/ Fig. 4. Comparison of previous memory-based repair and AdaRepair-Mem. AdaRepair-Mem adaptively retrieves memories by adaptive memory to provide more useful context for repair. historical repair experiences to support new issue resolution. ExpeRepair [23] is the closest baseline to our work because it augments repository-level repair with episodic and semantic memories. Compared with ExpeRepair, AdaRepair-Mem keeps the same repair setting but replaces its retrieval strategy with coverage-aware retrieval, quality-aware selection, and stage- aware routing. 3) Metrics: Following ExpeRepair and recent repository- level repair systems [7], [9], [23], we report the following metrics. • Pass@1: The percentage of issues resolved on the first attempt. • Average Cost: The average inference cost per issue, measured in USD. • Token Efficiency: The number of resolved tasks per 1,000 input tokens, where higher values indicate better use of the context budget. • Execution Success Rate (ESR): The percentage of gener- ated reproduction scripts that execute successfully without errors, such as missing dependencies or configuration issues. 4) Implementation Details: We follow ExpeRepair’s mem- ory construction mechanism and repair pipeline, replacing only its retrieval strategy. For coverage-aware retrieval (CAR), we TABLE I File localization results comparison between RepoRepair, Agentless Lite, and AdaRepair-Mem on SWE-Bench Lite. AL = Agentless Lite; R = RepoRepair; Ada-Mem = AdaRepair-Mem. RepositoryInstances File Retrieval (%)File Localization (%) ALRRAda-MemALRRAda-Mem astropy/astropy610010010083.33100100 django/django11495.6196.4996.4985.0987.7292.98 matplotlib/matplotlib2391.3095.6595.6543.4869.5795.65 mwaskom/seaborn410010010050.0075.00100 pallets/flask3100100100100100100 psf/requests610010083.3383.3310083.33 pydata/xarray510010010080.00100100 pylint-dev/pylint610066.6783.3310050.0083.33 pytest-dev/pytest1710088.2494.1294.125.88100 scikit-learn/scikit-learn2310095.6595.6565.2273.9195.65 sphinx-doc/sphinx1610010010075.0075.00100 sympy/sympy7794.8189.6188.3163.6484.4287.01 Total30096.3394.0094.0074.6779.0092.67 TABLE I Repair performance across repositories with different memory coverage levels. Cover: memory coverage level; Memo: the number of repair memories per repository. CoverRepoMemoBaseMemoAdaRepair-Mem High django82 63.1%65.8%↑2.7 sympy31 Medium flask18 41.2%52.3%↑11.1 sphinx15 Low astropy3 55.3%58.3%↑3.0 matplotlib1 set the initial same-repository retrieval target to 푘 same = 10 and expand to cross-repository and repair-type pools when fewer than 푘 same candidates are available, with cross-repository pool size capped at 푘 cross = 50 to balance coverage and noise. For quality-aware selection (QAS), we rank candidate memories by a weighted combination of relevance (BM25 score), repair utility (success indicator), specificity (trajectory length), and redundancy (pairwise similarity), and select the top-3 highest- ranked memories for each repair stage. The quality weights prioritize relevance and utility (0.8 total) over specificity and redundancy (0.2 total), reflecting the observation that task align- ment is more predictive than structural diversity. For stage-aware routing (SAR), memories are partitioned into five stage-specific pools based on the stage labels recorded during ExpeRepair’s memory construction. These design choices prioritize retrieval precision over coverage and were validated on a small held- out set of 24 issues (6 from each coverage group) before being applied to the main evaluation. B. Results 1) Overall Performance: Table I reports the main compar- ison on SWE-Bench-Lite and SWE-Bench-Verified. Compared with ExpeRepair under the same Claude 3.5 Sonnet + o4- mini setting, AdaRepair-Mem improves pass@1 from 57.2% to 63.2%, a gain of 6.0 percentage points, while the average cost decreases from $1.74 to $1.52. The bottleneck of memory- augmented repair is not only whether historical experiences are available, but whether the system can select suitable experiences under repository coverage, memory quality, and repair-stage constraints. In other words, adaptive retrieval makes repair knowledge more effective by reducing irrelevant or poorly matched memories before they enter the repair context. If the gain came mainly from more exploration or larger prompts, we would expect higher inference cost. Instead, AdaRepair- Mem obtains higher pass@1 with lower average cost, indicating that the retrieved memories help the repair agent reach useful repair actions with less wasted context and fewer ineffective repair steps. Compared with agent-based and pipeline-based baselines, this shows that improving the memory policy can provide a complementary source of progress without changing the underlying repair workflow. 2) Ablation Study: For the ablation study, we use a fixed 24- instance diagnostic subset from SWE-Bench-Verified, covering BaseMemo-resolved, AdaRepair-Mem-resolved, BaseMemo- unresolved, and AdaRepair-Mem unresolved cases with six instances each. All variants are evaluated on the same subset, enabling a paired comparison of CAR, QAS, and SAR under both successful and failed repair trajectories. Table IV shows that all three modules are effective and complementary. On the 24-instance diagnostic subset, removing QAS causes the largest drop in pass@1, indicating that selecting high-quality memories is more important than retrieving more memories. Removing SAR reduces both pass@1 and ESR and increases the average cost, showing that stage-aware routing helps the system reuse memories at the right repair phase. Overall, the full AdaRepair-Mem achieves the best accuracy and the lowest cost, confirming that the gains come from the joint effect of CAR, QAS, and SAR rather than from any single component. 3) Repository Coverage Analysis: For this analysis, we use a fixed 150-instance stratified subset from SWE-Bench- Verified. The subset is constructed only for coverage-oriented analysis, while the main comparison is still conducted on the full benchmark. We group repositories by the number of available repair memories before evaluation and select six repositories from three coverage levels: django and sympy for Fig. 5. Token Efficiency Across Repositories: resolved tasks per 1,000 API input tokens; higher is better. high coverage, flask and sphinx for medium coverage, and astropy and matplotlib for low coverage. All compared methods are evaluated on the same sampled instances, and the grouping is based on memory availability rather than repair outcomes. This subset is used only for coverage-oriented and token-efficiency analyses. Table I shows that the benefit of AdaRepair-Mem is most visible when repository-local memory is incomplete. On the high-coverage repositories, AdaRepair-Mem improves pass@1 from 63.1% to 65.8%, suggesting that coverage-aware retrieval does not hurt repositories that already have sufficient local experience. The largest gain appears on the medium- coverage repositories, where pass@1 increases from 41.2% to 52.3%. This indicates that adaptive retrieval is especially useful when repository-local memories exist but do not fully cover the current repair pattern. Even on the low-coverage repositories, where the local memory pool is extremely small, AdaRepair- Mem still raises pass@1 from 55.3% to 58.3%. Taken together, these results show that repair performance is not determined by memory quantity alone, but by whether the retrieved experiences match the current repository and repair need. 4) Token Efficiency: Fig. 5 further shows that AdaRepair- Mem uses the context budget more effectively across all six repositories. Compared with the base system, AdaRepair- Mem achieves higher token efficiency on every repository, with particularly clear gains on astropy, sympy, and flask. For example, token efficiency improves from 0.95 to 2.12 on astropy, from 2.23 to 3.04 on sympy, and from 2.30 to 3.14 on flask. These gains indicate that the improvement does not come from simply injecting more memory into the prompt. Instead, CAR and QAS help filter and expand memory more selectively, so that each 1,000 input tokens carries more repair-relevant information. This is consistent with our claim that adaptive retrieval improves the utility of the context budget rather than increasing its size. 5) Generalization across LLMs: For the model general- ization study, we use a fixed 24-instance subset from SWE- Bench-Verified, with eight cases sampled from each memory coverage level. This balanced design avoids over-representing a single coverage group and allows us to compare different backbone models under the same set of issues. The results Intersection analysis of resolved instances 0 25 50 75 Intersection Size SWE-agent 168 AutoCodeRover 192 OpenHands 265 Agentless-1.5 254 PatchPilot-Co 230 PatchPilot-o4 323 AdaRepair-Mem 316 Fig. 6. Intersection analysis of resolved instances across seven repository-level repair systems. Purple bars indicate intersections that include AdaRepair-Mem. on different backbone models show that AdaRepair-Mem is not tied to a specific LLM. Across Kimi 2.5 [45], Claude 4 Sonnet [46], Claude 3.5 Sonnet [47], and DeepSeek R1 [48], the bar chart consistently favors AdaRepair-Mem over the BaseMemo. This suggests that the proposed retrieval strategy is model-agnostic and can benefit both stronger and weaker reasoning models. The gain comes from better memory selection rather than from a particular prompt style or backbone capability. The generalization result supports our design goal of making adaptive experience retrieval a reusable plug-in for different repository-level repair systems. 6) Cumulative resolution rates: Fig. 7 reports the cumu- lative resolution rates of AdaRepair-Mem across 12 Python repositories in SWE-Bench-Verified. The repositories cover large, medium-size, and long-tail projects with diverse code structures and memory coverage levels. The curves show clear differences in repository-level repair difficulty, but AdaRepair- Mem maintains stable behavior across these settings. On the largest repository, django, the cumulative rate stabilizes after about 50 processed issues and stays within a narrow range without sustained degradation. SymPy maintains a resolution rate above 60% for most of the process, and scikit-learn also remains at a relatively high level despite having fewer instances. For more challenging or lower-coverage repositories such as astropy and matplotlib, the curves fluctuate more because of smaller sample sizes, but they still converge to non-trivial repair rates rather than collapsing. Together with Table I, this result supports RQ1 by showing that AdaRepair-Mem can mitigate repository-level memory imbalance and provide robust repair behavior across repositories of different sizes and difficulties. 7) File Localization Analysis: To further understand where the improvement of AdaRepair-Mem originates, we isolate its file-level localization performance, a critical prerequisite for successful patch generation. We compare AdaRepair-Mem with two systems that adopt different context strategies for this stage: Agentless Lite [9], a lightweight variant of Agentless that relies on embedding-based retrieval and syntactic filtering; and RepoRepair [49], which leverages hierarchically generated code documentation to guide fault localization. Table I reports per-repository results on SWE-Bench Lite. TABLE IV Ablation study on memory modules of AdaRepair-Mem. Method SWE-Bench LiteSWE-Bench Verified pass@1 (%) ESR (%) AVG Cost($)pass@1 (%) ESR (%) AVG Cost($) AdaRepair-Mem75.075.02.5570.875.02.18 w/o CAR75.062.52.4350.062.52.13 w/o QAS58.350.02.7045.875.02.54 w/o SAR66.745.82.7062.566.72.39 baseline45.845.82.9145.850.02.78 0 20 40 60 80 100 0255075100125150175200225 Number of Issues Processed Cumulative Resolution Rate (%) Django (231 issues) SymPy (75 issues) Sphinx (44 issues) Matplotlib (34 issues) scikit-learn (32 issues) Astropy (22 issues) Xarray (22 issues) pytest (19 issues) pylint (10 issues) Requests (8 issues) Seaborn (2 issues) Flask (1 issues) Fig. 7. Cumulative resolution rates of AdaRepair-Mem across repositories on SWE-Bench-Verified. For file retrieval, all three systems perform comparably (94%– 96%), indicating that initial candidate identification does not meaningfully differentiate them. For file localization, however, AdaRepair-Mem achieves 92.67% accuracy, substantially out- performing RepoRepair (79.00%) and Agentless Lite (74.67%). The improvement is most pronounced on repositories where historical repair experiences provide rich structural cues: AdaRepair-Mem correctly localizes all 17 pytest issues (com- pared to 1 for RepoRepair) and 22 of 23 matplotlib issues (compared to 10 for Agentless Lite). These results suggest that adaptively retrieved repair memo- ries deliver more actionable localization guidance than generic code documentation or embedding-based retrieval. This finding aligns with the design of Stage-aware Routing (SAR): by routing stage-specific repair experiences to the localization stage, AdaRepair-Mem supplies the agent with historical examples showing where similar issues were previously localized, com- plementing lexical and documentation-based similarity signals. 8) Intersection analysis.: Fig. 6 analyzes how the resolved instances of AdaRepair-Mem overlap with six representative baselines. The seven systems jointly resolve 393 unique in- stances, and 94 instances are solved by all methods. Beyond this common subset, many large intersections still include AdaRepair-Mem, indicating that AdaRepair-Mem remains com- petitive on broadly solvable issues while also contributing complementary repaired cases. The remaining 73 instances belong to smaller intersection groups that are omitted from the main bars for readability. This result suggests that adaptive memory retrieval improves repair coverage beyond simply reproducing the behavior of existing agentic repair systems. 9) Stage-Specific Memory Records: Figure 8 shows rep- resentative memories from the stage-specific memory banks in AdaRepair-Mem. Each memory stores the issue, retrieved context, generated artifact, failure feedback, and successful output, preserving both useful experience and repair signals. Among these fields, retrieved context and failure feedback are the most informative for future retrieval, while the stage-wise organization provides the basis for SAR and helps CAR and QAS select more relevant memories. V. Related Work A. Repository-Level Program Repair Large language models have advanced automated program repair (APR) from function-level patch generation to repository- level issue resolution [1], [2], [7]. Existing methods mainly follow two paradigms: agent-based approaches that enable LLMs to interact with repositories via tool use and iterative reasoning [39], [40], [50], and pipeline-based approaches that decompose repair into staged workflows of reproduction, localization and validation [9], [12]. Despite differing execution paradigms, these methods generally treat each issue as an independent task and do not retain or adaptively reuse historical repair experience across tasks. B. Memory-Augmented Program Repair To enable cross-task knowledge reuse, memory mechanisms have been gradually introduced into APR. Early learning- based and template-based methods [51]–[53] first demonstrated that repair knowledge can be extracted from historical fixes and reusable patterns. Recent retrieval-augmented works [54], [55] further show that external code and patch context can improve LLM-based repair quality. Representative repository- level memory systems, including HAFix [56], SWE-Exp [33], ExpeRepair [23] and ConRAD [57], have validated the value of historical repair experience. However, they all adopt component- specific retrieval designs, and no prior work formulates repair- memory retrieval as a unified adaptive policy that jointly considers coverage, quality and stage utility. Reproduce Memory memory_id: sphinx::M_rep, repair_stage: M_rep, issue: Decorated __init__ missing in docs, retrieved_context: Previous reproduction template, generated_test_or_patch: Minimal reproduction script, failure_feedback: Build path is incorrect, successful_output: Reusable reproduction harness Localize Memory memory_id: sphinx::M_loc, repair_stage: M_loc, issue: HTTP error masked by anchor check, retrieved_context: Candidate source files, generated_test_or_patch: Bug localized to check_thread(), failure_feedback: Initial search too broad, successful_output: Anchor-handling branch identified Generate Memory memory_id: requests::M_gen, repair_stage: M_gen, issue: GET sends Content-Length, retrieved_context: Similar protocol header fix, generated_test_or_patch: Skip Content-Length for safe methods, failure_feedback: Header emitted unnecessarily, successful_output: Emit only when body exists Patch-refinement Memory memory_id: pytest::M_ref, repair_stage: M_ref, issue: caplog.clear breaks synchronization, retrieved_context: Previous failed patch, generated_test_or_patch: Clear shared list in place, failure_feedback: Replacing list breaks alias, successful_output: Preserve shared record list Validation Memory memory_id: sphinx::M_val, repair_stage: M_val, issue: Whitespace in LaTeX inline code, retrieved_context: Previous validation case, generated_test_or_patch: Validate PDF inline rendering, failure_feedback: Regression detected in PDF output, successful_output: No regression in inline code rendering Fig. 8. Representative memory records from the stage-specific memory banks of AdaRepair-Mem. Retrieved context is highlighted in green and failure feedback in red. C. Core Research Gaps in Retrieval Strategy Repair-memory retrieval essentially answers three core ques- tions: which memories to retrieve, where to retrieve from, and when to use them. Existing studies only address these questions ---a/django/conf/global_settings.py filedjango/conf/global_settings.py +++b/django/conf/global_settings.py @@ 304,7+304,12 @@ FILE_UPLOAD_TEMP_DIR = None # The numeric mode to set newly uploaded files to. -FILE_UPLOAD_PERMISSIONS = None + FILE_UPLOAD_PERMISSIONS = 0o644 #The numeric mode to assign to newly - created # Directories, when uploading files. -FILE_UPLOAD_PERMISSIONS = None + FILE_UPLOAD_PERMISSIONS = 0o755 ---a/django/conf/global_settings.py +++b/django/conf/global_settings.py @@ 304,7+304,7 @@ FILE_UPLOAD_TEMP_DIR = None + FILE_UPLOAD_PERMISSIONS = 0o644 -FILE_UPLOAD_PERMISSIONS = None 1. Target setting: FILE_UPLOAD_PERMISSIONS Official test expects file_permissions_mode = 0o644. 2. Candidate analysis: a minimal one-line default change is sufficient. 3. Refinement: keep the fix limited to FILE_UPLOAD_PERMISSIONS = 0o644 avoid FILE_UPLOAD_DIRECTORY_PERMISSIONS Patch Agent with adaptive mem Patch Agent withoutadaptive mem 1. Target setting: The issue points to is_upper(), but localization also exposes _eval_is_upper_hessenberg with the same triangular-index pattern . 2. Candidate analysis: test_is_upper and test_hessenberg both pass. 3. Refinement: range(min( i , self.cols )) range(min( i - 1, self.cols )) Patch Agent with adaptive mem Patch Agent withoutadaptive mem file a/sympy/matrices/matrices.py @@ 641,7 +641,7 @@ def _eval_is_upper_hessenberg (self): return all(self[ i , j]. is_zero for i in range(2, self.rows ) - for j in range( i - 1)) + for j in range(min( i - 1, self.cols ))) @@ 1112,7 +1112,7 @@ def is_upper (self): return all(self[ i , j]. is_zero for i in range(1, self.rows ) - for j in range( i )) + for j in range(min( i , self.cols ))) @@ 1112,7 +1112,7 @@ def is_upper (self): return all(self[ i , j]. is_zero for i in range(1, self.rows ) --- for j in range( i )) +++ for j in range(min( i , self.cols ))) Fig. 9. Two real cases from the SymPy and Django repositories resolved by AdaRepair-Mem. separately, without forming an integrated adaptive framework. First, regarding memory selection, while semantic similarity- based code retrieval [58] and in-context example selection [59], [60] have been widely studied, no system jointly evaluates candidates from relevance, utility, specificity and redundancy. Second, regarding retrieval scope, current systems mostly rely on repository-local histories; cross-project knowledge transfer verified in fault localization [29], [30] has not been used to dynamically adjust retrieval scope for memory-sparse reposito- ries. Third, regarding stage matching, staged repair workflows imply phase-specific knowledge demands [12], [57], but existing stage-specific memory designs [34] are treated as independent storage schemes rather than an integrated part of the full retrieval pipeline. In summary, there lacks a unified framework that combines coverage-aware expansion, quality-aware selection and stage-aware routing into one coherent adaptive retrieval policy, which this work addresses with AdaRepair-Mem. VI. Conclusion This paper studies memory augmented repository level program repair and identifies a central issue in existing systems. Historical repair experiences are useful, but they are often unevenly distributed across repositories, vary in quality, and do not match different repair stages well. To address this, we propose AdaRepair-Mem, denoted as AdaRepair-Mem, which integrates Coverage-aware Retrieval, Quality-aware Selection, and Stage-aware Routing to retrieve more suitable repair expe- riences for reproduction, localization, patch generation, patch refinement, and validation. Experiments on SWE-Bench-Lite and SWE-Bench-Verified show that AdaRepair-Mem improves repair performance, especially for repositories with limited historical experiences, and achieves better token efficiency than the base system. VII. Data Availability An anonymous replication package is available for review. 2 It contains the implementation, controlled benchmark, seeded and held-out fault results, benign-transformation results, ablation data, diagnostic and witness data, runtime data, plotting scripts, and reproduction instructions. The package also includes the paper-facing CSV files used to generate the figures, so the reported counts, ablations, diagnostics, external-witness sum- maries, and runtime measurements can be checked without rerunning the experiments. References [1] A. Fan, B. Gokkaya, M. Harman, M. Lyubarskiy, S. Sengupta, S. Yoo, and J. M. Zhang, “Large language models for software engineering: Survey and open problems,” in 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE). IEEE, 2023, p. 31–53. [2] Z. Zheng, K. Ning, Y. Wang, J. Zhang, D. Zheng, M. Ye, and J. Chen, “A survey of large language models for code: Evolution, benchmarking, and future trends,” arXiv preprint arXiv:2311.10372, 2023, unpublished. [3] D. Zan, B. Chen, F. Zhang, D. Lu, B. Wu, B. Guan, W. Yongji, and J.-G. Lou, “Large language models meet nl2code: A survey,” in Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2023, p. 7443–7464. [4] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. D. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021, unpublished. [5] Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago et al., “Competition-level code generation with AlphaCode,” Science, vol. 378, no. 6624, p. 1092– 1097, 2022. [6] J. Austin, A. Odena, M. Nye, M. Bosma, H. Michalewski, D. Dohan, E. Jiang, C. Cai, M. Terry, Q. Le et al., “Program synthesis with large language models,” arXiv preprint arXiv:2108.07732, 2021, unpublished. [7] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “SWE-bench: Can language models resolve real-world GitHub issues?” in International Conference on Learning Representa- tions, vol. 2024, 2024, p. 54 107–54 157. [8] M. Martinez and X. Franch, “Dissecting the SWE-bench leaderboards: Profiling submitters and architectures of LLM- and agent-based repair systems,” arXiv preprint arXiv:2506.17208, 2025, unpublished. [9] C. S. Xia, Y. Deng, S. Dunn, and L. Zhang, “Agentless: De- mystifying LLM-based software engineering agents,” arXiv preprint arXiv:2407.01489, 2024, unpublished. [10] X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh et al., “Openhands: An open platform for ai software developers as generalist agents,” in International Conference on Learning Representations, vol. 2025, 2025, p. 65 882–65 919. [11] H. Ruan, Y. Zhang, and A. Roychoudhury, “Specrover: Code intent extraction via llms,” in 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2025, p. 963–974. [12] H. Li, Y. Tang, S. Wang, and W. Guo, “PatchPilot: A cost-efficient software engineering agent with early attempts on formal verification,” arXiv preprint arXiv:2502.02747, 2025, unpublished. [13] V. Aggarwal, O. Kamal, A. Japesh, Z. Jin, and B. Sch ̈ olkopf, “Dars: Dynamic action re-sampling to enhance coding agent performance by adaptive tree traversal,” in Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2025, p. 19 808–19 855. [14] A. Zhao, D. Huang, Q. Xu, M. Lin, Y.-J. Liu, and G. Huang, “Expel: Llm agents are experiential learners,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 38, no. 17, 2024, p. 19 632–19 642. [15] C. Packer, V. Fang, S. Patil, K. Lin, S. Wooders, and J. Gonza- lez, “MemGPT: Towards LLMs as operating systems,” arXiv preprint arXiv:2310.08560, 2023, unpublished. 2 https://anonymous.4open.science/r/AdaRepair-Mem-EB46/ [16] W. Zhong, L. Guo, Q. Gao, H. Ye, and Y. Wang, “Memorybank: Enhancing large language models with long-term memory,” in Proceedings of the AAAI conference on artificial intelligence, vol. 38, no. 17, 2024, p. 19 724–19 731. [17] P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav, “Mem0: Building production-ready ai agents with scalable long-term memory,” arXiv preprint arXiv:2504.19413, 2025, unpublished. [18] P. Anokhin, N. Semenov, A. Sorokin, D. Evseev, A. Kravchenko, M. Burt- sev, and E. Burnaev, “Arigraph: Learning knowledge graph world models with episodic memory for llm agents,” arXiv preprint arXiv:2407.04363, 2024, unpublished. [19] J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein, “Generative agents: Interactive simulacra of human behavior,” in Proceedings of the 36th annual acm symposium on user interface software and technology, 2023, p. 1–22. [20] G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, Y. Zhu, L. Fan, and A. Anandkumar, “Voyager: An open-ended embodied agent with large language models,” arXiv preprint arXiv:2305.16291, 2023, unpublished. [21] T. P. Ferraz, R. Deffayet, V. Nikoulina, H. D ́ ejean, and S. Clinchant, “Retrieval-augmented llm agents: Learning to learn from experience,” arXiv preprint arXiv:2603.18272, 2026, unpublished. [22] P. Du, “Memory for autonomous llm agents: Mechanisms, evaluation, and emerging frontiers,” arXiv preprint arXiv:2603.07670, 2026, unpublished. [23] F. Mu, J. Wang, L. Shi, S. Wang, S. Li, and Q. Wang, “ExpeRepair: Dual-memory enhanced LLM-based repository-level program repair,” Proceedings of the ACM on Software Engineering, vol. 3, no. FSE, p. 3954–3976, 2026. [24] Z. Jiang, F. F. Xu, L. Gao, Z. Sun, Q. Liu, J. Dwivedi-Yu, Y. Yang, J. Callan, and G. Neubig, “Active retrieval augmented generation,” in Proceedings of the 2023 conference on empirical methods in natural language processing, 2023, p. 7969–7992. [25] S. Robertson and H. Zaragoza, The probabilistic relevance framework: BM25 and beyond. Now Publishers Inc, 2009, vol. 4. [26] J. Liu, D. Shen, Y. Zhang, W. B. Dolan, L. Carin, and W. Chen, “What makes good in-context examples for gpt-3?” in Proceedings of Deep Learning Inside Out (DeeLIO 2022): The 3rd workshop on knowledge extraction and integration for deep learning architectures, 2022, p. 100– 114. [27] O. Rubin, J. Herzig, and J. Berant, “Learning to retrieve prompts for in-context learning,” in Proceedings of the 2022 conference of the North American chapter of the association for computational linguistics: human language technologies, 2022, p. 2655–2671. [28] A. E. Hassan, “The road ahead for mining software repositories,” in 2008 frontiers of software maintenance. IEEE, 2008, p. 48–57. [29] P. Chakraborty, M. Alfadel, and M. Nagappan, “BLAZE: Cross-language and cross-project bug localization via dynamic chunking and hard example learning,” IEEE Transactions on Software Engineering, vol. 51, no. 8, p. 2254–2267, 2025. [30] X. Li, W. Li, Y. Zhang, and L. Zhang, “Deepfl: Integrating multiple fault diagnosis dimensions for deep fault localization,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis, 2019, p. 169–180. [31] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, M. Wang, and H. Wang, “Retrieval-augmented generation for large language models: A survey,” arXiv preprint arXiv:2312.10997, 2023, unpublished. [32] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the middle: How language models use long contexts,” Transactions of the association for computational linguistics, vol. 12, p. 157–173, 2024. [33] S. Chen, S. Lin, Y. Shi, H. Lian, X. Gu, L. Yun, D. Chen, L. Cao, J. Liu, N. Xia et al., “SWE-exp: Experience-driven software issue resolution,” arXiv preprint arXiv:2507.23361, 2025, unpublished. [34] K. Shen, J. Zhang, C. Sun, W. Zeng, and Y. Yue, “Structurally aligned subtask-level memory for software engineering agents,” arXiv preprint arXiv:2602.21611, 2026, unpublished. [35] A. Pabba, S. Chen, A. Mathai, A. Chakraborty, and B. Ray, “Refine: En- hancing program repair agents through context-aware patch refinement,” arXiv preprint arXiv:2510.03588, 2025, unpublished. [36] Q. Zhang, C. Gao, Y. Han, Y. Shang, C. Fang, Z. Chen, and L. Xiao, “Sga- gent: Suggestion-guided llm-based multi-agent framework for repository- level software repair,” ACM Transactions on Software Engineering and Methodology, 2026. [37] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” arXiv preprint arXiv:2210.03629, 2022, unpublished. [38] I. Badertdinov, A. Golubev, M. Nekrashevich, A. Shevtsov, S. Karasik, A. Andriushchenko, M. Trofimova, D. Litvintseva, and B. Yangel, “Swe- rebench: An automated pipeline for task collection and decontaminated evaluation of software engineering agents,” Advances in Neural Informa- tion Processing Systems, vol. 38, 2026. [39] J. Yang, C. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated soft- ware engineering,” Advances in Neural Information Processing Systems, vol. 37, p. 50 528–50 652, 2024. [40] Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury, “Autocoderover: Autonomous program improvement,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, p. 1592–1604. [41] A. Ni, S. Iyer, D. Radev, V. Stoyanov, W.-t. Yih, S. Wang, and X. V. Lin, “Lever: Learning to verify language-to-code generation with execution,” in International Conference on Machine Learning.PMLR, 2023, p. 26 106–26 128. [42] E. Dinella, G. Ryan, T. Mytkowicz, and S. K. Lahiri, “Toga: A neural method for test oracle generation,” in Proceedings of the 44th Interna- tional Conference on Software Engineering, 2022, p. 2130–2141. [43] S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. Clement, D. Drain, D. Jiang, D. Tang et al., “CodeXGLUE: A machine learning benchmark dataset for code understanding and generation,” arXiv preprint arXiv:2102.04664, 2021, unpublished. [44] Aider Developers, “Aider: Ai pair programming in your terminal,” 2026. [Online]. Available: https://github.com/Aider-AI/aider [45] K. Team, T. Bai, Y. Bai, Y. Bao, S. Cai, Y. Cao, Y. Charles, H. Che, C. Chen, G. Chen et al., “Kimi k2.5: Visual agentic intelligence,” arXiv preprint arXiv:2602.02276, 2026, unpublished. [46] Anthropic, “Introducing Claude 4,” 2025. [Online]. Available: https://w.anthropic.com/news/claude-4 [47] Anthropic, “Introducing Claude 3.5 Sonnet,” 2024. [Online]. Available: https://w.anthropic.com/news/claude-3-5-sonnet [48] D. Guo, D. Yang, H. Zhang, J. Song, P. Wang, Q. Zhu, R. Xu, R. Zhang, S. Ma, X. Bi et al., “DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning,” arXiv preprint arXiv:2501.12948, 2025, unpublished. [49] Z. Pan, C. Li, W. Zhong, Y. Feng, B. Luo, and V. Ng, “RepoRepair: Leveraging code documentation for repository-level automated program repair,” arXiv preprint arXiv:2603.01048, 2026, unpublished. [50] A. Antoniades, A. ̈ Orwall, K. Zhang, Y. Xie, A. Goyal, and W. Wang, “Swe-search: Enhancing software agents with monte carlo tree search and iterative refinement,” in International Conference on Learning Representations, vol. 2025, 2025, p. 64 485–64 515. [51] N. Jiang, T. Lutellier, and L. Tan, “Cure: Code-aware neural machine translation for automatic program repair,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, p. 1161–1173. [52] K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyand ́ e, “Tbar: Revisiting template-based automated program repair,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and anal- ysis, 2019, p. 31–42. [53] J. Bader, A. Scott, M. Pradel, and S. Chandra, “Getafix: Learning to fix bugs automatically,” Proceedings of the ACM on Programming Languages, vol. 3, no. OOPSLA, p. 1–27, 2019. [54] Z. Yang, S. Chen, C. Gao, Z. Li, X. Hu, K. Liu, and X. Xia, “An empirical study of retrieval-augmented code generation: Challenges and opportunities,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 7, p. 1–28, 2025. [55] E. Mansur, J. Chen, M. A. Raza, and M. Wardat, “Ragfix: Enhancing llm code repair using rag and stack overflow posts,” in 2024 IEEE International Conference on Big Data (BigData).IEEE, 2024, p. 7491–7496. [56] Y. Shi, A. A. Bangash, E. Fallahzadeh, B. Adams, and A. E. Hassan, “Hafix: History-augmented large language models for bug fixing,” Empir- ical Software Engineering, vol. 31, no. 4, p. 104, 2026. [57] C. Li, Y. Xu, Z. Wang, S. H. Tan, and T.-H. Chen, “From historical patches to repair plans: Outcome-conditioned reasoning for repository-level program repair,” arXiv preprint arXiv:2601.23257, 2026, unpublished. [58] H. Husain, H.-H. Wu, T. Gazit, M. Allamanis, and M. Brockschmidt, “Codesearchnet challenge: Evaluating the state of semantic code search,” arXiv preprint arXiv:1909.09436, 2019, unpublished. [59] W. Xiao, H. Zhao, and L. Huang, “The role of diversity in in-context learning for large language models,” arXiv preprint arXiv:2505.19426, 2025, unpublished. [60] J. Li, C. Tao, J. Li, G. Li, Z. Jin, H. Zhang, Z. Fang, and F. Liu, “Large language model-aware in-context learning for code generation,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 7, p. 1–33, 2025.