Pith. sign in

REVIEW 4 major objections 7 minor 46 references

Enhancing Project-Specific Code Completion by Inferring Internal API Information

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

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

Pith's one-line read The paper claims that project-specific code completion improves substantially when a code-draft-driven retrieval step infers internal API usage without relying on import statements, and shows consistent gains across two benchmarks and…

desk verdict Solid RAG-for-code-completion paper with a useful benchmark and credible gains; the retrieval mechanism is plausible but its central claim—that UER/FSR actually recover the right API—is never directly measured. read the letter →

arxiv 2507.20888 v1 pith:B7PEJ5TO submitted 2025-07-28 cs.SE cs.CL

Le Deng , Xiaoxue Ren , Chao Ni , Ming Liang , David Lo , Zhongxin Liu This is my paper
classification cs.SEcs.CL
keywords project-specificcodecompletioninternalAPIinferenceretrieval-augmentedgenerationLLMusageexampleretrievalfunctionalsemanticbenchmarkexactmatchevaluation
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

Project-specific code completion with large language models routinely fails when the code to be written depends on an internal API that has not appeared in the file and is not importable from context. This paper proposes to close that gap by making the model's own first attempt at the completion, the code draft, do double duty: the draft's API call line is used to retrieve APIs with similar usage shapes, and a summary of the draft's remaining logic is used to retrieve APIs with similar function. Each internal API in the repository is enriched beforehand with heuristic usage examples and an LLM-generated docstring, so retrieval happens over those two representations rather than over raw code. On the new ProjBench and on CrossCodeEval, the resulting approach beats the best baseline by +5.91 code exact match and +6.26 identifier exact match, and the two retrieval components can be added to existing methods to lift their code match by 47.80% on average. The practical upshot is that an IDE autocompleter could suggest correct internal APIs before they are ever imported in the current file.

What carries the argument

The load-bearing mechanism is the dual-representation API knowledge base plus draft-guided retrieval. Each internal function is rewritten into a handful of plausible call forms (unqualified, qualified, with and without arguments, constructor/static/instance variants) and summarized into a natural-language docstring; both forms are encoded as vectors. During completion, a first LLM pass produces a code draft; the draft's target line becomes the query for usage-example retrieval and a summarization of the draft's tail becomes the query for functional-semantic retrieval, with cosine similarity selecting the top-k APIs. The final prompt combines the retrieved API definitions with similar code snippets, and the LLM regenerates the completion. The two retrieval channels are complementary, addressing respectively the wrong-function-name failure and the reinvents-an-existing-function failure.

What would settle it

Construct a test set of completion tasks where the code draft is deliberately scrubbed of every token that overlaps with the target API's name, and where the target API's docstring is a paraphrase sharing no vocabulary with the draft summary. If, over a few hundred such tasks, the top-8 retrieved APIs from UER/FSR rarely contain the ground-truth API while import-based retrieval succeeds, the mechanism's central claim would be falsified.

Watch

Extended reading notes

Core claim

The central claim is that internal API information is the missing ingredient in repository-level code completion, and that it can be inferred rather than looked up through imports. The paper argues that a generated code draft—even when wrong—carries enough signal: the line the model wants to write often contains a function name close to the intended internal API, and the rest of the draft often describes a function that already exists in the repository. The method therefore builds an API knowledge base in which every internal function is represented by its signature, class, body, file path, constructed usage examples, and a generated docstring, then uses usage-example retrieval and functional-semantic retrieval to pull the relevant APIs into the final prompt. Results on ProjBench and CrossCodeEval with DeepSeekCoder-6.7B, CodeLlama-7B, and StarCoder2-7B support the claim, with the stated improvements of +5.91 code EM and +6.26 identifier EM over the strongest baseline.

Load-bearing premise

The load-bearing premise is that the code draft, even when inaccurate, contains enough signal—a similar function name or a semantically related description—that embedding similarity over usage examples and generated docstrings retrieves the correct internal API.

Editorial extensions

If this is right

  • The approach works without import statements, so it applies to the first use of an internal API in a file, where import-based retrievers fail.
  • Adding the two retrieval components to InFile, RepoFuse, and RepoCoder raises their code exact match by 47.80% and identifier exact match by 35.55% on average, so the mechanism is a drop-in supplement rather than a competing pipeline.
  • The gains appear across Python and Java and across three open code LLMs, and a small study with a newer commercial model (19/50 vs 13/50 for the strongest baseline) suggests the benefit is not an artifact of older model weaknesses.
  • Because the API knowledge base is built offline and only incrementally updated, the extra per-task inference cost over RepoCoder is modest (about 0.33 seconds).

