PaperlayerView exact revision on arXiv

Source-linked AI summary

Helping LLMs Improve Code Generation Using Feedback from Testing and Static Analysis

Greta Dolcetti, Vincenzo Arceri, Eleonora Iotti, Sergio Maffeis, Agostino Cortesi, Enea Zaffanella

arXiv:2412.14841v2cs.SEcs.AI

TL;DR

LLM-generated code can contain correctness and safety issues, yet models may not reliably identify them. This paper evaluates open-source models with testing and static analysis, then uses the resulting feedback to assess code repair. Models often produce flawed code and perform poorly at detection, while showing repair capability when given issue reports.

  • Problem

    LLM-generated code may introduce correctness and security issues, motivating evaluation of its quality and of models’ ability to identify and remediate those issues.

    Source: §I · p. 1

  • Method

    The authors evaluate open-source LLMs on C tasks using ground-truth tests and static analysis, ask models to assess generated code, and provide detected issues as repair feedback.

    Source: §I · p. 1, Safety · p. 4

  • Results

    Models often generated incorrect or vulnerable code and performed poorly at detecting issues, while the best correctness and safety repair models fixed 96 of 155 incorrect files (62%) and 39 of 44 vulnerabilities (89%), respectively.

    Source: §I · p. 2, §VIII · p. 12

  • Takeaways & Limitations

    The authors conclude that prompted issue reports reveal some code-repair capability, while the observed correctness and safety gap underscores the role of verification and validation in code generation.

    Source: §VIII · p. 12

    The authors propose future work combining Infer and CodeQL to exploit complementary strengths and reduce false-positive and false-negative risk.

    Source: §VIII · p. 12

Abstract

from arXiv · show

Large Language Models (LLMs) are one of the most promising developments in the field of artificial intelligence, and the software engineering community has readily noticed their potential role in the software development life-cycle. Developers routinely ask LLMs to generate code snippets, increasing productivity but also potentially introducing ownership, privacy, correctness, and security issues. Previous work highlighted how code generated by mainstream commercial LLMs is often not safe, containing vulnerabilities, bugs, and code smells. In this paper, we present a framework that leverages testing and static analysis to assess the quality, and guide the self-improvement, of code generated by general-purpose, open-source LLMs. First, we ask LLMs to generate C code to solve a number of programming tasks. Then we employ ground-truth tests to assess the (in)correctness of the generated code, and a static analysis tool to detect potential safety vulnerabilities. Next, we assess the models ability to evaluate the generated code, by asking them to detect errors and vulnerabilities. Finally, we test the models ability to fix the generated code, providing the reports produced during the static analysis and incorrectness evaluation phases as feedback. Our results show that models often produce incorrect code, and that the generated code can include safety issues. Moreover, they perform very poorly at detecting either issue. On the positive side, we observe a substantial ability to fix flawed code when provided with information about failed tests or potential vulnerabilities, indicating a promising avenue for improving the safety of LLM-based code generation tools.

I. INTRODUCTION

The paper examines correctness, safety, self-assessment, and repair in code generated by open-source LLMs, using testing and static analysis to provide feedback. Models often generate flawed code and struggle to identify issues, but repair improves when they receive issue reports.

I. INTRODUCTION

  • The study aims to assess generated-code correctness and safety, models’ ability to identify and remediate issues, and whether they assess their own outputs differently.The authors frame this as an initial step toward safe and trustworthy LLM-enabled code generation.Source: §I · p. 1
  • The framework generates code from natural-language tasks, evaluates correctness with ground-truth tests and safety with static analysis, asks models to assess code, then requests repairs using detected issues as feedback.During self-evaluation, models assess code generated by themselves and by other models; repair may be attempted more than once.Source: §I · p. 1
  • Only 46% to 65% of generated code showed no correctness issues, while 87% to 96% contained no vulnerabilities according to Infer.These results assess prompt compliance with tests and safety through static analysis, respectively.Source: §I · p. 2
  • With feedback, the best model repaired 96 of 155 incorrect files (62%) for correctness, while the best safety model fixed 39 of 44 vulnerabilities (89%).The feedback came from correctness analysis and Infer; the study also reports no evidence of self-preference and a tendency toward one-sided predictions in two models.Source: §I · p. 2
  • Prompt design materially affected measured output quality, and the authors selected the best-performing prompt for each phase.Other prompt configurations and results are reported in the Appendix.Source: §I · p. 2

Paper Structure.

The paper lays out its experimental phases and constructs a C benchmark from MBPP tasks. It addresses possible memorization through this adaptation and compares four publicly available models.

