Pith. sign in

REVIEW 4 major objections 4 minor 38 references

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

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read AdaptAgent claims that a multi-agent, domain-guided pipeline turns Q&A code snippets into compile-verified repository patches, reaching 65.2% semantic correctness on a real-world dataset.

desk verdict Solid empirical paper with a real test-suite oracle; the headline gain is plausible but needs variance reporting and McNemar details before the 'outperforms' claim is fully pinned down. read the letter →

arxiv 2608.04459 v1 pith:Y7QUPVPB submitted 2026-08-05 cs.SE

Xiaokai Rong , Hridya Dhulipala , Aashish Yadavally , Tien N. Nguyen This is my paper
classification cs.SE
keywords codeadaptationmulti-agentLLMframeworkintentsummarizationdomain-guidedplanninghardeningexceptionhandlingunifieddiffpatchsemanticcorrectness
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Developers routinely lift code from Q&A forums or LLM output, but integrating that code into an existing repository is a manual, error-prone step. The paper formalizes this as the code adaptation problem and proposes AdaptAgent, a linear pipeline of specialized agents—an intent summarizer, a policy agent, a domain planner, a context miner, a code adapter, and a compiler verifier—that turns a snippet into a minimal, compile-verified patch. On a real-world dataset of 952 Java snippet-repository pairs, it reports 65.2% correctness on the 259 instances with test suites and 62.3% on the 693 manually checked instances, outperforming single-shot prompting, a naive single-agent baseline, and copy-then-repair baselines. If these numbers replicate, the paper would establish that decomposing adaptation into intent recovery, domain-guided planning, and compiler feedback—not a stronger base model—is what improves automatic code integration.

What carries the argument

The load-bearing mechanism is a typed-artifact pipeline of cooperating agents. The Intent Summarizer compresses a Q&A post into a structured summary of the adaptation goal; the Policy Agent turns a six-category taxonomy—code hardening, resolving compilation errors, exception handling, logic customization, refactoring, and miscellaneous—plus project-specific rules into a checklist; the Domain Planner performs chain-of-thought reasoning over the checklist, intent, snippet, and target code to output a self-ordered sequence of atomic actions with rationales; the Context Miner collects the API calls of sibling methods at the adaptation location; and the Code Adapter emits a minimal patch in unified diff format that an external compiler Verifier iteratively checks and corrects. The plan is what forces the LLM to consider robustness and error-handling categories it would otherwise skip.

What would settle it

Take 100 adaptation pairs from the paper's dataset where the accepted answer silently substitutes one library API for another without naming the substitution in the question or answer text. The paper's Section 14 predicts a steep correctness drop on such posts; if AdaptAgent's correctness stays near its reported 62–65% level, then intent recovery from text is not the load-bearing mechanism, and the framework's success must be attributed to a different component.

Watch

Extended reading notes

Core claim

The central claim is that code adaptation succeeds when the adaptation goal is extracted from noisy Q&A text, the change is planned against a six-category domain checklist, and the patch is generated as a minimal diff with compiler feedback. Concretely, AdaptAgent passes all tests in 65.2% of the 259 instances with test suites and is judged semantically correct in 62.3% of the 693 manually checked instances, while the strongest baseline reaches 59.7% on the test-suite subset. The paper further claims that correct AdaptAgent patches resemble developers' actual adaptation behavior: the frequencies of the five main adaptation categories correlate with human adaptations at Spearman $\rho=0.913$, and the ablation study shows that planning is the main driver of code-hardening and exception-handling changes while intent summarization is the main driver of logic-customization changes.

Load-bearing premise

The pipeline leans on the premise that the forum post's question and accepted answer contain enough textual signal for the intent summarizer to recover the true adaptation goal, and that the six adaptation categories cover the changes needed; the paper itself concedes in Section 14 that when a code switch between APIs is not mentioned in the text, the LLM cannot infer the intent.

Editorial extensions

