A hallucinated API or package is a name that the model invents even though it does not exist. It may suggest a believable method, configuration option, or dependency because the name fits common patterns. The generated code can appear correct until it is compiled or run.
Use the compiler, type checker, and language server as the first check.
For dynamic languages, run focused tests immediately.
Confirm unfamiliar methods in the official documentation for the version your project uses.
Before installing a suggested package, inspect its official registry page, repository, maintainers, release history, and usage. Attackers sometimes register names that models often invent.
Require human approval for new dependencies, especially when an agent can run package-install commands.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
An agent in your setup can run package installs. What guardrails would you put around that?Human approval for installs, an allowlist or internal registry, lockfile diffs in review, and a sandbox without secrets since install scripts can run code.
Why are hallucinated methods harder to catch in Python or JavaScript than in Java or TypeScript?No compile step, so the error shows up only when that line runs. Tests that hit that path, plus type hints and a type checker, catch most of these.
The method is real, but only in a newer version than the one you use. How do you catch that?Read the docs for the pinned version, trust the installed package's type definitions, and run the build and tests against the lockfile.
How would you make the model less likely to invent an API in the first place?Give it real context such as docs, type definitions and existing call sites, and let it run the compiler or tests in a loop to fix its own errors.
What you can say
A hallucinated API or package is a name the model made up. It's a method, config option or dependency that sounds right because it fits common patterns, but it doesn't exist.
The trouble is that the code looks correct, so you usually find out only when you compile or run it.
My first check is the compiler, type checker and language server, which flag an unknown method right away. In Python or JavaScript I run a focused test immediately.
If a method is unfamiliar, I look it up in the official docs for the version our project actually uses.
Packages need more care, because attackers register names that models tend to invent. Before installing one, I check its registry page, repo, maintainers, release history and usage.
It adds some friction, but I'd require a human to approve any new dependency, especially when an agent can run install commands on its own.
Weak answers to avoid
Says 'just review the code carefully'A made-up method reads as plausible, so eyes miss it. Name the tools that catch it: compiler, type checker, language server, and a quick test run.
Treats it as only a correctness bugA made-up package name can point to a real malicious package someone registered. Mention checking the registry and requiring approval for new dependencies.
Trusts the package because it installedA successful install proves the name exists, not that it is the right or safe package. Check the maintainers, release history, repo and usage.
Checks the latest docs, not your versionA method can exist in one version and not in the one you pin. Look it up in the official docs for your project's version.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
