💬 NLP

Library Hallucinations in LLM-Generated Code: A Risk Analysis Grounded in Developer Queries

This paper presents the first systematic study of how realistic developer prompt variations, such as misspellings and fabricated names, trigger library hallucinations in LLM-generated code, revealing significant vulnerabilities and introducing the LibHalluBench benchmark to enable reproducible evaluation and mitigation of these risks.

Original authors: Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

Published 2026-05-20

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Lukas Twist, Jie M. Zhang, Mark Harman, Helen Yannakoudakis

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a very talented, confident, but slightly forgetful assistant who is an expert at writing computer code. You ask them to build a specific tool, and they happily start typing. However, this assistant has a dangerous habit: sometimes, when they don't know the exact name of a tool they need, they just make one up. They invent a library (a pre-made collection of code) that doesn't exist, but they write it down with such confidence that you might not realize it's fake until you try to use it and it breaks.

This paper is a deep dive into why this assistant makes up these fake tools, specifically when you give them slightly different instructions or make small mistakes.

Here is the breakdown of their findings using simple analogies:

1. The "Time Travel" Trap

The researchers found that if you ask your assistant for a tool "from 2025" (a year that hasn't happened yet or is beyond their training), the assistant gets very nervous and starts hallucinating wildly.

The Analogy: Imagine asking a librarian for a book published in the future. Instead of saying, "I don't have that," the librarian might invent a title, a cover, and a summary that sounds perfect but doesn't exist.
The Result: When asked for libraries "from 2025," up to 85% of the time, the assistant invented a fake library. They are terrible at knowing their own "knowledge cutoff" (the date they stopped learning).

2. The "Typo" Trap (Sloppy Spelling)

If you accidentally misspell a real library name, the assistant often doesn't correct you. Instead, they double down and pretend the misspelled version is real.

The Analogy: Imagine you ask a chef for "Spagetti" (missing the 'h'). Instead of saying, "Did you mean Spaghetti?", the chef might just grab a box labeled "Spagetti" from a shelf they made up, or worse, they might invent a new dish called "Spagetti" that doesn't exist.
The Result:
- A one-letter typo (like numpi instead of numpy) caused fake libraries to be used in 26% of cases.
- A fake library name (something that sounds real but isn't, like "GaussianTools") was accepted and used in up to 99% of cases. The assistant is so eager to please that they will use a fake tool rather than tell you it doesn't exist.

3. The "Adjective" Trap (What Doesn't Work)

Interestingly, if you ask for a library that is "fast," "easy," or "modern," the assistant usually ignores those words and just picks a standard, real library they know.

The Analogy: If you ask for a "fast car," the assistant just gives you a standard Toyota. They don't invent a "super-fast-flying-car" because they know those adjectives are vague.
The Result: Adjectives like "fast" or "lightweight" rarely caused hallucinations. The danger comes from specific constraints (like dates) or errors (like typos).

4. The "Reasoning" Trap (Thinking Too Hard)

The researchers tried to fix this by telling the assistant to "think step-by-step" or "check your facts" before answering.

The Analogy: It's like telling a nervous student, "Take a deep breath and think hard about this math problem." Sometimes, this helps. But often, the student just gets more confident in their wrong answer because they spent more time justifying it.
The Result: These "reasoning" tricks didn't work consistently. In fact, they sometimes made the hallucinations worse. The assistant would confidently explain why their fake library was real, making it harder for you to catch the mistake.

5. The "Tool" Solution (Checking the Phone Book)

The researchers tested giving the assistant a simple tool: a button that checks if a library actually exists in the official database (PyPI).

The Analogy: Instead of the assistant guessing, you give them a phone book. If they say "I'll use Spagetti," they check the book, see it's not there, and then say, "Oh, that doesn't exist."
The Result: This helped a lot, but it wasn't a magic fix. The assistant still sometimes forgot to check the book, or checked it but decided to ignore the result and use the fake name anyway.

The Big Takeaway: LIBHALLUBENCH

Because this is such a big problem, the authors created a new test called LIBHALLUBENCH.

The Analogy: Think of this as a "driving test" specifically designed to see if a self-driving car will hallucinate a fake stop sign. It contains thousands of tricky questions (like "give me a library from 2025" or "use this misspelled name") to systematically test how likely different AI models are to make up fake tools.

Why Should You Care?

If you are a developer using AI to write code, and the AI invents a fake library, your code will crash when you try to run it. Even worse, if a hacker creates a fake library that matches the one the AI invented (a trick called "slopsquatting"), your system could get infected with malware.

In short: AI code generators are great, but they are dangerously confident when they don't know the answer. They will invent fake tools to satisfy your request, especially if you ask for something from the future or make a small typo. We need better ways to stop them from making things up.

Technical Summary: Library Hallucinations in LLM-Generated Code

Problem Statement

Large Language Models (LLMs) have become integral to modern software development, yet they frequently "hallucinate" by inventing non-existent libraries. While previous research has acknowledged library hallucinations as a failure mode, there is limited understanding of how these errors manifest under realistic usage conditions. Specifically, it remains unclear how variations in developer prompts—such as natural language descriptions, user typos, or fabricated library names—influence the rate at which LLMs generate invalid imports or invalid calls to valid libraries. These hallucinations pose significant risks, including broken builds, misleading developers, and exposure to supply chain threats like "slopsquatting" (where attackers register libraries that LLMs frequently hallucinate).

Methodology

The authors present the first systematic study of how user-level prompt variations influence library hallucinations across seven diverse production-grade LLMs (GPT-4o-mini, GPT-5-mini, Ministral-8B, Qwen2.5-Coder, Llama-3.3, DeepSeek-V3.1, and Claude-4.5-Haiku).

Experimental Design:
The study utilizes BigCodeBench as a seed dataset, filtering for 356 Python tasks that use external libraries. The experiments are divided into two primary categories:

Experiment 1: User Language Variations:
- Data Source: Over 20,000 questions from Software Recommendations StackExchange (SRSE) were analyzed to identify common user descriptors.
- Variations: Prompts were modified to include adjective-based descriptions (e.g., "fast," "lightweight," "best") and time-based descriptions (e.g., "from 2023," "from 2025").
- Goal: To determine if natural language variations trigger hallucinations.
Experiment 2: Controlled User Mistakes:
- Error Types: The study introduced specific errors into prompts:
  - One-character misspellings (Edit distance 1, e.g., numpi for numpy).
  - Multi-character misspellings (Edit distance 2–8, e.g., graphly for plotly).
  - Fake names/members: Completely non-existent libraries or members generated to simulate follow-up requests for previous hallucinations.
- Goal: To quantify LLM robustness against typos and fabricated entities.

Evaluation Pipeline:

Detection: Generated code was parsed using Python's ast module. Library names were verified against the Python Package Index (PyPI) with normalization, and library members were verified against official documentation of the latest library versions.
Metrics: The study measured Response Hallucination Rate (RHR) and Task Hallucination Rate (THR).
Additional Investigations: The authors examined the efficacy of prompt engineering strategies (Chain-of-Thought, Step-Back, Self-Analysis) and tested ecosystem generalizability using CodeInsight (JavaScript, Rust) and tool-augmented mitigation (PyPI existence checks).

Key Findings

1. Sensitivity to Prompt Variations

Adjectives vs. Time: Adjective-based descriptions (e.g., "fast," "open-source") rarely triggered hallucinations (rates $\approx$ 0%). In contrast, time-based prompts were a strong trigger. Requests for libraries "from 2025" induced hallucinations in up to 85% of tasks (specifically for GPT-4o-mini), significantly higher than requests for "from 2023."
User Mistakes: LLMs showed poor robustness to naming errors.
- One-character misspellings triggered hallucinations in up to 26% of tasks.
- Multi-character misspellings triggered hallucinations in up to 79% of tasks.
- Fake library names were accepted in up to 99% of tasks for certain models (e.g., GPT-5-mini, Ministral-8B), indicating a tendency toward "sycophancy" where the model complies with the user's incorrect premise rather than correcting it.

2. Library Name vs. Member Hallucinations

Library Names: Models were highly susceptible to hallucinating entire non-existent libraries when prompted with errors or time constraints.
Library Members: Hallucinations of members (functions/classes) within valid libraries were generally lower (mostly 1%–5%) but still present. Interestingly, newer models (GPT-5-mini, DeepSeek-V3.1) sometimes exhibited higher member hallucination rates than older ones, often suggesting deprecated functions without version specifications.

3. Mitigation and Generalizability

Prompt Engineering: Lightweight strategies like Chain-of-Thought and Step-Back prompting were unreliable and sometimes increased hallucination rates by reinforcing incorrect reasoning. Explicit checks and Self-Analysis showed more promise but were inconsistent across models.
Tool Usage: Providing a PyPI-existence tool reduced hallucinations significantly (e.g., GPT-4o-mini dropped to <3% for year-based prompts) but did not eliminate them. Models often failed to invoke the tool or ignored negative results.
Ecosystems: The patterns of hallucination persisted across Python, JavaScript, and Rust, suggesting the vulnerability is not limited to a single language or ecosystem.

Contributions

Systematic Study: The first fine-grained analysis of how prompt variations (language and errors) affect library hallucinations, revealing that time-based phrasing and typos are critical triggers.
Sycophancy and Typosquatting Link: The paper uncovers a novel connection between LLM behavior and supply chain risks, demonstrating that models often confidently hallucinate libraries in response to minor typos, potentially amplifying typosquatting and slopsquatting attacks.
LIBHALLUBENCH: Introduction of a new benchmark containing 4,173 labelled prompts derived from high-risk conditions (year-based, rarity-based, and error-based) to enable reproducible evaluation of library hallucinations.
Open Resources: Release of code, full model outputs, and the benchmark to support future research and mitigation development.

Significance and Claims

The paper argues that the fragility of LLMs to natural prompt variations constitutes a systemic vulnerability. The authors claim that:

Current LLMs cannot be relied upon to validate library names or members, even when users provide specific (but incorrect) names.
Common developer requests for "up-to-date" or "recent" libraries are a primary vector for hallucination, independent of knowledge cutoffs.
Existing mitigation strategies like Chain-of-Thought are insufficient for this specific failure mode.
The risk extends beyond mere code errors to security threats, as the high acceptance rate of fake libraries could facilitate the adoption of malicious packages (slopsquatting).

The authors conclude that robust defenses require more than prompt engineering; they likely necessitate model-level changes, external verification mechanisms, and a shift in how LLMs handle uncertainty regarding library validity. The study emphasizes that while the findings are based on specific datasets and models, the observed patterns suggest a broader, systemic issue in LLM-based code generation.