When an AI tool suggests an import, it is not weighing your maintenance burden or security exposure. It is pattern-matching against thousands of tutorials, and tutorials almost always reach for a library. That gap between what is common and what is wise for your specific codebase is where dependency pileups start, and it happens silently because the generated code runs fine.
The Details:
The real problem is not visibility. Anyone can run a dependency tree command and see everything installed. The actual failure point is earlier: nobody pauses to justify the import before the code gets written, because deciding whether to add something feels like a different, harder act than merely noticing it once it is already there.
A ratchet effect locks the trap shut. Once a package lands in a lockfile, it gains social proof as "part of the project." Removing it later requires untangling every feature built on top, so the cost of undoing a bad call grows with every sprint that passes after it.
Small process changes outperform big audits. A pull request field asking which dependencies were added and why kills casual additions before they happen, because writing the justification aloud is harder than skipping the library. A prompt instruction telling the AI to check the existing codebase before suggesting anything new works the same way, shifting the tool from reflex to search.
The risk extends past code quality into supply chain trust. Recent compromises in widely used packages did not succeed because the code looked malicious at install time. They succeeded because trust in a maintainer's future judgment was extended and never re-examined, which means pinned versions and read lockfiles matter as much as the initial install decision.
Bottom Line: The fix is not fewer dependencies, it is dependencies chosen on purpose, one justified sentence at a time.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
