Why does my AI assistant add a second library that does the same job?

An AI assistant adds a second library because it sees the file it is editing, not your whole dependency tree. If it does not know you already use an HTTP client, a date library or a validation package, it picks one from memory. The fix is to give it the inventory and to check for duplicates in review.

How duplicates creep in

A developer who has worked on a project for months knows its habits. An assistant starts each session with a short window of context. It may see one file, a few imports and your request. It does not automatically know that the team standardized on one logging package last year.

So a prompt such as add retry logic to this call can come back with a brand new retry package, even though a similar one is already in the lockfile, possibly several layers down as a transitive dependency. The code works. The tests pass. The manifest quietly gains a second way to do the same thing.

Why it matters for security

Each additional library is another thing to patch. If two packages solve the same problem, an advisory in either one can require work, and you need to remember both exist. Two libraries also double the chance that one of them is poorly maintained, and they make upgrades harder to schedule.

Duplicates also make incident response slower. When a new advisory lands, the first question is whether you use the affected package. A tidier tree answers faster. The same reasoning is behind keeping a dependency budget.

How to look for an existing equivalent

1. List what is installed. The npm documentation describes npm ls as printing all installed packages in a tree. With the all option it includes their dependencies. Search the output for the capability you are about to add.
2. Look at the manifest purpose by purpose. Open package.json or requirements and scan for the category: date handling, HTTP, validation, logging, testing.
3. Ask why it is here. For any package in the tree you did not choose, run npm explain on it. The docs describe it as printing the chain of dependencies that caused a package to be installed. If a package is already present transitively, you may still want to add it directly, but that is a decision, not an accident.
4. Search the code for existing helpers. Many projects already have a small internal wrapper for the task.
5. Compare before approving. If the pull request adds a second package in a category you already cover, ask the author to justify it or switch.

For duplicate versions of the same package, the related post on finding and removing duplicate packages covers a different problem: one library installed at two versions.

Give the assistant what it is missing

You can prevent most duplicates with two small habits. First, keep a short section in your agent instruction file listing the preferred package for each common job, for example: use the existing HTTP client, do not add another. Second, ask the assistant to read the manifest before suggesting a package and to list which existing dependencies it considered.

Neither habit is enforcement. A reviewer still needs to look at manifest changes. A pull request template line such as does this duplicate an existing dependency takes seconds to answer and catches a surprising number of cases.

Try it yourself

Open the dependency inventory demo and scan the component list for two packages that appear to serve the same purpose. That is what a reviewer is looking for in a real tree.

Click through it at your own pace, or open it full screen.

Quick check

Safeguard's SBOM and dependency scanning produces an inventory you can search for overlapping packages, and the free scan at gold.safeguard.sh/scan is a quick way to see your current tree.

Sources

• npm Docs, npm ls: https://docs.npmjs.com/cli/v10/commands/npm-ls
• npm Docs, npm explain: https://docs.npmjs.com/cli/v10/commands/npm-explain

Last reviewed: 19 October 2026.