Log In Sign Up

Evaluating Large Language Models Trained on Code

by   Mark Chen, et al.

We introduce Codex, a GPT language model fine-tuned on publicly available code from GitHub, and study its Python code-writing capabilities. A distinct production version of Codex powers GitHub Copilot. On HumanEval, a new evaluation set we release to measure functional correctness for synthesizing programs from docstrings, our model solves 28.8 solves 0 from the model is a surprisingly effective strategy for producing working solutions to difficult prompts. Using this method, we solve 70.2 problems with 100 samples per problem. Careful investigation of our model reveals its limitations, including difficulty with docstrings describing long chains of operations and with binding operations to variables. Finally, we discuss the potential broader impacts of deploying powerful code generation technologies, covering safety, security, and economics.


page 1

page 2

page 3

page 4


Security Implications of Large Language Model Code Assistants: A User Study

Advances in Deep Learning have led to the emergence of Large Language Mo...

A Hazard Analysis Framework for Code Synthesis Large Language Models

Codex, a large language model (LLM) trained on a variety of codebases, e...

An Empirical Cybersecurity Evaluation of GitHub Copilot's Code Contributions

There is burgeoning interest in designing AI-based systems to assist hum...

Generative Language Models for Paragraph-Level Question Generation

Powerful generative models have led to recent progress in question gener...

Program Synthesis with Large Language Models

This paper explores the limits of the current generation of large langua...

Code as Policies: Language Model Programs for Embodied Control

Large language models (LLMs) trained on code completion have been shown ...

Learning Python Code Suggestion with a Sparse Pointer Network

To enhance developer productivity, all modern integrated development env...

Code Repositories


A Dataset of Python Challenges for AI Research

view repo


Code for the paper "Evaluating Large Language Models Trained on Code"

view repo


Full description can be found here:

view repo

1 Introduction

Scalable sequence prediction models (Graves, 2014; Vaswani et al., 2017; Child et al., 2019)

have become a general-purpose method for generation and representation learning in many domains, including natural language processing

(Mikolov et al., 2013; Sutskever et al., 2014; Dai and Le, 2015; Peters et al., 2018; Radford et al., 2018; Devlin et al., 2018)

, computer vision

(Van Oord et al., 2016; Menick and Kalchbrenner, 2018; Chen et al., 2020; Bao et al., 2021), audio and speech processing (Oord et al., 2016, 2018; Dhariwal et al., 2020; Baevski et al., 2020), biology (Alley et al., 2019; Rives et al., 2021), and even across multiple modalities (Das et al., 2017; Lu et al., 2019; Ramesh et al., 2021; Zellers et al., 2021). More recently, language models have also fueled progress towards the longstanding challenge of program synthesis (Simon, 1963; Manna and Waldinger, 1971), spurred by the presence of code in large datasets (Husain et al., 2019; Gao et al., 2020) and the resulting programming capabilities of language models trained on these datasets (Wang and Komatsuzaki, 2021). Popular language modeling objectives like masked language modeling (Devlin et al., 2018) and span prediction (Raffel et al., 2020) have also been adapted to train their programming counterparts CodeBERT (Feng et al., 2020) and PyMT5 (Clement et al., 2020).

Similarly, our early investigation of GPT-3 (Brown et al., 2020) revealed that it could generate simple programs from Python docstrings. While rudimentary, this capability was exciting because GPT-3 was not explicitly trained for code generation. Given the considerable success of large language models in other modalities and the abundance of publicly available code, we hypothesized that a specialized GPT model, called Codex, could excel at a variety of coding tasks. This paper describes several early Codex models, whose descendants power GitHub Copilot and the Codex models in the OpenAI API.

Figure 1:

Pass rates of our models on the HumanEval dataset as a function of model size. When a single sample is generated for each problem, GPT-12B solves no problems, but Codex (fine-tuned on code) solves 28.8% of the problems, and Codex-S (further fine-tuned on correctly implemented standalone functions) solves 37.7% of the problems. From here, further gains can be realized by generating 100 samples per problem and selecting the sample with the highest mean log-probability (44.5% solved) or by selecting the sample that passes the unit tests (77.5% solved). All samples are generated with temperature 0.8.

In this work, we focus on the task of generating standalone Python functions from docstrings, and evaluate the correctness of code samples automatically through unit tests. This is in contrast to natural language generation, where samples are typically evaluated by heuristics or by human evaluators. To accurately benchmark our model, we create a dataset of 164 original programming problems with unit tests. These problems assess language comprehension, algorithms, and simple mathematics, with some comparable to simple software interview questions. We release this data along with an evaluation framework at

To solve a problem in our test set, we generate multiple samples from the models, and check if any of them pass the unit tests. With just a single sample, a 12B parameter Codex solves 28.8% of these problems, and a 300M parameter Codex solves 13.2% of these problems. In contrast, the 6B parameter GPT-J (Wang and Komatsuzaki, 2021) achieves 11.4% on the same dataset, while all GPT models achieve near 0%. To improve our model’s performance at the task of function synthesis from docstrings, we fine-tune Codex on standalone, correctly implemented functions. The resulting model, Codex-S, solves 37.7% of problems with a single sample. Figure 2 showcases problems of varying difficulty in our dataset, along with correct model generated solutions.

Figure 2: Three example problems from the HumanEval dataset, where the probabilities that a single sample from Codex-12B passes unit tests are 0.9, 0.17, and 0.005. The prompt provided to the model is shown with a white background, and a successful model-generated completion is shown in a yellow background. Though not a guarantee for problem novelty, all problems were hand-written and not programmatically copied from existing sources. Random problems and samples can be found in Appendix B.

Real-world programming tasks often involve iterations of approaches and bug fixes, which is approximated by generating many samples from our models and selecting one that passes all unit tests. Within 100 samples, Codex-S is able to generate at least one correct function for 77.5% of the problems. This result suggests that accurate code samples can be selected via heuristic ranking instead of fully evaluating each sample, the latter of which may not be possible or practical in deployment. Indeed, we find that the sample with highest mean log-probability passes unit tests for 44.5% of the problems.

We conclude by discussing the limitations and potential broader impacts of these Codex models and of increasingly powerful code generating models more generally.

2 Evaluation Framework

In this section, we discuss the details of our evaluation framework. We begin by defining the pass@ metric, and explain its advantages over standard match-based metrics. Next, we describe the dataset of hand-written problems, called “HumanEval,” which we created in order to benchmark our models. Finally, we discuss the sandbox environment we used to safely execute model-generated code.

2.1 Functional Correctness

Generative models for code are predominantly benchmarked by matching samples against a reference solution, where the match can be exact or fuzzy (as in BLEU score). However, recent work has surfaced deficiencies in match-based metrics for code. For instance, Ren et al. (2020) finds that BLEU has problems capturing semantic features specific to code, and suggests several semantic modifications to the score.

More fundamentally, match-based metrics are unable to account for the large and complex space of programs functionally equivalent to a reference solution. As a consequence, recent works in unsupervised code translation (Lachaux et al., 2020) and pseudocode-to-code translation (Kulal et al., 2019) have turned to functional correctness instead, where a sample is considered correct if it passes a set of unit tests. We argue that this metric should be applied to docstring-conditional code generation as well.

Perhaps the most convincing reason to evaluate functional correctness is that it is used by human developers to judge code. A framework known as test-driven development dictates that software requirements be converted into test cases before any implementation begins, and success is defined by a program that passes these tests. While few organizations employ full test-driven development, integration of new code is usually dependent on creating and passing unit tests.

Kulal et al. (2019) evaluate functional correctness using the pass@ metric, where code samples are generated per problem, a problem is considered solved if any sample passes the unit tests, and the total fraction of problems solved is reported. However, computing pass@

in this way can have high variance. Instead, to evaluate pass@

, we generate samples per task (in this paper, we use and ), count the number of correct samples

which pass unit tests, and calculate the unbiased estimator

pass@ (1)

Calculating this estimator directly results in very large numbers and numerical instability. In Figure

3, we include a numerically stable numpy implementation that simplifies the expression and evaluates the product term-by-term. One may be tempted to estimate pass@ with where is the empirical estimate of pass@1, but we show that it is biased in Appendix A.

def pass_at_k(n, c, k):
    if n - c < k: return 1.0
    return 1.0 - - k /
        np.arange(n - c + 1, n + 1))
Figure 3: A numerically stable script for calculating an unbiased estimate of pass@.

Later, we provide evidence that BLEU score may not be a reliable indicator of functional correctness by showing that functionally inequivalent programs generated by our model (which are guaranteed to disagree with the reference solution on some input) often have higher BLEU scores than functionally equivalent ones.

2.2 HumanEval: Hand-Written Evaluation Set

We evaluate functional correctness on a set of 164 hand-written programming problems, which we call the HumanEval dataset. Each problem includes a function signature, docstring, body, and several unit tests, with an average of 7.7 tests per problem. It is important for these tasks to be hand-written, since our models are trained on a large fraction of GitHub, which already contains solutions to problems from a variety of sources. For example, there are more than ten public repositories containing solutions to Codeforces problems, which make up part of the recently proposed APPS dataset (Hendrycks et al., 2021).

Programming tasks in the HumanEval dataset assess language comprehension, reasoning, algorithms, and simple mathematics. We release the HumanEval dataset so that others can evaluate functional correctness and measure the problem-solving capabilities of their models. The dataset can be found at

2.3 Sandbox for Executing Generated Programs

Since publicly available programs have unknown intent and generated programs are often incorrect, executing these programs poses a security risk. Indeed, GitHub is known to contain malicious programs that alter or change their environments (Rokon et al., 2020).

Therefore, we developed a sandbox environment to safely run untrusted programs against unit tests. Our goals were to prevent these programs from modifying, gaining persistence on, accessing sensitive resources on, or exfiltrating data from a host or network. Since OpenAI’s training infrastructure is built on Kubernetes and cloud services, we designed our sandbox to address the limitations of these environments while remaining idiomatic with their patterns of use.

We selected the gVisor container runtime (Lacasse, 2018) as the main host protection component. Since container runtimes like Docker can share host resources with containers, a malicious container could potentially compromise a host. gVisor protects the host by emulating its resources to introduce a security boundary between the host and its containers. Network-adjacent hosts and services are protected by eBPF-based firewall rules that prevent inbound and outbound connections except for those required for experiment control.

3 Code Fine-Tuning

We fine-tune GPT models containing up to 12B parameters on code to produce Codex. In contrast with GPT, Codex displays non-trivial performance on the HumanEval dataset. In fact, Codex is able to solve the majority of the problems in HumanEval if we generate and evaluate 100 samples per problem, and pick one that passes unit tests. When limited to a budget of one evaluation per problem, producing multiple samples with Codex and choosing the one with the highest mean log-probability provides significant gains.

3.1 Data Collection

Our training dataset was collected in May 2020 from 54 million public software repositories hosted on GitHub, containing 179 GB of unique Python files under 1 MB. We filtered out files which were likely auto-generated, had average line length greater than 100, had maximum line length greater than 1000, or contained a small percentage of alphanumeric characters. After filtering, our final dataset totaled 159 GB.

3.2 Methods

Since Codex is evaluated on natural language prompts, we hypothesized that it would be beneficial to fine-tune from the GPT-3 (Brown et al., 2020) model family, which already contains strong natural language representations. Surprisingly, we did not observe improvements when starting from a pre-trained language model, possibly because the fine-tuning dataset is so large. Nevertheless, models fine-tuned from GPT converge more quickly, so we apply this strategy for all subsequent experiments.

We train Codex using the same learning rate as the corresponding GPT model, with a 175 step linear warmup and cosine learning rate decay. We train for a total of 100 billion tokens, using the Adam optimizer with , , , and a weight decay coefficient of .

In order to maximally leverage text representations from GPT, we base our code lexer on the GPT-3 text tokenizer. Since the distribution of words in GitHub code differs from that of natural text, this tokenizer is not very effective for representing code. The largest source of inefficiency arises from encoding whitespace, so we add an additional set of tokens for representing whitespace runs of different lengths. This allows us to represent code using approximately 30% fewer tokens.

To compute pass@, we assemble each HumanEval problem into a prompt consisting of a header, a signature, and a docstring, which is illustrated in Figure 2. We sample tokens from Codex until we encounter one of the following stop sequences: ‘\nclass’, ‘\ndef’, ‘\n#’, ‘\nif’, or ‘\nprint’, since the model will continue generating additional functions or statements otherwise. We use nucleus sampling (Holtzman et al., 2020) with top for all sampling evaluation in this work.

3.3 Results