If this is right

  • If the correctness numbers hold, forum-snippet integration can be handed to an automated pipeline with a compile-and-test loop as its safety net.
  • Structured planning is what adds code hardening and exception handling; single-shot prompting misses them, so any LLM-based integration tool should plan before patching.
  • Intent summarization, not code context alone, drives logic customization such as switching APIs to match the user's goal.
  • Copying a snippet and then repairing it with an APR tool is a weaker strategy than planning-first adaptation, since the best such baseline still trails by about five percentage points on the test-suite subset.
  • Correctness is stable for localized patches—73.3% at one hunk—but falls to 33.3% at five or more hunks, so the reported advantage is clearest for small, localized changes.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper leaves implicit that the same intent-plus-planning decomposition could transfer to API migration and dependency upgrades, with release notes or deprecation warnings replacing Q&A text as the intent source.
  • The run-time experiment in Section 10, where 40.3% of extra code-hardening changes and 44.8% of extra exception-handling changes prevent a triggered failure, implies that divergence from the human patch is not the same as error; a failure-injection harness could make that robustness surplus a first-class metric.
  • The sharp multi-hunk drop—73.3% correctness at one hunk versus 33.3% at five or more—points to a testable ceiling: adding richer structural context (call graphs, types, or program dependence graphs), which the paper lists as future work, may recover part of the loss on large patches.
  • Because the evaluation covers only Java and one model family, the paper's claims about the division of labor deserve a cross-language replication; a Python dataset or a smaller open-weight model would reveal whether the agents, rather than the base LLM, carry the gain.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper formalizes the code adaptation problem: given a snippet, its functional intent, a target repository, and an adaptation location, a system must produce a patch that adapts the snippet into the repository. The authors propose AdaptAgent, a multi-agent framework in which an Intent Summarizer distills adaptation goals from Stack Overflow Q&A text, a Policy Agent builds a checklist from a six-category adaptation taxonomy, a Planner produces a self-ordered plan, a Context Miner extracts sibling-method API usage from the target codebase, and a Code Adapter generates a unified diff that is refined by a compiler-based Verifier. The empirical evaluation uses 952 snippet-to-GitHub adaptation pairs derived from Zhang et al.'s dataset, of which 259 pairs have executable test suites and 693 are manually checked. The central claims are that AdaptAgent outperforms strong baselines in semantic correctness (65.2% on the test-suite subset and 62.3% on the manual subset versus 59.7% for Agentless+ on the test-suite subset) and that its adaptation categories mirror developers' actual adaptation patterns, with ablations showing positive contributions from planning, intent summarization, and context mining.

Significance. If the empirical claims hold, AdaptAgent is a substantial contribution to AI4SE: it is a concrete instantiation of a multi-agent, domain-guided workflow for code adaptation, and it addresses a realistic and under-studied problem. The paper's strengths are its use of a test-suite oracle on 259 instances, the large real-world dataset inherited from prior work, a clearly specified pipeline with typed artifacts, an ablation study, and a data/code availability statement (Section 17). The gains over the strongest baseline, Agentless+, are large (5.5 percentage points on the test-suite subset) and, if properly validated statistically, would establish the value of decomposing adaptation into intent, policy, planning, context, and compiler feedback. The main weaknesses are statistical under-reporting of the headline comparison and a degree of circularity in the RQ2 alignment analysis, both of which are fixable without changing the architecture.

