Parallel Code Review: Many Agents, One Repository, One Owner

When I ask a single AI agent to review a repository, I usually get a scan. It searches for patterns, follows a few interesting references, and comes back with a list of findings. That's useful. It's also not the review I actually wanted.

The review I want is slower and more boring. Open each file. Look at the names. Look at the method that has quietly grown too long. Delete the comment that restates the code. Ask whether this class even lives in the right folder. And then fix it, not just report it.

A single agent can do that work, one file at a time. It just takes a long time. So I hand it to a swarm instead, and the part that makes it work is what happens after the swarm finishes.

The main agent decides the split, not me

I don't assign files to workers. I give the main agent the review and let it decide how to divide the repository and how many workers to start.

Every worker gets the same role and the same instructions. One might get a single large file; another might get a handful of small ones. Each worker reviews its assigned files against the same clean-code expectations and edits them directly:

• variable and method names that say what they mean
• methods that have grown too long
• comments that add nothing
• files that sit in the wrong place

There is no cast of specialists here. My /review-plan skill fans a plan out to reviewers with different roles; this is a different pattern. One kind of detailed work, repeated across many files, done in parallel.

The parallelism comes from splitting the repository, not from splitting the opinions.

Twenty workers is an example, not a target

Twenty workers is a useful picture of the pattern, but it's an example. If the change touches three files, twenty workers make no sense. Each worker needs enough real work to justify its existence, and every extra worker can add something the coordinator has to reconcile. So right-sizing is part of the main agent's job. I'm asking it to organize the work, not to maximize the headcount.

I think the pattern can apply to pretty much any code review, as long as the sizing stays honest. A large repository offers a lot of file-level work to distribute. A small change might deserve one or two workers, or none.

Agent count is an implementation detail. The objective is a finished review.

Everyone edits the same repository

The workers all edit the same working copy. I don't use worktrees for this, and there are no separate copies merged at the end.

The common alternative is a git worktree per agent, so each one has its own checkout. I don't do that here: every change lands in one shared state.

But I want to be clear about what file assignment does and doesn't buy you. It gives each worker a bounded area of responsibility. It does not make the files independent. A worker renames a method; a caller in someone else's file still uses the old name. A worker moves a class to a better folder; three other files still import it from the old one. Each edit is reasonable on its own. Together, they can break the build.

A file boundary is an assignment, not an isolation guarantee.

That's the price of the approach, and it's exactly why the next role exists.

The coordinator owns the whole repository

When the workers finish, the review is not done. It's at an intermediate state: lots of local improvements, possibly some broken edges between them.

The coordinator's job is to deal with the repository as a whole. It fixes the cross-file fallout: the stale references, the broken imports, the signatures that changed under someone else's feet. Then it builds and runs the tests. Done means a successful build and passing tests, and that's what reaches me.

I like this split because it gives each level a clear owner. A worker can concentrate on its files without pretending to be the authority on the combined change. The coordinator can't hide behind "my files look fine." Someone is explicitly responsible for the repository being in a working state.

Green is evidence, and the verdict is mine

A successful build and a passing test suite tell me the repository still works. They don't tell me every renamed variable is actually clearer, or that the shorter method is easier to read than the long one was. Those are judgment calls, and that's why the last step is still mine.

I review the final result. If the swarm produced a hundred edits quickly but the combined change were impossible to assess, I'd have gained nothing. The coordinator's real deliverable is a result I can actually review and decide whether to keep.

The speed claim needs a fair baseline

My honest impression is that this is dramatically faster. For a large repository, I'd estimate it's close to twenty times faster than a single agent doing the same file-by-file work. That's an estimate from using it. I haven't timed it.

The comparison matters, too. Comparing a swarm doing a detailed review with one agent doing a quick scan is meaningless; they're answering different questions. The only fair baseline is a single agent doing the same detailed work.

And the total time isn't just the parallel part. It includes delegation, the coordinator's repairs, the build, the tests, and my review. Some of that overhead likely grows with the number of changes. Doubling the workers doesn't halve the total. To be fair to the single agent, it also has to build and test its changes. What I care about is the time to a reviewable, green result, with all of that included.

Cost is still an open question

Cost could become a problem as this scales. So far it hasn't been one for me, and I don't want to pretend I've worked out the economics.

The obvious lever is running the workers on a smaller, cheaper model. That's a possible fallback, not something I've tested. A cheaper worker only helps if it doesn't push extra repair work onto the coordinator or extra judgment onto me. I'd want to evaluate that on a finished result, not a price list.

What I actually take from this

What I value here is the division of responsibility:

• The main agent sizes the swarm and assigns the files.
• Workers scrutinize and edit their files.
• The coordinator repairs the combined result and gets the build and tests green.
• I make the final call.

Parallelism gets one specific job: shrink the time spent on bounded, repeatable file-level work. Integration gets an explicit owner. And the outcome gets judged only after the repository has been put back together.

Where a rule can be checked deterministically, I prefer that, and deterministic architecture review is what I plan to write about next. For this kind of review, the rule is simpler: parallelize what can be bounded, account for the cost of putting it back together, and judge the repository as a whole.