Why AI Coding Tools Sometimes Invent Fake Code Packages

Most conversations about AI-generated code risk focus on bugs or bad logic. There’s a narrower, less obvious risk that’s specific to how these tools work: sometimes they recommend installing a software package that doesn’t actually exist — and attackers have figured out how to weaponize exactly that.

What’s Actually Happening

AI coding tools generate code, including dependency names, by predicting what’s statistically likely to come next based on patterns in their training data — not by checking a real package registry in real time. Most of the time this produces correct, real package names. Occasionally, it produces a name that sounds entirely plausible — following the same naming conventions as real packages — but simply doesn’t exist. This is called a “hallucinated” package.

A 2025 academic study analyzing millions of AI-generated code samples across multiple models found that roughly one in five contained at least one hallucinated package name, with the rate meaningfully higher in open-source models than commercial ones. It’s not a rare edge case — it’s a routine byproduct of how these tools generate code.

Why This Became an Actual Security Threat, Not Just a Bug

On its own, a hallucinated package name would just cause an installation error — annoying, but harmless. The problem is that attackers noticed the pattern and started deliberately registering these commonly-hallucinated names as real, working packages, uploaded with actual (often malicious) code inside them. This practice has been given a name: slopsquatting. A developer who copy-pastes an AI-suggested install command without checking it first can end up installing genuinely malicious, attacker-controlled code under a name that looked completely legitimate.

Who’s Actually at Risk

This risk scales with how much verification gets skipped, which makes it particularly relevant for non-technical founders vibe coding an MVP — the entire appeal of that workflow is moving fast and trusting the AI’s output, which is exactly the habit that makes a hallucinated package easiest to miss. A developer who’s used to manually checking dependencies before installing them is naturally more likely to catch it; someone who’s never had reason to think about package registries at all has no existing instinct telling them something’s off.

How to Actually Protect Yourself

• Check that a suggested package actually exists on its real registry (npm for JavaScript, PyPI for Python, and so on) before installing — a quick search takes seconds and catches an entirely fabricated name immediately.
• Look at download counts and history, not just existence — a package with almost no downloads and no real history is worth a second look even if it does technically exist.
• Be more cautious with obscure or unusual-sounding suggestions — a package name you don’t recognize, for a task you’d expect a well-known library to already handle, is worth double-checking before it goes anywhere near your project.
• Use dependency lock files and scanners where your tooling supports them, so an unexpected or unreviewed dependency doesn’t slip in silently during a later install.

This Is a Narrow Risk, Not a Reason to Avoid AI Tools

It’s worth keeping this in proportion: this is one specific, well-understood failure mode tied to one specific part of what AI coding tools generate — dependency names — not a reason to distrust AI-generated code broadly. The fix is a simple, cheap habit (verify before installing), not a wholesale change in how you use these tools. It sits alongside the other reasons AI-generated code sometimes breaks in production as a specific, addressable gap rather than a fundamental flaw in the approach.

The Bottom Line

AI coding tools occasionally invent package names that sound real but aren’t, and attackers have started registering those exact names to distribute malicious code to anyone who installs without checking. The fix costs almost nothing — a quick verification before any new dependency goes into your project — but skipping it, especially in a fast-moving, describe-and-generate workflow, is exactly how this risk turns from theoretical into real.

Frequently Asked Questions

What is a hallucinated package?

It's a software library name an AI coding tool suggests installing that doesn't actually exist — invented, plausible-sounding, but fabricated. It happens because the model is predicting a likely-looking name, not checking a real registry.

What is slopsquatting?

It's the practice of attackers deliberately registering the fake package names AI tools commonly hallucinate, so that a developer who copy-pastes an AI suggestion without checking it ends up installing real, attacker-controlled malicious code under a name that sounds legitimate.

How common is this problem?

A 2025 academic study analyzing millions of AI-generated code samples found that roughly one in five contained at least one hallucinated package name, with the rate notably higher in open-source models than commercial ones.

How do I protect myself from this as a non-technical founder?

Never install a package an AI tool suggests without a quick check that it actually exists on the official registry (like npm or PyPI) and has a real, established download history — a brand-new or obscure package name recommended by AI deserves extra scrutiny before installing.

Does this mean I shouldn't trust AI-generated code?

No — it means treating package/dependency suggestions specifically with the same verification habit you'd apply to any unfamiliar software before installing it, not avoiding AI coding tools altogether. The risk is narrow and specific, not a reason to distrust every line of AI-generated code.