How to stop AI coding tools from hallucinating fake APIs and packages

AI coding tools occasionally invent packages that don’t exist, a problem now commonly called slopsquatting: attackers register the fake package name the AI keeps suggesting, and the next developer who blindly runs npm install pulls in malware instead of a 404. This isn’t rare edge-case behavior — it happens often enough that you need a standing checklist before installing anything an AI recommended.

Why this happens

• Models predict plausible-sounding names based on naming patterns, not a live registry lookup.
• A package that “should” exist given the ecosystem’s conventions often gets hallucinated with total confidence.
• Older training data means a model may suggest a package that existed once, got deprecated, and was later re-registered by someone else with different code inside it.

The checklist: run this before npm install

#!/usr/bin/env bash
# verify-package.sh — run before installing anything an AI suggested
PKG="$1"

if [ -z "$PKG" ]; then
  echo "Usage: ./verify-package.sh "
  exit 1
fi

echo "== Registry check =="
npm view "$PKG" name version publisher time.created 2>/dev/null || {
  echo "WARNING: package not found on npm registry. Do not install."
  exit 1
}

echo "== Age and popularity =="
npm view "$PKG" time.created
npm view "$PKG" downloads 2>/dev/null

echo "== Repository link =="
npm view "$PKG" repository.url

echo "== Maintainers =="
npm view "$PKG" maintainers

Save that as verify-package.sh, make it executable with chmod +x verify-package.sh, and run ./verify-package.sh some-package-name before every install an AI tool suggested and you haven’t personally used before.

What to actually check in the output

• Does it exist at all? If npm view returns nothing, stop. Don’t assume it’s just unpublished — hallucinated names are the more common explanation.
• Creation date: a package created last week with a name that matches a well-known library convention is a red flag for typosquatting or slopsquatting.
• Download counts: near-zero downloads on a package the AI described as “the standard library for X” is inconsistent and worth investigating.
• Repository link: no linked repo, or a repo with almost no commit history, is another warning sign.
• Maintainer identity: search the maintainer’s other published packages; a single-package account with a recently created npm profile is riskier.

Beyond npm: APIs, not just packages

The same hallucination pattern shows up with API endpoints and method names, not just packages. Before trusting an AI-suggested API call:

• Open the official docs for that exact SDK version and confirm the method signature exists.
• Check the changelog if the method looks like it belongs to a newer or older major version than the one you have installed.
• Run it against a sandbox or staging environment first, never production, especially for anything billing- or auth-related.

Make it a habit, not a one-off

The fastest fix is a pre-install hook in your team’s workflow: nobody merges a PR that adds a new dependency without running the verification script and pasting the output in the PR description. It costs thirty seconds and catches the failure mode that costs days to clean up after a breach. For more on building disciplined habits around AI-assisted coding, see how to build a serious dev workflow around Claude.

Quick FAQ

How common is slopsquatting really?

Studies on AI-generated code have found hallucinated package names in a meaningful percentage of generated snippets, and attackers actively monitor for popular hallucinated names to register.

Does this only affect npm?

No, the same risk applies to PyPI, RubyGems, and any other package registry — the verification logic is the same, just swap the command.

Can I automate this check in CI?

Yes, wrap the verification script in a CI step that runs on any PR touching package.json and fails the build if a new dependency can’t be verified.