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

Teaching Large Language Models to Self-Debug

Open access
Chen, Xinyun, Lin, Maxwell, Schärli, Nathanael, Zhou, Denny·2023·arXiv

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.

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

74 of 74 references verified0 citation errors · 0 not checkable

Statistics

Nothing to recompute.

Claims the paper makes

6 of 16 cited sources checked · 6 supported · 0 flagged

  • Premisecitation

    Large language models have been shown to be capable of describing their generated problem solutions in both text and code formats.

    “On the other hand, large language models have been shown to be capable of describing their generated problem solutions in both text (Wei et al., 2022;Kojima et al., 2022;Zhou et al., 2023) and code (Gao et al., 2022;Chen et al., 2022) formats.”
    Quote in the paperSubstantial claim1 of 2 sources checked
    • cites Wei et al., 2022 source
    • cites Gao et al., 2022 source
  • Findingown data

    SELF-DEBUGGING consistently improves performance compared to prior code reranking approaches.

    “We demonstrate that SELF-DEBUGGING consistently improves the performance.”
    Quote in the paperSubstantial claim
  • Findingown data

    It is insufficient for accurately predicting SQL correctness when the few-shot prompt only contains simple feedback.

    “As will be shown in Section 5, it is insufficient for accurately predicting SQL correctness when the few-shot prompt only contains simple feedback.”
    Quote in the paperNot a substantial claim
  • Findingown data

    On Spider, applying SELF-DEBUGGING to predictions generated with greedy decoding matches the baseline accuracy using 16 samples.

    “In particular, on Spider, applying SELF-DEBUGGING to predictions generated with greedy decoding matches the baseline accuracy using 16 samples, and SELF-DEBUGGING from 8 samples outperforms the baseline accuracy using 32 samples.”
    Quote in the paperSubstantial claim
  • Findingown data

    On the Spider benchmark, where no unit tests verify prediction correctness, SELF-DEBUGGING with code explanation consistently improves the baseline by 2-3%.

    “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%”
    • Also stated in: § 1 INTRODUCTION · plain
      “On the Spider benchmark (Yu et al., 2018) for text-to-SQL generation where there are no unit tests in the problem description, with code explanation, SELF-DEBUGGING consistently improves the baseline by 2 -3% with different numbers of initial programs”
    Quote in the paperSubstantial claim
  • May combine two claims. 18
  • Classified as probably not a substantial claim. 27
  • The quote only partly states this claim. 9
  • May combine two claims.

    Interpretationcitation

    Different from prior works on utilizing human feedback for code repair, where the feedback message explains the code errors and how to fix them, SELF-DEBUGGING teaches the model to identify implementation errors by investigating execution results and explaining the code by itself.

    “Different from prior works on utilizing human feedback for code repair, where the feedback message explains the code errors and how to fix them (Chen et al., 2023a;Austin et al., 2021), SELF-DEBUGGING teaches the model to identify the implementation errors via investigating into execution results and explaining the code by itself.”
    Quote in the paperSubstantial claim1 of 2 sources checked
    • cites Chen et al., 2023a

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

    • cites Austin et al., 2021 source
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation

    Decoding multiple samples can significantly improve the performance of large language models.

    “Prior works demonstrate that decoding multiple samples can significantly improve the performance of large language models (Wang et al., 2023;Shi et al., 2022).”
    Quote in the paperNot a substantial claim1 of 2 sources checked
    • cites Wang et al., 2023

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

    • cites Shi et al., 2022 source
  • Classified as probably not a substantial claim.

    Premisecitation

    For code generation tasks, code execution can be utilized to select the final prediction.

    “In particular, for code generation tasks, we can utilize code execution to select the final prediction (Chen et al., 2019;Li et al., 2022;Shi et al., 2022;Zhang et al., 2022;Ni et al., 2023).”
    Quote in the paperSubstantial claim1 of 3 sources checked
    • cites Chen et al., 2019

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

    • cites Li et al., 2022

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

    • cites Shi et al., 2022 source
  • Classified as probably not a substantial claim.

    Premisecitation

    Prior work on code repair has demonstrated that training the repair model on execution traces improves debugging performance.

    “Prior work on code repair has demonstrated that training the repair model on execution traces improves the debugging performance (Wang et al., 2018;Gupta et al., 2020).”
    Quote in the paperSubstantial claim1 of 2 sources checked
    • cites Wang et al., 2018

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

    • cites Gupta et al., 2020 source
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation

    Few-shot prompting instructs the language model to solve a task with several input-output demonstrations.

    “Few-shot prompting instructs the language model to solve a task with several input-output demonstrations (Brown et al., 2020).”
    Quote in the paperNot a substantial claim1 of 1 sources checked
    • cites Brown et al., 2020 source
  • Probably not a substantial claim: may not pass S3 (load-bearing), S4 (based).

    Findingnone given

    Simple feedback does not produce meaningful changes to the initial predicted SQL queries.

    “and does not produce meaningful changes to the initial predicted SQL queries.”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingreasoning

    On TransCoder and MBPP, where at least one unit test is available, simple feedback also utilizes the execution result to infer code correctness even if execution information is not presented in the feedback message, so simple feedback still improves model prediction for both applications.

    “Note that on TransCoder and MBPP benchmarks where at least one unit test is available for SELF-DEBUGGING, simple feedback also utilizes the execution result to infer the code correctness even if the execution information is not presented in the feedback message, thus simple feedback still improves the model prediction for both applications.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Findingreasoning

    On Spider, both GPT-4's initial SQL generation and SELF-DEBUGGING performance are much worse than Codex.

    “Although GPT-4 is shown to be much stronger than previous GPT models on many tasks (Ope-nAI, 2023), on Spider, both its initial SQL generation and SELF-DEBUGGING performance are much worse than Codex.”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingown data

    Despite StarCoder's baseline performance being considerably worse than GPT models, SELF-DEBUGGING with unit test execution offers a significant performance gain, i.e., 6% on MBPP with execution trace feedback.

    “Despite that the baseline performance of StarCoder is considerably worse than GPT models, SELF-DEBUGGING with unit test execution also offers a significant performance gain, i.e., 6% on MBPP with the execution trace feedback.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Findingown data

    For all tasks, models generally benefit from richer feedback for SELF-DEBUGGING, especially when execution information is present in the feedback.

    “For all tasks, models generally benefit from richer feedback for SELF-DEBUGGING, especially when the execution information is present in the feedback.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Findingown data

    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 10× candidate programs.

    “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 10× candidate programs.”
    • Also stated in: § 1 INTRODUCTION · plain
      “Meanwhile, SELF-DEBUGGING improves sample efficiency, and can match or outperform baseline models that sample more than 10× predictions.”
    Quote in the paperSubstantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data

    Successful debugging processes mostly end within 3 turns.

    “though empirically the successful debugging processes mostly end within 3 turns”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingnone given

    Similar sample efficiency improvement is observed on other benchmarks.

    “We observe similar sample efficiency improvement on other benchmarks, and we defer the discussion to Appendix C.”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing), S4 (based).

    Findingnone given

    The accuracy improvement after one debugging turn is within 0.1%.

    “Note that typically one debugging turn is sufficient, and the accuracy improvement after one turn is within 0.1%.”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S4 (based).

    Findingown data

    Leveraging unit tests whenever available consistently boosts SELF-DEBUGGING performance.

    “In our experiments, we will demonstrate that leveraging unit tests whenever available consistently boosts the SELF-DEBUGGING performance.”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingown data

    GPT-4's self-debugging performance gain is on par with Codex: over 12% improvement on TransCoder and 8% improvement on MBPP.

    “Meanwhile, its self-debugging performance gain is on par with Codex: over 12% improvement on Transcoder, and 8% improvement on MBPP.”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingown data

    SELF-DEBUGGING can teach the large language model to perform rubber duck debugging; without any human feedback on code correctness or error messages, the model is able to identify its mistakes by investigating execution results and explaining the generated code in natural language.

    “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.”
    Quote in the paperSubstantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 5.7% of errors due to wrong COUNT columns.

    “Wrong COUNT columns | 5.7”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingown data

    SELF-DEBUGGING with unit test feedback fixes the code translation error, while simple feedback fails.

    “Figure 9: An example where SELF-DEBUGGING with unit test feedback fixes the code translation error, while the simple feedback fails.”
    Quote in the paperSubstantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data

    The translation with code explanation correctly checks for the end of a string.

    “Specifically, the translation with code explanation correctly checks for the end of a string.”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S1 (asserted), S3 (load-bearing), S4 (based). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 14.3% of errors due to wrong JOIN clauses.

    “Missing the DISTINCT keyword Wrong JOIN clauses Wrong number of SELECT columns | 17.1 14.3 11.4”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S1 (asserted), S3 (load-bearing), S4 (based). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 5.7% of errors due to missing nested conditions.

    “Missing nested conditions | 5.7”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data

    On TransCoder with gpt-3.5-turbo, 61.9% of errors fixed by SELF-DEBUGGING are output mismatches.

    “Output mismatch Runtime errors | 61.9 38.1 | 69.2 30.8”
    Quote in the paperNot a substantial claim
  • The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 25.7% of errors due to wrong WHERE conditions.

    “Wrong WHERE conditions | 25.7”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S1 (asserted), S3 (load-bearing), S4 (based). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 8.6% of errors due to wrong INTERSECT/UNION clauses.

    “Wrong INTERSECT/UNION clauses | 8.6”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data

    On MBPP with gpt-4, 30.8% of errors fixed by SELF-DEBUGGING are runtime errors.

    “Output mismatch Runtime errors | 61.9 38.1 | 69.2 30.8”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 5.7% of errors due to wrong column selection.

    “Wrong column selection | 5.7”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data

    SELF-DEBUGGING makes major changes to the initial code in Figure 11 example.

    “See Figure 11 in Appendix D for an example where SELF-DEBUGGING makes major changes to the initial code.”
    • Also stated in: § Original Python code · plain
      “Figure 11: An example on MBPP where the prediction after SELF-DEBUGGING is very different from the initial code.”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 11.4% of errors due to wrong number of SELECT columns.

    “Missing the DISTINCT keyword Wrong JOIN clauses Wrong number of SELECT columns | 17.1 14.3 11.4”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingown data

    Adding code explanation results in correct code translation, while baseline prompt does not.

    “Figure 10: An example where adding code explanation results in the correct code translation, while the baseline prompt does not.”
    Quote in the paperSubstantial claim
  • Probably not a substantial claim: may not pass S1 (asserted), S3 (load-bearing), S4 (based). The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 5.8% of errors due to wrong aggregate functions and keywords.

    “Wrong aggregate functions and keywords 5.8”
    Quote in the paperNot a substantial claim
  • May combine two claims.

    Findingown data

    Codex outperforms GPT-3.5 for both Simple and UT on MBPP.

    “It also performs close to GPT-3.5 on MBPP, and outperforms it for both Simple and UT.”
    Quote in the paperNot a substantial claim
  • The quote only partly states this claim.

    Findingown data

    On the Spider development set, SELF-DEBUGGING fixes 17.1% of errors due to missing the DISTINCT keyword.

    “Missing the DISTINCT keyword Wrong JOIN clauses Wrong number of SELECT columns | 17.1 14.3 11.4”
    Quote in the paperNot a substantial claim
  • Classified as probably not a substantial claim.

    Premisecitation

    Prior works suggest that large language models are not yet capable of correcting code when lacking external feedback, such as unit tests or human instructions.

    “prior works suggest that such large language models are not yet capable of correcting code when lacking external feedback, such as unit tests or human instructions (Chen et al., 2023a).”
    Quote in the paperSubstantial claim0 of 1 sources checked
    • cites Chen et al., 2023a

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

  • May combine two claims.

    Interpretationreasoning

    In text-to-SQL generation, SELF-DEBUGGING enables the model to identify errors and justify code correctness by explaining the predicted code.

    “First, text-to-SQL generation represents the scenario where no unit tests are available, where SELF-DEBUGGING enables the model to identify errors and justify code correctness by explaining the predicted code.”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation

    Rubber duck debugging for human programmers, where explaining code line-by-line in natural language to a rubber duck significantly boosts debugging efficiency without expert guidance.

    “This debugging process is reminiscent of rubber duck debugging for human programmers, where explaining the code line-byline in natural language to a rubber duck significantly boosts debugging efficiency without expert guidance (Hunt & Thomas, 2000).”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites Hunt & Thomas, 2000

      Couldn’t be matched to a paper in Crossref, so it can’t be checked.

  • Classified as probably not a substantial claim.

    Interpretationnone given

    Since unit tests are not available, it becomes more challenging for the model to infer the correctness of predicted SQL queries.

    “Since the unit tests are not available, it becomes more challenging for the model to infer the correctness of the predicted SQL queries.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Interpretationreasoning

    Both the execution trace and the line-by-line explanation come from model generation instead of code execution, so the trace feedback does not require more information than the pure code explanation feedback and does not require access to intermediate execution states.

    “Note that both the execution trace and the line-by-line explanation come from model generation instead of code execution, thus the trace feedback does not require more information than the pure code explanation feedback; i.e., no access to intermediate execution states.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Interpretationnone given

    SELF-DEBUGGING empowers the model to perform rubber duck debugging, so that the model can identify and fix bugs without human instructions.

    “In particular, we demonstrate that SELF-DEBUGGING empowers the model to perform rubber duck debugging, so that the model can identify and fix bugs without human instructions.”
    Quote in the paperSubstantial claim
  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims.

    Study design and conductnone given

    After the success feedback round, SELF-DEBUGGING is terminated and no further 'Feedback for failure' messages are issued, even if the new prediction is incorrect.

    “(Note that after this kind of feedback, we finish SELF-DEBUGGING and do not continue with”
    Quote in the paperNot a substantial claim
  • Probably not a substantial claim: may not pass S4 (based). May combine two claims.

    Interpretationnone given

    SELF-DEBUGGING teaches the large language model to notice prediction errors via code explanation in the style of rubber duck debugging, which does not require the feedback message to explicitly explain the implementation errors and how to fix them.

    “In particular, SELF-DEBUGGING teaches the large language model to notice prediction errors via code explanation in the style of rubber duck debugging, which does not require the feedback message to explicitly explain the implementation errors and how to fix them.”
    Quote in the paperNot a substantial claim
  • Classified as probably not a substantial claim.

    Study design and conductnone given

    In the chat feedback prompts, a new code prediction produced after the success feedback round is used for evaluation only if it also passes the unit test; otherwise the original prediction that passed is used.

    “The new code prediction is used only if it also passes the unit test, otherwise the original prediction which passes will be used for evaluation.”
    • Also stated in: § Task End ### ### Task Start ### # These are the assertions for your function: assert square_nums( [1,2,3,4,5,6,7,8,9, 10])== [1,4,9,16,25,36,49,64,81,100] """ Write a function to find squares of individual elements in a list using lambda function.""" def square_nums(nums): square_nums = list(map(lambda x: x ** 2, nums)) return square_nums · plain
      “The new code prediction is used only if it also passes the unit test, otherwise the original code will be used for evaluation.”
    • Also stated in: § Task End ### ### Task Start ### # These are the assertions for your function: assert square_nums( [1,2,3,4,5,6,7,8,9, 10])== [1,4,9,16,25,36,49,64,81,100] """ Write a function to find squares of individual elements in a list using lambda function.""" def square_nums(nums): square_nums = list(map(lambda x: x ** 2, nums)) return square_nums · plain
      “The new code prediction is used only if it also passes the unit test, otherwise the original code will be used for evaluation.”
    Quote in the paperSubstantial claim
  • Classified as probably not a substantial claim.

    Interpretationnone given

    Our work highlights the promise of improving the coding performance of large language models by teaching them to iteratively debug their own predictions, instead of requiring the model to generate the correct code from scratch.

    “Our work highlights the promise of improving the coding performance of large language models by teaching them to iteratively debug their own predictions, instead of requiring the model to generate the correct code from scratch.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Interpretationown data

    SELF-DEBUGGING demonstrates the effectiveness of both self-generated feedback and unit test feedback acquired by code execution.

    “In this work, we focus on code generation applications, and SELF-DEBUGGING demonstrates the effectiveness of both self-generated feedback and unit test feedback acquired by code execution.”
    Quote in the paperSubstantial claim
  • May combine two claims.

    Interpretationnone given

    SELF-DEBUGGING enables the model to generate feedback messages on its own at test time, and does not require extra training.

    “On the other hand, SELF-DEBUGGING enables the model to generate feedback messages on its own at test time, and does not require extra training.”
    Quote in the paperNot a substantial claim
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?

  • AlphaCode, Self-Debugging and CodeRL rely upon ground truth test cases that invalidate pass@1 eligibility, and do not use self-reflection to bridge the gap between error identification and implementation improvement.

    “AlphaCode, Self-Debugging and CodeRL are effective in fixing less-complex program bugs, but they rely upon ground truth test cases that invalidate pass@1 eligibility, and do not use self-reflection to bridge the gap between error identification and implementation improvement.”

    From Reflexion: Language Agents with Verbal Reinforcement Learning (2023) · cites this paper as [7]

    The paper contradicts both assertions about Self-Debugging. Its framework section says feedback can come from the model itself rather than unit tests, and §5.2.2 reports improvement without unit-test execution. The “Self-debugging with explanation” section says the model identifies errors through its own code explanations and uses feedback to revise its code. The cited paper does not establish the broader assertions about AlphaCode, CodeRL, or pass@1 eligibility. (LLM, conf=0.89)

    Checked by a reasoning model — may be wrong.

    Experimental — accuracy not yet measured
  • Self-Check with 3-shot CoT and zero-shot CoT have shown to been effective on various tasks including dialogue response, math reasoning, and code generation.

    “We evaluate FACTOOL against two baselines that use LLMs to check their own inputs: Self-Check with 3-shot CoT and zero-shot CoT, which have shown to been effective on various tasks including dialogue response, math reasoning, and code generation (Madaan et al., 2023;Chen et al., 2023).”

    From FacTool: Factuality Detection in Generative AI - A Tool Augmented Framework for Multi-Task and Multi-Domain Scenarios (2023) · cites this paper as Chen et al., 2023

    Section C.1 (page unavailable) reports that self-debugging improves code-translation accuracy, supporting the code-generation portion of the claim. The paper does not establish that the named Self-Check 3-shot CoT and zero-shot CoT baselines are effective across dialogue response, math reasoning, and code generation; its discussion of reasoning tasks describes other methods. (LLM, conf=0.82)

    Experimental — accuracy not yet measured
  • Earlier methods evaluate code quality by generating test cases, but this suffers from inaccurate test generation, inability to handle special judges, and failure to assess non-code parts of responses.

    “Previous works (Chen et al., 2023;Zhang et al., 2024a) rely on generating test cases to evaluate code quality.However, this method has issues with inaccurate test case generation (Jain et al., 2024), inability to handle special judge (Quan et al., 2025), and failure to evaluate non-code content in response such as code comments and explanations.”

    From RefineCoder: Iterative Improving of Large Language Models via Adaptive Critique Refinement for Code Generation (2025) · cites this paper as Chen et al., 2023

    The citation to Chen et al. is attached to the claim that earlier work generates test cases to evaluate code quality. The paper’s “Execution-based code selection” section describes using unit tests supplied in the problem description to check code correctness, not generating those tests. The later limitations are attached to other citations, so they are not assessed as claims attributed to Chen et al. (LLM, conf=0.86)

    Experimental — accuracy not yet measured
  • The belief that LLMs can self-critique and improve their own solutions in an iterative fashion rests on the assumption that verification of correctness should be easier than generation.

    “This belief seemingly rests on the assumption that verification of correctness should be easier than generation-a rather classical argument from computational complexity”

    From On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks (2024) · cites this paper as [5]

    The Abstract and “Self-debugging with explanation” section support the premise that LLMs can iteratively identify and correct errors in their own code. They do not say that this ability rests on verification being easier than generation, or invoke a computational-complexity argument; searches for that comparison found no supporting passage. (LLM, conf=0.82)

    Experimental — accuracy not yet measured
  • Recent research shows that LLMs such as ChatGPT demonstrate preliminary code debugging capabilities.

    “Meanwhile, recent research shows that LLMs such as ChatGPT demonstrate preliminary code debugging capabilities (Chen et al., 2023b,a).”

    From CodeTransOcean: A Comprehensive Multilingual Benchmark for Code Translation (2023) · cites this paper as Chen et al., 2023b

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.

  • Conflicting sampling temperatures for initial translation

    Minor

    The experiments section specifies temperature 0.7 when sampling multiple initial programs, while Appendix F.1 specifies 0.8 for generating initial Python translations. Both describe the initial code-generation setting for TransCoder.

1 of 1

Cites

Flagged first, then by citations

1 of the 75 references couldn’t be matched to a known paper.

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

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
77
References
75
Citations by year
2026: 11 · 2025: 15 · 2024: 29 · 2023: 22
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.

Claims read by deepseek-v4.1-flash under definition version 3 (extract-v3) on 2026-10-07.

Classified by jev-1.13-20260917 (gold-guideline-v0.2) on 2026-10-07.

Cited sources are checked by 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