AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

arXiv:2608.04459v1 [cs.SE] 5 Aug 2026

XIAOKAI RONG, University of Texas at Dallas, USA HRIDYA DHULIPALA, University of Texas at Dallas, USA AASHISH YADAVALLY, University of Central Florida, USA TIEN N. NGUYEN, University of Texas at Dallas, USA Developers often need to adapt into their projects the code generated from LLMs or code snippets from online forums. However, integrating them into an existing repository remains challenging in a manual process. A successful integration typically requires more than copying code as a user must produce correct adapting changes at a designated location in the target repository. We formalize this as the code adaptation problem: given a snippet, functional intent, a target repository, and an adaptation location, generate a patch that adapts the snippet into the repository. We present AdaptAgent, a multi-agent, domain-guided reasoning framework for code adaptation. Rather than relying on single-shot prompting, AdaptAgent decomposes adaptation into specialized agents that communicate via typed artifacts: an Intent Summarizer extracts adaptation goals from Q&A text; a Policy Agent derives domain policies from six adaptation categories; a Domain Planner generates a self-ordered plan; a Context Miner distills sibling-method semantics from the target codebase; and a Code Adapter realizes the plan as a minimal unified diff, iteratively refined using a compiler-based Verifier. This division of labor enables robust, policy-aligned adaptations and supports adapting code snippets into a project. On a real-world dataset, AdaptAgent outperforms strong baselines in semantic correctness and produces patches that mirror developers’ actual adaptation patterns. Our ablation study shows each agent’s necessity, especially planning for code-hardening and exception-handling, and intent for logic customization. CCS Concepts: • Computing methodologies → Neural networks; • Software and its engineering; Additional Key Words and Phrases: AI4SE, Agentic SE, Multi-agents, Code Adaptation ACM Reference Format: Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen. 2026. AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation. Proc. ACM Softw. Eng. 3, ISSTA, Article ISSTA193 (October 2026), 22 pages. https://doi.org/10.1145/3832284

1

Introduction

Software developers frequently turn to LLMs or forums for quick solutions, with millions of code snippets shared daily [6, 7, 20, 22, 26, 36–38]. Currently, adapting these snippets requires developers to manually analyze, refactor, and integrate the online code to ensure correctness and compatibility. This process is both time-consuming and error-prone, requiring a deep understanding of both the snippet and the target codebase. An automated tool that facilitates correct and efficient adaptation would be highly beneficial, ensuring that adapted code is not only seamlessly integrated but also semantically correct within the project. In this work, we formalize the above scenarios as the code adaptation problem: given a code snippet, (functional) adaptation intent, a target repository, Authors’ Contact Information: Xiaokai Rong, University of Texas at Dallas, Dallas, USA, xiaokai.rong@utdallas.edu; Hridya Dhulipala, University of Texas at Dallas, Dallas, USA, Hridya.Dhulipala@utdallas.edu; Aashish Yadavally, University of Central Florida, Orlando, USA, aashish.yadavally@ucf.edu; Tien N. Nguyen, University of Texas at Dallas, Dallas, USA, tien.n.nguyen@utdallas.edu.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. © 2026 Copyright held by the owner/author(s). ACM 2994-970X/2026/10-ARTISSTA193 https://doi.org/10.1145/3832284 Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:2

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

and an adaptation location, generate a change patch that adapts the snippet into the repository. The adaptation intent in a forum is described via the questions and realized in the answers. Large Language Models (LLMs) have shown strong performance on a range of code understanding and generation tasks. However, their effectiveness on code adaptation remains unknown. In our study, we explored LLMs’ capability for code adaptation and found that directly prompting an LLM to adapt a code snippet into a target project yields unsatisfactory results. Our preliminary experiment (Section 8) with direct prompting to GPT-4 revealed two primary shortcomings. First, a Stack Overflow (SO) post often contains irrelevant information, including unnecessary explanations, alternative solutions, and unrelated discussions. This is challenging for GPT-4 to extract the core adaptation intent, leading to incorrect and incomplete modifications. Second, when adapting code, GPT-4 frequently omits crucial elements such as code hardening (e.g., missing conditions, final modifiers, resource cleanup) and exception handling (e.g., try-catch blocks, exception declarations, or error propagation changes). These omissions can result in fragile or incorrect code. In this paper, we present AdaptAgent, a multi-agent framework that automates the adaptation of code snippets into a target project. AdaptAgent decomposes the task across specialized agents that communicate via typed artifacts. We leverage 1) LLM-based adaptation planning, 2) domain-specific knowledge, and 3) context-aware adaptation to ensure precise and reliable integration: 1. Adaptation Intent Summarizer is an LLM agent that summarizes the essential parts of the SO post, filtering out irrelevant details while retaining the adaptation goal from noisy texts. 2. Strategic Adaptation Planner is an LLM agent in which instead of performing adaptation in a single step, it employs autonomous planning for an LLM to generate a self-ordered adaptation plan before executing code modifications. The plan includes identifying necessary modifications based on the post and the target codebase, and structuring a step-by-step adaptation and validation checks to detect potential issues before finalizing the adaptation – all autonomously planned by the agent. To guide the planner agent, AdaptAgent uses a policy agent that derives the adaptation policy from domain knowledge with six adaptation categories. 3. Policy Agent is an agent that performs domain-specific knowledge integration. Prior research in Zhang et al. [37] has identified six major categories of code adaptation: code hardening, resolving compilation errors, exception handling, logic customization, refactoring, and miscellaneous improvements. The policy agent incorporates this domain knowledge as well as any project-specific policies into a checklist, guiding the LLM to systematically address these common adaptation challenges, ensuring that the generated code aligns with best practices. 4. Context Miner is an external tool to extract the adaptation context. To help AdaptAgent understand the target codebase for adaptation, we provide the target method/class context. 5. Code Adapter is a unified-diff generation agent realizing the plan as a minimal diff. With planning, LLM autonomously plans the potentially conflicting atomic adaptation changes, achieving a self-ordered adaptation plan. We do not need to specify the order of concrete adaptation changes. 6. Verifier is an external compiler to provide the feedback to the adapter to correct any syntactic errors in the adapted code. Our empirical evaluation on a real-world code adaptation dataset shows that AdaptAgent achieves 63.1% semantic correctness, which is 5.5%-53.6% more correct adaptation cases than the baselines. We also demonstrated that the code adapted by AdaptAgent covers similar adaptation aspects in proportions similar to the code adapted by actual developers in their projects. The adaptation correctness is also consistent across adaptation complexity. Finally, we showed that all four components (intent, policy guidance, planning, and context) contributed positively to AdaptAgent’s performance. In brief, in this paper, we make the following contributions: 1. AdaptAgent: A multi-agent, domain-guided framework for context-aware code adaptation with explicit agent contracts via a linear pipeline coordination with typed artifacts; Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:3

2. Autonomous code adaptation across categories without predefined order of atomic changes; 3. Extensive empirical evaluation to show the effectiveness of AdaptAgent in code adaptation over the baselines and the contributions of each component to the overall performance. 2

Motivation

Let us present a real-world example to motivate our approach. A developer posted a question on StackOverflow (SO) with the post ID #29764243 [1], stating: "I am trying to draw and erase on image and then save it to sd card. I got success in drawing and saving it to sd card, but when I checked the save image in sd card I got a black background image not the image that I drew. Please suggest how to apply an image as a canvas background and erase the drawn text without losing the background image. I have seen various examples on stack overflow but my bad nothing is working for me, pls help." (S)he also provided the relevant code to clarify the context of the question. Another developer replied with a solution, including the code in Fig. 1. Later, the Touch_Move method from the 1 public class DrawingView extends View { 2 ... solution in SO was adapted into a 3 private void touch_move(float x, float y) { float dx = Math.abs(x - mX); GitHub project named JustWeTools [2]. 4 5 float dy = Math.abs(y - mY); In JustWeTools (Fig. 2), the develop- 6 if (dx >= TOUCH_TOLERANCE || dy >= TOUCH_TOLERANCE) { mPath.quadTo(mX, mY, (x + mX) / 2, (y + mY) / 2); ers made a few modifications to adapt 7 8 mX = x; the original code to their specific needs. 9 mY = y; For instance, the code on lines 11–13 10 11 circlePath.reset(); of the original answer in Fig. 1 was in- 12 circlePath.addCircle(mX, mY, 30, Path.Direction.CW); mCanvas.drawPath(mPath, mPaint); tended for demonstration purposes in 13 14 } the SO post and was therefore removed 15 } ... by the JustWeTools developers. Notably, Fig. 1. An Answer to the Question in SO Post #29764243 they added the lines 10–14 (Fig. 2) to implement a feature that enables "applying an image as a canvas background and erasing or drawing text without losing the background image." However, they overlooked exception handling for drawPath on lines 11 and 13 (Fig. 2), which could cause exceptions if the image file path is invalid. As shown, code adaptation to an existing project is error-prone, necessitating an automated solution, yet no tool exists for seamless adaptation. Advancements in LLMs present a new direction. To assess that, we conducted a preliminary experiment using GPT-4 with a simple prompt, providing (1) the question showing the (functional) adaptation intent of the code, and (2) the Touch_Move method from the accepted answer. However, GPT-4 failed to adapt the code. With adjusted access control and a defined constant, the resulting code compiled but was functionally incorrect, retaining irrelevant operations (e.g., addCircle in lines 11-13, Fig. 1) while omitting functions like canvas background change, text erasure without image loss (lines 10–14, Fig. 2), and missing exception handling. 3

Key Ideas

The naive prompt clearly lacked sufficient guidance for the LLM in code adaptation. First, from the example, we can identify that the content of the posts and discussions surrounding the questions and answers can provide valuable insights into the functional adaptation intent. However, the entire post may include irrelevant information that could mislead the LLM in capturing the adaptation intent. For instance, while most of the question’s content is relevant, the last sentence is not. Thus, we hypothesize that a summarized version of the question and correct answers would be more concise and effective in conveying the intent for adaptation, which is expressed in Q&A texts. For LLM-generated code, adaptation intent can be expressed in users’ textual descriptions. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:4

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

1 public void Touch_Move(float x, float y) { 2 super.Touch_Move(x, y); 3 float dx = Math.abs(x - mX); 4 float dy = Math.abs(y - mY); 5 if (dx >= PaintView.TOUCH_TOLERANCE || dy >= PaintView.TOUCH_TOLERANCE) { 6 mPath.quadTo(mX, mY, (x + mX) / 2, (y + mY) / 2); 7 mX = x; 8 mY = y; 9 10 if(PaintView.IsPaint) { 11 mCanvas.drawPath(mPath, mPaint); 12 } else { 13 mCanvas.drawPath(mPath, mEraserPaint); 14 } 15 } 16 }

