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

Last updated: May 6, 2026

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 - the same Replit-to-Coolify migration work referenced below. 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. Some of that review load is why I also lean on writeups like our build log for the DevDigest blog agent content system to document exactly what a working agent pipeline looks like once it settles.

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. If you have not run agents at this scale before, building 24 apps with AI agents is a good look at the smaller-scale version of the same discipline before you fan out to hundreds of PRs.

FAQ#

How many Claude Code subagents can I safely run in parallel?#

There is no hard model-side limit, but practical limits show up first in shared infrastructure: disk space (each clone plus node_modules adds up fast), GitHub Actions billing minutes, and your own review bandwidth. In this run, 200+ concurrent agents against 35 repos blew through 60GB of disk and tripped a private-repo Actions minute cap around PR 180, well before hitting any agent-count ceiling.

Why did agents collide when working in the same local checkout?#

Running multiple agents against one shared local checkout causes branch switches to collide and working trees to tangle, with agents sometimes committing to each other's branches. The fix is disposable isolation: every agent clones fresh into its own /tmp/<repo-slug>/ directory, works there, pushes, and opens its PR without touching the canonical local copy.

What is the "honest-skip rule" and why does it matter?#

It is a prompt instruction that tells each agent to return SKIPPED with a one-line reason and exit cleanly if a repo does not match the migration profile, rather than inventing work to look productive. In this session, roughly 40 of 200+ runs returned honest skips, which saved hours of cleanup compared to agents force-fitting changes into repos that did not need them.

How do you catch a PR that looks successful but has an empty diff?#

Some agents reported "nothing to commit, branch is clean" after failing to detect modified files because they had cd'd into the wrong directory post-clone. The PR opened but contained zero diff, and the dispatch log showed it as a successful run. The only reliable catch was spot-checking PR diffs by hand rather than trusting the run status alone.