Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

ContextModule: Improving Code Completion via Repository-level Contextual Information

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

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

Pith's one-line read ContextModule claims that adding repository-level context—user-behavior code, similar snippets, and symbol definitions—to the completion prompt substantially improves accuracy and acceptance, with combined production gains above 15%.

desk verdict A plausible, practically useful repository-context system whose offline evidence is weakened by a potentially self-confirming metric and unreleased data, but whose online acceptance numbers make it worth refereeing. read the letter →

arxiv 2412.08063 v1 pith:N6BVVLNN submitted 2024-12-11 cs.SE cs.AI

Zhanming Guan , Junlin Liu , Jierui Liu , Chao Peng , Dexin Liu , Ningyuan Sun , Bo Jiang , Wenchao Li
show 2 more authors
Jie Liu Hang Zhu
This is my paper · ORCID
classification cs.SEcs.AI
keywords codecompletionrepositorycontextuserbehaviorknowledgegraphsimilarretrievallargelanguagemodelslowlatencyproductiondeployment
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

This paper seeks to show that a code completion system can be improved substantially by retrieving repository-level context and injecting it into the prompt. It proposes three retrieval strategies: user behavior code, drawn from the developer's recent cross-file browsing and editing history; similar code snippets, found by token-based similarity search across the repository; and symbol definitions, served from a code knowledge graph built by static analysis. Offline experiments on Python, Go, and TypeScript show each strategy raises completion accuracy, and a production deployment reports relative acceptance-rate gains of 7.1%, 6.3%, and 4.9% from the three strategies applied sequentially, with an estimated combined gain above 15%. A sympathetic reader would care because these gains come without retraining the model and are paired with caching and incremental-parsing optimizations that keep retrieval within production latency budgets.

What carries the argument

The machinery is a retrieval-and-concatenation pipeline. User behavior code: the IDE records cursor clicks, file paths, and line numbers; the five most recently browsed files are split into sliding-window snippets, and the top snippets by click count are added to the prompt. Similar code: repository files are split into sliding-window snippets, tokenized with camel/snake-case splitting and stop-word removal, and ranked by Jaccard similarity to the code near the cursor; an index cache with a BFS file-ordering strategy keeps retrieval latency below 80 milliseconds. Symbol definitions: a code knowledge graph built by static analysis stores function signatures and struct definitions; incremental parsing detects function-call, struct-initialization, and function-body completion positions and retrieves the relevant symbol in under 50 milliseconds. The three retrieved blocks are concatenated in the order symbol, similar code, user behavior code, together with the current file's prefix and suffix, in fill-in-the-middle format.

What would settle it

Run a production A/B test that toggles exactly one of the three context strategies at a time while holding the model and prompt template fixed; if removing user behavior code, similar code, or symbol definitions does not lower user acceptance, the central claim fails. A complementary offline check is to recompute the metrics with a strict exact-match or edit-distance criterion that does not count 'retrieved context helped' as a correct answer and see whether the improvements persist.

Watch

Extended reading notes

Core claim

The paper's central claim is that repository-level context, captured in three forms, materially improves LLM-based code completion. The three forms are user behavior code (snippets from files the developer recently browsed or edited), similar code snippets (retrieved by text similarity from the rest of the repository), and CKG-based symbol definitions (function signatures and struct definitions from a code knowledge graph built by static analysis). On offline datasets for Python, Go, and TypeScript, each context type raises soft exact match and edit similarity; the largest single gain is in struct initialization, where soft exact match rises from 6.17 to 17.41 when symbol definitions are added. In production, the three strategies were rolled out sequentially and produced relative acceptance-rate gains of 7.1%, 6.3%, and 4.9%, with an estimated combined improvement above 15%. The paper argues these gains matter because they come from signals—developer intent and precise symbol knowledge—that the file being edited alone does not contain.

Load-bearing premise

The offline evaluation assumes that the soft exact match metric and the pre-filtered user-behavior dataset measure completion quality independently of whether the retrieved context was actually needed, so part of the reported gain could be baked into how correctness is counted.

Editorial extensions

