Source-linked AI summary
Beyond Functional Correctness: Exploring Hallucinations in LLM-Generated Code
Fang Liu, Yang Liu, Lin Shi, Zhen Yang, Li Zhang, Xiaoli Lian, Zhongqi Li, Yuchi Ma
TL;DR
Research on hallucinations has focused mainly on natural-language generation, leaving code hallucinations’ types, distribution, causes, and impacts less understood. This study analyzes LLM-generated code and finds hallucinations frequent, particularly those that conflict with user requirements.
Problem
Prior research has focused mainly on natural-language hallucinations, while code’s syntax and correctness constraints call for investigation of code hallucinations’ categories and distribution.
Source: §I · pp. 1–2Method
The authors thematically analyzed 3,120 code samples from two code-generation benchmarks using open coding, developing a taxonomy of 3 primary and 12 specific hallucination types.
Source: §I · p. 2Results
Hallucinations frequently affected generated code, particularly by conflicting with user requirements; the authors report influences from model capabilities and prompt quality and impacts on functionality, readability, maintainability, and efficiency.
Source: §VII · p. 17Takeaways & Limitations
Prompt engineering is a promising direction for mitigating code hallucinations, according to the authors.
Source: C. Threats to Validity · p. 17The empirical study targets Python and Java, limiting the scope for generalizing its taxonomy and findings to other programming languages.
Source: C. Threats to Validity · p. 16
Abstract
from arXiv · showhide
The rise of Large Language Models (LLMs) has significantly advanced various applications on software engineering tasks, particularly in code generation. Despite the promising performance, LLMs are prone to generate hallucinations, which means LLMs might produce outputs that deviate from users' intent, exhibit internal inconsistencies, or misaligned with the real-world knowledge, making the deployment of LLMs potentially risky in a wide range of applications. Existing work mainly focuses on investigating the hallucination in the domain of Natural Language Generation (NLG), leaving a gap in comprehensively understanding the types, causes, and impacts of hallucinations in the context of code generation. To bridge the gap, we conducted a thematic analysis of the LLM-generated code to summarize and categorize the hallucinations, as well as their causes and impacts. Our study established a comprehensive taxonomy of code hallucinations, encompassing 3 primary categories and 12 specific categories. Furthermore, we systematically analyzed the distribution of hallucinations, exploring variations among different LLMs and benchmarks. Moreover, we perform an in-depth analysis on the causes and impacts of various hallucinations, aiming to provide valuable insights into hallucination mitigation. Finally, to enhance the correctness and reliability of LLM-generated code in a lightweight manner, we explore training-free hallucination mitigation approaches by prompt enhancing techniques. We believe our findings will shed light on future research about code hallucination evaluation and mitigation, ultimately paving the way for building more effective and reliable code LLMs in the future. The replication package is available at https://github.com/Lorien1128/code_hallucination
I. INTRODUCTION
The paper defines code hallucination as semantic conflict between generated code and requirements, contextual code, or real-world facts, then studies its types, causes, and consequences. It develops a taxonomy from generated code samples and explores prompt-based mitigation.
I. INTRODUCTION
- Code hallucination is an explicit semantic conflict with user requirements, contextual code, or real-world knowledge that can undermine software correctness, performance, maintenance, and security.The paper distinguishes complete solution programs from code snippets, which may be partial or complete solutions.Source: §I · pp. 1–2
- The study asks what code hallucinations occur and how they vary across models and benchmarks, why they arise, and how they affect software quality.Its analysis considers functional correctness, efficiency, and maintainability as downstream impacts.Source: §I · p. 2
- Requirement-conflicting hallucinations were most prevalent; model capabilities and prompt quality contributed, while incorrect functionality was the most common impact.Readability and efficiency were also typically affected.Source: §I · p. 2
- Thematic analysis of 3,120 samples from two benchmarks produced a taxonomy of three primary categories and 12 specific hallucination types.The primary categories are Requirement Conflicting, Code Inconsistency, and Knowledge hallucinations.Source: §I · p. 2
- Refining requirements or prompting chain-of-thought reasoning helped mitigate requirement-conflicting hallucinations, while adding relevant domain knowledge reduced knowledge-conflicting hallucinations.The paper reports a preliminary training-free exploration of prompt-enhancing strategies, including qualitative case studies of their mechanisms.Source: §I · p. 2
II. PRELIMINARY · A. Terminology · B. Definition of Code Hallucination
The paper defines code hallucination as an explicit semantic conflict between generated code and established facts, distinguishing it from errors that require logical reasoning. It classifies hallucinations as requirement conflicts, code inconsistencies, or knowledge hallucinations.
A. Terminology
- Requirements, contextual code, real-world knowledge, and established facts provide the terminology for identifying conflicts in generated code.Requirements are task descriptions; contextual code includes prompt code and prior model output; established facts are verifiable information bounded by requirements, context, or real-world knowledge.Source: A. Terminology · p. 3
B. Definition of Code Hallucination
- The authors distinguish failures to retain or recall context from reasoning errors, but restrict classification to immediate, obvious conflicts because the model’s black-box nature makes causes difficult to attribute.An explicit conflict makes the likelihood of a reasoning-error origin small enough for practical classification.Source: B. Definition of Code Hallucination · p. 3
- Code hallucination is an explicit semantic conflict with established facts caused by inaccurate retention, recall, or processing of requirements, contextual code, or real-world knowledge.The definition treats the conflict as a traceable indicator of hallucination.Source: B. Definition of Code Hallucination · p. 3
- Potential causes include flawed training data sources [34] [54] and suboptimal training or decoding choices [23] [84].Source: B. Definition of Code Hallucination · p. 3
- The taxonomy identifies three fundamental types: Requirement Conflicting, Code Inconsistency, and Knowledge Hallucination.The first two are faithfulness hallucinations; Knowledge Hallucination concerns discrepancies with real-world knowledge.Source: B. Definition of Code Hallucination · p. 3
- The three types correspond to input-, context-, and fact-conflicting hallucinations in NLG [85], while code generation may differ in specific categories, causes, and impacts.The distinction parallels faithfulness and factuality hallucinations in NLG [24] [28].Source: B. Definition of Code Hallucination · p. 3
- The definition excludes indirect conflicts requiring reasoning or calculation, as well as syntactic and logical-planning errors that do not directly contradict the requirement.In the Tribinacci example, initializing tri(1) as 1 contradicts the specified value tri(1) = 3, while an out-of-range index error remains semantically consistent.Source: B. Definition of Code Hallucination · pp. 3–4
C. Difference between Code Hallucinations and Errors … B. Hallucination in LLMs
The related-work material reviews code-generation models and benchmarks, adapts LLM hallucination distinctions to code, and separates direct semantic conflicts from other code errors.
C. Difference between Code Hallucinations and Errors
- Code hallucinations are direct semantic conflicts: useless statements may not cause errors, while implicit logical conflicts and syntax errors fall outside the definition.Semantic conflicts also need not produce conflicting execution results.Source: C. Difference between Code… · p. 4
- Syntactic errors are nonsemantic and often detectable at compilation, while logical reasoning errors yield incorrect deductions without directly conflicting with requirements.The paper classifies both patterns as errors that do not qualify as code hallucinations.Source: C. Difference between Code… · p. 4
- Incomplete implementation omits some requirements despite structurally sound code, whereas invalid generation produces formally incomplete or incoherent code.Examples of invalid generation include malformed function definitions or missing control structures.Source: C. Difference between Code… · p. 4
A. LLMs for Code Generation
- Codex [4] helped enable Copilot’s real-time coding suggestions, followed by models including AlphaCode [40], InCoder [18], Code Llama [63], CodeWhisperer, and StarCoder [39].The passage also names DeepSeek-Coder, GPT, and ChatGPT series as later code-generation models.Source: A. LLMs for Code Generation · p. 4
- Code-generation benchmarks include HumanEval [4], DS-1000 [33], MBPP [3], APPS [22], CoderEval [80], and DevEval.These benchmarks generally contain multiple test cases and a few examples to clarify task descriptions.Source: A. LLMs for Code Generation · p. 4
B. Hallucination in LLMs
- The paper adapts Zhang et al.’s [85] input-, context-, and fact-conflicting hallucination taxonomy to code’s task requirements, contextual information, and real-world knowledge.Prior NLG and NLP taxonomies distinguish source contradictions, unverifiable content, factuality, and faithfulness concerns [24] [28].Source: B. Hallucination in LLMs · p. 4
C. Code Hallucination … 1) Data Collection:
The paper distinguishes code hallucinations from general code errors by tracing semantic conflicts to requirements, code context, or real-world knowledge, then builds a taxonomy from generated samples and systematically analyzes them. Its collection uses HumanEval and CoderEval tasks, four LLMs, and controlled generation settings.
C. Code Hallucination
- Prior studies variously classify repository-level conflicts, nonexistent-package references, code defects, output divergence, irrelevant content, and mapping, naming, resource, or logic hallucinations.The cited studies also examine mechanisms such as training-data recency and decoding strategies, and emphasize contextual analysis.Source: C. Code Hallucination · pp. 4–5
- The study defines code hallucinations through direct, traceable semantic conflicts and organizes them by requirements, contextual code, and real-world knowledge.This distinction addresses prior work that overgeneralizes or underspecifies hallucination, while extending beyond repository-level or package-specific classifications.Source: C. Code Hallucination · p. 5
D. Evaluation of LLM-Generated Code
- The paper positions its work as the first comprehensive hallucination-focused analysis of LLM-generated code, including prevalence, patterns, causes, impacts, and prompt-enhancing mitigation strategies.It also examines code-quality issues arising from hallucinations, encompassing issues studied in prior work.Source: D. Evaluation of LLM-Generated Code · p. 5, C. Code Hallucination · p. 5
A. Hallucination Taxonomy Construction
- The taxonomy was constructed by collecting LLM-generated code samples, applying open coding, and categorizing the resulting hallucinations.Source: A. Hallucination Taxonomy Construction · p. 5
1) Data Collection:
- The study uses HumanEval and CoderEval to cover standalone-function and repository-level generation in Python and Java.HumanEval contains 164 Python tasks; CoderEval contains 230 Python functions from 43 projects and 230 Java methods from 10 projects, with references and unit tests.Source: 1) Data Collection · p. 5
- The four selected LLMs are CodeLlama, DeepSeek-Coder, GPT-4, and DeepSeek-R1, spanning open- and closed-source, general-purpose and code-specialized models.The study uses CodeLlama-7B, DeepSeek-Coder 1.3B and 7B, GPT-4 preview gpt-4-0125-preview, and DeepSeek-R1 (671B); R1 was included for its reasoning capabilities.Source: 1) Data Collection · pp. 5–6
- 3,120 code samples were collected using greedy decoding, one output per problem and model, with brief role-description and dataset-default prompts.Greedy decoding used do_sample=False to make outputs deterministic; each problem had five generated solutions across the selected models.Source: 1) Data Collection · p. 6
2) Manual Analysis:
The authors used a staged thematic analysis to build and refine a codebook for code hallucinations. The analysis identified 1,212 hallucinatory snippets and yielded a taxonomy of three primary and 12 specific categories.
2) Manual Analysis:
- A pilot analysis of 500 randomly sampled snippets—about 20% of the total—was used to enrich categories, establish a codebook, and develop an initial taxonomy.Two experienced labelers independently reviewed the pilot; the remaining 80% were then labeled to refine and expand the taxonomy.Source: 2) Manual Analysis · p. 6
- Pilot reviewers annotated hallucination types, locations, causes, and impacts, allowed multiple causes or impacts per snippet, and resolved disagreements through discussion or an expert decision.The two experts reviewed problem descriptions, reference code, and execution results; the pilot took approximately 60 person-hours.Source: 2) Manual Analysis · p. 6
- Ten participants independently labeled the remaining 80%, with each code reviewed by two participants; pairwise Cohen’s Kappa scores ranged from 0.76 to 0.96.Disagreements were discussed with a senior author until consensus, or decided by that author if consensus was not reached.Source: 2) Manual Analysis · pp. 6–7
- 1,212 hallucinatory snippets were found across 1,134 of 3,120 samples, yielding a taxonomy of three primary categories and 12 specific categories.The primary categories are Requirement Conflicting, Code Inconsistency, and Knowledge hallucinations; snippet counts were 173 for HumanEval, 452 for CoderEval-Python, and 587 for CoderEval-Java.Source: 2) Manual Analysis · pp. 6–7, Figure 2 · p. 7
B. Taxonomy of Code Hallucinations · I. Requirement Conflicting (39.60%)
The taxonomy groups code hallucinations into requirement conflicts, code inconsistencies, and knowledge conflicts; requirement conflicts are the largest primary category at 39.60%.
I. Requirement Conflicting (39.60%)
- Requirement Conflicting (39.60%) is divided into Behavior Conflicting (35.40%) and Data Conflicting (4.21%), according to which requirement content is violated.Behavior conflicts concern functional logic or execution flow; data conflicts concern requirement-specified values or formats.Source: §I · p. 7
- Behavior conflicts include implementing summation as multiplication, while data conflicts include returning “OK” instead of a required “SUCCESS”; variable-name misinterpretation may cause behavior errors.One example misuses register_value as a dictionary value rather than the required key.Source: §I · p. 7
II. Code Inconsistency (25.50%)
- Code Inconsistency (25.50%) comprises Undefined Variables (16.91%), Useless Statements (6.60%), Fragmented Logics (1.73%), and Inconsistent Libraries (0.25%).These cover references to undefined variables, disjointed logic, and library or API mismatches that create semantic conflicts.Source: §I · pp. 7–8
- Useless Statements include unexecuted statements (0.58%) and executed statements with no output impact (6.02%); a loop-bound conflict illustrates the first case.In the example, the loop reaches at most len(nums) - 1, so an if condition requiring i >= len(nums) prevents its statement from running.Source: §I · p. 8
III. Knowledge Hallucinations (34.90%)
- Knowledge Hallucinations (34.90%) conflict with real-world knowledge: Computer Science (33.25%), Mathematics and Natural Science (1.40%), or Common Sense (0.25%).The example incorrectly says XOR is 1 only when both inputs are 1, contrary to binary calculation rules.Source: §I · p. 8
- Computer Science conflicts comprise Library/Project knowledge (25.99%), Algorithm knowledge (4.95%), and Computer Theory knowledge (2.31%).Library/Project conflicts are single-point errors about libraries or project context; Inconsistent Libraries instead involve multi-point contextual inconsistencies.Source: §I · p. 8
V. CODE HALLUCINATION ANALYSIS · A. RQ1. Distribution of Code Hallucinations. · 1) Overall Distribution of Hallucinations:
Behavior Conflicting is the most frequent hallucination type across the models except DeepSeek-R1, where it ranks third. DeepSeek-R1 has the fewest hallucinations overall but the highest proportion in Library/Project.
A. RQ1. Distribution of Code Hallucinations.
- The analysis examines hallucination-category distributions across LLMs and benchmarks, following the study’s prior manual analysis.Source: §V · p. 8, A. RQ1. Distribution of Code… · p. 8
1) Overall Distribution of Hallucinations:
- Behavior Conflicting is the most frequent hallucination type across the models except DeepSeek-R1, where it ranks third and is below the top two categories.Data Conflicting is also relatively rare.Source: 1) Overall Distribution of… · pp. 8–9, Figure 6 · p. 9, Figure 7 · p. 9
- Library/Project and Undefined Variables hallucinations follow closely and are largely identified in CoderEval, while Algorithm and Computer Theory hallucinations are less common.The authors attribute the CoderEval pattern to generated functions depending on contextual information in their class, project, or libraries.Source: 1) Overall Distribution of… · p. 9
- Useless Statements show that LLMs struggle to capture execution semantics, but are less prevalent in DeepSeek-R1; the authors suggest reasoning or more parameters may alleviate these hallucinations.Source: 1) Overall Distribution of… · p. 9
- Inconsistent Libraries are least frequent but can be subtle and difficult to detect, cause runtime errors or loss of intended functionality, and increase debugging costs and potential risks.The category covers mixed API use across similar libraries or different versions of the same library.Source: 1) Overall Distribution of… · p. 9
- Hallucination counts decline across DeepSeek-Coder-1.3B, DeepSeek-Coder-7B, and DeepSeek-R1-671B, while CodeLlama-7B has more than either DeepSeek-Coder model, including the 1.3B model.The paper notes that CodeLlama-7B also has a lower code-generation pass rate than both DeepSeek-Coder versions.Source: 1) Overall Distribution of… · p. 9
- The authors caution that parameter size alone does not determine hallucination frequency and call for systematic study of architecture, training-data quality, and model size.They suggest CodeLlama-7B’s weaker instruction following may relate to training data or model design and training strategies, and point to DeepSeek-R1 as evidence that advanced training strategies matter.Source: 1) Overall Distribution of… · p. 9
- DeepSeek-R1 has the fewest hallucinations overall but the highest proportion in Library/Project; the authors omit Inconsistent Libraries and Common Sense from later analysis because they are scarce.Source: 1) Overall Distribution of… · pp. 9–10
2) Hallucination Distribution across Benchmarks: · B. RQ2. Hallucination Cause Analysis.
Hallucination distributions vary across code-generation scenarios and languages, while remaining largely consistent across models. The analysis attributes hallucinations to prompt-design deficiencies and model-related factors.
2) Hallucination Distribution across Benchmarks:
- HumanEval’s standalone math and algorithm tasks are associated with Mathematics & Natural Science conflicts, while CoderEval’s repository context is associated with Library/Project hallucinations.Missing contextual information in CoderEval prompts can also prompt guesses that produce Undefined Variables, Useless Statements, Fragmented Logic, or conflicts with algorithm knowledge; reasoning errors and lack of a real-time compiler or interpreter are also noted for HumanEval.Source: 2) Hallucination Distribution across… · p. 10
- CoderEval-Python requires more mathematics and computer-theory knowledge than CoderEval-Java, and models may generate code conflicting with that knowledge.Source: 2) Hallucination Distribution across… · p. 10
- Hallucination-type distributions remain largely consistent across benchmarks and models; DeepSeek-R1 discrepancies mainly reflect small counts that make proportions sensitive to minor fluctuations.Source: 2) Hallucination Distribution across… · p. 10
- Statistical tests found significant differences in the results that exhibited obvious differences; detailed test information is in the online replication package’s appendix.Source: 2) Hallucination Distribution across… · p. 10
- Behavior Conflicts are the most prevalent hallucination across LLMs and benchmarks; hallucination frequency may vary with model size, and type distributions vary by scenario and language.Generally, models with larger parameter sizes tend to hallucinate less.Source: 2) Hallucination Distribution across… · p. 10
B. RQ2. Hallucination Cause Analysis.
- Hallucination causes comprise ambiguous or incomplete requirements, insufficient domain-specific knowledge, and model-related factors; the first two are prompt-design deficiencies, while contextual code is generated output.These categories respectively concern defects in user requirements, real-world knowledge, and model limitations.Source: B. RQ2. Hallucination Cause Analysis · p. 11
- Prompt text complexity and length may indirectly affect hallucinations, while diverse model factors are grouped broadly as Model-related Causes because identifying them manually is impractical.The authors state that model and prompt factors cover the vast majority of cases.Source: B. RQ2. Hallucination Cause Analysis · p. 11
1) Distribution of Hallucination Causes:
Model-related limitations account for most code hallucinations, while missing domain knowledge and requirements-related causes also contribute. Their relative roles vary across hallucination categories, and prompt-focused checks support the cause annotations.
1) Distribution of Hallucination Causes:
- Model-related causes account for 80.86% of samples, compared with 26.24% for lack of domain-specific knowledge and 1.90% for ambiguous or incomplete requirements.Proportions are calculated over all samples; for samples with multiple causes, one cause was randomly retained for drawing. The study distinguishes incomplete task descriptions from gaps in relevant domain knowledge.Source: 1) Distribution of Hallucination Causes · p. 11
- Model-related causes are the primary contributors to nearly all hallucination categories, while requirement-related factors matter more for Undefined Variables and Library/Project hallucinations.The authors note that many CoderEval requirements lacked sufficient project-specific knowledge, and recommend clear, accurate, comprehensive requirements alongside improving model capabilities.Source: 1) Distribution of Hallucination Causes · pp. 11–12
- Prompt-focused checks supported the annotations: repository-code retrieval reduced Library/Project hallucinations from 7 samples to 2, while prompt revision reduced hallucinations from 4 samples to 1.For domain knowledge, the study sampled 144 of 230 Python CoderEval tasks; 9 hallucinations were attributed partly or fully to that cause, including 7 with Library/Project hallucinations. Revising all 4 affected HumanEval prompts addressed Ambiguous or Incomplete requirements.Source: 1) Distribution of Hallucination Causes · p. 12
2) Impact of Prompt Length and Complexity: · C. RQ3. Impact of Hallucination.
Prompt length and complexity are associated with hallucination rates, while hallucinations can impair functionality, readability, efficiency, and maintainability. Incorrect functionality is the most common impact, and hallucinatory code is more prone to errors and lower functional correctness.
2) Impact of Prompt Length and Complexity:
- Prompt complexity was rated on a 1–3 scale using criteria covering comprehension, reasoning steps, specialized knowledge or new definitions, and syntactical complexity; prompt length was measured in tokens.The study used tiktoken for length measurement and labelers to assign complexity ratings.Source: 2) Impact of Prompt Length and… · p. 12
- At approximately 350 tokens, hallucination probability rises after initially fluctuating and declining; higher prompt complexity consistently correlates with increased hallucination rates.Prompt length and complexity are strongly positively correlated; the authors attribute the initial decline to longer prompts clarifying requirements and the later rise to difficulty capturing key points.Source: Figure 11 · p. 12, 2) Impact of Prompt Length and… · p. 12
- The 95% bootstrap confidence interval for the prompt-length mediation effect was (0.0113, 0.0725), supporting a significant effect largely explained by prompt length’s relationship with complexity.When complexity is held fixed, changes in prompt length do not appear to significantly affect the proportion of hallucinatory code.Source: 2) Impact of Prompt Length and… · p. 12
- The authors identify stronger LLM reasoning and requirements written clearly, comprehensively, and concisely as potential strategies for reducing code hallucinations and improving code quality.They note that prompt complexity is an important prompt-related factor in causing hallucinations.Source: 2) Impact of Prompt Length and… · p. 12
C. RQ3. Impact of Hallucination.
- 95.30% of hallucinations were associated with incorrect functionality, followed by poor readability (14.27%), low efficiency (5.20%), and poor maintainability and scalability (3.88%).Incorrect functionality can undermine usability and complicate debugging; readability issues hinder collaboration, while inefficiency and maintainability problems can increase performance and system-evolution burdens.Source: C. RQ3. Impact of Hallucination · p. 13
- Eight of ten hallucination categories lead to incorrect functionality; Behavior Conflicting is the most frequent category, and hallucinatory code is more error-prone and generally less functionally correct than hallucination-free code.Non-hallucinatory code can still contain errors unrelated to hallucinations.Source: C. RQ3. Impact of Hallucination · pp. 13–14
- Hallucinations can impair code quality through distinct mechanisms: useless statements may reduce efficiency and readability, while incorrect or suboptimal algorithms can increase time complexity.These impacts typically arise from hallucination categories other than Requirement Conflicting.Source: C. RQ3. Impact of Hallucination · p. 13
VI. DISCUSSION · A. Hallucination Mitigation Exploration
The discussion explores training-free prompt enhancements as a flexible way to mitigate code hallucinations, using the paper’s taxonomy to match strategies to hallucination types. Experiments show reduced hallucinations but also reveal limitations tied to model reasoning capacity.
A. Hallucination Mitigation Exploration
- The authors propose tailoring mitigation to hallucination type: refine requirements or use chain-of-thought for requirement conflicts, and apply retrieval augmentation for knowledge gaps.For code inconsistencies, chain-of-thought can support implementation planning, while post-processing such as static analysis can detect undefined variables and replace them with similar defined variables.Source: A. Hallucination Mitigation Exploration · p. 14
- Experiments tested Self-Refine and CoT on HumanEval and RAG on CoderEval (Python), using DeepSeek-Coder-1.3B and manual evaluation of a random subset.For RAG, semantically similar repository snippets were retrieved with a 20-line sliding window and 2-line step, then included in prompts capped at 1,000 tokens.Source: A. Hallucination Mitigation Exploration · pp. 14–15
- The three prompt-enhancement strategies substantially reduced hallucinations on their target datasets, especially Requirement Conflicting; RAG notably reduced Knowledge Hallucinations, while Self-Refine and CoT lowered pass@1.The authors attribute the pass@1 decreases mainly to samples that were originally free of hallucinations; CoT also had no significant impact on Code Inconsistency hallucinations.Source: Table IV · p. 15, A. Hallucination Mitigation Exploration · p. 15
- In a Self-Refine example, requirement explanation softened a Behavior Conflicting error, but the result still mishandled zero-valued signs; it worked correctly when the input contained no zero.The original code took the absolute value of the product rather than the product of the numbers’ signs.Source: A. Hallucination Mitigation Exploration · p. 15
- For RAG, project-specific context supplied semantic and implementation clues that helped the LLM avoid using a nonexistent attribute and generate code closer to project requirements.The example drew on a complementary popitem method in another class.Source: A. Hallucination Mitigation Exploration · p. 15, Figure 13 · p. 16
- The authors present prompt enhancement as promising and the taxonomy as guidance for choosing methods, while noting effectiveness depends on requirement understanding, reasoning, and knowledge extraction.They identify improved training, decoding, architecture, multi-agent interaction, and external retrieval or fact-checking tools as future research directions.Source: A. Hallucination Mitigation Exploration · p. 15
B. Implications · 1) Implications for Researchers:
The implications call for evaluation and detection beyond functional correctness, stronger mitigation of model-related hallucinations, and research across code-generation tasks beyond NL2Code.
B. Implications
- Hallucination measures and benchmarks should complement functional-correctness evaluation, with automated detection developed to reduce the workload and subjectivity of manual review.These implications are directed to researchers and developers in software engineering and LLM fields.Source: 1) Implications for Researchers · p. 16, B. Implications · p. 16
1) Implications for Researchers:
- Advanced LLMs could detect hallucinations by using the taxonomy, representative examples, generated code, and context to identify whether a hallucination exists and its type.Source: 1) Implications for Researchers · p. 16
- Detection reliability could be improved with ensemble voting, coarse-to-fine classification, multiagent debates, or a critic model evaluating predicted types.Source: 1) Implications for Researchers · p. 16
- The manually annotated dataset could be expanded and used to fine-tune an LLM for supervised code-hallucination detection.Source: 1) Implications for Researchers · p. 16
- Because most hallucinations were attributed to model-related causes, researchers should investigate advanced training or fine-tuning, including reinforcement learning to improve chain-of-thought reasoning [61] [73] [76].Source: 1) Implications for Researchers · p. 16
- Retrieval-augmented generation and domain-specific knowledge warrant further study because external information may support and refine LLM reasoning [7] [44] [82] [87].Source: 1) Implications for Researchers · p. 16
- Hallucinations should also be studied in code translation, unit test generation [81], program repair, and code review [47] to inform task-specific mitigation.The study focused primarily on NL2Code generation; hallucination occurrence and distribution may differ across these other tasks.Source: 1) Implications for Researchers · p. 16
2) Implications for Developers: · C. Threats to Validity · VII. CONCLUSION
The paper characterizes code-generation hallucinations and their causes and impacts, offers training-free prompt-enhancement approaches, and discusses practical guidance, validity limitations, and future research.
2) Implications for Developers:
- Developers should select capable models and write clear, concise, complete prompts with detailed constraints to reduce hallucinations.The authors report that larger models tend to hallucinate less.Source: 2) Implications for Developers · p. 16
- Because hallucinations can be difficult to detect, developers should check and test generated code, then refine prompts using review and testing feedback [8] [57].The review should assess logical correctness and consistency with requirements.Source: 2) Implications for Developers · p. 16
C. Threats to Validity
- The external-validity study covers Python and Java tasks from two benchmarks, including standalone and repository-level function generation; evaluated models span open- and closed-source and general-purpose and code-specialized systems.The final three of four models introduced no new hallucination types, and hallucination proportions were consistent across evaluated models.Source: C. Threats to Validity · pp. 16–17
- The findings’ generalizability beyond the studied languages and code-generation scenarios remains to be explored.The authors identify other programming languages and scenarios as future areas of study.Source: C. Threats to Validity · p. 17
- Manual labeling of hallucination categories, causes, and impacts is subjective; a codebook and discussion-based conflict resolution improve reliability, but cannot eliminate subjectivity.LLM-based annotation may offer more objective and reproducible labels, although its reliability and validity remain open questions given limited interpretability.Source: C. Threats to Validity · p. 17
- To limit construct-validity variability, the study uses greedy decoding and consistent prompts, while noting prompt engineering can significantly affect generated-code quality.Prompts combine a role description with the dataset’s programming task description.Source: C. Threats to Validity · p. 17
VII. CONCLUSION
- The study develops a hallucination taxonomy through manual analysis and finds hallucinations often conflict with user requirements and can harm code functionality, readability, maintainability, and efficiency.The analysis also identifies model capabilities and prompt quality as influences on hallucinations.Source: §VII · p. 17
- The authors explore training-free prompt-enhancement techniques to mitigate code hallucinations and identify future research opportunities to improve code-generation reliability and trustworthiness.The replication package is publicly available.Source: §VII · p. 17
Related papers
This paper cites
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning2025
- LLaMA: Open and Efficient Foundation Language Models2023
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks2020
- Self-Refine: Iterative Refinement with Self-Feedback2023
- Survey of Hallucination in Natural Language Generation2022
- A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions2023
Cited by
- Progress Reward Model for Reinforcement Learning via Large Language Models2026
- How Developers Discuss Generative AI: A Longitudinal Study of the Visual Studio Code Community2026
- Adaptive Critical Token-Aware Retrieval for Repository-Level Code Generation2026
- Investigating Software Aging in LLM-Generated Software Systems across Generation-and-Execution Environments2026
- Evaluating Language Models on Cross-Language Code Functional Equivalence2026
- Evaluating Inference-Time Defenses Against Package Hallucination in LLM-Generated Code2026