second brain
source
← 首页

external-source

AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair

AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair

Note: body below is original English text extracted from arXiv abs / HTML. Do not treat this file as a translation.

arXiv:2609.20130 · published 2026-09-17 · submitted 2026-09-17

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.

Authors

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

Key claims (verbatim-leaning English extract)

Structure (section headings from HTML)

Body excerpts (original English)

AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair Report GitHub Issue × Title: Content selection saved. Describe the issue below: Description: Submit without GitHub Submit in GitHub arXiv is now an independent nonprofit! Learn more × Back to arXiv Why HTML? Report Issue Back to Abstract Download PDF Abstract I Introduction II Background and Motivation II-A Repository-Level Program Repair II-B Repair Memories II-C Motivating Observations III Method III-A Coverage-Aware Retrieval (CAR) III-B Quality-Aware Selection (QAS) III-C Stage-Aware Routing (SAR) IV Experiments IV-A Setup IV-A 1 Benchmarks IV-A 2 Baselines IV-A 3 Metrics IV-A 4 Implementation Details IV-B Results IV-B 1 Overall Performance IV-B 2 Ablation Study IV-B 3 Repository Coverage Analysis IV-B 4 Token Efficiency IV-B 5 Generalization across LLMs IV-B 6 Cumulative resolution rates IV-B 7 File Localization Analysis IV-B 8 Intersection analysis. IV-B 9 Stage-Specific Memory Records V Related Work V-A Repository-Level Program Repair V-B Memory-Augmented Program Repair V-C Core Research Gaps in Retrieval Strategy VI Conclusion VII Data Availability References License: arXiv.org perpetual non-exclusive license arXiv:2609.20130v1 [cs.SE] 17 Sep 2026 AdaRepair-Mem: Adaptive Experience Orchestration for Repository-Level Program Repair Thanks: † These authors contributed equally. Thanks: * Corresponding author.Email: zhaoziming@zju.edu.cn Zichen Luo Affiliation: Zhejiang University Jiachen Guo Affiliation: Zhejiang University Affiliation: Tencent Wenjun He Affiliation: Zhejiang University Affiliation: Tencent Siyu Wang Affiliation: Zhejiang University Jiongchi Yu Affiliation: Zhejiang University Fangming Zhao Affiliation: Zhejiang University Yuan Chen Affiliation: Tencent Te Cao Affiliation: Tencent Liqun Liu Affiliation: Tencent Ning Zheng Affiliation: Tencent Wei Xu Affiliation: Tencent Jie Jiang Affiliation: Tencent Ziming Zhao Affiliation: Zhejiang University 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. 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 , 2 , 3 , 4 , 5 , 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 , 10 , 11 , 12 , 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 , 15 , 16 , 17 , 18 , 19 , 20 , 21 , 22 ] , and ExpeRepair [ 23 ] has extended this idea to repository-level 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. 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. While prior work has established the value of repair memories, 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 , 26 , 27 ] , and use a shared memory pool throughout the repair process. These design choices are largely heuristic, and their implications 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 , 29 , 30 , 31 ] . Beyond coverage, a larger memory pool does not necessarily lead to better repair performance [ 32 , 31 , 24 , 21 ] . Our analysis 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 different 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 , 34 , 35 , 36 ] . These observations suggest that repository identity alone is insufficient for effective memory retrieval. Successful memory-augmented repair requires selecting experiences that are appropriate for the repository, the repair task, and the current stage of the repair process [ 31 , 24 , 21 , 37 , 34 ] . 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 different 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: 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. • 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 repair. 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 historical experiences, while achieving better token efficiency than the base system. II Background and Motivation II-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 [ 39 , 40 , 12 ] , 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 ] . II-B Repair Memories In this work, a repair memory denotes a structured record extracted from a previous repair attempt [ 23 , 33 ] . A memory 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 , 33 , 25 ] . 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. II-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 unevenly 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 imply 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 [ 32 , 31 ] . 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 historical 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. III 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. III-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 development conventions. Broader repair knowledge is introduced only when repository-specific memories are insufficient to provide adequate retrieval coverage. Given an issue q q from repository r r , let M r M_{r} denote the repair memories belonging to repository r r , M c M_{c} denote repair memories retrieved from other repositories, and M t M_{t} denote repair-type-based memories that share similar repair patterns. In Algorithm 1 , we additionally use s s to denote the current repair stage, t t to denote the repair type of q q , ℳ \mathcal{M} to denote the constructed memory bank, B B to denote the maximum number of cross-repository candidates, and A s A_{s} 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 k k denote the minimum number of candidate memories required for subsequent retrieval. The candidate pool 𝒞 \mathcal{C} is constructed as 𝒞 = { M r , | M r | ≥ k , M r ∪ M c , | M r | < k ∧ | M r ∪ M c | ≥ k , M r ∪ M c ∪ M t , otherwise . \mathcal{C}=\begin{cases}M_{r},&|M_{r}|\geq k,\ M_{r}\cup M_{c},&|M_{r}|<k\land|M_{r}\cup M_{c}|\geq k,\ M_{r}\cup M_{c}\cup M_{t},&\text{otherwise}.\end{cases} (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. Algorithm 1 Coverage-Aware Retrieval (CAR) 1: issue q q , repository r r , repair stage s s , repair type t t 2: memory bank ℳ \mathcal{M} , coverage threshold k k , global cap B B , admission rule A s A_{s} 3: candidate memory pool 𝒞 \mathcal{C} 4: M r ← LoadSameRepoMemory ​ ( ℳ , r , s ) M_{r}\leftarrow\textsc{LoadSameRepoMemory}(\mathcal{M},r,s) 5: M r ← FilterAdmitted ​ ( M r , A s ) M_{r}\leftarrow\textsc{FilterAdmitted}(M_{r},A_{s}) 6: 𝒞 ← M r \mathcal{C}\leftarrow M_{r} 7: if | 𝒞 | < k |\mathcal{C}|<k then 8: M c ← LoadCrossRepoMemory ​ ( ℳ , r , s , B ) M_{c}\leftarrow\textsc{LoadCrossRepoMemory}(\mathcal{M},r,s,B) 9: M c ← FilterAdmitted ​ ( M c , A s ) M_{c}\leftarrow\textsc{FilterAdmitted}(M_{c},A_{s}) 10: 𝒞 ← 𝒞 ∪ M c \mathcal{C}\leftarrow\mathcal{C}\cup M_{c} 11: end if 12: if | 𝒞 | < k |\mathcal{C}|<k then 13: M t ← LoadRepairTypeMemory ​ ( ℳ , t , s , B ) M_{t}\leftarrow\textsc{LoadRepairTypeMemory}(\mathcal{M},t,s,B) 14: M t ← FilterAdmitted ​ ( M t , A s ) M_{t}\leftarrow\textsc{FilterAdmitted}(M_{t},A_{s}) 15: 𝒞 ← 𝒞 ∪ M t \mathcal{C}\leftarrow\mathcal{C}\cup M_{t} 16: end if 17: 𝒞 ← RemoveDuplicateMemory ​ ( 𝒞 ) \mathcal{C}\leftarrow\textsc{RemoveDuplicateMemory}(\mathcal{C}) 18: return 𝒞 \mathcal{C} III-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. Candidate 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 Selection (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 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 different information, QAS adopts stage-specific retrieval queries following the original retrieval strategy of ExpeRepair. For example, 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 information 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 memories. 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 m m is computed as Q ⁡ ( m ) = R ⁡ ( m ) + U ⁡ ( m ) + S ⁡ ( m ) − D ⁡ ( m ) , Q(m)=R(m)+U(m)+S(m)-D(m), (2) where R ⁡ ( m ) R(m) , U ⁡ ( m ) U(m) , S ⁡ ( m ) S(m) , and D ⁡ ( m ) D(m) 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. III-C Stage-Aware Routing (SAR) Coverage-aware Retrieval determines where candidate memories are retrieved from, while Quality-aware Selection determines 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 , M loc , M gen , M ref , M val } \mathcal{M}={M_{\text{rep}},M_{\text{loc}},M_{\text{gen}},M_{\text{ref}},M_{\text{val}}} denote the five stage-specific memory partitions. Given the current repair stage s s , SAR routes the quality-ranked memories to the corresponding stage by M ∗ = f ⁡ ( s , ℳ ) = M s , M^{*}=f(s,\mathcal{M})=M_{s}, (3) where M s M_{s} denotes the memory partition associated with stage s s . The selected memories are then incorporated into the prompt of the current repair stage. 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. Method LLM SWE-Bench Lite SWE-Bench Verified pass@1 (%) AVG Cost ($) pass@1 (%) AVG Cost ($) SWE-agent Claude 3.5 Sonnet 23.0 1.62 33.6 1.59 Aider GPT-4o + Claude 3 Opus 26.3 - - - AutoCodeRover GPT-4o 30.7 - - - SpecRover Claude 3.5 Sonnet + GPT-4o 31.0 0.65 46.2 - Agentless-1.5 Claude 3.5 Sonnet 40.7 1.12 50.8 1.19 OpenHands CodeAct v2.1 41.7 1.33 53.0 0.78 PatchPilot Claude 3.5 Sonnet 45.3 0.97 53.6 0.99 DARS Claude 3.5 Sonnet + DeepSeek R1 47.0 12.24 - - ExpeRepair Claude 3.5 Sonnet + o4-mini 48.3 1.89 57.2 1.74 AdaRepair-Mem Claude 3.5 Sonnet + o4-mini 51.0 1.67 63.2 1.52 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 IV-A Setup IV-A 1 Benchmarks We evaluate AdaRepair-Mem on two widely used repository-level program repair benchmarks, SWE-Bench-Lite and SWE-Bench-Verified [ 7 ] . SWE-Bench-Lite contains 300 real GitHub issues sampled from popular Python repositories 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 understanding and multi-file reasoning. IV-A 2 Baselines We compare AdaRepair-Mem with representative open-source repository-level program repair methods on SWE-Bench-Lite and SWE-Bench-Verified 1 1 1 https://www.swebench.com/ . 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 execution. 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. 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. TABLE II: File localization results comparison between RepoRepair, Agentless Lite, and AdaRepair-Mem on SWE-Bench Lite. AL = Agentless Lite; RR = RepoRepair; Ada-Mem = AdaRepair-Mem. Repository Instances File Retrieval (%) File Localization (%) AL RR Ada-Mem AL RR Ada-Mem astropy/astropy 6 100 100 100 83.33 100 100 django/django 114 95.61 96.49 96.49 85.09 87.72 92.98 matplotlib/matplotlib 23 91.30 95.65 95.65 43.48 69.57 95.65 mwaskom/seaborn 4 100 100 100 50.00 75.00 100 pallets/flask 3 100 100 100 100 100 100 psf/requests 6 100 100 83.33 83.33 100 83.33 pydata/xarray 5 100 100 100 80.00 100 100 pylint-dev/pylint 6 100 66.67 83.33 100 50.00 83.33 pytest-dev/pytest 17 100 88.24 94.12 94.12 5.88 100 scikit-learn/scikit-learn 23 100 95.65 95.65 65.22 73.91 95.65 sphinx-doc/sphinx 16 100 100 100 75.00 75.00 100 sympy/sympy 77 94.81 89.61 88.31 63.64 84.42 87.01 Total 300 96.33 94.00 94.00 74.67 79.00 92.67 Memory-augmented repair. This category reuses 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. IV-A 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 generated reproduction scripts that execute successfully without errors, such as missing dependencies or configuration issues. IV-A 4 Implementation Details We follow ExpeRepair’s memory construction mechanism and repair pipeline, replacing only its retrieval strategy. For coverage-aware retrieval (CAR), we set the initial same-repository retrieval target to k same = 10 k_{\text{same}}=10 and expand to cross-repository and repair-type pools when fewer than k same k_{\text{same}} candidates are available, with cross-repository pool size capped at k cross = 50 k_{\text{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 alignment 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. TABLE III: Repair performance across repositories with different memory coverage levels. Cover: memory coverage level; Memo: the number of repair memories per repository. Cover Repo Memo BaseMemo AdaRepair-Mem High django 82 63.1% 65.8% ↑ \uparrow 2.7 sympy 31 Medium flask 18 41.2% 52.3% ↑ \uparrow 11.1 sphinx 15 Low astropy 3 55.3% 58.3% ↑ \uparrow 3.0 matplotlib 1 IV-B Results IV-B 1 Overall Performance Table I reports the main comparison 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. IV-B 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. IV-B 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 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. Fig. 5: Token Efficiency Across Repositories: resolved tasks per 1,000 API input tokens; higher is better. Table III 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. TABLE IV: Ablation study on memory modules of AdaRepair-Mem. Method SWE-Bench Lite SWE-Bench Verified pass@1 (%) ESR (%) AVG Cost($) pass@1 (%) ESR (%) AVG Cost($) AdaRepair-Mem 75.0 75.0 2.55 70.8 75.0 2.18 w/o CAR 75.0 62.5 2.43 50.0 62.5 2.13 w/o QAS 58.3 50.0 2.70 45.8 75.0 2.54 w/o SAR 66.7 45.8 2.70 62.5 66.7 2.39 baseline 45.8 45.8 2.91 45.8 50.0 2.78 IV-B 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. IV-B 5 Generalization across LLMs For the model generalization 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 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. Fig. 6: Intersection analysis of resolved instances across seven repository-level repair systems. Purple bars indicate intersections that include AdaRepair-Mem. IV-B 6 Cumulative resolution rates Fig. 7 reports the cumulative 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 III , 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. Fig. 7: Cumulative resolution rates of AdaRepair-Mem across repositories on SWE-Bench-Verified. 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. Fig. 9: Two real cases from the SymPy and Django repositories resolved by AdaRepair-Mem. IV-B 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 II reports per-repository results on SWE-Bench Lite. 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 outperforming 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 (compared to 1 for RepoRepair) and 22 of 23 matplotlib issues (compared to 10 for Agentless Lite). These results suggest that adaptively retrieved repair memories 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, complementing lexical and documentation-based similarity signals. IV-B 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 instances, and 94 instances are solved by all methods. Beyond this common subset, many large intersections still include AdaRepair-Mem, indicating that AdaRepair-Mem remains competitive 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. IV-B 9 Stage-Specific Memory Records Figure 8 shows representative 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 V-A Repository-Level Program Repair Large language models have advanced automated program repair (APR) from function-level patch generation to repository-level issue resolution [ 7 , 1 , 2 ] . 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. V-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 , 52 , 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. V-C Core Research Gaps in Retrieval Strategy Repair-memory retrieval essentially answers three core questions: which memories to retrieve, where to retrieve from, and when to use them. Existing studies only address these questions 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 repositories. 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 experiences 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 2 2 https://anonymous.4open.science/r/AdaRepair-Mem-EB46/ 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 summaries, 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 (2023) 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) , pp. 31–53 . Cited by: §I , §V-A . [2] Z. Zheng, K. Ning, Y. Wang, J. Zhang, D. Zheng, M. Ye, and J. Chen (2023) A survey of large language models for code: evolution, benchmarking, and future trends . arXiv preprint arXiv:2311.10372 . Note: unpublished Cited by: §I , §V-A . [3] D. Zan, B. Chen, F. Zhang, D. Lu, B. Wu, B. Guan, W. Yongji, and J. Lou (2023) Large language models meet nl2code: a survey . In Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) , pp. 7443–7464 . Cited by: §I . [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. (2021) Evaluating large language models trained on code . arXiv preprint arXiv:2107.03374 . Note: unpublished Cited by: §I . [5] Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago, et al. (2022) Competition-level code generation with AlphaCode . Science 378 ( 6624 ), pp. 1092–1097 . Cited by: §I . [6] J. Austin, A. Odena, M. Nye, M. Bosma, H. Michalewski, D. Dohan, E. Jiang, C. Cai, M. Terry, Q. Le, et al. (2021) Program synthesis with large language models . arXiv preprint arXiv:2108.07732 . Note: unpublished Cited by: §I . [7] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan (2024) SWE-bench: can language models resolve real-world GitHub issues? . In International Conference on Learning Representations , Vol. 2024 , pp. 54107–54157 . Cited by: §I , §I , §II-A , §IV-A1 , §IV-A3 , §V-A . [8] M. Martinez and X. Franch (2025) Dissecting the SWE-bench leaderboards: profiling submitters and architectures of LLM- and agent-based repair systems . arXiv preprint arXiv:2506.17208 . Note: unpublished Cited by: §I , §I . [9] C. S. Xia, Y. Deng, S. Dunn, and L. Zhang (2024) Agentless: demystifying LLM-based software engineering agents . arXiv preprint arXiv:2407.01489 . Note: unpublished Cited by: §I , §II-A , §IV-A2 , §IV-A3 , §IV-B7 , §V-A . [10] X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh, et al. (2025) Openhands: an open platform for ai software developers as generalist agents . In International Conference on Learning Representations , Vol. 2025 , pp. 65882–65919 . Cited by: §I , §IV-A2 . [11] H. Ruan, Y. Zhang, and A. Roychoudhury (2025) Specrover: code intent extraction via llms . In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE) , pp. 963–974 . Cited by: §I , §IV-A2 . [12] H. Li, Y. Tang, S. Wang, and W. Guo (2025) PatchPilot: a cost-efficient software engineering agent with early attempts on formal verification . arXiv preprint arXiv:2502.02747 . Note: unpublished Cited by: §I , §I , §I , §II-A , §II-C , §IV-A2 , §V-A , §V-C . [13] V. Aggarwal, O. Kamal, A. Japesh, Z. Jin, and B. Schölkopf (2025) 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) , pp. 19808–19855 . Cited by: §I , §IV-A2 . [14] A. Zhao, D. Huang, Q. Xu, M. Lin, Y. Liu, and G. Huang (2024) Expel: llm agents are experiential learners . In Proceedings of the AAAI Conference on Artificial Intelligence , Vol. 38 , pp. 19632–19642 . Cited by: §I . [15] C. Packer, V. Fang, S. Patil, K. Lin, S. Wooders, and J. Gonzalez (2023) MemGPT: towards LLMs as operating systems . arXiv preprint arXiv:2310.08560 . Note: unpublished Cited by: §I . [16] W. Zhong, L. Guo, Q. Gao, H. Ye, and Y. Wang (2024) Memorybank: enhancing large language models with long-term memory . In Proceedings of the AAAI conference on artificial intelligence , Vol. 38 , pp. 19724–19731 . Cited by: §I . [17] P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav (2025) Mem0: building production-ready ai agents with scalable long-term memory . arXiv preprint arXiv:2504.19413 . Note: unpublished Cited by: §I . [18] P. Anokhin, N. Semenov, A. Sorokin, D. Evseev, A. Kravchenko, M. Burtsev, and E. Burnaev (2024) Arigraph: learning knowledge graph world models with episodic memory for llm agents . arXiv preprint arXiv:2407.04363 . Note: unpublished Cited by: §I . [19] J. S. Park, J. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein (2023) Generative agents: interactive simulacra of human behavior . In Proceedings of the 36th annual acm symposium on user interface software and technology , pp. 1–22 . Cited by: §I . [20] G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, Y. Zhu, L. Fan, and A. Anandkumar (2023) Voyager: an open-ended embodied agent with large language models . arXiv preprint arXiv:2305.16291 . Note: unpublished Cited by: §I . [21] T. P. Ferraz, R. Deffayet, V. Nikoulina, H. Déjean, and S. Clinchant (2026) Retrieval-augmented llm agents: learning to learn from experience . arXiv preprint arXiv:2603.18272 . Note: unpublished Cited by: §I , §I , §I . [22] P. Du (2026) Memory for autonomous llm agents: mechanisms, evaluation, and emerging frontiers . arXiv preprint arXiv:2603.07670 . Note: unpublished Cited by: §I . [23] F. Mu, J. Wang, L. Shi, S. Wang, S. Li, and Q. Wang (2026) ExpeRepair: dual-memory enhanced LLM-based repository-level program repair . Proceedings of the ACM on Software Engineering 3 ( FSE ), pp. 3954–3976 . Cited by: §I , §II-A , §II-B , §IV-A2 , §IV-A3 , §V-B . [24] Z. Jiang, F. F. Xu, L. Gao, Z. Sun, Q. Liu, J. Dwivedi-Yu, Y. Yang, J. Callan, and G. Neubig (2023) Active retrieval augmented generation . In Proceedings of the 2023 conference on empirical methods in natural language processing , pp. 7969–7992 . Cited by: §I , §I , §I . [25] S. Robertson and H. Zaragoza (2009) The probabilistic relevance framework: bm25 and beyond . Vol. 4 , Now Publishers Inc . Cited by: §I , §II-B , §III-B . [26] J. Liu, D. Shen, Y. Zhang, W. B. Dolan, L. Carin, and W. Chen (2022) 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 , pp. 100–114 . Cited by: §I . [27] O. Rubin, J. Herzig, and J. Berant (2022) 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 , pp. 2655–2671 . Cited by: §I . [28] A. E. Hassan (2008) The road ahead for mining software repositories . In 2008 frontiers of software maintenance , pp. 48–57 . Cited by: §I , §I . [29] P. Chakraborty, M. Alfadel, and M. Nagappan (2025) BLAZE: cross-language and cross-project bug localization via dynamic chunking and hard example learning . IEEE Transactions on Software Engineering 51 ( 8 ), pp. 2254–2267 . External Links: Document Cited by: §I , §I , §V-C . [30] X. Li, W. Li, Y. Zhang, and L. Zhang (2019) Deepfl: integrating multiple fault diagnosis dimensions for deep fault localization . In Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis , pp. 169–180 . Cited by: §I , §V-C . [31] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, M. Wang, and H. Wang (2023) Retrieval-augmented generation for large language models: a survey . arXiv preprint arXiv:2312.10997 . Note: unpublished Cited by: §I , §I , §I , §I , §II-C . [32] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang (2024) Lost in the middle: how language models use long contexts . Transactions of the association for computational linguistics 12 , pp. 157–173 . Cited by: §I , §I , §II-C . [33] S. Chen, S. Lin, Y. Shi, H. Lian, X. Gu, L. Yun, D. Chen, L. Cao, J. Liu, N. Xia, et al. (2025) SWE-exp: experience-driven software issue resolution . arXiv preprint arXiv:2507.23361 . Note: unpublished Cited by: §I , §II-A , §II-B , §V-B . [34] K. Shen, J. Zhang, C. Sun, W. Zeng, and Y. Yue (2026) Structurally aligned subtask-level memory for software engineering agents . arXiv preprint arXiv:2602.21611 . Note: unpublished Cited by: §I , §I , §I , §II-C , §V-C . [35] A. Pabba, S. Chen, A. Mathai, A. Chakraborty, and B. Ray (2025) REFINE: enhancing program repair agents through context-aware patch refinement . arXiv preprint arXiv:2510.03588 . Note: unpublished Cited by: §I . [36] Q. Zhang, C. Gao, Y. Han, Y. Shang, C. Fang, Z. Chen, and L. Xiao (2026) Sgagent: suggestion-guided llm-based multi-agent framework for repository-level software repair . ACM Transactions on Software Engineering and Methodology . External Links: ISSN 1049-331X , Document Cited by: §I . [37] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao (2022) ReAct: synergizing reasoning and acting in language models . arXiv preprint arXiv:2210.03629 . Note: unpublished Cited by: §I . [38] I. Badertdinov, A. Golubev, M. Nekrashevich, A. Shevtsov, S. Karasik, A. Andriushchenko, M. Trofimova, D. Litvintseva, and B. Yangel (2026) Swe-rebench: an automated pipeline for task collection and decontaminated evaluation of software engineering agents . Advances in Neural Information Processing Systems 38 . Cited by: §I , §IV-A1 . [39] J. Yang, C. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press (2024) Swe-agent: agent-computer interfaces enable automated software engineering . Advances in Neural Information Processing Systems 37 , pp. 50528–50652 . Cited by: §II-A , §IV-A2 , §V-A . [40] Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury (2024) Autocoderover: autonomous program improvement . In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis , pp. 1592–1604 . Cited by: §II-A , §IV-A2 , §V-A . [41] A. Ni, S. Iyer, D. Radev, V. Stoyanov, W. Yih, S. Wang, and X. V. Lin (2023) Lever: learning to verify language-to-code generation with execution . In International Conference on Machine Learning , pp. 26106–26128 . Cited by: §III-C . [42] E. Dinella, G. Ryan, T. Mytkowicz, and S. K. Lahiri (2022) Toga: a neural method for test oracle generation . In Proceedings of the 44th International Conference on Software Engineering , pp. 2130–2141 . Cited by: §III-C . [43] S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. Clement, D. Drain, D. Jiang, D. Tang, et al. (2021) CodeXGLUE: a machine learning benchmark dataset for code understanding and generation . arXiv preprint arXiv:2102.04664 . Note: unpublished Cited by: §IV-A1 . [44] Aider Developers (2026) Aider: ai pair programming in your terminal . External Links: Link Cited by: §IV-A2 . [45] K. Team, T. Bai, Y. Bai, Y. Bao, S. Cai, Y. Cao, Y. Charles, H. Che, C. Chen, G. Chen, et al. (2026) Kimi k2.5: visual agentic intelligence . arXiv preprint arXiv:2602.02276 . Note: unpublished Cited by: §IV-B5 . [46] Anthropic (2025) Introducing Claude 4 . Anthropic . External Links: Link Cited by: §IV-B5 . [47] Anthropic (2024) Introducing Claude 3.5 Sonnet . Anthropic . External Links: Link Cited by: §IV-B5 . [48] D. Guo, D. Yang, H. Zhang, J. Song, P. Wang, Q. Zhu, R. Xu, R. Zhang, S. Ma, X. Bi, et al. (2025) DeepSeek-R1: incentivizing reasoning capability in LLMs via reinforcement learning . arXiv preprint arXiv:2501.12948 . Note: unpublished Cited by: §IV-B5 . [49] Z. Pan, C. Li, W. Zhong, Y. Feng, B. Luo, and V. Ng (2026) RepoRepair: leveraging code documentation for repository-level automated program repair . arXiv preprint arXiv:2603.01048 . Note: unpublished Cited by: §IV-B7 . [50] A. Antoniades, A. Örwall, K. Zhang, Y. Xie, A. Goyal, and W. Wang (2025) Swe-search: enhancing software agents with monte carlo tree search and iterative refinement . In International Conference on Learning Representations , Vol. 2025 , pp. 64485–64515 . Cited by: §V-A . [51] N. Jiang, T. Lutellier, and L. Tan (2021) Cure: code-aware neural machine translation for automatic program repair . In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) , pp. 1161–1173 . Cited by: §V-B . [52] K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyandé (2019) TBar: revisiting template-based automated program repair . In Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis , pp. 31–42 . Cited by: §V-B . [53] J. Bader, A. Scott, M. Pradel, and S. Chandra (2019) Getafix: learning to fix bugs automatically . Proceedings of the ACM on Programming Languages 3 ( OOPSLA ), pp. 1–27 . Cited by: §V-B . [54] Z. Yang, S. Chen, C. Gao, Z. Li, X. Hu, K. Liu, and X. Xia (2025) An empirical study of retrieval-augmented code generation: challenges and opportunities . ACM Transactions on Software Engineering and Methodology 34 ( 7 ), pp. 1–28 . Cited by: §V-B . [55] E. Mansur, J. Chen, M. A. Raza, and M. Wardat (2024) Ragfix: enhancing llm code repair using rag and stack overflow posts . In 2024 IEEE International Conference on Big Data (BigData) , pp. 7491–7496 . Cited by: §V-B . [56] Y. Shi, A. A. Bangash, E. Fallahzadeh, B. Adams, and A. E. Hassan (2026) Hafix: history-augmented large language models for bug fixing . Empirical Software Engineering 31 ( 4 ), pp. 104 . Cited by: §V-B . [57] C. Li, Y. Xu, Z. Wang, S. H. Tan, and T. Chen (2026) From historical patches to repair plans: outcome-conditioned reasoning for repository-level program repair . arXiv preprint arXiv:2601.23257 . Note: unpublished Cited by: §V-B , §V-C . [58] H. Husain, H. Wu, T. Gazit, M. Allamanis, and M. Brockschmidt (2019) Codesearchnet challenge: evaluating the state of semantic code search . arXiv preprint arXiv:1909.09436 . Note: unpublished Cited by: §V-C . [59] W. Xiao, H. Zhao, and L. Huang (2025) The role of diversity in in-context learning for large language models . arXiv preprint arXiv:2505.19426 . Note: unpublished Cited by: §V-C . [60] J. Li, C. Tao, J. Li, G. Li, Z. Jin, H. Zhang, Z. Fang, and F. Liu (2025) Large language model-aware in-context learning for code generation . ACM Transactions on Software Engineering and Methodology 34 ( 7 ), pp. 1–33 . Cited by: §V-C . Experimental support, please view the build logs for errors. Generated by L A T E xml . Instructions for reporting errors We are continuing to improve HTML versions of papers, and your feedback helps enhance accessibility and mobile support. To report errors in the HTML that will help us improve conversion and rendering, choose any of the methods listed below: Click the "Report Issue" ( ) button, located in the page header. Tip: You can select the relevant text first, to include it in your report. Our team has already identified the following issues . We appreciate your time reviewing and reporting rendering errors we may not have found yet. Your efforts will help us improve the HTML versions for all readers, because disability should not be a barrier to accessing research. Thank you for your continued support in championing open access for all. Have a free development cycle? Help support accessibility at arXiv! Our collaborators at LaTeXML maintain a list of packages that need conversion , and welcome developer contributions . We gratefully acknowledge support from our major funders , member institutions , , and all contributors. About · Help · Contact · Subscribe · Copyright · Privacy · Accessibility · Operational Status (opens in new tab) Major funding support from