Should an AI Coding Agent Upgrade Your Dependencies?
Should an AI coding agent upgrade your dependencies? Yes for patch versions, usually yes for minors with a real test suite, and no for majors, at least not as a dependency task. That split is not arbitrary.
Should an AI coding agent upgrade your dependencies? Yes for patch versions, usually yes for minors with a real test suite, and no for majors, at least not as a dependency task. That split is not arbitrary. It follows from what your tests can actually prove about each kind of change.
This is a different question from stopping an agent inventing new dependencies you never chose, which is covered in stop AI coding agents adding dependencies you did not pick. Here the package is already yours. The only thing changing is the number.
What each bump class is claiming
Under semantic versioning, the three positions carry different promises, and those promises are what your test suite is implicitly relying on.
Bump | The maintainer is promising | What your tests can prove |
|---|---|---|
Patch (1.4.2 to 1.4.3) | bug fixes, no API change | almost everything, since your call sites are unchanged |
Minor (1.4.2 to 1.5.0) | additions, nothing removed | most things, unless behaviour changed under a stable signature |
Major (1.4.2 to 2.0.0) | breaking changes, explicitly | only that your code still compiles and the paths you tested still pass |
The gap in the last row is the whole problem. A major bump changes behaviour deliberately, and a green test suite after a major bump proves that nothing you wrote a test for broke. It says nothing about the paths you did not.
When an AI coding agent should upgrade your dependencies
Patch bumps: let the agent do them, batched, on a schedule. One pull request a week containing every patch bump, with the lockfile diff and CI green. Review the diff, not the code.
Minor bumps: let the agent do them, one package per pull request. Batching minors means that when something breaks you cannot tell which package did it. One at a time costs nothing extra and makes bisecting trivial.
Major bumps: do not file them as dependency work at all. File them as a change request against the code that uses the package, with the migration guide linked in the description. The agent is genuinely useful here, but the task you give it is "migrate our usage of X from v1 to v2 per this guide", not "upgrade X".
The third line is the one that saves you. An agent handed "upgrade to v2" will change the version, run the tests, patch whatever fails until they pass, and report success. What it produces is a codebase that satisfies the old tests using the new API, which is not the same as a codebase that uses the new API correctly.
The preconditions that make any of this safe
None of the above holds without these three.
A test suite that fails when behaviour changes
If your tests only assert that functions return without throwing, they will stay green through almost any upgrade. The suite has to make claims about outputs. Writing tests that actually make claims is in how to use AI to write tests.
The agent running in CI, not on your machine
Dependency upgrades should be proposed by a process that has no ability to merge itself and no access to your local environment. The setup is in how to run an AI coding agent in CI.
A rollback you have actually used once
Reverting a dependency bump is easy in theory and unfamiliar under pressure. The general pattern is in how to roll back a bad AI coding agent change, and it is worth rehearsing on a low-stakes bump.
Two failure modes specific to agents
It fixes the test instead of the code
The single most common way an agent turns a breaking upgrade green. Guard against it mechanically: if a pull request whose stated purpose is a version bump also modifies test files, that pull request needs a human read, every time. A CI check that fails when the diff touches both a lockfile and a test file costs about six lines and catches this reliably.
It widens the constraint instead of pinning it
Asked to update a package, an agent will sometimes loosen the version range in the manifest so the resolver picks something newer, rather than pinning a specific version. The result is a build that changes on its own the next time someone installs. Review the manifest diff, not just the lockfile.
A workable weekly rhythm
Monday: agent opens one batched patch-bump pull request. Skim the lockfile diff, merge if CI is green.
Midweek: agent opens individual minor-bump pull requests, at most three at a time. Read the changelog entry for each before merging.
Majors: collected into a backlog and scheduled as real work, one per sprint, framed as a migration.
Security advisories: out of band and out of this rhythm entirely. A patched CVE is not a routine bump.
That rhythm keeps a codebase current without ever letting a machine make a judgment call about breaking behaviour, which is the only judgment call in the list that matters.
Frequently asked questions
Is it safe to let an AI agent update dependencies automatically?
For patch and minor versions, with a test suite that asserts behaviour and CI enforcing it, yes. For major versions, no, because a green suite after a breaking change proves less than it appears to.
How is this different from a bot like Dependabot?
A version bot changes the number and nothing else. An agent will also change your code to make the upgrade compile, which is more capable and considerably more dangerous, because it can make a broken upgrade look successful.
Should I batch dependency upgrades?
Batch patches, never batch minors or majors. When a batched upgrade breaks something, the time you save on review comes straight back out of bisecting.
What about security patches?
Treat them separately from routine upgrades. A patch for a known vulnerability is worth merging faster and reviewing more carefully, and it should not sit in a weekly batch.
Where dependency handling sits in the wider set of things to delegate or keep is covered in AI coding tools.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
