Pith. sign in

REVIEW 3 major objections 5 minor 62 references

Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation

T0 review · 3 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash

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

Pith's one-line read Repository-level code generation can skip static global graphs: build dependency context on demand with an LLM, improving Pass@1 by up to 59.7% at 7.4x lower build time.

desk verdict Genuinely new on-demand partial dependency graph retrieval with consistent gains; the load-bearing expand step is under-validated (60 cases, no error breakdown), but the paper still deserves serious review. read the letter →

arxiv 2608.01927 v1 pith:LF4RV56R submitted 2026-08-03 cs.SE cs.AI

Zhongxin Liu , Zhonghao Jiang , Zhifan Ye , Haoye Wang , Jiakun Liu , Xiaoxue Ren This is my paper
classification cs.SEcs.AI
keywords repository-levelcodegenerationretrieval-augmentedpartialdependencygraphmulti-hopreasoningLLM-basedretrievalPass@1constructioncontext
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

The paper claims that the standard recipe for repository-level code generation—retrieve similar snippets, optionally traverse a pre-built static dependency graph—misses the context that matters: the specific functions the target actually calls or depends on. It proposes DyRetriever, which uses an LLM to imitate how a developer explores a codebase: pick likely entry-point functions, then hop from function to function, at each step asking the LLM whether the next dependency is worth keeping. The graph is built partially, on demand, and discarded after use, avoiding the hours-long static parse of large repositories. Integrated with similarity retrieval into DyCoder, the method reports Pass@1 improvements of 25.63% on CoderEval and 59.73% on DevEval over RAG baselines, and a 7.4x speedup over static-graph construction. The point is that retrieval rules can be replaced by the LLM's semantic judgment, and that dependency context, not just similarity, is what unlocks correct generation.

What carries the argument

Partial dependency graph with LLM-driven multi-hop expansion. Named DyRetriever, the mechanism replaces a repository-wide static graph with a small, on-demand graph grown hop by hop. The three-step loop—select, visit, expand—uses the LLM both to choose which candidate function to inspect next and to identify callee dependencies from the function's source plus its file's import statements; a post-processing step matches names against the repository to remove hallucinated or out-of-repo functions. The graph exists only during retrieval, which is what avoids global parse and maintenance cost.

What would settle it

Take a set of target functions whose full ground-truth dependency sets are known; run the Expand step for each hop and count whether the LLM's identified callees cover every real dependency (especially same-file callees not appearing in import statements). If coverage falls well below the reported 93% on a few hundred functions, or if a deliberately seeded dependency with a non-descriptive name is systematically missed, the method's core mechanism fails. Simpler: audit more than 60 expand operations and check whether missed edges correspond to Pass@1 failures.

Watch

Extended reading notes

Core claim

DyCoder's central claim is that a partial dependency graph, built dynamically by an LLM and discarded after retrieval, is both more effective and more efficient than the global static dependency graphs used by prior graph-based RAG. DyRetriever first asks the LLM to select a small set of entry-point functions from a tree-structured view of the repository, then runs a bounded multi-hop traversal: select a candidate, visit it, extract the file's import statements, ask the LLM to name the functions it calls or lazily imports, and add those as new candidates. A name-matching post-process drops fabricated or standard-library dependencies. After up to ten hops the traversal trajectory is given to

Load-bearing premise

The method assumes the LLM can reliably name all callee dependencies of a function from its source plus the file's import statements, without a static parser; this is spot-checked on only 60 expansions (93.22% accuracy), and a single missed or fabricated edge can break the retrieval chain.

Editorial extensions

If this is right

  • Repository-level RAG no longer needs a pre-built global dependency graph; on-demand partial graphs can carry the dependencies that similarity misses.
  • Hand-crafted retrieval rules (e.g., import-based traversal or similarity thresholds) can be replaced by an LLM's per-hop helpfulness judgment, making retrieval adapt to in-file and cross-file dependencies alike.
  • The retrieved context is complementary to sparse and dense similarity retrieval; DyRetriever improved BM25, RLCoder, and AlignCoder by 7.5%–30.99% Pass@1 when combined.
  • The 7.4x speedup over static graph construction means the approach can serve large repositories where static parsing takes hours, and avoids rebuilding the graph as code evolves.
  • Because the method is training-free and plug-and-play, it can be layered onto existing retrievers without retraining cost.

