Every product stands on code somebody else wrote. That is normal and usually sensible. Dependency risk is what happens when nobody can say why a particular package is there, who maintains it, or what would break if it disappeared.
Where the packages come from
A generated solution reflects the patterns that were most common in its training data, which means it reaches for well-known libraries by default. Each suggestion looks reasonable on its own. Across a few months of fast building, the effect compounds: several packages that solve the same problem, transitive dependencies nobody reviewed, and versions pinned at whatever was current on the day the file was written.
Nothing about this is visible while the product works. It becomes visible when a library stops being maintained, when a vulnerability is published, or when an upgrade somewhere else in the tree forces a version bump that the rest of the code was never tested against.
What an audit looks for
The dependency tree is one of the few parts of a codebase that can be assessed quickly and objectively. An audit checks which packages are actually imported and which are dead weight, which ones are unmaintained or already carry published vulnerabilities, whether licences are compatible with how the product is sold, and where the same capability was solved twice by two different libraries.
It also checks how far the code is coupled to each package. A library used behind a thin internal interface is a decision that can be reversed. A library whose types and idioms spread through the whole product is closer to an architectural commitment, and replacing it later is the kind of work that shows up in what a code migration actually costs.
Keeping the surface small
The point of the exercise is not to remove dependencies for its own sake. It is to know what you rely on, keep that list as short as it can reasonably be, and make sure the pieces you cannot easily replace are the ones you chose on purpose. Read together with test coverage, it gives a realistic picture of how safely the product can be changed, which is what an audit of vibe-coded software is for.
