逃离Python依赖地狱：一种用于Python依赖解析的混合重放与修复管道

# Escaping Python Dependency Hell: A Hybrid Replay-and-Repair Pipeline for Python Dependency Resolution
Source: [https://arxiv.org/html/2609.26952](https://arxiv.org/html/2609.26952)
Veronica Poweska1⋄\\diamond, Ariana Oyanguren1⋄\\diamond, Jessica Pourleyli1⋄\\diamond, Sourena Khanzadeh23, Manar Alalfi1††thanks:Sourena Khanzadeh’s affiliation with Flybits began after the work reported in this paper had commenced\.Affiliation:1Toronto Metropolitan University, Computer Science, Toronto, Ontario, Canada \{vpoweska, aoyangurenvaldivia, jessica\.pourleyli, sourena\.khanzadeh, manar\.alalfi\}@torontomu\.caAffiliation:2Toronto Metropolitan University, Creative School, Toronto, Ontario, CanadaAffiliation:3Flybits, Creative AI Hub, Toronto, Ontario, Canada sourena\.khanzadeh@flybits\.comAffiliation:⋄\\diamondThese authors contributed equally to this work\.

June 2026

###### Abstract

Dependency conflicts in Python ecosystems arise from incompatible version constraints, missing packages, and undocumented compatibility relationships, causing many real\-world code snippets to fail at execution\. This paper presents PLLM\+, a hybrid dependency\-repair pipeline evaluated on the HG2\.9K benchmark of 2,891 dependency\-failing snippets\. PLLM\+ prioritizes inexpensive deterministic steps before invoking LLM\-based repair: static AST\-based interpreter inference, replay of historically successful dependency configurations from the competition\-provided solutions database, and live PyPI validation of candidate package versions\. When these steps do not resolve a case, the system falls back to a structured LLM\-based repair loop with typed error classification and Proposer/Critic agents\. On HG2\.9K, PLLM\+ solves 1,500 out of 2,891 snippets, compared with 1,169 solved by the PLLM baseline\. It also reduces average runtime from 368\.7 to 71\.8 seconds per snippet\. Most successful fixes come from replaying known configurations: 1,495 of the 1,500 successful fixes are produced by the solutions database, while the LLM fallback accounts for 5 additional fixes\. These results suggest that, in this benchmark setting, deterministic reuse of previously validated dependency configurations is a simple and effective strategy, with LLM\-based repair serving as a secondary fallback for cases not covered by prior solutions\. The code can be found at111https://github\.com/vpoweska/fse\-aiware\-python\-dependenciesand will be released upon publication\.

## IIntroduction

Modern software engineering depends heavily on third\-party libraries, but this reliance introduces a persistent problem: dependency conflicts\. Incompatible version constraints cause installation failures and broken execution environments, and prior work has shown that a substantial portion of real\-world Python programs fail to run due to missing or incompatible dependencies\[[1](https://arxiv.org/html/2609.26952#bib.bib1)\]\. The problem has grown as packages drop support for older interpreters and change their constraints over time\[[2](https://arxiv.org/html/2609.26952#bib.bib3)\]\. The FSE\-AIWare codebase formalizes this challenge, building agentic systems that automatically repair Python dependency specifications on the HG2\.9K dataset; it provides a reference implementation \(PLLM\) and its evaluation artifacts, and encourages reuse of previously successful configurations\[[3](https://arxiv.org/html/2609.26952#bib.bib2),[1](https://arxiv.org/html/2609.26952#bib.bib1)\]\.

Resolving conflicts automatically is hard because compatibility relationships are largely implicit, the space of valid combinations is large, and fixing one conflict can introduce another\. Existing LLM\-based approaches tackle this with iterative error\-feedback loops\[[4](https://arxiv.org/html/2609.26952#bib.bib4)\], but can still generate dependencies or versions that look plausible but fail in practice\. We introducePLLM\+, a hybrid pipeline that first reuses historical solution data, performs static syntax\-based interpreter inference, and validates candidate versions against PyPI before falling back to LLM\-based repair\. Our goal is not to replace deterministic dependency resolution with LLM reasoning, but to study how far a replay\-first strategy can go on the HG2\.9K benchmark and where an LLM fallback can add coverage\. We address three research questions: whether PLLM\+ improves the success rate over PLLM on HG2\.9K \(RQ1\), whether it resolves conflicts more efficiently in average time per snippet \(RQ2\), and what share of its fixes come from the solutions database versus the LLM fallback \(RQ3\)\. Our contributions are:

- •We present PLLM\+, a hybrid dependency\-repair pipeline that prioritizes deterministic replay and validation before invoking LLM\-based repair\.
- •We evaluate PLLM\+ on the HG2\.9K benchmark and show that it improves success rate and runtime compared with the PLLM baseline under the benchmark setting\.
- •We report where successful fixes come from, showing that the solutions database is the primary source of successful repairs, while the LLM fallback provides limited additional coverage\.
- •We provide a reproducible implementation integrated with the FSE\-AIWare framework\. The code and artifacts will be released upon publication\.

![Refer to caption](https://arxiv.org/html/2609.26952v1/arch.png)Fig\. 1:High\-Level Architecture of the PLLM\+ enhanced dependency repair pipeline\.
## IIRelated Work

Early dependency\-inference systems treat the task as knowledge retrieval\. DockerizeMe builds an inter\-dependency graph to generate a Dockerfile for a snippet\[[5](https://arxiv.org/html/2609.26952#bib.bib12)\], and PyEGo extends this with a knowledge graph that jointly infers packages, interpreter, and system libraries at compatible versions\[[6](https://arxiv.org/html/2609.26952#bib.bib13)\]; later graph\-based tools such as ReadPy add iterative refinement and adaptive knowledge maintenance\[[7](https://arxiv.org/html/2609.26952#bib.bib14)\]\. These methods are reproducible but bounded by the coverage and freshness of a hand\-built knowledge base\[[2](https://arxiv.org/html/2609.26952#bib.bib3)\], a difficulty compounded by the scale and prevalence of configuration issues across the PyPI ecosystem\[[8](https://arxiv.org/html/2609.26952#bib.bib18)\]\. PLLM instead casts repair as LLM generation, using retrieval\-augmented prompting with an iterative build\-feedback loop, though it remains susceptible to hallucinated versions\[[4](https://arxiv.org/html/2609.26952#bib.bib4)\]\. PLLM\+ keeps deterministic retrieval as a fast path while validating every candidate against live PyPI to eliminate non\-existent releases before any build\.

More broadly, LLM\-based program repair spans prompting, procedural, and agentic designs, the last delegating loop control to the model at higher latency and cost\[[9](https://arxiv.org/html/2609.26952#bib.bib15),[10](https://arxiv.org/html/2609.26952#bib.bib16)\]\. Cooperative multi\-agent frameworks extend this further, coordinating specialised agents across software development tasks\[[11](https://arxiv.org/html/2609.26952#bib.bib19)\]and refining inter\-agent communication\[[12](https://arxiv.org/html/2609.26952#bib.bib17)\]\. PLLM\+ instead adopts a procedural design with the LLM as a bounded fallback, and for that fallback uses multi\-agent debate, which improves factual accuracy over single\-model reasoning that tends to confirm its own errors\[[13](https://arxiv.org/html/2609.26952#bib.bib5)\]\. Our Proposer–Critic loop instantiates this for dependency repair, with all surviving candidates still validated against PyPI\.

## IIIMethodology

Figure[1](https://arxiv.org/html/2609.26952#S1.F1)presents an overview of the PLLM\+ architecture\. Given a single Python snippet, the goal is to construct a Docker container in which it executes without dependency\-related failures\. The pipeline proceeds through four stages in priority order, stopping as soon as a solution is found, and is deliberately ordered so that cheap, deterministic operations are attempted before LLM reasoning is invoked as a fallback\.

##### Stage 1: Static AST Analysis

The snippet is parsed with Python’s built\-inastmodule to determine the minimum required interpreter version\[[14](https://arxiv.org/html/2609.26952#bib.bib6)\], inspecting the syntax tree for version\-specific constructs \(e\.g\., the walrus operator:=, valid only in Python 3\.8 or later\[[15](https://arxiv.org/html/2609.26952#bib.bib10)\]\)\. This establishes a hard lower bound before any LLM call, preventing the system from proposing or testing versions that are syntactically incompatible with the snippet and steering the pipeline toward versions more likely to succeed\.

##### Stage 2: Solutions Database

The competition provides, and encourages reuse of, result archives from the original PLLM experiment together with PyEGo and ReadPy artifacts\[[3](https://arxiv.org/html/2609.26952#bib.bib2)\]\. We parse these tar archives of YAML results for all 2,891 snippets and, for each successful run, record the exact package versions from the final iteration before the success marker\. Multiple passing configurations per snippet are preserved under unique run identifiers rather than overwritten\. At query time, all known configurations for a snippet are returned in ascending order of package count, and each is built and run until one succeeds or all are exhausted\. This exhaustive replay means that even when the first solution uses an incompatible interpreter or a package version that has since changed on PyPI, later solutions are tried automatically without invoking the LLM\. A compatibility filter using the Stage 1 lower bound discards configurations that will always fail, avoiding wasted Docker builds\.

##### Stage 3: Live PyPI Validation

When no database solution succeeds, the system falls through to the LLM pipeline\. Beforehand, candidate versions are validated against the PyPI JSON API\[[16](https://arxiv.org/html/2609.26952#bib.bib7)\]: for each detected import, the resolver queries PyPI for the real list of versions available for the target Python version and returns the latest compatible release\. A hard\-coded cap table handles Python 2\.7, since many packages dropped 2\.7 support at different releases after its end\-of\-life\[[17](https://arxiv.org/html/2609.26952#bib.bib8)\], creating compatibility boundaries not always captured by PyPI metadata\[[18](https://arxiv.org/html/2609.26952#bib.bib9)\]\. This eliminates hallucinated or non\-existent versions before they reach a build, a major source of wasted attempts in the PLLM baseline\.

##### Stage 4: Multi\-Agent Repair Loop

On a failed build, the error is classified into a structured type \(ModuleNotFoundError,ImportError,DependencyConflict,NonZeroCode, orSyntaxError\), each mapped to a specialist prompt that injects the most relevant context; forNoMatchingDistribution, for instance, the available versions parsed from the pip error are supplied so the model selects from versions known to exist rather than guessing\[[19](https://arxiv.org/html/2609.26952#bib.bib11)\]\. Repair then uses a two\-role debate\[[13](https://arxiv.org/html/2609.26952#bib.bib5)\]: a single instance that both generates and evaluates a candidate tends to confirm its own reasoning and repeat the same incorrect configuration, whereas separating generation from critique exploits the finding that models detect flaws more reliably than they avoid them\. The Proposer produces a revised package set from the error class, current configuration, and knowledge graph context; the Critic independently screens it for implausible versions, missing dependencies, and known incompatibilities before a build is triggered\. Every surviving candidate is re\-validated against PyPI, so hallucinated versions cannot enter the pipeline regardless of what the agents propose\. The loop repeats for up to five iterations\.

##### Knowledge Graph

Across a batch run, verified package combinations accumulate in a persistent knowledge graph indexed by package name and Python version\. When the LLM pipeline runs, matching entries for the snippet’s imports are injected as retrieved context\. This both narrows the search space by anchoring suggestions to combinations already proven to work and produces a compounding effect: solutions from early snippets benefit later ones sharing common dependencies, which is especially effective for frequent packages such asnumpy,pandas, andrequests\.

### III\-AValidation and Optimization

A configuration is valid only if the container builds and the snippet executes without dependency\-related failures, the same build\-and\-run criterion used by the competition and PLLM, enabling a direct CSV\-to\-CSV comparison on snippet ID and outcome\[[13](https://arxiv.org/html/2609.26952#bib.bib5)\]\. Three optimizations reduce wasted effort\. Exhaustive replay \(above\) is the most impactful, since a snippet may have been solved on a different Python version across PLLM runs, so testing all stored configurations before the LLM conserves resources\. Second, afrom versions: noneerror—indicating a package absent from PyPI—is detected directly from pip output, and the offending package is dropped without entering the debate loop\. Third, duplicate database entries are detected via a content hash of the package set and skipped, avoiding repeated failing builds\.

### III\-BImplementation

PLLM\+ is implemented in Python as separable components—static analysis, solutions database management, PyPI validation, error classification, multi\-agent debate, and persistent knowledge storage—interacting through well\-defined interfaces\. Separating deterministic from LLM\-assisted stages makes behaviour on database\-covered snippets fully reproducible and independent of model non\-determinism while retaining LLM flexibility for novel failures\. The system is compatible with the FSE\-AIWare framework and accepts the same input format as PLLM, allowing direct comparison on HG2\.9K\.

## IVEvaluation

In this section, we describe the setup used to run the experiments and provide a detailed discussion of empirical results obtained for research questions RQ1\-RQ3\.

### IV\-AExperimental setup

All experiments were run on a GPU cluster, each machine uses an 11th Gen Intel Core i7 processor with 8 cores and 16 threads, 15 GB of RAM, and two NVIDIA GeForce GTX 1070 GPUs\. The machines run Ubuntu 24\.04\.

Our system uses an Ollama server to run the language model, specifically Gemma 2\. All parts of the system were deployed using Docker containers so that the environment stayed consistent across runs\. The containers communicated through a shared Docker network\. To evaluate the tool, we ran it on the full set of final Python code snippets in the dataset\. Each snippet was processed once\.

The results from every run were saved automatically in a file calledsummary\_all\_runs\.csv\. This file includes the fields:snippet\_id, snippet\_path, return\_code, solved, elapsed\_seconds, status, and error\.

Here,return\_codeshows whether the run finished properly, solved shows if the snippet was handled successfully, andelapsed\_secondsshows how long it took\. The status field gives a short result label, and error stores the failure message if something went wrong\.

To make the experiments reproducible, the code, setup steps, and instructions are all included in the project repository\.

### IV\-BResults

#### IV\-B1RQ1: Does PLLM\+ achieve a higher success rate than the PLLM baseline on the HG2\.9K benchmark?

To answer this research question, we compare how many snippets were successfully solved by PLLM and PLLM\+ on HG2\.9K using thesummary\_all\_runs\.csvfiles from both tools\.

As shown in Figure[2](https://arxiv.org/html/2609.26952#S4.F2), PLLM solved 1,169 out of 2,891 snippets, while PLLM\+ solved 1,500 out of 2,891\. This gives PLLM a success rate of 40\.4% and PLLM\+ a success rate of 51\.9%\. PLLM\+ solved 331 more snippets than the baseline and improved the success rate by 11\.5 percentage points\. Based on these results, PLLM\+ performs better than PLLM on the benchmark, suggesting that the replay\-based approach helps the system resolve more dependency issues successfully\.

![Refer to caption](https://arxiv.org/html/2609.26952v1/success_comparison_pies.png)Fig\. 2:Success rate across tools
#### IV\-B2RQ2: Does PLLM\+ resolve dependency conflicts more efficiently than the PLLM baseline, measured by average resolution time per snippet?

TABLE I:Failure categories: counts per tool on unsuccessful runs \(same 2891 snippets\)\. Our tool usesstatus; baselines useresult\.To answer this research question, we compare both the average and median runtime per snippet for PLLM and PLLM\+ using theelapsed\_secondsvalues recorded in the output CSV files\.

PLLM had an average runtime of 368\.74 seconds per snippet, while PLLM\+ averaged 71\.77 seconds—296\.97 seconds faster, or about 5\.1 times faster than the baseline\. The same gap holds at the median: 364\.48 seconds for PLLM versus 21\.5 seconds for PLLM\+\.

One likely explanation is that many PLLM\+ snippets were resolved quickly through replaying known dependency configurations, while more difficult cases required additional fallback processing\. Overall, these results show that PLLM\+ resolves dependency issues much more efficiently than PLLM\.

#### IV\-B3RQ3: What portion of the successful fixes arise from configurations stored in the competition\-provided solutions database compared to the LLM\-based fallback pipeline?

To answer this research question, we examined how each successful fix in PLLM\+ was produced\. Specifically, we tracked whether a solved snippet was resolved through replaying a stored dependency configuration from the solutions database or through the LLM\-based fallback pipeline\.

As shown in Figure[3](https://arxiv.org/html/2609.26952#S4.F3), PLLM\+ successfully solved 1500 snippets in total\. Out of these, 1495 were solved using the solutions database, while only 5 were solved using the LLM fallback pipeline\. This corresponds to 99\.7% of successful fixes coming from database replay and 0\.3% coming from the LLM\.

![Refer to caption](https://arxiv.org/html/2609.26952v1/fix_source_pie.png)Fig\. 3:Source of successful fixes in PLLM\+: solutions database replay vs\. LLM fallback\.These results show that almost all successful fixes in PLLM\+ came from reusing previously known working configurations rather than generating new solutions through the LLM\. This suggests that the main strength of PLLM\+ comes from its ability to retrieve and replay valid dependency setups efficiently\.

This is an important result because it shows that many dependency resolution problems in the benchmark can be handled by matching and reusing known configurations instead of resolving them from scratch\. In practice, this makes the system both faster and more reliable\.

At the same time, the LLM fallback still plays a useful role for cases where no matching configuration is found in the database\. Even though it contributed to only a small number of successful fixes in our experiments, it provides coverage for cases that cannot be solved through direct reuse alone\.

Overall, these results suggest that the knowledge\-base component is the primary driver of PLLM\+ performance, while the LLM fallback acts as a secondary recovery mechanism\.

Table[I](https://arxiv.org/html/2609.26952#S4.T1)breaks down the unsuccessful runs by failure category across all four tools on the same 2,891 snippets\. The knowledge\-graph baselines fail in semantically specific ways—PyEGo and ReadPy together account for the bulk ofImportErrorandModuleNotFoundcases, and ReadPy additionally incurs 612 build failures—while PLLM’s failures spread acrossSyntaxError,NoMatchingDistribution, and other runtime categories\. In contrast, PLLM\+ records its unsolved cases almost entirely as a singlefailedstatus \(1,374\) plus 17 timeouts, reflecting that our pipeline reports a coarse build\-and\-run outcome rather than classifying the underlying error on unsolved snippets\.

## VDiscussion

![Refer to caption](https://arxiv.org/html/2609.26952v1/runtime_per_snippet_distribution.png)Fig\. 4:Runtime Distribution Across Different Tool SetsFigure[4](https://arxiv.org/html/2609.26952#S5.F4)shows the full per\-snippet runtime distribution for both tools, making this separation visible across the benchmark rather than only in aggregate\.

##### Implications\.

The main lesson from PLLM\+ is that dependency repair can benefit substantially from simple deterministic reuse before invoking more expensive LLM\-based reasoning\. On HG2\.9K, many failing snippets can be repaired by replaying dependency configurations that were previously observed to work\. This makes the repair process faster, more reproducible, and less dependent on model behavior\.

The LLM component remains useful as a fallback mechanism, but our results show that it is not the main source of successful fixes in this evaluation\. Instead, the strongest performance comes from ordering the pipeline by cost: first applying static interpreter inference, then replaying known configurations, then validating candidates against PyPI, and only then invoking LLM\-based repair\. This suggests that LLMs may be most useful in dependency repair when used selectively, after cheaper sources of evidence have been exhausted\.

### V\-AThreats to Validity

##### Internal\.

Repair depends on classifying build failures into error types via string matching over common patterns \(version conflict, no matching distribution, missing system dependency, Python version mismatch, and module not found\); a misclassification can trigger the wrong strategy, and design choices such as version filtering or package removal may bias the process by excluding valid configurations\. We mitigate this with structured error categories and consistent filtering and validation rules across all runs\.

##### External\.

Results are bounded by HG2\.9K, a specific set of GitHub snippets that may not represent all real\-world dependency issues\. Crucially, most successful fixes draw on the provided solutions database, which is built from the same dataset, so performance on completely new or unseen data may differ\. We reduce this threat by evaluating on the full benchmark under the same setup as the PLLM baseline\.

### V\-BLimitations and Future Work

PLLM\+’s main limitation is its reliance on the solutions database: high success and low runtime depend on how many cases are already covered\. The database is currently limited to benchmark\-provided configurations and could be expanded with external sources—open\-source repositories, package documentation, or developer discussions such as Stack Overflow—to broaden coverage\.

## VIConclusion

This paper presented PLLM\+, a hybrid pipeline for automated Python dependency repair\. The system combines static interpreter inference, replay of previously validated dependency configurations, live PyPI validation, and a bounded LLM\-based fallback\. On the HG2\.9K benchmark, PLLM\+ solved 1,500 out of 2,891 snippets, compared with 1,169 solved by the PLLM baseline, while substantially reducing average runtime\. The evaluation shows that the main source of improvement is deterministic replay of known\-good configurations\. In our experiments, 1,495 of the 1,500 successful fixes came from the solutions database, while the LLM fallback solved 5 additional cases\. This result suggests that, at least for this benchmark, dependency repair benefits strongly from efficient reuse and validation of prior solutions\. We therefore view PLLM\+ as a practical hybrid design: use deterministic methods whenever possible, and reserve LLM\-based repair for cases where prior validated configurations are unavailable\. A natural next step is to evaluate the same design on held\-out snippets or external repositories with less overlap with the existing solutions database\. Future work should also strengthen the LLM fallback and expand the retrieval source beyond benchmark artifacts, for example by mining open\-source repositories, package documentation, and developer discussions for validated dependency configurations\.

## References

- \[1\]\(2018\)Gistable: evaluating the executability of python code snippets on github\.In2018 IEEE international conference on software maintenance and evolution \(ICSME\),pp\. 217–227\.Cited by:[§I](https://arxiv.org/html/2609.26952#S1.p1.1)\.
- \[2\]R\. G\. Kula, D\. M\. German, A\. Ouni, T\. Ishio, and K\. Inoue\(2018\)Do developers update their library dependencies?\.Empirical Softw\. Engg\.23\(1\),pp\. 384–417\.External Links:ISSN 1382\-3256,[Link](https://doi.org/10.1007/s10664-017-9521-5),[Document](https://dx.doi.org/10.1007/s10664-017-9521-5)Cited by:[§I](https://arxiv.org/html/2609.26952#S1.p1.1),[§II](https://arxiv.org/html/2609.26952#S2.p1.1)\.
- \[3\]F\. Team\(2026\)FSE\-aiware agentic based python dependency resolution competition\.Note:https://github\.com/checkdgt/fse\-aiware\-python\-dependenciesCited by:[§I](https://arxiv.org/html/2609.26952#S1.p1.1),[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px2.p1.1)\.
- \[4\]A\. Bartlett, C\. Liem, and A\. Panichella\(2025\)The last dependency crusade: solving python dependency conflicts with llms\.In2025 40th IEEE/ACM International Conference on Automated Software Engineering Workshops \(ASEW\),pp\. 66–73\.Cited by:[§I](https://arxiv.org/html/2609.26952#S1.p2.1),[§II](https://arxiv.org/html/2609.26952#S2.p1.1)\.
- \[5\]E\. Horton and C\. Parnin\(2019\)Dockerizeme: automatic inference of environment dependencies for python code snippets\.In2019 IEEE/ACM 41st International Conference on Software Engineering \(ICSE\),pp\. 328–338\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p1.1)\.
- \[6\]H\. Ye, W\. Chen, W\. Dou, G\. Wu, and J\. Wei\(2022\)Knowledge\-based environment dependency inference for python programs\.InProceedings of the 44th International Conference on Software Engineering,pp\. 1245–1256\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p1.1)\.
- \[7\]W\. Cheng, W\. Hu, and X\. Ma\(2024\)Revisiting Knowledge\-Based Inference of Python Runtime Environments: A Realistic and Adaptive Approach\.IEEE Transactions on Software Engineering50\(02\),pp\. 258–279\.External Links:ISSN 1939\-3520,[Document](https://dx.doi.org/10.1109/TSE.2023.3346474),[Link](https://doi.ieeecomputersociety.org/10.1109/TSE.2023.3346474)Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p1.1)\.
- \[8\]Y\. Peng, R\. Hu, R\. Wang, C\. Gao, S\. Li, and M\. R\. Lyu\(2024\)Less is more? an empirical study on configuration issues in python pypi ecosystem\.InProceedings of the IEEE/ACM 46th international conference on software engineering,pp\. 1–12\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p1.1)\.
- \[9\]B\. Yang, Z\. Cai, F\. Liu, B\. Le, L\. Zhang, T\. F\. Bissyandé, Y\. Liu, and H\. Tian\(2025\)A survey of llm\-based automated program repair: taxonomies, design paradigms, and applications\.arXiv preprint arXiv:2506\.23749\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p2.1)\.
- \[10\]I\. Bouzenia, P\. Devanbu, and M\. Pradel\(2025\)Repairagent: an autonomous, llm\-based agent for program repair\.In2025 IEEE/ACM 47th International Conference on Software Engineering \(ICSE\),pp\. 2188–2200\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p2.1)\.
- \[11\]S\. Khanzadeh\(2025\)Agentmesh: a cooperative multi\-agent generative ai framework for software development automation\.arXiv preprint arXiv:2507\.19902\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p2.1)\.
- \[12\]W\. Du, B\. Wu, Y\. Sun, W\. Guo, Y\. Du, Z\. Yan, G\. Yu, and L\. Cui\(2026\)Learning efficient and interpretable multi\-agent communication\.InThe Fourteenth International Conference on Learning Representations,Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p2.1)\.
- \[13\]Y\. Du, S\. Li, A\. Torralba, J\. B\. Tenenbaum, and I\. Mordatch\(2024\)Improving factuality and reasoning in language models through multiagent debate\.InProceedings of the 41st International Conference on Machine Learning,ICML’24\.Cited by:[§II](https://arxiv.org/html/2609.26952#S2.p2.1),[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px4.p1.1),[§III\-A](https://arxiv.org/html/2609.26952#S3.SS1.p1.1)\.
- \[14\]Python Software Foundation\(2026\)ast — Abstract Syntax Trees\.Note:https://docs\.python\.org/3/library/ast\.htmlAccessed: 2026\-04\-04Cited by:[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px1.p1.1)\.
- \[15\]Python Software Foundation\(2019\)What’s new in python 3\.8\.Note:https://docs\.python\.org/3/whatsnew/3\.8\.htmlAccessed: 2026\-04\-04Cited by:[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px1.p1.1)\.
- \[16\]Python Packaging Authority\(2026\)PyPI json api documentation\.Note:https://docs\.pypi\.org/api/json/Accessed: 2026\-04\-04Cited by:[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px3.p1.1)\.
- \[17\]Numba Developers\(2020\)Python 2\.7 end of life plan\.Note:https://numba\.readthedocs\.io/en/0\.51\.2/reference/python27\-eol\.htmlAccessed: 2026\-04\-04Cited by:[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px3.p1.1)\.
- \[18\]K\. Gao, W\. Xu, W\. Yang, and M\. Zhou\(2024\)PyRadar: towards automatically retrieving and validating source code repository information for pypi packages\.Proc\. ACM Softw\. Eng\.1\(FSE\)\.External Links:[Link](https://doi.org/10.1145/3660822),[Document](https://dx.doi.org/10.1145/3660822)Cited by:[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px3.p1.1)\.
- \[19\]B\. Feuer, C\. Tseng, A\. S\. Lathe, O\. Elachqar, and J\. P\. Dickerson\(2025\)When judgment becomes noise: how design failures in llm judge benchmarks silently undermine validity\.arXiv preprint arXiv:2509\.20293\.Cited by:[§III](https://arxiv.org/html/2609.26952#S3.SS0.SSS0.Px4.p1.1)\.