PreprintCited by 17Software Engineering ResearchTopic ModelingTeaching and Learning Programming

Improving Code Autocompletion with Transfer Learning

Open access
Zhou, Wen, Kim, Seohyun, Murali, Vijayaraghavan, Aye, Gareth Ari·2021·arXiv

Abstract

Software language models have achieved promising results predicting code completion usages, and several industry studies have described successful IDE integrations. Recently, accuracy in autocompletion prediction improved 12.8% from training on a real-world dataset collected from programmers' IDE activity. But what if limited examples of IDE autocompletion in the target programming language are available for model training? In this paper, we investigate the efficacy of pretraining autocompletion models on non-IDE, non-autocompletion, and different-language example code sequences. We find that these unsupervised pretrainings improve model accuracy by over 50% on very small fine-tuning datasets and over 10% on 50k labeled examples. We confirm the real-world impact of these pretrainings in an online setting through A/B testing on thousands of IDE autocompletion users, finding that pretraining is responsible for increases of up to 6.63% autocompletion usage.

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Integrity signals

Registry

DataCite · 10.48550/arxiv.2105.05991

Cites

30 of 30 references verified0 citation errors · 0 not checkable

Statistics

Claims the paper makes

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

  • DCPU (Daily Completions accepted Per User) has been reported around 20.

    “An alternative measure is that of DCPU (Daily Completions accepted Per User) for which a value of around 20 has been reported [3,19].”

    From Productivity Assessment of Neural Code Completion (2022) · cites this paper as [19]

    The E. Evaluation section defines DCPU as the number of autocompletion suggestions a developer accepts in a day. The Online evaluation section reports percentage changes in DCPU, but neither section reports a DCPU value around 20; searches for that value found none. (LLM, conf=0.88)

    Experimental — accuracy not yet measured
  • An alternative measure is daily completions accepted per user (DCPU), for which a value of around 20 has been reported.

    “An alternative measure is that of daily completions accepted per user (DCPU) for which a value of around 20 has been reported.3,29”

    From Measuring GitHub Copilot's Impact on Productivity (2024) · cites this paper as [29]

    The Evaluation section defines DCPU as the number of autocompletion suggestions a developer accepts in a day. The Online evaluation reports percentage changes in DCPU, but no value of around 20 accepted completions per user per day; the cited paper therefore supports the measure, not the reported value. (LLM, conf=0.88)

    Experimental — accuracy not yet measured
  • The empirical software engineering research community has concluded that developer productivity is a multidimensional topic that cannot be summarized by a single metric.

    “To sum up, after many studies and many definitions, measurements, and approaches to productivity, the empirical software engineering research community has concluded that developer productivity is a multidimensional topic that cannot be summarized by a single metric.10”

    From Measuring GitHub Copilot's Impact on Productivity (2024) · cites this paper as [10]

    The Evaluation section describes metrics for code-autocompletion performance and use, including daily completions per user. Searches for developer productivity, multidimensional measurement, and a single metric found no passage saying that the empirical software engineering community reached the attributed conclusion. (LLM, conf=0.74)

    Experimental — accuracy not yet measured

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

The self-check needs the paper’s full text.

Cites

Flagged first, then by citations

2 of the 32 references couldn’t be matched to a known paper.

Research works printed but not linked: 1

  1. P. Bielik, V. Raychev, and M. Vechev, "Phog: Probabilistic model for code," in Proceedings of the 33rd International Conference on Inter- national Conference on Machine Learning -Volume 48, ser. ICML'16. JMLR.org, 2016, p. 2933-2942.

Cited by

Sorted by citations

Authors
Zhou, W., Kim, S., Murali, V., & Aye, G. A.
Affiliations
Meta (United States) (US)
Venue
arXiv
Publisher
arXiv
Published
2021
ISSN
2331-8422 (ISSN-L)
OpenAlex
W4303711643
Cited by
0
References
32
Type
posted content
Language
en
Open access
Locations
  • arXiv (Cornell University) (submittedVersion, cc-by)
  • arXiv (Cornell University) (cc-by)
Topics
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Research
  • Physical Sciences › Computer Science › Artificial Intelligence › Topic Modeling
  • Physical Sciences › Computer Science › Computer Science Applications › Teaching and Learning Programming
Keywords
transfer learning, pre-training, IDE integration, fine-tuning, unsupervised pre-training, A/B testing

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review