Write the helper yourself when the task is small, well understood and not security sensitive. Add a library when the problem is hard to get right, such as cryptography, parsing untrusted input or date handling. The cost of a dependency is not the install, it is every update and advisory that follows for as long as it stays.
Why the question comes up with AI
A person who is about to add a dependency usually feels the friction. They open a registry page, read a README, maybe check the last release. An assistant feels none of that. Asking for a feature and getting back an install line plus three imports is easy to accept.
That makes the default drift toward adding. Each package adds code you did not write, a maintainer you did not choose and a list of transitive packages you did not see. The assistant is not wrong to suggest a library. It is just not weighing the long term cost for you.
Four questions that decide it
- How much code is the task? If a helper is under about twenty lines and has no tricky edge cases, owning it is usually cheaper than owning a dependency. Examples: clamping a number, joining paths in a known format, formatting a string.
- Is it easy to get subtly wrong? Some small tasks are not small. Escaping output, validating tokens, comparing secrets and parsing formats from outside your system are better handled by a maintained, widely used library than by fresh code from a model.
- Do you already have something that does it? Search your dependency tree first. A second library that does the same job doubles the surface for no gain.
- Who will update it? A library you add today needs someone watching its advisories for years. If no one owns that, prefer the helper.
A quick comparison
| Factor | Small helper you own | Library you add |
|---|---|---|
| Update burden | Yours, but only your code | Upstream releases and advisories |
| Review cost | One short diff | Package vetting plus transitive packages |
| Correctness risk | Higher for security sensitive logic | Lower when the library is mature |
| Supply chain exposure | None added | New publisher and install path |
| Testing | You write tests for it | You trust and spot check upstream |
What to ask the assistant
If a pull request adds a package for something small, ask the assistant to produce the plain version for comparison. Put both in the pull request and let the reviewer judge. Phrase the request as a request for an alternative, for example: write this without a new dependency, using only what the project already imports, and note any edge cases you left out.
The notes on edge cases are the useful part. If the list is long or touches security, that is your answer: use a library, and vet it. The dependency budget idea pairs well here, because a visible budget makes the tradeoff conscious.
When writing it yourself is the wrong move
Do not hand roll anything that protects secrets, authenticates users, or decides who may do what. If an assistant writes cryptographic or authorization code from scratch because it wanted to avoid a dependency, send it back. Pick a well maintained library, vet it with the five minute routine, and review the call sites carefully.
The goal is not zero dependencies. It is dependencies you chose deliberately.
Quick check
Is fewer dependencies always more secure?
No. A mature library maintained by many people can be safer than your first attempt at security sensitive code. Fewer dependencies reduce supply chain exposure, but they do not make hand written logic correct.
How do I stop an assistant adding packages for trivial tasks?
State a rule in your instruction file: prefer the standard library and existing dependencies, and ask before adding anything new. Back it with a pull request check that flags manifest changes.
Safeguard policies and gates can be applied to pull requests, which is one way to make sure a new package gets a reviewer's attention before it merges. The free scan at gold.safeguard.sh/scan shows what your current tree already contains.
Last reviewed: 19 October 2026.