Reading between the lines

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

  • If the LLM's dependency-spotting accuracy generalizes beyond the 60 manually inspected expansion operations, the same on-demand traversal could be applied to other repository-scale tasks such as bug localization, feature addition, or refactoring, where the relevant code is also defined by dependency chains rather than textual similarity.
  • The reported accuracy of 93.22% is measured on a small sample; a larger audit or an adversarially constructed repository with unusual naming, dynamic dispatch, or re-exports would show how much of the method's gain depends on the specific LLM's ability to read callees.
  • Token consumption scales with the hop budget (2–2.4x baseline), so the optimal max-hop setting likely trades accuracy against cost; the paper's choice of 10 is empirical and may shift for longer functions or larger repositories.
  • The approach as presented is Python-only; statically typed languages with explicit type relations may make dependency identification easier, which would be a direct testable extension of the method's core assumption.
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

3 major / 5 minor

Summary. The paper proposes DyRetriever, an LLM-driven context-retrieval method for repository-level code generation. Instead of building a static global dependency graph, DyRetriever selects entry-point functions from a repository structure and then performs multi-hop traversal over a partial dependency graph, using the LLM to identify callees (Algorithm 1, Expand Step) and to judge whether a function is useful for the target function. The retrieved functions are combined with similarity-based retrieval results to form DyCoder. The authors evaluate DyCoder on CoderEval and DevEval with three LLMs, reporting relative Pass@1 gains of 25.63% and 59.73% over existing RAG baselines and a 7.4x speedup over the static-graph baseline RepoScope. Ablations show that both the similarity-based component and DyRetriever contribute, and RQ4 shows that DyRetriever can be combined with BM25, RLCoder, and AlignCoder.

Significance. If the findings hold, DyRetriever is a practical contribution: it avoids the construction and maintenance cost of global repository graphs, adapts to different context types without hand-crafted rules, and improves generation accuracy consistently across models and benchmarks. The paper's strengths include the multi-model and multi-benchmark evaluation, the clean ablation design (Table 3), the generalizability experiments (Table 4), and the explicit discussion of limitations in Sections 6.1 and 6.2. The replication package and official repository are also valuable. However, the central mechanism—LLM-based expansion of partial dependency graphs—is validated with only a small manual spot-check of 60 expand operations, and the maximum-hop hyperparameter is tuned on one of the two evaluation benchmarks. These issues do not invalidate the end-to-end results, but they are load-bearing for the paper's specific novelty claim that LLM-driven partial graph expansion can replace static global graph RAG.

