I once worked at an office where the boss made us run a dependency version check every two weeks. It was genuinely the right workflow, and we stuck to it every time — never with any pleasure, but with a clear understanding that it absolutely had to be done. Someone would open every repo in turn, diff the lockfile against the registry, and write down what had moved. Most sprints it found nothing worth acting on. You still did it, because the sprint where you skipped it was the one where something had moved.
Now we have an agent that does the same sweep, once a week instead of once every two, across every repository we run rather than the one or two a person had time for. The strange part is not that it works. The strange part is how completely we have stopped thinking about it — right up to the morning its tasks land on the board across every project at once.
What the old ritual actually cost
The fortnightly check was never expensive in theory. In practice it ate a real afternoon, and the time distribution was lopsided: perhaps 90 percent of it went into confirming that nothing had changed, and the other 10 percent into the one package that had. You can't tell in advance which afternoon is the expensive one, so you pay the full price every time, on the chance that this is the time it matters.
That cost structure is exactly why the check was also the first thing to slip. A dependency sweep competes for attention against a feature with a deadline, and a feature with a deadline always wins a single round. The problem is that it's not a single round — it's a standing obligation, and an obligation that loses once tends to lose again, because nothing visibly breaks the week you skip it. Skip it twice and you've normalized skipping it. Six months later nobody remembers the last time anyone looked, and the gap between "safe to ignore" and "overdue" has quietly become a gap nobody is tracking at all.
We know this because it happened to us, on a smaller scale, before we had anything watching for it. Dental Landing — one of the two Astro marketing sites — had never been swept, not once, until the agent got to it. Nobody had decided not to check it. It had simply never come up, because it never broke, and a thing that never breaks never earns a slot in anyone's fortnight.
Why weekly beats fortnightly once it's free
Once the check costs an agent's time instead of a person's, the obvious move is to run it more often, not just automate the old cadence. Weekly instead of fortnightly roughly halves the gap between a major version landing upstream and us finding out about it — which matters more than it sounds, because the size of a diff grows with how long you waited to look at it. A one-week-late upgrade is a changelog entry. A six-month-late upgrade is an afternoon of reading release notes for versions you skipped entirely, trying to work out whether the thing that broke is the thing you just bumped or something three versions back that finally surfaced.
Small, frequent diffs are also the only kind anyone actually reviews properly. Put a four-major-version jump in front of a reviewer and they skim it, because reading every line of a dependency's internal rewrite is not a realistic ask. Put a one-minor-version bump in front of the same reviewer and they can actually reason about what changed. Weekly sweeps keep almost every diff in the second category.
What the agent is good at that we weren't
A person doing this job gets bored, and boredom is where the drift gets missed. The agent doesn't get bored, and it reads every repo on the list every single week, including the one nobody has opened in a year.
It also notices a kind of drift a human skims straight past: relative drift. One recent sweep flagged that a service's own HTTP client library was three major versions behind the same library in its sibling services — not behind upstream in some abstract sense, but behind the version its neighbours in the same fleet were already running. That's an easy thing to miss when you're checking packages one repository at a time, and an obvious thing to catch when something is checking all of them in the same pass and comparing notes.
That one sweep is a fair sample of what a week actually produces. It filed seven tasks in a single pass: a MongoDB version that had gone end-of-life, which is urgent, sitting next to a Postgres three majors behind, which is not; an API gateway two majors out of date in front of every service that gateway fronts, on both the dental platform and its clinic twin; a cluster of backend services four majors behind across their framework, validation library, document-mapper and mail client; a frontend with multiple major version jumps piling up across its UI library, router and build tooling; and the first-ever sweep of that one marketing site nobody had opened in a year, which turned up exactly one major version behind and not much else.
Seven tasks from one quiet week is not an exaggeration of what "we forgot to check" costs. It's close to the actual number.
It files tasks. It does not upgrade.
This is the part worth being precise about, because it's the part that makes the whole thing trustworthy rather than alarming. The agent's job ends at writing down what it found and how urgent each finding is. A MongoDB end-of-life and a gateway major version in front of every service in production are not the same decision, and a sweep that says so plainly — one flagged critical, one flagged "behind but not urgent" — is worth more to us than one that quietly opens a pull request for both and lets us discover the difference in the diff.
This site is itself a fair example of how a sweep actually turns into a shipped change: it went through two tiers, the safe bumps landing first and the framework's own major version landing second, as separate, reviewed steps rather than one undifferentiated jump.
The humans are still exactly where you'd want them to be for the part that matters. Someone reviews every diff before it's approved. Someone runs the stack and checks it against the running system before anything is called done. And nothing reaches the live site until a person accepts it, by name, on purpose. A gateway major version sitting in front of every production service is precisely the kind of change you do not want landed quietly at three in the morning by anything, agent or otherwise — and nothing in this setup lands it that way.
The part people don't expect
The honest cost of this is that the agent generates real work. A quiet week on the calendar becomes seven tasks on the board, all at once, all needing a decision. That's not a side effect to tolerate — it's the point. The alternative isn't zero tasks; it's the same seven tasks, discovered eighteen months later, compressed into one much worse week, after something has already broken because of them.
What we'd tell someone about to try this: don't expect the ritual to disappear. Expect it to get honest. The fortnightly check we used to run by hand wasn't really finding problems most of the time — it was mostly confirming there weren't any, at the cost of someone's afternoon regardless. What changed isn't that the problems went away. It's that we only spend attention on the weeks there's actually something to decide, and we trust that the other weeks were genuinely checked rather than quietly skipped.
Top comments (0)