A hallucinated API is an invented method, option, or endpoint whose plausible name makes it look real. Models invent whole packages the same way.
Let the compiler, type checker, or language server flag unknown symbols.
In dynamic code, run a focused experiment instead of trusting an explanation.
Check unfamiliar calls in the official documentation for the version the project installs.
Review a package's registry entry, publisher, and source before installing it. Invented names are a supply-chain risk, because an attacker can publish a real package under one.
Keep new dependencies behind human approval.
When sources conflict, trust the executable project and authoritative documentation over the model's confidence.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
Why do models invent API names that look so plausible?They predict likely text from patterns across many libraries and versions, so a name that fits the conventions scores high whether or not it exists.
Your type checker passes, yet the code uses an option that doesn't exist. How did it get through?Name the gaps: untyped option bags or kwargs, any-casts, dynamic lookups, and type definitions that don't match the installed version.
An agent adds a dependency you've never heard of. What do you check before approving it?Registry entry, publisher and history, a source repo that matches the package, install scripts, and whether an existing dependency already covers it.
How would you catch invented packages automatically in CI instead of relying on reviewers?Flag new lockfile entries for approval, resolve against an allowlist or internal registry proxy, and fail the build on unresolved imports.
A hallucinated API is a method, option or endpoint the model made up, with a name plausible enough to look real, and models invent whole packages the same way.
The cheapest check comes first, because the compiler, type checker or language server flags a symbol that doesn't exist.
In dynamic code nothing flags it for me, so I run a small focused experiment instead of trusting the model's explanation.
For any unfamiliar call I check the official docs for the version the project actually installs, not the latest one.
Packages are worse, because an attacker can publish a real package under an invented name, so I check the registry entry, publisher and source, and new dependencies need human approval.
The limit is that the model sounds just as sure when it's wrong, so when sources disagree I trust the project that runs and the official docs over the model.
Weak answers to avoid
Asks the model whether it's sureThe model is just as confident when it's wrong. Name a check outside the model instead, like the type checker, a quick experiment, or the docs for the installed version.
Treats it as a bug the tests will catchMisses the package case. Installing an attacker's package can run their code before any test does, so cover registry checks and human approval of new dependencies.
Checks the docs but not the installed versionA method can exist in the latest release and be missing from the one the project pins. Say you check the docs for the version the project actually installs.
Stops at the definitionThe question asks how you catch one. Walk through the actual checks, from the compiler to dependency approval, and say which source you trust when they disagree.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
