Why Your AI Coding Agent Keeps Suggesting Old Packages

Your AI coding agent keeps recommending deprecated packages because its knowledge of package registries was frozen at a fixed point during training, and nothing in a default setup tells it to check the live registry before answering. Ask it for an HTTP client, a state manager, or a date library, and it reaches for whatever was common in its training data, not whatever is current today. It is not guessing. It is confidently reporting stale facts as if they were fresh. The fix is not "tell it to be more careful". It is pinning what actually gets installed and giving the agent an explicit, checkable instruction to verify a package before it suggests one.

Where the bad advice actually comes from

Every model has a training data cutoff, a date after which it has seen nothing. Whatever the state of the npm, PyPI, or crates.io registry was before that date is baked into the model's weights as "normal". A package that was actively maintained and idiomatic at cutoff time gets recommended with total confidence, even if the maintainers deprecated it, archived the repo, or published a warning banner on the README six months later.

This is different from the model being wrong about a fact. It is the model being right about a fact that used to be true. There is no internal alarm that fires when reality moves on. Unless the agent actually queries the registry at the moment it answers, it has no way to know the ground shifted under it.

A worked example: why the agent still suggests moment.js

Ask most coding agents to format a date in a Node project and a meaningful share of the time you will still get a suggestion to install moment.js. Moment's own maintainers put the project into maintenance mode years ago and explicitly point new projects toward alternatives like Luxon or date-fns. None of that matters to the model if moment.js appears constantly in its training data, in tutorials, forum answers, and old blog posts, almost all of which predate the maintainers' own warning.

The same pattern shows up with the old request package for HTTP calls in Node, long deprecated in favor of built-in fetch or lighter clients, and with plenty of Python packages that quietly stopped receiving updates while still dominating tutorial content from a few years back. The training data cutoff freezes the popularity contest at a point in the past. The deprecation notice happened after the freeze, so the model never saw it.

The second half of the problem compounds the first. Even when an agent has a web search or shell tool available, nothing forces it to use that tool before making a dependency recommendation. Pattern completion from memory is faster and looks just as confident in the output, so unless an instruction explicitly demands a check, the agent has no reason to reach for one.

Why upgrading the model doesn't fix this on its own

A newer model with a later training cutoff pushes the same problem forward in time rather than eliminating it. It will know moment.js is out of favor, and it will confidently recommend whatever the new incumbent was as of its own cutoff, which will eventually go stale too. Training volume also skews recommendations toward whatever has the most historical content written about it, and an older, more established package almost always has more tutorials and answers referencing it than whatever replaced it eighteen months ago. Popularity in the training corpus and current best practice are two different rankings, and the model can only see the first one.

The fix: pin the lockfile, then make the check mandatory

Two changes close most of this gap. Neither one requires trusting the model to know better next time.

Let the lockfile do the catching

A lockfile, package-lock.json, pnpm-lock.yaml, poetry.lock, or Cargo.lock, does not stop an agent from suggesting a bad package, but it does mean the exact version that gets installed is recorded and reproducible rather than silently drifting. Add an outdated or audit check to the same pipeline that already runs your tests, for example npm outdated or pip list --outdated as a CI step, and a deprecated dependency stops being a surprise you find in production and becomes a failed check on the pull request before it merges. That discipline pairs well with stopping AI agents from adding dependencies you didn't ask for in the first place, since fewer unreviewed additions means fewer chances for a stale one to slip in.

The lockfile diff is also a cheap early warning on its own. If an agent adds a dependency and the lockfile pulls in a package whose last publish was years ago, that is visible in the diff before anyone runs a command.

Give the agent an explicit, checkable instruction

A generic instruction like "only use well-maintained packages" does nothing, because the agent's internal sense of well-maintained is exactly the stale training-data judgment causing the problem. What works is a concrete, mechanical step written into an AGENTS.md file or system prompt, one the agent can actually execute rather than just agree with. For example:

## Dependency policy
- Before adding or recommending any new package, run:
  npm view <package> deprecated
  npm view <package> time
- Report the result before suggesting the package.
- If the last publish date is more than 18 months old, say so explicitly
  and name at least one actively maintained alternative.
- Prefer a package already in package.json over adding a new one.
- After adding a dependency, run npm outdated and summarize the output.

For Python, the equivalent is querying the PyPI JSON API or running pip index versions <package> before recommending it, then reporting the last release date the same way. The exact command matters less than the pattern: the instruction converts trusting the model's memory into running one command and reporting a real answer, something an agent can reliably do even though it cannot reliably remember the current state of a registry it was never connected to during training.

This combination is what closes the loop. The lockfile catches what slips through and makes it visible in review. The instruction file reduces how often something slips through in the first place, because the agent is now checking a live source instead of pattern-matching from a training snapshot. Neither piece alone is enough. A lockfile without the instruction just means you find out about the deprecated package after it is already in your dependency tree. An instruction without the lockfile relies on the agent following it perfectly every single time, which it will not.

Where this fits with other AI coding agent problems

A deprecated package recommendation is a milder cousin of an AI agent hallucinating a package that doesn't exist. Both come from the same root cause: the model producing a confident, fluent answer that isn't checked against anything real. One gives you a package name that resolves to nothing on install. The other gives you a package name that resolves fine but was already on its way out. Both are easier to live with once

debugging AI-generated code is treated as a normal step in the workflow rather than a sign something went wrong. Among the broader set of AI coding tools people use to ship faster, this specific failure mode is one of the more manageable ones precisely because it is caught by tooling you likely already have, a lockfile and a CI check, rather than requiring anything exotic.

If you are earlier in the process, still building an app with AI for the first time, it is worth setting up the AGENTS.md instruction and the CI outdated check before you have dozens of dependencies to audit retroactively. It is a five-minute setup cost against a recurring source of small, avoidable technical debt.

FAQ

Why does my AI agent still suggest packages that npm shows as deprecated?

Because the model's knowledge of the package comes from training data that predates the deprecation notice, and by default it does not query the live registry before answering. It is recommending what was true when it was trained, not what is true now.

Does giving the agent internet access fix this?

Only if it actually uses that access for this specific check. Having a browsing or shell tool available does not mean the agent will reach for it before every dependency suggestion unless an instruction tells it to. Without that instruction, pattern completion from memory is usually faster and the agent defaults to it.

Should I let the AI agent auto-update dependencies to fix this?

Not on its own. Auto-updating without review can pull in breaking changes just as easily as it removes a stale package. Pair any update step with your existing test suite and a human review of the lockfile diff, the same way you would treat a dependency bump a person proposed.

How do I know if a specific package suggestion is actually outdated?

Run npm view <package> deprecated and npm view <package> time (or the PyPI equivalent) before accepting the suggestion. A deprecated flag or a last-publish date of well over a year tells you more in ten seconds than asking the model to reassure you.

Does this happen with every AI coding tool, or just some of them?

It happens with any tool built on a large language model, because the underlying cause is the training data cutoff, not a bug specific to one product. Tools differ in whether they nudge the agent to check a live source before recommending a package, which is exactly the gap an AGENTS.md instruction is meant to close.