If this is right

  • Adding user behavior code raises soft exact match by 1.65 to 2.55 percentage points and edit similarity by 1.8 to 2.4 points across Python, Go, and TypeScript.
  • Similar code retrieval with split tokens raises soft exact match from 49.77 to 56.55 in Python at a 4k token window, and to 59.1 at an 8k window with more snippets.
  • CKG-based symbol definitions lift struct initialization soft exact match from 6.17 to 17.41, indicating the context reduces hallucinated member names.
  • The production rollouts of user behavior code, similar code, and symbol definitions each produced a relative acceptance-rate improvement, with an estimated combined improvement above 15%.
  • Latency constraints are met: similar code retrieval stays below 80 milliseconds and CKG symbol retrieval below 50 milliseconds in production.

Reading between the lines

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

  • If the acceptance gains generalize, repository-level context is a cheap add-on to existing completion systems: no model retraining is required, only retrieval. A natural next step the paper does not test is replacing the fixed rule-based fusion order with a learned ranker over the same three context streams.
  • The user-behavior results imply that IDE telemetry—cursor position, file visits, and edit history—carries predictive signal for what a developer will type next. A testable extension is whether on-device, privacy-preserving summarization of that history retains most of the gain.
  • The large struct-initialization improvement points to a concrete failure mode: hallucinated object members when the type definition is absent. This suggests a focused benchmark: struct and object initialization completions with and without type definitions.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. ContextModule is an industry-oriented framework that augments LLM-based code completion with three repository-level context sources: user behavior code (recently browsed/edited snippets), similar code snippets retrieved by token-based similarity, and symbol definitions from a proprietary code knowledge graph (CKG). The paper describes retrieval strategies, latency optimizations (index caching, incremental parsing), offline evaluations on internal Go/Python/TypeScript datasets using a single base model (DeepSeek-Coder-6.7b-Base), and production acceptance-rate improvements of 7.1%, 6.3%, and 4.9% for the three strategies. The central claim is that repository-level context significantly improves completion accuracy and user acceptance.

Significance. If the results hold, ContextModule is a practical, deployable contribution to code completion in real IDEs, with useful engineering artifacts: a low-latency token-based retrieval pipeline, an incremental CKG for symbol definitions, and a production deployment with measured acceptance gains. The paper credibly addresses a real gap—most academic code-completion evaluations do not capture cross-file user behavior or industrial latency constraints. The strengths are the production evidence, the multi-language offline setup, and the explicit treatment of retrieval latency. However, the evaluative apparatus has load-bearing weaknesses, principally the vague and potentially circular definition of the primary metric 'soft exact match' and the construction of the user-behavior test set. These need to be resolved before the offline causal claims can be accepted.

major comments (4)
  1. [IV.A.3] The definition of 'soft exact match' is load-bearing for Tables II–IV but is not operationalizable as written: the paper says a result is correct 'as long as the retrieved context helps the model generate the correct answer.' This makes correctness conditional on the intervention being evaluated; if the scorer uses knowledge of whether retrieved context was present or was helpful, then the with-context condition is scored against a different standard than the no-context condition, and the reported gains partly reflect the scoring rule. Please give the exact algorithm (e.g., whether SEM checks that the prediction contains the gold label after stripping trailing tokens, and whether the check is symmetric across conditions), and report both exact match and edit similarity for all conditions.
  2. [IV.B.1] The user-behavior dataset is constructed by selecting instances where 'the generated code was correct' via rule-based filtering and manual annotation, but no annotation protocol or inter-annotator agreement is reported. If annotators had access to the retrieved user-behavior snippets, or if the correctness filter uses the same soft-exact-match criterion as the main metric, the no-context baseline is evaluated only on samples where context demonstrably helps, artificially inflating the gains in Table II. The ground truth also appears to be the final code at the completion point, which may be the model's own accepted suggestion; using it as supervision for the same model can reward reproducing model output. Please describe the annotation interface (whether context was visible), report inter-annotator agreement, and verify that the correctness filter is independent of the retrieval strategies.
  3. [V.D] The online acceptance-rate improvements (7.1%, 6.3%, 4.9%) are reported for strategies implemented sequentially, with no control group, no experiment period, no population definition, and no adjustment for time-varying factors; the authors themselves note the indicators 'could not fully represent the effectiveness.' The subsequent claim that the combined improvement 'could achieve a relative increase of more than 15%' is an unsupported estimate. Please report the online experimental design (e.g., randomized rollout with holdout users, or at least pre/post acceptance rates with confounder controls) and present an uncertainty/range if the 15% figure is retained.
  4. [Tables II–IV] Effect sizes are small (1.65–2.55 SEM points, 1.8–2.4 edit-similarity points) and no error bars, confidence intervals, or significance tests are provided, despite 1500 samples per language. With a single base model (DeepSeek-Coder-6.7b-Base) and internal, unreleased datasets, the external validity of the 'significant improvement' claim is not established. Please add variance estimates or significance tests across samples, and ideally across multiple base models or at least justify the single-model choice.
