Why "Just Run Claude Against Your Repos" Doesn't Work at Scale

Every conversation about maintenance automation reaches the same question. It comes from a Staff Engineer, sometimes a CTO, occasionally an intern who has been handed license to be provocative.

The question: “What’s stopping us from just running Claude against our repos in a loop?”

It’s a fair question. Claude Code exists. Codex CLI exists. The APIs are cheap. Every AI coding tool now supports scripting. If the task is “make the same change across a hundred repos,” a bash loop that clones each repo, runs an AI tool, and opens a PR looks like a weekend project.

For ten repos, it is. For a hundred, it isn’t. This is what happens when teams try to run an AI coding agent across every repo they own.

You can script an AI coding tool to run across every repo, and it will generate changes. Generating the change is about 20% of the work. The other 80% is reviewing failures, handling repo-by-repo differences, tracking what actually merged, and driving every change to completion. A loop does not do that part.

What works at ten repos and breaks at a hundred

The naive version of “run Claude against every repo” works well at ten repos. The prompt is straightforward. The tool is capable. Ten rounds of clone, run, push take an hour on a laptop. Two of the PRs have issues, and the engineer who wrote the script fixes them by hand. The initiative is done. Everyone agrees the script was a good idea.

The math changes at a hundred repos. It changes again at three hundred.

Assume the tool succeeds on 85% of repos. That sounds great. In practice it means fifteen failures out of a hundred. Fifteen is manageable to hand-review. Now assume 85% success on three hundred repos. That is forty-five failures. Forty-five failures is a full-time job for a week. And the failure modes are not distributed evenly. Some are trivial, like a prompt that didn’t know one repo used a different naming convention. Some are real bugs, where the tool generated code that compiles but is subtly wrong. Some are false negatives, where the tool flagged a safe change as risky and refused it.

Reading forty-five failure logs and deciding which ones matter consumes a platform engineer’s week without producing anything the rest of the organization sees. It is the work the naive script was supposed to eliminate.

Why doesn’t a high success rate ship the change?

The success-rate framing hides most of the actual problems. Even the 85% that “succeeded” often didn’t ship.

Different stacks per repo. Your prompt says “upgrade this to Node 24.” Some repos have package.json. Some add a lockfile. Some carry nvm config, some .node-version, some asdf config, some all three. Some declare engines. Some are TypeScript. Some are ESM. Some pin dependencies. A single prompt does not know any of that. The tool makes reasonable guesses that turn out wrong in the specific ways each repo diverges from the norm.

Failure rates compound. For a single change, 85% success is fine. For a five-step migration (update dependencies, update the Dockerfile, update CI config, update the lockfile, update the deployment manifest), 85% per step compounds to about 44% end-to-end. A hundred PRs go out. Fifty-six carry at least one step wrong.

At 85% per-step success, a five-step migration completes correctly end-to-end on only about 44% of repos.

CI fails silently on some repos. The tool ran. The PR opened. Nobody watches that repo often, and CI has been red for weeks for unrelated reasons. Nobody notices the new PR made CI redder. The change merges. The change ships. The repo is broken. Someone catches it weeks later when they try to deploy.

Reviews get gamed by volume. A hundred PRs from a script land in the review queues of forty teams. Some teams have review-quality gates. Others approve on ping. The PRs that merge fastest sit in front of the lowest-attention reviewers. The PRs in front of the strictest reviewers wait longest. Over time the initiative looks “done” even though the highest-quality repos never merged the change.

There is no re-run policy. The script ran once. Half the PRs merged. What now? Re-run the script? Against which repos? What about the ones where the PR is open but stuck? What if the tool now makes a different change because the model updated last week? The naive script has no answer.

The prompt drifts. A teammate updated the prompt to handle a case they hit last week. Now it behaves differently, and nobody documented the change. The initiative is no longer reproducible. Six months later, when someone asks “what did we do for this migration?”, the answer is “we ran a script, but it’s been rewritten four times and the original is gone.”

None of these failure modes are Claude’s fault. They are what happens when you take a tool built for interactive use and run it as an unsupervised batch process across a heterogeneous fleet.

What the objection actually reveals

When an engineer says “why not just run Claude against our repos,” they are usually right about the technical primitive and wrong about the scope of work. The primitive is real. You can wrap an API call in a for-loop. It does a thing. It can fairly be described as “just” running Claude.

What the framing misses is that generating the change is roughly 20% of the total effort of shipping the change at scale. The other 80% is reviewing the failures the tool produces, handling the heterogeneity across repos, actually shipping through CI and review and merge rather than only opening PRs, tracking what merged and what stalled and what needs a follow-up, and managing the initiative as it evolves.

At ten repos, that 80% is a few hours of extra work, and everyone accepts it. At a hundred repos, the 80% is weeks. At three hundred repos, the 80% is a quarter.

The objection is answered by acknowledging what the AI tool doesn’t do. Generating the code is one part of a maintenance initiative. Coordinating it to completion across dozens of teams is the harder and larger part. Claude writes the code. It doesn’t ship the code. Between those two things is where the initiative actually lives, and the naive script has no answer for any of it.

How to apply the same code change across every repo

Teams that succeed at running AI-assisted changes at scale share a pattern. It looks different from “run a script” and different from “buy a platform.” It looks like a workflow.

1. Define the change once, precisely. Write a specification, not a chatty prompt: what files to touch, what patterns to change, what to leave alone, version-controlled and re-runnable.
2. Run it against a preview batch first. Start with a dozen representative repos, read the diffs before anything is pushed, and refine the specification until the failure rate drops.
3. Track every repo’s state. Record whether the change applied, whether tests passed, whether CI went green, whether a PR opened, whether it was reviewed, and whether it merged.
4. Re-run against the stuck ones. A repo that failed the first time often succeeds on the second, but only if you know which repos are still stuck.
5. Own the merge, not just the generation. The initiative is done when changes are merged, so treat every unmerged PR as a repo where the work failed.
6. Report on what shipped. Track “changes shipped,” not “PRs opened,” and not “generation success rate.”

That is a system. It is the difference between running a tool and running an initiative.

Build the other 80%, or use a tool built for it

The “just run Claude” objection isn’t wrong to raise. It’s the right question. The answer isn’t “you can’t.” The answer is “you can, it gets you 20% of the way, and the other 80% is still your problem.”

Some teams accept that math and build the other 80% themselves. That is a reasonable choice with a platform team that has capacity and a mandate to build internal tooling. It is also a real project, not a weekend. Expect to maintain the coordination layer for years.

Other teams treat shipping code changes at scale as a category of work that now exists, has known patterns, and can be handled by tools built for it. That is why platforms for code maintenance exist. They are the coordination layer that turns “we can generate changes” into “we can ship changes.”

Tidra is an AI coding agent for both implementation and coordination of code changes across your organization. It scopes an initiative, generates the change for every targeted repo, opens each change as a reviewable pull request, and tracks review and merge across teams from one place. The user iterates on the plan and the diffs before any PR is created. Get started with a real initiative.

A platform engineer we worked with put the tradeoff plainly: “We tried the script version for two months. We got about halfway through the migration. The problem wasn’t Claude. Claude wrote the code fine. The problem was that we still had to do everything else, and we ran out of time for it.”

The script isn’t wrong. It’s incomplete. The only question left is who owns the other half, and for how many quarters.

Tidra handles the other 80%: scoped initiatives, PRs generated and tracked, review and merge coordinated across every repo. tidra.ai/get-started