DepRepair: LLM-Based Source-Code Repair for Dependency Breaking Changes
Shenghao Yang∗ , Bo Lu† , Yaochen Liu† , Yu Kang† , Qiongfang Zhang† , Chetan Bansal† , Saravan Rajmohan† , Minghua Ma† ∗ Carnegie Mellon University, Pittsburgh, PA, USA
arXiv:2607.17957v1 [cs.SE] 20 Jul 2026
Email: [email protected] † Microsoft Email: [email protected]
Abstract—Modern software projects depend on numerous third-party libraries, whose updates often introduce breaking changes. Adapting consumer code to such changes remains laborintensive and error-prone. Existing work either characterizes dependency breaking changes without producing a verified consumer-side patch, or studies automated repair only in settings where the failure and repair context are contained within the target repository. However, dependency breaking changes violate this assumption: the decisive repair evidence lies upstream in release notes and API diffs, and no failing test localizes where the consumer breaks, leaving the repair under-informed. To study this cross-repository problem on real data, we introduce DepBench, a benchmark of 95 real-world dependency-update instances across four ecosystems, each paired with a Dockerbased executable oracle that runs the consumer’s own tests. To address these challenges, we propose D EP R EPAIR, a singlecall LLM approach that grounds repair in structured upstream evidence through three components: an evidence filter that distills relevant upstream changes, a usage locator that identifies affected consumer sites, and a subcategory-aware guide that tailors repairs to the breaking-change type. Evaluated on D EP B ENCH, D EP R EPAIR attains the highest executable pass rate on each backbone, achieving 89.5% with GPT-5.5 and 82.1% with Claude Opus 4.6. We further find that raw upstream evidence reduces LLM and agent pass rates by 7–23 percentage points, whereas structured evidence consistently improves them. Index Terms—program repair, upstream evidence, large language model
I. I NTRODUCTION Software projects depend heavily on third-party libraries, and a modern application typically pulls in dozens of direct and transitive dependencies that it must keep up to date for security fixes, new features, and performance improvements. When upstream libraries update, they often introduce breaking changes, such as API migrations, renames, import migrations, and paradigm shifts [1]. Such changes usually cause compilation errors or runtime failures in downstream consumer code, forcing developers to manually adapt their projects to the new library version. However, adapting consumer code to such changes is timeconsuming and error-prone. Studies show that developers frequently delay dependency updates primarily because of the perceived cost [2], and 81.5% of studied projects keep outdated Work done during an internship at Microsoft.
dependencies [3]. The resulting technical lag exposes projects to known vulnerabilities and missed performance gains [4]. Thus, the tension between the cost of manual adaptation and the risk of falling behind motivates automated tools that repair the consumer code so that projects can keep their dependencies up to date. Research on dependency management has emerged to understand and tame breaking changes from dependency updates. One category characterizes breaking changes, measuring how often upstream updates break their consumers and how the resulting risk propagates through the software supply chain [1], [5], [6]. The other category builds tooling that assists migration by reusing how the library or its earlier clients evolved [7], [8]. However, for a specific project, most of this work neither localizes the exact consumer sites that must change nor emits a verified source patch that adapts the project to the new version. As a result, a developer facing a concrete upgrade is still left to find and edit every affected line by hand. In contrast, rule-based and LLM-based methods focus on localizing and repairing the broken consumer code. Rulebased approaches rewrite outdated API usages into their replacements using transformation rules that are hand-crafted or mined from past migrations [7], [9]. LLM-based program repair instead synthesizes a patch directly from the consumer code and a failing test, assuming the fix can be found within the project itself. This paradigm was established by SWE-bench [10] and now drives coding agents such as Codex CLI [11] and Claude Code [12]. Despite their difference in form, both treat dependency breaking-change repair as a same-repository problem, overlooking its inherently crossrepository nature. This leaves the repair under-informed and the model prone to abstain or mis-apply the fix, since the evidence for what to change resides upstream in release notes and API diffs, and no failing test localizes where the breakage occurs. For example, when a project upgrades JUnit from 4 to 5, the required @Before→@BeforeEach rename appears only in the JUnit 5 release notes, not in the consumer’s own code or tests. To study this cross-repository problem in real data, we need a benchmark that no prior work provides: its instances must be driven by real dependency upgrades, carry the upstream
evidence required to repair them, and be verified by running the consumer’s own tests. We therefore design a four-stage construction strategy to establish such a benchmark. It first mines dependency-update pull requests from GitHub, then filters them for repository and pull-request quality, next confirms the changes are caused by the upgrade and backed by upstream evidence, and finally keeps only instances whose upgrade breaks the consumer’s tests and whose patch repairs them in Docker. Through this strategy, we construct D EP B ENCH, which includes 95 real-world instances across four ecosystems—Maven (38), npm (33), Cargo (15), and PyPI (9)—each paired with a Docker-based executable oracle that runs the consumer’s own test suite. Constructing D EP B ENCH and analyzing its instances let us pinpoint the central challenges of cross-repository breakingchange repair. First, the decisive repair evidence is external and noisy, so the correct fix must be distilled from upstream release notes rather than read off the consumer code. In 57 of the 95 instances (60%) the developer’s patch adopts an upstream API symbol (e.g., a new import or namespace) that never appears in the consumer’s pre-upgrade sources. Second, localization gets no help from a failing test, so the affected call sites and imports must be found by other means and are widely diffuse. In D EP B ENCH, the gold patches span a median of 10 files and 21 edit hunks, and 85 of the 95 (89%) touch more than one file. Third, no single repair strategy fits all, so the edit must be tailored to the breaking-change type, which ranges across direct renames (27), compound API migrations (25), import migrations (23), and paradigm shifts (20). To address these challenges, we propose D EP R EPAIR, a single-call LLM approach that treats dependency repair as an evidence-grounding problem. Specifically, D EP R EPAIR structures the upstream evidence with three key components: (1) upstream evidence filter, which first collects and distills breaking-change information from the upstream library into a compact set of migration rules; (2) consumer-side usage locator, which then identifies the specific call sites and imports affected in the downstream project; and (3) subcategoryaware guide, which finally tailors the repair instructions to the type of breaking change (e.g., API migration, rename, import migration, or paradigm shift). To systematically evaluate D EP R EPAIR and isolate the role of cross-repository evidence, we investigate four research questions (RQs): • RQ1 (Overall comparison): How does D EP R EPAIR compare with prompt baselines and state-of-the-art coding agents, and are the differences statistically significant? This establishes whether grounding a single LLM call in structured upstream evidence can match multi-turn agents that repeatedly read and edit the repository. • RQ2 (Failure taxonomy): When repair fails, how does it fail? Characterizing the failure modes reveals whether the bottleneck is producing any fix or producing a correct one, which dictates where evidence should intervene. • RQ3 (Evidence form and ablation): How does the form of upstream evidence—and each D EP R EPAIR
component—affect repair for both LLMs and agents? This tests our central hypothesis that the value of crossrepository context lies in its processing, not its mere provision. • RQ4 (Subcategory analysis): How does performance vary across breaking-change subcategories, and where does structured evidence help most? We summarize our key findings as follows. For RQ1, D EP R EPAIR attains the highest executable pass rate on each backbone—89.5% with GPT-5.5 and 82.1% with Claude Opus 4.6—matching or surpassing multi-turn coding agents with a single LLM call, which shows that the bottleneck is access to the right cross-repository evidence rather than the amount of in-repository interaction. For RQ2, the empty patch dominates: the most common failure is emitting no usable patch rather than an incorrect one, and raw upstream evidence aggravates it—Direct LLM (upstream) returns an empty patch on 32 of 95 instances, whereas D EP R EPAIR cuts this to 10. For RQ3, cross-repository evidence helps only when structured— supplying the raw upstream changelog lowers pass rates by up to 10.5 percentage points for LLMs and up to 23.2 for agents, whereas the same evidence distilled into migration rules consistently improves them. For RQ4, D EP R EPAIR’s gains concentrate on direct-rename and compound API migrations, whereas paradigm shifts—which demand structural refactoring beyond rule-level edits—remain the hardest residual, solved on only 65–70% of cases even by the best method. Our contributions are: • We shift the perspective on dependency breaking-change repair from a same-repository task to a cross-repository one, recognizing that the decisive repair evidence lies upstream rather than in the consumer project. • We introduce D EP B ENCH , a benchmark of 95 realworld dependency-update instances across four ecosystems, each with a verified ground-truth patch and a Docker-based executable oracle. • We propose D EP R EPAIR , a single-call approach that grounds the model in distilled upstream evidence and tailors its guidance to the breaking-change type, matching or surpassing state-of-the-art coding agents at a fraction of their cost. • We show that raw upstream evidence hurts both LLMs and agents while distilled evidence consistently helps, and that the empty patch—not incorrect repair—is the dominant failure mode, which structured evidence sharply reduces (from 32 to 10 of 95 instances). II. R ELATED W ORK A. Dependency Updates and Breaking Changes Prior work on dependency management measures the breaking-change problem or assists migration, but none automatically generates the consumer-side source patch that adapts a downstream project to an upstream update. One line characterizes the problem empirically, quantifying the prevalence and client-side impact of breaking changes, behavioral
incompatibilities, and semantic-versioning violations across ecosystems [1], [5], [13]–[17], showing that most projects run outdated dependencies and negotiate breaking changes and API deprecations at a real cost [2], [3], [9], [18], [19]. This breaking-change burden is what keeps projects from staying current, with direct consequences for the software supply chain: stale and bloated dependencies, as well as dependency conflicts, expose projects to known vulnerabilities and supplychain attacks [6], [20]–[28], yet even automated upgrade pull requests are frequently ignored because they break the consumer’s build [29]–[31]. A second line provides tooling that supports, but does not fully automate, migration: Henkel and Diwan [7] record and replay library-side API refactorings (CatchUp!), Lu et al. [4] propose strategies for minimizing breaking changes when mitigating technical lag, and earlier studies chart how libraries are migrated in practice [8], [32] and test for breaking changes across versions [33]. D EP R E PAIR closes this gap: rather than measuring or recording breaking changes, it distills upstream evidence into structured migration rules and uses them to generate the consumer-side source patch that resolves the breakage. B. Same-Repository Repair Existing automated repair for breaking changes, whether rule-based or LLM-based, shares a common assumption: the information needed to fix the code already lives inside the consumer project (or in rules derived from past migrations of it). We organize prior work along these two lines and contrast both with our cross-repository view. 1) Rule-Based Repair: Rule-based approaches rewrite outdated API usages into their replacements using transformation rules. Dig and Johnson characterized how APIs evolve through refactorings [9], and Henkel and Diwan’s CatchUp! records refactorings in the library and replays them on consumers [7]. To avoid hand-written rules, later work mines adaptations automatically: Dagenais and Robillard’s SemDiff recommends replacement methods by analyzing how the framework itself adapts to its own changes [34], Nguyen et al.’s LibSync learns API-usage adaptation patterns from already-migrated clients [35], Fazzini et al.’s AppEvolve infers and applies update edits from examples of other projects that completed the same migration [36], Xu et al.’s Meditor infers and applies API migration edits from prior client commits [37], and Lamothe et al.’s A3 assists API migrations using code examples [38]. These methods pre-encode the fix as transformation rules; they depend on either curated rules or a corpus of prior migrations, and they struggle when the upstream evidence is unstructured release notes rather than clean before/after examples. D EP R EPAIR instead distills such raw upstream evidence into migration rules at repair time, removing the dependence on pre-existing rule sets or migrated exemplars. 2) LLM-Based Repair: Automated program repair has a long history, and large language models now drive its strongest results [39]–[42]. SWE-bench established real-world GitHub issues as a benchmark for this setting [10], spurring a range of repair systems. Agentless follows a non-agentic, two-phase
localize-then-repair pipeline [43], whereas SWE-agent [44], OpenHands [45], AutoCodeRover [46], RepairAgent [47], and repository-level planners such as CodePlan [48] grant the model autonomy to navigate and edit repository files over multiple turns, and commercial agents such as Codex CLI [11] and Claude Code [12] apply the same paradigm in practice. All of these assume a same-repository setting: the bug report, relevant code, and fix reside within a single project, and the model recovers the fix by reading and editing that project. Dependency breaking-change repair violates this assumption, because the decisive evidence lies in the upstream library; D EP R EPAIR addresses this by explicitly grounding a single LLM call in distilled cross-repository evidence. III. B ENCHMARK A. Construction We construct D EP B ENCH, a benchmark of real-world dependency update instances drawn from open-source projects. Each instance represents a pull request that updates a dependency to a new major version and modifies consumer source code to adapt to breaking API changes introduced by the update. Fig. 1 summarizes the construction pipeline, which proceeds from candidate harvesting through quality filtering to oracle construction. a) Data sources.: We draw from four popular package ecosystems: Maven, npm, Cargo, and PyPI, covering both statically and dynamically typed languages. Within them we target 10 popular libraries undergoing a well-documented major-version transition: JUnit 4→5 and Spring Boot 2.7→3.0 (Maven), Vue 2→3, Next.js 12→13, and ESLint 8→9 (npm), Clap 3→4 and Tokio 0.3→1.0 (Cargo), and Pydantic 1.10→2.0, SQLAlchemy 1.4→2.0, and NumPy 1.26→2.0 (PyPI). b) Candidate harvest.: To collect genuine migration pull requests with high recall, we combine two complementary strategies. Query-driven retrieval uses keywords to search GitHub for pull requests that both bump a dependency version in a manifest file (e.g. pom.xml, package.json, Cargo.toml, or requirements.txt) and modify source files in the same commit. Dependency-graph traversal follows each library’s reverse dependency graph to consumers still pinning the old major version, surfacing migration commits that keyword search misses. c) Quality Filter.: To retain only instances that are genuine, reproducible, and evidence-bearing, each candidate must clear three gates. Repository quality: the project must build, excluding forks and abandoned repositories, so an executable environment is reconstructable. Pull-request quality: the source edits must be caused by the update, excluding rollbacks, lockfile- or manifest-only changes, unrelated build churn, and patches touching files outside the consumer snapshot. Evidence quality: usable upstream signals—release notes, changelogs, or an API diff—must exist, since these are the inputs that D EP R EPAIR and the upstream baselines consume.
Data Sources
Candidate Harvest
Quality Filter
Oracle Construction
Query-driven DependencyRetrieval graph traversal
Repository Pull-Request Evidence Quality Quality Quality
Image Negative Construction Test
DepBench
Fig. 1. Construction pipeline for D EP B ENCH. Candidate pull requests are first harvested from popular packages across four ecosystems by query-driven retrieval and dependency-graph traversal. They are then passed through quality filters that retain only genuine, reproducible, and evidence-bearing PRs, and finally paired with a Docker-based executable oracle, yielding 95 self-contained instances.
d) Oracle construction.: We package the pre-update snapshot, update metadata, upstream evidence, and the developer’s gold patch into a self-contained Docker image, then probe it with two checks: a negative test confirming the un-repaired snapshot actually fails the breakage-related tests, and a positive test confirming the gold patch makes those tests pass. Building successfully is necessary but not sufficient: we keep only feasible instances—those exhibiting real, reproducible breakage that the gold patch demonstrably repairs. The 95 feasible instances surviving all three stages constitute D EP B ENCH. B. Breaking-Change Taxonomy We classify each instance into one of four subcategories based on the type of upstream breaking change: • Direct rename (27 instances): Symbols, types, or import paths are renamed in the upstream API (e.g., clap::App → clap::Command). • Compound API migration (25): Multiple related APIs change simultaneously, requiring coordinated multi-site modifications (e.g., Spring Boot annotation and property changes). • Import migration (23): The module structure is reorganized upstream, requiring import path updates throughout the consumer (e.g., JUnit 4 → JUnit 5 namespace migration). • Paradigm shift (20): The upstream API’s design philosophy changes fundamentally (e.g., Vue 2 Options API → Vue 3 Composition API), requiring structural refactoring beyond simple renaming. C. Benchmark Statistics The final benchmark comprises 95 instances across four package ecosystems, partitioned cleanly into the four breakingchange subcategories above, as shown in Table I. Table II shows the target packages and their version transitions. Each instance provides on the order of ten source files as context to the tool, and the ground-truth patches modify tens of diff hunks on average (up to several hundred), reflecting the non-trivial nature of real-world migration edits. IV. A PPROACH D EP R EPAIR grounds the entire repair in the upstream evidence. Because raw evidence is not directly actionable,
TABLE I B ENCHMARK DISTRIBUTION BY ECOSYSTEM AND BREAKING - CHANGE SUBCATEGORY. Subcategory
Maven
npm
Cargo
PyPI
Total
Direct rename Compound API migr. Import migration Paradigm shift
0 19 19 0
6 4 4 19
15 0 0 0
6 2 0 1
27 25 23 20
Total
38
33
15
9
95
TABLE II TARGET PACKAGES AND VERSION TRANSITIONS . Package
Ecosystem
n
Version
Vue JUnit Spring Boot Clap Next.js Pydantic ESLint Tokio SQLAlchemy NumPy
npm Maven Maven Cargo npm PyPI npm Cargo PyPI PyPI
20 19 19 11 8 6 5 4 2 1
2→3 4→5 2.7 → 3.0 3→4 12 → 13 1.10 → 2.0 8→9 0.3 → 1.0 1.4 → 2.0 1.26 → 2.0
D EP R EPAIR structures it into the three decisions a repair must make: what changed upstream, where it affects the consumer, and how to edit. Each decision is produced by a dedicated transformation and composed into a single LLM call, as shown in Fig. 2. We use the JUnit 4→5 migration exec-114 as a running example throughout this section. A. Problem Formulation We formalize dependency breaking-change repair as a function of three inputs. The dependency update u = (p, vold , vnew ) names the package p and its old and new versions. The consumer snapshot C = {f1 , . . . , fn } is the set of source files in the project before the update is applied. The upstream evidence E is the unstructured documentation associated with u, such as release notes, changelogs, migration guides, and version diffs. The goal is to produce a patch ∆ (a unified diff over C) such that, after applying ∆ and bumping p to vnew , the consumer’s own test suite passes.
① Evidence Distiller Raw Evidence
Clear Rules
② Code Locator
③ Subcategory Guide
Localized Code
User Code
Subcategories Import Migration Direct Rename Paradigm Shift API Migration
Paradigm Shift Guidance Import Migration Guidance
④ Single-turn LLM Unified Diff
Prompt Guidance
Fig. 2. Overview of the D EP R EPAIR approach. Three evidence transformations: an evidence filter that distills raw upstream changelogs into structured migration rules (what), a usage locator that connects those rules to affected consumer call sites (where), and a subcategory guide that tailors the repair strategy to the breaking-change type (how). Finally, all these are assembled into a single LLM call that emits a unified diff, verified by the Docker-based executable oracle.
This formulation makes the cross-repository nature of the task explicit: the signal that determines a correct ∆ is concentrated in E, which originates outside C, and unlike conventional repair there is no failing test inside C that localizes the fault. D EP R EPAIR produces ∆ in a single generation step that composes three evidence-derived inputs: ∆ = LLM A SSEMBLE(R, L, g, C) , (1) where the migration rules R, the localization hint L, and the subcategory instruction g are produced by three transformations of the inputs: R = F ILTER(u, E),
(2)
L = L OCALIZE(C, R),
(3)
g = G UIDE(u).
(4)
The four subsections below develop these operators in turn. B. Evidence Filter: what changed To address the noise interference caused by raw upstream evidence, the evidence filter distills the raw evidence E into a compact, structured set of migration rules R. Specifically, it first gathers candidate evidence for the version range (vold , vnew ) from sources that are routinely available across ecosystems: • release notes and changelogs from the package registry (Maven Central, npm, crates.io, PyPI); • upstream source diffs between the two versions, when the project is open source; • deprecation and removal markers in API documentation; and • dedicated migration guides, when the maintainers publish them.
However, this evidence is often noisy, mixing a few consumer-visible breaking changes with many internal refactorings, performance notes, and unrelated features. Thus, the filter then prompts the backbone LLM to distill this evidence into a list of rules, where each rule r ∈ R records the old API surface, its new replacement, and a one-line description of the required edit, discarding the surrounding prose. For our running example exec-114, this stage yields rules for the JUnit 4→5 namespace move and annotation renames, such as: {old: "org.junit.Before", new: "org.junit.jupiter.api.BeforeEach", kind: import+annotation rename}
so that downstream reasoning operates on actionable facts rather than narrative text. C. Usage Locator: where it matters The second stage, L OCALIZE, identifies which parts of the consumer are affected by the rules in R, producing a localization hint L. Whereas conventional repair localizes from a failing test or a bug report, no such signal exists here; our localization is instead API-driven, connecting each rule’s old API surface to its usage sites in C. For every rule r ∈ R we scan the consumer files for: • imports of changed or removed symbols; • call sites of modified APIs; • code patterns matching renamed or restructured constructs; and • transitive uses reached through local wrappers or reexports. The result is a list of (file, line, matched rule) anchors that narrows the model’s attention to the regions that actually need editing. On exec-114, L OCALIZE flags the JUnit imports and the @Before/@Test annotation sites across the test files, pointing the model straight at the lines to change.
D. Subcategory Guide: how to edit Knowing what changed and where it is used still leaves open how to edit: the same rules call for a mechanical sweep in one case and a structural rewrite in another. The third stage, G UIDE, supplies the model with an editing strategy matched to the kind of change at hand. It first classifies the change type based on the migration rules R: pure symbol substitutions as a direct rename, relocated import paths as an import migration, several interacting rules as a compound API migration, and rules that alter a design contract as a paradigm shift. It then attaches the matching instruction g that tells the model how to apply the rules: • for direct renames, g emphasizes systematic, exhaustive symbol replacement across all occurrences; • for import migrations, g stresses updating import paths consistently while leaving call sites intact; • for compound API migrations, g warns that several related changes must be applied together or the patch will regress; and • for paradigm shifts, g instructs the model to perform structural refactoring guided by the migration rules rather than a one-to-one substitution. On exec-114, the rules touch a namespace, several annotations, and an assertion API at once, so G UIDE reads the change as a compound API migration and tells the model to apply the three in concert. E. Assembly and Single-Call Generation Finally, A SSEMBLE composes the four ingredients into a single prompt: system instructions fixing the output format, the migration rules R, the localization hint L, the subcategory instruction g, and the consumer source C. The backbone LLM answers in one call with a unified diff ∆, which we apply to the consumer snapshot and verify with the Docker-based executable oracle (Section V). V. E VALUATION A. Research Questions We investigate four research questions: • RQ1 (Overall comparison): How does D EP R EPAIR compare with baseline approaches and state-of-the-art coding agents, and are the differences statistically significant? • RQ2 (Failure taxonomy): When repair fails, how does it fail, and what does the distribution of failure modes reveal about the underlying difficulty? • RQ3 (Evidence form and ablation): How does the form of upstream evidence—and each D EP R EPAIR component— affect repair performance for both LLMs and agents? • RQ4 (Subcategory analysis): How does repair performance vary across breaking-change subcategories, and where does structured evidence help most? B. Experimental Setup Models. We evaluate with two LLM backbones to ensure generalizability: GPT-5.5 (OpenAI) and Claude Opus 4.6
(Anthropic), both set with a 300-second timeout and temperature 0. Direct LLM baselines. Our method D EP R EPAIR is a single-call (non-agentic) LLM approach. We therefore compare it against the same single-call interface without structured evidence, which we term Direct LLM [39], prompting each backbone once to emit a unified diff under two evidence conditions: • D EP R EPAIR (our method): Full pipeline with structured migration rules, localization hints, and subcategory-aware instructions; unified diff output. • Direct LLM (upstream): Raw upstream changelog/migration guide included verbatim; unified diff output. • Direct LLM (minimal): Only dependency update metadata and consumer code; no upstream evidence; unified diff output. Agentic baselines. We compare against two state-of-theart coding agents that follow the agentic, multi-turn repair paradigm [44], each evaluated in both minimal and upstream configurations: • Codex CLI [11]: OpenAI’s coding agent (GPT-5.5 backbone) with multi-turn file editing. • Claude Code [12]: Anthropic’s coding agent (Claude Opus 4.6 backbone) with autonomous planning and editing. Controlled generation setting. To isolate the role of upstream evidence, every method—prompt baselines and agents alike—generates its patch from the same consumer snapshot without an in-loop build/test environment, and the resulting patch is verified afterwards by the shared Docker oracle. This holds the execution interface fixed across methods, so that differences in pass rate reflect the form of cross-repository evidence rather than the amount of in-repository execution feedback available during generation. Evaluation oracle. We use an execution-based oracle, which grounds every verdict in the consumer’s own tests rather than textual similarity to the developer patch. For each instance, we build the consumer project in a Docker container, apply the candidate patch, and run the project’s test suite. An instance is counted as PASS if all breakage-related tests pass, and FAIL otherwise. Instances where the LLM times out or returns an API error are counted as failures. We report the pass rate: PASS/95 across all feasible instances. C. RQ1: Overall Comparison Table III presents the main results across all methods and both backbones. We test each pairwise gap to D EP R EPAIR with the McNemar paired test (exact binomial form when the discordant count is small). • D EP R EPAIR attains the highest pass rate. On both backbones it tops every baseline and agent, reaching 89.5% on GPT-5.5 and 82.1% on Opus 4.6. • D EP R EPAIR significantly beats the same-backbone Direct LLM. D EP R EPAIR adds +7 instances on GPT-5.5
TABLE III OVERALL COMPARISON ON 95 BENCHMARK INSTANCES , GROUPED BY BACKBONE . PASS RATE = PASS /95. O N EACH BACKBONE , D EP R EPAIR IS SIGNIFICANTLY HIGHER THAN EVERY OTHER METHOD (M C N EMAR PAIRED TEST, p < 0.05) EXCEPT THE RUNNER - UP (†), WHOSE GAP TO D EP R EPAIR IS NOT STATISTICALLY SIGNIFICANT.
TABLE IV G ENERATION - SIDE EMPTY PATCHES : NUMBER OF INSTANCES ( OUT OF 95) ON WHICH THE METHOD EMITS no PATCH . R AW UPSTREAM EVIDENCE DRIVES THE MODEL TO EMIT AN EMPTY PATCH FAR MORE OFTEN ; D EP R EPAIR ’ S STRUCTURED EVIDENCE DOES SO LEAST. Method
Method
Pass
Rate
GPT-5.5 backbone D EP R EPAIR Agentic Codex (minimal) Direct LLM (minimal) Direct LLM (upstream) Agentic Codex (upstream)
85 83 78 71 70
89.5% 87.4%† 82.1% 74.7% 73.7%
Claude Opus 4.6 backbone D EP R EPAIR Agentic Claude Code (minimal) Direct LLM (minimal) Direct LLM (upstream) Agentic Claude Code (upstream)
78 77 68 58 55
82.1% 81.1%† 71.6% 61.1% 57.9%
(p=0.016) and +10 on Opus 4.6 (p=0.002) over Direct LLM (minimal), with no instance regressing in the other direction (b01 =0 on both backbones)—a clean, one-sided improvement. • D EP R EPAIR matches, but does not beat, the strongest agent. The closest competitors are the cross-architecture agents in their minimal configurations—Codex (87.4%) and Claude Code (81.1%). D EP R EPAIR’s edge here is only +2 and +1 instances and does not reach significance, so the honest reading is on par with the best agents, not ahead of them. • Raw upstream evidence sinks the agents. Both agents are strong with minimal context but collapse once fed the raw changelog—Codex to 73.7% and Claude Code to 57.9%, both significantly below D EP R EPAIR (p<0.001).
•
The empty patch is the dominant failure. Even the strongest LLM baselines decline to emit a patch on roughly a fifth of instances (21/95), and raw upstream evidence makes this sharply worse—Direct LLM (upstream) returns an empty patch on 32/95 (33.7%) and Agentic Claude Code on 35/95 (36.8%). The largest single barrier
Rate
10 21 21 32 35
10.5% 22.1% 22.1% 33.7% 36.8%
D EP R EPAIR Direct LLM (minimal) Agentic Codex (minimal) Direct LLM (upstream) Agentic Claude Code (minimal)
is therefore producing any fix at all, and unstructured evidence aggravates it. • D EP R EPAIR attacks exactly this barrier. It returns an empty patch on only 10/95 instances (10.5%), less than half the rate of Direct LLM (minimal), and— crucially—the patches it does emit almost always pass: on GPT-5.5 every one of the 85 emitted diffs clears the executable oracle. In other words, structured evidence converts the model’s non-answers into small, applicable, oracle-passing patches. This empty-patch gap is the largest single lever on pass rate: the raw-evidence configurations abstain on 32–35 of 95 instances, whereas D EP R EPAIR does so on only 10, turning non-answers into applicable patches. E. RQ3a: Evidence as a Double-Edged Sword A surprising finding is that providing raw upstream evidence hurts performance for both LLMs and agents. TABLE V I MPACT OF EVIDENCE FORM ON PASS RATE . R AW EVIDENCE CONSISTENTLY REDUCES PERFORMANCE VS . THE NO - EVIDENCE BASELINE .
D. RQ2: The Empty Patch as the Dominant Failure To analyze repair failure modes, we examine the artifact each method generates before oracle evaluation, distinguishing a produced candidate patch from an empty patch (i.e., no code diff). Failures rarely arise from explicit abstention; instead, the model often incorrectly concludes that the consumer code remains compatible and needs no modification. Such falsenegative localization errors manifest as empty patches despite the existence of a required repair. Because empty patches are identifiable directly from generation logs, independent of oracle behavior, they serve as a robust proxy for localization failures. Table IV summarizes each method’s empty-patch frequency over the 95 benchmark instances. Two findings stand out.
Empty patches
Method
Minimal
Upstream
Direct LLM (GPT-5.5) Agentic Codex (GPT-5.5) Direct LLM (Opus 4.6) Agentic Claude Code (Opus)
82.1% 87.4% 71.6% 81.1%
74.7% 73.7% 61.1% 57.9%
∆ −7.4pp −13.7pp −10.5pp −23.2pp
Table V shows that raw upstream evidence reduces pass rates by 7–23 percentage points across all methods, and two observations stand out. Raw evidence hurts every method. The drops are large and directionally consistent across every method– backbone pair, and Claude Code is the most severely affected (−23.2pp), possibly because its longer agent loop amplifies the misleading effect of unstructured evidence. • Structured evidence reverses the effect. D EP R EPAIR ’s structured evidence extraction turns the loss into a gain: pass rates increase by 7.4pp (GPT-5.5, 82.1%→89.5%) and 10.5pp (Opus 4.6, 71.6%→82.1%) over the minimal baseline. •
This reveals a fundamental insight: the value of upstream evidence depends entirely on how it is processed. Raw changelogs and migration guides contain both actionable information and irrelevant noise; LLMs and agents lack the ability to reliably separate the two, leading to worse outcomes than having no evidence at all. F. RQ3b: Component Ablation Table VI presents the ablation results for both backbones. TABLE VI A BLATION STUDY: CONTRIBUTION OF EACH D EP R EPAIR COMPONENT.
Components
TABLE VII PASS RATES BY BREAKING - CHANGE SUBCATEGORY ( BEST METHODS ). C OUNTS IN PARENTHESES ARE THE NUMBER OF INSTANCES PER SUBCATEGORY.
Method
CAM (25)
DR (27)
IM (23)
PS (20)
All (95)
D EP R EPAIR (GPT-5.5) Agentic Codex (GPT) Direct LLM (GPT-5.5) D EP R EPAIR (Opus) Agentic Claude Code (Opus) Direct LLM (Opus)
96% 92% 88% 80% 84% 64%
93% 89% 81% 78% 81% 63%
100% 100% 100% 100% 100% 100%
65% 65% 55% 70% 55% 60%
89.5% 87.4% 82.1% 82.1% 81.1% 71.6%
Result
Configuration
Rules
Loc.
SubCat
Pass
Rate
Claude Opus 4.6 backbone Full D EP R EPAIR −Subcategory −Evidence Minimal (no components)
✓ ✓ — —
✓ ✓ — —
✓ — ✓ —
78 58 58 68
82.1% 61.1% 61.1% 71.6%
GPT-5.5 backbone Full D EP R EPAIR −Subcategory −Evidence Minimal (no components)
✓ ✓ — —
✓ ✓ — —
✓ — ✓ —
85 82 80 78
89.5% 86.3% 84.2% 82.1%
The two backbones expose complementary effects, but converge on one message: evidence and guidance only help when supplied together. • On Opus, a half-pipeline is worse than none. Removing either subcategory instructions or structured evidence drops the pass rate by 21.0pp (82.1%→61.1%); both contrasts against the full pipeline are large enough to be highly significant under McNemar (p<0.001). Strikingly, both ablated configurations (61.1%) land below the minimal baseline with no components at all (71.6%). This mirrors the evidence pattern in Section V-E: structured rules without category-specific guidance act as noise, just as raw evidence does, because the model cannot tell which of the supplied rules apply. • The contribution is backbone-dependent. On the weaker Opus backbone, the full pipeline adds 10.5 percentage points over the minimal configuration. In contrast, the stronger GPT-5.5 backbone already achieves 82.1% with the minimal prompt and therefore benefits less from the additional components. Removing either component still retains 84.2–86.3%, remaining above the minimal baseline. The consistent takeaway across backbones is that evidence and guidance must work together: supplying one without the other is at best neutral and at worst actively harmful. G. RQ4: Per-Subcategory Analysis Table VII breaks down D EP R EPAIR’s performance by breaking-change subcategory. Table VII exposes a clear difficulty gradient across subcategories.
Import migration is saturated. Every method in Table VII achieves 100% on import migration, so it offers no room to separate methods. • D EP R EPAIR ’s gains concentrate on CAM and DR. D EP R EPAIR’s advantage lands on compound API migration (CAM) and direct rename (DR), where structured evidence most directly helps: on the Opus backbone it lifts CAM from 64% to 80% (+16pp) and DR from 63% to 78% (+15pp) over the minimal baseline, and on GPT5.5 it lifts CAM from 88% to 96% (+8pp) and DR from 81% to 93% (+12pp). • Paradigm shift is the residual gap. Paradigm shift (PS) is now the hardest subcategory: even D EP R EPAIR reaches only 65% (GPT-5.5) and 70% (Opus), and the minimal baselines fall to 55–60%. It is also lifted—+10pp on both backbones (GPT 55%→65%, Opus 60%→70%)— but remains the residual gap, as it demands structural refactoring beyond the rule-level edits that structured evidence most readily supplies. •
Broken down by ecosystem, D EP R EPAIR (GPT-5.5) solves all 38 Maven instances and 14 of 15 Cargo instances, with npm (26/33) and PyPI (7/9) trailing; the PyPI pocket—once a complete blind spot—is now largely repairable, leaving paradigm-shift instances as the clearest target for future work. H. Case Studies We close with three real D EP R EPAIR patches (Figs. 3– 5) that make the RQ4 difficulty gradient concrete, spanning compound API migration (CAM), direct rename (DR), and paradigm shift (PS) across three ecosystems—Maven, PyPI, and npm. Each shows how, once the upstream change is distilled into migration rules and localized to the affected sites, a single call emits a compact edit whose shape matches the kind of migration. •
exec-068 (junit, CAM). The structured rules tie the JUnit 4→5 namespace move, the Mockito runner-to-extension switch (@RunWith(MockitoJUnitRunner)→ @ExtendWith(MockitoExtension)), and the @Before→@BeforeEach / Assert→Assertions renames into one change; D EP R EPAIR applies all of
exec-068 : JUnit 4→5 (Maven, CAM)
exec-841 : Vue 2→3 (npm, PS)
-import org.junit.Assert; -import org.junit.Before; -import org.junit.runner.RunWith; +import org.junit.jupiter.api.Assertions; +import org.junit.jupiter.api.BeforeEach; +import org.junit.jupiter.api.extension.ExtendWith; -import org.mockito.junit.MockitoJUnitRunner; +import org.mockito.junit.jupiter.MockitoExtension; @@ -@RunWith(MockitoJUnitRunner.class) +@ExtendWith(MockitoExtension.class) public class AdapterFactoryTest { @Before + @BeforeEach public void setup() { ... } Assert.assertTrue(factory.isModelClass(...)); + Assertions.assertTrue(factory.isModelClass(...) );
import { defineComponent, - getCurrentInstance, h, + nextTick, ref, } from ’vue’; @@ expose(publicApi); const instance = getCurrentInstance(); instance?.proxy?.$nextTick(() => { + nextTick(() => { for (const key in innerRef.value) { ... }
Fig. 3. CAM. D EP R EPAIR applies the JUnit 4→5 namespace move, the Mockito runner-to-extension switch, and the annotation/assertion renames together in one coordinated patch.
exec-180 : Pydantic 1→2 (PyPI, DR)
Fig. 5. PS. The Vue 2 instance-proxy idiom has no symbol-level equivalent; D EP R EPAIR restructures it into the standalone nextTick import and call—a pattern rewrite, not a rename.
each landing precisely on the migrated API surface that the structured evidence identified. VI. D ISCUSSION
Why structured evidence wins. The dominant failure is the empty patch: facing a raw changelog, the model must decide what changed, where it matters, and how to edit at once, and often does none—returning no patch (32 of 95 for Direct LLM (upstream) and 35 for Agentic Claude Code, versus 10 for D EP R EPAIR). D EP R EPAIR factors this decision—evidence extraction answers what, localization where, and subcategory guidance how—converting non-answers into small, oraclepassing patches. The value of cross-repository context thus lies in its processing, not its mere provision (RQ3): raw text is counterproductive, whereas distilled rules reliably help. We do not overclaim: in a single call D EP R EPAIR significantly beats the same-backbone Direct LLM (minimal) and every raw-evidence configuration, while only matching the strongest Fig. 4. DR. The Pydantic v2 renames are pure symbol substitutions; D EP R EPAIR sweeps every occurrence and adds the ConfigDict import cross-architecture agent on each backbone. that the new names require. Threats to validity. We organize threats along the four standard dimensions. • Statistical conclusion validity. All methods run on the them together, as a partial CAM that omits any one same 95 instances, so we use the paired McNemar would leave the test uncompilable. test (exact binomial form when discordant pairs are • exec-180 (pydantic, DR). The Pyfew) and Fisher’s exact test as a conservative check. At dantic v2 renames are pure symbol n=95 power is limited, so we separate ranking claims substitutions—.dict()→.model_dump(), (D EP R EPAIR is first on each backbone) from significance __fields__→model_fields, claims, stating only that it significantly beats the same__fields_set__→model_fields_set—which backbone Direct LLM (minimal) and all raw-evidence D EP R EPAIR sweeps exhaustively while pulling in the configurations while matching the strongest agent. ConfigDict import the new API needs. • Construct validity. The oracle counts an instance as • exec-841 (vue, PS). The Vue 2 idiom repaired iff the breakage-related tests pass, which cannot getCurrentInstance().proxy.$nextTick(...) certify correctness beyond test coverage; we mitigate has no one-to-one Vue 3 replacement; D EP R EPAIR this with the developer’s own test suite and executable rewrites it into the standalone nextTick(...) import verdicts rather than file-level equivalence. Subcategory and call—the kind of structural pattern change (not labels are author-assigned and released for scrutiny. renaming) that keeps PS the residual gap (RQ4). • Internal validity. Outputs are re-applied and re-executed in freshly rebuilt containers, so the oracle is determinRead together, the three trace one capability at rising difficulty: istic; generation uses temperature 0 with no retries, and a coordinated multi-API rewrite for CAM, a mechanical timeouts or errors count as failures. symbol sweep for DR, and a structural replacement for PS— -from pydantic import BaseModel, Field, validator +from pydantic import BaseModel, ConfigDict, Field, validator @@ ... for key, value in self.dict().items() ... + ... for key, value in self.model_dump().items() ... @@ return {a for a in cls.__dict__["__fields__"]. keys() ...} + return {a for a in cls.model_fields.keys() ...} @@ self.__fields__[field].alias for field in self. __fields_set__ + self.model_fields[field].alias for field in self.model_fields_set
External validity. Results may not generalize beyond the studied packages and ecosystems; we mitigate singlemodel bias with two very different backbones (GPT-5.5 and Claude Opus 4.6) that show consistent trends. Limitations. • Data volume. D EP B ENCH currently comprises 95 instances, which limits statistical power; we are expanding it toward 200 instances to sharpen significance and broaden coverage. • Data distribution. Instances are unevenly spread across ecosystems and subcategories (e.g., Maven 38 vs. PyPI 9; paradigm shift only 20), so some per-cell rates rest on small samples; a more balanced distribution would make subcategory comparisons more robust. Generalizability. While evaluated on four ecosystems, D E P R EPAIR ’s approach is ecosystem-agnostic: the upstream evidence extraction, localization, and subcategory-aware prompting stages apply to any language. The consistent improvement across two very different LLM backbones (GPT-5.5 and Claude Opus 4.6) suggests that D EP R EPAIR’s benefits are not model-specific. •
VII. C ONCLUSION We presented D EP R EPAIR, an LLM-based approach to source-code repair for dependency breaking changes. By combining upstream evidence extraction, consumer-side usage localization, and subcategory-aware prompt construction, D EP R EPAIR attains the highest executable pass rate on each backbone—89.5% (GPT-5.5) and 82.1% (Claude Opus 4.6)— on a benchmark of 95 real-world instances, significantly beating the same-backbone Direct LLM (minimal) baseline on both backbones and ranking ahead of state-of-the-art coding agents. A generation-side analysis shows that the empty patch—the model emits no usable patch—is the dominant failure mode: raw upstream evidence drives empty patches on up to a third of instances, whereas D EP R EPAIR emits one on only 10 of 95 and nearly every patch it does emit passes, identifying the empty patch as the largest single barrier that structured evidence relieves. Our analysis further reveals that raw upstream evidence is a double-edged sword—hurting both LLMs (up to −10.5pp) and agents (up to −23.2pp)—while structured evidence extraction is essential for effective repair. These findings highlight the importance of cross-repository context processing, not merely provision, in LLM-based program repair. ACKNOWLEDGMENT Generative AI tools were used to assist with drafting and editing portions of this manuscript. All technical content, experimental results, and conclusions were produced and verified by the authors. R EFERENCES [1] S. Raemaekers, A. van Deursen, and J. Visser, “Semantic versioning and impact of breaking changes in the maven repository,” Journal of Systems and Software, vol. 129, pp. 140–158, 2017.
[2] C. Bogart, C. Kästner, J. Herbsleb, and F. Thung, “How to break an api: cost negotiation and community values in three software ecosystems,” in Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2016, pp. 109–120. [3] R. G. Kula, D. M. German, A. Ouni, T. Ishio, and K. Inoue, “Do developers update their library dependencies? an empirical study on the impact of security advisories on library migration,” Empirical Software Engineering, vol. 23, no. 1, pp. 384–417, 2018. [4] R. Lu, L. Zhang, K. Li, M. Zhang, and Y. Chen, “Minimizing breaking changes and redundancy in mitigating technical lag for java projects,” arXiv preprint arXiv:2511.06762, 2025. [5] A. Decan, T. Mens, and P. Grosjean, “An empirical comparison of dependency network evolution in seven software packaging ecosystems,” vol. 24, no. 1. Springer, 2019, pp. 381–416. [6] M. Zimmermann, C.-A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in 28th USENIX Security symposium (USENIX security 19), 2019, pp. 995–1010. [7] J. Henkel and A. Diwan, “Catchup! capturing and replaying refactorings to support api evolution,” in Proceedings of the 27th international conference on Software engineering, 2005, pp. 274–283. [8] C. Teyton, J.-R. Falleri, and X. Blanc, “Mining library migration graphs,” in 2012 19th Working Conference on Reverse Engineering. IEEE, 2012, pp. 289–298. [9] D. Dig and R. Johnson, “How do apis evolve? a story of refactoring,” Journal of software maintenance and evolution: Research and Practice, vol. 18, no. 2, pp. 83–107, 2006. [10] C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan, “Swe-bench: Can language models resolve real-world github issues?” in International Conference on Learning Representations, vol. 2024, 2024, pp. 54 107–54 157. [11] OpenAI, “Codex CLI is a coding agent that runs in your terminal,” https://github.com/openai/codex, 2025, apache-2.0 license. Accessed: 2026-06-13. [12] Anthropic, “Claude code is an agentic coding tool,” https://code.claude.com/docs/en/overview, 2025, accessed: 2026-06-13. [13] L. Xavier, A. Brito, A. Hora, and M. T. Valente, “Historical and impact analysis of api breaking changes: A large-scale study,” in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2017, pp. 138–147. [14] A. Brito, L. Xavier, A. Hora, and M. T. Valente, “Why and how java developers break apis,” in 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2018, pp. 255–265. [15] L. Ochoa, T. Degueule, J.-R. Falleri, and J. Vinju, “Breaking bad? semantic versioning and impact of breaking changes in maven central: An external and differentiated replication study,” Empirical Software Engineering, vol. 27, no. 3, p. 61, 2022. [16] S. Mostafa, R. Rodriguez, and X. Wang, “Experience paper: a study on behavioral backward incompatibilities of java software libraries,” in Proceedings of the 26th ACM SIGSOFT international symposium on software testing and analysis, 2017, pp. 215–225. [17] D. Jayasuriya, V. Terragni, J. Dietrich, S. Ou, and K. Blincoe, “Understanding breaking changes in the wild,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023, pp. 1433–1444. [18] E. Derr, S. Bugiel, S. Fahl, Y. Acar, and M. Backes, “Keep me updated: An empirical study of third-party library updatability on android,” in Proceedings of the 2017 ACM SIGSAC conference on computer and communications security, 2017, pp. 2187–2200. [19] A. A. Sawant, R. Robbes, and A. Bacchelli, “To react, or not to react: Patterns of reaction to api deprecation,” Empirical Software Engineering, vol. 24, no. 6, pp. 3824–3870, 2019. [20] A. Decan, T. Mens, and E. Constantinou, “On the impact of security vulnerabilities in the npm package dependency network,” in Proceedings of the 15th international conference on mining software repositories, 2018, pp. 181–191. [21] I. Pashchenko, H. Plate, S. E. Ponta, A. Sabetta, and F. Massacci, “Vulnerable open source dependencies: Counting those that matter,” in Proceedings of the 12th ACM/IEEE international symposium on empirical software engineering and measurement, 2018, pp. 1–10. [22] M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife collection: A review of open source software supply chain attacks,” in
International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 2020, pp. 23–43. [23] P. Ladisa, H. Plate, M. Martinez, and O. Barais, “Sok: Taxonomy of attacks on open-source software supply chains,” in 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 1509–1526. [24] C. Soto-Valero, N. Harrand, M. Monperrus, and B. Baudry, “A comprehensive study of bloated dependencies in the maven ecosystem,” Empirical Software Engineering, vol. 26, no. 3, p. 45, 2021. [25] Y. Wang, M. Wen, Z. Liu, R. Wu, R. Wang, B. Yang, H. Yu, Z. Zhu, and S.-C. Cheung, “Do the dependency conflicts in my project matter?” in Proceedings of the 2018 26th ACM joint meeting on european software engineering conference and symposium on the foundations of software engineering, 2018, pp. 319–330. [26] Y. Wang, M. Wen, Y. Liu, Y. Wang, Z. Li, C. Wang, H. Yu, S.C. Cheung, C. Xu, and Z. Zhu, “Watchman: Monitoring dependency conflicts for python library ecosystem,” in Proceedings of the ACM/IEEE 42nd international conference on software engineering, 2020, pp. 125– 135. [27] Y. Wang, B. Chen, K. Huang, B. Shi, C. Xu, X. Peng, Y. Wu, and Y. Liu, “An empirical study of usages, updates and risks of third-party libraries in java projects,” in 2020 IEEE International conference on software maintenance and evolution (ICSME). IEEE, 2020, pp. 35–45. [28] C. Liu, S. Chen, L. Fan, B. Chen, Y. Liu, and X. Peng, “Demystifying the vulnerability propagation and its evolution via dependency trees in the npm ecosystem,” in Proceedings of the 44th international conference on software engineering, 2022, pp. 672–684. [29] J. Cox, E. Bouwers, M. Van Eekelen, and J. Visser, “Measuring dependency freshness in software systems,” in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 2. IEEE, 2015, pp. 109–118. [30] S. Mirhosseini and C. Parnin, “Can automated pull requests encourage software developers to upgrade out-of-date dependencies?” in 2017 32nd IEEE/ACM international conference on automated software engineering (ASE). IEEE, 2017, pp. 84–94. [31] M. Alfadel, D. E. Costa, E. Shihab, and M. Mkhallalati, “On the use of dependabot security pull requests,” in 2021 IEEE/ACM 18th International conference on mining software repositories (MSR). IEEE, 2021, pp. 254–265. [32] B. E. Cossette and R. J. Walker, “Seeking the ground truth: a retroactive study on the evolution and migration of software libraries,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering, 2012, pp. 1–11. [33] G. Mezzetti, A. Møller, and M. T. Torp, “Type regression testing to detect breaking changes in node. js libraries,” in 32nd European Conference on Object-Oriented Programming, ECOOP 2018. Dagstuhl Publishing, 2018, pp. 7–1. [34] B. Dagenais and M. P. Robillard, “Recommending adaptive changes for framework evolution,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 20, no. 4, pp. 1–35, 2011. [35] H. A. Nguyen, T. T. Nguyen, G. Wilson Jr, A. T. Nguyen, M. Kim, and T. N. Nguyen, “A graph-based approach to api usage adaptation,” ACM Sigplan Notices, vol. 45, no. 10, pp. 302–321, 2010. [36] M. Fazzini, Q. Xin, and A. Orso, “Automated api-usage update for android apps,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis, 2019, pp. 204–215. [37] S. Xu, Z. Dong, and N. Meng, “Meditor: inference and application of api migration edits,” in 2019 IEEE/ACM 27th International Conference on Program Comprehension (ICPC). IEEE, 2019, pp. 335–346. [38] M. Lamothe, W. Shang, and T.-H. P. Chen, “A3: Assisting android api migrations using code examples,” IEEE Transactions on Software Engineering, vol. 48, no. 2, pp. 417–431, 2020. [39] C. S. Xia, Y. Wei, and L. Zhang, “Automated program repair in the era of large pre-trained language models,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1482–1494. [40] Z. Fan, X. Gao, M. Mirchev, A. Roychoudhury, and S. H. Tan, “Automated repair of programs from large language models,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1469–1481. [41] M. Jin, S. Shahriar, M. Tufano, X. Shi, S. Lu, N. Sundaresan, and A. Svyatkovskiy, “Inferfix: End-to-end program repair with llms,” in Proceedings of the 31st ACM joint european software engineering conference and symposium on the foundations of software engineering, 2023, pp. 1646–1656.
[42] X. Hou, Y. Zhao, Y. Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engineering: A systematic literature review,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 8, pp. 1–79, 2024. [43] C. S. Xia, Y. Deng, S. Dunn, and L. Zhang, “Agentless: Demystifying llm-based software engineering agents,” arXiv preprint arXiv:2407.01489, 2024. [44] J. Yang, C. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated software engineering,” Advances in Neural Information Processing Systems, vol. 37, pp. 50 528–50 652, 2024. [45] X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh et al., “Openhands: An open platform for ai software developers as generalist agents,” in International Conference on Learning Representations, vol. 2025, 2025, pp. 65 882–65 919. [46] Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury, “Autocoderover: Autonomous program improvement,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2024, pp. 1592–1604. [47] I. Bouzenia, P. Devanbu, and M. Pradel, “Repairagent: An autonomous, llm-based agent for program repair,” in 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2025, pp. 2188–2200. [48] R. Bairi, A. Sonwane, A. Kanade, V. D. C, A. Iyer, S. Parthasarathy, S. Rajamani, B. Ashok, and S. Shet, “Codeplan: Repository-level coding using llms and planning,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 675–698, 2024.