AI Coding Assistant Dependency Version Selection Risks: Stale, Bleeding Edge, or Non-Existent

AI coding assistant dependency version selection risk describes the pattern of tools like GitHub Copilot, Cursor, and Claude Code choosing library versions that are outdated, published within the last few days, or entirely fictional.

For most of software history, picking a dependency version was a judgment call. A developer knew which internal library version the team had standardized on, remembered why the last upgrade attempt got rolled back, and could weigh a security patch against the risk of a breaking change.

That context lived in someone's head, or, at best, in a wiki page that nobody read consistently. AI coding assistants increasingly make that decision as a recommendation rather than a deliberate human choice, and the result is a version choice that lands in your dependency manifest with none of the judgment that once accompanied it.

Who decides which dependency version ends up in your codebase now?

A developer used to deliberately choose a dependency version, weighing the team's internal standards against the risk of upgrading.

An AI coding assistant now proposes that version instead, and the developer typically accepts it without a second look, because the code compiles and the feature works.

That single substitution, model suggestion for human judgment, is the root of every risk described below, and it plays out in three distinct failure modes depending on what the assistant is optimizing for at the moment it writes the import statement.

Why do AI coding assistants default to stale dependency versions?

An AI coding assistant defaults to stale versions because its training data skews toward the version of a library that was most widely documented when the model was trained, rather than the current or most secure version.

Large language models don't fetch live registry data by default, but rather they generate the version string that appeared most often in the code and documentation they learned from, which is almost always an older release simply because it existed longer and accumulated more tutorials, Stack Overflow answers, and GitHub examples.

A stale version may easily install cleanly, passes the build, and looks correct in every way that matters to a compiler. What it can also do is retain vulnerabilities disclosed against that release since the day it shipped, including risks inherited through its own transitive dependencies.

If the model's training cutoff predates a critical CVE, the assistant has no way of knowing the version it just recommended has since been flagged, and neither does the developer who accepted the suggestion without checking.

What happens when an AI assistant swings to the newest release instead?

When prompted to fix an outdated dependency, an AI coding assistant can overcorrect and jump straight to the most recently published version, sometimes a release only days old. That release has had less time for production use, bug reports, and ecosystem scrutiny.

The risk here is real. When attackers compromise a popular package, the malicious version typically survives only a short window before it gets caught and pulled.

In one recent incident involving a compromised release of the widely used axios library, researchers at Huntress reported that the malicious axios versions were pulled within about three hours of publication, and in that short window still logged over a hundred endpoints reaching out to attacker infrastructure.

An assistant reflexively reaching for whatever is newest can walk a project directly into that exposure window, installing a version before the ecosystem has had a chance to notice anything is wrong with it.

Can an AI coding assistant recommend a version that doesn't exist?

Yes, and it happens often enough to have a name: package hallucination, where the assistant generates a version number that has never been published to any registry. This is distinct from staleness or prematurity; the version simply does not exist, invented by the model because it resembles the pattern of real version strings it learned during training.

Sonatype's 2026 State of the Software Supply Chain research found that Sonatype analyzed 36,870 real dependency upgrade recommendations and found that 27.76% referenced non-existent versions, including more than 10,000 hallucinated package releases.

A hallucinated version breaks the build the first time anyone tries to install it, but the more dangerous scenario is when an attacker notices the pattern and pre-emptively publishes a package under the exact name and version an AI assistant is likely to hallucinate, turning a broken build into a supply chain compromise.

Why doesn't writing rules into an AGENTS.md file fix this?

An AGENTS.md or IDE rules file cannot fix dependency version risk because it only documents intent; it does nothing to verify that the assistant followed it, and nothing announces when the document itself has drifted out of date.

The instinct to solve this problem by writing organizational rules into a file the assistant reads before generating code is reasonable, but it substitutes one blind spot for another.