Figure 4: Model cross-entropy test loss measured on a held-out split of our Python GitHub code corpus. The smooth power law scaling of performance with model size observed in GPT-3 appears to hold even after code fine-tuning.

In Figure 4, we plot test loss on a held-out validation set against Codex model size. We find that just as language model test loss follows a power law in model size (Kaplan et al., 2020), test loss after code fine-tuning follows a similar power law with functional form where is the number of non-embedding parameters in the model.

When evaluating pass@, it is important to optimize sampling temperature for the particular value of . In Figure 5, we plot pass@ against the number of samples and the sampling temperature. We find that higher temperatures are optimal for larger , because the resulting set of samples has higher diversity, and the metric rewards only whether the model generates any correct solution.

In particular, for a 679M parameter model, the optimal temperature for pass@1 is and the optimal temperature for pass@100 is . With these temperatures, we find that pass@1 and pass@100 scale smoothly as a function of model size (Figure 6).

Figure 5: In the top panel, we plot pass@ against the number of samples () for various temperature settings. Higher temperatures are better when the number of samples is large, likely due to the increased sample diversity. In the bottom panel, we plot the best temperature setting for each , obtained by taking the upper hull of the top panel.
Figure 6: Using the optimal temperatures 0.2 and 0.8 for pass@1 and pass@100, we plot these two metrics as a function of model size. Performance appears to scale smoothly as a sigmoid in log-parameters.

Pass@ can also be interpreted as the result of evaluating the best out of samples, where the best sample is picked by an oracle with prior knowledge of the unit tests. From a practical perspective, we are also interested in the setting where we must select a single sample from samples without having access to an oracle. For instance, when the model is used as an autocomplete tool where a user provides a prompt, we do not have unit tests, but would like to return only a single completion to the user for evaluation so as to not overwhelm them.

Inspired by similar work in language modeling, we find that choosing the sample with the highest mean token log probability outperforms evaluating a random sample, while choosing the sample based on sum log probability can perform slightly worse than picking randomly. Figure 7 demonstrates the benefits of applying these heuristics to samples (at temperature 0.8) from Codex-12B.

Figure 7: Model performance in the setting where we can generate multiple samples, but only evaluate one. We can do better than randomly selecting a sample by choosing the solution with the highest mean log-probability (red) or with the highest back-translation score (orange) described in Sec. 5. The blue line represents the theoretical best performance obtained using an oracle with prior knowledge of the unit tests.

Finally, we compute BLEU scores for all Codex-12B HumanEval samples (at temperature 0.8) against their reference solutions. For each problem, when we plot the distributions of BLEU scores for correct and incorrect solutions, we notice significant overlap (Figure 8). Since an incorrect solution is guaranteed to be functionally inequivalent to the reference solution, we conclude that improvements in BLEU score may not indicate improved rates of functional correctness in practice.

Figure 8: BLEU score probability densities for correct (blue) and wrong (green) solutions from Codex-12B for 4 random tasks from HumanEval. Note that the distributions are not cleanly separable, suggesting that optimizing for BLEU score is not equivalent to optimizing for functional correctness.

3.4 Comparative Analysis of Related Models and Systems

Two recent works similar in spirit to Codex are GPT-Neo (Black et al., 2021) and GPT-J (Wang and Komatsuzaki, 2021), which are trained on The Pile (Gao et al., 2020), a dataset containing text from a variety of sources as well as 8% GitHub code. The broader research community has found that these models outperform existing GPT systems in qualitative programming evaluations (Woolf, 2021).

We confirm these findings using the HumanEval dataset, showing that GPT-Neo achieves 6.4% pass@1 and 21.3% pass@100, while GPT models of comparable sizes achieve near 0% on both metrics. We see a remarkable progression in capabilities, with GPT-Neo-2.7B roughly equivalent to Codex-85M ( fewer parameters). Similarly, GPT-J-6B achieves 11.6% pass@1 and 27.7% pass@100, which is roughly equivalent to Codex-300M ( fewer parameters). Pass rates are obtained by taking the best result from evaluating at temperatures 0.2, 0.4, and 0.8 for GPT-Neo, and from temperatures 0.2 and 0.8 for GPT-J. Detailed results across multiple model sizes can be found in Table 1.

Finally, we benchmark Codex against the largest free model from Tabnine, a leading code autocomplete system, which achieves 2.6% pass@1 (at ) and 7.6% pass@100 (at ). This is roughly equivalent to Codex-12M, one of the smallest models in our suite.

GPT-Neo 125M 0.75% 1.88% 2.97%
GPT-Neo 1.3B 4.79% 7.47% 16.30%
GPT-Neo 2.7B 6.41% 11.27% 21.37%
GPT-J 6B 11.62% 15.74% 27.74%
TabNine 2.58% 4.35% 7.59%
Codex-12M 2.00% 3.62% 8.58%
Codex-25M 3.21% 7.1% 12.89%
Codex-42M 5.06% 8.8% 15.55%
Codex-85M 8.22% 12.81% 22.4%
Codex-300M 13.17% 20.37% 36.27%
Codex-679M 16.22% 25.7% 40.95%
Codex-2.5B 21.36% 35.42% 59.5%
Codex-12B 28.81% 46.81% 72.31%
Table 1: Codex, GPT-Neo, & TabNine evaluations for HumanEval. We find that GPT-J pass@1 is between Codex-85M and Codex-300M performance.

3.5 Results on the APPS Dataset

Recently, Hendrycks et al. (2021) introduced the APPS dataset to measure the coding challenge competence of language models. The APPS dataset consists of 5000 training and 5000 test examples of coding problems, each with a set of unit tests and, for the training data, a set of correct solutions. Most of the APPS tests problems are not formulated as single-function synthesis tasks, but rather as full-program synthesis, reading input from stdin and printing output to stdout, in contrast to the main Codex training data.

In the paper that introduces APPS, the authors benchmark a few language models and report two metrics: the percentage of problems where the model finds a correct solution (called the “strict accuracy”) and the percentage of unit tests passed, even if the solution is incorrect. The latter measure is reported only so as to reduce variance of the measurements, because the results on the first metric were so low. We avoid this metric and only focus on “strict accuracy”, and - as in the previous sections - we report pass@ numbers for various (Table 2). There are 2 additional factors, well-known from coding competitions, that we take into account:

  • In coding competitions and in the APPS datasets, tasks are provided with 3 input/output examples included in the task description. We utilize this by sampling 1000 solutions from the model and filtering out only those that pass these 3 unit tests (if such solutions exist). We then calculate pass rates in this filtered set, and call it filtered pass@. Results without filtering are presented as raw pass@.

  • It is often the case both in coding competitions and in the results from Codex that a correct solution is found, but it is not algorithmically efficient enough to be considered passing. While this is not acceptable in the competitions, we also report the number of solutions that Codex produces that do not fail on any unit test, but that do time-out on some of them. We use a timeout of 3 seconds in our evaluation.

To compensate for the fact the Codex is not fine-tuned on APPS, we append a single input/output example from the task description to the docstring as a formatting hint. We denote this setting as “1-shot” in Table 2, and find that Codex-12B evaluated 1-shot achieves comparable performance to a GPT-Neo model fine-tuned on APPS. Consistent with our earlier findings, there are large benefits from generating and evaluating as many as 1000 samples per task, though for more difficult problems, solutions are often not efficient enough to pass the time limits. Finally, evaluating the first sample which passes the 3 public unit tests for each problem yields higher performance than raw@100 samples.

Introductory Interview Competition
GPT-Neo 2.7B raw pass@1 3.90% 0.57% 0.00%
GPT-Neo 2.7B raw pass@5 5.50% 0.80% 0.00%
1-shot Codex raw pass@1 4.14% (4.33%) 0.14% (0.30%) 0.02% (0.03%)
1-shot Codex raw pass@5 9.65% (10.05%) 0.51% (1.02%) 0.09% (0.16%)
1-shot Codex raw pass@100 20.20% (21.57%) 2.04% (3.99%) 1.05% (1.73%)
1-shot Codex raw pass@1000 25.02% (27.77%) 3.70% (7.94%) 3.23% (5.85%)
1-shot Codex filtered pass@1 22.78% (25.10%) 2.64% (5.78%) 3.04% (5.25%)
1-shot Codex filtered pass@5 24.52% (27.15%) 3.23% (7.13%) 3.08% (5.53%)
Table 2: Finetuned GPT-Neo numbers from the APPS paper referenced above. For Codex-12B, the number of passing programs that timeout on some test is in the bracket. We used temperature 0.6 for sampling to cover all in pass@, so raw pass@1 results could be improved with lower temperature.

4 Supervised Fine-Tuning

In addition to standalone functions, Python code found on GitHub contains class implementations, configuration files, scripts, and even files used to store data. This code is seemingly unrelated to synthesizing functions from docstrings, and we hypothesize that the distribution mismatch reduces HumanEval performance.

In order to adapt Codex to the distribution of the task of interest, we construct a set of training problems from correctly implemented standalone functions, and use them for additional supervised fine-tuning. We describe two approaches for collecting these examples: from competitive programming websites and from repositories with continuous integration. We call the supervised fine-tuned models Codex-S, and show that they produce consistent gains across model size.

4.1 Problems from Competitive Programming

Programming contest and interview preparation websites use hidden unit tests to automatically judge the functional correctness of submissions. These problems are self-contained, come with well-written problem statements, and generally have excellent test coverage. Additionally, these problems test algorithmic reasoning over a broad range of core skills and difficulties.

We collected problem statements, function signatures, and solutions from several popular programming contest and interview preparation websites. We then assembled these into programming tasks similar to HumanEval, using the problem description as the docstring. Since complete test suites are often hidden, we created unit tests from examples found in the problem statements, or extracted additional test cases through submitting incorrect solutions. In total, we curated 10,000 problems in this way.

4.2 Problems from Continuous Integration

Next, we curated programming problems from open source projects. Taking advantage of

sys.setprofile, we were able to trace and collect inputs and outputs for all functions called during integration tests. This data could then be used to create unit tests for the functions.

Projects that employ continuous integration (CI) are ideal candidates for tracing. We follow the commands in the CI configuration files, which contain build and test commands, to set up the virtual environments, install dependencies, and run integration tests.

We considered GitHub repos using travis and tox as their CI frameworks, as they are two of the most popular CI tools. We additionally used publicly available source code from pip packages found in the python package index (PyPI). Because these projects contained untrusted code, it was important to run integration tests in the sandboxed environment described above.

While there are millions of potential functions to curate problems from, we only collected about 40,000 because not all functions accept inputs and return outputs. Even when they do, most objects captured at runtime cannot be pickled and restored outside the sandbox unless the project was installed.

Since our tracing methodology produced inputs and outputs for all invoked functions, even builtin and library calls imported by the project were turned into problems. For this reason, functions from tracing tended to be the building blocks of command-line utilities. To excel at these tasks, the model does not need to know advanced algorithms and data structures. Rather, it needs to be able to follow instructions to implement the functionality specified in the docstring. Thus, tracing complements the puzzle nature of coding competition problems and broadens the distribution of tasks.

4.3 Filtering Problems

In the previous sections, we presented two methods we used to automatically create training problems. However, it is unclear how to control for quality. Some prompts underspecify the function that is implemented, in which case a perfectly valid solution may be wrongly penalized by the unit test. Some problems are stateful, and subsequent executions can result in different outcomes.

To address these issues, we use Codex-12B to generate 100 samples per curated problem. If no samples pass the unit tests, we consider the task to be either ambiguous or too difficult, and filter it out. We reran this verification several times to remove stateful or non-deterministic problems.

4.4 Methods

We fine-tune Codex on these training problems to produce a set of “supervised fine-tuned” models, which we call Codex-S. To produce examples from training problems, we assemble the problems into the format shown in Figure 2

. If there are prompts of varying length in a batch, we left-pad shorter prompts to the length of the longest prompt, so that the first tokens in the reference solutions line up in context.

We train to minimize negative log-likelihood of the reference solution, and mask out loss for any tokens in the prompt. We train using a learning rate as large as used for fine-tuning Codex, but adhere to the same learning rate schedule, and train until validation loss plateaus (less than 10B tokens).

4.5 Results

As with Codex, we first compute the optimal temperature for evaluating pass@ for . We find that Codex-S prefers slightly higher temperatures for all , which possibly reflects the fact that Codex-S captures a narrower distribution than Codex. We use for computing pass@1 and for computing pass@100.

Figure 9: Optimal sampling temperatures as a function of the number of samples generated for both Codex and Codex-S. Codex-S generally requires a higher temperature for any particular value of , possibly to compensate for the fact that it models a narrower distribution.

