Ask an AI coding assistant to solve a problem it has seen a thousand times and it will usually reach for a real library, a real method, a real pattern. Ask it something slightly off the beaten path and it will sometimes do something stranger: it will invent one. A package name that sounds exactly right and resolves to nothing. A method on a well-known class that was never part of its API. An import statement for a library that simply does not exist, written with the same confident syntax as every other line around it.
This is not a rare glitch. Researchers studying code-generation models have found hallucinated package names showing up in a meaningful share of generated snippets across multiple languages, and the problem has a name now: package hallucination. It matters more than a typo would, because a hallucinated package name is not just wrong, it is an opening. Attackers have started registering the exact fake names models tend to invent, so that the next developer who copies the suggestion and runs an install command pulls down real, malicious code.
It is a problem 137Foundry's AI automation team runs into constantly, because the clients asking for help wiring an AI coding assistant into a real workflow are usually already using one daily, and usually have no formal process for catching a suggestion that only looks correct.
Why AI Coding Assistants Invent APIs in the First Place
A code-generation model is predicting the most statistically plausible next token, not looking anything up. Most of the time those predictions land on something real, because real APIs are what the model was trained on. But when a prompt describes a need that sits between two real patterns, or asks for a library slightly outside the model's strongest training distribution, the most "plausible-sounding" completion can be a name that was never real to begin with.
The underlying phenomenon is the same one behind hallucinated facts and citations in other AI outputs, see the general overview on Wikipedia for how the term is used across model types. Code hallucination is a special case of that broader pattern, made worse by the fact that code either runs or it doesn't, and a hallucinated package name fails loudly at install time rather than quietly at read time.
That said, "fails loudly" only helps if someone is watching for the failure. A hallucinated import that gets pasted into a private branch, run once locally, and then quietly swapped for a real package after an error message is a near miss nobody logs anywhere. The same hallucination in a script that runs unattended, a scheduled job, a CI step, or a colleague who copies a snippet without running it first, can travel a lot further before anyone notices.
Photo by Ron Lach on Pexels
Two Different Failures Hide Behind the Same Word
"Hallucination" gets used loosely, but catching it requires treating two distinct failures differently. The first is a hallucinated package: an import or dependency reference to something that does not exist in the registry at all. The second is a hallucinated API surface: a real, installed library, but a method, argument, or return type that library never actually shipped.
The first kind fails fast and loud, usually the moment someone runs an install command. The second kind is more dangerous precisely because it can compile or run without error in some cases, especially in dynamically typed languages, and only surface as a bug much later, often in production rather than in review.
Package Hallucinations Are a Security Problem, Not Just a Build Error
Treat a hallucinated package name as a security finding, not a typo. The attack, sometimes called slopsquatting, works because it does not require tricking anyone. It only requires that an AI assistant invent the same plausible-sounding fake name often enough that an attacker can predict it, register it on a real public registry, and wait.
Both major package ecosystems make it straightforward to check whether a name is real before you trust it. For JavaScript and Node projects, search the package directly on npm rather than trusting the assistant's import line. For Python projects, do the same against PyPI. A package with zero downloads, a publish date from last week, and a description that reads like it was written to match a common AI suggestion is a strong signal to stop and verify manually before anyone runs an install.
How to Catch a Hallucinated Package Before It Ships
The fix does not require banning AI-suggested dependencies, it requires a checkpoint between suggestion and installation. Before a new package name from an assistant reaches your lockfile, check three things: that it exists on the registry your project actually uses, that its download count and maintenance history look like a real, actively used project, and that the version the assistant suggested is one that actually exists for that package.
Lockfile discipline does a lot of the remaining work. A package-lock.json, poetry.lock, or equivalent that only updates through a reviewed pull request means a hallucinated dependency has to survive human eyes before it becomes part of the build, rather than silently entering through an unreviewed local install.
Photo by Tima Miroshnichenko on Pexels
How to Catch a Hallucinated Method or API Call
Hallucinated method calls are harder to catch by eye because the surrounding code usually looks completely normal. The most reliable defense is tooling that actually checks the claim rather than trusting it. Static type checkers catch a large share of these automatically: in Python, running mypy against generated code will flag a call to a method or argument that a typed library genuinely does not expose, well before the code ever runs.
For JavaScript and TypeScript, a strict linter configuration does similar work. ESLint rules that flag unresolved imports and unknown members catch a hallucinated API call at lint time instead of at runtime, which is a much cheaper place to find it. Neither tool replaces a human reviewer, but both turn an invisible problem into a build failure with a clear error message, which is a far better place for it to surface.
Build Verification Into the Review Step, Not Just Into CI
CI checks catch a hallucination after the fact, once a pull request already exists. The cheaper place to catch it is in the review itself, before a reviewer's attention has moved on to the next thing. When a diff includes a new import or a call to an unfamiliar method on a familiar library, treat "does this actually exist" as a normal review question, the same way a reviewer would question an unfamiliar SQL query or an unusual regular expression.
"The AI-generated code that causes real damage is never the code that looks obviously wrong. It's the import that looks completely normal, references a package that was registered by an attacker three weeks ago, and sails through review because nobody thought to check." - Dennis Traina, founder of 137Foundry
The OWASP Cheat Sheet Series has general dependency and supply-chain guidance worth folding into a review checklist even outside the AI-generated case, since the underlying risk of trusting an unverified dependency predates AI coding assistants by decades.
Photo by Valentin Lacoste on Unsplash
Give the Assistant Enough Real Context to Stop Guessing
A surprising amount of hallucination comes from an assistant working with too little grounding, not from the model being unreliable in general. When a prompt includes the actual installed package versions, a snippet of the real API from your own dependency, or a link to the specific documentation page you want it to follow, the completions that come back are far more likely to reference things that are actually real.
This is one of the places where 137Foundry's AI automation work spends real time with clients: wiring an assistant into a codebase so it can see actual installed versions and real type definitions, instead of guessing from training data that may be a year or two out of date relative to the library version the project actually uses.
Photo by Christina Morillo on Pexels
Know When to Trust the Suggestion and When to Stop and Check
Not every AI-suggested import needs a full investigation. A well-known package already in your lockfile, suggested for a use case it is commonly used for, is low risk. The moment to slow down is a package name you have never heard of, a method call on a library you know well that does not match your memory of its API, or any suggestion involving authentication, payments, or data handling where a mistake is expensive.
That risk-based instinct is worth writing down as an actual team norm rather than leaving it to individual judgment, the same way most teams already have a norm for when a database migration needs a second reviewer. Teams building this into a formal front-end or back-end workflow for the first time often start by adding it to whatever checklist already governs new dependencies, rather than inventing a separate process just for AI-suggested ones. 137Foundry's web development engagements usually fold this straight into the existing dependency review step clients already have, instead of bolting on something new.
What Skipping This Actually Costs
Most hallucinated packages never get registered by anyone malicious, and most hallucinated method calls get caught by a type checker or a test long before they reach production. The cost of skipping verification is not that it always goes wrong, it is that when it does go wrong, it looks exactly like normal, trusted code until the moment it doesn't. A team that treats "does this dependency actually exist and do what it claims" as a routine review question pays a small, constant cost. A team that skips it pays nothing, repeatedly, right up until the one time it pays a great deal at once. If your team wants a second set of eyes on how AI-assisted code moves through review before it ships, 137Foundry's engineering services team has built that checkpoint into client workflows enough times to know where it usually needs to sit.