Fig. 2. Human-adapted Code in JustWeTools Project

1 public void Touch_Move(float x, float y) { 2 super.Touch_Move(x, y); 3 float dx = Math.abs(x - mX); 4 float dy = Math.abs(y - mY); 5 if (dx >= PaintView.TOUCH_TOLERANCE || dy >= PaintView.TOUCH_TOLERANCE) { 6 mPath.quadTo(mX, mY, (x + mX) / 2, (y + mY)/2); 7 mX = x; 8 mY = y; 9 10 try { 11 mCanvas.drawPath(mPath, PaintView.IsPaint ? mPaint : mEraserPaint); 12 } catch (Exception e) { 13 e.printStackTrace(); 14 } 15 } 16 }

Fig. 3. The Code Adapted by AdaptAgent

Key Idea 1 (Adaptation Intent). (Functional) adaptation intent in adapting code snippets can be effectively conveyed through a summary of the question and its answers. Second, to ensure a complete adaptation process, we propose integrating domain-specific knowledge. Specifically, Zhang et al. [37] conducted a large-scale study on the adaptations and variations of SO snippets by qualitatively analyzing 400 SO examples and the GitHub counterparts that adapted them. They developed a taxonomy of six categories of code adaptation: code hardening, resolving compilation errors, exception handling, logic customization, refactoring, and miscellaneous. We will incorporate the guidance in those categories into the prompts provided to the LLMs. Key Idea 2 (Domain-Specific Guidance). Guidance for LLMs can be developed effectively based on domain-specific knowledge collected from practice, e.g., online code-snippet adaptation knowledge. Third, the target code’s context is a critical factor in guiding adaptation. For example, the Touch_Move method (Fig. 2) was integrated into the DrawPath class of the JustWeTools project. Providing details on the adaptation location, along with relevant semantic context, e.g., the other methods in the same class (sibling methods), can be helpful. In this case, sibling methods like Touch_Down, Touch_Up, and onDraw offer related functionality and share common APIs, providing valuable adaptation guidance. Key Idea 3 (Semantic Context). The methods in the target class, into which the given code snippet is integrated, offer semantic context that helps guide the LLM in performing the adaptation. Finally, adapting code snippets to an existing project involves understanding the project’s context, dependencies, and developers’ intentions. Single-shot prompting may overlook crucial details or produce inconsistent results. In contrast, multi-agent architecture enables cooperating specialized agents and/or external tools with division of work in which LLM planning offers an autonomous approach, enabling it to break down the adaptation task into smaller reasoning/action steps. Key Idea 4 (Why Multi-agent and LLM Planning?). Multi-agent architecture enables cooperating agents in which LLM planning leverages a more strategic process that integrates context, relevant guidance, and intermediate validations, deriving a sequence of non-conflicting atomic changes that collectively satisfy all adaptation requirements. By reasoning over dependencies among atomic adaptation changes, the agents determine the right order of atomic changes without relying on a pre-defined workflow, ensuring the final patch is correct, complete, and consistent with the target codebase. Fig. 3 illustrates the adaptation suggested by AdaptAgent, which leverages its multi-agent framework equipped with adaptation intent, domain-specific guidance, and semantic context. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:5

Fig. 4. AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

As shown, the code at line 11 in Fig. 3 features a ternary operator expression, equivalent to the conditional statement in the adapted code at lines 10–14 of Fig. 2. Exception handling was added to gracefully manage drawing issues (lines 12–14, Fig. 3). 4 AdaptAgent Overview Fig. 4 illustrates AdaptAgent’s multi-agent architecture comprising of cooperating agents connected by typed artifacts. It takes as inputs the given code snippet, (functional) adaptation intent, the adaptation code location in the target codebase. For online code adaptation, the adaptation intent is expressed in the question and answer and the given code is the one in the accepted answer. First, the Summarizer ( 1 ) captures the intent from the post. It takes as inputs the question, the accepted code snippet selected for adaptation, and the associated texts, among multiple potential answers. The Summarizer creates the summary, concisely capturing the intent of the adaptation. Second, the Policy agent ( 2 ) yields a checklist from the domain-specific guide and any projectspecific policies (e.g., error-handling style). For online code adaptation, the common adaptation types include 1) code hardening (i.e., adding a conditional or a final modifier, cleaning up un-managed resources, etc.), 2) resolving compilation errors, 3) exception handling (i.e., inserting/deleting a try-catch block or a thrown exception in a method header, changing statements in catch or finally blocks, updating exception types), 4) logic customization, 5) refactoring (i.e., renaming, replacing magic numbers, inlining a field, etc.), and 6) others [37]. This agent builds the checklist that instructs the Planner to look for the opportunities to support those adaptation categories. Third, AdaptAgent leverages the Planner agent ( 3 ) to develop an adaptation plan using the checklist produced by the Policy agent. In total, the Planner takes as inputs 1) the summary of the adaptation intent produced by the Summarizer agent, 2) the adaption checklist produced by the Policy agent, 3) the target code in the project (the adapting location), and 4) the selected code for adaptation. The output of the Planner is the adaptation plan with descriptions of change actions. Fourth, Context Miner component ( 4 ) distills the important contextual information surrounding the adaption location from the target project for adaptation. In the current design, for simplification, we collect only the API method calls in the sibling methods as the semantic context. However, our general framework can accommodate richer structural/semantic signals (types, call graphs, PDGs) that are often critical for correct integration. We left these richer signals for future work as AdaptAgent achieved high accuracy in code adaptation in our evaluation (Section 8). Fifth, the Code Adapter agent ( 5 ) takes as inputs 1) the adaptation plan, 2) the summary of the intent, 3) the target code and adaptation location in the target project, and 4) the semantic context. This agent outputs the adaptation patch. The Adapter LLM autonomously determines the sequence of non-conflicting, atomic changes across relevant categories, without explicitly specifying their order (see Fig. 3). This is the benefit of the use of multi-agents. Moreover, we use the Verifier ( 6 ), which Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:6

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

is an external compiler to provide the feedback to the Adapter to correct the adapted code. This feedback is repeated until no more syntactic errors or a limit number of attempts is reached. The agents use a linear pipeline coordination via typed messages including intent summary, policy checklist, self-ordered adaptation plan, semantic context, unified diff, etc. (see artifacts in Fig. 4). 5

LLM-Based Content Summarization

Leveraging LLMs’ capability in summarization [17, 24], Summarizer ( 1 ) creates the summary of adaptation intent from a post. We formulate this step of abstracting adaptation intent, ℐ: ℳ(ℐ⋃︀𝒫𝒬, 𝒫𝒞 , 𝒫𝒜 ). Given a post 𝒫 in our problem statement, we denote the question text, including any code or natural language descriptions as 𝒫𝒬 , the specific answer text which has online answering code snippet that has been chosen by a questioner to be adapted into his/her codebase (possibly with an explanatory text), as 𝒫𝒞 , and the associated tags as 𝒫𝒜 . The tuple 𝒫 = ∐︀𝒫𝒬, 𝒫𝒞 , 𝒫𝒜 ̃︀ is consumed by the Summarizer ( 1 ), leveraging LLM’s capability to convert a mixture of natural language (NL) and programming language (PL) into a concise, highlevel NL summary ℐ. Specifically, 𝒫𝒬 often contains questions, while 𝒫𝒞 represents the online code solution that a user aims to adapt. By combining both into a single prompt, Summarizer can make a connection between the question 𝒫𝒬 and the answer code snippet 𝒫𝒞 , thus capturing the adaptation intent. The tags 𝒫𝒜 provide other meta-information, e.g., language, version, library constraints, etc. Notably, these tags, such as "Java 1.8", "Apache 2.0", or even "Debugging", encode contextual details on the environment or constraints that might be critical for an effective adaptation. To capture the adaptation intent in a post, we construct a specialized prompt used in the Summarizer as shown in top left (⊗) of Fig. 5. In this prompt, we explicitly guide LLM to structurally break down the core component in a post, including a descriptive title of the question, the primary problem statement, and notable constraints or environment details, the solution strategy within the chosen snippet, and any edge cases that possibly could be mentioned in the post. 𝒫 = ∐︀𝒫𝒬, 𝒫𝒞 , 𝒫𝒜 ̃︀ is embedded into the location marked with <POST> in the prompt. Within the prompt, for the sections "Accepted Answer’s Core Idea" and "Detailed Code Snippet Explanation," we guide the model to identify the most relevant connections from 𝒫𝒬 → 𝒫𝒞 . For example, as shown in the bottom-left subfigure of Fig. 5 (⊛), the sample output of our prompt—after applying to the motivation example—shows that the LLM successfully extracts the intent behind 𝒫𝒬 → 𝒫𝒞 . Specifically, it identifies the core of the question ("enabling a user to draw and erase parts of an image without losing the background in an Android drawing application") and the key idea of the code snippet in the solution (See "Accepted Answer’s Core Idea"). The "Core Problem" section highlights the issue in incorrect background setting. 𝒫𝒯 specifies Android app as the domain. 6

Domain-Specific Knowledge-Guided Planning

In the LLM planning, we provide the Planner agent with three core inputs to generate a structured adaptation plan. First, we integrate relevant domain-specific checklist 𝒟 derived from the Policy agent on adaptation categories, allowing the LLM to systematically determine the necessary adaptation modifications to the given target code snippet. Second, we incorporate the adaptation intent ℐ from the summarizer agent, ensuring modifications align with the overarching goal rather than isolated code changes. Third, we supply the target code itself. Finally, the LLM Planner produces a step-by-step adaptation plan 𝒴, outlining actionable items 𝒜 and reasoning steps ℛ. 6.1

Knowledge Guidance

Prior research has shown that providing LLMs with specialized, domain-specific guidelines enhances accuracy [23, 32]. In the initial planning step, the Policy agent ( 2 ) takes as inputs the domainspecific guide and any project-specific policies and constructs a checklist for adaptation guidance. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:7

⊗ Summarization Prompt

⧫ Planning Prompt

Final Adaptation Prompt

System Prompt for online code adaptation (if GPT): You are an assistant specialized in summarizing Q&A posts... User Prompt: Given the full text of a Stack Overflow question and its accepted answer, produce a concise summary following the template below. Stack Overflow Post Summary: 1. Question Title: [Descriptive title of the question] 2. Core Problem: [Sentences describing the main issue the user wants to solve] 3. Relevant Environment or Constraints: [List any important details such as programming language, platform, libraries, frameworks, or performance limitations mentioned in the post] 4. Accepted Answer’s Core Idea: [For each method or class, summarizing how the answer solves the problem and how the answer do the implementation] 5. Detailed Code Snippet Explanation: If there are multiple methods or classes, write a summary for each of them and clearly label it... <POST>→ 𝒫 = (𝒫𝒬 , 𝒫𝒞 , 𝒫𝒜 )