Reading between the lines

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

  • A fair stress test would hold out samples where the code draft shares no token with the target API name; the paper's mechanism predicts UER should sometimes still win through usage-shape similarity, while a purely lexical retriever would fail.
  • The heuristic usage-example templates could be replaced by mined call sites from version history or test files, adding argument-name and call-pattern coverage that the templates currently approximate.
  • The same dual representation could be reused for other repository-level tasks such as bug localization or code review, wherever a noisy draft or description needs to be matched to an internal function.
  • The benchmark construction could be extended to other languages by porting the heuristic usage-example rules, since the Java results already show the mechanism transfers beyond Python.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 7 minor

Summary. This paper proposes an import-free approach to project-specific code completion. It builds an API knowledge base in which each internal function is augmented with heuristic usage examples and LLM-generated docstrings; given unfinished code, it first generates a draft using similar-code context, then retrieves internal APIs by matching the draft line against usage examples (UER) and matching a docstring of the draft continuation against API docstrings (FSR), and finally regenerates with similar snippets and retrieved API signatures. The authors introduce ProjBench, a Python/Java benchmark built from post-2024 GitHub repositories with import masking for first-use cross-file lines, and evaluate on ProjBench and CrossCodeEval with DeepSeekCoder-6.7B, CodeLlama-7B, and StarCoder2-7B. They report average exact-match gains of +5.91 for code and +6.26 for identifiers over the best baseline, and further gains of +7.77/+8.50 when integrating their API inference method into existing baselines.

Significance. The contribution is potentially significant: if the UER/FSR mechanism actually retrieves the needed internal APIs, the method offers a practical, training-free complement to similarity- and import-based retrieval-augmented generation for code completion, and ProjBench directly targets the realistic problem of missing imports. Strengths include evaluation across two benchmarks, three open models, and two languages; the disclosed replication package; the component ablation; the manual semantic-equivalence check; and the recent-LLM evaluation on post-cutoff projects, which is a sensible contamination-control idea. The comparison setting is also conservative in one respect, since RepoFuse is allowed to keep import statements while the proposed method is not. The main weakness is that retrieval correctness is never directly measured, so the causal explanation of the reported gains is not yet established.

major comments (4)
  1. [§3.2.2 and §5.2, Table 4] The central claim that UER and FSR improve completion by retrieving the correct internal API is never directly tested. The paper reports no recall@k of the ground-truth API, no oracle upper bound in which the correct API definition is injected, and no analysis of how often a retrieved API is actually the one used in the ground truth; the only qualitative evidence is the two hand-picked cases in Figure 9. Since the target prompt (Figure 7) supplies retrieved signatures as context, a plausible-but-incorrect signature can still shift the second-pass generation, and the Table 4 gains are therefore consistent with an 'any API-shaped context helps' explanation. I ask for a retrieval-correctness analysis on ProjBench (where ground truth is available), an oracle upper bound, and a random-API or extra-context control.
  2. [§5.3, Table 5] Every +AIM result in Table 5 includes a regeneration step, but there is no control that regenerates from the baseline output without the retrieved API information or with non-informative/random snippets. Without such a control, the reported +7.77/+8.50 gains cannot be attributed to AIM's retrieval rather than to a second LLM pass over the same draft. Please add a 'baseline + regenerate' condition and a 'baseline + random API context' condition.
  3. [§4.1.1 and §7 (Threats to Validity)] The claim that ProjBench avoids data leakage because repositories were created after January 1, 2024 is not sufficient: GitHub creation date does not guarantee that the code is absent from pretraining corpora, nor that it is not derived from earlier code, and the manual fork check covers only known cases. Please add contamination checks (e.g., n-gram overlap with training data, inspection of git history), or at least report commit dates and original development history, and state clearly how many benchmark samples have masked imports versus how many have imports visible.
  4. [§5.1, Table 3] All comparisons are reported as single point estimates without confidence intervals, significance tests, or information about run-to-run variability. Differences as small as 2.75 EM points (StarCoder2-7B on ProjBench Java) may be within noise; please report the number of runs, decoding settings, and appropriate intervals or tests.
