How to fix: AI-generated code references a nonexistent API or package
Last verified: June 2026· AI coding agents
Where this shows up
AI coding agents
How it shows up
The same root cause surfaces in a few different ways. If any of these match, you're in the right place.
- An import or dependency that does not exist in any registry, failing at install or at build time.
- A call to a method on a real library that the library has never had, often with plausible naming and argument order.
- Code written against a version of an API that existed previously, or against a proposal that was never shipped.
- Confident inline comments describing behaviour the referenced function does not implement.
Diagnose it first
Confirm which cause you actually have before changing anything — most wasted time here comes from fixing the wrong one.
| Check | What the result tells you |
|---|---|
| Install and build in a clean environment before reviewing the logic. | A nonexistent package fails immediately here, which is the cheapest possible place to catch it. Reviewing logic first wastes attention on code that cannot run. |
| Type-check and run the tests. | Hallucinated methods on real libraries are caught by a type checker in typed languages and by the first test execution in untyped ones. This is the single highest-return control for this failure mode. |
| Look the symbol up in the official documentation for the pinned version. | A method that exists in the latest release but not the version you depend on is a different problem — a version mismatch, not a hallucination — and is fixed by upgrading rather than rewriting. |
| Check whether the package name resolves to something recently published. | A plausible but previously nonexistent name that now exists and is days old warrants scrutiny rather than relief, because name-squatting on model-suggested packages is a known supply-chain pattern. |
The fix
- 1Run the code: compile/type-check and run tests, which catch most hallucinated APIs immediately.
- 2Validate that any new dependency resolves to a known-good, existing package before installing it.
- 3Give the agent better context — accurate docs, types, and a rules file — so it relies less on guessing.
- 4Add a review hook in CI that flags new dependencies and missing tests on AI-generated diffs.
Provider-specific behaviour
The error means roughly the same thing everywhere, but each provider signals it differently.
- Why it happens
- A model generates the most plausible continuation, and a well-named function that ought to exist is highly plausible. This is why hallucinated APIs look so reasonable: they are what a sensible library would have provided, which is precisely what makes them hard to spot by reading.
- Version drift
- Training data spans a period during which libraries changed. Generated code frequently mixes idioms from several versions of the same library, which type-checks in parts and fails in others.
What doesn't work
Common fixes for this error that look right and aren't.
Installing the suggested package to see if it works.
If the name was hallucinated and now resolves, you have just installed something someone registered specifically because models suggest it. Verify provenance before installing, not after.
Asking the model to confirm whether the API exists.
It will often confirm confidently, because the same process that produced the hallucination produces the confirmation. Check the documentation or the registry, not the model.
Relying on review to catch these.
Reviewers reading for logic routinely miss a plausible method name on a familiar library. This class of defect is caught cheaply by tooling and expensively by humans, so it belongs in CI.
Prevent it
Treat AI-generated code as untrusted input: require tests, scan dependencies, and gate it in CI.
Common variations and related errors
You'll usually hit this same root cause under a few different names. Same fix.
- "model invented API"
- "hallucinated function call"
- "package does not exist"
- "no such method"
- "hallucinated import"
Frequently asked questions
What causes “AI-generated code references a nonexistent API or package”?
The model generated a plausible but nonexistent function, library, or dependency (a hallucination).
How do I prevent “AI-generated code references a nonexistent API or package” from recurring?
Treat AI-generated code as untrusted input: require tests, scan dependencies, and gate it in CI.
Why does the model invent packages that sound real?
Because it is producing the most plausible continuation, and a well-named library that ought to exist for a common task is extremely plausible. The output is not random — it is what a sensible ecosystem would have provided, which is exactly why it reads as correct. The same mechanism produces methods on real libraries that the library never had, often with idiomatic naming and the right-looking argument order.
What is the actual security risk?
Not the failed build, which is the good outcome. The risk is that a hallucinated name is plausible enough for someone else to register it, so that the next developer who accepts the same suggestion installs an attacker-controlled package. The control has to operate on whether a dependency existed and was trusted before the model suggested it — a provenance question your manifest-reading license scanner does not answer.
How do I prevent this systematically?
Make it a build concern rather than a review concern. Install and build in a clean environment, type-check, and run the tests in CI on every change, which catches nearly all of this class at zero marginal cost. Add a dependency allowlist or a provenance check on new packages so that adding one is a deliberate act. And pin versions, so generated code is checked against the API you actually depend on rather than the one the model remembers.