System Prompt(if GPT): You are an assistant specialized in adapting code snippets to new contexts. You have these resources: 1) A code snippet or method signature from Stack Overflow. 2) A partial call graph (or relevant codebase context). 3) A checklist of adaptation categories and project-specific policies <6_adaptation_category> and <policies> → 𝒟 Your goal in this phase is ONLY to analyze potential adaptation issues and produce a plan. User Prompt Below are all the information you need. <answering_code> → 𝒫𝒞 <target_code> → 𝒫𝒯 <Intent_Summarization> → ℐ Instructions: 1) Review the code in light of guidelines. 2) Produce a structured plan explaining what adaptations are needed. 3) Do not generate final code. 4) Do not add extra commentary outside the plan. ...

User Prompt Below is the plan detailing required adaptations, along with the original code context and summarization. [ADAPTATION_PLAN] → ★ [answering_code] → 𝒫𝒞 [target_code] → 𝒫𝒯 [CODE_CONTEXT] [GitHub_Code_Base] (with target Counter Part removed) [SUMMARIZATION] → ⊛ Please generate: 1) A unified patch that implements a final function between function ‘<purpose1>‘, and function ‘<purpose2>‘(e.g., getName()): 2) Incorporates all the adaptations described in the adaptation plan. 3) Provide a short explanation of the changes made in the patch. Disclaimer: - Follow the repository style indicated by the call graph or code context. - Provide well-formatted code in a standard patch/diff format. ...

⊛ Summarization of Intent Post Summary: 1. Question Title: Drawing and erasing on an image without losing the background, then saving it 2. Core Problem: ... However, the saved image only contains a black background rather than the intended image, and the erasing functionality is not working as expected. ... 3. Relevant Environment/Constraints: - Android app development... 4. Accepted Answer’s Core Idea: The solution involves correctly setting the background for the canvas by drawing the desired background image onto the canvas instead of just using a color or invalid ‘drawable‘ reference. ... 5. Detailed Snippet Explanation: create_image Method:... Potential Edge Cases Mentioned: - Ensure proper permissions for writing to external storage when saving images. ....

★ Adaptation Plan

Generated Patch ▲

Here are the steps for adaptation 1) Code Hardening: - Ensure ‘mX’, ‘mY’, ‘TOUCH_TOLERANCE’, ‘mPath’, ‘circlePath’, ‘mCanvas’, and ‘mPaint’ are initialized before they are used. - Ensure to handle both drawing and erasing by properly using .drawPath(). ... 2) Resolve Compilation Errors: - Ensure that all necessary variables (‘mX’, ‘mY’, ‘TOUCH_TOLERANCE’, ‘mPath’, ‘circlePath’, ‘mCanvas’, ‘mPaint’) are declared and in scope. - Often needed imports for this exact snippet: android.graphics.Path, android.graphics.Canvas, android.graphics.Paint. ... 3) Exception Handling: - Implement a try-catch block around ‘mCanvas.drawPath()’ to handle any potential drawing issues. 4) Miscellaneous: - Ensure that ‘quadTo’ and ‘addCircle’ methods are being exercised in a way consistent with the intended application functionality.

@@ -42,6 +44,31 @@ public class DrawPath extends DrawBase { } @Override public void touchMove(float x, float y) { float dx = Math.abs(x - mX); float dy = Math.abs(y - mY); if (dx >= TOUCH_TOLERANCE || dy >= TOUCH_TOLERANCE) { mPath.quadTo(mX, mY, (x + mX) / 2, (y + mY) / 2); mX = x; mY = y; circlePath.reset(); circlePath.addCircle(mX, mY, 30, Path.Direction.CW); + try { + mCanvas.drawPath(mPath, PaintView.IsPaint ? + mPaint : mEraserPaint); + } catch (Exception e) { + // Handle issues + e.printStackTrace(); + } + } + } ...

Fig. 5. Prompt Templates used in AdaptAgent

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:8

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

First, the domain-specific knowledge for code adaptation can be derived from the study by Zhang et al. [37] (Table I). Below is a concrete example of six domain-specific adaptation categories, which are used as the first part of the prompt supplied to the Policy agent: 1) Code Hardening: Enhancing robustness by adding conditionals, handling new exception types, inserting final modifiers, and managing resources (e.g., closing streams). 2) Resolving Compilation Errors: Declaring variables, correcting method calls, removing references to undefined methods, etc. 3) Exception Handling: Modifying try-catch blocks, updating exception types, and refining catch/finally logic. 4) Logic Customization: Adjusting method calls, changing constants or variable types, and refining conditionals for adaptation. 5) Refactoring: Improving maintainability (renaming, replacing magic values, restructuring fields). 6) Other adjustments: Minor modifications, e.g., altering log statements, reformatting code, or updating annotations and comments. Second, the project-specific rules/policies, if any (e.g., error-handling or naming convention), can be fed into the Policy agent. Below is a concrete example of a project-specific list of policies: 1) Exception Naming Convention: All custom exceptions must follow the suffix *Exception (e.g., InvalidOrderException, DependencyResolutionException) and reflect a clear, domain-specific failure. 2) No Silent Failures: Exceptions must never be swallowed silently. Every caught exception must be either logged with context or re-thrown with additional information. 3) Methods that may fail should use clear naming conventions: get* → expected to succeed or throw, tryget* → returns null instead of throwing, and validate* → throws validation-specific exceptions. 4) Resource Cleanup and Fail-Safety: All methods interacting with external resources (files, network, DB) must ensure proper cleanup (e.g., finally blocks or try-with-resources) and maintain system consistency in case of failure. Third, the Policy agent takes as its prompt the two above lists of guidelines and policies, and produces a case-specific combined checklist, collectively denoted as 𝒟 (not shown). As seen in Fig. 5 (⧫), we then incorporate the case-specific combined checklist 𝒟 at the placeholder <6_adaptation_categories> and <policies>, prompting Planner agent (Section 6.2) to review the code and methodically determine adaptation categories. If a category is inapplicable, we instruct the model to skip it. The Planner is expected to systematically evaluate each category and determine all potential, necessary changes for the target code 𝒫𝒞 , rather than focusing on isolated modifications. 6.2

Self-Guided Adaptation Plan Generation

We build the Adaptation Planner agent ( 3 ) with LLM and Chain-of-Thought (CoT). CoT structured reasoning helps LLMs produce more accurate and contextually aligned results when they first develop a structured plan before generating the final solution [15, 27]. Our prompt instructs the LLM to build a self-ordered adaptation plan, consisting of executable actions 𝐴 paired with reasoning justifications 𝑅. This plan is guided by (1) the previously collected checklist 𝒟 from the Policy agent, (2) the adaptation intent ℐ from the Summarizer, (3) the chosen answering code 𝒫𝒞 , and (4) the target code 𝒫𝒯 in a project. The structured reasoning process using CoT can be formulated as: 𝑝(𝒴⋃︀ℐ, 𝒟, 𝒫𝒞 , 𝒫𝒯 ) 𝑛

= ∏ 𝑝(𝒴𝑖 ⋃︀𝒴1, ..., 𝒴𝑖−1, ℐ, 𝒟, 𝒫𝒞 , 𝒫𝒯 ) 𝑖=1 𝑛

= ∏ 𝑝((𝒜𝑖 , ℛ𝑖 )⋃︀(𝒜1, ℛ1 ), ..., (𝒜𝑖−1, ℛ𝑖−1 ), ℐ, 𝒟, 𝒫𝒞 , 𝒫𝒯 ) 𝑖=1

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

(1)

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:9

At each reasoning step of CoT, the LLM produces a pair of an action 𝒜𝑖 and a reasoning justification ℛ𝑖 . The decision for a reasoning step depends on the previous reasoning steps and the 4-tuple of the intent ℐ, the checklist 𝒟, the chosen answering code 𝒫𝒞 , and the target code 𝒫𝒯 . The final output is a plan comprising a sequence of pairs of actions 𝒜𝑖 and their corresponding reason ℛ𝑖 . By capturing the rationale alongside the specific action, it ensures the LLM addresses potential changes to be made in its adaptation plan. This plan serves as an explicit blueprint, prompting the model to decompose the adaptation process into distinct, atomic steps 𝒴𝑖 = (𝒜𝑖 , ℛ𝑖 ). From prior research [12, 27], such task decomposition reduces inconsistent or incomplete modifications. Moreover, by providing ℐ (the high-level goal) and 𝒫𝒯 (the target environment in which the snippet must integrate), the LLM gains insight into how the new code will function within existing structures. The intent ℐ makes sure the generated plan focused on adaptation changes while directly feeding the answering code 𝒫𝒞 reveals the context that the plan must address. In combination with domain knowledge in 𝒟, the model can strategize around typical adaptation needs in the target code/project 𝒫𝒯 (e.g., handling exceptions or refactoring), thereby maximizing the likelihood of producing coherent, context-appropriate plan 𝒴 = (𝒜, ℛ). For example, in the generated plan, shown in highlighted text, Fig. 5(★), LLM correctly identifies four categories that need to be adapted in the target code snippet, shown in Fig. 1. It explicitly mentions the potential issue of variable mX, mY, TOUCH_TOLERANCE, mPath, circlePath, mCanvas, and mPaint, precisely points out the action it needs to take upon the API call and its usage: "handle both drawing and erasing by properly using .drawPath()". 7

Code Adaptation with LLM-Based Patch Generation

