Use case
How do you approach this?
How to Spot Hallucinated APIs in Code
Published · Updated
Published by Unrust. Scoring and editorial method
Quick answer
Spot a hallucinated API by checking the proposal against the installed package and the exact version your project uses. Verify the import path, method name, parameter shape, return type, and error behavior at the call site. A method that sounds likely can still be absent, deprecated, available only in another version, or incompatible with the surrounding code's runtime assumptions.
Verify the source before adapting the call
Do not repair an unfamiliar call by guessing at a nearby API. Start with the package lockfile, local type definitions, generated docs, or official documentation for the version in use. That check is usually faster than building a chain of compensating changes around an invented method.
Check the boundary created by the call
Even a real method can be used incorrectly. Confirm what it accepts, whether it returns a value or promise, how it signals failure, and whether the proposal handles the result according to the codebase's conventions. Imports and types are evidence, not a substitute for a behavior check.
Verify the method exists before trusting the name
Return distinct primitive IDs in their first-seen order using standard JavaScript built-ins. No project extension adds an Array.unique method.
The plausible method name throws before producing a result. A Set supplies the documented operation for these primitive values. This example does not define structural equality for objects; that would need a different contract and tests.
The outcomes below are checked by executable tests against the exact displayed snippets. NaN and undefined are written by name so they remain visible in the table.
function run(ids) {
return ids.unique();
}function run(ids) {
return [...new Set(ids)];
}| Arguments to run | Before | After |
|---|---|---|
| ["a", "b", "a"] | "TypeError" | ["a", "b"] |
| [] | "TypeError" | [] |
Practice loop
- 01For an unfamiliar call, locate its installed declaration or official documentation before editing arguments.
- 02Compare the documented return and failure behavior with the branch that consumes it.
- 03Add a focused test or type check that would fail if the method or signature were wrong.
Limits of this page
Documentation and type declarations can still lag behind deployment configuration, feature flags, or runtime permissions. This page gives a verification habit, not a guarantee that one session can measure API knowledge or explain why a proposed call initially seemed believable.
Source context
Published by Unrust as practical teaching material using public language documentation and original examples. See the scoring and editorial method for scope, checking and limitations.
Check your own starting point
One diagnostic session is a snapshot, not causal proof of why a result occurred. It can help you choose a focused next practice step without making a broader claim about your ability.
Take the free diagnostic