The AI builder used a function, package, or API that does not exist
Filed under AI builder problems (Lovable, Bolt, Replit)
The builder predicted what the API probably looks like instead of checking it, and invented a function, package, or parameter that follows the library's style but was never real.
Fastest route
Give your AI this prompt
Copy it, replace the bracketed part with your error, and send it.
Preview the prompt
Your last change used [the function / package / parameter] which does not exist. The error is: [paste it — e.g. "X is not exported from Y" or "… is not a function"]. Do not guess another name. Here is the ground truth I verified myself — the official documentation / the package's actual exports: [paste the docs section, the API reference, or the list of real exports]. Please: 1) rewrite the code using ONLY functions and parameters that appear in what I pasted, 2) if what I asked for cannot be done with this API, say that clearly and suggest the closest documented alternative — do not invent one, 3) list every place in the project where the invented name was used, so we remove all of them, 4) confirm which version of the library your rewrite targets: [the version from your package.json]. From now on in this project: before using any library function you have not already used here, state its documented name and signature first.
Fix it yourself
Follow the repair
- Recognise the signature and stop the guessing loop. The giveaway is a confident, tidy block of code that fails on a name: an export that does not exist, a method that is "not a function", a package that will not install. When you see that shape, do not say "fix it" and let the builder try another plausible name — each guess is written into more files, and soon you have invented code calling invented helpers. One round of guessing is a mishap; three rounds is an architecture. Stop at the first unexplained name.
- Check the name against ground truth you control. Pick the suspect function, package, or parameter and verify it somewhere that cannot hallucinate. For a package: its page on npmjs.com — does it exist, who publishes it, when was it last updated, how many downloads does it have? For a function in a package you already have: search your project's node_modules for the name in the package's type definitions (the .d.ts files list every real export). For a service's API: the official documentation or API reference. Two minutes here settles what an hour of arguing with the builder cannot.
- If the package does not exist, treat the name as burnt. Never install a package just because the builder insists it is the right one, and be extra careful with a similar-looking name that does exist — attackers register plausible package names precisely to catch people following AI suggestions. Remove the import, and choose the replacement from the official docs of the service you are using, or a well-known package you verified on npm yourself. The feature gets built on a library that demonstrably exists.
- Paste the real documentation into the chat. This is the step that actually cures it. Copy the relevant section of the official docs — the function list, the API reference for the endpoint, the example code — and paste it into the conversation with a plain instruction: rewrite using only this. The builder writes excellent code when the truth is in front of it; it invents when the truth is absent. You are not doing its job for it — you are handing it the map it was pretending to have.
- Make it show its sources before it writes the next unfamiliar call. Change the standing rule for this project: when the builder wants to use a library or API it has not already used successfully here, it must first state which documented functions it plans to call, and say so plainly if the thing you asked for does not exist rather than inventing a stand-in. Also pin down versions — "use the API as of version X, the one in my package.json" — because half of these failures are the builder writing for a version you do not have.
- Verify the repair like a sceptic. After the rewrite, run the app and exercise the exact feature, not just the build. A build passing means the names exist; only clicking the thing proves the documented function does what you wanted. Watch for quiet substitutions too — a builder that could not find the real function sometimes wires the button to a simpler lookalike behaviour and reports success. Test the behaviour, then move on.
Why this happensOptional explanation
AI models write code the way they write sentences: by predicting what most plausibly comes next, based on enormous amounts of code they have seen. Real APIs have patterns — getUser, createSession, sendMessage — so a predicted call often looks exactly like something a library would offer, follows its naming style, and takes the parameters you would expect. The builder is not lying to you and it is not broken. It genuinely cannot tell the difference between a function it remembers and a function it has smoothly invented, and it reports both with the same confidence.
The invention takes a few familiar shapes. A method that does not exist on a real library ("client.users.verify()" when the library never had it). A package that sounds right but was never published — or worse, a name someone else has since registered with junk in it. A real function called with a parameter from a different library, or from a newer or older version than the one in your project. The tell is in the errors: "X is not exported from Y", "… is not a function", an install that fails — the code reads beautifully and then reality declines to run it.
- Invented function: a method or export that follows the library's style perfectly but was never part of it.
- Imaginary package: an npm package name that sounds official and does not exist — check before you ever install its namesakes.
- Version drift: a real API, but from a different version than your project uses — renamed, moved, or not yet released in yours.
- Mixed-up libraries: a parameter or pattern borrowed from a similar tool and applied to yours, where it means nothing.
Quick answers
Doesn't the AI know when it is making something up?
Not in any way it can report to you. The model predicts what code most plausibly comes next, and an invented function that follows a library's naming patterns feels identical to a remembered one — both come out in the same confident tone. That is why verification has to happen outside the chat: docs, the package's own files, the registry.
The package it named does exist on npm. Should I install it?
Caution — treat it as untrusted until you have checked it yourself. Attackers register plausible names hoping people install them on an AI's say-so. A legitimate package has a real publisher, a history, meaningful download numbers, and documentation; if any of that is missing, choose a well-known alternative you found through the service's official docs.
Is pasting documentation really worth the effort?
Very — it is the single most reliable cure. Builders write accurate code when the real API reference is in the conversation and inventful code when it is not. Pasting the relevant docs section turns the next attempt from a prediction into a transcription, and it costs you two minutes instead of an afternoon.