Most of what is written about slopsquatting measures the model: ask it for code, count how often it names a package that does not exist. We wanted the other end of the pipeline. Of the code people actually built with AI tools and published, how much still depends on a package that is not there?
A dependency that does not exist is not just a broken install. Its name is free, and whoever registers it first decides what that install runs from then on.
Two samples, both taken on 2026-10-03, both with a control group.
Popular projects. Every GitHub repository linked from a Show HN post since January 2025 with more than 20 points: 673 reachable repositories.
Recent, unpopular projects. Repositories created since January 2025 with at most 50 stars, found by the files AI tools leave behind: a Lovable build marker, Bolt's project prompt, a CLAUDE.md, a .cursorrules file. The control group is repositories created in the same period with no such trace.
A repository counts as AI-built if it carries any of these: an agent instruction file (CLAUDE.md, AGENTS.md, .cursorrules and their relatives), commits signed by an AI tool (Co-Authored-By: Claude, Co-authored-by: Copilot and others), a Lovable or Bolt marker, or the author saying so in the Show HN post.
| AI-built | Control | |
|---|---|---|
| Popular (Show HN) | 412 repositories, 37,158 dependency entries | 261 repositories, 7,655 entries |
| Recent, ≤ 50 stars | 920 repositories, 22,966 dependencies added beyond the platform template | 303 repositories, 6,494 entries |
Every dependency in every package.json, requirements.txt, pyproject.toml, Cargo.toml and go.mod was looked up live in npm, PyPI, crates.io and the Go module proxy — 8,240 distinct names in the first sample and 6,565 in the second.
A side note on the control group: of 600 ordinary repositories we drew from the same period, 297 (49.5%) already carried an AI tool's trace and had to be moved out. Half of new code on GitHub is touched by these tools now.
A name that is missing from the registry is usually not a phantom. Most were packages that live inside the same repository, private packages under a company scope, packages from a different registry (Deno's JSR, Unity's), or placeholder names in examples. We removed each of those by hand. What was left:
| AI-built | Control | |
|---|---|---|
| Popular | 1 repository, 1 name | 1 repository, 1 name |
| Recent, ≤ 50 stars | 2 repositories, 4 names | 0 |
| Names anyone can register today | 5 | 1 |
The five, without the repositories they are in:
"name": "^1.0.0". None of the three has ever existed on npm, and the app's code imports one of them. The repository's lockfile does not contain them: the install that would have failed was never run, so nothing caught them.==5.3.0 in the backend of an app built with Lovable.requirements.txt in a popular project.
The control group's one is the same shape as the last: a ROS package that is installed with the system package manager, never from PyPI, listed in requirements.txt with an exact version.
Two more were invented but cannot be taken: a @types/ package (only the DefinitelyTyped maintainers can publish under that scope) and a standard-library module (PyPI refuses those names).
They say phantom dependencies are rare in published code — about one AI-built repository in four hundred — and that they exist, with version numbers attached, in code people put online.
They do not say AI-built code is worse than other code. Two repositories against none in the unpopular sample and one against one in the popular one are counts too small to compare. The samples come from search rankings, not a random draw.
A published repository is a finished product. Every phantom package that broke a build on the way there was most likely noticed and removed before anyone pushed: the author ran the app, the install failed, the name went. What we found is what survived, and every case we found survived for the same reason — it sat where nobody ran an install. An example folder. A backend nobody deployed. An app whose lockfile shows its install was never completed.
So these counts are a floor, not a rate. We did not measure what happened before the commit, but two things point the same way. When we put ordinary coding tasks to Claude, GPT and Gemini, they recommended 87 package names that do not exist. Academic work that measures the same thing at generation time (Spracklen et al., 2024) found invented package names in a substantial share of generated code, more for open models than for commercial ones. Between what the model writes and what gets pushed, someone has to catch the rest — usually by running the install and watching it fail.
That makes the dangerous moment the one before the failure. The install fails because nobody has registered the name yet. The day someone does, the same command succeeds, quietly, and runs their code. A phantom name in a published repository is a standing invitation. The three in the Bolt app have been one since March 2025.
The place to stop a phantom package is when the agent adds it — before the install that fails today and succeeds once the name is taken. All five names above, sent to VDB's package gate, come back REFUSE:
POST /v1/ai/check-packages
{"packages": ["pkg:pypi/<one of the five>"]}
"agent_action": "REFUSE"
"because": "this name does not exist on the registry — likely hallucinated, and attackers register such names"
The gate answers up to five packages without a key; see Connect to put it in front of an agent.
.npmrc sends to a private registry. For Lovable and Bolt, dependencies present in at least half of that platform's repositories count as the template and were left out.
We told the maintainers of the four repositories involved on 2026-10-03, before this post, and none is named here. We did not register any of the names ourselves.