Next, we compare Codex-S against Codex on pass@1 and pass@100. Codex-S outperforms the corresponding Codex by an average margin of 6.5 percentage points on pass@1 and by a larger average margin of 15.1 percentage points on pass@100 across model size.

We also plot the performance of different sample selection heuristics for Codex-S-12B against the same heuristics for Codex-12B. When ranking between 1 and 100 samples by mean log probability, the average benefit over random ranking is 11.6 percentage points, which is over 2 percentage points higher than the corresponding benefit for Codex.

Figure 10: Comparing Codex-S against Codex on the metrics proposed in Section 3. Codex-S is one or two orders of magnitude more parameter efficient on pass@1 and pass@100, and log-prob sample ranking with Codex-S yields similar benefits over random sampling that Codex does.

5 Docstring Generation

Generating code from docstrings is possible with Codex because code typically follows after a docstring, but it is not easy to induce Codex to generate docstrings from code. Nevertheless, we are motivated to produce a docstring writing model for safety reasons, as such a model can be used to describe the intent behind generated code. Using the training problems described in the previous section, we can easily create a training dataset for code-conditional docstring generation.

Specifically, for each training problem, we assemble a training example by concatenating the function signature, the reference solution, and then the docstring. Just as we train Codex-S by minimizing negative log-likelihood of the reference solution, we train the docstring generating models Codex-D by minimizing negative log-likelihood of the docstring.

When we benchmark our code generation models, we measure pass@ on the HumanEval dataset, where correctness is defined by passing a set of unit tests. However, there is no similar way to evaluate docstring samples automatically. Therefore, we grade sample docstrings by hand, considering a docstring correct if it uniquely and accurately specifies the code body. Due to the time consuming nature of this process, we only grade 10 samples per problem, for a total of 1640 problems, from Codex-D-12B at temperature 0.8.

Codex-D often generates incorrect unit tests along with a docstring, but we ignore these during grading. However, we do not consider the docstring correct when the model simply copies the code body into the docstring. The most common failure modes we observe are when the docstring model leaves out an important detail (such as “an answer must be to two decimal places”) or when it over-conditions on the function name and invents a problem unrelated to the function body.

As shown in Table 3, pass rates for Codex-D are lower but comparable to the corresponding pass rates for Codex-S at the same temperature. We do not have a strong hypothesis for which direction should yield higher pass rates. While generating docstrings may be more forgiving because natural language syntax is less strict than code syntax, docstrings in our dataset may be lower quality because developers tend to devote less time to writing docstrings. Indeed, our model produces docstrings like “I just found this function online” and “This test is not correctly written and it’s not my solution.”

Model pass@1 pass@10
Codex-S-12B 32.2% 59.5%
Codex-D-12B 20.3% 46.5%
Table 3: Pass rates for our docstring generating model Codex-D, which is evaluated by hand-grading 10 samples per task due to the lack of a ground-truth automatic evaluation. We find similar but lower pass-rates compared to Codex-S.

Finally, with a docstring model, we have yet another way to choose a single sample from a set of samples. Instead of picking the sample with the best mean log probability as investigated in the previous two sections, we can choose the sample that maximizes the back-translation objective where is evaluated using Codex-D. Unfortunately, in Figure 7, we show that ranking samples via back-translation underperforms mean log-probability ranking, though it outperforms random ranking. This heuristic also appears to overfit quickly.

6 Limitations

While Codex is able to sample correct solutions for the majority of HumanEval problems, we find that it has a number of limitations.

First, Codex is not sample efficient to train. Our training dataset comprises a significant fraction of publicly available Python code on GitHub, totaling hundreds of millions of lines of code. Even seasoned developers do not encounter anywhere near this amount of code over their careers. Indeed, a strong student who completes an introductory computer science course is expected to be able to solve a larger fraction of problems than Codex-12B.

Next, we explore prompts on which Codex is likely to fail or display counter-intuitive behavior. While evaluating code generation is well-studied (Xu et al., 2021; Helmuth and Spector, 2015; Pantridge et al., 2017), many existing metrics measure performance in tightly specified, constrained problem instances (e.g., string manipulation in FlashFill (Gulwani, 2011)). Therefore, we developed a set of qualitative metrics for measuring the capabilities of code generating models while controlling for the complexity and abstraction level of the specifications (Appendix D). Applying this framework, we find that Codex can recommend syntactically incorrect or undefined code, and can invoke functions, variables, and attributes that are undefined or outside the scope of the codebase. Moreover, Codex struggles to parse through increasingly long and higher-level or system-level specifications.

To concretely illustrate model performance degradation as docstring length increases, we create a dataset of synthetic problems assembled from 13 basic building blocks, each of which modifies an input string in a deterministic way. Example building blocks are “convert the string to lowercase” or “remove every third character from the string” (the full list is described in Appendix C). We find that as the number of chained building blocks in the docstring increases, model performance decreases exponentially. This behavior is uncharacteristic of a human programmer, who should be able to correctly implement a program for a chain of arbitrary length if they can do so for a chain of length two.

Figure 11: Pass rates of Codex-12B samples against the number of chained components in the synthetically generated docstring. With each additional component, pass rate drops by roughly a factor of 2-3.

Further, just as text-conditional generative models in other modalities (Ramesh et al., 2021) have difficulty with binding attributes to objects, Codex can make mistakes binding operations to variables, especially when the number of operations and variables in the docstring is large. For instance, in the following prompt, Codex-12B does not decrement the variable w and also fails to return the product of all numbers.

def do_work(x, y, z, w):
    t = y + 3
    u = x - 4
    v = z * w
    return v

This understanding of Codex’s limited system-level synthesis capabilities helps inform our assessment of the potential hazards of using it in a generative capacity, as well as the broader societal impacts that such systems could have.

7 Broader Impacts and Hazard Analysis

Codex has the potential to be useful in a range of ways. For example, it could help onboard users to new codebases, reduce context switching for experienced coders, enable non-programmers to write specifications and have Codex draft implementations, and aid in education and exploration. However, Codex also raises significant safety challenges, does not always produce code that is aligned with user intent, and has the potential to be misused.

To better understand some of the hazards of using Codex in a generative capacity, we conducted a hazard analysis focused on identifying risk factors (Leveson, 2019) with the potential to cause harm.111We sought to include harms spanning geographic and temporal scales. We also considered not only the severity and probability, but also the distribution of harms. However, we note that the analysis described here is only one milestone in what we hope will be a larger cross-sectoral and cross-organizational effort to steer code generation in a societally beneficial direction. As we describe our findings, we note various specific uncertainties and areas for future work in different sections. We outline some of our key findings across several risk areas below.

While some of our findings about the potential societal impacts of code generation systems were informed by work towards responsible deployment of the production-oriented Codex models (which descended from the research-oriented Codex models described in this paper), this section is not intended to provide a full account of any particular product’s safety features. Unless otherwise specified, we anchor our analysis in the specific properties of the models described in this paper. We share this analysis in the belief that some of it generalizes to the broader class of code generation systems, and to encourage a norm of performing detailed impact analysis as part of major machine learning research projects.

Note that by focusing largely on risks in this section, we do not mean to imply that we expect the impact of this class of technologies to be net-negative; rather, risks merit particular attention here because they may be subtle or require deliberate effort to address, whereas we expect the benefits to be more obvious and “automatic” from the perspective of most users and affected stakeholders.

7.1 Over-reliance

One of the key risks associated with using code generation models in practice is over-reliance on generated outputs. Due to the limitations described above as well as alignment issues described below, Codex may suggest solutions that superficially appear correct but do not actually perform the task the user intended. This could particularly affect novice programmers, and could have significant safety implications depending on the context. We discuss a related issue in Appendix G, namely that code generation models can suggest insecure code. For these reasons, human oversight and vigilance is required for safe use of code generation systems like Codex.

We note several immediate ways to improve safety in the subsection on risk mitigation below, though over-reliance in particular is one that we believe merits further inquiry in industry and academia. While it is conceptually straightforward to provide documentation to users reminding them about model limitations, empirical investigation is necessary in order to identify how to reliably ensure vigilance in practice across a range of user experience levels, UI designs, and tasks. One challenge researchers should consider is that as capabilities improve, it may become increasingly difficult to guard against “automation bias.”

7.2 Misalignment

As with other large language models trained on a next-token prediction objective, Codex will generate code that is as similar as possible to its training distribution. One consequence of this is that such models may do things that are unhelpful for the user, despite having the capability to be more helpful (see Figure 12). For example, if the user has some subtle mistakes in their code, Codex may “deliberately” suggest code that superficially appears good but is incorrect.

Figure 12: When the prompt includes subtle bugs, Codex tends to produce worse code than it is capable of. This persists when the prompt also includes instructions to write correct code. This gap increases with model size.

This is an alignment failure - the model is not aligned with the user’s intentions. Informally, a system is misaligned if there’s some task X that we want it to do, and it is “capable” of doing X but “chooses” not to. In contrast, if a system fails to do X because it does not have the ability to do so, then this system is not misaligned; it is just incompetent. See Appendix E for more detail, including a more precise definition of alignment.

It is important to study misalignment because it is a problem that is likely to become worse, not better, as the capabilities of our systems increase. For example, the model size scaling trend for the example in Figure 12 indicates that misalignment would likely persist and even get worse if data, parameters, and training time were scaled up.

While we expect that misaligned behaviour like this is unlikely to cause significant harm in current models, it is likely to become more dangerous and harder to eliminate as model capabilities increase. A highly capable but sufficiently misaligned model trained on user approval might produce obfuscated code that looks good to the user even on careful inspection, but in fact does something undesirable or even harmful.

7.3 Bias and representation

Mirroring what has been found in the case of other language models trained on Internet data (Bender et al., 2021; Blodgett et al., 2020; Abid et al., 2021; Brown et al., 2020), we found that Codex can be prompted in ways that generate racist, denigratory, and otherwise harmful outputs as code comments, meriting interventions such as those discussed in the subsection on risk mitigation below. We also found that code generation models raise further bias and representation issues beyond problematic natural language: Codex can generate code with structure that reflects stereotypes about gender, race, emotion, class, the structure of names, and other characteristics. Particularly in the context of users who might over-rely on Codex or use it without first thinking through project design, this issue could have significant safety implications, giving further motivation to discourage over-reliance. We discuss bias and representation issues further in Appendix F. Filtration or modulation of generated outputs, documentation, and other interventions may help to mitigate these risks.

7.4 Economic and labor market impacts

Code generation and associated capabilities have several possible economic and labor market impacts. While Codex at its current capability level may somewhat reduce the cost of producing software by increasing programmer productivity, the size of this effect may be limited by the fact that engineers don’t spend their full day writing code (O*NET, 2021). Other important tasks include conferring with colleagues, writing design specifications, and upgrading existing software stacks.222

Indeed, BLS classifies computer programmers and software developers separately, where developers are more highly paid than programmers, have more tasks indirectly related to writing and interacting with code, and, in the US, are already projected to see greater demand over the next 10 years

(Li et al., 2020; Bureau of Labor Statistics, 2021b, a). We also found that Codex imports packages at different rates, which could advantage some package authors over others, particularly if programmers and engineers come to rely on Codex’s suggestions. Over a longer time horizon, the effects of this class of technologies on software-related labor markets and on the economy more generally could be more substantial as capabilities improve. More study is needed both on the effects of code generation capabilities and on appropriate responses. We discuss economic and labor market implications in more detail in Appendix H.

7.5 Security implications

Codex could have various effects on the security landscape. Because Codex can produce vulnerable or misaligned code,333See Appendix G - Insecure Code for examples of Codex producing insecure code. qualified operators should review its generations before executing or trusting them, absent appropriate precautions. Future code generation models may be able to trained to produce more secure code than the average developer, though that is far from certain.

Codex could also be misused to aid cybercrime. Although this is worthy of concern, based on our testing, we believe that at their current level of capability, Codex models do not materially lower the barrier to entry for malware development.444For more on characterizing Codex’s capability limitations, see the Limitations section and experiments in the security analysis in Appendix G. We expect that more powerful code generation models will lead to future advancements, and therefore further research into mitigations and continued study of model capabilities are necessary.

The non-deterministic nature of systems like Codex could enable more advanced malware. This non-determinism makes it easier to create diverse software that accomplish the same tasks. While software diversity can sometimes aid defenders,555For example, by helping to prevent certain types of memory corruption vulnerabilities. See (Davis, 2018) for more. it presents unique challenges for traditional malware detection and antivirus systems that rely on fingerprinting and signature-matching against previously sampled binaries. For example, a more capable code generation model could conceivably advance techniques for generating polymorphic malware.666Polymorphic malware is malicious code that mutates its implementation while maintaining its function. We believe that application security and model deployment strategies including rate-limiting access and abuse monitoring can manage this threat in the near term; however, the efficacy of these mitigations may scale sublinearly as more capable models are developed.

