Writing

Sweeping codebase changes feel safe until they are not

Sweeping codebase changes feel safe until they are not. I have seen migrations start with a clear target, a script, and a list of repos. The first few diffs look reasonable, so the batch keeps running. A week later there are hundreds of open pull requests, some outdated, some conflicting, and a few that quietly changed behavior in a library no one has touched in years. The ease of generating changes creates a false sense of control.

Agentic Batch Changes tries to flip that dynamic for me. At first, the headline feature is plain-language prompts across thousands of repositories. That sounds ambitious, and it is. But the more important shift is outcome-based pricing tied to merged changesets. Paying for merged changesets, not attempted edits, changes what the vendor optimizes for.

What I keep coming back to is that most large-scale migrations do not fail on code generation. They fail on governance, review bandwidth, and rollback confidence. A model can produce a plausible diff in seconds. It cannot make a maintainer available to review it, it cannot prove that a change does not break a downstream integration, and it cannot guarantee that a bad merge can be reverted without an incident. Pricing against merged changesets aligns vendor incentives with actual delivery, which is the point of the change.

But the same incentive alignment raises the bar for everyone involved, including me as a reviewer. If the vendor is paid only for merges, they will care about making diffs easy to approve. That is good. But they may also push for broader auto-merge permissions or lower the threshold for what counts as a successful review. I still need diff-level review, approval workflows, and guardrails before anything auto-merges. Batch scale is not a substitute for change control.

The need for diff-level review does not disappear just because a thousand diffs are generated. In fact, it becomes the bottleneck. Auto-merge without human review is how a syntactically correct change becomes a semantic regression. The guardrails have to be defined before the batch runs: which repositories can auto-merge, which require an owner, and how many approvals are needed for a change that touches shared libraries.

Rollback confidence is another non-negotiable for me. A merged changeset across many repos can be hard to reverse if the tooling does not track which changes belonged to the same batch. The vendor's pricing model may reward merges, but I still bear the operational cost of a bad merge. That asymmetry is why approval workflows and guardrails cannot be hand-waved away.

In practice, that means defining what a legitimate review is. Does a bot approval count? Which CI checks are mandatory? Who can override a failing test? What is the rollback path if a merged changeset causes a regression? Those questions are not new, but they become sharper when the vendor has a financial interest in the merge.

The real shift, then, is not that agents can now touch thousands of repos. It is that the pricing model forces both sides to be explicit about what is being delivered. I am not buying generated code. I am buying merged, reviewed, reversible changesets. And that requires the same discipline at scale that I would apply to a single risky pull request.

Mass change is easy to trigger. Mass trust is not.

Originally covered at sourcegraph.com ↗