Paper Structure.

  • The paper proceeds from experimental setup and code generation through self-evaluation, repair, results, related work, and conclusions.The setup covers dataset creation, model selection, and prompt engineering.Source: Paper Structure · p. 2

Benchmark Creation

  • The benchmark randomly selects 100 MBPP tasks, adapts them to C, and produces 100 code samples per model; evaluation and repair cover code from all four models.The authors manually refactored MBPP’s three unit tests per task for C, including using memcmp for array comparisons; Python built-in data-structure tasks were excluded.Source: Benchmark Creation · pp. 2–3

(Non-)Memorization in Benchmark Design

  • Adapting MBPP tasks to C aims to reduce memorization risk but does not eliminate overlap between task wording and model training data.The authors’ primary focus is evaluating issue detection and repair rather than fully resolving non-memorization; they suggest comparing generated C with direct translations in future work.Source: (Non-)Memorization in Benchmark Design · p. 3

Models

  • The study uses Llama 3 8B and 70B, Gemma 7B, and Mixtral 8X7B, selected as recent, capable, freely accessible, publicly released general models.The models vary in parameter counts, training data, and architecture; experiments used the Groq API with temperature 0.2.Source: Models · p. 3

Prompt Engineering

The authors iteratively tuned prompts for the experimental phases, then generated C code under specified constraints. They assessed correctness with tests and safety with Infer, whose reports and limitations inform the repair workflow.

Prompt Engineering

  • The authors tested multiple prompt configurations for each phase and selected prompts intended to improve output adequacy and correctness.Prompts combined system directives with task-specific content; discarded prompts and experiments appear in the Appendix, and reported results came from one of multiple consistent runs.Source: Prompt Engineering · p. 3

III. CODE GENERATION

  • The code-generation system prompt required correct, compilable, safe code with the requested signature and libraries, bounded by //BEGIN and //END markers.The prompt included correct and incorrect execution examples and requested explanations; the content prompt supplied the task and signature.Source: §III · pp. 3–4

Correctness

  • Correctness assessment ran MBPP-adapted unit tests on compiling programs, distinguishing passed tests, failed tests, execution errors or timeouts, and compilation errors.Passing tests cannot prove correctness, while a test failure can demonstrate incorrectness.Source: Correctness · p. 4

Safety

  • Infer analyzed generated files that compiled and produced issue reports for use as repair feedback.Infer searches for likely issues rather than proving code error-free; its reports are grouped by expected precision, from known true positives to lower-priority reports more likely to be false positives.Source: Safety · p. 4
  • The enabled Infer checkers covered buffer overruns, syntax-based lint issues such as dangerous pointer conversions, and memory-safety issues including uninitialized values.Buffer-overrun analysis also tracks certain allocation errors, out-of-bound access, and integer overflow; the pulse checker can report escaped stack addresses and constant-address dereferences.Source: Safety · p. 4
  • The study calls selected Infer findings “vulnerabilities,” focusing on popular and relevant memory-management, resource-leak, and access-control issues considered less likely to be false positives.The checkers can identify these issues with differing levels of precision.Source: Safety · p. 4

IV. SELF-EVALUATION

Self-evaluation asks models to assess generated code’s correctness and safety; repair then targets correctness failures and Infer-reported vulnerabilities. The repair procedures provide task or analyzer feedback iteratively.

IV. SELF-EVALUATION

  • Correctness self-evaluation asks whether generated code solves the task and requests a YES or NO plus an explanation.The prompt includes the task description and code generated by the model itself or another model, with correct and incorrect response examples.Source: §IV · p. 4
  • Vulnerability checks query one vulnerability type at a time; YES means that type was found, while NO means the code is safe.The model receives the generated source code and the vulnerability’s name and description.Source: §IV · pp. 4–5

V. REPAIR

  • Correctness repair supplies one failed test at a time and repeats for up to six iterations, allowing two attempts per failed test.It runs only on compiling programs that did not pass all tests or had an execution or compilation error.Source: §V · p. 5
  • Safety repair runs on compiling code with at least one Infer finding and prompts on each finding’s type, severity, qualifier, and code line.The prompts also include findings manually judged to be false positives.Source: §V · p. 6
  • For iterative vulnerability repair, the authors chose instruction-based prompting after Chain-of-Thought approaches seemed to worsen results, especially when code failed to compile during an iteration.They also observed similar results for one-shot Chain-of-Thought and instruction-based prompting.Source: §V · p. 6

VI. EXPERIMENTAL EVALUATION