major comments (4)
  1. [§9.1.3, §9.2.4, Table 1] The central claim that AdaptAgent outperforms Agentless+ rests on a 65.2% versus 59.7% margin on 259 instances, a difference of about 14 instances, yet Section 9.1.3 only states that 'we ran each tool five times and reported the mean values.' No per-run breakdown, variance, confidence interval, or aggregation rule for the five runs is reported anywhere, and the McNemar test in Section 9.2.4 (p=0.00951) does not specify which run's per-instance outcomes were used, how multi-run outcomes were aggregated (first run, majority vote, best-of-five, or something else), or how ties were handled. Additionally, the 952 pairs in RQ1 are derived from only 542 SO posts, and the paper never reports the number of unique posts in D_t; if the 259 test-suite pairs contain multiple adaptations of the same snippet, the paired observations are not independent and the effective sample size for McNemar is smaller than 259. Please report per-run outcomes, specify the aggregation rule, provide a confidence interval or an exact paired test on a well-defined comparison, and state the number of unique posts in D_t. Without these details, the abstract's strongest quantitative claim is not statistically pinned down.
  2. [§6.1 and §10] There is a circularity in the RQ2 'mirroring' claim. The Policy Agent constructs its checklist from the six-category adaptation taxonomy of Zhang et al. [37] (Section 6.1), and RQ2 measures alignment by counting adaptation categories and types with a tool derived from the same taxonomy (Section 10, Fig. 6). The strong Spearman and Pearson correlations in Section 10 therefore partly reflect the fact that AdaptAgent was prompted with that taxonomy, so the result is partially induced by the prompts rather than an independent measurement of similarity to human behavior. The correctness results in Table 1 are independent of this concern and are not affected. However, the Section 10 conclusion that AdaptAgent 'is effective in producing adaptation patterns that are strongly aligned with those observed in human behavior' should be reframed, or supplemented with an evaluation that uses a taxonomy or scoring procedure that was not embedded in the policy checklist.
  3. [§9.2.1, §9.2.4, Table 1] The reporting of the headline correctness number is internally inconsistent. Section 9.2.4 states that 'AdaptAgent achieves 63.1% semantic correctness,' while Table 1 and the abstract report 65.2% for the test-suite subset and 62.3% for the manual subset; 63.1% appears nowhere in Table 1. If 63.1% is the mean over the five runs, that should be stated explicitly with per-run values; if it is a typographical error, it should be corrected. The same paragraph should clarify whether the quoted range '5.5%-53.6% more correct adaptation cases' is computed on mean correctness or on paired instance-level differences, since the latter is what the McNemar test actually evaluates.
  4. [§13, Table 6] The RQ5 plan-correctness analysis rests on manual inspection of 274 instances by a single independent evaluator, with no inter-rater reliability reported for the per-category judgments such as 'missing' and 'extra' adaptation types. Because the planner's plan is an intermediate natural-language artifact whose mapping to ground-truth adaptation categories is not mechanical, a single annotator's counts are a weak basis for the Table 6 fidelity claims. At minimum, the paper should report annotation guidelines, have a second annotator label a subset, and report agreement (e.g., Cohen's kappa) for the per-type judgments before drawing conclusions about which adaptation categories the Planner handles correctly.
minor comments (4)
  1. [Table 1 legend] The legend uses 'AgentLes' while the text and Section 9.1.3 use 'Agentless'; standardize the spelling throughout.
  2. [References [36] and [37]] References [36] and [37] are the same paper (Zhang et al., ICSE 2019) and should be consolidated into a single reference to avoid citation duplication.
  3. [§9.2.3] The Pearson correlations reported in Section 9.2.3 (r≈0.934, 0.925, 0.908) are computed on only eight outcome-conditioned mean points per oracle, and no p-values or caution about the small n are given; please add an appropriate caveat or exact test.
  4. [§14] The limitation stated in Section 14, that the approach under-performs when a post omits a needed API substitution from the text, is important and should be reflected in the abstract's unqualified claim that AdaptAgent 'produces patches that mirror developers' actual adaptation patterns.'

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: core correctness results rest on independent test suites; only a minor, non-load-bearing self-citation appears.

full rationale

AdaptAgent's central correctness claim is evaluated against external oracles: GitHub test suites for D_t (apply+build+all tests) and manual semantic review for D_m. Neither oracle is constructed from AdaptAgent's prompts, the Zhang et al. taxonomy, or any fitted parameter, so the 65.2%/62.3% results in Table 1 are independent evidence for the main claim. The only self-referential element is RQ2: the Policy Agent is prompted with six adaptation categories from Zhang et al. (Section 6.1), and Section 10 measures 'alignment' with human adaptations using Zhang et al.'s categorization tool. This shares an instrument between generation and evaluation, but it is not a by-construction reduction: the human distribution is external, and the LLM's exact category frequencies are not dictated by the prompt (AdaptAgent produces 743 Code Hardening counts vs. 315 for humans, so the alignment is not forced). The author-overlapping citation [4] appears only in Related Work and is not load-bearing. Section 14's stated limitations (prompt sensitivity, dependence on SO post quality, no Python support) are validity and robustness concerns, not circularity. No fitted parameter is renamed as a prediction and no definitional identity underlies the main result.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

No fitted numerical constants or new physical/theoretical entities appear in this work. The free parameters are design choices in the LLM pipeline (sampling settings, retry limits, context extraction scope, and prompt wording) that are not tuned to data but are chosen by the authors and not fully disclosed. The axioms are domain assumptions about the dataset, the evaluation oracles, and the sufficiency of intent/context signals, which the paper itself partially acknowledges as threats to validity.

free parameters (4)
  • LLM sampling configuration
    The paper says each tool was run five times and mean values reported, but temperature, top-p, max tokens, and seeds are not disclosed; these settings are chosen by the authors and affect the point estimates.
  • Compiler verification retry limit
    Section 4 states feedback repeats 'until a certain limit', but the limit and the prompt used to resubmit errors are not specified.
  • Context window scope
    Context Miner is simplified to API calls in sibling methods (Section 4); whether this scope is optimal is a hand-selected design choice validated only indirectly through ablations.
  • Policy checklist content
    The six categories come from prior work, but the concrete wording and any project-specific policies used in experiments are not fully disclosed, leaving a hand-authored prompt component.
assumptions (6)
  • domain assumption The six adaptation categories of Zhang et al. [37] are a sufficient and correct characterization of code adaptation changes.
    Used to build the Policy Agent checklist (Section 6.1) and to evaluate category alignment in RQ2 (Section 10).
  • domain assumption Passing all available test cases in the target repository implies semantic correctness of the adapted code.
    Central evaluation oracle for the 259-instance test-suite subset (Section 9.1.2).
  • domain assumption Manual annotators can reliably distinguish semantically correct from incorrect adaptations without anchoring to the ground truth.
    Used as the oracle for 693 instances without tests; only two annotators plus majority voting are described (Section 9.1.2).
  • domain assumption Sibling-method API calls provide sufficient semantic context for correct adaptation.
    Context Miner design choice in Section 4; richer structural signals are deferred to future work.
  • domain assumption Stack Overflow Q&A text contains enough information to recover the functional adaptation intent.
    Foundation of Key Idea 1 and the Summarizer agent (Section 5); paper concedes failure when intent is not stated (Section 14).
  • domain assumption The dataset after filtering is representative of realistic adaptation tasks.
    Filtering removed self-updated posts and only buildable repositories with reachable test suites were used (Section 9.1.1).

how reviews work

0 comments
Cite this review

Pith. "Pith review of AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation." pith.science (2026). https://pith.science/paper/Y7QUPVPB

@misc{pith2026260804459,
  author       = {Pith},
  title        = {Pith review of: AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Y7QUPVPB}},
  note         = {Machine review of arXiv:2608.04459}
}
read the original abstract

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.