Similar to large language models, Codex models can learn patterns present in their training data (Carlini et al., 2021). Sensitive data present in source code are liable to be predicted by the model. Because Codex is trained on public repositories, we consider any sensitive data present in the training data to have already been compromised. Similarly, the public data should generally be treated as untrusted, as previous work (Goldblum et al., 2021; Schuster et al., 2020) has found that attackers may be able to corrupt training data to trigger specific model behaviors at runtime. We further discuss security implications in Appendix G.

7.6 Environmental impacts

Codex, like other large generative models, has an energy footprint from both training and inference (Schwartz et al., 2019; Bender et al., 2021; Patterson et al., 2021). The original training of GPT-3-12B consumed hundreds of petaflop/s-days of compute, while fine-tuning it to create Codex-12B consumed a similar amount of compute. This training was performed on a platform (Azure) that purchases carbon credits and sources significant amounts of renewable energy, reducing its carbon footprint.777Microsoft made a commitment in 2020 to shift to 100 percent renewable energy supply in its buildings and data centers by 2025. A full assessment of the environmental impact of compute use is impossible to conduct without grounding in context and making comparison to the counterfactual impacts of competing products or services. Such analysis is out of scope for this paper. Compute consumption also has costs in the wider supply chain that can be quite concentrated on certain regions.888While data center energy usage has become much more efficient in recent years (Masanet et al., 2020), the production, use, and disposal of semiconductors still imposes environmental and human costs. See, e.g., (Crawford, 2021) Looking more globally and long-term, the compute demands of code generation could grow to be much larger than Codex’s training if significant inference is used to tackle challenging problems.999Given that code generation (and other forms of AI) might be deployed widely throughout the economy as discussed above, these considerations suggest additional urgency in adopting renewable energy.

7.7 Legal implications

There are several legal considerations related to generated code. To begin with, the training of AI systems on Internet data, such as public GitHub repositories, has previously been identified as an instance of “fair use” (O’Keefe et al., 2019).

Our preliminary research also finds that Codex models rarely generate code that is identical to the contents of training data. Such occurrences were 0.1% in a study examining the frequency of code generations that appear to match code snippets in the training data (Ziegler, 2021). In these rare instances, the generated code consisted of common expressions or conventions within the programming language that appeared over and over again in the training data. We find that, to the extent the generated code appears identical to the training data, it is due to the predictive weightings in the model rather than retention and copying of specific code.

Generated code is also responsive and customized to the user’s input, and the user retains complete control over editing and acceptance of the generated code. This can make code generation similar to auto-suggest or auto-completion features that exist as features of other tools of authorship (e.g., document editors), in the sense that the finished work is still seen as the author’s.

Our commitment to responsible and safe AI includes continued attention to the broader intellectual property implications of code generation systems. We intend to remain engaged with policymakers and experts on these issues so that the users of such systems can ultimately deploy them with confidence.

7.8 Risk mitigation

In closing, given the above, models like Codex should be developed, used, and their capabilities explored carefully with an eye towards maximizing their positive social impacts and minimizing intentional or unintentional harms that their use might cause. A contextual approach is critical to effective hazard analysis and mitigation, though a few broad categories of mitigations are important to consider in any deployment of code generation models.

Careful documentation and user interface design, code review requirements, and/or content controls (e.g., filtering of outputs) may help to reduce harms associated with over-reliance as well as offensive content or insecure code generation. In the context of a model made available as a service (e.g., via an API), policies such as user review, use case restrictions, monitoring, and/or rate limiting may also help to reduce harms associated with malicious use or prevent its use in high-stakes domains for which the models are not well suited.

Appendices E, F, G, and H provide further detail on the risks described in this section and outline additional mitigation and research opportunities.

8 Related Work

The deep learning resurgence has led to strong advances in the field of program learning. Two popular approaches to neural program learning are program induction and program synthesis.

In program induction, a model generates program outputs directly from a latent program representation. Learning to Execute (Zaremba and Sutskever, 2014)

demonstrated that models could execute simple tasks like addition and memorization, though they encountered difficulties with more general tasks. Later attempts at program induction incorporated inductive biases based on modern computing devices, such as the Neural Turing Machine

(Graves et al., 2014) and the Neural GPU (Kaiser and Sutskever, 2015).

In program synthesis, a model explicitly generates a program, usually from a natural language specification. One of the most popular classical approaches used a probabilistic context free grammar (PCFG) to generate a program’s abstract syntax tree (AST). Maddison and Tarlow (2014)

improved on this setup by learning a state vector used to condition child node expansion. Later,

Allamanis et al. (2015) applied this idea in text-to-code retrieval and Yin and Neubig (2017) utilized it in text-conditional code generation. Code2seq (Alon et al., 2018) found that ASTs could also be leveraged for code-to-text generation.

Programs can also be synthesized without passing through an AST representation. Hindle et al. (2012)

investigated n-gram language models of code, finding code to be more predictable than natural language. Latent Predictor Networks

(Ling et al., 2016) showed that character-level language models could generate working code for implementing Magic the Gathering cards in an online arena, when aided with a latent mode that allows card attributes to be copied into code. DeepCoder (Balog et al., 2017) trained a model to predict the functions appearing in source code, which could be used to guide program search.

Following the success of large natural language models (Devlin et al., 2018; Radford et al., 2019; Liu et al., 2019; Raffel et al., 2020; Brown et al., 2020) large scale Transformers have also been applied towards program synthesis. CodeBERT (Feng et al., 2020) trained the BERT objective on docstrings paired with functions, and obtained strong results on code search. PyMT5 (Clement et al., 2020) is similar in spirit to our work, and used the T5 objective to train a system which can translate between non-overlapping subsets of {signature, docstring, body}.

We used functional correctness to benchmark our models, and observed improvements on this metric with more sampling. SPoC (Kulal et al., 2019) considered the problem of producing functionally correct code from pseudocode with a fixed budget of compilations, which is similar to our pass@ metric. TransCoder (Lachaux et al., 2020) trained a system to translate between programming languages in an unsupervised manner, and also observed that functional correctness better captured the capabilities of their model than BLEU score. In fact, ContraCode (Jain et al., 2020) leveraged the large space of functionally correct programs to train a contrastive code model, which improved model performance on tasks like type inference. Finally, RobustFill (Devlin et al., 2017) observed that the best way to find a program consistent with input examples was to synthesize multiple samples through beam search.

Two early domain-specific datasets used to benchmark neural programming systems were FlashFill (Gulwani, 2011; Gulwani et al., 2012) and Hearthstone (Ling et al., 2016), though the community has trended towards broader and more difficult datasets. Barone and Sennrich (2017) proposed a large training and evaluation dataset consisting of Python declarations, docstrings, and bodies scraped from GitHub. The CodeSearchNet challenge (Husain et al., 2019) built an even larger corpus from GitHub with data from multiple popular programming languages. Recently, CodeXGLUE (Lu et al., 2021) aggregated several programming benchmarks, making use of the recently proposed CodeBLEU metric (Ren et al., 2020). Most relevant to our evaluation work is the APPS (Hendrycks et al., 2021) benchmark for measuring functional correctness based on problems from the competitive programming website Codeforces.

Finally, we note that coding is a broad activity which involves much more than synthesizing code from docstrings. Tufano et al. (2020) use Transformers to generate unit tests for code which outperformed commercial offerings. Aye et al. (2021) built an internal auto-complete tool for Facebook, and found that training on accepted user completions boosted system performance. Development also entails locating and fixing bugs. Early works used static or dynamic code analysis (Agrawal et al., 1995; Korel and Rilling, 1997), learned association rules (Jeffrey et al., 2009)

, and genetic programming

(Goues et al., 2012) to debug faulty code. These approaches relied on running against a test suite to not only evaluate the correctness of suggestions but also expose problems in execution trace or search for a solution. More recent works (Tufano et al., 2019; Drain et al., 2021)

considered bug-fixing as neural machine translation from buggy to correct programs. However, these works used an exact match against a reference instead of functional correctness, citing

Qi et al. (2015)’s finding that most of the proposed solutions by genetic search in (Goues et al., 2012) passed through weak test suites by deleting functionality that failed. Human developers often write test suites with limited but targeted coverage, but this does not always work well against an algorithm, highlighting the challenges of evaluating correctness of programs.

9 Conclusion

We investigated whether it was possible to train large language models to produce functionally correct code bodies from natural language docstrings. By fine-tuning GPT on code from GitHub, we found that our models displayed strong performance on a dataset of human-written problems with difficulty level comparable to easy interview problems. Model performance could be improved by training on a distribution more similar to the evaluation set, and also by producing multiple samples from a model. We also found that it was simple to train a model to complete the reverse task of producing docstrings from code bodies, and that the performance profiles of these models were similar. Finally, we expanded on the broader impacts of code generating models, and discussed model limitations, finding significant room for improvement.