Code Adapter agent ( 5 ) utilizes an LLM to process four key inputs: the generated adaptation plan 𝒴 = (𝒜, ℛ) = {(𝒜1, ℛ1 ), (𝒜2, ℛ2 ), ..., (𝒜𝑛 , ℛ𝑛 )}, the adaptation intent ℐ, the target code 𝒫𝒯 , and the context 𝒞. Based on these inputs, the LLM generates a unified diff patch [16] relative to the original code. We opted to prompt the Adapter LLM to produce a diff patch rather than rewriting the entire file to prevent unintended modifications due to LLM hallucination. This ensures minimal yet precise modifications to the target code while preserving the original structure [5]. Moreover, automated program repair (APR) research showed that LLMs are well-suited for generating unified diff patches, enabling seamless integration of changes into source code [14, 16, 29]. The prompt to the Adapter consists of four sections, each serving a specific role in guiding the LLM in adaptation: 1) Adaptation Plan 𝒴: This provides the LLM with a structured adaptation roadmap generated by the Planner. The plan explicitly lists modifications and reasons based on adaptation categories. 2) Code Context 𝒞 and Codebase: Rather than feeding the entire project, we extract the most relevant context, ensuring that the LLM has a precise understanding of where and how the adaptation should be applied. The context 𝒞, built by the Context Miner tool ( 4 ), includes: (1) adaptation location (𝒞ℒ ): The exact points are marked by purpose1 and purpose2 in Fig. 5 (Final adaptation prompt) where the changes should be integrated. (2) The file level structure 𝒞𝒢 of the codebase is provided. (3) The list of the API calls 𝒞𝒜 that are used in the sibling methods of the adapted method. 3) Target Code 𝒫𝒯 : The specific function or module where the adaptation will occur. 4) Intent Summarization ℐ: This is derived from the first phase. Generated Unified Diff Patch. A patch in the unified diff format consists of multiple hunks ℋ={ℋ1, ℋ2 ...}, where each hunk represents the modifications localized to an area in consecutive lines. Formally, the patch generation process can be formulated as: 𝑝(ℋ⋃︀ℐ, 𝒴, 𝒞, 𝒫𝒯 ) 𝑛

= ∏ 𝑝(ℋ𝑖 ⋃︀ℋ1, ..., ℋ𝑖−1, ℐ, 𝒴, 𝒞ℒ, 𝒞𝒢 , 𝒞𝒜, 𝒫𝒯 )

(2)

𝑖=1

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:10

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

The order of applying the hunks of unified diff patches is autonomously decided by Adapter. As shown in Fig. 5 (★), the adaptation plan ensures that the model correctly differentiates between drawing and erasing when calling drawPath(). Thus, the LLM explicitly inserts the missing statement: + mCanvas.drawPath(mPath, PaintView.IsPaint ? mPaint : mEraserPaint); This change ensures the function correctly switches between mPaint (for drawing) and mEraserPaint

(for erasing), addressing a key issue highlighted in the intent ℐ: "draw and erase parts of an image without losing the background in an Android drawing application." The LLM also anticipates potential API failures and integrates exception handling for drawPath() as part of the adaptation plan. The resulting adapted code is verified by the external compiler (Verifier 6 ). If the code is un-compiled, the error messages are fed to the Adapter agent for correction until a certain limit. 8

Empirical Evaluation

To evaluate AdaptAgent, we seek to answer to the following research questions: RQ1. Correctness Analysis. How accurate is the code adapted by AdaptAgent compared to the actual code adapted by the human developers for online code adaptation? RQ2. Human Adaptation vs AdaptAgent’s Adaptation. How does the code adapted by AdaptAgent align with actual developers’ adapted code regarding different adaptation categories? RQ3. Ablation Study. How does each agent of AdaptAgent contribute to its performance? RQ4. Performance with Different Adaptation Complexity. How well does AdaptAgent perform when adapting code with varying complexities regarding numbers of lines and code hunks? RQ5. Correctness of Adaptation Plan. How accurate is the Planner agent in AdaptAgent? 9 9.1

Correctness Analysis (RQ1) Experimental Methodology

9.1.1 Dataset. We used Zhang et al. [37]’s dataset with 629 Java samples of potentially adapted code from SO to GitHub. Each sample includes a SO code snippet and all of its adapted code across multiple GitHub repos. To ensure relevance, we filtered out cases where adaptation support was not needed: we excluded SO posts where discussions revealed that the snippet was self-updated, i.e., the author of the question had independently found and incorporated a solution into the post and later copied the exact original SO code snippet into his codebase. After that, we obtained a dataset of 542 samples, which gives us 952 pairs of SO code snippets and corresponding Github’s adapted code. Among those GitHub repos, we were able to set up and run 201 unique repos with the associated 496 concrete test suites. That gives us a subset 𝐷𝑡 with 259 unique pairs of SO code snippets and GitHub counterparts with test cases. Let us call the subset without test cases 𝐷𝑚 (693 pairs). 9.1.2 Procedure and Metrics. For each data instance, we extracted the question, the answering code snippet that was adapted, and its associated explanatory texts, then fed them into the Summarizer and Planner. We used the corresponding GitHub project from the version preceding the adaptation as the target code and location for the adaptation, and fed them to the Context Miner to extract the sibling methods (as the context) within the same class (as the target code) and all of their API calls. To assess the correctness of adapted code 𝑃, we compare it with the post-adaptation code 𝐺 by developers from the dataset. For a sample 𝑠 in 𝐷𝑡 (with test cases), if the adapted code passes all the available test cases for 𝑠 in the ground truth, we consider it as correct. Otherwise, it is incorrect. Correctness is the ratio of the instances with all passing test cases over the total instances. For the samples in 𝐷𝑚 without test cases, we conducted a manual evaluation with two evaluators. Annotators were shown the source Stack Overflow code, the target project context, the modelproduced adapted code, and the ground-truth code. For each instance, they assigned a binary label: correct or incorrect. An adaptation was labeled correct only if it satisfied: (1) it implemented Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:11

the intended functionality of the source snippet in the target setting; (2) it was consistent with the target project context, including relevant variable usages, APIs, and data flows, and (3) it introduced no clear semantic mismatch, such as incorrect API substitution, wrong arguments, or behaviors contradicting the target context. To reduce reference bias, annotators were not asked to judge by similarity to the ground-truth adapted code. Instead, the ground truth was used only as contextual evidence for semantic validity, rather than a direct answer key for textual matching. We resolved disagreements via majority voting with an additional evaluator. Moreover, for both 𝐷𝑡 and 𝐷𝑚 , we also compare 𝑃 and 𝐺 via three code similarity metrics: 1) dependency similarity via Program Dependence Graphs (PDGs) (from Joern [30]), 2) syntactic similarity via ASTs, and 3) lexical similarity via CodeBLEU and editing similarity. Our evaluation tool aligns PDG/AST nodes based on their statement types (e.g., assignment, method call), and control/data dependencies (e.g., producer/consumer of variables). An edge in 𝑃 is considered a match with an edge in 𝐺 if it has the same statement types at two ends and its edge type (control/data/structure) aligns with that in 𝐺. F1-score of the alignment is computed as: precision is the portion of matched edges in the adapted 𝑃 over its total edges, and recall is the ratio of matched edges in the ground-truth 𝐺 and its total. 9.1.3 Baselines. GPT-4o is used as the base LLM. With no existing tool, our baselines include: 1) A Chain-of-Thought-(CoT)-only baseline: This baseline represents a straightforward, LLMbased, minimal-context approach. We provided the SO code snippet to GPT-4o and only a Chainof-Thought prompt, which instructs the LLM to integrate the SO snippet into the target codebase. 2) Naive prompting baseline: This single-agent (also using CoT) is similar to the CoT-only baseline except that we also provided to GPT-4o the domain guidance, intent summarization, or context. 3) Two Copy-and-APR baselines: We simulate a baseline where the SO code is directly copied into the target codebase at the given location, and then an automated program repair (APR) tool is used to fix any errors. The objective is to evaluate if an APR tool can produce a fix as the final adaptation. We chose two APR approaches: Agentless [28] (a state-of-the-art LLM-based APR) and GPT-4o (we prompted it to fix any errors). We ran each tool five times and reported the mean values. 9.2

Empirical Results

9.2.1 Correctness of Adapted Code. As seen in Table 1, in the subset 𝐷𝑡 with 259 instances that include test cases, AdaptAgent achieves higher correctness of 65.2%, meaning that 65.2% of AdaptAgent-adapted code instances pass all corresponding test cases. For the subset 𝐷𝑚 with 693 instances without test cases, 62.3% Table 1. Correctness of Adapted Code. Test cases: Pass = apply + build of instances are judged correct + all tests. Adaptation Categories on semantically-correct outputs only. according to the semantics of Test cases Manual-check Adapt. Category (Counts) the human-adapted ground truth Approach Corr. (%) Corr. (%) CH CE EH LC Ref Misc via manual verification. We mea11.6 11.8 155 62 24 138 63 16 sured inter-rater reliability on CoT-only Naive⋆ 29.9 35.1 128 31 102 438 176 202 the manually checked instances Copy+APR⋆ 36.4 40.7 161 46 263 604 287 279 using Cohen’s Kappa. The two Agentless− NA 54.0 198 78 377 809 406 285 annotators achieved an observed Agentless+ 59.7 NA agreement of 86.9% and a Cohen’s AdaptAgent 65.2 62.3 743 183 353 993 432 171 Kappa of 0.72, indicating substanLegend: ⋆= w/ GPT-4o; AgentLess has two modes: − w/o test cases; += w/ test tial agreement. Notably, the test cases. CH=Code Hardening, CE=Compilation Errors, EH=Exception Handling, cases written by Github develop- LC=Logic Customization, Ref=Refactoring. Note: Category counts are not mutually exclusive (one instance may trigger multiple categories/types). ers were aimed to test the code adapted from Stack Overflow and they covered those adapted lines. The accuracy on instances without test cases is at a comparable Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:12

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

