219 PRs in One Day: A Parallel Agent Fan-Out Postmortem

The Setup

I run a small empire: 35 apps under the developersdigest org, each one a separate repo, most of them deployed on Coolify, a few stragglers still on Replit and Vercel. Migrations across that many repos used to mean a week of context-switching. This week I tried something different: spawn one subagent per repo, fan out, let them work in parallel, then come back and review.

The session shipped 219 pull requests in one day. Here is the honest breakdown - the patterns that survived contact with reality, the ones that exploded, and the fixes that turned chaos into a repeatable workflow.

Why Parallel

The work was embarrassingly parallel by nature. Same migration, 35 different codebases, no shared state. A sequential loop would have taken eight hours of agent time and probably twelve hours of me babysitting tool calls. A parallel fan-out is bounded by the slowest agent, not the sum of them.

The pitch is simple: if your task decomposes into N independent units of work, the wall-clock time should be dominated by the longest unit, not N times the average. That is the whole shape of the speedup. Three sequential searches are slower than three parallel agents. Three hundred sequential migrations are catastrophically slower than three hundred parallel ones.

Patterns That Worked

Tight scope per agent. Every agent got one repo, one branch, one PR target. No agent was allowed to touch shared infra. No agent could decide its own scope. The prompt was a checklist, not a goal. When I gave agents room to interpret, they invented work - extra refactors, README rewrites, dependency bumps nobody asked for. When I gave them a checklist, they finished and stopped.

The honest-skip rule. I baked into every prompt: if this repo does not match the migration profile, return SKIPPED with a one-line reason and exit cleanly. This was the single most useful pattern. Without it, agents will hallucinate work to look productive. With it, ~40 of the 200+ runs returned honest skips - repos already migrated, repos that were docs-only, repos with no deploy target. Those skips saved hours of cleanup.

/tmp/<slug>/ isolation. The first thing I tried was running multiple agents against the same local checkout. Catastrophic. Branch switches collided, working trees got tangled, two agents committed to each other's branches. The fix: every agent clones fresh into /tmp/<repo-slug>/, works there, pushes, opens its PR, and never touches the canonical local copy. Disposable working directories are non-negotiable for parallel work.

Patterns That Broke

Rogue pkill collisions. A few agents had build steps that ran pkill -f next to clean up dev servers. With twenty agents running simultaneously, one agent's cleanup killed another agent's build mid-compile. Builds failed for reasons that had nothing to do with their code. I lost an hour chasing ghost failures before I traced it.

Disk fill. Two hundred clones of medium-sized Next.js repos plus 200 node_modules installs blew through 60GB. Coolify started returning 500s on unrelated apps because the host disk was full. docker builder prune -f fixes this after the fact, but the better answer is to never let it happen.

False-empty remotes. Several agents reported "nothing to commit, branch is clean" when in fact they had simply failed to detect modified files because they had cd'd into the wrong directory after a clone. The PR opened but contained zero diff. From the dispatch log it looked like a successful run. I caught these only by spot-checking PR diffs by hand.

Fixes

Build-lock script. A simple flock-based wrapper around any command that touches a shared resource. Builds serialize through the lock, everything else stays parallel. Crude but it works.

Fallback to local copies. When a /tmp/<slug>/ clone failed for billing or network reasons, fall back to copying from a local cache directory rather than failing the run. Saved a dozen agents during a brief GitHub API blip.

Narrow filters. Instead of "run this on every repo," I now generate the target list explicitly with a query - "repos with nixpacks.toml and no coolify.yml, modified in the last 90 days." Smaller, sharper target list, fewer wasted runs, fewer false-empty PRs.

Outcome

219 pull requests opened. Maybe 70% of them are mergeable as-is. The rest need small edits - a wrong env var name, a stale port number, a missing health check. The bottleneck now is not agent capacity. It is human review bandwidth and, embarrassingly, a GitHub Actions billing cap I hit around PR 180.

Two non-code lessons came out of this:

1. Devin review is the new rate limit. I tag @devin-ai-integration on every DD PR for a second-pass review before merge. With 200+ open PRs that queue is now the choke point. Parallelizing the agent does nothing if the reviewer is serial.

2. GitHub billing scales with your agents. I tripped a private-repo Actions minute cap I had never come close to before. Worth budgeting for if you plan to run anything like this regularly.

The Skill Codification

The whole recipe - the clone pattern, the honest-skip rule, the build lock, the PR-and-tag-Devin flow - is now a single skill called replit-to-coolify. I trigger it with one phrase and a target repo, and the same well-debugged prompt runs every time. That is the actual outcome of a session like this. Not the 219 PRs. The 219 PRs are the artifact. The skill is the asset.

Next time I have a many-repos-one-change job, I do not have to re-derive the patterns. I run the skill, fan out, and review. The whole cycle from "I should migrate these" to "PRs are open" collapses from a week to an afternoon.

If you are sitting on a portfolio of repos that need the same change, the leverage is real. Just budget for the disk, the billing, and the reviewer queue before you press go.