minor comments (6)
  1. [Table IV] The table header 'Function Declaration' is inconsistent with the text in §IV.B.3 and §V.C, which both refer to 'function definition'; please unify the terminology.
  2. [V.B.1] There is a typo in the sentence 'we sorte and filtered the results'; it should be 'sorted'.
  3. [IV.A.3] The acronym SEM is introduced without being explicitly attached to 'soft exact match' in the text; please define it at first use and use it consistently throughout.
  4. [Figure 1] The figure caption reads 'FrameWork of ContextModule'; the capitalization should be fixed to 'Framework'.
  5. [III.C.1] The LSP limitations are listed qualitatively but no measured latency or accuracy comparison is given; a small table comparing LSP vs. CKG retrieval times and hit rates would strengthen the motivation.
  6. [V.D] The statement 'We did not conduct offline experiments on context fusion' is a limitation; it should be acknowledged explicitly and, if possible, receive a short offline sanity check even on a subsample.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the paper is an empirical evaluation with independent online acceptance-rate evidence; the SEM wording is ambiguous but no reported step reduces to its own input by construction.

full rationale

The paper is an empirical evaluation rather than a derivation, so the fitted-parameter-prediction and self-citation-chain patterns do not apply. No parameter is fitted to the evaluation data, no load-bearing argument rests on a self-citation (CKG is described as an in-house proprietary tool, and every cited reference is external prior work), and no uniqueness theorem is imported. The only arguable concern is the soft exact match (SEM) metric in Section IV.A.3, whose wording 'considers a result correct as long as the retrieved context helps the model generate the correct answer' could be read as conditioning correctness on retrieval success. However, the metric as described forgives only trailing tokens, is applied symmetrically to with-context and without-context conditions, and there is no formal scorer equation in the paper that uses the presence or absence of retrieved context in judging a prediction. The reported with-context SEM values (24.15%, 24.15%, 21.75% in Table II) are far below 100%, showing the user-behavior test set was not filtered to SEM-correct outputs, so the observed gains are not forced by the scoring definition. The Section IV.B.1 filter retaining only instances where the final code was judged 'correct' is an evaluation-validity concern about baseline representativeness, but it is a selection-bias issue rather than a definitional reduction, and the paper does not specify any annotation rule that encodes the retrieved context's necessity. The online acceptance-rate improvements (7.1%, 6.3%, 4.9% in Section V.D) are independent of the offline metrics, and the paper explicitly concedes overlapping effects among sequentially deployed strategies, which undercuts rather than supports any claim that the gains are definitional. Overall, the claimed improvements are empirical comparisons with independent online evidence, not conclusions that reduce to their own inputs.

Assumptions & free parameters 5 free parameters · 5 assumptions · 1 invented entities

The central empirical claim rests on several hand-set engineering constants and domain heuristics. No number is fitted to the headline metrics, so the free parameters do not by themselves create circularity, but they do limit generalization claims. The most consequential assumptions are that token similarity captures functional similarity, cursor behavior captures intent, and the proprietary CKG provides accurate symbol definitions.

free parameters (5)
  • Recent-file window N = 5
    Default number of recently browsed files used for user-behavior retrieval; hand-set in Section III.A.2.
  • Top-K user-behavior snippets = 2 in experiments
    Snippets with highest cursor-click counts are selected; user-behavior experiments use the top 2 (Sections III.A.2, V.A).
  • Index cache queue limit = 3000
    Queue limit for cached file indexes in similar-code retrieval; hand-set default in Section III.B.3.b.
  • Snippet window size = 30 lines, or 60 at 8k
    Sliding-window size for code snippet construction; changed when max input length increases (Sections V.B.1, V.B.2).
  • Similarity thresholds = Jaccard 0.1, cosine 0.7
    Filtering thresholds for token-based and embedding-based retrieval; manually chosen in Section V.B.1.