The evaluation finds frequent correctness problems and detected vulnerabilities in generated code, while models perform poorly at judging code themselves. Iterative repair improves code using test and static-analysis feedback, though it does not eliminate all issues.

Code Generation

  • After cleaning and intervention, each model compiled at least 93% of files, with mixtral-8x7b-32768 reaching 98%; the 89 tasks retained for later phases yielded 356 files.None of the generated code compiled as-is before refactoring and library additions.Source: Table II · p. 6, Code Generation · p. 6

Safety

  • Infer found 44 vulnerabilities, including five false positives; 73 of 89 tasks had safe files from every model, and safe files outnumbered unsafe files for each model.NULL_DEREFERENCE was the only vulnerability type found for every model.Source: Figure 6 · p. 7, Code Generation · p. 7, Table IV · p. 8

Correctness

  • 46% (gemma-7b-it) to 65% (llama3-70b-8192) of generated files were correct; only 29 tasks had correct code from every model, while 19 had incorrect code from every model.Correctness was assessed against the available unit tests.Source: Table III · p. 7, Code Generation · p. 7

Self-evaluation

  • Correctness self-evaluation was poor: all evaluator-model F1-scores were below 80%, and evaluators often favored nearly always-YES or nearly always-NO responses.The reported confusion matrices further explain the poor precision, recall, and F1-scores for llama3-70b-8192 and mixtral-8x7b-32768.Source: Code Generation · p. 8, Figure 8 · p. 8, Figure 9 · p. 8
  • Safety self-evaluation also performed poorly: all F1-scores were below 0.3, with class imbalance allowing near-always-NO responses to achieve high accuracy while missing vulnerabilities.Gemma-7b-it instead tended to answer YES, detecting vulnerabilities but producing false positives.Source: Code Generation · pp. 8–9, Table VI · p. 9

Correctness

  • Llama3-70b-8192 fixed 59% of incorrect files on average and 68% of gemma-7b-it files, but no model repaired every file or showed general self-preference.For all models except gemma-7b-it, the percentage fixed was lower when repairing their own generated code.Source: Code Generation · pp. 9–10, Table VIII · p. 10

Repair

  • Across repair iterations, llama3-70b-8192 showed the steepest decrease in failed tests; some models produced code that temporarily failed to compile during vulnerability repair before recovering.The failed-test curves were lower and more stable for llama3-70b-8192 after two iterations.Source: Figure 10 · p. 10, Code Generation · pp. 10–11, Figure 11 · p. 11

Safety

  • About 77% of previously detected vulnerabilities were fixed; of 39 still detected, manual inspection found only one true positive.The analysis covered 176 original vulnerability instances across four models.Source: Table IX · p. 10, Code Generation · pp. 10–11

VII. RELATED WORK

Prior studies examine vulnerabilities in generated code, code repair, and LLM-based static analysis, but the authors identify gaps in functional correctness and model self-awareness evaluation. Their study uses open-source models and iterative repair informed by static-analysis feedback.

Related studies

  • Prior security studies assessed generated code with vulnerability tools: FormAI evaluated 112,000 AI-generated C programs using ESBMC,, while Pearce et al. examined Copilot.The cited Copilot study also tested strategies for improving security, none entirely effective at removing vulnerabilities.Source: §VII · p. 11
  • Repair research spans counterexample-guided vulnerability repair, static-analyzer-based repair, and LLM applications to loop invariants and false-positive pruning,.Other cited work studies LLM self-repair and security repair [22]–.Source: §VII · pp. 11–12

Study distinction

  • Unlike cited studies –, this work uses open-source models without fine-tuning and evaluates functional correctness against specifications as well as safety and model self-awareness.The authors state that the cited methodologies do not check functional correctness against specifications or measure self-awareness when models assess their own generated code.Source: §VII · p. 12

Static analysis and repair

  • Prior work interleaves static-analyzer reports with LLM responses or applies a neurosymbolic framework to repository-level vulnerability detection [28]; this study likewise uses iterative repair.The authors say these works have different purposes, while their results motivate employing an iterative method in repair.Source: §VII · p. 12

Datasets

  • The authors use a C adaptation of MBPP with single-function specifications, contrasting it with LiveCodeBench’s competition-sourced problems [22]; cybersecurity remains outside this paper’s primary scope.They prioritize correctness and safety evaluation on the tailored benchmark.Source: §VII · p. 12

VIII. CONCLUSIONS

The paper evaluates LLM-generated C code for correctness and safety, their ability to assess those properties, and their repair capabilities. It reports weak autonomous generation and self-assessment, alongside some ability to repair code when given issues to address.