minor comments (7)
  1. [§4.1.2] Please report how many of the 200 sampled lines per repository are first-use cross-file lines and therefore have imports masked; as written, the extent to which ProjBench actually tests import-free completion is unclear.
  2. [§4.3] Please specify the decoding parameters (temperature, sampling, beam size) and whether each reported number is a single greedy run or an average over multiple seeds.
  3. [§5.1, Table 3] The table header says 'StarCoder-7B' while the text and Section 4.3 use 'StarCoder2-7B'; please make the naming consistent.
  4. [§5.1, Figure 9] 'load_cituscapes_sem_seg' appears to be a typo for 'load_cityscapes_semantic' in the left example; please correct the text and figure.
  5. [§6.4] The 50-sample Claude 3.7 Sonnet evaluation would benefit from reporting the project names, the retrieval-correctness rate on those samples, and a significance test; the current claim of 'significantly outperforming' is not backed by a test.
  6. [§8.2] The sentence 'RLPG [14] and Repoformer [16] train classifiers' appears to cite the wrong reference: [16] is RepoFusion, while RepoFormer is [33].
  7. [§6.1, Table 6] The statement that the method adds 'one additional model call during retrieval compared to RepoCoder' should clarify that the code-draft generation itself is an additional model call outside RepoCoder's own pipeline.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the UER/FSR pipeline is empirical retrieval-generation, and the only self-citation (RepoFuse baseline) is non-load-bearing.

full rationale

The paper's derivation chain is a pipeline rather than a mathematical derivation with fitted parameters. The target completion is produced by an LLM from a prompt containing similar-code snippets, retrieved internal-API definitions, and the unfinished code; the retrieval queries are constructed from a code draft generated without access to the ground-truth line. No parameter is fitted to the benchmark labels ('For project dependency retrieval, we set k to 4' is a fixed hyperparameter rather than a fitted value), and no equation defines the predicted code in terms of the retrieved API. The API knowledge base is constructed from the repository alone via static analysis, heuristic usage-example generation, and LLM docstring summarization, none of which uses the target completion. The only self-citation is RepoFuse [17], which shares co-author Ming Liang; however, RepoFuse is used as a measured baseline with its official implementation on ProjBench and CrossCodeEval, not as evidence for the UER/FSR mechanism, so it is not load-bearing. The paper's limitations—no recall@k measurement for retrieval correctness, no oracle or random-API control, and possible alternative explanations through second-pass regeneration—concern experimental attribution and evidence quality, not definitional circularity. These gaps could weaken confidence in the causal story, but they do not make the reported predictions equivalent to their inputs by construction.

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

The central claim rests on several domain assumptions: the embedding model preserves code semantics, the summarization model produces accurate docstrings, the hand-crafted usage examples reflect real calls, and the benchmark's date-based leakage filter works. The method's hyperparameters (top-k, window size, prompt split) are fixed by convention rather than derived.

free parameters (4)
  • top-k API retrieval (k) = 4
    Retrieves 8 APIs total (2 retrieval types x 4); chosen by hand, not varied.
  • sliding window size / stride = 20 / 10
    Follows RepoCoder's window length 20 and sliding size 10.
  • prompt length split = 1:1 retrieved:in-file
    Half of prompt for retrieved snippets, half for in-file code, per RepoCoder.
  • max generation length = 128 tokens
    Implementation constant for all code generation.
assumptions (5)
  • domain assumption UniXcoder embeddings represent code and docstring semantics well enough for cosine-similarity retrieval.
    Used in Section 3.1.2 to encode UEs and docstrings; retrieval quality depends on this.
  • domain assumption Llama3-Instruct-8b generates accurate and consistent docstrings for internal functions.
    Section 3.1.2; FSR matching relies on these summaries.
  • domain assumption The heuristic usage-example rules in Table 1 approximate real API usage.
    Section 3.1.2; UER searches over these constructed examples.
  • domain assumption GitHub repositories created after January 1, 2024 are unlikely to be in the training data of DeepSeekCoder-6.7B, CodeLlama-7B, and StarCoder2-7B.
    Section 4.1.1; the leakage-avoidance claim of ProjBench depends on this.
  • domain assumption Masking import statements for first-use samples mimics real development scenarios.
    Section 4.1.2; benchmark design choice.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Enhancing Project-Specific Code Completion by Inferring Internal API Information." pith.science (2026). https://pith.science/paper/B7PEJ5TO

