Coding with AI
How to catch hallucinated library APIs in AI code
Verify package versions, exports and official documentation before accepting plausible methods or configuration.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Check the lockfile and installed type definitions or source, then confirm against official versioned documentation. A method may exist in a newer release, another language SDK or a blog example but not in the project you are changing.
What this means in plain English
AI tools sometimes produce a method that looks right but does not exist in the installed package. The method may belong to a newer release, another programming language or no real library at all.
Check package.json and the lockfile, then search installed types or source and official documentation for that exact version. Do not add random packages just to make invented code compile.
Does the installed version expose this exact interface?
| Version | Exact locked package release |
|---|---|
| Interface | Export, signature and runtime environment |
| Evidence | Types, source or official versioned docs |
A simple example
Generated code calls client.responses.streamText(), but the locked SDK exposes a different interface. Reading the installed type definitions reveals the real method. The team adapts the code without an unnecessary major upgrade.
What to do, step by step
1. Read package.json and lockfile.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on version: exact locked package release. Write the result down so you can compare it later.
2. Search installed declarations/source.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Run the smallest compile/runtime proof.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Upgrade only if the change is justified and tested.
Finish by checking the result against evidence: types, source or official versioned docs. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
When an upgrade is justified, treat it as its own reviewed change. New major versions can alter more than the one missing method.
Common mistakes and how to avoid them
Installing a new package to make invented code compile.
This gives a misleading or unsafe result because it leaves out version. A better approach is to read package.json and lockfile, then check the result before making the change permanent.
Using documentation for another major version.
This gives a misleading or unsafe result because it leaves out interface. A better approach is to search installed declarations/source, then check the result before making the change permanent.
Trusting autocomplete-shaped syntax.
This gives a misleading or unsafe result because it leaves out evidence. A better approach is to run the smallest compile/runtime proof, then check the result before making the change permanent.
Words explained
- API
- A defined way for one program to send requests to another program or service.
Quick checklist
- Read package.json and lockfile.
- Search installed declarations/source.
- Run the smallest compile/runtime proof.
- Upgrade only if the change is justified and tested.
Common questions
What is the simple answer?
Check the lockfile and installed type definitions or source, then confirm against official versioned documentation. A method may exist in a newer release, another language SDK or a blog example but not in the project you are changing.
What should I check first?
Start with version: exact locked package release. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Read package.json and lockfile. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Installing a new package to make invented code compile. Avoiding that one mistake makes the rest of the comparison much more trustworthy.