We would like to sincerely thank Sandhini Agarwal, Casey Chu, Jeffrey Ding, Peter Eckersley, Gillian Hadfield, Rich Harang, Jacob Jackson, Yunxin Jiao, Jade Leung, Andrew Lohn, Ryan Lowe, Thomas McGuire, Margaret Mitchell, Florentine Eloundou Nekoul, Cullen O’Keefe, Long Ouyang, William Saunders, Pranav Shyam, Irene Solaiman, Aravind Srinivas, Helen Toner, Ashish Vaswani, and Jeffrey Wu for helpful discussions and feedback on drafts of this work. We are also grateful to the Acceleration and Supercomputing teams at OpenAI for their work on software and hardware infrastructure that this project used.


  • [1] (2017) A6:2017-security misconfiguration. OWASP. External Links: Link Cited by: footnote 24.
  • A. Abid, M. Farooqi, and J. Zou (2021) Persistent anti-muslim bias in large language models. arXiv preprint arXiv:2101.05783. Cited by: §7.3.
  • D. Acemoglu and P. Restrepo (2020a) Robots and jobs: evidence from us labor markets. Journal of Political Economy 128 (6), pp. 2188–2244. Cited by: §H.1.
  • D. Acemoglu and P. Restrepo (2020b)

    The wrong kind of ai? artificial intelligence and the future of labour demand

    Cambridge Journal of Regions, Economy and Society 13 (1), pp. 25–35. Cited by: §H.1.
  • H. Agrawal, J. R. Horgan, S. London, and W. E. Wong (1995) Fault localization using execution slices and dataflow tests. Proceedings of Sixth International Symposium on Software Reliability Engineering. ISSRE’95, pp. 143–151. Cited by: §8.
  • M. Allamanis, D. Tarlow, A. Gordon, and Y. Wei (2015) Bimodal modelling of source code and natural language. In Proceedings of the 32nd International Conference on Machine Learning, F. Bach and D. Blei (Eds.), Proceedings of Machine Learning Research, Vol. 37, Lille, France, pp. 2123–2132. External Links: Link Cited by: §8.
  • E. C. Alley, G. Khimulya, S. Biswas, M. AlQuraishi, and G. M. Church (2019) Unified rational protein engineering with sequence-based deep representation learning. Nature methods 16 (12), pp. 1315–1322. Cited by: §1.
  • U. Alon, S. Brody, O. Levy, and E. Yahav (2018) Code2seq: generating sequences from structured representations of code. In International Conference on Learning Representations, Cited by: §8.
  • G. A. Aye, S. Kim, and H. Li (2021) Learning autocompletion from real-world datasets. 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pp. 131–139. Cited by: §8.
  • A. Baevski, H. Zhou, A. Mohamed, and M. Auli (2020)

    Wav2vec 2.0: a framework for self-supervised learning of speech representations

    arXiv preprint arXiv:2006.11477. Cited by: §1.
  • M. Balog, A. Gaunt, M. Brockschmidt, S. Nowozin, and D. Tarlow (2017) DeepCoder: learning to write programs. In 5th International Conference on Learning Representations (ICLR), Cited by: §8.
  • H. Bao, L. Dong, and F. Wei (2021) BEiT: bert pre-training of image transformers. arXiv preprint arXiv:2106.08254. Cited by: §1.
  • A. V. M. Barone and R. Sennrich (2017) A parallel corpus of python functions and documentation strings for automated code documentation and code generation. ArXiv abs/1707.02275. Cited by: §8.
  • I. M. Barrington and A. Maciel (2000) Lecture 3: nondeterministic computation. Note:[Online; accessed 29-June-2000] Cited by: footnote 10.
  • E. M. Bender, T. Gebru, A. McMillan-Major, and S. Shmitchell (2021) On the dangers of stochastic parrots: can language models be too big?. In Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency, pp. 610–623. Cited by: §7.3, §7.6.
  • S. Black, L. Gao, P. Wang, C. Leahy, and S. Biderman (2021)

    GPT-Neo: large scale autoregressive language modeling with mesh-tensorflow

    External Links: Link Cited by: §3.4.
  • S. L. Blodgett, S. Barocas, H. Daumé III, and H. Wallach (2020) Language (technology) is power: a critical survey of “bias” in nlp. arXiv preprint arXiv:2005.14050. Cited by: Appendix F, §7.3.
  • T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert-Voss, G. Krueger, T. Henighan, R. Child, A. Ramesh, D. M. Ziegler, J. Wu, C. Winter, C. Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B. Chess, J. Clark, C. Berner, S. McCandlish, A. Radford, I. Sutskever, and D. Amodei (2020) Language models are few-shot learners. ArXiv abs/2005.14165. Cited by: Appendix F, §1, §3.2, §7.3, §8, footnote 16, footnote 17, footnote 21.
  • U.S. D. o. L. Bureau of Labor Statistics (2021a) BLS - software developers. Occupational Outlook Handbook. External Links: Link Cited by: footnote 2.
  • U.S. D. o. L. Bureau of Labor Statistics (2021b) Computer programmers. Occupational Outlook Handbook. External Links: Link Cited by: footnote 2.
  • N. Carlini, F. Tramèr, E. Wallace, M. Jagielski, A. Herbert-Voss, K. Lee, A. Roberts, T. Brown, D. Song, U. Erlingsson, A. Oprea, and C. Raffel (2021) Extracting training data from large language models. In 30th USENIX Security Symposium (USENIX Security 21), External Links: Link Cited by: §7.5, footnote 22.
  • M. Chen, A. Radford, R. Child, J. Wu, H. Jun, D. Luan, and I. Sutskever (2020) Generative pretraining from pixels. In International Conference on Machine Learning, pp. 1691–1703. Cited by: §1.
  • R. Child, S. Gray, A. Radford, and I. Sutskever (2019) Generating long sequences with sparse transformers. ArXiv abs/1904.10509. Cited by: §1.
  • P. Christiano (2018) Clarifying ”ai alignment”. AI Alignment Forum. External Links: Link Cited by: §E.1.
  • M. R. Clarkson, B. Finkbeiner, M. Koleini, K. K. Micinski, M. N. Rabe, and C. Sánchez (2014) Temporal logics for hyperproperties. In International Conference on Principles of Security and Trust, pp. 265–284. Cited by: 4th item.
  • C. Clement, D. Drain, J. Timcheck, A. Svyatkovskiy, and N. Sundaresan (2020) PyMT5: multi-mode translation of natural language and python code with transformers. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pp. 9052–9065. Cited by: §1, §8.
  • K. Crawford (2017) The trouble with bias. NIPS 2017 Keynote. External Links: Link Cited by: footnote 13.
  • K. Crawford (2021) Atlas of ai: power, politics, and the planetary costs of artificial intelligence. Yale University Press. Cited by: footnote 8.
  • [29] (2006) CWE-327: use of a broken or risky cryptographic algorithm. MITRE. External Links: Link Cited by: footnote 24.
  • [30] (2009) CWE-780: use of rsa algorithm without oaep. MITRE. External Links: Link Cited by: footnote 24.
  • A. M. Dai and Q. V. Le (2015) Semi-supervised sequence learning. Advances in neural information processing systems 28, pp. 3079–3087. Cited by: §1.
  • A. Das, S. Kottur, K. Gupta, A. Singh, D. Yadav, J. M. Moura, D. Parikh, and D. Batra (2017) Visual dialog. In

    Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition

    pp. 326–335. Cited by: §1.
  • B. Davis (2018) Protecting applications with automated software diversity. External Links: Link Cited by: footnote 5.
  • J. Devlin, J. Uesato, S. Bhupatiraju, R. Singh, A. Mohamed, and P. Kohli (2017) RobustFill: neural program learning under noisy i/o. In ICML, Cited by: §8.
  • J. Devlin, M. Chang, K. Lee, and K. Toutanova (2018) Bert: pre-training of deep bidirectional transformers for language understanding. arXiv preprint arXiv:1810.04805. Cited by: §1, §8.
  • P. Dhariwal, H. Jun, C. Payne, J. W. Kim, A. Radford, and I. Sutskever (2020) Jukebox: a generative model for music. arXiv preprint arXiv:2005.00341. Cited by: §1.
  • D. Drain, C. Wu, A. Svyatkovskiy, and N. Sundaresan (2021) Generating bug-fixes using pretrained transformers. Proceedings of the 5th ACM SIGPLAN International Symposium on Machine Programming. Cited by: §8.
  • N. Eghbal (2020) Working in public: the making and maintenance of open source software. Stripe Press. Cited by: §H.4.
  • Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang, et al. (2020) CodeBERT: a pre-trained model for programming and natural languages. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pp. 1536–1547. Cited by: §1, §8.
  • C. B. Frey (2019) The technology trap. Princeton University Press. Cited by: §H.1.
  • L. Gao, S. Biderman, S. Black, L. Golding, T. Hoppe, C. Foster, J. Phang, H. He, A. Thite, N. Nabeshima, S. Presser, and C. Leahy (2020) The pile: an 800gb dataset of diverse text for language modeling. External Links: arXiv:2101.00027 Cited by: §1, §3.4.
  • M. Goldblum, D. Tsipras, C. Xie, X. Chen, A. Schwarzschild, D. Song, A. Madry, B. Li, and T. Goldstein (2021) Dataset security for machine learning: data poisoning, backdoor attacks, and defenses. External Links: 2012.10544 Cited by: §7.5.
  • C. L. Goues, M. Dewey-Vogt, S. Forrest, and W. Weimer (2012) A systematic study of automated program repair: fixing 55 out of 105 bugs for $8 each. 2012 34th International Conference on Software Engineering (ICSE), pp. 3–13. Cited by: §8.
  • A. Graves, G. Wayne, and I. Danihelka (2014)

    Neural turing machines

    arXiv preprint arXiv:1410.5401. Cited by: §8.
  • A. Graves (2014)

    Generating sequences with recurrent neural networks

    External Links: 1308.0850 Cited by: §1.
  • S. Gulwani, W. R. Harris, and R. Singh (2012) Spreadsheet data manipulation using examples. Commun. ACM 55, pp. 97–105. Cited by: §8.
  • S. Gulwani (2011) Automating string processing in spreadsheets using input-output examples. In PoPL’11, January 26-28, 2011, Austin, Texas, USA, Cited by: §6, §8.
  • P. He, X. Liu, J. Gao, and W. Chen (2020) Deberta: decoding-enhanced bert with disentangled attention. arXiv preprint arXiv:2006.03654. Cited by: §E.4.
  • T. Helmuth and L. Spector (2015) General program synthesis benchmark suite. In

    Proceedings of the 2015 Annual Conference on Genetic and Evolutionary Computation

    pp. 1039–1046. Cited by: Appendix D, §6.
  • D. Hendrycks, S. Basart, S. Kadavath, M. Mazeika, A. Arora, E. Guo, C. Burns, S. Puranik, H. He, D. Song, et al. (2021) Measuring coding challenge competence with apps. arXiv preprint arXiv:2105.09938. Cited by: §2.2, §3.5, §8.
  • A. Hindle, E. T. Barr, Z. Su, M. Gabel, and P. Devanbu (2012) On the naturalness of software. In 2012 34th International Conference on Software Engineering (ICSE), pp. 837–847. Cited by: §8.
  • A. Holtzman, J. Buys, L. Du, M. Forbes, and Y. Choi (2020) The curious case of neural text degeneration. External Links: 1904.09751 Cited by: §3.2.
  • H. Husain, H. Wu, T. Gazit, M. Allamanis, and M. Brockschmidt (2019) CodeSearchNet challenge: evaluating the state of semantic code search. ArXiv abs/1909.09436. Cited by: §1, §8.
  • P. Jain, A. Jain, T. Zhang, P. Abbeel, J. Gonzalez, and I. Stoica (2020) Contrastive code representation learning. ArXiv abs/2007.04973. Cited by: §8.
  • D. Jeffrey, M. Feng, N. Gupta, and R. Gupta (2009) BugFix: a learning-based tool to assist developers in fixing bugs. 2009 IEEE 17th International Conference on Program Comprehension, pp. 70–79. Cited by: §8.
  • C. Jones and O. Bonsignour (2011) The economics of software quality. Addison-Wesley Professional. Cited by: 2nd item.
  • Ł. Kaiser and I. Sutskever (2015) Neural gpus learn algorithms. arXiv preprint arXiv:1511.08228. Cited by: §8.
  • J. Kaplan, S. McCandlish, T. Henighan, T. B. Brown, B. Chess, R. Child, S. Gray, A. Radford, J. Wu, and D. Amodei (2020) Scaling laws for neural language models. External Links: 2001.08361 Cited by: §3.3.
  • Z. Kenton, T. Everitt, L. Weidinger, I. Gabriel, V. Mikulik, and G. Irving (2021) Alignment of language agents. arXiv preprint arXiv:2103.14659. Cited by: §E.1, §E.4.
  • N. S. Keskar, B. McCann, L. R. Varshney, C. Xiong, and R. Socher (2019) CTRL: a conditional transformer language model for controllable generation. External Links: 1909.05858 Cited by: §E.4.
  • B. Korel and J. Rilling (1997) Application of dynamic slicing in program debugging. In AADEBUG, Cited by: §8.
  • J. R. Koza, D. Andre, M. A. Keane, and F. H. Bennett III (1999) Genetic programming iii: darwinian invention and problem solving. Vol. 3, Morgan Kaufmann. Cited by: Appendix D.
  • S. Kulal, P. Pasupat, K. Chandra, M. Lee, O. Padon, A. Aiken, and P. S. Liang (2019) SPoC: search-based pseudocode to code. In Advances in Neural Information Processing Systems, H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alché-Buc, E. Fox, and R. Garnett (Eds.), Vol. 32, pp. . External Links: Link Cited by: Appendix A, §2.1, §2.1, §8.
  • N. Lacasse (2018) Open-sourcing gvisor, a sandboxed container runtime. May. Cited by: §2.3.
  • M. Lachaux, B. Rozière, L. Chanussot, and G. Lample (2020) Unsupervised translation of programming languages. ArXiv abs/2006.03511. Cited by: §2.1, §8.
  • N. Leveson (2019) Improving the standard risk matrix: part 1. External Links: Link Cited by: §7.
  • P. L. Li, A. J. Ko, and A. Begel (2020) What distinguishes great software engineers?. Empirical Software Engineering 25 (1), pp. 322–352. Cited by: §H.1, footnote 2.
  • W. Ling, P. Blunsom, E. Grefenstette, K. M. Hermann, T. Kočiskỳ, F. Wang, and A. Senior (2016) Latent predictor networks for code generation. In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (ACL), pp. 599–609. Cited by: §8, §8.
  • Y. Liu, M. Ott, N. Goyal, J. Du, M. Joshi, D. Chen, O. Levy, M. Lewis, L. Zettlemoyer, and V. Stoyanov (2019) RoBERTa: a robustly optimized bert pretraining approach. ArXiv abs/1907.11692. Cited by: §8.
  • J. Lu, D. Batra, D. Parikh, and S. Lee (2019) Vilbert: pretraining task-agnostic visiolinguistic representations for vision-and-language tasks. arXiv preprint arXiv:1908.02265. Cited by: §1.
  • S. Lu, D. Guo, S. Ren, J. Huang, A. Svyatkovskiy, A. Blanco, C. Clement, D. Drain, D. Jiang, D. Tang, G. Li, L. Zhou, L. Shou, L. Zhou, M. Tufano, M. Gong, M. Zhou, N. Duan, N. Sundaresan, S. K. Deng, S. Fu, and S. Liu (2021) CodeXGLUE: a machine learning benchmark dataset for code understanding and generation. ArXiv abs/2102.04664. Cited by: §8.
  • C. J. Maddison and D. Tarlow (2014) Structured generative models of natural source code. In Proceedings of the 31st International Conference on International Conference on Machine Learning (ICML), pp. II–649. Cited by: §8.
  • Z. Manna and R. J. Waldinger (1971) Toward automatic program synthesis. 14 (3), pp. 151–165. External Links: ISSN 0001-0782, Link, Document Cited by: §1.
  • E. Masanet, A. Shehabi, N. Lei, S. Smith, and J. Koomey (2020) Recalibrating global data center energy-use estimates. Science 367 (6481), pp. 984–986. Cited by: footnote 8.
  • A.J. Menezes, P.C. van Oorschot, and S.A. Vanstone (2018) Handbook of applied cryptography. Discrete Mathematics and Its Applications, CRC Press. External Links: ISBN 9780429881329, Link Cited by: footnote 25.
  • J. Menick and N. Kalchbrenner (2018) Generating high fidelity images with subscale pixel networks and multidimensional upscaling. External Links: 1812.01608 Cited by: §1.
  • T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, and J. Dean (2013) Distributed representations of words and phrases and their compositionality. In Advances in neural information processing systems, pp. 3111–3119. Cited by: §1.
  • C. O’Keefe, D. Lansky, J. Clark, and C. Payne (2019) Comment regarding request for comments on intellectual property protection for artificial intelligence innovation. Before the United States Patent and Trademark Office Department of Commerce. External Links: Link Cited by: §7.7.
  • M. O’Neill and L. Spector (2019) Automatic programming: the open issue?. Genetic Programming and Evolvable Machines, pp. 1–12. Cited by: Appendix D.
  • O*NET (2021) 15-1252.00 - software developers. National Center for O*NET Development. External Links: Link Cited by: §H.1, §7.4.
  • M. Ohm, H. Plate, A. Sykosch, and M. Meier (2020) Backstabber’s knife collection: a review of open source software supply chain attacks. External Links: 2005.09535 Cited by: §G.2.
  • A. v. d. Oord, S. Dieleman, H. Zen, K. Simonyan, O. Vinyals, A. Graves, N. Kalchbrenner, A. Senior, and K. Kavukcuoglu (2016) Wavenet: a generative model for raw audio. arXiv preprint arXiv:1609.03499. Cited by: §1.
  • A. v. d. Oord, Y. Li, and O. Vinyals (2018) Representation learning with contrastive predictive coding. arXiv preprint arXiv:1807.03748. Cited by: §1.
  • E. Pantridge, T. Helmuth, N. F. McPhee, and L. Spector (2017) On the difficulty of benchmarking inductive program synthesis methods. In Proceedings of the Genetic and Evolutionary Computation Conference Companion, pp. 1589–1596. Cited by: Appendix D, §6.
  • D. Patterson, J. Gonzalez, Q. Le, C. Liang, L. Munguia, D. Rothchild, D. So, M. Texier, and J. Dean (2021)

    Carbon emissions and large neural network training

    arXiv preprint arXiv:2104.10350. Cited by: §7.6.
  • M. E. Peters, M. Neumann, M. Iyyer, M. Gardner, C. Clark, K. Lee, and L. Zettlemoyer (2018) Deep contextualized word representations. arXiv preprint arXiv:1802.05365. Cited by: §1.
  • S. Planning (2002) The economic impacts of inadequate infrastructure for software testing. National Institute of Standards and Technology. Cited by: 2nd item.
  • Python Software Foundation and JetBrains (2020) Python developers survey 2020 results. External Links: Link Cited by: footnote 26.
  • Z. Qi, F. Long, S. Achour, and M. Rinard (2015) An analysis of patch plausibility and correctness for generate-and-validate patch generation systems. Proceedings of the 2015 International Symposium on Software Testing and Analysis. Cited by: §8.
  • A. Radford, J. W. Kim, C. Hallacy, A. Ramesh, G. Goh, S. Agarwal, G. Sastry, A. Askell, P. Mishkin, J. Clark, et al. (2021) Learning transferable visual models from natural language supervision. arXiv preprint arXiv:2103.00020. Cited by: Appendix F.
  • A. Radford, K. Narasimhan, T. Salimans, and I. Sutskever (2018) Improving language understanding by generative pre-training. Cited by: §1.
  • A. Radford, J. Wu, R. Child, D. Luan, D. Amodei, and I. Sutskever (2019) Language models are unsupervised multitask learners. Cited by: §8.
  • C. Raffel, N. M. Shazeer, A. Roberts, K. Lee, S. Narang, M. Matena, Y. Zhou, W. Li, and P. J. Liu (2020)

    Exploring the limits of transfer learning with a unified text-to-text transformer

    ArXiv abs/1910.10683. Cited by: §E.4, §1, §8.
  • A. Ramesh, M. Pavlov, G. Goh, S. Gray, C. Voss, A. Radford, M. Chen, and I. Sutskever (2021) Zero-shot text-to-image generation. ArXiv abs/2102.12092. Cited by: §1, §6.
  • S. Ren, D. Guo, S. Lu, L. Zhou, S. Liu, D. Tang, N. Sundaresan, M. Zhou, A. Blanco, and S. Ma (2020) Codebleu: a method for automatic evaluation of code synthesis. arXiv preprint arXiv:2009.10297. Cited by: §2.1, §8.
  • A. Rives, J. Meier, T. Sercu, S. Goyal, Z. Lin, J. Liu, D. Guo, M. Ott, C. L. Zitnick, J. Ma, et al. (2021)

    Biological structure and function emerge from scaling unsupervised learning to 250 million protein sequences

    Proceedings of the National Academy of Sciences 118 (15). Cited by: §1.
  • M. O. F. Rokon, R. Islam, A. Darki, E. E. Papalexakis, and M. Faloutsos (2020) SourceFinder: finding malware source-code from publicly available repositories in github. In 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020), San Sebastian, pp. 149–163. External Links: ISBN 978-1-939133-18-2, Link Cited by: §2.3.
  • R. Schuster, C. Song, E. Tromer, and V. Shmatikov (2020) You autocomplete me: poisoning vulnerabilities in neural code completion. The Advanced Computing Systems Association. External Links: Link Cited by: §7.5, footnote 23.
  • R. Schwartz, J. Dodge, N. A. Smith, and O. Etzioni (2019) Green ai. External Links: 1907.10597 Cited by: §7.6.
  • H. A. Simon (1963) Experiments with a heuristic compiler. J. ACM 10 (4), pp. 493–506. External Links: ISSN 0004-5411, Link, Document Cited by: §1.
  • Stack Overflow (2020) 2020 developer survey. External Links: Link Cited by: footnote 26.
  • N. Stiennon, L. Ouyang, J. Wu, D. M. Ziegler, R. Lowe, C. Voss, A. Radford, D. Amodei, and P. Christiano (2020) Learning to summarize from human feedback. External Links: 2009.01325 Cited by: §E.4.
  • I. Sutskever, O. Vinyals, and Q. V. Le (2014) Sequence to sequence learning with neural networks. In Advances in neural information processing systems, pp. 3104–3112. Cited by: §1.
  • B. Trinkenreich, I. Wiese, A. Sarma, M. Gerosa, and I. Steinmacher (2021) Women’s participation in open source software: a survey of the literature. arXiv preprint arXiv:2105.08777. Cited by: §H.4.
  • M. Tufano, D. Drain, A. Svyatkovskiy, S. K. Deng, and N. Sundaresan (2020) Unit test case generation with transformers and focal context. Cited by: §8.
  • M. Tufano, C. Watson, G. Bavota, M. D. Penta, M. White, and D. Poshyvanyk (2019) An empirical study on learning bug-fixing patches in the wild via neural machine translation. ACM Transactions on Software Engineering and Methodology (TOSEM) 28, pp. 1 – 29. Cited by: §8.
  • A. Van Oord, N. Kalchbrenner, and K. Kavukcuoglu (2016) Pixel recurrent neural networks. In International Conference on Machine Learning, pp. 1747–1756. Cited by: §1.
  • A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin (2017) Attention is all you need. In Advances in Neural Information Processing Systems, I. Guyon, U. V. Luxburg, S. Bengio, H. Wallach, R. Fergus, S. Vishwanathan, and R. Garnett (Eds.), Vol. 30, pp. . External Links: Link Cited by: §1.
  • B. Wang and A. Komatsuzaki (2021) GPT-J-6B: A 6 Billion Parameter Autoregressive Language Model. Note: Cited by: §1, §1, §3.4.
  • M. Woolf (2021) Fun and dystopia with ai-based code generation using gpt-j-6b. External Links: Link Cited by: §3.4.
  • F. F. Xu, B. Vasilescu, and G. Neubig (2021) In-ide code generation from natural language: promise and challenges. arXiv preprint arXiv:2101.11149. Cited by: Appendix D, 3rd item, §H.3, §6.
  • P. Yin and G. Neubig (2017) A syntactic neural model for general-purpose code generation. In Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (ACL), pp. 440–450. Cited by: §8.
  • W. Zaremba and I. Sutskever (2014) Learning to execute. arXiv preprint arXiv:1410.4615. Cited by: §8.
  • R. Zellers, X. Lu, J. Hessel, Y. Yu, J. S. Park, J. Cao, A. Farhadi, and Y. Choi (2021) MERLOT: multimodal neural script knowledge models. arXiv preprint arXiv:2106.02636. Cited by: §1.
  • T. Z. Zhao, E. Wallace, S. Feng, D. Klein, and S. Singh (2021) Calibrate before use: improving few-shot performance of language models. arXiv preprint arXiv:2102.09690. Cited by: §H.1.
  • A. Ziegler (2021) A first look at rote learning in github copilot suggestions.. GitHub. External Links: Link Cited by: §7.7.