@misc{pith2026250720888,
  author       = {Pith},
  title        = {Pith review of: Enhancing Project-Specific Code Completion by Inferring Internal API Information},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/B7PEJ5TO}},
  note         = {Machine review of arXiv:2507.20888}
}
read the original abstract

Project-specific code completion is a critical task that leverages context from a project to generate accurate code. State-of-the-art methods use retrieval-augmented generation (RAG) with large language models (LLMs) and project information for code completion. However, they often struggle to incorporate internal API information, which is crucial for accuracy, especially when APIs are not explicitly imported in the file. To address this, we propose a method to infer internal API information without relying on imports. Our method extends the representation of APIs by constructing usage examples and semantic descriptions, building a knowledge base for LLMs to generate relevant completions. We also introduce ProjBench, a benchmark that avoids leaked imports and consists of large-scale real-world projects. Experiments on ProjBench and CrossCodeEval show that our approach significantly outperforms existing methods, improving code exact match by 22.72% and identifier exact match by 18.31%. Additionally, integrating our method with existing baselines boosts code match by 47.80% and identifier match by 35.55%.

Figures

Figures reproduced from arXiv: 2507.20888 by the authors.

Figure 1
Figure 1. An example from FramePack. The red box marked [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. A example from corenet In this section, we will detail our approach designed to fully harness the potential knowledge within the project to assist LLMs in code completion through two phases (i.e., API knowledge base construction and project-specific code completion). In the first phase, we extract the project’s APIs and uncover their potential knowledge (i.e., usage examples and functional semantic information) to c… view at source ↗
Figure 4
Figure 4. The overall framework of our approach. 3.1.1 API Information Extraction To collect dispersed information within the project, we extract all APIs within the project through static analysis. Specifically, given a code repository, we traverse all the code files within the repository. For each code file, we use tree￾sitter [26] to parse it into an Abstract Syntax Tree (AST) and then identify and extract each function. F… view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: Real API information construction example [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Our summary template, where examples are sourced [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: A visual example of our approach prompt format [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Venn diagrams of EM results for Python (left) and [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Two test samples, the left from MagicClothing and the right from corenet [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]
Figure 10
Figure 10. Figure 10: An example in manual evaluation. to be extended to more complex scenarios such as multi-line code completion. For example, in the multi-line setting, the knowledge base constructed by our approach remains fully applicable, as it takes the entire codebase as input to c…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

46 extracted references · 19 canonical work pages

  1. [1]

    Codegen: An open large language model for code with multi-turn program synthesis,

    E. Nijkamp, B. Pang, H. Hayashi, L. Tu, H. Wang, Y. Zhou, S. Savarese, and C. Xiong, “Codegen: An open large language model for code with multi-turn program synthesis,” arXiv preprint arXiv:2203.13474, 2022

    arXiv 2022

  2. [2]

    Starcoder: may the source be with you!

    R. Li, L. B. Allal, Y. Zi, N. Muennighoff, D. Kocetkov, C. Mou, M. Marone, C. Akiki, J. Li, J. Chimet al., “Starcoder: may the source be with you!” arXiv preprint arXiv:2305.06161, 2023

    arXiv 2023

  3. [3]

    Starcoder 2 and the stack v2: The next generation,

    A. Lozhkov, R. Li, L. B. Allal, F. Cassano, J. Lamy-Poirier, N. Tazi, A. Tang, D. Pykhtar, J. Liu, Y. Weiet al., “Starcoder 2 and the stack v2: The next generation,” arXiv preprint arXiv:2402.19173, 2024

    arXiv 2024

  4. [4]

    Deepseek-coder: When the large language model meets programming–the rise of code intelligence,

    D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y. Wu, Y. Liet al., “Deepseek-coder: When the large language model meets programming–the rise of code intelligence,” arXiv preprint arXiv:2401.14196, 2024

    arXiv 2024

  5. [5]

    Codegeex: A pre-trained model for code generation with multilingual evaluations on humaneval-x,

    Q. Zheng, X. Xia, X. Zou, Y. Dong, S. Wang, Y. Xue, Z. Wang, L. Shen, A. Wang, Y. Li et al., “Codegeex: A pre-trained model for code generation with multilingual evaluations on humaneval-x,” arXiv preprint arXiv:2303.17568, 2023

    arXiv 2023

  6. [6]

    Wizardcoder: Empowering code large lan- guage models with evol-instruct,

    Z. Luo, C. Xu, P . Zhao, Q. Sun, X. Geng, W. Hu, C. Tao, J. Ma, Q. Lin, and D. Jiang, “Wizardcoder: Empowering code large lan- guage models with evol-instruct,” arXiv preprint arXiv:2306.08568, 2023

    arXiv 2023

  7. [7]

    Code llama: Open foundation models for code,

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, T. Remez, J. Rapin et al. , “Code llama: Open foundation models for code,” arXiv preprint arXiv:2308.12950, 2023

    arXiv 2023

  8. [8]

    Github copilot,

    “Github copilot,” https://github.com/features/copilot, 2022

    work page 2022

Show all 46 references
  1. [9]

    Amazon codewhisperer,

    “Amazon codewhisperer,” https://aws.amazon.com/ codewhisperer, 2023

    2023

  2. [10]

    Learning to mine aligned code and natural language pairs from stack over- flow,

    P . Yin, B. Deng, E. Chen, B. Vasilescu, and G. Neubig, “Learning to mine aligned code and natural language pairs from stack over- flow,” in Proceedings of the 15th international conference on mining software repositories, 2018, pp. 476–486

    2018

  3. [11]

    Eval- uating large language models trained on code,

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P . d. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman et al. , “Eval- uating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021

    2021 arXiv

  4. [12]

    Repocoder: Repository-level code com- pletion through iterative retrieval and generation,

    F. Zhang, B. Chen, Y. Zhang, J. Keung, J. Liu, D. Zan, Y. Mao, J.-G. Lou, and W. Chen, “Repocoder: Repository-level code com- pletion through iterative retrieval and generation,” arXiv preprint arXiv:2303.12570, 2023

    2023 arXiv

  5. [13]

    Cocomic: Code completion by jointly modeling in-file and cross-file context,

    Y. Ding, Z. Wang, W. U. Ahmad, M. K. Ramanathan, R. Nallapati, P . Bhatia, D. Roth, and B. Xiang, “Cocomic: Code completion by jointly modeling in-file and cross-file context,” arXiv preprint arXiv:2212.10007, 2022

    2022 arXiv

  6. [14]

    Repository-level prompt generation for large language models of code,

    D. Shrivastava, H. Larochelle, and D. Tarlow, “Repository-level prompt generation for large language models of code,” in Inter- national Conference on Machine Learning . PMLR, 2023, pp. 31 693– 31 715

    2023

  7. [15]

    Reacc: A retrieval-augmented code completion frame- work,

    S. Lu, N. Duan, H. Han, D. Guo, S.-w. Hwang, and A. Svy- atkovskiy, “Reacc: A retrieval-augmented code completion frame- work,” arXiv preprint arXiv:2203.07722, 2022

    2022 arXiv

  8. [16]

    Repofusion: Training code models to understand your repository,

    D. Shrivastava, D. Kocetkov, H. de Vries, D. Bahdanau, and T. Scholak, “Repofusion: Training code models to understand your repository,” arXiv preprint arXiv:2306.10998, 2023

    2023 arXiv

  9. [17]

    Repofuse: Repository-level code completion with fused dual context,

    M. Liang, X. Xie, G. Zhang, X. Zheng, P . Di, H. Chen, C. Wang, G. Fan et al. , “Repofuse: Repository-level code completion with fused dual context,” arXiv preprint arXiv:2402.14323, 2024

    2024 arXiv

  10. [18]

    Repohyper: Better context retrieval is all you need for repository-level code completion,

    H. N. Phan, H. N. Phan, T. N. Nguyen, and N. D. Bui, “Repohyper: Better context retrieval is all you need for repository-level code completion,” arXiv preprint arXiv:2403.06095, 2024

    2024 arXiv

  11. [19]

    Retrieval- augmented generation for knowledge-intensive nlp tasks,

    P . Lewis, E. Perez, A. Piktus, F. Petroni, V . Karpukhin, N. Goyal, H. K ¨uttler, M. Lewis, W.-t. Yih, T. Rockt ¨aschel et al. , “Retrieval- augmented generation for knowledge-intensive nlp tasks,” Ad- vances in Neural Information Processing Systems , vol. 33, pp. 9459– 9474, 2020

    2020

  12. [20]

    Full line code completion: Bringing ai to desktop,

    A. Semenkin, V . Bibaev, Y. Sokolov, K. Krylov, A. Kalina, A. Khan- nanova, D. Savenkov, D. Rovdo, I. Davidenko, K. Karnaukhov et al. , “Full line code completion: Bringing ai to desktop,” arXiv preprint arXiv:2405.08704, 2024

    2024 arXiv

  13. [21]

    Repobench: Benchmarking repository-level code auto-completion systems,

    T. Liu, C. Xu, and J. McAuley, “Repobench: Benchmarking repository-level code auto-completion systems,” arXiv preprint arXiv:2306.03091, 2023

    2023 arXiv

  14. [22]

    Crosscodeeval: A diverse and multilingual benchmark for cross-file code comple- tion,

    Y. Ding, Z. Wang, W. Ahmad, H. Ding, M. Tan, N. Jain, M. K. Ramanathan, R. Nallapati, P . Bhatia, D. Rothet al., “Crosscodeeval: A diverse and multilingual benchmark for cross-file code comple- tion,” Advances in Neural Information Processing Systems , vol. 36, 2024

    2024

  15. [23]

    Codereval: A benchmark of pragmatic code generation with generative pre-trained models,

    H. Yu, B. Shen, D. Ran, J. Zhang, Q. Zhang, Y. Ma, G. Liang, Y. Li, Q. Wang, and T. Xie, “Codereval: A benchmark of pragmatic code generation with generative pre-trained models,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, 2024, pp. 1–12

    2024

  16. [24]

    Deveval: Evaluating code generation in practical software projects,

    J. Li, G. Li, Y. Zhao, Y. Li, Z. Jin, H. Zhu, H. Liu, K. Liu, L. Wang, Z. Fang et al. , “Deveval: Evaluating code generation in practical software projects,” arXiv preprint arXiv:2401.06401, 2024

    2024 arXiv

  17. [25]

    Learning to break the loop: Analyzing and mitigating repetitions for neural text generation,

    J. Xu, X. Liu, J. Yan, D. Cai, H. Li, and J. Li, “Learning to break the loop: Analyzing and mitigating repetitions for neural text generation,” Advances in Neural Information Processing Systems, vol. 35, pp. 3082–3095, 2022

    2022

  18. [26]

    Treesitter: An incremental parsing system for programming tools,

    “Treesitter: An incremental parsing system for programming tools,” https://github.com/tree-sitter/tree-sitter, 2024

    2024

  19. [27]

    Pep 8 – style guide for python code,

    A. C. Guido van Rossum, Barry Warsaw, “Pep 8 – style guide for python code,” 2013. [Online]. Available: https: //peps.python.org/pep-0008/#naming-conventions

    2013

  20. [28]

    The appendix of the paper,

    L. Deng, “The appendix of the paper,” 2025. [Online]. Available: https://github.com/baday19/project-specific code completion/blob/main/appendix.pdf

    2025

  21. [29]

    Unixcoder: Unified cross-modal pre-training for code representation,

    D. Guo, S. Lu, N. Duan, Y. Wang, M. Zhou, and J. Yin, “Unixcoder: Unified cross-modal pre-training for code representation,” arXiv preprint arXiv:2203.03850, 2022

    2022 arXiv

  22. [30]

    A survey on in-context learning,

    Q. Dong, L. Li, D. Dai, C. Zheng, Z. Wu, B. Chang, X. Sun, J. Xu, and Z. Sui, “A survey on in-context learning,” arXiv preprint arXiv:2301.00234, 2022

    2022 arXiv

  23. [31]

    In-context learning cre- ates task vectors,

    R. Hendel, M. Geva, and A. Globerson, “In-context learning cre- ates task vectors,” arXiv preprint arXiv:2310.15916, 2023

    2023 arXiv

  24. [32]

    Long-range modeling of source code files with ewash: Extended window access by syntax hierarchy,

    C. B. Clement, S. Lu, X. Liu, M. Tufano, D. Drain, N. Duan, N. Sundaresan, and A. Svyatkovskiy, “Long-range modeling of source code files with ewash: Extended window access by syntax hierarchy,” arXiv preprint arXiv:2109.08780, 2021

    2021 arXiv

  25. [33]

    Repoformer: Selective retrieval for repository-level code comple- tion,

    D. Wu, W. U. Ahmad, D. Zhang, M. K. Ramanathan, and X. Ma, “Repoformer: Selective retrieval for repository-level code comple- tion,” arXiv preprint arXiv:2403.10059, 2024

    2024 arXiv

  26. [34]

    The distribution of the flora in the alpine zone. 1,

    P . Jaccard, “The distribution of the flora in the alpine zone. 1,”New phytologist, vol. 11, no. 2, pp. 37–50, 1912

    1912

  27. [35]

    Term-weighting approaches in auto- matic text retrieval,

    G. Salton and C. Buckley, “Term-weighting approaches in auto- matic text retrieval,” Information processing & management , vol. 24, no. 5, pp. 513–523, 1988

    1988

  28. [36]

    Rlcoder: Reinforcement learning for repository-level code com- pletion,

    Y. Wang, Y. Wang, D. Guo, J. Chen, R. Zhang, Y. Ma, and Z. Zheng, “Rlcoder: Reinforcement learning for repository-level code com- pletion,” arXiv preprint arXiv:2407.19487, 2024

    2024 arXiv

  29. [37]

    The probabilistic relevance framework: Bm25 and beyond,

    S. Robertson, H. Zaragoza et al. , “The probabilistic relevance framework: Bm25 and beyond,” Foundations and Trends® in Infor- mation Retrieval, vol. 3, no. 4, pp. 333–389, 2009. JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021 17

    2009

  30. [38]

    Transformers: State-of-the-art natural language processing,

    T. Wolf, L. Debut, V . Sanh, J. Chaumond, C. Delangue, A. Moi, P . Cistac, T. Rault, R. Louf, M. Funtowicz et al. , “Transformers: State-of-the-art natural language processing,” in Proceedings of the 2020 conference on empirical methods in natural language processing: system d...

    2020

  31. [39]

    Efficient memory management for large language model serving with pagedattention,

    W. Kwon, Z. Li, S. Zhuang, Y. Sheng, L. Zheng, C. H. Yu, J. E. Gon- zalez, H. Zhang, and I. Stoica, “Efficient memory management for large language model serving with pagedattention,” in Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023

    2023

  32. [40]

    Binary codes capable of correcting dele- tions, insertions, and reversals,

    V . I. Levenshtein et al., “Binary codes capable of correcting dele- tions, insertions, and reversals,” in Soviet physics doklady , vol. 10, no. 8. Soviet Union, 1966, pp. 707–710

    1966

  33. [41]

    Practitioners’ expectations on code completion,

    C. Wang, J. Hu, C. Gao, Y. Jin, T. Xie, H. Huang, Z. Lei, and Y. Deng, “Practitioners’ expectations on code completion,” arXiv preprint arXiv:2301.03846, 2023

    2023 arXiv

  34. [42]

    Hits: High-coverage llm- based unit test generation via method slicing,

    Z. Wang, K. Liu, G. Li, and Z. Jin, “Hits: High-coverage llm- based unit test generation via method slicing,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 1258–1268

    2024

  35. [43]

    Claude 3.7 sonnet,

    Anthropic, “Claude 3.7 sonnet,” https://www.anthropic.com/ news/claude-3-7-sonnet, 2025

    2025

  36. [44]

    Guiding language models of code with global context using monitors,

    L. A. Agrawal, A. Kanade, N. Goyal, S. K. Lahiri, and S. K. Rajamani, “Guiding language models of code with global context using monitors,” arXiv preprint arXiv:2306.10763, 2023

    2023 arXiv

  37. [45]

    Teaching code llms to use autocompletion tools in repository- level code generation,

    C. Wang, J. Zhang, Y. Feng, T. Li, W. Sun, Y. Liu, and X. Peng, “Teaching code llms to use autocompletion tools in repository- level code generation,” arXiv preprint arXiv:2401.06391, 2024

    2024 arXiv

  38. [46]

    Iterative refinement of project-level code context for precise code generation with compiler feedback,

    Z. Bi, Y. Wan, Z. Wang, H. Zhang, B. Guan, F. Lu, Z. Zhang, Y. Sui, X. Shi, and H. Jin, “Iterative refinement of project-level code context for precise code generation with compiler feedback,” arXiv preprint arXiv:2403.16792, 2024

    2024 arXiv

Pith tools

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