major comments (3)
  1. [Section 6.1 / Algorithm 1, Line 15] The validity of the Expand Step is the load-bearing premise of the paper, but the evidence provided is not commensurate. The manual check covers only 60 expand operations, with no stated sampling protocol (which tasks, models, hops, or repositories), and reports only a binary 'completely accurate' rate of 93.22%. The post-processing described in Section 3.1.2 can discard hallucinated names, but it cannot recover a callee that the LLM omitted; a single missed edge on a multi-hop path can remove the only route to an essential dependency. With maxHop=10, even a small per-expansion miss rate can affect a substantial fraction of tasks. The paper should report an error breakdown distinguishing missed from fabricated edges, per-hop and path-level recall/precision, a documented sampling procedure for the 60 operations, and an analysis of whether errors occur on load-bearing edges (e.g., by compa
  2. [Section 4.4] The maximum hop hyperparameter is selected by 'preliminary experiments' on CoderEval with values in [1,20], and CoderEval is also one of the two benchmark datasets used for the headline results. This is effectively tuning on the test set. No sensitivity analysis is reported for DevEval, where the claimed relative improvement is largest (59.73%). The paper should report Pass@1 and token consumption as functions of maxHop on both benchmarks, or on a held-out development split, to demonstrate that the chosen value does not inflate the reported gains.
  3. [Section 4.1] The treatment of the 209 DevEval instances that cannot be executed in the authors' environment is transparent, but the effect on the reported comparison may still be material. 209/1825 is about 11.5% of the benchmark; if these instances are concentrated in particular repositories or have particular dependency structures, the relative improvements and rankings could be biased. The paper should characterize these 209 instances (e.g., reasons for failure, distribution across repositories) and provide a sensitivity analysis that recomputes Pass@1 after excluding them or using an alternative evaluation, to confirm the DevEval results are robust.
minor comments (5)
  1. [Section 6.1] The 60 expand operations are not tied to any specific LLM, benchmark, or sampling protocol. If they were collected from a particular configuration (e.g., Qwen3-Coder on CoderEval), that should be stated explicitly so readers can judge generalizability. The comparison with static-analysis accuracies (77.4%–99.2%) cites [42] but does not clarify whether the accuracy definitions are directly comparable.
  2. [Section 3.1.1] The parser used to extract functions from the related-file list is not specified. Please name the tool/version (e.g., tree-sitter, ast) and include it in the replication package, since function extraction is a prerequisite for both the entry-point stage and the similarity-based retrieval.
  3. [Section 3.3] The indentation post-processing for generated code is mentioned but not described. Please provide details or examples, or point to the exact implementation in the replication package, so that readers can assess its effect on the reported Pass@1.
  4. [Table 2] The 'Total imp.' column mixes a multiplier with token counts (e.g., '1.00×13.09k'), and the footnote formatting is awkward. Please clean up the table and clarify whether the dollar costs are based on local Qwen3-Coder deployment or on API pricing for the other models.
  5. [Section 1] There is a typo in the sentence 'Existing studies have [13, 29] demonstrated'—the word 'have' appears without its complement. Also, the abstract's '7.4x faster' claim is based on a single configuration (CoderEval with Qwen3-Coder-30B); please state this qualification where the speedup is advertised.

Circularity Check

0 steps flagged · score 0.0 of 10

No derivational circularity: Pass@1 is measured on external benchmarks, and self-citations are not load-bearing.

full rationale

The central effectiveness claim is evaluated by executing generated code against the test suites of CoderEval and DevEval, so the Pass@1 metric is grounded in external ground truth rather than in DyRetriever's own LLM judgments or definitions. The retrieval pipeline (entry-point selection, multi-hop expansion, top-k extraction) is an intermediate heuristic whose output is a context set; correctness is measured downstream by the benchmark, not by the LLM's self-rating. The self-citations in the paper (refs. [18], [19], and [29]) are used as related work or for the tree-structured repository representation; none of them supplies the load-bearing assertion that DyRetriever improves code generation performance. The 60-operation manual accuracy check in Sec. 6.1 is a small-sample validity concern, but it is not a circular step because it does not define the benchmark outcome. The maxHop selection on CoderEval in Sec. 6.2.1 is test-set tuning and a potential overfitting risk, but it is not a circular derivation: the reported Pass@1 is measured after fixing the hyperparameter, not computed from it. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no equation reduces to its own input by construction. The paper is therefore self-contained against external benchmarks for its central claims.

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

The method's correctness rests on LLM judgment for graph edges and entry points rather than on static analysis; these are domain assumptions that receive only a 60-case spot check. The single fitted numeric hyperparameter is maxHop, tuned on the evaluation benchmark itself.

free parameters (1)
  • maxHop = 10
    Maximum number of multi-hop reasoning steps, selected by preliminary experiments on CoderEval over the range [1,20] (Section 4.4).
assumptions (4)
  • domain assumption The LLM can accurately identify callee dependencies (call and lazy import) from a function's source code plus its file's import statements.
    Used in the Expand Step (Algorithm 1, Line 15); manually validated on only 60 expand operations (Section 6.1).
  • domain assumption A partial dependency graph grown from a few entry points captures the context needed to generate the target function.
    Core design choice of Section 3.1; assumes dependencies outside the traversed subgraph are unnecessary for generation.
  • domain assumption The tree-based repository structure is sufficient for the LLM to select related files.
    Entry point selection (Section 3.1.1) relies on prompting with the folder hierarchy.
  • domain assumption CoderEval and DevEval test suites correctly judge functional correctness.
    Pass@1 is computed by executing provided tests (Section 4.1).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation." pith.science (2026). https://pith.science/paper/LF4RV56R

@misc{pith2026260801927,
  author       = {Pith},
  title        = {Pith review of: Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LF4RV56R}},
  note         = {Machine review of arXiv:2608.01927}
}
read the original abstract

