You could tell your AI to write everything from scratch. You should not. Almost everything your app needs, login, payments, date handling, file uploads, someone has already built and millions have tested. These ready-made pieces are dependencies, and this chapter shows you how to lean on them without inheriting their problems.
1.13.1What a dependency actually is
A dependency is code someone else wrote that your app installs and uses, usually called a library or a package. Rather than build a payment flow or a calendar yourself, you pull in one that already works, hardened by everyone who uses it.
Your agent installs them and lists them in one file, the manifest (like package.json), so any machine can rebuild the exact same set. You never install them by hand. Your job is deciding which are worth trusting, because each one is code you cannot fully see.
1.13.2Pick popular, maintained, and alive
Not every library deserves your trust. Before your agent adds one, it should prefer the option that is widely used, recently updated, and still maintained. Popularity means bugs surface fast; recent activity means security holes get patched.
Add one only when it saves real work, too. For a handful of lines, have your agent just write them, every dependency you skip is one less thing that can break on you.
Rule of thumb: a library with thousands of users and a commit this month beats a slicker one nobody has touched in two years.
1.13.3Update often, but never blindly
Old dependencies are where security problems quietly pile up, so keep them current. An update can also change how a library behaves, though, so it pays to update a few at a time and check the app still works after each batch.
Read the changelog before each one, too. That is where maintainers announce the change that will break you, in plain language, and it costs a minute.
What you never do is update everything at once the day before you ship. Small, checked steps let you catch the one update that broke something while it is still easy to find.
1.13.4Lock versions so builds stay identical
Libraries depend on other libraries, so two of them can want different versions of a third, or a fresh install can pull in a newer piece that breaks yours. Those version numbers follow a shared convention, semantic versioning, so a jump in the first number warns you a change may break things. A lockfile, which your agent creates automatically, records the exact version of everything, so the app builds the same on every machine and nothing shifts under you unseen.
When versions do conflict, your agent sorts it out. Your job is only to notice when something that worked yesterday suddenly does not, and point the agent at it.
1.13.5Pick one package manager and never mix
The program that does the installing is your package manager. It fetches each package, writes it into the manifest, and keeps the lockfile honest, and its name starts every install command you will ever see.
npm is the lazy default: it ships with Node, and every tutorial assumes it. pnpm is what most senior engineers reach for instead, same packages, faster installs, far less disk.
Either is fine; using both is not. Each writes its own lockfile, package-lock.json for npm and pnpm-lock.yaml for pnpm, and a project carrying two of them installs differently on every machine. Tell your agent which one you use and hold it there.
1.13.6Check the license before you build on it
Every library comes with a license, the legal terms for using it. Most popular ones, like MIT and Apache, let you do almost anything. A few, like some GPL variants, put conditions on how you share your own code.
It rarely bites a small project, but before you build a business on a library, have your agent confirm its license is one you can live with. choosealicense.com explains the common ones in plain language.
This prompt turns that into a standing check rather than a one-off:
Do this now: paste the prompt and let your agent audit what you are standing on, so you know before a dependency becomes a problem instead of after.
