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.
2.5.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.
2.5.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.
2.5.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.
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.
2.5.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. 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.
2.5.5Check 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.
Do this now: ask your agent to list every dependency your project already pulls in, with each one's popularity, last update, and license, so you know exactly what you are standing on.