LLM-based repository-level code generation aims to generate code using the context available in a software repository, requiring LLMs to reason over complex code dependencies. Due to limited context windows and insufficient repository-specific understanding, LLMs typically rely on retrieval-augmented generation (RAG) to incorporate relevant code. Early RAG approaches primarily employ similarity-based retrieval, which often fails to retrieve code snippets that the target function depends on. Recent work introduces graph-based retrieval to model such dependencies, but typically relies on manually designed rules and static global graphs, leading to limited flexibility and high construction and maintenance costs. In contrast, human developers collect helpful context by implicitly constructing a partial dependency graph and iteratively inspecting along it. Inspired by this behavior, we propose DyRetriever, an efficient context retrieval method via partial dependency graphs. DyRetriever uses an LLM to first select a set of entry-point functions and then perform multi-hop reasoning along the code dependency graph. During multi-hop reasoning, it uses the LLM's semantic understanding to validate whether a function can help generate the target function, eliminating manually designed rules and enabling flexibility across scenarios. Instead of statically constructing a global dependency graph, DyRetriever builds a partial graph on demand and discards it after use, reducing construction and maintenance costs. We integrate DyRetriever with a similarity-based code retriever to build DyCoder and evaluate it on CoderEval and DevEval. Experimental results show that DyCoder achieves relative Pass@1 improvements of 25.63% and 59.73% on CoderEval and DevEval, respectively, compared with existing RAG-based methods, while being 7.4x faster than baselines based on static dependency graph construction.

Figures

Figures reproduced from arXiv: 2608.01927 by the authors.