VIII. CONCLUSIONS

  • The evaluation covered code generation, correctness and safety assessment, and repair, using a benchmark adapted from MBPP to C.Generated programs were tested and analyzed with Infer before the resulting feedback was used to evaluate repairs.Source: §VIII · p. 12
  • Models showed a gap in generating fully compliant and secure code autonomously, very low self-awareness of correctness and safety, and some ability to repair code when given issues.The evaluation used an MBPP-derived C benchmark and assessed generated code with tests and static analysis.Source: §VIII · p. 12
  • The proposed pipeline is modular, but the paper identifies combining static analyzers as future work to reduce false positives and false negatives.The authors also describe future hybrid approaches combining static and dynamic analyses for safety repair.Source: §VIII · pp. 12–13
  • The study focuses on C; the authors plan to extend evaluation to languages including Rust and Python.Future work also includes investigating whether generated code is newly produced or translates code encountered during model training.Source: §VIII · p. 13

IX. DATA AVAILABILITY

The paper provides its benchmark tasks, generated source code, evaluation scripts, and Infer analysis results.

IX. DATA AVAILABILITY

  • The shared materials include the benchmark tasks and raw and cleaned model-generated code, evaluation scripts, and Infer results for vulnerability analysis and repair.The passage supplies an anonymous data link for review and says the data would move to Zenodo with a DOI if accepted.Source: §IX · p. 13

APPENDIX

The appendix lists prompt experiments and results, including code-generation prompts and correctness self-evaluation materials.

APPENDIX

  • The appendix reports prompt experiments and results for each phase, with the names of best prompts highlighted in italics.Source: APPENDIX · p. 16

Code Generation Experiments

Self-Evaluation Experiments - Correctness

Self-Evaluation Experiments - Safety

The appendix provides prompt variants and tables for self-safety analysis.

Self-Evaluation Experiments - Safety

Code Repair Experiments - Correctness

The correctness repair experiments compare prompting strategies and report code correctness after repair and code cleaning, including model-specific results for the one-assert-at-a-time prompt.

Code Repair Experiments - Correctness

  • The Vanilla and Chain of Thought prompts are each represented by a figure and an overall post-repair correctness table.The supplied captions do not state which prompt or model performs better.Source: Figure 28 · p. 24, Table XXII · p. 24, Figure 29 · p. 24
  • Tables XXII–XXIV report overall code correctness after repair and code cleaning for Vanilla, Chain of Thought, and One Assert at the Time prompts.The captions identify the evaluation scope but do not provide result values.Source: Table XXII · p. 24, Table XXIII · p. 24, Table XXIV · p. 24
  • The One Assert at the Time prompt supplies one failed assertion iteratively, for up to six iterations.Tables XXV–XXIX report model-specific correctness results for gemma-7b-it, llama3-8b-8192, llama3-70b-8192, and mixtral-8x7b-32768.Source: Figure 30 · p. 24, Table XXV · p. 24, Table XXVI · p. 24

Code Repair Experiments - Safety

The safety repair experiments assess aggregate vulnerability results across several prompts, including variants that withhold vulnerability details or line numbers and a one-vulnerability-at-a-time prompt.

Code Repair Experiments - Safety

  • Figures also identify Vanilla, Chain of Thought, Instructions, and Combo as safety-repair prompt settings.Their corresponding aggregate analyses are reported in Tables XXIX–XXXII.Source: Figure 31 · p. 26, Table XXIX · p. 26, Figure 32 · p. 26
  • Tables XXIX–XXXV report aggregate vulnerability analyses after repair for Vanilla, Chain of Thought, Instructions, Combo, No Info, No Line, and One Vulnerability at the Time prompts.The captions identify the compared prompt settings but provide no vulnerability counts or comparative outcomes.Source: Table XXIX · p. 26, Table XXX · p. 26, Table XXXI · p. 26
  • The No Info prompt omits vulnerability-type information, while No Line omits the vulnerability's line number.These prompt variants are each represented by a figure and an aggregate post-repair vulnerability table.Source: Table XXXIII · p. 26, Figure 35 · p. 27, Figure 36 · p. 27
  • The One Vulnerability at the Time prompt has an aggregate analysis and model-specific vulnerability breakdowns for gemma-7b-it, llama3-70b-8192, llama3-8b-8192, and mixtral-8x7b-32768.The supplied captions do not disclose the breakdown values.Source: Table XXXV · p. 27, Table XXXVI · p. 27, Table XXXVII · p. 27

Related papers

Loading 2412.14841v2…