Use Case · Batch Refactors

Wide Changes, One Review.

A large refactor is a partition problem. Split it into independently verifiable slices, give each worker its own checkout, and review one integration branch instead of twelve parallel surprises.

Direct answer

Batch refactoring with coding agents means running a wide, mechanical change as a supervised batch: partition it into slices with independent verification commands, run workers in isolated workspaces, repair failures with bounded escalation, and land verified work on a single integration branch. Anvaya Swarm is built for this shape: 24 concurrent workers by default (256 hard cap), shared, worktree or clone placement, Tier 0 verification with linters and tests before any model critic, and an integration gate that never pushes. A measured production run delivered three applications this way with zero merge conflicts and green integration suites, and the supervisor itself held 7.55 MB max RSS in a 32-agent soak. The pattern works when slices are verifiable; when they are not, it automates the production of plausible diffs.

The Method

Six Steps To A Reviewable Batch.

011 · Partition by module, not by fileThe unit of work should be a slice with its own test command, a package, a service, a directory with a suite. File-level partitioning maximizes merge collisions and minimizes the value of isolation.

022 · Write the verification command firstEvery task in the plan carries the command that proves it done. If a slice has no test, the plan's first task is to add one, or that slice does not belong in the batch.

033 · Isolate each workerWorktree placement gives each agent its own checkout on shared git objects: concurrent edits cannot collide, and each task's changes are reviewable as its own diff. Use clone placement when tasks need completely separate filesystem state.

044 · Run waves, not a stampedeStart with a small wave (three or four tasks) on the least coupled modules. Watch per-agent tokens and memory while it runs; verify the integration branch before widening.

055 · Repair with limitsFailed tasks escalate through a bounded ladder instead of retrying blindly: same model, then a repair role, then a wider scope, then replanning, then a human gate. The cap is what stops a confused agent from spending the budget learning the same lesson.

066 · Integrate, never pushVerified work lands on an integration branch. You review the aggregate diff, run the full suite yourself, and merge on your terms. The agent never had push authority to begin with.

Fit

Good Batch, Bad Batch.

01Good: describe once, prove per sliceSignature migrations, dependency upgrades, error-handling standardization, test backfills, codemod renames, dead-code removal with coverage evidence.

02Bad: behavior across boundariesAuth changes, billing logic, schema migrations without a human design, concurrency fixes, and anything whose verification is a reviewer's opinion.

03Good: many similar slicesTwenty modules with the same pattern are ideal: the first wave teaches you the plan's flaws before you scale to the second.

04Bad: one tightly coupled sliceIf two workers would edit the same symbols, use one agent with checkpoints, a swarm adds merge cost without adding throughput.

Questions

Asked About Batch Refactors.

What kind of refactor suits a batch?

Mechanical, wide, and independently verifiable: API signature migrations, dependency upgrades, logging and error-handling standardization, test backfills, codemod-driven renames. The change must be describable once and provable per slice.

What should never be batched?

Changes that alter behavior across module boundaries, anything touching auth, billing or migrations without a human design pass, and refactors whose verification is 'it looks right.' If slices cannot be verified independently, the batch multiplies uncertainty instead of work.

How do I control cost?

Keep verification at the cheapest effective tier, linters and tests before model critics; cap repair attempts; partition conservatively; and watch the per-agent token column while the run is live. Batch economics are per merged change, not per agent-hour.

How is this different from running a codemod?

A codemod applies a fixed transformation; an agent batch can find the places the transformation needs judgment (renamed symbols, moved files, new test shapes) and repair its own failures. Use a codemod when the rewrite is truly mechanical; use agents when each slice needs a little reasoning and a lot of verification.

Run Agents That Fit On Your Laptop.

25.6 MB median RSS. 25 agents ran in parallel on a Core 2 Duo with 4 GB RAM. Hundreds on your machine. Zero cloud required on the Ollama path.

Get Started →Read the FAQ

Requires Rust/cargo to build from source. Linux and macOS today, Windows not yet supported. Pre-1.0, public beta. Pricing TBD.