level to that on instances with test cases, suggesting that AdaptAgent’s performance is stable across the evaluations in two separate subsets. 9.2.2 Adaptation Categories. Table 2 indicates that adaptations can still be correct despite being divergent from the human reference. To understand these divergences, we analyzed AdaptAgent’s changes. Table 1 (right) reports the number of counts per adaptation category produced by our tool. We computed them using the categorization tool from Zhang et al. [36] on adaptation changes. Code Hardening. AdaptAgent correctly added defensive Table 2. Code Similarities between Adapted Code and Ground Truth programming (e.g., null checks, Test cases Manual-check API validations) where the ground Approach Result PDG AST C.BLEU Edit Result PDG AST C.BLEU Edit truth does not. The adapted code Pass 0.45 0.74 0.61 0.54 Corr 0.52 0.81 0.65 0.54 passes all the test cases and even CoT-only Fail 0.26 0.43 0.40 0.29 Incorr 0.32 0.45 0.46 0.35 conforms to good coding practice. Pass 0.68 0.80 0.60 0.56 Corr 0.70 0.82 0.65 0.53 This improvement comes from Naive⋆ Fail 0.28 0.31 0.35 0.31 Incorr 0.32 0.43 0.42 0.32 adaptation planning, where explicit guidance was provided to Pass 0.71 0.80 0.57 0.53 Corr 0.68 0.76 0.63 0.57 Copy+APR⋆ Fail 0.27 0.39 0.26 0.25 Incorr 0.34 0.50 0.39 0.33 LLM. We confirmed the impact of adaptation planning on Code Pass NA NA NA NA Corr 0.73 0.78 0.61 0.58 Agentless− Fail NA NA NA NA Incorr 0.40 0.51 0.46 0.40 Hardening in our ablation study. Exception Handling. Via doPass 0.72 0.81 0.58 0.56 Corr NA NA NA NA Agentless+ Fail 0.41 0.51 0.44 0.33 Incorr NA NA NA NA main-specific guidelines, the LLM is reminded of critical corner Pass 0.80 0.86 0.65 0.62 Corr 0.84 0.87 0.68 0.62 cases, e.g., defensive null checks, AdaptAgent Fail 0.48 0.64 0.50 0.42 Incorr 0.52 0.65 0.54 0.44 API-specific exceptions, and error Legend: ⋆= w/ GPT-4o; −= w/o test cases; += w/ test cases. PDG and AST: F1-scores for alignments. C.BLEU: CodeBLEU. handling. We also confirmed the impact of planning to improve Exception Handling in our ablation study. For example, we found the following correct plan by LLM: "Step 1: Check for Exception Handling: ClassNotFoundException is thrown but not caught within the method. Consider adding handling for this exception... Handle potential null pointer exceptions that may arise from the listFiles() method if it returns null. Step 2: Check for Code Hardening: Check if directory or packageName are null and handle appropriately to avoid runtime errors. Ensure the File object represents an actual directory before calling listFiles()..." Logic Customization. As an example, to adapt a hashing algorithm.getInstance API call, AdaptAgent correctly changed the algorithm selection via MessageDigest, shifting from "SHA256" to "SHA1" to match the intent. Moreover, the plan guided the model to adjust the type of sb, leading it to correctly update from StringBuffer to StringBuilder, which is more suitable for single-threaded scenarios. We later showed that intent summary helps improve logic customization (Section 11). Resolve Compilation Errors and Refactoring. These tasks seem manageable for modern LLMs. E.g., they perform renaming and extract methods, which might differ from the ground truth. 9.2.3 Similarity of Adapted Code. Table 2 shows that code similarity metrics for correct adaptations are higher than those for incorrect cases in both 𝐷𝑡 and 𝐷𝑚 . The separation indicates that static similarity metrics align with both oracles. As a coarse-grained sanity check using the outcomeconditioned means (8 points per oracle), the F1-score for PDG alignment shows the strongest positive association with the "pass" outcome (Pearson 𝑟 ≈0.934 on test outcomes and 𝑟 ≈0.925 on manual outcomes), and is similarly correlated on manual outcomes (𝑟 ≈0.908). This suggests that code similarity metrics can serve as useful proxy signals for correctness when test cases are unavailable. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:13

9.2.4 Comparative Results. We performed statistical significance testing using McNemar test on paired instance-level outcomes. We formed null hypotheses comparing our tool to each baseline in Table 1. The resulting p-values are 2.88e-114 for CoT-only variant, 9.07e-21 for Naive*, 2.91e-14 for Copy+APR, and 0.00951 for Agentless. Since all the p-values are below 0.01, we reject the respective null hypotheses, indicating that AdaptAgent performs better than each baseline. First, comparing AdaptAgent with all the baselines in Table 1, because they all use the same underlying LLM (GPT-4o), the observed gains cannot be attributed merely to stronger foundational model capacity. Instead, they indicate the effectiveness of AdaptAgent’s multi-agent workflow. Second, comparing the result of Naive* with CoT-only’s, the gain shows the positive contributions to the performance of adaptation intent summary, domain-specific guidance, and code context, which confirms our Key Ideas 1–3. Our ablation study (Section 11) will present the contribution of each individual factor. Third, comparing AdaptAgent with Naive*, we can assess the effectiveness of our multi-agent framework over a single-agent workflow equipped with the same intent summary, domain-specific guidance, and context. As seen, the multi-agent framework helps improve 35.3% and 27.2% more correct adaptation cases over the single agent in 𝐷𝑡 and 𝐷𝑚 , respectively. Specifically, as seen in Table 1, AdaptAgent achieves 63.1% semantic correctness, i.e., it has 5.5%-53.6% and 8.3%-50.5% more correct adaptation cases than the baselines in 𝐷𝑡 and 𝐷𝑚 , respectively. The advantage is also reflected in static code similarity (Table 2): for the correct adaptation code in 𝐷𝑡 , AdaptAgent attains higher similarity than every baseline across dependency similarity 11.1%–77.8%, syntactic similarity 6.2%–16.2%, and lexical similarity 6.6%–17.0%. The same observation holds for correct instances in 𝐷𝑚 , and the same general trend also appears when comparing similarity for incorrect instances. Note that for correctly adapted code (in both 𝐷𝑡 and 𝐷𝑚 ), despite not being perfect, it achieves the highest code similarities (dependency, syntactic, and lexical similarities) (Table 2). For example, in 𝐷𝑡 , the code similarities average 80.5%, 86%, and 65%, and in 𝐷𝑚 they are 84%, 87%, and 68%, respectively. This suggests that AdaptAgent produces adaptations that are not only more often correct, but also more structurally and semantically aligned with developers’ ground truth. In brief, these performance gaps indicate that AdaptAgent’s structured adaptation process yields more reliable correctness under both evaluation settings. 9.2.5 Qualitative Analysis. Table 1 (right) helps explain where these gains come from. The baselines frequently miss key steps such as Refactoring and Resolve Compilation Error, and—without explicit guidance—rarely add Code Hardening or Exception Handling proactively. In contrast, AdaptAgent performs better on these categories because its guidelines explicitly prompt the LLM to consider code building, robustness checks, and defensive handling, which are often needed. For Logic Customization, we observe an additional qualitative difference. While the baselines generate a large number of instances in this category, they often compensate in brittle ways: they introduce extra APIs or helper functions to replace missing method invocations rather than using the existing package ecosystem, or they replace meaningful constants with placeholder values. These choices may “patch” compilation or produce superficially plausible code, but they frequently drift away from the intended behavior and from project-consistent API usage. In contrast, AdaptAgent most consistently performs direct calls to methods already existing in the target project. By leveraging the context summarizer, AdaptAgent tends to select calls matching the local style and conventions in the file, leading to better alignment with developers’ adapted code. Another key limitation of the baselines is that they often fail to preserve the adaptation intent expressed by users. For example, consider a case where a user reports a type error arising from use of the Java class PrintWriter and the corresponding Stack Overflow answer recommends switching to a FileWriter wrapped by a BufferedWriter. Without incorporating this intent, none of the baselines reliably extract or apply the recommendation; they keep using PrintWriter in the adapted code, Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:14

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

Fig. 6. Adaptation Category Distributions: Human Adaptation versus Adaptation by AdaptAgent (RQ2)

which can reproduce the same type error. In contrast, AdaptAgent is designed to carry intent through the pipeline, enabling it to make the specific substitution that resolves the root cause rather than producing an adaptation that remains behaviorally inconsistent with the user’s goal. 9.2.6 Unique Adaptation Analysis. Among all correct adaptation samples (601), we identified 59 cases uniquely adapted by AdaptAgent in which no baseline approach achieved. Of these unique ones, 14 occur in the test-suite subset and 45 occur in the manual subset. From these unique instances, we observed that: (1) 40 cases were successfully adapted due to improvements in Logic Customization; (2) 16 cases benefited from stronger Exception Handling; (3) 15 cases were resolved through more effective Code Hardening; (4) 9 cases involved Resolving Compilation Errors; and (5) 21 cases were improved through refined Refactoring (categories can overlap within an instance). 9.2.7 Limitations. For the incorrect instances in 𝐷𝑡 and 𝐷𝑚 by AdaptAgent, we observe several recurring failures in the adapted code. The most common cause of test failure is that the new project does not build; the top three underlying reasons are (1) API misuse, (2) unresolved dependencies, and (3) signature mismatches. On further inspection, we also find cases where, despite receiving instructions that cover multiple adaptation categories, AdaptAgent does not fully follow them or introduces incorrect changes for specific categories. We defer to Section 10 the details of these mismatches, especially where AdaptAgent’s adaptations diverge from real developer changes. 10

Tool Adaptation versus Human Adaptation (RQ2)

In this experiment, we study the adaptation effectiveness of AdaptAgent by analyzing how close real developers and AdaptAgent perform various adaptation types, rather than just the final adaptation. To achieve this, we applied Zhang et al. [37]’s tool to detect different adaptation categories in both real developer-adapted code and the code produced by AdaptAgent. Fig. 6 displays the counts of different adaptation categories that were performed by GitHub developers and by AdaptAgent. Statistical Test. To assess whether our tool’s adaptation result aligns with that of humans, we compared the distributions of adaptation categories across the two groups. We have two lists of counts, where each number corresponds to the frequency of one of 24 specific adaptation types, with one list derived from human-adapted code and the other from our tool’s. To that end, we computed both Spearman’s rank correlation and Pearson’s correlation between the two frequency vectors. If we considered 5 main adaptation categories with respect to their sub-categories (excluding the “Misc” main category), Spearman’s test yielded 𝜌=0.913 with 𝑝=5.1×10−8 , and Pearson’s test yielded 𝑟 =0.858 with 𝑝=2.7 × 10−6 , both indicating a strong and statistically significant positive association between the two distributions. Thus, the null hypothesis that there is no association between the human and tool adaptation frequencies can be rejected. This result suggests that our tool is effective in producing adaptation patterns that are strongly aligned with those observed in human behavior. If Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:15

