How to run migrations and batch tasks with coding agents

TLDR: The work nobody wants (migrating twenty repositories to the new version, upgrading the library across the monorepo, applying the same mechanical change in a hundred places) is exactly where agents pay off beyond argument. The method: a pilot task that defines the pattern, Devin or Conductor to scale in parallel, and verification through automatic tests plus human sampling. What never penciled out in human hours is now an afternoon.

This guide is for teams with accumulated mechanical debt: the postponed upgrades, the migrations pending for two quarters, the cross-cutting changes nobody prioritizes because they bore. It is the use case where agents have the best value-to-risk ratio, because the work is repetitive and verifiable.

The entry condition: this works for changes that follow a pattern. The creative and the ambiguous go through the normal flow of the first project with agents guide.

1. Identify the work that is batch work

Batch work is recognized by its structure: the same conceptual change applied in many places, where each application needs local adaptation but the pattern is identical. The classics: framework or library version migrations, dependency upgrades with API changes, cross-cutting renames or restructures, adding the same instrument (metrics, logs, error handling) across all services, and security fixes touching the same pattern everywhere.

The upfront inventory is worth it: list the affected places (repositories, modules, services) before starting. That number turns the decision into arithmetic: twenty places at half a human hour each is two days of boring work, and that is the figure the batch competes against.

2. Define the pattern with a pilot task

The expensive mistake is launching the whole batch first. The serious method starts with a pilot: pick the most representative case and solve it with Claude Code in supervised mode, paying attention to which decisions had to be made, which edge cases appeared and how you verified it was right.

From that pilot comes the asset that scales: the pattern description. Not “migrate to the new version” but the concrete document: what changes, in what order, which special cases exist and how each gets checked. The better that pattern is written, the less supervision each replica demands.

The pilot also gives the honest per-unit cost and time estimate, which multiplied by the inventory tells you whether the batch is an afternoon or a week.

3. Scale with the right architecture

With the pattern defined, scaling has two routes depending on where the work lives.

For large batches across many repositories, Devin is built exactly for this: you launch the same task with the documented pattern on each repository, the agents work in parallel in the cloud and you receive one pull request per place. It is its star use case and where its quota pays for itself in the first round. From $20 a month with overage at API prices: estimate with the pilot before launching all twenty.

For batches inside your environment with close supervision, Conductor parallelizes Claude Code on your Mac: each replica in its isolated repository copy, with the panel to watch and merge. Free on your existing subscription, with the full mechanics in the parallel agents guide.

On both routes, the batch’s golden rule: launch in rounds (five, not twenty), because a pattern flaw detected in round one costs five corrections, not twenty.

4. Verify by sampling and automation

Reviewing twenty pull requests line by line returns the saving the way it came. Batch verification has its own two-layer technique.

The automatic layer covers one hundred percent: each repository’s tests must pass, and if the change admits a specific verification (the script checking the old pattern no longer exists, compilation on the new version), it gets written once and run across the whole batch. That written verification is part of the pattern, not an extra.

The human layer goes by directed sample: full review of two or three replicas chosen by risk (the most complex repository, the one that drifted most from the pattern according to the agent itself) and perimeter review on the rest, looking at which files each one touched. The detail of that technique is in the reviewing AI code guide.

With the batch merged, document the pattern where the next person will find it: the next similar migration starts with half the work done. The whole sector lives in AI for software development.

Common mistakes

Launching the batch without a pilot. A pattern flaw multiplies by the batch size, and correcting twenty crooked replicas costs more than the original work.

Reviewing everything or nothing. Both extremes fail: full review returns the saving, and blind trust accumulates the risk. Directed sampling plus automatic verification is the point.

Slicing into rounds too large. The round is the early detection mechanism: five replicas expose the pattern flaw at an affordable cost.

Forgetting the places with history. The odd repository (the old fork, the one with local patches) is where the pattern fails. When inventorying, mark them for full review.

Frequently asked questions

What batch size justifies this method?

From five replicas, pilot plus rounds already beats going one by one. Below that, the normal supervised agent flow covers the case without ceremony.

Devin or Conductor for batches?

Devin for many repositories in the cloud and tasks that fly alone. Conductor for the batch inside your environment with close supervision and zero added cost. Size and code sensitivity decide.

What does a twenty-migration batch cost?

With Conductor, the extra consumption of your Claude quota. With Devin, the monthly quota plus overage, which the pilot lets you estimate precisely before committing.

What if the pattern has exceptions?

Exceptions caught in the pilot go into the pattern document with their treatment. Ones discovered mid-batch stop the round, update the pattern and relaunch: that discipline is the difference between a batch and a wreck.