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 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 automated tests plus human sampling. What you review is not twenty changes, it is one pattern applied twenty times, and that difference is the whole method.

The security advisory that has sat on the board for three weeks

The library shipped its patch three weeks ago and the vulnerable dependency lives in twenty-three services. Each one is fifteen minutes of mechanical work: change the import, adjust two calls whose signature moved, watch the tests pass. Nobody has done it, because twenty-three times fifteen minutes is a day and a half, a day and a half fits into no sprint, and this is the kind of task that shows up in no demo. So it stays in the backlog column while the advisory is already public.

That is the work this guide is about. It is not hard, it is just a lot, and coordinating it has always cost more than doing it. Agents change that arithmetic and only that. The judgement about what should change, and the responsibility for what gets merged, stay where they were.

The entry condition is that the change follows a pattern. Creative and ambiguous work goes through the first project with agents guide, and if what you have is different tasks you want running at once, that is parallel work.

The route, and who answers on each leg

Look at where the color sits. One leg out of four is done by the machine, and it is the one that looked like the whole job. The leg that kills the most batches is the last, because the agent delivers twenty-three pull requests and its part ends there.

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 are framework or library version migrations, dependency upgrades with API changes, cross-cutting renames, adding the same instrumentation (metrics, logs, error handling) across every service, and security fixes that touch the same pattern everywhere.

List the affected places with two extra columns: who maintains each one, and whether its tests pass today. The number turns the decision into arithmetic, and those two columns prevent both surprises in step 4.

2. Define the pattern with a pilot task

The expensive mistake is launching the whole batch first. The 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 and which edge cases showed up.

That produces the asset that scales, which is the pattern description. Not “migrate to the new version” but the concrete document: what changes, in what order, which special cases exist, how each one gets checked, and what to do when something nobody anticipated turns up. It goes in a file rather than a chat window, because every replica starts remembering nothing of the one before it and whatever is not written down does not exist for number twelve. That is the same memory problem the product context for agents guide covers.

3. Scale with the right architecture

Scaling has two routes depending on where the work lives.

If it is spread across many repositories, Devin is the piece built for it: you launch the same documented pattern on each repository and get one pull request per place. It starts at $20 a month on top of a free entry plan, and consumption above that depends on volume, so the figure that matters is your pilot’s and not the pricing page’s.

If it stays on your own machine, Conductor runs several Claude Code agents at once, each in its own isolated working copy. Two limits before you plan around it: it is macOS only, and its job is parallelism across tasks on your machine rather than a sweep over twenty remote repositories. It is free, and the part usually left out deserves saying, which is that it runs on Claude Code from $17 a month. Calling the local route free only holds if you were already paying for that subscription.

Choosing between orchestrators is its own decision and the parallel agents guide owns it, including the cloud options this one does not cover. What belongs here is the rule that holds whichever you pick: launch in rounds of five, not twenty. A pattern flaw caught in the first round costs five corrections. If the deciding factor is the bill, the cost of coding with AI guide breaks down where the money actually goes.

4. Verify by sampling and automation

Reviewing twenty pull requests line by line returns the saving the way it came. Batch verification has two layers and neither replaces the other.

The automated layer covers one hundred percent. Every repository’s tests have to pass, and if the change admits a specific check (a script confirming the old pattern no longer appears, compilation against the new version), it gets written once and run across the whole batch. It is part of the pattern, not an extra you do if there is time.

The human layer goes by directed sample: a full reading of two or three replicas, and a perimeter review of the rest, looking at which files each one touched. Choose the sample by real risk, which is almost never the largest repository but the one that drifted furthest from the pattern according to the agent itself. The technique lives in the reviewing AI code guide, and if the change touches authentication, dependencies or data, the pass you want is the one in security of generated code.

The four exceptions that always show up

Batches go wrong for the same handful of reasons, and none of the four is the agent’s fault:

The repository that was already broken. You launch twenty-three and three fail their tests. The change did not break them, they were red beforehand and nobody knew. Fix this before you start by running all twenty-three suites on inventory day. The ones already red leave the batch and go on their own list, because if they stay you will spend your review debugging an old failure and blaming the agent for it.

The one with the migration half-done. Somebody started it by hand months ago and stopped halfway, so the old pattern and the new one coexist. The agent, which is looking for the old one, “fixes” backwards the part that was already right. The stop rule in the pattern document is what catches it, and this case is the reason the pattern gets written down instead of explained in a message.

The fork with local patches. The odd repository, the one that split off two years ago carrying changes that exist nowhere else. The pattern fails there in ways that do not resemble each other. Mark it in the inventory for a full reading and take it out of the time estimate, because it will cost what five of the others cost.

The one that passes the tests and changes behavior. The whole batch green and something still moved: a serialization format, a time zone, a rounding rule. This is the expensive exception because no automated layer sees it. You solve it in the pilot, by writing into the pattern what that project’s tests do not cover, and using that sentence as the script for the directed sample.

What to watch to know the method is working

Three numbers you count yourself, without asking anyone for a metric:

How many replicas landed first time, with no edit to the pattern and none to the result. If round one gives you five out of five, raise the round size. If it gives you two, the pattern is badly written.

How many times you changed the pattern after launching. It is the direct measure of whether the pilot was worth anything, and one that changes three times was done in a hurry.

How many pull requests are still open after seven days. This is the one nobody looks at and the one that says whether the batch worked. Twenty-three open branches are not a finished migration, they are debt under another name, with conflicts ripening.

The approval boundary

The agent opens pull requests and merges none, and this is not a style preference.

Green CI is a gate, not an approval: it says nothing we knew how to check has broken, which is a good deal less than saying the change is right. Every pull request needs a named owner in that repository, and that is why the step 1 inventory carries the maintainer column. A repository with no identified owner does not enter the batch, because its pull request is going to stay open forever.

Keep three things per batch: the pattern document, which replicas were read in full, and who approved each merge. With those, the question six months from now (“who changed this, and on what basis?”) gets answered by looking. The whole sector lives in AI for software development.

Frequently asked questions

What batch size justifies this method?

From five replicas, pilot plus rounds already beats going one by one. Below that, building an inventory and a pattern document for three places costs more than it saves.

Devin or Conductor for batches?

Devin for many repositories in the cloud. Conductor for a batch inside your own environment, on the Claude Code subscription you already pay for. If you are unsure, start local: the expensive route earns itself once the inventory passes ten places.

When is a batch NOT worth setting up?

When the pattern has more exceptions than clean cases, which you know the moment the pilot ends. Also when the places belong to many different teams, because then the bottleneck is not making the change but collecting twenty approvals, and no agent speeds that up. And when each place needs its own product decision, which is not mechanical work however much it looks like it.

What if my company does not accept pull requests written by an agent?

It happens, and it is not always stubbornness. What usually sits behind it is that nobody wants to review code no person answers for. The way through is that you sign the pull request, that its body states which pattern and which tool generated it and which replicas were read in full, and that you start with the repositories your own team maintains. Two clean documented batches later, the conversation changes on its own.

What does a twenty-migration batch cost?

With Conductor, what you already pay for Claude Code, which starts at $17 a month. With Devin, which starts at $20 a month, the subscription plus consumption above the plan, which depends on volume and is therefore estimated with the pilot before committing all twenty. Neither figure includes what a batch actually costs, which is the review hours on the sample.