A dependency isn’t free help with no strings attached. When you add one, you pull someone else’s choices, bugs, and security problems into your project, so convenience always comes with responsibility.
Think about 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. Code works the same way. A project might depend on a package for dates, payments, or logins. An SDK is a common kind, a package that makes a service easier to use.
How it shows up
This shows up constantly with AI tools. You ask Codex or Claude Code for a feature and it may reach for a package. Sometimes that’s right, since you shouldn’t hand-recreate a trusted package, but you still need to know what was added and why. It’s also why simple-looking apps have long install steps: the project grabs every outside part it expects, and that stack runs deep.
Why you care
This is where supply chain risk comes in. Install a random package and you’re trusting it. Install a plugin and you may be trusting code, instructions, connectors, and permissions at once. The smart move is to be selective rather than avoid dependencies in your codebase: use well-known packages, keep them updated, drop what you don’t need, and ask the agent why a package is being added before you accept it.
A dependency saves time when it’s chosen on purpose, and creates risk when it sneaks in unnoticed.