Why AI coding tools invent APIs that do not exist

Prediction, not lookup

A model generating an import line is doing the same thing it does when generating prose. It is predicting what token is likely to follow, based on the distribution of text it was trained on. The study on package hallucinations makes the point bluntly: the model is not looking up real packages, so sometimes the prediction lands on one and sometimes it does not.

That explains the pattern of where it goes wrong. Hallucination rises where the model has seen an API less often, which the research on mitigating code hallucinations with API documentation attributes to low-frequency APIs and to the fact that APIs keep moving. Libraries add functions, rename parameters and deprecate methods, and a model trained on a snapshot of the internet carries several versions of a library in its weights at once. Ask for something popular and stable and you get code that mostly works. Ask for the flag that was added last quarter, or the one that was removed, and you get a confident guess.

There is a second, less obvious factor: how the model behaves in general. The models most willing to reach for an unusual library are the ones most likely to reach for one that does not exist.

Errors also compound. The same paper describes a snowball effect, where a hallucinated API call leads to hallucinated handling of its response in the code that follows. A single invented function does not sit quietly in one line. It shapes the next twenty, so the surrounding code reads as coherent and reinforces the mistake.

The shapes an invented API takes

“Hallucinated API” covers several distinct failures, and they are not equally easy to spot. One category, identifier knowledge conflicts, covers the model misusing a variable or function it defined itself a few lines earlier.

In descending order of how quickly you will notice:

• A package that does not exist. import yaml_parser when the real library is pyyaml. This one surfaces at install time, unless somebody has registered the name.
• A function that does not exist on a real package. Fails at runtime.
• A real function with the wrong signature. A parameter that belongs to a different version, or a keyword argument that was never there. Fails at runtime, sometimes only on an unusual path.
• A real function used wrongly. No guard on a value that can be null, no handling of the exception the library documents. This runs fine until it does not, and it is the one that reaches production.

What makes all of these hard to catch by reading is that the invented names are not gibberish. The researchers found the majority of hallucinated package names were substantively different from existing names, yet those names fit their context convincingly. yaml_parser is exactly what a YAML parser would be called if somebody had called it that.

Scale matters too. API hallucinations make up a meaningful share of a problem that is itself concentrated in API-heavy work: the glue code, the SDK calls, the cloud integration.

How often it actually happens

The best public baseline comes from the paper on package hallucinations.

When an invented name becomes an attack

A package name that does not exist is a bug. A package name that does not exist and is predictable is a supply-chain opening. Slopsquatting is the term for registering a non-existent package name that a model is known to hallucinate, so that the next developer who copies the generated install command pulls the attacker’s code.

Agentic tools raise the stakes, because the thing that used to require a human to copy and paste now happens inside a loop that installs dependencies on its own. That is one of the reasons to be deliberate about when you hand work to an agentic coding tool rather than an inline assistant, and one of the specific items worth naming in an AI code policy covering security and IP.

Catching it: run the code, then distrust the install

The cheapest detection is execution. Code has an executable ground truth, which is the one advantage this problem has over hallucination in prose: an invented function raises an ImportError or an AttributeError the first time the line is reached. If generated code has never been run, you have not checked it, you have read it.

Running it is necessary and not sufficient, for two reasons. A misused real API runs happily until the edge case arrives, so you need tests that exercise the path, not just an import that succeeds. And an invented package name that somebody has already registered will install without a murmur. “It installed” tells you a name exists on a registry. It tells you nothing about who put it

---

Written with AI assistance and reviewed under our editorial policy. Vibe coding changes quickly; details reflect sources current on 2026-09-14. Some passages are the author's opinion. Spotted an error? tell us.