Figure 1
Figure 1. A motivating example of “fs.path.iteratepath” in DevEval. demonstrates the general applicability of DyRetriever, but also provides directions for future enhancements. In summary, our main contributions are as follows: • We propose DyRetriever, a context retrieval method for repository-level code generation, inspired by human behaviors in collecting helpful code snippets. DyRetriever uses LLMs’ semantic understanding… view at source ↗
Figure 2
Figure 2. Overview of DyCoder. 3 Approach In this section, we introduce DyCoder, an LLM-driven repository￾level code generation framework. Different from existing graph￾based methods, DyCoder is a rule-free, autonomous framework that flexibly collects context through partial graphs. As shown in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. An example of the retrieved context and generated [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

62 extracted references · 10 linked inside Pith

  1. [1]

    Zhangqian Bi, Yao Wan, Zheng Wang, Hongyu Zhang, Batu Guan, Fangxin Lu, Zili Zhang, Yulei Sui, Hai Jin, and Xuanhua Shi. 2024. Iterative Refinement of Project-Level Code Context for Precise Code Generation with Compiler Feedback. InFindings of the Association for Computational Linguistics. 2336–2353

    2024

  2. [2]

    Leah Bidlake, Eric Aubanel, and Daniel Voyer. 2025. Investigating the Progression of the Mental Models Formed by Programmers Learning Parallel Programming. ACM Transactions on Computing Education25, 1, Article 5 (2025)

    2025

  3. [3]

    Islem Bouzenia, Bajaj Piyush Krishan, and Michael Pradel. 2024. DyPyBench: A benchmark of executable python software.Proceedings of the ACM on Software Engineering1, FSE (2024), 338–358

    2024

  4. [4]

    Mark Chen. 2021. Evaluating large language models trained on code.arXiv preprint arXiv:2107.03374(2021)

    arXiv 2021

  5. [5]

    Wei Cheng, Yuhan Wu, and Wei Hu. 2024. Dataflow-guided retrieval augmen- tation for repository-level code completion. InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 7957–7977

    2024

  6. [6]

    Yangruibo Ding, Zijian Wang, Wasi Ahmad, Hantian Ding, Ming Tan, Nihal Jain, Murali Krishna Ramanathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, et al. 2023. Crosscodeeval: A diverse and multilingual benchmark for cross-file code completion.Advances in Neural Information Processing Systems36 (2023), 46701–46723

    2023

  7. [7]

    Gang Fan, Chengpeng Wang, Rongxin Wu, Xiao Xiao, Qingkai Shi, and Charles Zhang. 2020. Escaping dependency hell: finding build dependency errors with the unified dependency graph. InProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis. 463–474

    2020

  8. [8]

    Lishui Fan, Zhongxin Liu, Haoye Wang, Lingfeng Bao, Xin Xia, and Shanping Li

Show all 62 references
  1. [9]

    Lishui Fan, Yu Zhang, Mouxiang Chen, and Zhongxin Liu. 2026. ReCode: Rein- forcing Code Generation with Reasoning-Process Rewards. InProceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 43896–43914. ASE ’26, October 1...

    2026

  2. [10]

    Scott D Fleming, Chris Scaffidi, David Piorkowski, Margaret Burnett, Rachel Bellamy, Joseph Lawrance, and Irwin Kwan. 2013. An information foraging theory perspective on tools for debugging, refactoring, and reuse tasks.ACM Transactions on Software Engineering and Methodology2...

    2013

  3. [11]

    Google. 2026. google/pytype: A static type analyzer for Python code. https: //github.com/google/pytype. Accessed: 2026-01-30

    2026

  4. [12]

    Wenchao Gu, Juntao Chen, Yanlin Wang, Tianyue Jiang, Xingzhe Li, Mingwei Liu, Xilin Liu, Yuchi Ma, and Zibin Zheng. 2025. What to Retrieve for Effective Retrieval-Augmented Code Generation? An Empirical Study and Beyond.arXiv preprint arXiv:2503.20589(2025)

    2025 arXiv

  5. [13]

    Zhanming Guan, Junlin Liu, Jierui Liu, Chao Peng, Dexin Liu, Ningyuan Sun, Bo Jiang, Wenchao Li, Jie Liu, and Hang Zhu. 2024. ContextModule: Improving Code Completion via Repository-level Contextual Information.arXiv preprint arXiv:2412.08063(2024)

    2024 arXiv

  6. [14]

    Aaron Hurst, Adam Lerer, Adam P Goucher, Adam Perelman, Aditya Ramesh, Aidan Clark, AJ Ostrow, Akila Welihinda, Alan Hayes, Alec Radford, et al. 2024. Gpt-4o system card.arXiv preprint arXiv:2410.21276(2024)

    2024 arXiv

  7. [15]

    Naman Jain, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. 2025. Livecodebench: Holistic and contamination free evaluation of large language models for code. In International Conference on Learning Representations...

    2025

  8. [16]

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2026. A survey on large language models for code generation.ACM Transactions on Software Engineering and Methodology35, 2 (2026), 1–72

    2026

  9. [17]

    Tianyue Jiang, Yanli Wang, Yanlin Wang, Daya Guo, Ensheng Shi, Yuchi Ma, Jiachi Chen, and Zibin Zheng. 2025. AlignCoder: Aligning Retrieval with Target Intent for Repository-Level Code Completion. In2025 IEEE/ACM 40th International Conference on Automated Software Engineering. 971–982

    2025

  10. [18]

    Zhonghao Jiang, David Lo, and Zhongxin Liu. 2025. Agentic Software Issue Res- olution with Large Language Models: A Survey.arXiv preprint arXiv:2512.22256 (2025)

    2025

  11. [19]

    Zhonghao Jiang, Xiaoxue Ren, Meng Yan, Wei Jiang, Yong Li, and Zhongxin Liu

  12. [20]

    Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. Swe-bench: Can language models resolve real-world github issues?. InInternational Conference on Learning Representations, Vol. 2024. 54107–54157

    2024

  13. [21]

    In 2025 40th IEEE/ACM International Conference on Automated Software Engineering

    Issue Localization via LLM-Driven Iterative Code Graph Searching. In 2025 40th IEEE/ACM International Conference on Automated Software Engineering. 3034–3045

    2025

  14. [22]

    Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph Gonzalez, Hao Zhang, and Ion Stoica. 2023. Efficient memory management for large language model serving with pagedattention. In Proceedings of the 29th symposium on operating systems princip...

    2023

  15. [23]

    Mehdi Keshani, Georgios Gousios, and Sebastian Proksch. 2024. Frankenstein: fast and lightweight call graph generation for software builds.Empirical Software Engineering29, 1 (2024), 1

    2024

  16. [24]

    Joseph Lawrance, Christopher Bogart, Margaret Burnett, Rachel Bellamy, Kyle Rector, and Scott D Fleming. 2010. How programmers debug, revisited: An infor- mation foraging theory perspective.IEEE Transactions on Software Engineering 39, 2 (2010), 197–215

    2010

  17. [25]

    Thomas D LaToza and Brad A Myers. 2010. Developers ask reachability ques- tions. InProceedings of the 32Nd ACM/IEEE International Conference on Software Engineering-Volume 1. 185–194

    2010

  18. [26]

    Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, et al . 2024. Deveval: A manually- annotated code generation benchmark aligned with real-world code repositories. InFindings of the Association for Computational Lin...

    2024

  19. [27]

    Jia Li, Ge Li, Xuanming Zhang, Yunfei Zhao, Yihong Dong, Zhi Jin, Binhua Li, Fei Huang, and Yongbin Li. 2024. Evocodebench: An evolving code generation benchmark with domain-specific evaluations.Advances in Neural Information Processing Systems37 (2024), 57619–57641

    2024

  20. [28]

    Zongjie Li and Shuai Wang. 2025. Reasoning as a resource: Optimizing fast and slow thinking in code generation models. InProceedings of the 1st ACM SIGPLAN International Workshop on Language Models and Programming Languages. 1–5

    2025

  21. [29]

    Jia Li, Xianjie Shi, Kechi Zhang, Ge Li, Zhi Jin, Lei Li, Huangzhao Zhang, Jia Li, Fang Liu, Yuwei Zhang, Zhengwei Tao, Yihong Dong, Yuqi Zhu, and Chongyang Tao. 2025. GraphCodeAgent: Dual Graph-Guided LLM Agent for Retrieval- Augmented Repo-Level Code Generation.arXiv preprin...

    2025

  22. [30]

    Aixin Liu, Aoxue Mei, Bangcai Lin, Bing Xue, Bingxuan Wang, Bingzheng Xu, Bochao Wu, Bowei Zhang, Chaofan Lin, Chen Dong, et al . 2025. DeepSeek- V3.2: Pushing the Frontier of Open Large Language Models.arXiv preprint arXiv:2512.02556(2025)

    2025 arXiv

  23. [31]

    Dianshu Liao, Shidong Pan, Xiaoyu Sun, Xiaoxue Ren, Qing Huang, Zhenchang Xing, Huan Jin, and Qinying Li. 2024. A 3-codgen: A repository-level code gener- ation framework for code reuse with local-aware, global-aware, and third-party- library-aware.IEEE Transactions on Softwar...

    2024

  24. [32]

    Wei Liu, Ailun Yu, Daoguang Zan, Bo Shen, Wei Zhang, Haiyan Zhao, Zhi Jin, and Qianxiang Wang. 2024. Graphcoder: Enhancing repository-level code completion via coarse-to-fine retrieval based on code context graph. InProceedings of the 39th IEEE/ACM International Conference on ...

    2024

  25. [33]

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2023. Is your code generated by chatgpt really correct? rigorous evaluation of large language models for code generation.Advances in Neural Information Processing Systems 36 (2023), 21558–21572

    2023

  26. [34]

    Shuai Lu, Nan Duan, Hojae Han, Daya Guo, Seung-won Hwang, and Alexey Svy- atkovskiy. 2022. ReACC: A Retrieval-Augmented Code Completion Framework. InProceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 6227–6240

    2022

  27. [35]

    Yang Liu, Li Zhang, Fang Liu, Zhuohang Wang, Donglin Wei, Zhishuo Yang, Kechi Zhang, Jia Li, and Lin Shi. 2025. Reposcope: Leveraging call chain-aware multi- view context for repository-level code generation.arXiv preprint arXiv:2507.14791 (2025)

    2025

  28. [36]

    Will McGugan, Martin Larralde, Giampaolo Cimino, Geoff Jukes, and contributors

  29. [37]

    Yingwei Ma, Qingping Yang, Rongyu Cao, Binhua Li, Fei Huang, and Yongbin Li. 2025. Alibaba lingmaagent: Improving automated issue resolution via com- prehensive repository exploration. InProceedings of the 33rd ACM International Conference on the Foundations of Software Engine...

    2025

  30. [38]

    Ruwei Pan and Hongyu Zhang. 2025. Modularization is Better: Effective Code Generation with Modular Prompting.arXiv preprint arXiv:2503.12483(2025)

    2025 arXiv

  31. [39]

    Thomas Reps, Susan Horwitz, and Mooly Sagiv. 1995. Precise interprocedural dataflow analysis via graph reachability. InProceedings of the 22nd ACM SIGPLAN- SIGACT symposium on Principles of programming languages. 49–61

    1995

  32. [40]

    Melissa Z Pan, Negar Arabzadeh, Riccardo Cogo, Yuxuan Zhu, Alexander Xiong, Lakshya A Agrawal, Huanzhi Mao, Emma Shen, Sid Pallerla, Liana Patel, et al

  33. [41]

    Measuring agents in production.arXiv preprint arXiv:2512.04123(2025)

    2025 arXiv

  34. [42]

    Vitalis Salis, Thodoris Sotiropoulos, Panos Louridas, Diomidis Spinellis, and Dimitris Mitropoulos. 2021. Pycg: Practical call graph generation in python. In 2021 IEEE/ACM 43rd International Conference on Software Engineering. 1646–1657

    2021

  35. [43]

    Jordan Samhi, Marc Miltenberger, Marco Alecci, Steven Arzt, Tegawendé Bis- syandé, and Jacques Klein. 2025. Do you have 5 min? Improving Call Graph Analysis with Runtime Information. InProceedings of the 33rd ACM International Conference on the Foundations of Software Engineer...

    2025

  36. [44]

    Stephen Robertson, Hugo Zaragoza, et al . 2009. The probabilistic relevance framework: BM25 and beyond.Foundations and Trends®in Information Retrieval 3, 4 (2009), 333–389

    2009

  37. [45]

    Barbara G Ryder and Frank Tip. 2001. Change impact analysis for object-oriented programs. InProceedings of the 2001 ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering. 46–53

    2001

  38. [46]

    Yicheng Tao, Yao Qin, and Yepang Liu. 2025. Retrieval-Augmented Code Gen- eration: A Survey with Focus on Repository-Level Approaches.arXiv preprint arXiv:2510.04905(2025)

    2025 arXiv

  39. [47]

    Tree-sitter Contributors. 2026. py-tree-sitter Documentation. https://tree-sitter. github.io/py-tree-sitter/. Accessed: 2026-01-30

    2026

  40. [48]

    Weifeng Sun, Naiqi Huang, Meng Yan, Li Huang, Zhongxin Liu, Xiao Liu, and David Lo. 2026. Cost-Effective Adversarial Attacks Against Code LLM with Model Attention.IEEE Transactions on Software Engineering(2026)

    2026

  41. [49]

    Weifeng Sun, Naiqi Huang, Meng Yan, Zhongxin Liu, Hongyan Li, Yan Lei, and David Lo. 2026. On-the-Fly Generation-Quality Enhancement of Deep Code Models via Model Collaboration.ACM Transactions on Software Engineering and Methodology35, 6 (2026), 1–40

    2026

  42. [50]

    Yanlin Wang, Yanli Wang, Daya Guo, Jiachi Chen, Ruikai Zhang, Yuchi Ma, and Zibin Zheng. 2025. RLCoder: Reinforcement Learning for Repository-Level Code Completion. In2025 IEEE/ACM 47th International Conference on Software Engineering. 1140–1152

    2025

  43. [51]

    An Yang, Anfeng Li, Baosong Yang, Beichen Zhang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Gao, Chengen Huang, Chenxu Lv, et al. 2025. Qwen3 technical report.arXiv preprint arXiv:2505.09388(2025)

    2025 arXiv

  44. [52]

    Ashwin Prasad Shivarpatna Venkatesh, Rose Sunil, Samkutty Sabu, Amir M Mir, Sofia Reis, and Eric Bodden. 2025. An empirical study of large language models for type and call graph analysis in Python and JavaScript.Empirical Software Engineering30, 6 (2025), 167

    2025

  45. [53]

    Jianxun Wang and Yixiang Chen. 2023. A review on code generation with llms: Application and evaluation. In2023 IEEE International Conference on Medical Artificial Intelligence. 284–289

    2023

  46. [54]

    Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. 2023. Repocoder: Repository-level code Effective and Efficient Context Retrieval via Partial Dependency Graph for Repository-Level Code Generation ASE ’26, October 1...

    2023

  47. [55]

    Kechi Zhang, Jia Li, Ge Li, Xianjie Shi, and Zhi Jin. 2024. CodeAgent: Enhancing Code Generation with Tool-Integrated Agent Systems for Real-World Repo-level Coding Challenges. InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1:...

    2024

  48. [56]

    Zezhou Yang, Sirong Chen, Cuiyun Gao, Zhenhao Li, Xing Hu, Kui Liu, and Xin Xia. 2025. An empirical study of retrieval-augmented code generation: Challenges and opportunities.ACM Transactions on Software Engineering and Methodology (2025)

    2025

  49. [57]

    Hao Yu, Bo Shen, Dezhi Ran, Jiaxin Zhang, Qi Zhang, Yuchi Ma, Guangtai Liang, Ying Li, Qianxiang Wang, and Tao Xie. 2024. Codereval: A benchmark of prag- matic code generation with generative pre-trained models. InProceedings of the 46th IEEE/ACM International Conference on So...

    2024

  50. [60]

    Yanzhao Zhang, Mingxin Li, Dingkun Long, Xin Zhang, Huan Lin, Baosong Yang, Pengjun Xie, An Yang, Dayiheng Liu, Junyang Lin, et al. 2025. Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models.arXiv preprint arXiv:2506.05176(2025)

    2025 arXiv

  51. [61]

    Terry Yue Zhuo, Minh Chien Vu, Jenny Chim, Han Hu, Wenhao Yu, Ratnadira Widyasari, Imam Nur Bani Yusuf, Haolan Zhan, Junda He, Indraneil Paul, et al

  52. [62]

    InInternational Conference on Learning Representations, Vol

    Bigcodebench: Benchmarking code generation with diverse function calls and complex instructions. InInternational Conference on Learning Representations, Vol. 2025. 66602–66656. Received 2026-03-26; accepted 2026-06-18

    2025

  53. [2025]

    In2025 40th IEEE/ACM International Conference on Automated Software Engineering

    FGit: Fault-Guided Fine-Tuning for Code Generation. In2025 40th IEEE/ACM International Conference on Automated Software Engineering. 1338–1350

  54. [2026]

    https://github.com/ PyFilesystem/pyfilesystem2

    PyFilesystem2: Python’s Filesystem Abstraction Layer. https://github.com/ PyFilesystem/pyfilesystem2. Accessed: 2025-12-06

    2025

Pith tools

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