Appendix A Estimating pass@

While all estimators mentioned previously are consistent, only the empirical estimate used by Kulal et al. (2019), and (1) are unbiased. Evaluating pass@ in an unbiased way with any number of samples is important for fair comparison. For example, estimating with using the empirical pass@1, results in a consistent underestimate as shown in Figure 13. The gap doesn’t fully close even when , and results can seem better with more samples. The interpretation of this estimator is that we draw samples with replacement from a pool of candidates, but the samples are not independent.

Figure 13: Comparing the amount of bias and variance of two estimators of pass@. While the top expression may look correct, it underestimates the true value by a considerable margin. The unbiased estimator may have a slightly higher variance initially but allows for a fair comparison across different numbers of samples.

(1) is unbiased, because it estimates the fail probability as the probability of drawing failed samples without replacement. To show this, note that , the number of correct samples that pass the unit tests, is distributed , where is pass@1, and that (1) evaluates to 1 when . Then,

Appendix B Random Problems and Solutions from Codex-12B

We show 8 random problems from HumanEval along with 8 random samples per problem generated from Codex-12B at temperature 0.8.

def words_string(s):
␣␣␣␣words_string("Hi, my name is John")==["Hi","my","name","is","John"]
␣␣␣␣words_string("One, two, three, four, five, six")==["One","two","three","four","five","six"]
    ### COMPLETION 1 (CORRECT): ###
    words = []
    splitted_word = ""
    for char in s:
        if char == "":
            if splitted_word != "":
                splitted_word = ""
        elif char != ",":
            splitted_word += char
    if splitted_word != "":
    return words
    ### COMPLETION 2 (WRONG): ###
    return s.split()
    ### COMPLETION 3 (WRONG): ###
    words = s.split("")
    words = [w.strip(",") for w in words]
    words = [w.strip() for w in words]
    return words
    ### COMPLETION 4 (WRONG): ###
    # Split the string into words
    words = s.split(’,’)
    # Remove any whitespace around each element
    words = [w.strip() for w in words]
    # Return an array of the words in the string
    return words
    ### COMPLETION 5 (WRONG): ###
    return s.split()
    ### COMPLETION 6 (WRONG): ###
    return s.split()
    ### COMPLETION 7 (WRONG): ###
    return s.split(’,’)
    ### COMPLETION 8 (WRONG): ###
    return s.split(sep=None)