Figures

Figures reproduced from arXiv: 2608.04459 by the authors.

Figure 1
Figure 1. An Answer to the Question in SO Post #29764243 [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 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 (Exce… view at source ↗
Figure 4
Figure 4. AdaptAgent: A Multi-agent, Domain-Guided Reasoning Framework for Code Adaptation As shown, the code at line 11 in [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (4 more)
Figure 5
Figure 5. Figure 5: Prompt Templates used in AdaptAgent Proc. ACM Softw. Eng., Vol. 3, No. ISSTA, Article ISSTA193. Publication date: October 2026 [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 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 …
Figure 7
Figure 7. Figure 7: Adaptation Type Distribution in Ablation Study (RQ3) [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 8
Figure 8. Figure 8: A Natural-language Adaptation Plan by Planner Agent [PITH_FULL_IMAGE:figures/full_fig_p019_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

38 extracted references · 12 canonical work pages

  1. [37]

    Tianyi Zhang, Di Yang, Crista Lopes, and Miryung Kim. 2019. Analyzing and supporting adaptation of online code examples. InProceedings of the 41st International Conference on Software Engineering(Montreal, Quebec, Canada)(ICSE ’19). IEEE Press, 316–327. doi:10.1109/ICSE.2019.00046

    arXiv 2019

  2. [1]

    https://stackoverflow.com/questions/ 29764243/draw-on-canvas-without-removing-the-background-image-on-erase-function/29790350#29790350

    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

    work page arXiv 2015

  3. [2]

    https://github.com/lfkdsk/JustWeTools/blob/master/justwetools/src/main/java/com/lfk/justwetools/ View/NewPaint/Graph/DrawPath.java#L41-L59

    2015.JustWeTools. https://github.com/lfkdsk/JustWeTools/blob/master/justwetools/src/main/java/com/lfk/justwetools/ View/NewPaint/Graph/DrawPath.java#L41-L59

    work page 2015

  4. [3]

    2026.Code Adaptation Repository

    Anonymous. 2026.Code Adaptation Repository. https://anonymous.4open.science/r/Code-Adaptation-5E32/README. md

    work page 2026

  5. [4]

    Yuchen Cai, Aashish Yadavally, Abhishek Mishra, Genesis Montejo, and Tien Nguyen. 2024. Programming Assistant for Exception Handling with CodeBERT. InProceedings 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/359750...

    arXiv 2024

  6. [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

    arXiv 2022

  7. [6]

    Felix Fischer, Konstantin Böttinger, Huang Xiao, Christian Stransky, Yasemin Acar, Michael Backes, and Sascha Fahl

    work page

  8. [7]

    Hyunji Hong, Seunghoon Woo, and Heejo Lee. 2021. Dicos: Discovering Insecure Code Snippets from Stack Overflow Posts by Leveraging User Discussions. InProceedings 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

    work page arXiv 2021

Show all 38 references
  1. [8]

    Amber Horvath, Andrew Macvean, and Brad A Myers. 2024. Meta-Manager: A Tool for Collecting and Exploring Meta Information about Code. InProceedings of the 2024 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA)(CHI ’24). Association for Computing Machiner...

    2024

  2. [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

    2024 doi

  3. [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

    2023 doi

  4. [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. InProceedings of the 37th IEEE/ACM International Conference on Automated Soft...

    2023

  5. [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

    2023 arXiv

  6. [13]

    Annie Li, Madeline Endres, and Westley Weimer. 2022. Debugging with stack overflow: web search behavior in novice and expert programmers. InProceedings of the ACM/IEEE 44th International Conference on Software Engineering: Software Engineering Education and Training(Pittsburgh...

    2022

  7. [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

    2024 arXiv

  8. [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

    2024 arXiv

  9. [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

    2024 arXiv

  10. [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

    2023 arXiv

  11. [18]

    Sonal Mahajan, Negarsadat Abolhassani, and Mukul R. Prasad. 2020. Recommending stack overflow posts for fixing runtime exceptions using failure scenario matching. InProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Found...

    2020

  12. [19]

    Sonal Mahajan and Mukul R. Prasad. 2022. Providing Real-time Assistance for Repairing Runtime Exceptions using Stack Overflow Posts. In2022 IEEE Conference on Software Testing, Verification and Validation (ICST). 196–207. doi:10. 1109/ICST53961.2022.00030 Proc. ACM Softw. Eng....

    2022

  13. [20]

    Chaiyong Ragkhitwetsagul, Jens Krinke, Matheus Paixao, Giuseppe Bianco, and Rocco Oliveto. 2021. Toxic Code Snippets on Stack Overflow.IEEE Transactions on Software Engineering47, 3 (2021), 560–581. doi:10.1109/TSE.2019. 2900307

    2021 doi

  14. [21]

    Brittany Reid, Christoph Treude, and Markus Wagner. 2020. Optimising the fit of stack overflow code snippets into existing code. InProceedings of the 2020 Genetic and Evolutionary Computation Conference Companion(Cancún, Mexico) (GECCO ’20). Association for Computing Machinery...

    2020

  15. [22]

    Stolee, and Sebastian Elbaum

    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...

    2015

  16. [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

    2025 arXiv

  17. [24]

    Bissyandé

    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

    2023 arXiv

  18. [25]

    Akhila Sri Manasa Venigalla and Sridhar Chimalakonda. 2021. StackEmo: towards enhancing user experience by augmenting stack overflow with emojis. InProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Softwar...

    2021

  19. [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

    2022

  20. [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

    2023 arXiv

  21. [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

    2025 doi

  22. [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

    2025 arXiv

  23. [30]

    Fabian Yamaguchi, Nico Golde, Daniel Arp, and Konrad Rieck. 2014. Modeling and Discovering Vulnerabilities with Code Property Graphs. InIEEE Symposium on Security and Privacy. IEEE Computer Society, 590–604

    2014

  24. [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 Au...

    2023

  25. [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

    2023 arXiv

  26. [33]

    Yuan Yuan and Wolfgang Banzhaf. 2020. ARJA: Automated Repair of Java Programs via Multi-Objective Genetic Programming.IEEE Transactions on Software Engineering46, 10 (2020), 1040–1067. doi:10.1109/TSE.2018.2874648

    2020

  27. [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

    2024

  28. [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. InProceedings of the 40th ACM/IEEE International Conference on Automate...

    2025

  29. [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...

    2025 arXiv

  30. [2017]

    InProceedings of the 2017 IEEE Symposium on Security and Privacy

    Stack Overflow Considered Harmful? The Impact of Copy&Paste on Android Application Security. InProceedings of the 2017 IEEE Symposium on Security and Privacy. IEEE Computer Society, 121–136

    2017

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.