# Update your dependencies with a coding agent, one package at a time - Author: RomanMotion (https://wurk.fun/user/RomanMotion) - Published: 2026-11-04 - Canonical (HTML): https://wurk.fun/blog/update-your-dependencies-with-a-coding-agent-one-package-at-a-time - Cover image: https://ik.imagekit.io/wurk/browser-uploads/f1c626b5c17e7f0a61dfbbe7a20d85ae7b33a20527243aeec2ee1d0a8b87562a/cf7fba4c-3fe8-4494-bead-a42dfd9881d8/cover-deps.jpg?wurkUpload=v1.sRi-xInLRBc5Ri005uJJYlT7IWTbhqR3OnrvIOJo94U --- Your app has been live for months and the versions in your lockfile are the same ones from the day you shipped. Some of those packages have had security fixes since then, and you do not have them. The fix is not a big update night; it is a routine where your coding agent upgrades one package at a time, reads what changed, runs the tests, and stops the moment something breaks, so you always know exactly what to roll back. That is the whole idea: small, reversible steps. It looks slower on paper and is far faster in practice, because you never lose an evening hunting for which of many upgrades took the login page down. ## Why "update everything" in one commit is the trap When one big upgrade breaks the app, you are stuck. Dozens of packages moved at once, each with its own changelog, and nothing tells you which one did it. You cannot revert a single package out of the pile either, because the pile is one commit: you either keep the broken state or throw the whole thing away and start over. It gets worse when the break is quiet. A dependency updates a rounding rule, a date format, an auth default, and nothing throws an error at all; the app just starts returning the wrong total and you notice weeks later with no idea when it changed. A single giant commit gives you no clean way to trace that back. So it is tempting to give up and pin every version forever. The packages rot, the security debt compounds, and the next major jump is bigger and scarier than the last one. One package per commit turns a terrifying afternoon into a boring one, and boring is exactly what you want here. ## See what is actually out of date Before touching anything, get a list. In a Node project, `npm outdated` shows each package's current version, the newest version your declared range allows, and the latest release ([npm docs](https://docs.npmjs.com/cli/commands/npm-outdated)). In Python, `pip list --outdated` does the same job ([pip docs](https://pip.pypa.io/en/stable/cli/pip_list/)). Sort by risk, not by age. Security fixes come first: `npm audit` reports known vulnerabilities in what you have installed and what fixing them takes ([npm audit](https://docs.npmjs.com/cli/commands/npm-audit)), and `pip-audit` is the Python equivalent ([pip-audit](https://pypi.org/project/pip-audit/)). A patched vulnerability beats a new feature every time, so clear those before you touch anything cosmetic. Updates and new packages are two sides of the same habit, so this pairs well with [checking every package your coding agent adds before you install it](https://wurk.fun/blog/check-every-package-your-coding-agent-adds-before-you-install-it). ## What a version number is telling you Versions look like 2.4.1, and that shape carries meaning. Semantic versioning is the convention behind it: the first number is the major version, the middle is minor, the last is a patch ([semver.org](https://semver.org/)). Roughly: a patch bump is a bug fix with no new behavior, a minor bump adds features without breaking what you already use, and a major bump is allowed to break things. That last one is the one to respect. Patch and minor updates can go in small batches; majors go one at a time, with the changelog read before the upgrade, never after. Watch the major note closely for the words "breaking", "removed", and "renamed". The catch is that not every maintainer follows the convention strictly. A minor bump can still surprise you, which is why the changelog stays the real source of truth for what changed, and why you run the tests either way. ## The routine that keeps you safe The loop is the same every time, and it is deliberately unglamorous. Pick one package, upgrade it, commit it alone, run your tests and your build, click through the main flow once, then either keep it or revert it. Your lockfile is committed with each step, so the exact working set is recorded, and `git revert` undoes a bad upgrade cleanly because it is exactly one commit. One package per commit. Small groups only for patches that touch the same area. Majors alone. If a test fails, stop and fix or revert before moving on, and never stack the next upgrade on top of a broken one. You do not have to do this by hand. Hand the rules to your coding agent and let it work through the list while you do something else; if you want a harness that can run your tests and commit as it goes, you can [try the zcode agent harness free](https://zcode.z.ai/invite/ALWM9JUA) (our invite link). ## The prompt to copy Paste this into your coding agent when you start: ``` You are updating dependencies for this project. Follow these rules exactly: - Update ONE package per commit. Never bundle unrelated upgrades. - Before any major version bump, summarize the changelog's breaking changes and wait for my OK before upgrading. - After each upgrade, run the full test suite and the build, then report. - If anything fails, STOP and ask me. Do not fix it by upgrading more. - Never delete, regenerate, or ignore the lockfile. Commit it with the change. - Never run a bulk "update everything" command. - After each upgrade, tell me the package, the old and new versions, and one line on what the changelog said. ``` Working through a long list this way means many small agent sessions. If you pay for a plan to cover them, our referral link gives [10% off GLM coding plans](https://z.ai/subscribe?ic=R0K78RJKNW). ## A checklist you can screenshot Keep this beside you and tick one row per package: ``` [ ] One package, one commit [ ] Lockfile committed [ ] Changelog read (breaking changes noted for majors) [ ] Tests pass [ ] Build passes [ ] Main flow clicked through once [ ] Broken? git revert, then move on ``` That is it. No cleverness, no bulk commands, no all-nighter. Just one clean commit at a time until the list is empty. If updating your dependencies this way for a week saves you one panic, a tip on WURK goes a long way and tells me which posts to write next. There is [more on our blog](https://jackgross-five.vercel.app) too.