Wired for Reuse: Automating Context-Aware Code Adaptation in IDEs via LLM-Based Agent

The overview of WIRL is illustrated in Fig. 2. WIRL consists of three core components: an LLM, a customized toolkit containing three types of tools, i.e., locator, collector, and completer, and an agent pilot, which orchestrates communication between the LLM and the toolkit by parsing outputs, updating prompts, and executing tool invocations. Given a piece of isolated code, the agent pilot begins by initializing the prompt (Step 1). This prompt includes system roles, task descriptions, and instructions on how the task should be addressed using the available tools. It also embeds the location of unresolved elements and results from preliminary analyses. Using this prompt, the agent pilot issues a request to the LLM (Step 2). The LLM responds by specifying a tool to invoke from the customized toolkit (Step 3). The agent pilot then parses the response and executes the corresponding tool with the appropriate arguments (Step 4). The tool’s output is subsequently parsed and integrated into the prompt (Step 5) for the next iteration. This loop continues iteratively until either the completer tool is executed, or a predefined computational budget is reached. The customized toolkit, implemented by the proposed approach, depends on high-level abstractions like compilers, AST parsers, and LLMs.

Adopting the ReAct framework [13], WIRL iteratively reasons and acts until the goal is met or the budget is exceeded. In each cycle, the agent pilot parses tool outputs and integrates them into the prompt for the next iteration, which consists of both static and dynamic sections.

One of the key novelties of WIRL is its ability to autonomously decide which tools to invoke based on the current state. The toolkit provided for WIRL (as shown in Table II) is carefully customized to facilitate the code wiring task.

The agent pilot orchestrating the communication between LLM and customized toolkit, playing a essential role in WIRL. Its responsibilities are outlined as follows:

• •

  RQ1: How well does WIRL perform compared against baselines?

• •

  RQ2: How well does WIRL perform regarding latency?

• •

  RQ3: How well does WIRL perform regarding token consumption and monetary cost?

• •

  RQ4: How do the design components contribute to the performance of WIRL?

RQ1 investigates the effectiveness of WIRL in comparison to selected baseline approaches for automatic code wiring. By addressing this question, we aim to understand how well WIRL performs in real-world development scenarios, as the evaluation leverages real data under realistic experimental conditions. Additionally, this analysis helps identify specific cases where WIRL outperforms the baselines. Gaining insights into the strengths of WIRL can guide future improvements and optimizations of the approach.

RQ2 examines the time efficiency of WIRL relative to baseline methods, with a particular focus on whether WIRL can meet the responsiveness requirements of integrated development environments (IDEs) and developers. To answer this question, we use the average time taken to complete a code wiring task as the primary metric. This allows us to assess whether WIRL delivers timely recommendations that support fluid and productive software development workflows.

RQ3 assesses the token consumption and associated monetary cost of WIRL. Specifically, we evaluate input/output token usage and the total cost incurred per code wiring instance. By comparing these metrics against those of the baseline approaches, we aim to determine the cost-efficiency of WIRL in delivering practical code wiring support at a reasonable computational expense.

RQ4 quantifies the contribution of each of WIRL’s design components, namely the Locator, Collector, and Completer tools, as well as its architectural design, to the system’s overall performance. Understanding the individual impact of these elements is crucial for validating the novelty of our approach and justifying the design of the WIRL framework.

To the best of our knowledge, there are no existing datasets specifically collected for the evaluation of automatic code wiring approaches. Recently, Zhang et al.[3] investigated context-based code snippet adaptation and constructed a high-quality dataset through a combination of automated processing and meticulous manual curation. The resulting dataset comprises 3,628 real-world code reuse cases, where code snippets were copied from Stack Overflow and subsequently adapted for use in GitHub projects. Their dataset was initially derived from the latest version of SOTorrent[14] (version 2020-12-31), available via Zenodo [15], and includes only those reuse cases in which GitHub files contain explicit references to Stack Overflow posts. Given the quality and relevance of this dataset, we adopted it as the foundation for our evaluation and performed additional filtering and manual curation. The construction of the evaluation dataset used in this paper involves the following steps:

• •

  To prevent data leakage and potential overfitting, we first excluded the 300 sampled instances used by Zhang et al. [3], as the design of WIRL was partially inspired by their empirical observations.

• •

  From the remaining 3,328 reuse cases, we performed a deduplication step to eliminate redundancy caused by forked repositories. Subsequently, we constructed a mapping between GitHub repositories and the corresponding Stack Overflow posts.

• •

  As WIRL depends on compiler feedback and AST binding analysis, it requires the project to be resolvable. Therefore, we conducted a project-wise manual inspection of the remaining dataset. The mappings were sorted in descending order based on the frequency of references to each repository, prioritizing more frequently reused code.

• •

  Following this order, two authors independently reviewed each code reuse case to determine whether it qualifies as a code wiring instance. In cases of disagreement, discussions were held until a consensus was reached. Ultimately, we identified 100 code wiring cases involved with 221 pairs of unresolved elements and context elements from Stack Overflow to GitHub. For ease of reference, we refer to this curated evaluation dataset as $CWEvaluation$.

We adopted the evaluation metrics used by Wang et al. [22] to assess the performance of WIRL and the baselines. The definitions are introduced in the following:

• •

  #Total Cases: the number of cases involved in the evaluation, i.e., number of unresolved elements.

• •

  #Recommendation (#Rec): the number of cases where the evaluated approaches make a recommendation for the developers. Note that the number of recommendations (#recommendation) may not always match the total number of cases (#total cases).

• •

  #Exact Match (#EM): the number of cases where the recommended code elements are identical to the ground truth (i.e., the existing names in context).

