PreprintCited by 812Software Engineering ResearchSoftware Testing and Debugging TechniquesTeaching and Learning Programming

The DOI matches its DataCite record; 77 of the 77 references it cites were found in a registry or an index; 6 of the 16 sources its claims cite were checked for support.

Teaching Large Language Models to Self-Debug

Open access

Abstract

Large language models (LLMs) have achieved impressive performance on code generation. However, for complex programming tasks, generating the correct solution in one go becomes challenging, thus some prior works have designed program repair approaches to improve code generation performance. In this work, we propose Self-Debugging, which teaches a large language model to debug its predicted program via few-shot demonstrations. In particular, we demonstrate that Self-Debugging can teach the large language model to perform rubber duck debugging; i.e., without any human feedback on the code correctness or error messages, the model is able to identify its mistakes by investigating the execution results and explaining the generated code in natural language. Self-Debugging achieves the state-of-the-art performance on several code generation benchmarks, including the Spider dataset for text-to-SQL generation, TransCoder for C++-to-Python translation, and MBPP for text-to-Python generation. On the Spider benchmark where there are no unit tests to verify the correctness of predictions, Self-Debugging with code explanation consistently improves the baseline by 2-3%, and improves the prediction accuracy on problems of the hardest level by 9%. On TransCoder and MBPP where unit tests are available, Self-Debugging improves the baseline accuracy by up to 12%. Meanwhile, by leveraging feedback messages and reusing failed predictions, Self-Debugging notably improves sample efficiency, and can match or outperform baseline models that generate more than 10x candidate programs.

Overview

AI snapshot

Written from the paper’s full text.

TL;DR

SELF-DEBUGGING teaches LLMs to debug their own generated code via few-shot prompting, using execution results and natural-language code explanations without additional training. It improves state-of-the-art accuracy on text-to-SQL, code translation, and text-to-Python benchmarks, and notably improves sample efficiency.

Key findings

  • On Spider text-to-SQL, where no unit tests are available, SELF-DEBUGGING with code explanation improves the Codex baseline from 81.3 to 84.1, and improves accuracy on the hardest problems by 9%.
  • On TransCoder C++-to-Python and MBPP text-to-Python, using unit tests plus code explanation improves baseline accuracy by up to 12%; e.g., Codex on TransCoder improves from 80.4 to 92.5 with UT + Expl.
  • SELF-DEBUGGING improves sample efficiency: on Spider, applying it to greedy decoding matches the baseline using 16 samples, and SELF-DEBUGGING from 8 samples outperforms the baseline using 32 samples.
  • Error analysis shows Spider fixes often address wrong WHERE conditions (25.7%), missing DISTINCT (17.1%), and wrong JOIN clauses (14.3%); on TransCoder and MBPP, 60%–70% of successful fixes address output mismatch errors.

Methods

  • The method uses few-shot prompting with a pretrained LLM, without finetuning, in iterative turns of Generation, Explanation, and Feedback; feedback can be simple, unit-test-based, code-explanation-based, or execution-trace-based.
  • For multiple initial samples, the paper selects the program with the most frequent execution result among those without execution errors, filtering by unit tests when available; maximum debugging turns is 10, though successful debugging mostly ends within 3 turns.
  • Evaluation uses Codex, GPT-3.5, GPT-4, and StarCoder on Spider development set, TransCoder C++-to-Python with 560 problems and 10 unit tests each, and MBPP with 500 Python problems and 3 unit tests each, with the first MBPP unit test included in the prompt.

Limitations

  • The paper does not state an explicit limitations section.
  • Evident from the text: on MBPP, context length limits reduce the number of exemplars when adding code explanation (6 exemplars for simple/unit-test feedback vs. 3 for unit test + explanation), and code explanation is less significant when the initial predicted code is far from correct.
  • Evident from the text: GPT-4 is tuned for zero-shot prompting and does not follow few-shot exemplars as well as Codex on Spider; evaluation is limited to specific benchmarks and C++-to-Python translation rather than broader languages or tasks.