the “Misc” main category is included, Spearman’s test yielded 𝜌=0.591 with 𝑝=0.0018, and Pearson’s test yielded 𝑟 =0.613 with 𝑝=0.0014, showing a moderate association. This is expected because the adaptation types in “Misc” (logging, style formatting, comments) are project-specific. What are the Differences? We analyzed the correctly adapted cases in both 𝐷𝑡 (test cases) and 𝐷𝑚 (manual-check) in which the numbers of adaptation types by the tool and humans are different. We observed that our tool produces useful code including exception handling, defensive checks, etc. (similar to the results in Sections 9.2.1 and 9.2.2), which still passes all the test cases. These extra edits typically close resources or wrap I/O in try{...}catch{...} blocks, which improve robustness, but also introduce false-positive edges, explaining why code similarity is not perfect. Moreover, as seen Fig. 6, our tool suggests more of the following adaptation types than actual humans’ adaptation, many of which are useful: 1) handle a new exception type (98 vs 60), 2) clean-up unmanaged resources (4 vs 3), 3) insert try-catch (100 vs 52), 4) change catch blocks (98 vs 47) and 5) add conditions (364 vs 167). The analysis on additional changes by AdaptAgent is presented later. In comparison, Agentless performs 809 logic customizations (184 fewer than AdaptAgent and 276 fewer than developers) while inflating Miscellaneous changes (e.g., comments, logging, formatting) to 285, much higher than 171 in AdaptAgent. At the same time, the shortfall in logic customizations means Agentless fails to recover many of the true behavioral dependencies. Additional Adaptation Changes from AdaptAgent. This section presents a targeted analysis of whether AdaptAgent’s additional adaptation changes in Code Hardening (CH) and Exception Handling (EH) are useful in preventing run-time errors/crashes. For Code Hardening, humans applied 315 changes, whereas AdaptAgent produced 743, i.e., 428 extra changes. For Exception Handling, humans applied 167 changes, whereas AdaptAgent produced 353, more than the human-written adaptations. To assess to what degree these additional changes are necessary, we conducted an run-time experiment as follows. We first identified the set of Code Hardening changes introduced by AdaptAgent but not present in the respective human-adapted snippets. We then retained only those snippets whose target projects are compilable and have executable test cases, yielding 188 unique extra CH instances. We performed the same procedure for Exception Handling, obtaining 106 unique extra EH instances. We denote the resulting sets by 𝐷𝐶𝐻 and 𝐷 𝐸𝐻 , respectively. For each code snippet 𝑐𝑒 ∈ 𝐷𝐶𝐻 , we identified its corresponding human-adapted code 𝑐𝑜 in our dataset, where the Code Hardening change by AdaptAgent is absent. We then prompted GPT-4o with each pair of snippets (𝑐𝑜 , 𝑐𝑒 ) to generate an input that would trigger an error in 𝑐𝑜 but not in 𝑐𝑒 thanks to the extra Code Hardening, thereby testing whether the added hardening logic prevents a failure that could otherwise occur. Similarly, for each code snippet in 𝐷 𝐸𝐻 , we prompted GPT-4o to generate an input that would trigger an exception in the human version 𝑐𝑜 but not in the tool-adapted version 𝑐𝑒 , thereby evaluating the necessity and correctness of the added Exception Handling logic. We repeated each prompting process at most 3 times and reported the number of cases in which the enhanced version 𝑐𝑒 , augmented with the additional Code Hardening or Exception Handling logic, successfully avoided the runtime errors or exceptions triggered in 𝑐𝑜 . Table 3 shows that a substantial portion of the additional adaptation logic by AdaptAgent is indeed useful. For Code Hardening (CH), in 40.3% of the 188 extra CH instances, the enhanced version 𝑐𝑒 successfully avoided a runtime failure that occurred in the human version 𝑐𝑜 , showing that the added hardening logic was needed for the execution under realistic inputs. For Exception Handling (EH), this effect was observed in 44.8% of the 106 extra EH instances, where the added exceptionhandling logic in 𝑐𝑒 successfully prevented an exception triggered in 𝑐𝑜 . These results suggest that the extra CH and EH changes by AdaptAgent often provide meaningful robustness improvements. Overall, they show AdaptAgent’s usefulness in generating necessary Code Hardening and Exception Handling logic beyond what might actually be missed by humans. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:16

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

Table 3. Usefulness of additional Code Hardening and Exception Handling code introduced by AdaptAgent.

11

Adaptation Category

Additional CH or EH instances

Errors Triggered

Code Hardening Exception Handling

188 106

40.3% 44.8%

Ablation Study (RQ3)

AdaptAgent consists of four critical agents: the adaptation plan 𝒴 via Planner, adaptation intent ℐ via Summarizer, the code context 𝒞 via Cxt Miner, and Adapter agent. Because Code Adapter cannot be removed, to systematically evaluate the importance of each agent, we removed each of other agents separately, creating three variants: 1) without Planner, 2) without Summarizer, and 3) without context. Table 4 and Fig. 7 show how each agent uniquely impacts adaptation performance. 11.1

Impact of Agents

We performed statistical significance test on Table 4 using the McNemar test on paired instancelevel outcomes. The p-values are 6.84e-05 for “w/o Planner”, 1.79e-07 for “w/o Summarizer”, and 6.12e-04 for “w/o Context Miner”. Since all p-values are below 0.01, we reject the corresponding null hypotheses, concluding that the ablation variants performed worse than AdaptAgent. 11.1.1 Adaptation Plan via Planner agent. The removal of the Plan- Table 4. Ablation Study on Correctness (RQ3). Test cases: Corr. = apply ner agent from our pipeline sig- +build+all tests. Adapt. Categories on semantically-correct outputs only. nificantly decreases correctness in Test cases Manual-check Adapt. Category (Counts) the Code Hardening and Excep- Variant Corr. (%) Corr. (%) CH CE EH LC Ref Misc tion handling categories, making 52.4 51.0 173 38 257 728 307 229 them similar to naive prompt- w/o Planner w/o Summarizer 46.7 47.6 558 139 276 511 322 151 ing’s results. The analysis on w/o Ctx Miner 49.8 56.8 627 158 368 706 284 193 adaptation types in Fig. 7 reinLegend: Variants remove one component from AdaptAgent: Planner forces this observation: without (adaptation plan), Summarizer (intent), or Ctx Miner (semantic context). adaptation planning, the adaptaCH=Code Hardening, CE=Compilation Errors, EH=Exception Handling, LC=Logic Customization, Ref=Refactoring. Note: Category counts are tion missed more on crucial adapaggregated type-level edits; counts are not mutually exclusive. tation types like “add a conditional,” “handle a new exception type,” and “insert/delete try-catch blocks”. Comparing Fig. 6 and Fig. 7, these adaptation types observe a sharp decline of 33.5%–75.4%. This confirms our idea that structured planning guides LLMs to perform critical adaptation steps on Code Hardening and Exception Handling. 11.1.2 Adaptation Intent via Summarizer agent. Without incorporating adaptation intent ℐ created by the Summarizer agent, performance in Logic Customization notably drops by 30.8%–70.8% more compared to the two other variants. Fig. 7 shows a decrease in the adaptation type “change method call”, indicating that the model relies heavily on the high-level, abstract information provided by the intent to modify API calls or conditional logic accurately. 11.1.3 Structural Information of Codebase and Context via Context Miner agent. Excluding structural context (sibling methods of the target code), considerably affects adaptations, evident in adaptation types such as “change method call,” “specify target of method call,” and “change access modifiers.” Comparing Fig. 6 and Fig. 7 demonstrates a clear drop in these adaptation types, nearly comparable to the absence of intent. The correctness does not drastically decline. However, without structural context via Context Miner, the LLM lacks essential guidance on program semantics. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:17

Fig. 7. Adaptation Type Distribution in Ablation Study (RQ3) Table 5. Correctness by Line Number and by Number of Code Hunks in Adapted Code (RQ4) (A) Performance by Line Numbers <10 11-20 21-30 31-40 41-50 51-60 61-70 >71 79.9 71.7 68.0 65.1 61.8 58.3 53.4 46.7

(B) Performance by Number of Hunks 𝑁 =1 𝑁 =2 𝑁 =3 𝑁 =4 𝑁 =5+ 73.3 64.6 51.9 40.1 33.3

11.1.4 Combination. Our results also reveal the scenarios where adaptation intent via Summarizer agent and code context via Context Miner agent have compound impacts. For example, when both intent and code context are provided (i.e., w/o Planner in Fig. 7), the category “change method call” achieves the highest frequency among the three variants, indicating that these two agents significantly aid the LLM in correctly identifying necessary APIs. Similarly, in adaptations involving “type resolution,” both intent and context independently yield comparable improvements, meaning better understanding of the user package and type resolution due to the awareness of the target code. Our results show that the adaptation plan with Planner serves as a structured template guiding LLMs’ reasoning, while adaptation intent with Summarizer and code context with Ctx Miner provide complementary high-level and low-level details, helping the model make correct adaptations. 11.2

Comparison on Impacts of Agents

11.2.1 Planner vs Summarizer. For tasks like “add thrown exceptions” “change method calls,” and “declare a type,” Planner seems more critical than Summarizer. This suggests that while understanding what the user wants (intent) is important, knowing how to achieve it (planning) is even more crucial for these specific adaptations, as Summarizer is most critical for logic changes (e.g., method-call changes). 11.2.2 Summarizer vs Context Miner. The Summarizer can drive Logic Customization, indicating that the LLM benefits more from capturing the user’s adaptation goal than from additional targetcode context, improving strongly in correctness via test cases. In contrast, Ctx Miner can support the integration for tasks such as renaming, inserting a final modifier, updating exception types. 12

Stratified Performance Analysis on Adaptation Complexity (RQ4)

In this experiment, we assess how well our tool performs on the adaption changes involving multiple lines and hunks of code. We stratified the result in RQ1 into different groups with respect to numbers of lines and numbers of hunks in the diff patches returned from AdaptAgent. Performance by Adaptation Complexity in terms of LOCs. The smallest adaptation change involved 4 LOCs, while the largest spanned 220 lines, with an average of 42 lines per instance. As seen in Table 5(A), our tool achieves 79.9% correctness for minimal adaptation changes (<10 lines) and maintains high scores for medium changes (71.7% for 11-20 lines, 68.0% for 21-30 lines, 65.1% Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:18

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

for 31-40 lines, and 61.8% for 41-50 lines). However, the correctness drops much to 58.3% for the adaptations with 51-60 lines and drops to 46.7% for adaptation changes exceeding 71 lines. Interestingly, the 61–70 line range achieves a higher correctness despite being longer because its 5 instances involve comparably simpler edits. To further understand this performance drop, we conducted a category-wise analysis. For changes under 50 lines, AdaptAgent typically handles only 1.6 adaptation categories with on average 3.6 adaptation types on average. However, for changes exceeding 50 lines, the number of adaptation categories increases to 2.9, involving an average of 7.9 adaptation types per instance. This makes the adaptation significantly more complex. Notably, for large code, AdaptAgent struggles the most with Logic Customization, particularly when adapting API calls into the target code. Performance by Adaptation Complexity in terms of Hunks. Table 5(B) presents AdaptAgent’s performance across different patch complexities, measured by the number of hunks of code changes for adaptation. For single-hunk adaptation (𝑁 =1), it achieves an correctness of 73.3%. Each hunk modifies between 1–103 lines of code, with an average modification of 18 lines. Thus, it performs well even with a large number of consecutive lines for a single-hunk adaptation. When the adaptation involves two hunks (𝑁 =2), the performance drops from 73.3% to 64.6%. This is because most two-hunk patches involve modifying import statements and implementing the function body. However, with three hunks (𝑁 =3), the performance drops significantly to 51.9%, and further declines to 40.1% at 𝑁 =4. For patches with more than four hunks (𝑁 >=5), it drops to 33.3%. This decline occurs because, in more complex adaptations, AdaptAgent starts modifying unrelated sections of the method. This decline correlates with the structural complexity of the adaptation. For instance, the average code length at 𝑁 =1 is 43 lines, while at 𝑁 ≥ 5 it increases to 61 lines, with a 41.9% increase. However, during the same progression, the correctness decreases from 73.3% to 33.3%, a relative 120% decrease. This suggests that when edits are localized (fewer hunks), the model is better at preserving the structural alignment implied by the intent. However, as adaptations spread across more hunks, especially into unrelated blocks in the method, the model struggles to maintain consistent adaptation. 13

