Dependency upgrades with AI agents: sort the queue before you delegate it

The advisory arrives at 09:12, about a package you have never typed, five levels down in the tree. You open the repo, run the outdated command for your language, and get 43 rows back. Six are majors. One is the framework. Somewhere in the tab bar, a bot's upgrade pull request from March is still open, still red, still unassigned.

None of it is hard. That is the whole problem: a pile of small, unrewarding jobs that never fit the afternoon you actually have. So the obvious move is to hand the pile to an agent.

The instinct is right. The pile is wrong. Sorting the queue first is what makes delegating it work, and it takes about ten minutes.

Why the dependency backlog never moves

Every upgrade asks you to prove a negative: that nothing broke. No demo at the end, no feature in the ticket, and the only outcome is the absence of an incident. So it loses every priority fight it enters, until an advisory or a blocked release forces six months of upgrades into one week, which is exactly when mistakes land.

It is also not the shape of a big framework migration, where one change fans out across four hundred files. It is many small changes spread across time, each cheap, all of them deferred.

Sort the queue by what can prove it safe, not by semver

The useful question is not "how big is the version jump." It is what evidence would convince me this upgrade changed nothing. Answer that per package and the queue falls into three lanes.

Lane 1: the bot's work. Patch and minor releases in packages your test suite genuinely exercises. GitHub's own description of the loop is the whole job: tests pass, skim the changelog, merge. An agent adds nothing. If you are pasting these into a session, the fix is your bot config, not a model.

Lane 2: agent-shaped. Majors with written release notes and call sites you can find: a renamed method, a moved config key, a helper that now wants an object instead of three arguments. Mechanical once somebody reads the migration guide, and reading the migration guide is the part you keep postponing. This is where an agent earns its keep.

Lane 3: yours. Anything the suite barely covers, anything wired to money, auth or background jobs, and majors whose changes are silent: a default that flipped, a timezone assumption, a rounding mode. No green suite proves these, so no agent can hand them back proven.

A typical 40-package backlog lands roughly 30 in lane 1, 8 in lane 2, 2 in lane 3. Your agent time goes to those eight.

The brief that makes an upgrade agent-shaped

One package per session. Fill in the blanks and reuse it verbatim:

Upgrade <package> from <current version> to <target version> and nothing else. First, read the release notes between exactly those two versions and list every breaking change that touches this repo, with file and line. Then apply only those changes. Run <test command>. Do not edit tests to make them pass. If anything in the diff is not explained by the release notes, stop and tell me.

Every clause is load-bearing. One package per session keeps blame bisectable when the suite goes red tomorrow. The exact version pair stops the agent reading today's documentation for a version you are not on, which is how a 2.x to 3.x upgrade quietly picks up 4.x idioms. "Not explained by the release notes" turns silent improvisation into a report, the most valuable output of the run. And "do not edit tests" holds here for the reason test-driven work with agents always comes back to: an agent graded on green will find green, and relaxing an assertion is the cheapest path there.

Read the lockfile diff, not the manifest diff

The manifest shows one line changed. The lockfile shows what actually happened: thirty packages moved, four are new, one arrived with an install script.

That is the review surface: transitive packages nobody chose, a dependency whose repository URL changed hands, and any install flag the agent added to make resolution work (--legacy-peer-deps and --force both mean "I gave up on the constraint"). The habits from reviewing agent output apply directly: read the diff for what appeared, not only for what you asked for.

Worth naming, too: release notes and migration guides are text written by strangers, pulled into your session, read by a model that cannot tell prose from a command. That is the ordinary entry point for prompt injection, and an upgrade sweep reads dozens of those pages in a row.

Where agent-run upgrades go wrong

The honest section, as the four objections that turn out to be right.

"The suite passed, so the upgrade is fine." Your suite covers the code you wrote, not the behavior you inherited. Green after a major is evidence, not proof. A research framework built for this exact job (multi-agent LLM dependency upgrades) reported 71.4% precision on synthetic Java upgrades. The rest is why somebody still reads the diff.

"Renovate already does this." It does lane 1 perfectly, opens the lane 2 pull request, then leaves the breaking changes to you. That ceiling is precisely why the March pull request is still open.

"Just upgrade everything in one branch." Then one red test has 43 suspects, and bisecting costs more than the sweep saved. Batch by package, or by tightly coupled group at most.

"It fixed the incompatibility." Check how. The common quiet failure is an agent that meets the goal by pinning the old version back, adding a shim nobody asked for, or loosening a type until the compiler stops arguing.

The cost is real, too: a lane 2 session burns tokens reading release notes and hunting call sites before it writes a line. Fine in a slot you chose, expensive mid-feature, which is the argument for running upgrades as a scheduled chore.

A workspace where the upgrade queue runs beside real work

Eight lane 2 upgrades do not want eight terminal tabs that all look identical.

SanuDesk is a desktop app built for that shape. Your Claude Code, Codex and Gemini sessions tile into one grid, so each pane is one package and a stalled upgrade is visible instead of buried. A Kanban board sits beside the grid: one card per upgrade carrying the version pair and the acceptance criteria, deployed to a fresh session with one click, landing in a review lane with a what-changed note when the agent stops. The weekly sweep that rebuilds the queue (run the outdated command, check advisories, sort into lanes, drop the cards) becomes a Loop: same brief every run, journaled. It drives the model subscriptions you already pay for, and grid and board are in the free plan (see pricing).

Run the read-only half tonight

Take the oldest major in your queue. Open one session and run only the first half of the brief: list every breaking change between your version and the target that touches this repo, with file and line, and change nothing.

Five minutes later you know whether that package is lane 2 or lane 3, and that fact decides how the rest of the queue gets done. Better to learn it tonight than in the week an advisory decides for you.

Download SanuDesk free to keep the upgrade queue on a board beside the work it interrupts, or see how the grid, the board and Loops fit together on the features page.