Think back to December 2021. Log4Shell.
If you were anywhere near security or platform work, you remember that week. The fix sounded simple: upgrade log4j. Then you tried to find every place log4j lived. That’s when the week turned into a month.
The hard part of a big vulnerability was never writing the patch. It was opening the same patch in every repo you own.
How big it really was
Google’s open source team measured the blast radius across Maven Central, the main Java package repository. As of December 16, 2021, 35,863 Java artifacts depended on the affected log4j code. That’s more than 8% of every package on Maven Central. For comparison, the average advisory affecting Maven Central hits 2%, and the median hits less than 0.1% (Google Security Blog ).
The depth was the real problem. For more than 80% of affected packages, log4j was more than one level deep in the dependency chain. A majority were five levels down. Some were nine.
At the time Google wrote it, nearly five thousand affected artifacts had been fixed, which they called a mammoth effort. That still left over 30,000. And looking at earlier critical advisories, less than half (48%) of affected artifacts had ever been fixed. Google’s own read was that we might be in for a long wait, “likely years.”
That’s the public ecosystem. Now picture your own company’s repos on top of it.
Why people stall on this work
I don’t think teams are lazy about this. Fan-out work is just built to stall.
It’s boring. The same change, again, in a repo you’ve never opened.
It spans teams. The security team finds it. Forty other teams have to fix it. Every one of them has a sprint already.
Every repo is a little different. Different build tool, different test command, different CI quirks. The change takes five minutes. Getting the build green takes an afternoon.
Half the repos have no clear owner. The person who wrote it left. The team got reorganized twice.
So the tickets sit in backlogs. The spreadsheet gets longer. Somebody sends a reminder email every Friday.
The agent version
This is the kind of work agents are good at, because it’s the same task many times with clear success criteria.
Plan once. Write down the change, how to find affected repos, and how to check the fix. For log4j that’s “move to a fixed version, or remove the dependency.” Detection means checking lockfiles and the resolved dependency tree, not just the top-level manifest, because most of the exposure was indirect.
Find every affected repo. Let the agent search all of them, not just the ones on someone’s list.
Fan out. One agent per repo. Each one makes the change, figures out that repo’s own build and test commands, runs them, and opens one PR. Same branch name, same PR title, same description template everywhere, so reviewers know what they’re looking at.
Report back. Not 400 notifications. One report.
Here’s what the middle of that report looks like:
payments-api PR opened, tests pass
checkout-web PR opened, tests pass
inventory-sync PR opened, 2 tests failing (also failing on main)
legacy-reports build broken before the change, needs an owner
do-not-touch-ever PR opened, tests pass
notifications PR opened, tests pass
search-indexer blocked: waiting on upstream library release
The agent doesn’t merge anything. Owners review and merge their own PRs. The agent just made sure every owner has a PR in front of them by lunch, instead of a ticket in front of them next quarter.
Where it breaks
Agents don’t fix the parts of your codebase that were already broken. They just find them faster.
Repos with no tests. The agent can make the change, but nothing proves it works. This is the noise floor problem from the last post all over again. If the tests can’t be trusted, neither can the green PR.
Repos nobody owns. The PR opens and sits there. That’s an org problem, but now it’s a visible one.
Repos that haven’t built in two years. The change is fine. The build was already dead. The report should say so plainly.
Blocked upstream. If the vulnerable code is five levels deep in someone else’s library, your agent can’t fix it. It can tell you exactly which library, which version you need and which of your repos are waiting on it. That alone saves days. It’s also a reminder of what open source really costs to maintain, which I wrote about in free like a puppy .
What a good report looks like
One page. Two audiences.
The top is counts. Affected repos. PRs open and passing. PRs open and failing. Blocked upstream. No owner. Leadership reads this part and asks one question: when does the first number hit zero?
The bottom is the short list that needs a human, with the reason for each. Security works this part.
Nobody needs a spreadsheet of 400 rows. They need to know which 12 repos are the problem.
A few guardrails
PRs, not merges. Owners stay in charge of their code.
Rate limit the fan-out. 400 PRs at once will melt your CI. Batch them.
Same template everywhere. Reviewers should know what the PR is from the title.
Rerun when it changes. When a new fixed version ships, the plan updates and the agents run again on whatever is left.
The next one is coming
There will be another Log4Shell. Maybe not that bad, maybe worse. The patch will probably be simple again. The work will be every repo it touches.
The question isn’t whether you can write the fix. It’s whether rolling it out takes a week or a quarter. In the on-call post the clock was minutes. For this kind of work the clock is weeks, and that’s where agents can save the most time.