def is_prime(n):
    ### COMPLETION 1 (WRONG): ###
    for i in range(2, n):
        if n % i == 0:
            return False
    return True
    ### COMPLETION 2 (WRONG): ###
    for i in range(2, n):
        if n % i == 0:
            return False
    return True
    ### COMPLETION 3 (WRONG): ###
    # TODO: implement this function
    ### COMPLETION 4 (CORRECT): ###
    if n < 2: return False
    if n == 2: return True
    if n%2 == 0: return False
    return not any(n%k == 0 for k in range(3,int(n**0.5)+1,2))
    ### COMPLETION 5 (WRONG): ###
    def helper(n):
        # check if an odd number is multiple of any integer up to the square root of the number
        # if this is true, n is not prime
        for i in range(2, int(n**0.5 + 1)):
            if n % i == 0:
                return False
        return True
    # if helper returns true, then n is prime, else n is not prime
    if helper(n):
        return True
        return False
    ### COMPLETION 6 (CORRECT): ###
    prime = True
    if n == 1:
        return False
    for i in range(2, n):
        if n % i == 0:
            prime = False
    return prime
    ### COMPLETION 7 (WRONG): ###
    for i in range(2, n):
        if n % i == 0:
            return False
    return True
    ### COMPLETION 8 (CORRECT): ###
    if n == 2 or n == 3:
        return True
    if n < 2 or n % 2 == 0:
        return False
    if n < 9:
        return True
    if n % 3 == 0:
        return False
    r = int(n**0.5)
    f = 5
    while f <= r:
        if n % f == 0:
            return False
        if n % (f+2) == 0:
            return False
        f += 6
    return True
def add_elements(arr, k):
    ### COMPLETION 1 (WRONG): ###
    ### COMPLETION 2 (WRONG): ###
    for i in range(0, k):
        if len(str(arr[i])) < 3:
            k = k - 1
            return arr[i]
    ### COMPLETION 3 (WRONG): ###
    sum_ = 0
    i = 0
    while k > 0 and i < len(arr):
        if len(str(arr[i])) <= 2:
            sum_ += arr[i]
            k -= 1
        i += 1
    return sum_
    ### COMPLETION 4 (WRONG): ###
    size = len(arr)
    if k > size:
        return None
    start = k * -1 - 1
    end = k * -1
    arr = arr[start:end]
    return sum(arr)
    ### COMPLETION 5 (CORRECT): ###
    if k <= len(arr):
        sum = 0
        for i in range(k):
            if len(str(arr[i])) <= 2:
                sum += arr[i]
        return sum
        return "Numberofelementsarelessthank"
    ### COMPLETION 6 (WRONG): ###
    ### COMPLETION 7 (WRONG): ###
    return int(str(sum(arr[:k]))[:k+1])
    ### COMPLETION 8 (WRONG): ###
    global_sum = 0
    for i in range(0, k):
        if i == 0:
            global_sum = arr[0]
            if len(str(arr[i])) <= 2:
                global_sum += arr[i]
    return global_sum
def vowels_count(s):
    ### COMPLETION 1 (WRONG): ###
    vowels = "aeiou"
    v = 0
    for i in s:
        if i in vowels:
            v += 1
    return v
    ### COMPLETION 2 (WRONG): ###
    vowels_set = {’a’, ’e’, ’i’, ’o’, ’u’, ’y’}
    count = 0
    for c in s:
        if c in vowels_set:
            count += 1
    return count
    ### COMPLETION 3 (WRONG): ###
    vowels_list = [’a’, ’e’, ’i’, ’o’, ’u’, ’y’]
    vowels_count = 0
    for char in s:
        if char in vowels_list:
            vowels_count += 1
    return vowels_count
    ### COMPLETION 4 (WRONG): ###
    return 0
    ### COMPLETION 5 (WRONG): ###
    vowels = ["a", "e", "i", "o", "u", "y"]
    num_vowels = 0
    for i in range(len(s)):
        if s[i] in vowels:
            num_vowels += 1
    return num_vowels
    ### COMPLETION 6 (WRONG): ###
    vowels = "aeiou"
    return sum(vowels.count(i) for i in s)
    ### COMPLETION 7 (WRONG): ###
    vowels = 0
    for c in s:
        if c in [’a’, ’e’, ’i’, ’o’, ’u’, ’y’]:
            vowels += 1
    return vowels
    ### COMPLETION 8 (WRONG): ###
    vowels = "aeiou"
    count = 0
    for letter in s:
        if letter in vowels:
            count += 1
    return count