Correctness of Adaptation Plan Generated by the Planner Agent (RQ5)

In this experiment, we evaluate the correctness of the generated adapta- Table 6. Quantitative Analysis on Micro Reasoning of Planner tion plans by the Planner agent re- and Adapter. CH: Code Hardening, CE: Compiling Errors, EH: garding the six adaptation categories. Exception Handling, LC: Logic Customization, REF: Refactoring. To achieve the confidence level of 95% with the margin of error of 5%, Adaptation Type→ CH CE EH LC REF MISC and the population proportion of 50%, Agent↓ we randomly selected 274 adapta- Planner correct 179 199 147 246 186 165 correct 165 190 134 187 160 140 tion instances among 952 instances Adapter missing 14 9 13 59 26 25 in RQ1 for manual checking by an extra 77 23 42 62 31 22 independent evaluator. The model’s reasoning in texts (see Fig. 8 for an example) was assessed to validate if the reasoning correctly constitutes any adaptation category in Zhang et al. [37]. Specifically, for the planning steps from the Planner, (s)he counted the number of incorrect instances in planning if the plan misclassified a needed change, omitted a needed step, added an unnecessary step, or sequenced steps incorrectly relative to the ground truth. As seen in Table 6, the planning steps for Logic Customization are the most correct (246/274), while Exception Handling is more challenging for the Planner (147/274). In Logic Customization, Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:19

instead of correctly removing an undefined variable, it attempts to initialize and integrate it into the existing method, potentially altering the original functionality. For Code Hardening, Compiling Errors, and Refactoring, the Planner performs reasonably well (179-199 over 274). Additionally, each portion of the generated adaptation of each instance (in generated source code) is mapped with each planning step (in texts) in each adaptation category to examine the cases where the Planner provides correct reasoning, yet the Adapter does not produce the correct adapted code. The Adapter adapts Compilation Errors, Code Hardening, and Exception Handling with relatively high fidelity, while Logic Customization has the largest missing gap. In Table 6, among 179 correctly 1 1. **Code Hardening**: planned instances for Code Hardening, 2 - Add validation to check if the `encrypted` byte array is null or empty. 165 of them have the correctly gen- 3 Validate that `keyIn` is not null before attempting to use. erated adaptation code. 14 instances 4 - Ensure the `password` array is not null before calling `findSecretKey` . have missed Code Hardening, while 5 - Handle potential resource leaks by making sure `InputStream` and `ByteArrayOutputStream` are closed in 77 of them have extra ones. For Exa finally block or using try-with-resources. ... ception Handling, among 147 correctly 6 3. **Exception Handling**: planned instances, 134 are correctly 7 - Wrap the method body in a try-catch block to handle specific exceptions and provide meaningful error messages. adapted, while 13 are missed and 42 ex- 8 - Consider handling `PGPDataValidationException` separately if it can occur in this context. tra Exception Handling are introduced. that `PGPException` and `NoSuchProviderException` We further investigated the error 9 - Ensure are appropriately handled if they are not directly thrown by this method but during library usage.... patterns from the Adapter. A common 5. **Refactoring**: error in Logic Customization is that 10 11 - Ensure that `sKey` and `pbe` are properly initialized with values to prevent null references before usage. a variable should have been declared variables to more descriptive names, for instance, at the file level; however, the Adapter 12 - Rename rename `in` to `decodedStream`, `o` to `decryptObj`. added it as a final modifier, a local vari- 13 - Break down the method into smaller private helper methods to increase readability, such as `getPrivateKey`, able, or an input parameter. The other `getPgpObjectFactory`, etc.... errors include “not updating String value”, “missing repo-level APIs”, and Fig. 8. A Natural-language Adaptation Plan by Planner Agent “incorrect changing types”. For Exception Handling, the common mistake is an exception type mismatch with the ground truth. 14

Threats to Validity

Internal Validity. A potential threat concerns data leakage. We showed the results of both GPT-4o with naive prompting and AdaptAgent, which increases the total number of correct adaptations in all types. This shows that the improvement stems from our workflow rather than GPT-4o’s pre-trained knowledge alone. GPT-4o’s underperformance suggests a low risk of data leakage. In our dataset, not all the code instances have test cases, we had to manually check the subset 𝐷𝑚 . External Validity. While our Java dataset may not be representative, it was comprehensively collected by Zhang et al. [37] from real-world SO posts and humans’ adaptations. Similarly, we evaluated only on Java and GPT-4o, and results may vary with other models on other languages. For example, our implementation did not support Python thus we did not use AdaptEval dataset [35]. Construct Validity. Another risk lies in the design of prompts, whose variations in wording and level of detail can affect the results. For mitigation, we standardized prompts across models. To handle non-determinism, we executed the LLMs five times and reported the mean values. We rely on the posts’ content, making it dependent on their quality. It may under-perform when SO posts lack sufficient context or when adaptation involves complex domain-specific reasoning. For instance, if the code switches from one API to another, without mentioning it in the text, the LLM cannot infer the intent. The adaptions requiring multiple hunks are also challenging. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:20

15

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

Related Work

Studies on quality of SO code examples. Verdi et al. [26] analyzed 1,325 SO answers and found 99 vulnerable snippets that propagated to 2,589 GitHub repositories. [7] detected 14,719 insecure code snippets from 1,958,283 SO posts, confirming that 151 out of 2,000 popular C/C++ projects contained at least one insecure snippet. Similarly, 15.4% of 1.3 million Android apps were found to include security-related SO code [6]. Ragkhitwetsagul et al. [20] also reported that S/O code imported into GitHub projects often contains defects, vulnerabilities, performance issues. Studies on Online Code Adaptation. Zhang et al. [37] manually examine SO snippets and their GitHub counterparts, proposing a taxonomy of 24 adaptation types across 6 categories. Zhang et al. [34] analyze 300 code reuse cases with 1,384 adaptations and find that adaptation patterns are repetitive, which benefits automatic adaptation. Li et al. [13] report that developers’ ability to identify helpful posts for debugging varies based on expertise levels. Tool supports for SO code examples. Cai et al. [4] develop a BERT-based tool to automatically wrap SO code snippets with try-catch blocks and handle exceptions. Huang et al. [10, 11] fine-tune a code masked language model (MLM) for type inference in statically-typed partial code using a “pre-train, prompt, and predict” paradigm. Venigalla et al. [25] introduce StackEmo, a Chrome plugin that adds sentiment-based emojis to SO comments. Horvath et al. [8] create Meta-Manager, which tracks and organizes code changes, including AI-generated and copy-pasted code. Mahajan et al. [18, 19]’s MAESTRO suggests the most relevant SO post for a given Java RE. TechSumBot [31] aids in usefulness ranking, centrality estimation, and redundancy removal for technical Q&A. NLP2TestableCode [21] search for code in SO and modify snippets to improve fit and correct errors. For code adaptation, one could copy a code snippet into a codebase and leverage an automated program repair (APR) tool for correction. We compared AdaptAgent with such an approach in our experiments. According to the survey by Huang et al. [9], learning-based APR is better than traditional non-AI APR on some dimensions, especially lower patch overfitting and better generality. For example, ARJA [33] uses the partial fixes in the same codebase. Moreover, ARJA requires the test cases, which are available for about 25% of our dataset. 16

Conclusion

We present AdaptAgent, a knowledge-guided, intent-aware, and context-driven agentic framework that leverages LLMs to automate code adaptation from online forums to a target codebase. Our findings show that simply prompting LLMs to adapt a given code snippet yields suboptimal results, often missing critical modifications. By incorporating adaptation guidelines, capturing adaptation intent via textual summarization, and providing the semantic context, we enable LLMs to generate a structured and accurate adaptation plan, leading to better adaptation. Significance and Impact. First, our agentic framework to integrating domain-specific guidance and semantic context can be extended to broader software maintenance tasks that involve code changes, such as automatic program repair, automated code refactoring, and API or framework migration, etc. Second, its structured LLM-based planning for code changes can enhance AI-assisted IDEs by improving reasoning about multi-step modifications, suggesting code changes. Third, our principles can be applied to improve program repair by guiding LLMs to understand the root causes of defects and propose context-aware bug-fixing change plans and actual fixes. Finally, the cost of our approach is also reasonable. Our experiment costs $47 (in terms of API calls, latency, and token consumption), i.e., $0.05 per instance. The cost of naive prompting is $14.7, i.e., $0.018 per instance. 17

Data Availability

Data/code is available in project’s website [3]. Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation

ISSTA193:21