assumptions (5)
  • domain assumption Token-level Jaccard similarity over split identifiers identifies functionally similar code.
    Assumed in similar-code retrieval; validated only indirectly through downstream completion gains (Section V.B.1).
  • domain assumption Cursor history and recent file browsing encode developer intent.
    Used to retrieve user-behavior code; no independent user study is provided, only selected completion traces (Section III.A).
  • ad hoc to paper CKG static analysis yields correct, current symbol definitions with low latency.
    CKG is a proprietary ByteDance tool; construction, error rates, and freshness guarantees are not disclosed (Section III.C.2).
  • domain assumption DeepSeek-Coder-6.7b-Base is a representative base model for measuring context gains.
    All offline experiments use one model; no cross-model check, so results may be model-specific (Section IV.A.1).
  • domain assumption Inserting retrieved context as comments does not interfere with generation.
    Prompting choice made to minimize interference; not separately ablated (Section IV.A.2).
invented entities (1)
  • CKG (code knowledge graph)
    purpose: Repository-wide static analysis to retrieve function and struct definitions for prompt augmentation.
    Central to the symbol-definition results, but proprietary and not described in sufficient detail for independent verification.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ContextModule: Improving Code Completion via Repository-level Contextual Information." pith.science (2026). https://pith.science/paper/N6BVVLNN

@misc{pith2026241208063,
  author       = {Pith},
  title        = {Pith review of: ContextModule: Improving Code Completion via Repository-level Contextual Information},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/N6BVVLNN}},
  note         = {Machine review of arXiv:2412.08063}
}
read the original abstract

Large Language Models (LLMs) have demonstrated impressive capabilities in code completion tasks, where they assist developers by predicting and generating new code in real-time. However, existing LLM-based code completion systems primarily rely on the immediate context of the file being edited, often missing valuable repository-level information, user behaviour and edit history that could improve suggestion accuracy. Additionally, challenges such as efficiently retrieving relevant code snippets from large repositories, incorporating user behavior, and balancing accuracy with low-latency requirements in production environments remain unresolved. In this paper, we propose ContextModule, a framework designed to enhance LLM-based code completion by retrieving and integrating three types of contextual information from the repository: user behavior-based code, similar code snippets, and critical symbol definitions. By capturing user interactions across files and leveraging repository-wide static analysis, ContextModule improves the relevance and precision of generated code. We implement performance optimizations, such as index caching, to ensure the system meets the latency constraints of real-world coding environments. Experimental results and industrial practise demonstrate that ContextModule significantly improves code completion accuracy and user acceptance rates.

Figures

Figures reproduced from arXiv: 2412.08063 by the authors.

