A dependency is outside code your project relies on so you don’t have to build that piece yourself: a package for dates, payments, or logins. An SDK is a common kind. Adding one pulls someone else’s choices, bugs, and security problems into your codebase, so convenience always comes with responsibility.
Consider building out an office. You don’t manufacture the light switches, door handles, and copier yourself. You buy from specialists, and your office now depends on them: if the copier breaks, your workflow feels it.
Why you care
This is where supply chain risk comes in. Ask an agent for a feature and it may reach for a package. Often that’s the right call, since you shouldn’t hand-recreate trusted work, and you still need to know what was added and why. Install a plugin and you may be trusting code, instructions, connectors, and permissions at once. Be selective rather than avoidant: use well-known packages, keep them updated, drop what you don’t need, and ask the agent why a package is being added. A dependency saves time when it’s chosen on purpose, and creates risk when it sneaks in unnoticed.