References [1] 2015. draw on canvas without removing the background image on erase function. https://stackoverflow.com/questions/ 29764243/draw-on-canvas-without-removing-the-background-image-on-erase-function/29790350#29790350 [2] 2015. JustWeTools. https://github.com/lfkdsk/JustWeTools/blob/master/justwetools/src/main/java/com/lfk/justwetools/ View/NewPaint/Graph/DrawPath.java#L41-L59 [3] Anonymous. 2026. Code Adaptation Repository. https://anonymous.4open.science/r/Code-Adaptation-5E32/README. md [4] Yuchen Cai, Aashish Yadavally, Abhishek Mishra, Genesis Montejo, and Tien Nguyen. 2024. Programming Assistant for Exception Handling with CodeBERT. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New York, NY, USA, Article 94, 13 pages. doi:10.1145/3597503.3639188 [5] Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin, Jian-Guang Lou, and Weizhu Chen. 2022. CodeT: Code Generation with Generated Tests. arXiv:2207.10397 [cs.CL] https://arxiv.org/abs/2207.10397 [6] Felix Fischer, Konstantin Böttinger, Huang Xiao, Christian Stransky, Yasemin Acar, Michael Backes, and Sascha Fahl. 2017. Stack Overflow Considered Harmful? The Impact of Copy&Paste on Android Application Security. In Proceedings of the 2017 IEEE Symposium on Security and Privacy. IEEE Computer Society, 121–136. [7] Hyunji Hong, Seunghoon Woo, and Heejo Lee. 2021. Dicos: Discovering Insecure Code Snippets from Stack Overflow Posts by Leveraging User Discussions. In Proceedings of the 37th Annual Computer Security Applications Conference (, Virtual Event, USA,) (ACSAC ’21). Association for Computing Machinery, New York, NY, USA, 194–206. doi:10.1145/ 3485832.3488026 [8] Amber Horvath, Andrew Macvean, and Brad A Myers. 2024. Meta-Manager: A Tool for Collecting and Exploring Meta Information about Code. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI ’24). Association for Computing Machinery, New York, NY, USA, Article 929, 17 pages. doi:10.1145/3613904.3642676 [9] Kai Huang, Zhengzi Xu, Su Yang, Hongyu Sun, Xuejun Li, Zheng Yan, and Yuqing Zhang. 2024. Evolving Paradigms in Automated Program Repair: Taxonomy, Challenges, and Opportunities. ACM Comput. Surv. 57, 2, Article 36 (Oct. 2024), 43 pages. doi:10.1145/3696450 [10] Qing Huang, Zhiqiang Yuan, Zhenchang Xing, Xin Peng, Xiwei Xu, and Qinghua Lu. 2023. FQN Inference in Partial Code by Prompt-tuned Language Model of Code. ACM Trans. Softw. Eng. Methodol. 33, 2, Article 31 (Dec. 2023), 32 pages. doi:10.1145/3617174 [11] Qing Huang, Zhiqiang Yuan, Zhenchang Xing, Xiwei Xu, Liming Zhu, and Qinghua Lu. 2023. Prompt-tuned Code Language Model as a Neural Knowledge Base for Type Inference in Statically-Typed Partial Code. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (Rochester, MI, USA) (ASE ’22). Association for Computing Machinery, New York, NY, USA, Article 79, 13 pages. doi:10.1145/3551349.3556912 [12] Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. 2023. Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916 [cs.CL] https://arxiv.org/abs/2205.11916 [13] Annie Li, Madeline Endres, and Westley Weimer. 2022. Debugging with stack overflow: web search behavior in novice and expert programmers. In Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: Software Engineering Education and Training (Pittsburgh, Pennsylvania) (ICSE-SEET ’22). Association for Computing Machinery, New York, NY, USA, 69–81. doi:10.1145/3510456.3514147 [14] Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang. 2024. Hybrid Automated Program Repair by Combining Large Language Models and Program Analysis. arXiv:2406.00992 [cs.SE] https://arxiv.org/abs/2406.00992 [15] Yi Liang, You Wu, Honglei Zhuang, Li Chen, Jiaming Shen, Yiling Jia, Zhen Qin, Sumit Sanghai, Xuanhui Wang, Carl Yang, and Michael Bendersky. 2024. Integrating Planning into Single-Turn Long-Form Text Generation. arXiv:2410.06203 [cs.CL] https://arxiv.org/abs/2410.06203 [16] Changshu Liu, Pelin Cetin, Yogesh Patodia, Saikat Chakraborty, Yangruibo Ding, and Baishakhi Ray. 2024. Automated Code Editing with Search-Generate-Modify. arXiv:2306.06490 [cs.SE] https://arxiv.org/abs/2306.06490 [17] Zheheng Luo, Qianqian Xie, and Sophia Ananiadou. 2023. ChatGPT as a Factual Inconsistency Evaluator for Text Summarization. arXiv:2303.15621 [cs.CL] https://arxiv.org/abs/2303.15621 [18] Sonal Mahajan, Negarsadat Abolhassani, and Mukul R. Prasad. 2020. Recommending stack overflow posts for fixing runtime exceptions using failure scenario matching. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Virtual Event, USA) (ESEC/FSE 2020). Association for Computing Machinery, New York, NY, USA, 1052–1064. doi:10.1145/3368089.3409764 [19] Sonal Mahajan and Mukul R. Prasad. 2022. Providing Real-time Assistance for Repairing Runtime Exceptions using Stack Overflow Posts. In 2022 IEEE Conference on Software Testing, Verification and Validation (ICST). 196–207. doi:10. 1109/ICST53961.2022.00030

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

ISSTA193:22

Xiaokai Rong, Hridya Dhulipala, Aashish Yadavally, and Tien N. Nguyen

[20] Chaiyong Ragkhitwetsagul, Jens Krinke, Matheus Paixao, Giuseppe Bianco, and Rocco Oliveto. 2021. Toxic Code Snippets on Stack Overflow. IEEE Transactions on Software Engineering 47, 3 (2021), 560–581. doi:10.1109/TSE.2019. 2900307 [21] Brittany Reid, Christoph Treude, and Markus Wagner. 2020. Optimising the fit of stack overflow code snippets into existing code. In Proceedings of the 2020 Genetic and Evolutionary Computation Conference Companion (Cancún, Mexico) (GECCO ’20). Association for Computing Machinery, New York, NY, USA, 1945–1953. doi:10.1145/3377929.3398087 [22] Caitlin Sadowski, Kathryn T. Stolee, and Sebastian Elbaum. 2015. How developers search for code: a case study. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (Bergamo, Italy) (ESEC/FSE 2015). Association for Computing Machinery, New York, NY, USA, 191–201. doi:10.1145/2786805.2786855 [23] Zirui Song, Bin Yan, Yuhan Liu, Miao Fang, Mingzhe Li, Rui Yan, and Xiuying Chen. 2025. Injecting Domain-Specific Knowledge into Large Language Models: A Comprehensive Survey. arXiv:2502.10708 [cs.CL] https://arxiv.org/abs/ 2502.10708 [24] Haoye Tian, Weiqi Lu, Tsz On Li, Xunzhu Tang, Shing-Chi Cheung, Jacques Klein, and Tegawendé F. Bissyandé. 2023. Is ChatGPT the Ultimate Programming Assistant – How far is it? arXiv:2304.11938 [cs.SE] https://arxiv.org/abs/2304.11938 [25] Akhila Sri Manasa Venigalla and Sridhar Chimalakonda. 2021. StackEmo: towards enhancing user experience by augmenting stack overflow with emojis. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (Athens, Greece) (ESEC/FSE 2021). Association for Computing Machinery, New York, NY, USA, 1550–1554. doi:10.1145/3468264.3473119 [26] Morteza Verdi, Ashkan Sami, Jafar Akhondali, Foutse Khomh, Gias Uddin, and Alireza Karami Motlagh. 2022. An Empirical Study of C++ Vulnerabilities in Crowd-Sourced Code Examples. IEEE Trans. Software Eng. 48, 5 (2022), 1497–1514. [27] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, and Denny Zhou. 2023. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 [cs.CL] https://arxiv.org/abs/2201.11903 [28] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying LLM-Based Software Engineering Agents. Proc. ACM Softw. Eng. 2, FSE, Article FSE037 (June 2025), 24 pages. doi:10.1145/3715754 [29] Junjielong Xu, Ying Fu, Shin Hwei Tan, and Pinjia He. 2025. Aligning the Objective of LLM-based Program Repair. arXiv:2404.08877 [cs.SE] https://arxiv.org/abs/2404.08877 [30] Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. 2014. Modeling and Discovering Vulnerabilities with Code Property Graphs. In IEEE Symposium on Security and Privacy. IEEE Computer Society, 590–604. [31] Chengran Yang, Bowen Xu, Ferdian Thung, Yucen Shi, Ting Zhang, Zhou Yang, Xin Zhou, Jieke Shi, Junda He, Donggyun Han, and David Lo. 2023. Answer Summarization for Technical Queries: Benchmark and New Approach. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (Rochester, MI, USA) (ASE ’22). Association for Computing Machinery, New York, NY, USA, Article 8, 13 pages. doi:10.1145/3551349.3560421 [32] Fangkai Yang, Pu Zhao, Zezhong Wang, Lu Wang, Jue Zhang, Mohit Garg, Qingwei Lin, Saravan Rajmohan, and Dongmei Zhang. 2023. Empower Large Language Model to Perform Better on Industrial Domain-Specific Question Answering. arXiv:2305.11541 [cs.CL] https://arxiv.org/abs/2305.11541 [33] Yuan Yuan and Wolfgang Banzhaf. 2020. ARJA: Automated Repair of Java Programs via Multi-Objective Genetic Programming. IEEE Transactions on Software Engineering 46, 10 (2020), 1040–1067. doi:10.1109/TSE.2018.2874648 [34] Tanghaoran Zhang, Yao Lu, Yue Yu, Xinjun Mao, Yang Zhang, and Yuxin Zhao. 2024. How Do Developers Adapt Code Snippets to Their Contexts? An Empirical Study of Context-Based Code Snippet Adaptations. IEEE Trans. Softw. Eng. 50, 11 (Nov. 2024), 2712–2731. doi:10.1109/TSE.2024.3395519 [35] Tanghaoran Zhang, Xinjun Mao, Shangwen Wang, Yuxin Zhao, Yao Lu, Jin Zhang, Zhang Zhang, Kang Yang, and Yue Yu. 2025. AdaptEval: A Benchmark for Evaluating Large Language Models on Code Snippet Adaptation. In Proceedings of the 40th ACM/IEEE International Conference on Automated Software Engineering (ASE 2025). IEEE CS. [36] Tianyi Zhang, Di Yang, Crista Lopes, and Miryung Kim. 2019. Analyzing and Supporting Adaptation of Online Code Examples. In Proceedings of the 41st International Conference on Software Engineering (ICSE ’19). IEEE Press, 316–327. doi:10.1109/ICSE.2019.00046 [37] Tianyi Zhang, Di Yang, Crista Lopes, and Miryung Kim. 2019. Analyzing and supporting adaptation of online code examples. In Proceedings of the 41st International Conference on Software Engineering (Montreal, Quebec, Canada) (ICSE ’19). IEEE Press, 316–327. doi:10.1109/ICSE.2019.00046 [38] Suzhen Zhong, Ying Zou, and Bram Adams. 2025. Developer-LLM Conversations: An Empirical Study of Interactions and Generated Code Quality. arXiv:2509.10402 [cs.SE] https://arxiv.org/abs/2509.10402

Received 2026-01-30; accepted 2026-06-25

Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026.

Related documents

• Projecting the Emerging Mindset of SWE Agent by Launching a Wild Code Understanding Journey#267724
• Developing LLM-based Multi-Agent Systems in Software Engineering: A Mixed-Method Experience Report#448000
• Faster but Not Wiser: GitHub Copilot Decouples Programming Performance from Code Comprehension in Brownfield Tasks#1118434
• SWE-Adept: An LLM-Based Agentic Framework for Deep Codebase Analysis and Structured Issue Resolution#1117332
• MaCTG: Multi-Agent Collaborative Thought Graph for Automatic Programming#792606