Figure 1
Figure 1. FrameWork of ContextModule [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. User Behavior Code Retrieval Process on the number of cache updates per cycle, which practically cannot exceed 1/10 of the queue capacity limit. With this strategy, we achieve retrieval latency below 80ms in production environments. C. CKG-based Symbol Definition 1) Observation: Accurate symbol definitions, such as meth￾ods, classes, and structures, are essential for code completion. These definitions reduce LLM hal… view at source ↗
Figure 3
Figure 3. Cache Strategy for Similar Code Retrieval [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: CKG-based Symbol Retrieval Process 1) User Behavior Code: To construct this dataset, we relied on real user editing behavior from within our company. We collected user editing data during code completion and recorded the final code at the completion point, which can ei…
Figure 5
Figure 5. Figure 5: CKG Case 1 [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: CKG Case 2 [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: CKG Case 3 [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: User Behavior Case 1 [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: User Behavior Case 2 [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Similar Code Case Several empirical studies have highlighted the challenges and gaps in current code completion tools [20]. Proksch et al. [21] and Hellendoorn et al. [22] emphasized that many evaluations of code completion models are performed using synthetic benchma…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

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

    cs.SE 2026-08 conditional novelty 6.0 of 10

    An LLM-driven partial dependency graph retriever improves repository-level code generation Pass@1 by 25.63% and 59.73% over RAG baselines on CoderEval and DevEval, with a 7.4x speedup over static graph construction.

Reference graph

Works this paper leans on

35 extracted references · 14 canonical work pages · cited by 1 Pith paper

  1. [1]

    Github copilot,

    “Github copilot,” https://github.com/features/copilot, accessed: 2024-05- 28

    work page 2024

  2. [2]

    Codeium,

    “Codeium,” https://codeium.com/, accessed: 2024-05-28

    work page 2024

  3. [3]

    Marscode,

    “Marscode,” https://www.marscode.com/, accessed: 2024-05-28

    work page 2024

  4. [4]

    Official page for language server protocol,

    “Official page for language server protocol,” accessed: 2024-10-10

    work page 2024

  5. [5]

    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 . K. Li, F. Luo, Y . Xiong, and W. Liang, “Deepseek-coder: When the large language model meets programming – the rise of code intelligence,” 2024. [Online]. Available: https://arxiv.org/abs/2401.14196

    arXiv 2024

  6. [6]

    Efficient training of language models to fill in the middle,

    M. Bavarian, H. Jun, N. Tezak, J. Schulman, C. McLeavey, J. Tworek, and M. Chen, “Efficient training of language models to fill in the middle,” 2022. [Online]. Available: https://arxiv.org/abs/2207.14255

    arXiv 2022

  7. [7]

    Nltk :: Natural language toolkit,

    “Nltk :: Natural language toolkit,” https://www.nltk.org/, accessed: 2024- 10-10

    work page 2024

  8. [8]

    Codet5+: Open code large language models for code understanding and generation,

    Y . Wang, H. Le, A. D. Gotmare, N. D. Bui, J. Li, and S. C. Hoi, “Codet5+: Open code large language models for code understanding and generation,” arXiv preprint arXiv:2305.07922 , 2023

    arXiv 2023

Show all 35 references
  1. [9]

    An efficient recommendation generation using relevant jaccard similarity,

    S. Bag, S. K. Kumar, and M. K. Tiwari, “An efficient recommendation generation using relevant jaccard similarity,” Information Sciences, vol. 483, pp. 53–64, 2019

    2019

  2. [10]

    Okapi bm25,

    “Okapi bm25,” https://en.wikipedia.org/wiki/Okapi BM25, accessed: 2024-10-10

    2024

  3. [11]

    Large language models for code completion: A systematic literature review,

    R. A. Husein, H. Aburajouh, and C. Catal, “Large language models for code completion: A systematic literature review,” Computer Standards & Interfaces, p. 103917, 2024

    2024

  4. [12]

    Large language models for software engineer- ing: A systematic literature review,

    X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engineer- ing: A systematic literature review,” arXiv preprint arXiv:2308.10620 , 2023

    2023 arXiv

  5. [13]

    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

  6. [14]

    Structured chain-of-thought prompting for code generation,

    J. Li, G. Li, Y . Li, and Z. Jin, “Structured chain-of-thought prompting for code generation,” ACM Transactions on Software Engineering and Methodology, 2023

    2023

  7. [15]

    Large language model-aware in-context learning for code generation,

    J. Li, G. Li, C. Tao, H. Zhang, F. Liu, and Z. Jin, “Large language model-aware in-context learning for code generation,” arXiv preprint arXiv:2310.09748, 2023

    2023

  8. [16]

    Codefill: Multi-token code completion by jointly learning from structure and naming sequences,

    M. Izadi, R. Gismondi, and G. Gousios, “Codefill: Multi-token code completion by jointly learning from structure and naming sequences,” in Proceedings of the 44th International Conference on Software Engi- neering, 2022, pp. 401–412

    2022

  9. [17]

    Intellicode compose: Code generation using transformer,

    A. Svyatkovskiy, S. K. Deng, S. Fu, and N. Sundaresan, “Intellicode compose: Code generation using transformer,” in Proceedings of the 28th ACM joint meeting on European software engineering conference and symposium on the foundations of software engineering , 2020, pp. 1433–1443

    2020

  10. [18]

    Classeval: A manually-crafted benchmark for evaluating llms on class-level code generation,

    X. Du, M. Liu, K. Wang, H. Wang, J. Liu, Y . Chen, J. Feng, C. Sha, X. Peng, and Y . Lou, “Classeval: A manually-crafted benchmark for evaluating llms on class-level code generation,” arXiv preprint arXiv:2308.01861, 2023

    2023 arXiv

  11. [19]

    Incoder: A generative model for code infilling and synthesis,

    D. Fried, A. Aghajanyan, J. Lin, S. Wang, E. Wallace, F. Shi, R. Zhong, W.-t. Yih, L. Zettlemoyer, and M. Lewis, “Incoder: A generative model for code infilling and synthesis,” arXiv preprint arXiv:2204.05999, 2022

    2022 arXiv

  12. [20]

    Language models for code completion: A practical evaluation,

    M. Izadi, J. Katzy, T. Van Dam, M. Otten, R. M. Popescu, and A. Van Deursen, “Language models for code completion: A practical evaluation,” in Proceedings of the IEEE/ACM 46th International Con- ference on Software Engineering , 2024, pp. 1–13

    2024

  13. [21]

    Evaluating the evalu- ations of code recommender systems: a reality check,

    S. Proksch, S. Amann, S. Nadi, and M. Mezini, “Evaluating the evalu- ations of code recommender systems: a reality check,” in Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering, 2016, pp. 111–121

    2016

  14. [22]

    When code completion fails: A case study on real-world completions,

    V . J. Hellendoorn, S. Proksch, H. C. Gall, and A. Bacchelli, “When code completion fails: A case study on real-world completions,” in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 960–970

    2019

  15. [23]

    Learning autocompletion from real- world datasets,

    G. A. Aye, S. Kim, and H. Li, “Learning autocompletion from real- world datasets,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) . IEEE, 2021, pp. 131–139

    2021

  16. [24]

    Code llama: Open foundation models for code,

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

    2023 arXiv

  17. [25]

    Deepseek-coder-v2: Breaking the barrier of closed-source models in code intelligence,

    Q. Zhu, D. Guo, Z. Shao, D. Yang, P. Wang, R. Xu, Y . Wu, Y . Li, H. Gao, S. Ma et al., “Deepseek-coder-v2: Breaking the barrier of closed-source models in code intelligence,” arXiv preprint arXiv:2406.11931 , 2024

    2024 arXiv

  18. [26]

    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 . Wei et al. , “Starcoder 2 and the stack v2: The next generation,” arXiv preprint arXiv:2402.19173 , 2024

    2024 arXiv

  19. [27]

    Longcoder: A long- range pre-trained language model for code completion,

    D. Guo, C. Xu, N. Duan, J. Yin, and J. McAuley, “Longcoder: A long- range pre-trained language model for code completion,” in International Conference on Machine Learning . PMLR, 2023, pp. 12 098–12 107

    2023

  20. [28]

    Bridge and hint: Extending pre-trained language models for long-range code,

    Y . Chen, C. Gao, Z. Yang, H. Zhang, and Q. Liao, “Bridge and hint: Extending pre-trained language models for long-range code,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis , 2024, pp. 274–286

    2024

  21. [29]

    Improving code generation by dynamic temperature sampling,

    Y . Zhu, J. Li, G. Li, Y . Zhao, J. Li, Z. Jin, and H. Mei, “Improving code generation by dynamic temperature sampling,” arXiv e-prints, pp. arXiv–2309, 2023

    2023

  22. [30]

    Multi-task learning based pre- trained language model for code completion,

    F. Liu, G. Li, Y . Zhao, and Z. Jin, “Multi-task learning based pre- trained language model for code completion,” in Proceedings of the 35th IEEE/ACM International Conference on Automated Software En- gineering, 2020, pp. 473–485

    2020

  23. [31]

    An empirical study on the usage of transformer models for code completion,

    M. Ciniselli, N. Cooper, L. Pascarella, A. Mastropaolo, E. Aghajani, D. Poshyvanyk, M. Di Penta, and G. Bavota, “An empirical study on the usage of transformer models for code completion,” IEEE Transactions on Software Engineering , vol. 48, no. 12, pp. 4818–4837, 2021

    2021

  24. [32]

    Planning with large language models for code generation,

    S. Zhang, Z. Chen, Y . Shen, M. Ding, J. B. Tenenbaum, and C. Gan, “Planning with large language models for code generation,” arXiv preprint arXiv:2303.05510, 2023

    2023 arXiv

  25. [33]

    Clarifygpt: A framework for enhancing llm-based code generation via requirements clarification,

    F. Mu, L. Shi, S. Wang, Z. Yu, B. Zhang, C. Wang, S. Liu, and Q. Wang, “Clarifygpt: A framework for enhancing llm-based code generation via requirements clarification,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 2332–2354, 2024

    2024

  26. [34]

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

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

    2023 arXiv

  27. [35]

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

    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 com- pletion,” arXiv preprint arXiv:2403.06095 , 2024

    2024 arXiv

Pith tools

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