arXiv:2604.24222v1 [cs.SE] 27 Apr 2026
MEMCoder: Multi-dimensional Evolving Memory for Private-Library-Oriented Code Generation Mofei Li*
Taozhi Chen*
Guowei Yang
Jia Li†
College of AI Tsinghua University Beijing, China Fitten Tech Co., Ltd. Beijing, China [email protected]
College of AI Tsinghua University Beijing, China [email protected]
Fitten Tech Co., Ltd. Beijing, China [email protected]
College of AI Tsinghua University Beijing, China [email protected]
Abstract—Large Language Models (LLMs) excel at general code generation, but their performance drops sharply in enterprise settings that rely on internal private libraries absent from public pre-training corpora. While Retrieval-Augmented Generation (RAG) offers a training-free alternative by providing static API documentation, we find that such documentation typically provides only isolated definitions, leaving a fundamental knowledge gap. Specifically, LLMs struggle with a task-level lack of coordination patterns between APIs and an API-level misunderstanding of parameter constraints and boundary conditions. To address this, we propose MEMC ODER, a novel framework that enables LLMs to autonomously accumulate and evolve Usage Guidelines across these two dimensions. MEMC ODER introduces a Multi-dimensional Evolving Memory that captures distilled lessons from the model’s own problem-solving trajectories. During inference, MEMC ODER employs a dual-source retrieval mechanism to inject both static documentation and relevant historical guidelines into the context. The framework operates in an automated closed loop by using objective execution feedback to reflect on successes and failures, resolve knowledge conflicts, and dynamically update memory. Extensive evaluations on the NdonnxEval and NumbaEval benchmarks demonstrate that MEMC ODER substantially enhances existing RAG systems, yielding an average absolute pass@1 gain of 16.31%. Furthermore, MEMC ODER exhibits vastly superior domain-specific adaptation compared to existing memory-based continual learning methods.
I. I NTRODUCTION Large Language Models (LLMs) have demonstrated exceptional proficiency in general code generation tasks [1–4]. However, their performance drops sharply in real-world enterprise environments that rely heavily on internal private libraries, which are absent from public pre-training corpora [5, 6]. This gap defines the task of Private-Library-Oriented Code Generation, which requires models to accurately coordinate projectspecific APIs to fulfill complex requirements. Since LLMs typically lack prior knowledge of these libraries, they often struggle to utilize them effectively, thereby significantly limiting their practical efficacy in real-world software development. To address the issue that private-library APIs are absent from public pre-training corpora, the prevailing paradigm leverages Retrieval-Augmented Generation (RAG) to provide * Equal contribution. † Corresponding author.
LLMs with static API documentation [5–8]. However, our study in Section III reveals that the performance gains from merely providing static documentation are remarkably limited. Empirical results show that even in an Oracle setting where the complete set of required documentation is perfectly injected, the performance of advanced code models remains unsatisfactory. For instance, in the NumbaEval benchmark [9– 11], providing full API specifications only improves the Pass@1 of Qwen2.5-Coder-7B-Instruct [12] from 26.15% to 27.70%, an incremental gain of only 1.55%. Through qualitative observation of these failure cases, we find that the root cause is that static documentation typically provides only isolated API definitions, and the model still does not know how to correctly utilize these APIs in complex scenarios. Specifically, this gap exists at two levels: a task-level lack of coordination patterns between multiple APIs, and an API-level misunderstanding of parameter constraints and boundary conditions. To this end, as illustrated in Figure 1, we manually write Usage Guidelines covering both levels and inject them into the context, finding that the model can correct previous invocation errors and produce executable solutions. This contrast suggests that relying solely on static API documentation is insufficient, and incorporating Usage Guidelines that can teach the model how to use APIs into the retrieval source can further enhance the performance of private-library-oriented code generation. Given the critical value of Usage Guidelines, a key operational challenge arises in their acquisition. For large-scale and rapidly evolving private libraries, relying on manual efforts to craft these Usage Guidelines is not only labor-intensive but also entirely unsustainable in real-world development scenarios. Considering that existing research demonstrates LLMs can self-reflect through test-time interactions with the environment and continuously accumulate insights into the reasons behind task success or failure [13], we naturally investigate in Section III whether LLMs can leverage this capability to automatically reflect on and generate Usage Guidelines from their own generated responses and execution feedback. Our analysis (as illustrated in Figure 2) reveals that when provided with their initially generated code and the corresponding execution feedback, the models demonstrate a remarkable
ability to reflect and accurately generate high-quality Usage benchmarks for code completion, function synthesis, and Guidelines, which subsequently enable the models to correct program construction. These results suggest that modern code their previous errors and produce correct solutions. This finding LLMs can capture common programming patterns, language suggests that instead of relying on high-cost manual curation, syntax, and knowledge about widely used public libraries. we can implement an automated closed loop of generation, Despite this progress, the capability of code LLMs remains execution, feedback, and reflection to achieve the autonomous fundamentally constrained by the knowledge available during accumulation of Usage Guidelines during the inference process. training [27]. After pretraining or instruction tuning, model Based on the above observations and analysis, we propose parameters provide only a static representation of library knowlMEMC ODER, a novel framework for private-library-oriented edge. As a result, code LLMs often struggle on tasks that decode generation characterized by its training-free, plug-and-play, pend on knowledge absent from public corpora, such as projectand continual learning nature. To address the identified task- internal APIs, proprietary libraries, or rapidly evolving software level and API-level knowledge gaps, the core of MEMC ODER ecosystems [6, 28]. This limitation has motivated a growing line is a Multi-dimensional Evolving Memory that stores and of research on code generation under external knowledge supmaintains Usage Guidelines across two dimensions—task-level port, especially in settings where successful generation depends memory and API-level memory—supplemented by key auxil- on access to private-library information at inference time. iary information such as code snippets and execution feedback. Private-Library-Oriented Code Generation. Private-libraryDuring inference, MEMC ODER employs a Guideline-Driven oriented code generation studies how to generate executable Code Generation strategy, which injects relevant static code for tasks that depend on proprietary or project-internal documentation along with Usage Guidelines into the context libraries [6]. Compared with conventional code generation [29– through a dual-source retrieval mechanism. After code exe- 32], this setting is more challenging because the target APIs cution, MEMC ODER utilizes execution feedback to refine and are often absent from public training corpora, and successful update the Usage Guidelines via a Feedback-Driven Memory generation depends on accurate understanding and correct Evolution mechanism. We conducted extensive experiments use of library-specific functions. Existing work includes both on private-library benchmarks, and the results validate the training-based and training-free solutions, but training-based effectiveness of MEMC ODER. Integrating MEMC ODER into adaptation is often less practical in private-library settings strong static RAG baselines yields an average absolute Pass@1 because supervision data is limited and library APIs evolve gain of 16.31%. Moreover, under continual adaptation settings, over time [11, 33–35]. Existing training-free approaches consistently address MEMC ODER outperforms existing memory-based continual private-library code generation with retrieval-augmented learning baselines without updating model parameters. generation (RAG) [36]. Early methods such as APIFinder [6] In summary, our contributions are as follows: and DocPrompting [7] retrieve relevant APIs or library • We identify the limitations of static API documentation in private-library-oriented code generation. To address this, documents and provide the retrieved information in the we introduce a Multi-dimensional Evolving Memory that prompt. Later work improves this pipeline by strengthening extends the retrieval source from static documentation API retrieval. For example, EpiGEN [8] and CAPIR [37] alone to documentation enriched with reusable Usage decompose coding requirements into intermediate subtasks or intents before retrieval to improve API matching and Guidelines. • We propose MEMC ODER , a novel framework for private- recall, while ExploraCoder [5] further incorporates real-time library-oriented code generation characterized by its execution feedback within a single task to alleviate failures training-free, plug-and-play, and continual learning nature. caused by incomplete or ambiguous API documentation. Existing methods still frame private-library code generation It organizes Usage Guidelines into task-level and API-level memory, jointly retrieves documentation and memory dur- mainly as a retrieval problem [6–8, 37]. Retrieved ing inference, and continuously evolves memory through documentation is necessary, but often insufficient for executable solutions, because correct private-library use a closed loop of execution, feedback, and reflection. also depends on cross-API composition patterns, practical • We conduct extensive experiments on private-library benchmarks. MEMC ODER consistently improves strong constraints, and error-prone details that are not fully specified static RAG baselines and outperforms existing memory- in documentation. This gap motivates methods that leverage based continual learning methods without updating model reusable usage experience in addition to retrieved documents. Memory-Based Continual Learning. A growing line of work parameters. studies how language models can improve over time by accumuII. R ELATED W ORK lating and reusing memory during inference, without repeated Large Language Models for Code Generation. Large offline retraining [13, 38]. In these approaches, the model is language models (LLMs) have recently become a dominant augmented with dynamically updated external memory, such paradigm for code generation and software engineering as retrieved context, reusable summaries, reflections, execution tasks [14–18]. Recent model families, including GPT [19, 20], trajectories, or other experience records [13, 38]. Such methods LLaMA [21, 22], Qwen [23, 24], and DeepSeek [25, 26], are especially appealing when the target knowledge is private, have achieved strong performance on a broad range of evolving, or difficult to collect as supervised training data [11].
Failure under Oracle Docs Only
TABLE I Pass@k ON NdonnxEval AND NumbaEval. NdonnxEval
Method pass@1
pass@3
Input:
NumbaEval pass@5
pass@1
pass@3
pass@5
42.89 45.35 +2.46
50.08 52.65 +2.57
21.37 21.77 +0.40
28.90 28.79 -0.11
27.46 29.47 +2.01
37.52 38.26 +0.74
Qwen2.5-Coder-7B-Instruct Vanilla Oracle Gain (↑)
14.20 45.62 +31.42
23.57 61.31 +37.74
27.78 66.66 +38.88
26.15 27.70 +1.55
Llama-3.1-8B-Instruct Vanilla Oracle Gain (↑)
6.75 26.92 +20.17
Vanilla Oracle Gain (↑)
12.60 43.73 +31.13
14.13 43.84 +29.71
18.31 51.06 +32.75
9.57 10.16 +0.59
DeepSeek-Coder-6.7B-Instruct 21.53 59.66 +38.13
26.34 65.50 +39.16
11.93 13.53 +1.60
Recent work has explored several forms of memory-based continual learning. For example, Dynamic Cheatsheet [38] maintains a persistent adaptive memory of reusable strategies, code snippets, and problem-solving insights, while and ReMem [13] study how historical experience can be retrieved, refined, and updated to support future inference. These approaches show that inference-time accumulation and reuse of experience can improve downstream performance without modifying model parameters [13, 38]. Our work is related to this line of research, but differs in both task setting and memory design. Existing methods are mostly designed for general reasoning or agent tasks, rather than private-library-oriented code generation. In addition, prior methods typically store reusable experience in a single memory space, without explicitly separating task-level reusable knowledge from API-level reusable knowledge. In contrast, MEMC ODER uses a Multi-dimensional Evolving Memory tailored to private-library-oriented code generation and updates both task-level and API-level experience from execution feedback. III. M OTIVATION
Goal: Convert input data to an array of a given shape filled with a specified constant value; if a mask is provided, masked positions should take the constant while unmasked positions keep the original values. Required API Knowledge (Oracle): • ndonnx.full(shape, fill_value, *, dtype=None, device=None) -> Array Creates a constant-filled target array with the requested shape. • ndonnx.broadcast_arrays(*arrays) -> list[Array] Aligns multiple arrays to a shared broadcasted shape. • ndonnx.where(cond, a, b) -> Array Returns a where cond is true, and b otherwise. • …
Output: 1: def masked_fill_like(x, shape, fill_value, mask=None): 2: x_array = ndx.asarray(x) 3: result = ndx.full(shape, fill_value) 4: if mask is not None: 5: mask_array = ndx.asarray(mask) 6: broadcasted_mask = ndx.broadcast_to(mask_array, x_array.shape) 7: result = ndx.where(broadcasted_mask, x_array, result) 8: return result
Failure: ValueError: target rank must be equal or greater than rank of 'self'
Success with Usage Guidelines Input: Goal: Convert input data to an array of a given shape filled with a specified… Required API Knowledge (Oracle): • ndonnx.full… Usage Guidelines: • Task-level: Align data, mask, and the constant-filled target to a shared broadcasted shape before masked selection. • API-level: 1. Use ndx.full(shape, fill_value) to construct the constant-filled target array. 2. Use ndx.broadcast_arrays(...) to align the data input, mask, and target to one shared shape before selection. 3. In ndx.where(cond, a, b), cond=True selects a, and cond=False selects b.
Output: 1: def masked_fill_like(x, shape, fill_value, mask=None): 2: x_arr = ndx.asarray(x) 3: result = ndx.full(shape, fill_value) 4: if mask is not None: 5: mask_arr = ndx.asarray(mask) 6: data_b, mask_b, target_b = ndx.broadcast_arrays(x_arr, mask_arr, target) 7: result = ndx.where(mask_b, target_b, data_b) 8: else: 9: result = target 10: return result
Success: Passes all test cases.
Fig. 1. A representative failure case study on NdonnxEval. Qualitative analysis reveals model failures at both the task-level and API-level . Injecting targeted Usage Guidelines addressing these two levels successfully recovers the correct invocation pattern.
Currently, private-library-oriented code generation primarily relies on the RAG framework. Research efforts have largely focused on optimizing retrieval algorithms to improve the recall of API documentation, aiming to push performance toward the theoretical upper bound of this paradigm. However, requirements for practical deployment. The effects of injecting little research has investigated the limitations of this upper static API documentation vary significantly across libraries. On bound itself—specifically, whether relying solely on static API NdonnxEval, although the three models achieve a significant documentation is sufficient to support reliable code generation. average Pass@1 gain of 27.57%, the theoretical upper bound To investigate the theoretical bottleneck, we design an Oracle remains constrained, with an average Pass@5 success rate of study. By directly injecting all required API specifications only 61.07%. On the more complex NumbaEval benchmark, (including signatures and descriptions), we completely elimi- the injection of static API documentation is nearly ineffective, nate retrieval errors to observe the actual gains of static API with an average Pass@1 improvement of only 1.25% across documentation. We compare this setting with a Vanilla setting the three models, and Llama-3.1-8B-Instruct even experiences where no reference documentation is provided, and evaluate negative growth in Pass@5. This demonstrates that the primary three mainstream open-source models on the NdonnxEval and performance bottleneck is no longer retrieval quality, but rather the model’s inability to effectively translate accurate API NumbaEval benchmarks. Empirical results in Table I reveal a stark reality: even information into correct and executable code. This phenomenon in an idealized state where retrieval errors are eliminated, suggests that static API documentation possesses significant the performance of existing models remains far below the limitations when handling complex private-library logic.
x Observation 1: Even with perfect retrieval, the information provided by static API documentation is inadequate to support models in completing complex private-library code generation.
Input: Goal: Convert input data to an array of a given shape filled with a specified… Failed Output: 1: def masked_fill_like(x, shape, fill_value, mask=None): 2: x_array = ndx.asarray(x) 3: … Runtime Error: ValueError: target rank must be equal or greater than rank of 'self' Reflection Prompts : L1: Summarize the missing task-level coordination pattern across multiple APIs from the failed code and feedback. L2: Distill the API-level parameter-role semantics violated in the failed execution.
We therefore conduct a case study on the failure cases under the Oracle setting to investigate why the model fails despite having complete API specifications,. As shown in Figure 1, we select the masked_fill_like task from NdonnxEval as a representative example. This task requires first constructing Output: a constant target tensor of a specified shape. It then uses a Task-Level Guideline: Ensure that the data input, mask, and constant-filled target are aligned together boolean mask to fill this constant where the mask is true, using ndonnx.broadcast_arrays before performing any masked selection operations. while retaining the original input data elsewhere. API-Level Guideline: When cond is true, a is selected; otherwise, b is selected. Through an in-depth analysis of numerous failure cases, Fig. 2. A reflection case on NdonnxEval with Qwen2.5-Coder-7B-Instruct. we find that the model’s errors are primarily manifested From failed code and execution feedback, the model derives task-level and at two levels, and the aforementioned representative case API-level Usage Guidelines. exposes both of these typical failure modes. First is the API coordination failure at the task-level. The model fails to Qwen2.5-Coder-7B for reflection. Experimental observations reuse ndonnx.broadcast_arrays provided by the Oracle to vealed that the model demonstrated outstanding self-correction jointly align the input data, mask, and target tensor. Instead, it and summarization capabilities: at the task level, it accurately extracts an internal function from the underlying source code identified the alignment gaps in multi-API collaboration and and erroneously performs a one-way ndonnx.broadcast_to summarized that ndonnx.broadcast_arrays must be used operation solely on the mask, disrupting the coordination work- before the execution selection operation for unified alignment; flow. Second is the misunderstanding of parameter semantics at the API level, it also precisely extracted the correct and constraints at the API-level. Specifically, when calling execution semantics of the conditional branches and parameter ndonnx.where(cond, a, b) , the model not only reverses roles in ndonnx.where . This performance of learning from the constant branch and the original data branch that should be feedback proves that we do not need to rely on costly manual selected when mask=True , but also ignores the strict implicit maintenance, but can achieve autonomous accumulation and constraint of this interface requiring the dimensions (rank) of evolution of private library practical experience through the the input tensors to be aligned. automated closed loop of ”generation – execution – feedback – To address the failure modes at these two levels, we reflection.” summarize the missing coordination patterns and interface usage details into specific Usage Guidelines and re-inject x Observation 3: While manual curation is unsustainable, LLMs can autonomously distill task-level and API-level knowledge them into the Oracle context for verification. Experiments from feedback, enabling an automated closed-loop for experience show that after adding these guidelines, the model successfully accumulation. corrects its previous invocation errors, recovers the correct API coordination pattern, and ultimately generates executable IV. M ETHODOLOGY code that passes all test cases. This stark contrast proves that supplementing explicit usage guidelines can effectively A. Overview compensate for the deficiencies of static documentation, thereby We propose MEMC ODER, a novel framework for privateimproving the performance of private-library code generation. library-oriented code generation featuring training-free, plug-and-play, and continual learning characteristics. Formally, x Observation 2: The model failure is due to the lack of task-level let L denote the target private library and D denote its static collaboration and the misunderstanding of API-level constraints; API documentation set. To manage the aforementioned Usage using the usage guide for injection can effectively correct errors Guidelines, MEMC ODER introduces a Multi-dimensional and improve performance. Evolving Memory M (Section IV-B), which systematically Although manually-written usage guidelines can significantly organizes and stores guidelines and their auxiliary code enhance performance, when dealing with large-scale and information across two dimensions: the task-level (MTask ) and rapidly evolving private libraries, relying on expert experience the API-level (MAPI ). As illustrated in Figure 3, MEMC ODER for manual annotation is not only costly but also unsustainable operates in a closed-loop workflow consisting of forward in actual production environments. Therefore, we further generation and backward evolution. explored whether the model has the ability to conduct During the forward phase, Guideline-Driven Code Generaself-reflection based on environmental feedback during testing tion (Section IV-C), MEMC ODER synthesizes the code solution and autonomously extract usage guidelines. ct for a given natural language requirement rt . Serving as a As shown in Figure 2, we reuse the masked_fill_like flexible extension to the conventional RAG pipeline, it employs failure case described previously and provided the initially a dual-source retrieval strategy: in addition to retrieving the generated error code and corresponding execution feedback to API documentation D, it retrieves relevant historical records
Guideline-Driven Code Generation
1.Retrieve via Requirement
Requirement
3.Retrieve via API docs
API Mem
5.Inject Mem
6.Generate Code
Task-level Memory - Requirement: Write a helper that computes …… - Used APIs: ndonnx.asarray, ndonnx.boradcast_arrays …… - Code: def masked_min_and_row_product(x, y, mask)… - Execution Feedback: Success - Usage Guideline: Use ndx.asarray for shape compatibility…
API-level Memory
9.Generate Mem
MEMCoder
7.Update Task-Level Mem
Execution Feedback
Index Layer
10.Update API-Level Mem
- API Name: ndonnx.asarray 11.Store Code Snipptes
Content Layer - API Documentation: ·Qualname: ndonnx.asarray ·Signature: (obj, ·Definition: def asarray(obj, ...): ...
...) -> Array
12.Update Usage Weights
- Code Snippet : {if isinstance(x,list):\n
[-] Deleted (Weight: 3) Note: Directly using a sequence of Arrays in 'asarray' causes errors; convert it to a single array first. ……
MEMCoder
13.Generate Usage Guideline
x = ndx.asarray(x)……} ……
- Usage Guideline: [+] Active (Weight: 77) Note: Always check if the input object is already an `Array` before copying to avoid unnecessary operations.
Code
Feedback-Driven Memory Evolution 8.Store Task Query
Index Layer Content Layer
2.Return Mem
Retrieved APIs 4.Retrieve
MEMCoder
Multi-dimensional Evolving Memory
14.Discard/Add /Deleted Usage Guideline
Fig. 3. Overview of the MEMC ODER framework. Middle: The Multi-dimensional Evolutionary Memory (IV-B) stores refined task-level and API-level memories. Left: The Guideline-Driven Code Generation pipeline (IV-C) retrieves these memories along with API docs to guide code generation. Right: The Feedback-Driven Memory Evolution module (IV-D) updates and optimizes the memory based on real-time execution feedback.
from MTask and matches corresponding Usage Guidelines from where the Index Layer consists of the historical natural MAPI for the candidate APIs. By injecting the documenta- language requirement r, which is embedded into a dense vector tion Drt ⊂ D and the retrieved multi-dimensional memory space for semantic similarity retrieval. The remaining elements Mrt ⊂ M into the context, the LLM directly generates constitute the Content Layer, storing the essential execution the final code ct . This ensures that the model masters the footprint and guidelines of this task: c is the generated code coordination strategies while understanding the API definitions. solution; f represents the runtime execution feedback (such as In the backward phase following generation, namely a success signal or error traceback); Aused is the specific set Feedback-Driven Memory Evolution (Section IV-D), the system of private APIs successfully invoked; and gTask is a concise, obtains objective feedback ft by executing ct to continuously natural-language usage guideline distilled by the reflector, update the memory M. By analyzing the execution trajectory, providing high-level intent and cross-API collaboration the LLM Reflector extracts new Usage Guidelines and updates patterns that are often absent in static API documentation. (2) API-Level Memory (MAPI ). While task-level memory the contents and weights of the existing memory M. Through this closed-loop evolution, MEMC ODER achieves continual addresses orchestration, API-level memory is dedicated to execution fidelity by capturing individual API usage constraints capability enhancement without parameter updates. and failure modes. Formally, an API-level memory entry is defined as: B. Multi-dimensional Evolving Memory mAPI = ⟨a, Da , Ca , Ga ⟩, (2) To systematically store and manage the Usage Guidelines where the Index Layer is anchored by the unique API name automatically generated by the LLM, we construct a Multia. The Content Layer maintains an evolving profile of the dimensional Evolving Memory M. As detailed in the middle API, comprising: Da , which represents the static baseline API block of Figure 3, to balance efficient retrieval matching documentation (including signature and source code); Ca , a with rich generative context, every memory entry in our repository of concrete code snippets exclusively relevant to framework is organized into two components: an Index Layer this API that records successful invocations and failed attempts designed for semantic search, and a Content Layer designed along with their runtime error messages; and Ga , a dynamic for prompt injection. We instantiate this architecture across collection of extracted usage guidelines. Each guideline g ∈ Ga two complementary dimensions: task-level and API-level. is associated with a dynamic weight w, enabling the framework (1) Task-Level Memory (MTask ). Task-level memory is to effectively manage and refine the pool of available guidelines. designed to capture cross-API orchestration strategies, teaching the model how to coordinate multiple APIs to fulfill a specific C. Guideline-Driven Code Generation With the M established, this section details the forward user requirement. Formally, a task-level memory entry is pass of MEMC ODER. As illustrated in Figure 3, the code defined as a tuple: generation process is disentangled into two sequential stages: mTask = ⟨r, c, f, Aused , gTask ⟩, (1) dual-source API retrieval and context-augmented generation.
(1) Dual-Source API Retrieval. Existing RAG-based methods typically use the natural language requirement rt (or decomposed sub-requirements) to retrieve API documentation D. However, this cross-modal matching between requirements and code signatures often suffers from semantic gaps. As a plug-and-play framework, MEMC ODER augments the existing RAG pipeline with an additional retrieval path that leverages historical task guidelines via task-to-task semantic matching. Specifically, given the current requirement rt , we first retrieve the Ktask most similar historical tasks from MTask : Mrt = Top-Ktask sim(rt , m.r),
(3)
m∈MTask
where sim(·, ·) denotes the semantic similarity score. By extracting the historically verified APIs (m.Aused ) from these retrieved entries, we identify a set of candidate APIs that have successfully resolved similar requirements. Concurrently, we follow the existing RAG-based method to retrieve Kdoc APIs directly from the documentation D, denoted as Adoc . To ensure high recall, the final candidate API set Acand is constructed by taking the union of the explicitly retrieved documentation APIs (Adoc ) and the S implicitly verified APIs extracted from the retrieved tasks ( m∈Mr m.Aused ). t (2) Context-Augmented Generation. To ensure the LLM understands how to orchestrate the identified APIs, MEMC ODER further retrieves the corresponding API-level (a) memory entry mAPI for each a ∈ Acand . We then construct a structured context Ct by concatenating the multi-dimensional memory components with the requirement: h i (a) Ct = m.c, m.f, m.gTask m ; mAPI a ; rt , (4) where [ · ; · ] denotes sequence concatenation, and m ∈ Mrt represents each retrieved task-level memory entry. In this unified context Ct , the API-level usage guidelines and code snippets prevent common invocation errors, while the task-level guidelines provide cross-API orchestration strategies. Finally, the LLM takes Ct as input to synthesize the code ct . By conditioning on both dimensions of evolving memory, MEMC ODER effectively improves the accuracy of private-library-oriented code generation. D. Feedback-Driven Memory Evolution In the backward phase following generation, MEMC ODER executes the generated code ct to obtain objective feedback ft ∈ {Success, Failure}. The primary objective of this evolution phase is to build a generalizable and actionable knowledge base by distilling the execution trajectory (ct , ft ) into concise Usage Guidelines. While raw code snippets and their execution outcomes are concurrently archived into Ca to serve as fewshot demonstrations, the LLM Reflector focuses on evolving the existing memory M through two core mechanisms: guideline refinement and dynamic weight updating. (1) Guideline Extraction and Refinement. Upon receiving ft , the reflector first updates the task-level memory MTask . It identifies the APIs Act invoked in the generated code ct , filtering out any APIs not present in the official documentation
D. Guided by ft , the reflector distills a task-level usage guideline gTask . This reflection explicitly analyzes the combinatorial relationships, data dependencies, and execution order among the invoked APIs, identifying robust coordination patterns or diagnosing conflicting usage that led to failure. The new memory entry mTask is then appended to MTask . For API-level knowledge, MEMC ODER introduces a refinement protocol to maintain MAPI . For each invoked API a ∈ Act , the reflector generates a candidate guideline ĝ detailing technical nuances that contributed to the outcome. To prevent memory bloat and resolve knowledge conflicts, the reflector evaluates ĝ against the documentation Da and existing guidelines Ga via three routing actions: • Discard: If ĝ is redundant or already covered by Da , it is discarded to maintain memory compactness. • Delete: If ĝ invalidates an existing guideline in Ga (e.g., correcting an outdated workaround), the obsolete entry is marked for deletion. • Add: If ĝ represents a novel, verified insight, it is added to Ga with an initialized weight. (2) Dynamic Weight Updating. To handle the varying reliability of distilled knowledge across different contexts, MEMC ODER implements a feedback-driven credit assignment mechanism for Ga . When a new usage guideline is first extracted and added to the memory, it is assigned an initial positive weight winit . During the retrieval phase, guidelines are prioritized and selected based on their current weights. To evaluate the utility of these insights, we track the specific subset of guidelines Gused ⊆ Ga that were injected into the context Ct for a given task. Once the execution feedback ft is obtained, MEMC ODER dynamically adjusts the weight wt of each guideline g ∈ Gused to compute its updated weight wt+1 : ( wt + ∆w+ , if ft = Success, wt+1 = (5) − max(wmin , wt − ∆w ), if ft = Failure, where ∆w+ and ∆w− are the reward and penalty step sizes respectively, and wmin > 0 acts as a strict floor threshold for weight degradation. Instead of physically erasing penalized guidelines, they are retained in the memory with the lowest retrieval priority bounded by wmin to prevent the model from repeating past mistakes. V. E XPERIMENTAL S ETUP To assess the effectiveness of MEMC ODER, we conduct a comprehensive study designed to address four key Research Questions (RQs). This section details our experimental configuration, including the formal definition of RQs, the benchmarks utilized for evaluation, the selection of metrics, the competitive baselines across different categories, the large language models (LLMs) employed, and specific implementation details regarding retrieval and memory management. A. Research Questions Our study aims to answer the following RQs. RQ1: How effective is MEMC ODER in improving privatelibrary-oriented code generation? This research question
evaluates the practical utility of MEMC ODER as a plug-andplay enhancement for existing RAG systems. By applying MEMC ODER to established baselines, we examine whether augmenting static API documentation with our evolving Usage Guidelines leads to measurable performance gains. This analysis allows us to verify if the autonomous accumulation of task-level and API-level guidelines can successfully bridge the knowledge gap that static documentation fails to address. RQ2: How does MEMC ODER perform in private-libraryoriented code generation compared to existing CL-based methods? To evaluate MEMC ODER’s evolving capability, we adapt representative memory-based CL methods to the private-library code generation task as baselines. By comparing them across a continuous stream of tasks, we assess whether our method provides superior adaptation and domain-specific knowledge retention for evolving private libraries. RQ3: What are the individual contributions of the core components in MEMC ODER? To dissect the inner workings of MEMC ODER, we conduct comprehensive ablation studies to evaluate its multi-dimensional memory and feedback-driven evolution. Specifically, we isolate the impact of task-level and API-level memory, and compare our dynamic memory refinement against a naive first-in-first-out accumulation baseline (MEMC ODER-Accum). B. Benchmarks We evaluate MEMC ODER on two specialized benchmarks designed for private-library-oriented code generation: NdonnxEval and NumbaEval [11]. Since real-world private libraries are proprietary and inaccessible for public research, we utilize these benchmarks to simulate private-library scenarios. These benchmarks target libraries released in 2024 and significantly developed throughout 2025, ensuring their latest APIs are absent from the training corpora of the models released before these dates to mitigate data contamination. • NdonnxEval. This benchmark evaluates code generation using the ndonnx library, an ONNX-based tensor library. It consists of 169 manually curated programming instances. On average, each instance requires the coordinated invocation of more than 4 distinct APIs and is rigorously verified by over 9 unit tests to ensure functional correctness. • NumbaEval. This benchmark focuses on code generation with the numba-cuda library, which is used for highperformance CUDA JIT compilation. It contains 187 manually curated instances involving complex algorithmic requirements. Following the same rigorous construction standards as NdonnxEval, each instance requires the coordinated use of more than 4 distinct APIs on average and is verified by over 9 unit tests to ensure high quality and solvability. C. Metrics We use functional correctness and efficiency as our main evaluation metrics. To reduce randomness and obtain more reliable estimates, we compute the functional metrics using standard unbiased estimators.
•
Pass@k (k ∈ {1, 3, 5}). For each instance, we sample n ≥ k candidate solutions (we use n = 10), execute the provided test cases, and count the number of passing solutions c. Following prior work [39, 40], we compute Pass@k using the unbiased estimator: " # Pass@k = Einstances 1 −
•
n−c k n k
.
(6)
Exec@k (k ∈ {1, 3, 5}). As models often misuse private APIs and trigger runtime failures, we report Exec@k to measure basic executability. It is defined analogously to Pass@k, except that a solution is counted as successful if it runs to completion on the test inputs without raising any runtime exceptions.
D. Baselines We establish a diverse set of baselines to comprehensively evaluate MEMC ODER across our research questions. These baselines can be divided into two main categories: existing retrieval-augmented generation (RAG) approaches designed for private-library code generation, and representative memory-based Continual Learning (CL) frameworks. (1) RAG-based Methods: To evaluate the enhancement capability of our framework, we select three representative RAG pipelines as backbones, comparing their performance both with and without the integration of MEMC ODER. Naive RAG [6, 7] represents the standard RAG paradigm, which embeds the comprehensive API documentation, retrieves relevant APIs based on the task requirement, and directly injects their static specifications into the prompt. EpiGen [8] introduces a taskoriented retrieval strategy by utilizing an LLM to decompose complex requirements into fine-grained subtasks, performing independent API retrieval for each subtask to enhance the relevance of the injected documentation. CAPIR [37] further optimizes the retrieval precision by leveraging an LLM to rerank and filter the retrieved candidate APIs, effectively reducing context redundancy before final code generation. By integrating MEMC ODER into these diverse backbones, we assess whether our multi-dimensional Usage Guidelines can consistently provide performance gains across different RAG architectures. (2) CL-based Methods: To assess the evolving capability of our approach over a continuous stream of tasks, we compare it against two representative memory-based CL methods. Since there are currently no CL frameworks specifically tailored for evolving private libraries, we carefully adapt them to our task scenario. To ensure a fair comparison, all CL baselines are initially equipped with a Naive RAG module to retrieve and inject the top-K relevant APIs for each task. Dynamic Cheatsheet (DC-RS) [38] introduces an adaptive external memory to accumulate reusable problem-solving strategies and code snippets across tasks. Specifically, it retrieves relevant historical requirement-generation pairs and employs an LLM curator to synthesize a task-specific cheat sheet prior to generation, notably curating memory from its own past outputs without requiring ground-truth execution feedback. ReMem [13] serves as a task-level retrieval agent that stores
historical requirements, generated outputs, and execution feedback as unified memory entries. For a new task, it introduces a dynamic “Think-Act-Refine” decision loop, empowering the LLM to actively evaluate and reorganize the most similar retrieved experiences before generating the final code. These adapted baselines allow us to evaluate whether MEMC ODER provides superior adaptation and domain-specific knowledge retention compared to existing continual learning paradigms. E. Models Given the strict confidentiality and data privacy requirements inherent in private-library development, enterprise code generation systems are typically deployed on-premise. Therefore, we evaluate MEMC ODER using three widely adopted, high-performance open-source large language models (LLMs) that are highly suitable for local deployment: Qwen2.5Coder-7B-Instruct [12], Llama-3.1-8B-Instruct [21], and DeepSeek-Coder-6.7B-Instruct [26]. These models represent the state-of-the-art in open-source code intelligence at the 7B-8B parameter scale. Crucially, the official knowledge cutoffs of these models precede the release of the latest APIs evaluated in NdonnxEval and NumbaEval, thereby strictly preventing any potential data leakage during their pre-training phases. For brevity, we hereafter refer to them as Qwen2.5-Coder, Llama-3.1, and DeepSeek-Coder. F. Implementation Details We deploy all evaluated Large Language Models locally and maintain strict consistency in inference hyperparameters. For code generation in the main evaluations (RQ1 and RQ2), we set the maximum generation length to 4096 tokens, the sampling temperature to 0.7, and top_p to 0.95. For the ablation study (RQ3), we evaluate Qwen-7B by reporting pass@5 and exec@5 to provide a more robust assessment of the individual contributions of our framework’s core components. For all modules and baselines that involve semantic similarity retrieval, we uniformly employ bge-base-en-v1.5 as the core embedding model. Regarding the retrieval configurations, any component relying on API documentation retrieval (including the Naive RAG modules equipped in the CL baselines) is set to retrieve the top-5 most relevant APIs. For our proposed MEMC ODER, memory retrieval is performed at both the task and API levels. For each candidate API, the framework retrieves 1 successful code snippet as a few-shot demonstration, along with 3 Usage Guidelines that encapsulate reflections distilled from both successful and failed execution feedback. In contrast, for the existing continual learning baselines (DC-RS, ExpRAG, and ReMem), the retrieval module is configured to fetch the top-3 most similar historical interaction traces for each new requirement. VI. E XPERIMENTAL R ESULTS A. RQ1: Effectiveness of MEMCoder in Private-Library Code Generation This research question evaluates the practical effectiveness of MEMC ODER in enhancing existing RAG systems. We
integrate MEMC ODER into three representative RAG backbones (Naive RAG, EpiGen, and CAPIR) and measure the performance growth across multiple LLMs. Results. The results for all RAG-based approaches are reported in Table II. ❶ MEMCoder consistently yields substantial performance gains across all evaluated RAG backbones. As shown in Table II, regardless of the backbone or the underlying model, the integration of MEMC ODER leads to a significant leap in correctness. For instance, on the NdonnxEval benchmark, MEMC ODER improves the pass@1 of Naive RAG, EpiGen, and CAPIR by 25.32%, 18.46%, and 19.23% respectively using Qwen2.5-Coder. These universal gains demonstrate that MEMC ODER serves as a robust enhancement framework for any documentation-based retrieval pipeline. ❷ MEMCoder surpasses the benefits of complex retrieval optimization strategies. Empirical comparisons show that Naive RAG combined with MEMC ODER achieves superior performance to standalone advanced RAG methods. For example, on NumbaEval with Llama-3.1, Naive RAG +MEMC ODER achieves a pass@1 of 28.72%, whereas EpiGen and CAPIR only reach 7.86% and 5.72%, respectively. This indicates that the task-level and API-level memory stored in MEMC ODER provide more effective guidance for code generation than the task decomposition or reranking mechanisms used in existing pipelines. Answer to RQ1: MEMC ODER significantly enhances RAG systems, outperforming complex retrieval strategies by injecting tasklevel and API-level memory to supplement static documentation.
B. RQ2: Effectiveness Compared to CL-based Methods This research question evaluates the evolving capability of MEMC ODER across a continuous task stream, comparing it with representative memory-based Continual Learning (CL) methods: DC-RS and ReMem. All methods process tasks sequentially and evolve their memory via execution feedback. Results. Table III presents the performance across CL baselines. ❶ MEMC ODER demonstrates superior knowledge retention and adaptation in most scenarios. As shown in Table III, MEMC ODER consistently achieves higher functional correctness than existing CL baselines across the majority of configurations. For Qwen2.5-Coder on NumbaEval, MEMC ODER achieves a pass@1 of 33.74%, significantly outperforming DC-RS (17.33%) and ReMem (23.16%). On Llama-3.1, MEMC ODER maintains a decisive lead on both benchmarks; notably on NumbaEval, its pass@1 (28.72%) is several times higher than that of ReMem (3.10%). This indicates that our Multi-dimensional Evolving Memory structure generalizes better than raw dialogue logs or simple experience stacking when handling complex library logic. ❷ By distilling guidelines from execution feedback, MEMC ODER achieves more robust evolving effects. The stability of MEMC ODER is particularly evident in exec@1. For instance, on NumbaEval with Llama-3.1, MEMC ODER’s exec@1 reaches 63.21%, while all baseline methods remain
TABLE II P ERFORMANCE COMPARISON WITH RAG- BASED BASELINES IN TERMS OF pass@k AND exec@k (%) ON NdonnxEval AND NumbaEval.
Model
NdonnxEval
Method
NumbaEval
pass@1 pass@3 pass@5 exec@1 exec@3 exec@5 pass@1 pass@3 pass@5 exec@1 exec@3 exec@5 Naive RAG +MEMC ODER EpiGen +MEMC ODER CAPIR +MEMC ODER
27.22 52.54 23.49 41.95 30.89 50.12
41.16 64.96 38.41 53.83 45.24 62.26
47.39 69.42 45.34 58.57 50.85 66.79
34.32 60.71 30.41 52.19 38.76 63.37
50.34 71.92 48.13 64.50 56.21 76.14
56.64 75.87 55.53 68.89 62.78 80.82
23.16 33.74 19.73 30.05 20.91 32.67
40.04 46.91 36.19 40.60 36.84 43.37
48.09 52.41 44.63 44.53 43.83 48.37
40.27 54.87 34.44 46.95 36.15 51.12
66.37 71.62 59.90 63.55 63.14 66.93
76.82 76.84 71.10 68.86 73.92 71.67
Naive RAG +MEMC ODER EpiGen Llama-3.1 +MEMC ODER CAPIR +MEMC ODER
11.95 20.41 12.31 19.11 13.37 19.29
20.90 30.46 22.14 30.25 22.11 28.89
25.80 34.92 27.17 35.52 26.72 33.43
24.85 36.39 21.72 33.20 23.08 32.37
42.64 51.16 37.13 49.09 37.20 45.52
51.23 57.11 44.19 55.67 44.07 50.61
5.61 28.72 7.86 24.33 5.72 24.92
13.98 39.69 17.41 34.49 13.95 35.13
20.12 44.69 23.04 38.71 19.42 39.47
22.57 63.21 25.88 51.44 22.25 50.53
47.66 79.95 53.65 69.34 48.62 69.50
61.47 85.07 67.59 75.65 62.78 75.88
Naive RAG +MEMC ODER EpiGen +MEMC ODER CAPIR +MEMC ODER
24.26 44.44 30.00 42.90 25.44 43.79
40.13 56.35 44.91 54.16 39.95 54.80
48.29 60.09 50.31 58.08 45.81 58.42
35.68 53.55 39.11 52.49 32.84 55.09
54.72 66.67 56.30 66.12 51.45 66.67
62.60 70.82 62.13 70.70 59.31 70.67
7.86 32.25 10.05 30.70 10.75 32.30
18.36 46.08 22.18 44.42 23.51 44.51
25.63 51.70 29.84 49.40 31.48 48.99
17.59 55.08 20.80 54.65 21.02 55.99
39.49 75.03 45.31 73.78 44.10 76.83
52.70 81.93 59.53 79.29 57.24 82.54
Qwen2.5 -Coder
DeepSeek -Coder
Results. The results for pass@5 and exec@5 are detailed in Table IV. ❶ Both Task-level and API-level evolving memory are indispensable for accurate code generation. Removing either memory dimension leads to distinct performance degradation. When MTask is removed (MEMC ODER w/o MTask ), the model loses its ability to leverage historically verified orchestration patterns, causing pass@5 to drop to 58.66% on NdonnxEval and 46.34% Answer to RQ2: MEMC ODER outperforms memory-based CL on NumbaEval. More critically, removing MAPI (MEMC ODER methods by evolving its Multi-dimensional Evolving Memory, w/o MAPI ) results in a catastrophic collapse in execution enabling superior adaptation and execution correctness. fidelity. On NdonnxEval, pass@5 plummets from 69.42% to 38.12%, and exec@5 drops to 45.44%. This confirms that static C. RQ3: Ablation Study documentation D is insufficient for preventing execution errors, MEMC ODER introduces a Multi-dimensional Evolving Mem- highlighting the immense value of our extracted API-level ory architecture and a feedback-driven evolution mechanism. guidelines Ga and snippets Ca in ensuring execution fidelity. This RQ conducts comprehensive ablation studies to dissect ❷ Feedback-driven evolution is strictly superior to the individual contributions of these core components using naive accumulation. Comparing Full MEMC ODER with Qwen2.5-Coder. MEMC ODER-Accum reveals the necessity of our refinement Setting. We design three experimental variants to evaluate the protocol. Under the naive accumulation strategy, the model necessity of our memory layers and refinement protocol: (1) directly appends raw trajectories without distilling guidelines, MEMC ODER w/o MTask : Disabling the task-level evolving leading to severe knowledge collision. This causes pass@5 memory. This removes the retrieved historical code solutions on NdonnxEval to drop dramatically from 69.42% to 39.09%, m.c and orchestration guidelines gTask from the context, thereby performing similarly to removing the API memory entirely. losing cross-API collaboration strategies. (2) MEMC ODER In the more complex NumbaEval tasks, MEMC ODER-Accum w/o MAPI : Removing the API-level evolving memory. This achieves an exec@5 of only 59.44%, while Full MEMC ODER omits the specific usage guidelines Ga and execution-derived reaches 76.84%. These results demonstrate that distilling raw code snippets Ca for each candidate API, providing only feedback into structured guidelines is essential for maintaining the static baseline documentation Da . (3) MEMC ODER- a noise-free and effective evolving memory. Accum: Replacing the feedback-driven evolution (the Reflector’s Answer to RQ3: Multi-dimensional Evolving Memory ensures distillation and weight updating) with a naive first-in-first-out orchestration and execution fidelity. Feedback-driven evolution (FIFO) accumulation. All raw execution trajectories are directly justifies its complexity by distilling trajectories into high-density appended as Ca without extracting high-density guidelines Ga guidelines, vastly outperforming naive accumulation. or resolving knowledge conflicts. below 20.36%. This confirms that our framework effectively guides the model to avoid repetitive pitfalls and correct deep-seated invocation errors. In contrast, the static cheat sheets in DC-RS or the simple retrieval mechanism in ReMem often fail to resolve complex library constraints due to the lack of explicit reflections on execution failures, making it difficult for the model to recover from erroneous states.
TABLE III P ERFORMANCE COMPARISON WITH CL-BASED BASELINES IN TERMS OF pass@k AND exec@k (%) ON NdonnxEval AND NumbaEval
Model
NdonnxEval
Method
NumbaEval
pass@1 pass@3 pass@5 exec@1 exec@3 exec@5 pass@1 pass@3 pass@5 exec@1 exec@3 exec@5 ReMem DC-RS MEMC ODER
24.67 19.11 52.54
37.33 38.20 64.96
42.44 47.35 69.42
32.07 25.38 60.71
48.30 48.26 71.92
55.01 58.04 75.87
23.16 17.33 33.74
40.12 31.67 46.91
48.48 38.57 52.41
44.55 34.55 54.87
72.13 61.05 71.62
81.37 70.89 76.84
ReMem Llama-3.1 DC-RS MEMC ODER
8.17 7.87 20.41
16.23 17.51 30.46
20.83 22.99 34.92
20.36 14.62 36.39
36.95 31.97 51.16
44.72 41.63 57.11
3.10 1.93 28.72
8.34 5.02 39.69
12.66 7.49 44.69
19.79 11.28 63.21
45.14 26.21 79.95
59.98 35.71 85.07
ReMem DC-RS MEMC ODER
28.11 18.52 44.44
47.83 33.58 56.35
55.74 40.33 60.09
42.43 32.84 53.55
67.22 54.70 66.67
75.83 62.90 70.82
10.53 6.52 32.25
23.43 16.37 46.08
31.16 23.43 51.70
22.89 15.99 55.08
49.24 38.11 75.03
63.42 52.36 81.93
Qwen2.5 -Coder
DeepSeek -Coder
TABLE IV A BLATION STUDY OF MEMC ODER ON NdonnxEval AND NumbaEval USING Q W E N 2.5-C O D E R
Setting MEMC ODER w/o MAPI MEMC ODER w/o MTask MEMC ODER-Accum Full MEMC ODER
NdonnxEval
NumbaEval
pass@5
exec@5
pass@5
exec@5
38.12 58.66 39.09 69.42
45.44 67.79 59.44 75.87
46.33 46.34 37.93 52.41
72.28 66.09 59.44 76.84
study in Section VI-C, this evolving management mechanism significantly outperforms MEMC ODER-Accum. This proves that MEMC ODER can effectively mitigate knowledge conflicts during long-term accumulation while maintaining high knowledge density, thereby ensuring the robustness of the system. VIII. C ONCLUSION
In this paper, we address the challenge of Private-LibraryOriented Code Generation, where LLMs struggle due to the absence of proprietary APIs in their pre-training data. Our VII. D ISCUSSION motivation study reveals that even with perfect retrieval of static Threats to Validity. In this section, we summarize the identified API documentation, models frequently fail due to a lack of tasklevel coordination patterns and API-level execution constraints. potential threats and limitations of our study as follows: ❶ Computational Overhead and Inference Efficiency. A To bridge this gap, we propose MEMC ODER, a training-free potential challenge for MEMC ODER is the additional com- and plug-and-play framework that extends the retrieval source putational overhead introduced by the Guideline-Driven Code from static documents to evolving Usage Guidelines. The core of MEMC ODER is a Multi-dimensional Evolving Generation and Feedback-Driven Memory Evolution phases. The framework requires injecting relevant memories into the Memory that systematically organizes task-level and API-level context during forward inference and performing guideline Usage Guidelines distilled from runtime feedback. Through a extraction and refinement in the backward phase, which closed-loop mechanism of execution, reflection, and refinement, inevitably leads to higher token consumption compared to MEMC ODER autonomously accumulates these guidelines naive RAG. Taking the NumbaEval benchmark as an example, to explicitly guide the model and prevent execution traps. MEMC ODER consumes an average of 17,111 additional total Extensive experiments on the NdonnxEval and NumbaEval tokens per task. Based on current mainstream LLM pricing, the benchmarks demonstrate that MEMC ODER consistently extra cost to process the entire NumbaEval benchmark (187 and significantly improves the performance of various RAG tasks) is approximately $0.46. These results demonstrate that backbones and outperforms existing memory-based continual the overhead of MEMC ODER is highly acceptable in practical learning methods. By enabling the autonomous accumulation and reuse of programming knowledge, MEMC ODER provides production environments. ❷ Knowledge Conflict and Bloat in Long-term Memory. As a robust and evolving solution for code generation in private the task stream extends, the volume of evolving memory con- software ecosystems. tinues to grow, potentially posing threats to retrieval efficiency R EFERENCES and knowledge consistency. However, MEMC ODER adopts differentiated management strategies for different memory [1] J. Li, G. Li, Y. Li, and Z. Jin, “Structured chain-of-thought dimensions. For task-level memory, continuous accumulaprompting for code generation,” ACM Transactions on tion is essential as it increases the probability of matching Software Engineering and Methodology, vol. 34, no. 2, historical tasks similar to new requirements. For API-level pp. 1–23, 2025. memory, the static documentation does not accumulate over [2] S. Jiang, J. Li, H. Zong, H. Liu, H. Zhu, S. Hu, E. Li, time, and code snippets are managed by retaining only the J. Ding, Y. Han, W. Ning, et al., “aixcoder-7b: A latest execution records to achieve logic coverage rather than lightweight and effective large language model for code full injection. Furthermore, Usage Guidelines are managed processing,” in 2025 IEEE/ACM 47th International Conthrough a specialized refinement protocol, including Discard, ference on Software Engineering: Software Engineering Add, and Delete actions. As demonstrated by the ablation in Practice (ICSE-SEIP), pp. 215–226, IEEE, 2025.
[3] C. Li, Y. Zhang, J. Li, L. Cai, and G. Li, “Beyond autoregression: An empirical study of diffusion large language models for code generation,” arXiv preprint arXiv:2509.11252, 2025. [4] L. Cai, Y. Ren, Y. Zhang, and J. Li, “Ai-driven selfevolving software: A promising path toward software automation,” arXiv preprint arXiv:2510.00591, 2025. [5] Y. Wang, Y. Zhang, Z. Qin, C. Zhi, B. Li, F. Huang, Y. Li, and S. Deng, “Exploracoder: Advancing code generation for multiple unseen apis via planning and chained exploration,” in Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 18124–18145, 2025. [6] D. Zan, B. Chen, Z. Lin, B. Guan, W. Yongji, and J.-G. Lou, “When language model meets private library,” in Findings of the Association for Computational Linguistics: EMNLP 2022, pp. 277–288, 2022. [7] S. Zhou, U. Alon, F. F. Xu, Z. Jiang, and G. Neubig, “Docprompting: Generating code by retrieving the docs,” in The Eleventh International Conference on Learning Representations, 2022. [8] S. Li, S. Li, H. Zhang, S. Li, K. Chen, J. Yuan, Y. Cao, and L. Yang, “Epigen: An efficient multi-api code generation framework under enterprise scenario,” in Proceedings of the 2024 Joint International Conference on Computational Linguistics, Language Resources and Evaluation (LRECCOLING 2024), pp. 6206–6215, 2024. [9] QuantCo, “ndonnx (version 0.17.1).” https://pypi.org/pro ject/ndonnx/0.17.1/, 2025. [10] NVIDIA, “numba-cuda (version 0.27.0).” https://pypi.org /project/numba-cuda/0.27.0/, 2026. [11] Y. Zhang, C. Li, R. Chen, G. Yang, X. Jia, Y. Ren, and J. Li, “To see is not to master: Teaching llms to use private libraries for code generation,” 2026. [12] B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Dang, A. Yang, R. Men, F. Huang, X. Ren, X. Ren, J. Zhou, and J. Lin, “Qwen2.5-coder technical report,” CoRR, vol. abs/2409.12186, 2024. [13] T. Wei, N. Sachdeva, B. Coleman, Z. He, Y. Bei, X. Ning, M. Ai, Y. Li, J. He, E. H. Chi, C. Wang, S. Chen, F. Pereira, W.-C. Kang, and D. Z. Cheng, “Evo-memory: Benchmarking llm agent test-time learning with selfevolving memory,” 2025. [14] C. Qian, W. Liu, H. Liu, N. Chen, Y. Dang, J. Li, C. Yang, W. Chen, Y. Su, X. Cong, et al., “Chatdev: Communicative agents for software development,” in Proceedings of the 62nd annual meeting of the association for computational linguistics (volume 1: Long papers), pp. 15174–15186, 2024. [15] L. Li, R. Wang, H. Song, Y. Mao, T. Zhang, Y. Wang, J. Fan, Y. Zhang, J. Ye, C. Zhang, et al., “What papers don’t tell you: Recovering tacit knowledge for automated paper reproduction,” arXiv preprint arXiv:2603.01801, 2026. [16] Y. Zhang, Y. Li, Y. Liu, J. Li, X. Jia, Z. Li, and G. Li, “Lookahead-then-verify: Reliable constrained decoding
for diffusion llms under context-free grammars,” arXiv preprint arXiv:2602.00612, 2026. [17] J. Li, Y. Zhao, Y. Li, G. Li, and Z. Jin, “Acecoder: An effective prompting technique specialized in code generation,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 8, pp. 1–26, 2024. [18] L. Yang, Y. Liu, Y. Zhang, and J. Li, “Difftester: Accelerating unit test generation for diffusion llms via repetitive pattern,” arXiv preprint arXiv:2509.24975, 2025. [19] A. Singh, A. Fry, A. Perelman, A. Tart, A. Ganesh, A. El-Kishky, A. McLaughlin, A. Low, A. Ostrow, A. Ananthram, et al., “Openai gpt-5 system card,” arXiv preprint arXiv:2601.03267, 2025. [20] A. Hurst, A. Lerer, A. P. Goucher, A. Perelman, A. Ramesh, A. Clark, A. Ostrow, A. Welihinda, A. Hayes, A. Radford, et al., “Gpt-4o system card,” arXiv preprint arXiv:2410.21276, 2024. [21] A. Grattafiori, A. Dubey, A. Jauhri, A. Pandey, A. Kadian, A. Al-Dahle, A. Letman, A. Mathur, A. Schelten, A. Vaughan, et al., “The llama 3 herd of models,” arXiv preprint arXiv:2407.21783, 2024. [22] B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, R. Sauvestre, T. Remez, et al., “Code llama: Open foundation models for code,” arXiv preprint arXiv:2308.12950, 2023. [23] A. Yang, A. Li, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Gao, C. Huang, C. Lv, et al., “Qwen3 technical report,” arXiv preprint arXiv:2505.09388, 2025. [24] B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Lu, et al., “Qwen2. 5-coder technical report,” arXiv preprint arXiv:2409.12186, 2024. [25] A. Liu, B. Feng, B. Xue, B. Wang, B. Wu, C. Lu, C. Zhao, C. Deng, C. Zhang, C. Ruan, et al., “Deepseekv3 technical report,” arXiv preprint arXiv:2412.19437, 2024. [26] D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. Li, et al., “Deepseek-coder: when the large language model meets programming–the rise of code intelligence,” arXiv preprint arXiv:2401.14196, 2024. [27] C. Wang, Z. Chu, Z. Cheng, X. Yang, K. Qiu, Y. Wan, Z. Zhao, X. Shi, and D. Chen, “Codesync: Synchronizing large language models with dynamic code evolution at scale,” arXiv preprint arXiv:2502.16645, 2025. [28] G. Ou, Q. Zhang, S. Chen, A. Li, D. Xu, T. Luo, D. Dai, C. Gao, L. Wang, J. Zhou, M. Liu, and Z. Zheng, “Unseencodebases-domain data synthesis and training based on code graphs,” 2026. [29] D. Zan, A. Yu, B. Shen, B. Chen, W. Li, Y. Gong, X. Chen, Y. Yao, W. Luo, B. Guan, et al., “Diffcoder: Enhancing large language model on api invocation via analogical code exercises,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 406–426, 2024. [30] X. Gu, M. Chen, Y. Lin, Y. Hu, H. Zhang, C. Wan, Z. Wei, Y. Xu, and J. Wang, “On the effectiveness of large language models in domain-specific code generation,” ACM
Transactions on Software Engineering and Methodology, vol. 34, no. 3, pp. 1–22, 2025. [31] J. Liu, Y. Zhang, D. Wang, Y. Li, and W. Dong, “Think: Tackling api hallucinations in llms via injecting knowledge,” in 2025 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 229–240, IEEE, 2025. [32] M. Liu, T. Yang, Y. Lou, X. Du, Y. Wang, and X. Peng, “Codegen4libs: A two-stage approach for library-oriented code generation,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 434–445, IEEE, 2023. [33] D. Zan, B. Chen, Y. Gong, J. Cao, F. Zhang, B. Wu, B. Guan, Y. Yin, and Y. Wang, “Private-library-oriented code generation with large language models,” KnowledgeBased Systems, vol. 326, p. 113934, 2025. [34] H. Li, L. Ding, M. Fang, and D. Tao, “Revisiting catastrophic forgetting in large language model tuning,” 2024. [35] Y. Luo, Z. Yang, F. Meng, Y. Li, J. Zhou, and Y. Zhang, “An empirical study of catastrophic forgetting in large language models during continual fine-tuning,” 2025. [36] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Küttler, M. Lewis, W.-t. Yih, T. Rocktäschel, et al., “Retrieval-augmented generation for knowledgeintensive nlp tasks,” Advances in neural information processing systems, vol. 33, pp. 9459–9474, 2020. [37] Z. Ma, S. An, B. Xie, and Z. Lin, “Compositional api recommendation for library-oriented code generation,” in Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension, pp. 87–98, 2024. [38] M. Suzgun, M. Yuksekgonul, F. Bianchi, D. Jurafsky, and J. Zou, “Dynamic cheatsheet: Test-time learning with adaptive memory,” 2025. [39] B. Chen, F. Zhang, A. Nguyen, D. Zan, Z. Lin, J.-G. Lou, and W. Chen, “Codet: Code generation with generated tests,” arXiv preprint arXiv:2207.10397, 2022. [40] B. Athiwaratkun, S. K. Gouda, Z. Wang, X. Li, Y. Tian, M. Tan, W. U. Ahmad, S. Wang, Q. Sun, M. Shang, et al., “Multi-lingual evaluation of code generation models,” arXiv preprint arXiv:2210.14868, 2022.