Start with what the assistant cannot know regardless of how good its training data is: your organization's own internal decisions about its own libraries. Which version of your internal auth library is currently approved, and which version got retired last quarter after an incident, exists nowhere in public training data and nothing a scanner infers from the internet will surface it.

Teams try to close that gap by writing the rule down directly, something like "use version 4 of the internal auth library," and pointing the assistant at that file before every session.

The problem is that this file behaves exactly like the wiki pages it was meant to replace. If version 4 shipped a security fix in March and version 3 was formally retired, the instruction file only reflects that change if someone remembers to update it, and nothing in the system flags the moment it becomes wrong.

Multiply that across twenty repositories, each with its own copy of the same rules file, and you have twenty independent points of failure instead of one shared source of truth.

Research across more than 34,000 repositories confirms this pattern: 1 in 4 organizations showed gaps in AI agent config files. Worse, even a perfectly current rules file offers no guarantee of compliance: an assistant can read the instruction and still generate code that ignores it, because these are probabilistic systems following statistical patterns rather than deterministic ones executing a policy.

Probabilistic compliance is not compliance, and it cannot be audited when a regulator or a security lead asks whether the rule was actually followed on every commit.

Instructions shape what an assistant is likely to do. They don't enforce what it must do, and that distinction is the entire reason this category of risk survives even in teams that have already written careful rules files.

Why do risky dependency versions slip past pull request review?

Risky dependency versions slip past review because the volume of AI-generated code arriving in each pull request has grown faster than the amount of time reviewers spend evaluating it — Stack Overflow's 2025 Developer Survey found 66% of developers spending more time fixing AI-generated code that looked almost right.

A version bump buried in a package manifest is one of the easiest lines in a diff to skim past, especially when the surrounding code looks clean, and the build passes.

This is a reflection of a workload imbalance that AI-assisted development has made worse, and it's a dynamic worth understanding in more depth if you want to see how the pressure on code review is actually playing out across engineering teams.

What should you check on your repositories this week?

Before deciding how to fix this, it helps to know how exposed your repositories already are. A short internal audit answers that question without requiring new tooling.

• How many dependency version changes merged last month, and how many carried a human comment specifically about the version choice rather than the feature it enabled?
• Of the dependencies added in the last 90 days, how many sit more than two major versions behind the current release?
• Do you know right now which merged dependencies have a disclosed vulnerability, or would someone need to run a scan to find out?
• Can a vulnerable dependency actually fail a pull request today, or does it only generate a warning nobody is required to act on?
• Is that gate configured identically across every repository, or only on the handful someone happened to set up carefully?
  
  

Where should the dependency version check actually run?

The dependency version check has to run twice: once when the change is proposed, and again on a recurring schedule after it merges, because a version that looked clean on the day it was added can have a vulnerability disclosed against it weeks later. Relying on either check alone leaves a gap that maps directly onto the stale-version problem described earlier.

At the pull request, Codacy scans dependency manifest files and surfaces vulnerable dependencies as security issues.

Those issues count against the quality gate, so a pull request introducing one is marked as not meeting standards, and Codacy reports that status back to the Git provider, where branch protection turns the failed gate into a blocked merge.

The gate fails first; the platform enforces the block second, and that sequence is what makes the control real rather than advisory.

Codacy's proactive software composition analysis scan runs nightly across every repository in the organization and flags vulnerable dependencies even when the most recent commit never touched a dependency file.

That second check is what closes the gap the pull request scan cannot: a version an assistant selected can pass review cleanly because no vulnerability was known that day, then have one disclosed three weeks later against a repository nobody has opened since. The nightly scan also covers the repositories most teams forget about, legacy services, and internal libraries that rarely see a new pull request but still run in production.

Findings land in a Security and Risk Management dashboard with vulnerability prioritization ordered by most recent detection, with Slack alerts for anything critical. None of this works if the quality gate itself is configured differently from one repository to the next, so consistency across the organization matters as much as the check itself.