Model-written summary. Check it against the paper before relying on it.

Integrity signals

Registry

DataCite · 10.48550/arxiv.2304.05128

Cites

77 of 77 references verified0 citation errors · 0 not checkable

Statistics

Nothing to recompute.

Verification

Claims the paper makes

95 Own result · 19 Own interpretation · 9 No basis given · 4 Partly supported · 4 Sources not found · 2 Own method · 1 Supported · 1 Supported so far

Show all 90 claims

  • It may state two separate claims as one. 18
  • Probably not a substantial claim. 27
  • The quote only partly states this claim. 9
45 of 45
  • The paper relies on this without support.

    For complex programming tasks, generating the correct solution in one go is challenging.

    “However, for complex programming tasks, generating the correct solution in one go becomes challenging”
    “However, for many programming tasks, generating correct code with a single attempt is challenging.”
  • The paper relies on this without support.

    Human programmers typically look into incorrect code and investigate execution results, then make changes to resolve implementation errors.

    “Instead of completely discarding the incorrect code, humans typically look into the code and investigate execution results, then make changes to resolve the implementation errors.”
  • The paper relies on this without support.

    There is no guarantee that code written on the first try by human programmers is always accurate.

    “Intuitively, even for human programmers, there is no guarantee that the code written on the first try is always accurate.”
  • The paper relies on this without support.

    Human programmers can usually identify bugs by describing code implementation and comparing it to the problem description without extra guidance.

    “By describing the code implementation and comparing it to the problem description, human programmers are usually able to identify the bugs without extra guidance.”
  • The paper relies on this without support.

    The Spider benchmark's difficulty annotations, based on the complexity of the ground truth SQL queries, are valid.

    “where the difficulty of each problem is annotated in the Spider benchmark based on the complexity of the ground truth SQL queries.”
5 of 5

Claims other papers make about this one

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

Self-check

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

Each contradiction between two passages listed here was confirmed by an independent check.

1 of 1

Citations

Cites

Show all 75 references

Research works printed but not linked: 2

  1. Xinyun Chen, Chang Liu, and Dawn Song. Execution-guided neural program synthesis. In Interna- tional Conference on Learning Representations, 2019.
  2. Cheng Fu, Huili Chen, Haolan Liu, Xinyun Chen, Yuandong Tian, Farinaz Koushanfar, and Jishen Zhao. Coda: An end-to-end neural program decompiler. In NeurIPS, 2019.

Cited by

Sorted by citations

Metadata

Authors
Chen, X., Lin, M., Schärli, N., & Zhou, D.
Affiliations
University of California, Berkeley (US)
Venue
arXiv
Publisher
arXiv
Published
2023
ISSN
2331-8422 (ISSN-L)
OpenAlex
W4365205411
Cited by
812
References
75
Citations by year
2026: 287 · 2025: 222 · 2024: 211 · 2023: 92
Type
posted content
Language
en
Open access
Locations
  • arXiv (Cornell University) (submittedVersion, cc-by)
  • arXiv (Cornell University) (cc-by)
Topics
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Research
  • Physical Sciences › Computer Science › Software › Software Testing and Debugging Techniques
  • Physical Sciences › Computer Science › Computer Science Applications › Teaching and Learning Programming
Keywords
large language models, code generation, program repair, code explanation, text-to-SQL, sample efficiency, unit testing

About these checks

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

A language model drew the claims from the paper on 2026-10-07, under version 3 of the claim definition (model deepseek-v4.1-flash, prompt extract-v3).

A second model labelled each claim on 2026-10-07 (model jev-1.13-20260917, definition revision gold-guideline-v0.2).

Cited sources are checked with a language model’s help (gpt-6-sol).

Statistics and arithmetic are recomputed, not judged.

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

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

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