AI Wrote Code Using a Removed API: How to Fix It

When AI wrote code using a removed API, you are looking at one of three different problems wearing the same error message. The model's training predates the removal. The method never existed and the model invented it. Or the method exists, your installed version is simply not the one the model assumed. Each has a different fix, and the usual mistake is to start rewriting before working out which one you have.

The check that tells them apart takes under a minute: find out whether the symbol exists in the version you have installed, and whether it ever existed at all.

When AI wrote code using a removed API, check this first

Run this before you change any code. For a JavaScript project:

# what version is actually installed?
npm ls the-package

# does the symbol exist in it?
grep -rn "theMethodName" node_modules/the-package/ | head

For Python:

pip show the-package
python -c "import the_package; print([n for n in dir(the_package) if 'method' in n.lower()])"

Three possible outcomes, and they map exactly onto the three causes:

• The symbol is absent, and the package changelog shows it was removed in a version you are past. This is a training cutoff problem.

• The symbol is absent and the changelog never mentions it. The model invented it.

• The symbol is present but behaves differently, or is present in a newer version than the one installed. Version drift.

Cause one: the model's training predates the removal

The most common case, and the least interesting. The API existed, was widely documented, got removed in a major version, and the model learned the world as it was before that. The model is not wrong so much as out of date.

The fix is the migration guide, not the model. Libraries that remove public API in a major version are following semantic versioning, which requires a major bump for any backwards-incompatible change to the public API. That means a migration path almost always exists and is almost always documented. Find the release notes for the major version you crossed and apply the documented replacement.

Worth doing once rather than repeatedly: paste the relevant section of the current docs into the prompt. A model with the current API in context stops producing the old one, and this is considerably more effective than telling it to "use the latest version", which it cannot verify.

Cause two: the method never existed

This one looks the same in your editor and is a different thing entirely. The model produced a method name that fits the library's naming conventions, sits in a plausible place in the API surface, and has never existed in any version. The tell is the changelog: a method that was removed leaves a trace, and an invented one does not.

These are the hardest to spot by reading, because they are designed by construction to look right. user.findByEmailOrCreate() is exactly what that library would have called the method if it had one. This is ordinary invented detail from a language model applied to an API surface, and the defence is mechanical rather than attentive: run the code, and let the import or attribute error find it. Reading more carefully does not work reliably, which is one of the points our guide to reviewing AI-generated code makes about where human attention is and is not useful.

Cause three: version drift in your own tree

The subtlest of the three, and the one that produces the strangest bug reports. The model wrote code against a version of the library that is perfectly current. Your project is pinned to something older, or your lock file and your manifest disagree, or your environment resolved a different version than your colleague's did.

Here the generated code is correct and your environment is the problem. The signature of this cause is code that works on one machine and not another, or works in CI and not locally. Check the lock file rather than the manifest, because the lock file is what actually got installed:

# the resolved version, not the requested range
npm ls the-package --depth=0
cat package-lock.json | grep -A3 '"the-package"'

Agents make this worse than it used to be, because they modify dependency files as a side effect of other work. If your installed tree has moved and you did not move it, our explainer on lock files and why AI agents change them describes the mechanism and how to keep it from happening quietly.

Reducing how often this happens

1. Put the version in the prompt. "Using version 5 of this library" is a weak instruction; pasting the actual API reference section is a strong one.

2. Run the code before reading it. An import error finds an invented method in a second. A careful read may not find it at all.

3. Pin your dependencies and review lock file changes. Treat an unexplained lock file diff as a change, not as noise.

4. Expect it on fast-moving libraries. Packages that ship breaking changes frequently will generate this error frequently, whatever model you use.

The broader version of this problem, where the model itself is the thing that moved rather than the library, follows the same diagnostic logic. Our notes on what to do when an AI model gets deprecated cover that case, and the general question of picking tools that keep up is the subject of our AI coding tools guide.

Common questions

Does a newer model fix this?

It moves the cutoff forward, which helps with cause one and does nothing for causes two and three. A current model still invents plausible methods, and still cannot see your lock file.

Should I tell the model its training is out of date?

On its own that rarely changes the output. Supplying the current documentation does, because it replaces a claim about the world with content the model can read.

Is this more common with some languages?

It tracks ecosystem churn more than language. Fast-moving package ecosystems with frequent major versions produce this more often than conservative standard libraries.