• •

  $EM_{Precision}$ ($EM_{P}$): the number of exact matches divided by the number of recommendations, i.e.,

  $$EM_{Precision}=\frac{\#Exact\ Match}{\#Recommendation}$$

  (1)

• •

  $EM_{Recall}$ ($EM_{R}$): the number of exact matches divided by the number of cases involved in the evaluation.

  $$EM_{Recall}=\frac{\#Exact\ Match}{\#Total\ Cases}$$

  (2)

In Table III, the first column lists the evaluated approaches. The second and third columns indicate, respectively, the number of cases in which the recommended code elements exactly match the ground truth and the number of cases in which a recommendation is made by the approach. The fourth and fifth columns, $EM_{Precision}$ and $EM_{Recall}$, report how often the recommendations are correct and how many of the correct substitutions are successfully identified, respectively (see Section IV-D for detailed definitions). From Table III, we make the following observations:

• •

  WIRL outperforms all selected baselines by a significant margin in both $EM_{Recall}$ and $EM_{Precision}$. It produces the highest number of recommendations (217) while also achieving the highest number of exact matches (199). The resulting $EM_{Recall}$ and $EM_{Precision}$ scores of 90.0% and 91.7%, respectively, reflect its strong and reliable performance in real-world development scenarios.

• •

  Compared to IDEA, WIRL achieves improvements of 54.3 percentage points in $EM_{Recall}$ and 49.9 percentage points in $EM_{Precision}$. Against ExampleStack, it shows even greater gains: 88.2 and 51.7 percentage points in $EM_{Recall}$ and $EM_{Precision}$, respectively. Compared to advanced code editing approaches, i.e., GrACE and CoEdPilot, WIRL achieves improvements of 16.2 and 80.5 percentage points in $EM_{Recall}$ and 3.1 and 26.1 percentage points in $EM_{Precision}$, respectively. When benchmarked against the advanced LLM model Qwen2.5-Coder-32B, WIRL still delivers notable improvements of 22.6 and 13.7 percentage points, further demonstrating its superior effectiveness.

• •

  WIRL also substantially improves upon the performance of directly using a raw LLM (Qwen2.5-Coder-14B). Without the academic design described in Section III, the baseline LLM achieves only 49.8% $EM_{Recall}$ and 70.1% $EM_{Precision}$. With the integration of the external toolkit and structured prompt design, WIRL improves $EM_{Recall}$ and $EM_{Precision}$ by 40.2 and 21.6 percentage points, highlighting the value of its architectural innovations.

In this research question, we examine the time efficiency of WIRL compared to other baseline approaches on the $CWEvaluation$. The comparison results are summarized in Table III, where the last column reports the average execution time per code wiring instance. It is worth noting that the reported time costs of raw LLMs are averaged over five independent runs to ensure robustness and consistency. From Table III, we make the following observations:

• •

  WIRL required only marginally more time (approximately 0.6 seconds) to generate a recommendation compared to Qwen2.5-Coder-14B, and it demonstrated greater time efficiency than all other evaluated LLMs except GPT-4o-mini. This efficiency can be attributed to its use of a relatively compact LLM (14B parameters), whereas other models incur longer response times due to their significantly larger parameter sizes. For example, DeepSeek-V3, with 671B parameters, exhibited the highest latency, averaging 11.5 seconds per recommendation.

• •

  Although IDEA and ExampleStack achieved superior performance in terms of time cost, they fall short in ensuring recommendation accuracy. We argue that WIRL offers a more practical trade-off between recommendation quality and acceptable latency, making it well-suited for real-world development workflows.

• •

  Code editing methods, such as GrACE and CoEdPilot, exhibit moderate time efficiency, placing them between the fast, heuristic-based methods and the slower, raw LLM baselines. This performance is attributable to their reliance on pretrained language models, which are more computationally intensive than simple heuristics.

To gain deeper insights into the time cost distribution of WIRL and the raw LLMs, we visualized the results using a violin plot, as shown in Fig. 6. The plot reveals that WIRL is capable of handling the majority of code wiring instances in under 5 seconds. Its median time cost is 4,201.5ms, which is comparable to that of Qwen2.5-Coder-14B (3,977.5ms), and substantially lower than that of DeepSeek-V3 (7,983.5ms). This demonstrates WIRL’s ability to deliver high-quality recommendations with competitive latency.

In this research question, we evaluate the token usage and monetary cost of WIRL compared to other LLM-based baselines on the $CWEvaluation$. The comparison results are summarized in Table IV. Columns 2-4 report the average number of input tokens, output tokens, and total tokens per code wiring instance, respectively, while the last column shows the corresponding average monetary cost. All figures are averaged over five independent experimental runs.

As shown in Table IV, WIRL consumes slightly more tokens than Qwen2.5-Coder-14B, with an average increase of 237.3 input tokens and 80.2 output tokens. This results in a marginally higher monetary cost, i.e., approximately 0.0001 USD more per instance. Surprisingly, although GPT-4o-mini incurs the lowest monetary cost, its performance is relatively poor (refer Table III). The increase in token usage is attributed to WIRL’s iterative design, where it progressively collects and integrates contextual information into the prompt before generating a final recommendation. As the output from one iteration is passed as input to the next, the cumulative token count naturally exceeds that of the single-pass raw LLMs.

To further examine the distribution of token consumption for WIRL and the LLM baselines, we present a violin plot in Fig. 7. The results indicate that WIRL handles the majority of cases using fewer than 2,500 tokens, with a median token count of 2,306.5 per code wiring instance, which is comparable to that of Qwen2.5-Coder-14B having a median of 1,962.5 tokens. Additionally, both WIRL and Qwen-max exhibit stable token usage, with minimal outlier points. Notably, Qwen-max shows consistent performance in both time and token consumption, largely because it omits cases that exceed its maximum token limit.

To investigate the impact of each design choice on overall performance, we conducted an ablation study by creating several variants of WIRL. We first individually removed the three types of customized tools, Locator, Collector, and Completer, to assess their respective contributions (Rows 3-5 in Table V). Next, we evaluated the impact of key architectural components. We replaced the state machine with a fully agent-guided exploration strategy and individually removed the filtering tools (i.e., reserve_type_compatible_ones and sort_by_literal_similarity), and the retrieval tools (retrieve_identical_function_call and get_method_names). From Table V, we make the following observations:

• •

  Tool Contributions: Three tool types contribute differently to WIRL’s performance. The locator tools are the most critical, followed by the completer and then the collector tools. The paramount importance of the locator tools is because both the collector and completer depend on the precise location information they provide. Without locator, the system effectively degrades to a raw LLM.

• •

  Architectural Necessity: All architectural components are integral to the overall performance. The data clearly shows that removing any component, the state machine, filtering tools, or retrieval tools, results in a performance degradation. This highlights their crucial roles in providing valid contextual information to the agent. While the time efficiency remains stable across most variants, the removal of the state machine presents a notable exception.

• •

  State Machine Efficiency: The moderate latency increase observed when removing the state machine is a direct result of a proactive design choice to prevent aimless exploration, a common pitfall in agentic systems. We constrained the maximum iteration number to two, which limits the observable latency penalty in this study. Without this constraint, removing the state machine would lead to prolonged, multi-step exploration cycles and a significantly more substantial, and likely unacceptable, increase in latency.

The ablation study results confirm that each component is integral to WIRL’s performance and the architecture designs are also the key contributors to the efficiency of WIRL.

Despite its specific focus, code wiring represents a frequent, critical, and foundational aspect of code adaptation. This claim is supported by two key factors:

• •

  Prevalence in Adaptations: The empirical study by Zhang et al. [3] on real-world code adaptations provides strong evidence for this. Their study revealed that a remarkable 88.0% of code reuses require adaptation. Through our further analysis, over one quarter (27.3%) of those adaptations involve code wiring operation, underscoring its high prevalence. Additionally, the study highlights that variable references and method invocations are central to the adaptation process, with 77.2% of statement-level code adaptations involving method invocations or variable references.

• •

  Task Complexity: While direct variable-to-variable mapping is relatively straightforward, the core challenge lies in mapping a variable to a complex expression, such as a deeply nested method invocation. This elevates the task from simple pattern matching to one requiring deeper program semantic understanding. A complex example is presented in Fig. 5 and the analysis is presented in Section IV-F5.

We evaluate WIRL’s real-world applicability across three key dimensions:

• •

  Accuracy: With a precision of 91.7%, WIRL significantly reduces the developer’s cognitive load by turning a tedious and error-prone manual adaptation process into a simple inspection and approval task in nine out of ten cases. This accuracy substantially outperforms the 71.8% of the previous state-of-the-art approach [9] in code snippet adaptation.

• •

  Latency: WIRL introduces a minimal computational overhead of only 0.6 seconds on top of the base model’s inference time. The average 5.25-second recommendation time, inflated by our experimental setup using online API calls, would be significantly reduced in a production environment with a locally deployed model or a dedicated API, making it well-suited for practical development workflows. To support self-hosted models or private APIs, the implementation of WIRL [30] allows for the configuration of a custom endpoint URL via the IDEA settings panel at File - Settings - Tools - WIRL AI Settings.

• •

  Cost: Economically, WIRL is highly efficient, with an average cost of just $0.0009 per recommendation based on public API pricing. This negligible cost yields a high return on investment by saving valuable developer time.

Although our dataset, $CWEvaluation$, is modest in size, its quality and representativeness are justified by:

• •

  Ecological Validity: $CWEvaluation$ is derived from genuine code reuse instances from the SOTorrent database filtered and validated by Zhang et al. [3], ensuring it reflects authentic development practices.

• •

  Project and Domain Diversity: It includes 29 distinct open-source projects from a wide range of domains, e.g., foundational libraries and popular mobile applications, enhancing the generalizability of our findings.

• •

  Structural Diversity: The code snippets’ structural properties, e.g., LOC, are comparable to those in larger datasets [3], and a distributional analysis can be found in our online website [31]. Besides, $CWEvaluation$ covers both file-level and project-level adaptation scenarios, ensuring its diversity and complexity.

WIRL is designed to be language-agnostic. Its core LLM-based reasoning and agentic control flow are language-independent. To adapt WIRL to a new language, only two language-specific components in its toolkit require modification: the Locator, which uses compiler information to find unresolved variables, and the Collector, which leverages Abstract Syntax Tree (AST) analysis to gather contextual information. This modular design ensures high generalizability.

The primary threat to external validity is the dataset’s size. We mitigate this by using a public, manually inspected dataset [3] and by open-sourcing our data and results [23] to encourage replication. A threat to construct validity is potential bias in identifying code wiring instances. To address this, two authors independently inspected the data, achieving a high inter-rater agreement (Cohen’s kappa of 0.81), with all discrepancies resolved through discussion.

WIRL has three main limitations. First, in the current implementation, if WIRL’s analysis does not identify any suitable existing variables with high confidence, it will not make a replacement recommendation. Instead, it will inform the developer that no suitable match was found, implicitly guiding them to declare a new variable. For future work, we plan to enhance WIRL to not only detect this scenario but also suggest contextually appropriate names and types for the new variable declaration. Second, our dataset, $CWEvaluation$, lacks more complex wiring scenarios, such as those with semantic ambiguities or many-to-many mappings, due to the laborious nature of manual collection. We plan to develop a semi-automated approach to expand the dataset in the future. Finally, WIRL is currently implemented and evaluated only for Java, and extending it to other languages remains future work.

Research into code snippet adaptation began with empirical studies classifying the reuse and modification patterns developers employ when integrating external code [32, 4, 3]. Early automated tools like CSNIPPEX[33] and NLP2Testable[34] addressed unresolved variables by declaring them with default values, a solution insufficient for complex, context-dependent adaptations. A more significant body of work leverages code clones and existing examples. Tools such as SniptMatch[35], ExampleStack[16], CCDemon[36], MICoDe[37], and EUKLAS[38] recommend adaptations by matching snippets to local or online code repositories. However, their reliance on finding similar, previously adapted code limits their applicability to novel scenarios. Another strategy frames adaptation as a de-obfuscation task, masking and recovering identifiers using context-aware models[39, 40]. Other tools address related but distinct goals, such as assessing code compatibility [41] or converting snippets into methods [42].

In contrast, WIRL focuses on resolving unresolved variables in new contexts without depending on prior examples.

Recent advancements in code editing also inform our approach. Some models are pre-trained specifically for code modification, such as CoditT5 [43], which models edits directly, and CCT5 [44], which learns from code change datasets. Other methods leverage edit history and structural context: C3PO [45] represents edits as paths in the Abstract Syntax Tree, while Overwatch [46] learns from sequences of developer actions. More advanced LLM-based approaches like GrACE [7] and CoEdPilot [8] condition edit generation on prior associated edits to better capture developer intent.

While powerful, these methods differ from WIRL in two key ways. First, the edit location of code wiring problem is often a deterministic problem guided by compiler errors, whereas general code editing involves less predictable changes across multiple files. Second, advanced code editing approaches are dependent on a rich history of prior edits, information that is inherently scarce in the context of code wiring.

LLM-based agents are increasingly used to automate complex software engineering tasks through iterative reasoning and tool use [47, 48, 49]. They have been successfully applied to code generation and testing [50, 51, 52, 53], code maintenance and repair [54, 55, 56], and automated issue resolution [57].

Despite these advancements, no prior work addresses context-aware code wiring for pasted snippets. WIRL fills this gap as the first framework to integrate agent-based planning and a customized toolkit for automated variable resolution.