An AI coding tool will always hand you the package that made its training data look clean, not the one that fits your maintenance budget. That gap is structural, and it compounds silently until an audit forces you to explain code you never consciously chose.
The Details:
- Popular libraries dominate the code a model learned from because mature projects have had their rough edges sanded off over years of production use. To the model, popular and well documented and easy to generate correctly all blend into one signal, so it reaches for the library that gets you working code fastest, with zero awareness of your team's capacity to absorb another dependency.
- The cost hides at the exact moment the choice gets made. It resurfaces later as an upgrade that breaks two layers removed from anything you wrote, or a security review where you have to trace the provenance of a package nobody remembers adding. Reviewers will argue over a variable name for four minutes and let a new import line pass without a second glance.
- A written policy changes the default before generation starts. A repo file that says prefer the standard library, name the HTTP and date packages already in use, and flag any new dependency with a lighter alternative, reshapes what the tool produces from the first response, rather than requiring you to catch it after the fact.
- Machine enforcement outlasts good intentions. A reviewer assignment on the dependency file plus a build check that fails when the lockfile grows without an explanation in the pull request turns the conversation into something that happens automatically, not something that depends on someone remembering to ask why a package showed up.
Bottom Line: If nobody deliberately sets the dependency default to no, the AI and the deadline will jointly set it to yes.