def multiply(a, b):
    ### COMPLETION 1 (WRONG): ###
    if a == 0 or b == 0:
        return 0
    elif a < b:
        return (a - b) * 10
    elif a > b:
        return (a - b) * 10 + b
        return (a - b) * 10 + b
    ### COMPLETION 2 (WRONG): ###
    #return sum([a * b for a, b in zip(str(a), str(b))])
    return sum(a*b for a, b in zip(str(a), str(b)))
    ### COMPLETION 3 (WRONG): ###
    # Edge case: a and b are both 0. Return 1.
    if a == 0 and b == 0:
        return 1
    # Convert to strings so we can convert digits to characters
    a_str = str(a)
    b_str = str(b)
    # Initialize carry
    carry = 0
    # Initialize result to be empty
    result = ""
    # Loop through each digit in both numbers
    for digit in a_str:
        # Get the digit at this index
        digit = int(digit)
        for digit_2 in b_str:
            # Get the digit at this index
            digit_2 = int(digit_2)
            # Perform the calculation
            curr_sum = digit * digit_2 + carry
            # Append new digit to result
            result = result + str(curr_sum % 10)
            # If there’s a carry, add to carry
            carry = curr_sum // 10
        # Keep track of carry to do sum over
        carry = carry
    ### COMPLETION 4 (WRONG): ###
    result = 0
    for i in range(0, min(len(str(a)), len(str(b)))):
        result += abs(a//10**i - b//10**i) * 10**i
    return result
    ### COMPLETION 5 (WRONG): ###
    prod = [0, 0]
    for i in [0,1]:
        for j in [0,1]:
            if a % 10 != 0:
                prod[i] += a % 10 * b % 10
            a = a // 10
            b = b // 10
    return prod[0] * 10 + prod[1]
    ### COMPLETION 6 (WRONG): ###
    if a < 0 or b < 0:
        a = abs(a)
        b = abs(b)
    res = 0
    a = list(str(a))
    b = list(str(b))
    a = reversed(a)
    b = reversed(b)
    print(a, b)
    for i in range(len(a)):
        res += int(a[i]) * int(b[i]) * 10**i
    return res
    ### COMPLETION 7 (WRONG): ###
    # Write your code here.
    a = abs(a)
    b = abs(b)
    result = 0
    power = 0
    while a > 0:
        a_digit = a % 10
        a //= 10
        b_digit = b % 10
        b //= 10
        result += (a_digit * b_digit) * (10 ** power)
        power += 1
    if b < 0:
        return 0 - result
    return result
    ### COMPLETION 8 (WRONG): ###
    number = a*b
    string = str(number)
    total = 0
    for i in string:
        total += int(i)
    return total
def even_odd_palindrome(n):
    ### COMPLETION 1 (WRONG): ###
    if n == 1:
        return 0, 0
    elif n == 0:
        return 0, 0
        return (1 + 2 * (n % 2), 2 * (n - 1))
    ### COMPLETION 2 (WRONG): ###
    count_even = 0
    count_odd = 0
    for i in range(1, n+1):
        s = str(i)
        if s == s[::-1]:
            count_even += 1
        if s == s[::-1][1:]:
            count_odd += 1
    return (count_even, count_odd)
    ### COMPLETION 3 (WRONG): ###
    # Declare list and dict to save the count of palindrome
    count_even = [0, 0]
    count_odd = [0, 0]
    palindrome_dict = {
        ’1’: [0, 0],
        ’2’: [0, 1],
        ’3’: [0, 1],
        ’4’: [0, 2],
        ’5’: [0, 2],
    ### COMPLETION 4 (CORRECT): ###
    even_count = 0
    odd_count = 0
    for i in range(1, n+1):
        if str(i) == str(i)[::-1]:
            if i % 2 == 0:
                even_count += 1
                odd_count += 1
    return (even_count, odd_count)
    ### COMPLETION 5 (CORRECT): ###
    even_pal = 0
    odd_pal = 0
    for x in range(1, n + 1):
        if str(x) == str(x)[::-1]:
            if x % 2 == 0:
                even_pal += 1
                odd_pal += 1
    return even_pal, odd_pal
    ### COMPLETION 6 (CORRECT): ###
    even, odd = 0, 0
    for i in range(1, n+1):
        if str(i) == str(i)[::-1]:
            if int(str(i)[::-1]) % 2 == 0:
                even += 1
                odd += 1
    return even, odd
    ### COMPLETION 7 (WRONG): ###
    even, odd = 0, 0
    for num in range(1, n+1):
        if is_palindrome(num):
            if is_odd(num):
                odd += 1
            elif is_even(num):
                even += 1
    return (even, odd)
    ### COMPLETION 8 (WRONG): ###
    evens = [i for i in range(1, n) if i % 2 == 0]
    odds = [i for i in range(1, n) if i % 2 != 0]
    return (len(evens), len(odds))
def longest(strings: List[str]) -> Optional[str]:
    ### COMPLETION 1 (CORRECT): ###
    return max(strings, key=len) if strings else None
    ### COMPLETION 2 (WRONG): ###
    if not strings:
        return None
    strings = sorted(strings, key=len)
    return strings[-1]
    ### COMPLETION 3 (WRONG): ###
    longest_string = strings[0]
    # if len(strings) > 1:
    #     # longest_string = ’’
    #     longest_string = max(strings, key=lambda a: len(a))
    # else:
    #     return strings[0]
    for s in strings:
        if len(s) > len(longest_string):
            longest_string = s
    return longest_string
    ### COMPLETION 4 (WRONG): ###
    if not strings:
        return None
        return sorted(strings)[-1]
    ### COMPLETION 5 (CORRECT): ###
    lengths = [len(string) for string in strings]
    if len(lengths) == 0:
        return None
    max_length = max(lengths)
    max_indices = [i for i, v in enumerate(lengths) if v == max_length]
    if len(max_indices) == 1:
        return strings[max_indices[0]]
        return strings[max_indices[0]]
    ### COMPLETION 6 (CORRECT): ###
    if not strings:
        return None
    return max(strings, key=len)
    ### COMPLETION 7 (WRONG): ###
    lens = [len(s) for s in strings]
    i = max(lens)
    return strings[lens.index(i)] if lens else None
    ### COMPLETION 8 (WRONG): ###
    if strings is None:
        return None
    longest_so_far = strings[0]
    for s in strings:
        if len(s) > len(longest_so_far):
            longest_so_far = s
    return longest_so_far
def x_or_y(n, x, y):
    ### COMPLETION 1 (WRONG): ###
    return x if n % x == 0 else y
    ### COMPLETION 2 (WRONG): ###
    if n > 1:
        return x if n%2 != 0 else y
        return "Error"
    ### COMPLETION 3 (WRONG): ###
    if n%x == 0:
        return x
        return y
    ### COMPLETION 4 (WRONG): ###
    return x if n % x == 0 else y
    ### COMPLETION 5 (WRONG): ###
    if n < x:
        return n
        return y
    ### COMPLETION 6 (WRONG): ###
    for i in range(2,n-1):
        if (n % i == 0):
            return y
    return x
    ### COMPLETION 7 (WRONG): ###
    if n == 2:
        return x
    elif n == 3:
        return y
        return x_or_y(n-1, x, y)
    ### COMPLETION 8 (WRONG): ###
    if n == x:
        return x
    elif n == y:
        return y
        return n

Appendix C Building Blocks for Synthetic Tasks

We describe the 13 building blocks used to create synthetic tasks for evaluating model performance as a function of docstring complexity. Each building block is specified by a line of text and a line of code:

  1. “remove all instances of the letter e from the string”

        s = s.replace("e", "")
  2. “replace all spaces with exclamation points in the string”

        s = s.replace("", "!")
  3. “convert the string s to lowercase”

        s = s.lower()
  4. “remove the first and last two characters of the string”

        s = s[2:-2]
  5. “removes all vowels from the string”

        s = "".join(char for char in s if char not in "aeiouAEIOU")
  6. “remove every third character from the string”

        s = "".join(char for i, char in enumerate(s) if i % 3 != 0)
  7. “drop the last half of the string, as computed by characters”

        s = s[: len(s) // 2]
  8. “replace spaces with triple spaces”

        s = s.replace("", "␣␣␣")
  9. “reverse the order of words in the string”

        s = "".join(s.split()[::-1])
  10. “drop the first half of the string, as computed by number of words”

        s = "".join(s.split()[len(s.split()) // 2 :])
  11. “add the word apples after every word in the string”

        s = "".join(word + "apples" for word in s.split())
  12. “make every other character in the string uppercase”

        s = "".join(char.upper() if i % 2 == 0 else char for i, char in enumerate(s))
  13. “delete all exclamation points, question marks, and periods from the string”

        s = "".join([x for x in s if x not in ".!?"])

These building blocks can be easily composed by concatenating their one-line descriptions into a docstring and by concatenating their one-line implementations into a code body. An example is shown below:

def string_manipulation(s: str):
    s = "".join(char.upper() if i % 2 == 0 else char for i, char in enumerate(s))
    s = s.replace("", "␣␣␣")
    return s

Appendix D Details of Specification-based Evaluation Framework

Evaluating the capabilities of code synthesis and generation is not a novel problem and has been explored in both the ML (Xu et al., 2021) and synthesis (Helmuth and Spector, 2015; Pantridge et al., 2017) communities. Previously, researchers have recommended the use of existing metrics such as McCabe Cyclomatic Complexity (CC). That is, synthesis and generation metrics have largely concentrated on analyzing the correctness and complexity of the code output rather than the expressivity and complexity of the specification itself. Yet, evaluating the output of synthesized code is moot if there is no specification that it can be measured against. Indeed, the synthesis and automatic programming community (O’Neill and Spector, 2019) have recently called for principled benchmarks and grand challenge problems to be made in order to adopt a scientifically rigorous approach to compare synthesis methodologies against.

If we wish to understand the performance of generation and synthesis models relative to human ability, we should evaluate them against the complexity and expressivity of specification prompts, and assess their capability to understand and execute them. Given the ambiguity of natural language specifications, the challenge arises in how to define an appropriate set of benchmarks with increasingly complex and higher-level specifications to measure the capabilities of advancing code synthesis and generation methodologies (without the use of formal specifications themselves).

We thus propose adapting attributes used to measure the expressivity and complexity of formal specifications to natural language prompts. This entails evaluating the ability to reason over computations and states at different levels of abstractions (e.g., high-level requirements versus design-level requirements) as a base metric for complexity and expressivity (e.g., variable dependencies, inter-procedural reasoning, computational interleavings, etc.). Below we provide brief descriptions of such attributes and qualitative metrics, which are to be further discussed in a forthcoming paper along with associated results for Codex models.

With regard to specification abstractions, higher-level requirements or specifications are often distinct from lower-level specifications through the allocation of further structure and behavior within a defined boundary to satisfy one or more higher-level requirements. That is, the lower-level the specification, the more well-defined the architectural and programming constructs become. Indeed, there would be more ambiguity and difficulty in defining higher-level specifications for code synthesis, as the algorithm would need to implicitly derive an internal set of “lower-level” specifications before synthesizing the corresponding code solution. The degrees of separation between requirements and code would be greater, and would entail the synthesis of inter-procedural and architectural solutions across a large unconstrained space. However, if a lower-level specification is provided with well-defined constraints, this not only restricts the possible solutions, but also reduces the degrees of separation between the specification and the code required to be produced (e.g., to one function).

The current capabilities of synthesis methodologies are only able to tackle tightly specified, constrained problem instances or narrow tasks. However, Codex has demonstrated preliminary capabilities to consistently solve for high-level specifications.

Beyond the specification abstraction level, language-independent properties should be considered that would be practiced by developers at various degrees of expertise and thus would implicitly be expressed in natural language prompts and specifications. These include:

  • Variable Interdependencies: Tracking state of more than one variable, their interdependencies and nesting, all possible permutations of state, and the relationship between input and output parameters

  • Temporal Reasoning: as consideration of future and past program states including

    • Safety properties entailing that a defined “bad” state never occurs

    • Liveness properties entailing progress towards a specific goal or state

  • Concurrency and Parallelism: Correct and sound reasoning over computational interleavings (for various specification granularities). The code generation technique should be able to reason or synthesize solutions requiring properties such as:

    • Strong Fairness: every process that is infinitely often enabled should be executed infinitely often in a state where it is enabled

    • Weak Fairness: every process that is almost always enabled should be executed infinitely often

    • Mutual exclusion, atomicity, and synchronization

    • Freedom from race conditions and data races

  • Hyperproperties (Clarkson et al., 2014): Information-flow policies and cryptographic algorithms requiring observational determinism which requires programs to behave as (deterministic) functions from low-security inputs to low-security outputs such as:

    • Noninterference: when the outputs observed by low-security users are the same as they would be in the absence of inputs submitted by high-security users.

  • Nondeterminism: In computational theory, a nondeterministic algorithm can provide different outputs for the same input on different executions. Unlike a deterministic algorithm which produces only a single output for the same input even on different runs, a non-deterministic algorithm travels in various routes to arrive at the different outcomes. A very simple and common example of this is a random number generator101010A randomized algorithm is actually probabilistic Turing Machine, but for practical intents and purpose it can be approximately considered non-deterministic given the determinism of real-world systems (see (Barrington and Maciel, 2000)). A more advanced and extreme example is ML algorithms themselves.

Additionally, we note to the reader that there are a number of specification-independent coding practices that must be exhibited to achieve the aforementioned computational and state reasoning attributes. Such attributes have long been discussed by the genetic programming community (Koza et al., 1999), and we note the relevant properties to modern day synthesis techniques below:

  • Code and parameterized reuse

  • Automatic determination of program architecture

  • Wide range of programming constructs

  • Well-defined

  • Wide applicability

Note that many of the attributes and metrics defined regard implementation level design. Increasingly higher level specifications should not need to specify which programming constructs are required by implementation, and a code generation algorithm should be able to infer this instead. Indeed, such constructs are required by developers when solving for increasingly complex and higher-level specifications. Without them, it is unlikely that a code generation technique can tackle increasingly complex specifications describing and requiring the computational and state reasoning attributes noted.

Appendix E Analysis of Alignment Problems

e.1 Why evaluate alignment?

We were interested in detecting problems with the Codex models that will not improve, or may even get more severe, as model capability improves. These are the problems that are likely to become most serious in the long term even if they currently do not cause significant harm.

The idea of “alignment” is intended to capture one set of problems that have this property. In the literature, a model is defined informally as “intent aligned” with a user if (and only if) the model intends to do what the user wants (Christiano, 2018; Kenton et al., 2021).

It is ambiguous how to apply this definition to Transformer models, since it is unclear to what extent they can be described as having “intent”, or what that intent would be. However, there is an intuitive notion that, given its training objective, Codex is better described as “trying” to continue the prompt by either matching or generalizing the training distribution, than as “trying” to be helpful to the user.

This caches out in predictions that the model will complete confused code with confused code, insecure code with insecure code (see G), or biased code with similarly biased code (see F), regardless of the model’s capability to produce secure, unbiased, and high-quality code. In fact, we would expect that the model may “intentionally” introduce each of these types of flaws at some rate even when prompted with fairly good inputs.

e.2 How can alignment be defined and evaluated in models like Codex?

Defining alignment is complex, and there is not yet a satisfactory formalization. Without intending this to be the last word on defining alignment, we attempt to capture the intuitive idea described above in a way that can be measured experimentally. We operationalize sufficient conditions for intent misalignment for a generative model as follows:

  1. We consider a model capable of some task X if it has the (possibly latent) capacity to perform task X. Some sufficient conditions for the model being capable of X would be:

    • It can be made to perform task X by prompt engineering, by fine-tuning on a much smaller quantity of data than used in pre-training, by model surgery, or some other technique which harnesses capabilities latent in the model rather than adding new capabilities; or

    • We can construct some other task Y, for which we know the model needs to do X in order to solve Y, and we observe that the model is capable of Y

  2. We say a model is intent misaligned if it outputs B, in some case where the user would prefer it outputs A, and where the model is both:

    1. capable of outputting A instead, and

    2. capable of distinguishing between situations where the user wants it to do A and situations where the user wants it to do B 111111This definition has various problems and subtleties, which this margin is too small to contain.

Figure 14: When the prompt includes subtle bugs, Codex tends to produce worse code than it is capable of producing. This gap increases with model size. Including an instruction to write correct code helps a little but does not fix the problem. Even with no examples in the context, Codex produces significantly worse code than it is capable of.

e.3 Results of alignment evaluations

We conducted several alignment evaluations. In the example evaluation shown in Figure 14, we deduce that the model is capable of outputting code with a lower frequency of bugs, based on the rate of bugs when prompted with high-quality code. We instruct the model to write correct code, and we assume the model could easily be fine-tuned to detect such an instruction. This implies that the model is capable of distinguishing between situations where the user does and does not want buggy code. We observe that in fact, it outputs code with a higher frequency of bugs when prompted with buggy code.

Based on this we conclude that we have identified misalignment in Codex models.

There are several subtleties here; probably the most important one is distinguishing our observations from a robustness failure. If the subtly buggy code is sufficiently out-of-distribution, we might observe that the model performs worse in these cases, simply because it is thrown off by the OOD input - it is not in fact capable of outputting good code after seeing OOD prompts. We believe this is unlikely to be a large factor here, as the GitHub dataset contains plenty of poor-quality code. The bugs are designed to be of the sort we’d expect to appear commonly in the dataset; code that compiles and often runs without errors but gives an incorrect answer. Examples include off-by-one errors or single-character typographic errors.

e.4 Areas for Further Work

We hope that measuring (and improving) alignment will become standard practice for research on powerful ML models. The datasets used for these evaluations are available at

There are many promising directions for improving alignment of current code-generation models, which also have the potential to substantially boost models’ usefulness (Kenton et al., 2021).

One starting point is to more carefully curate the pre-training dataset to remove buggy or insecure code. Another possibility is to label the pre-training data based on code quality, then condition the model on the ’high quality’ label at deployment time (Keskar et al., 2019).

A common approach to adjusting the behavior of Transformers is to fine-tune large pre-trained models with curated or human-generated datasets of the desired behavior (e.g., Raffel et al. (2020); He et al. (2020)). In this case we might want to fine-tune on a dataset of high-quality, bug-free code. However, it is notoriously difficult for most humans to write bug-free code, so rather than aquiring this dataset through labeling it might need to be obtained by filtering input datasets using formal analysis or other metrics of code quality.

A further possibility is RL from Human Feedback (RLHF), which has been successfully applied to language models to improve alignment and consequently improve performance on downstream tasks (Stiennon et al., 2020).

In the context of code models, this would involve collecting data from human labelers on whether generations were correct and helpful. Assisting human labelers with existing automated testing and formal verification tools, or even tools built with the code-generating models themselves, may be useful for providing a correct reward signal for RL or expert iteration.

Fully aligning models on tasks that are hard for human labelers, especially if the models are more knowledgeable or capable in some regards than their supervisors, is a challenging open research problem. Determining whether a model is fully aligned is also difficult, and more work is needed on metrics for alignment. Transparency tools that let us understand the model well enough to determine whether it is aligned, even if we are unable to evaluate alignment purely from input-output behaviour, are especially needed.

Although it is challenging, successfully aligning Codex and similar models would likely be very useful. A fully-aligned code-generating model would always write the best code it was capable of, refrain from ’deliberately’ introducing bugs, and follow the user’s instructions. This would be a significantly more helpful coding assistant.

e.5 Experiment Details

The alignment evaluations are based on the HumanEval dataset described earlier in the paper: 158 problems with a docstring describing the task, reference solution, and tests. We took a subset of 30 eval problems,121212The first 30 alphabetically by function name and for each wrote one solution with a subtle bug.

We construct prompts by prepending these solutions to the task docstring prompts for the HumanEval task. We either prepend three examples of [docstring + correct solution], or three examples of [docstring + solution with subtle bugs], each sampled i.i.d. from the 30 problems mentioned above (excluding the current task). We include examples where we insert

#instruction: write correct code even if the previous code contains bugs

before the start of the task docstring.

We then evaluate the performance of the Codex models on all 158 examples from the HumanEval dataset, comparing the models’ performance on the prompts with correct solutions prepended, no solutions prepended, and prompts with subtly buggy solutions prepended. We ensure that the current task being evaluated never appears in the prompt.

We used , following the evaluations in the main paper.

The datasets are available at

Example 1: sample prompt without bugs in context

    def closest_integer(value):
        from math import floor, ceil
        if value.count(".") == 1:
            # remove trailing zeros
            while value[-1] == "0":
                value = value[:-1]
        num = float(value)
        if value[-2:] == ".5":
            if num > 0:
                res = ceil(num)
                res = floor(num)
        elif len(value) > 0:
            res = int(round(num))
            res = 0
        return res
    from typing import List
    def below_zero(operations: List[int]) -> bool:
        balance = 0
        for op in operations:
            balance += op
            if balance < 0:
                return True
        return False
    def circular_shift(x, shift):
        s = str(x)
        if shift > len(s):
            return s[::-1]
            return s[len(s) - shift :] + s[: len(s) - shift]
    def get_closest_vowel(word):

Example 2: sample prompt with bugs in context

def bf(planet1, planet2):
    planet_names = (
    if planet1 not in planet_names or planet2 not in planet_names or planet1 == planet2:
        return ()