Running 4 coding assistants at once is fun until your brain melts at the PR review stage
by•
I tried spinning up multiple AI coding tabs last weekend to knock out a bunch of bug fixes in one go thinking it would make me four times as productive. Instead I spent two hours staring at different git diffs completely losing track of what logic belonged where.
The agents spat out code way faster than I could read, let alone test or understand. Code generation speed doesn't mean much if your own review bottleneck slows everything down to a crawl.
How many parallel tasks do you actually let your tools run before you start missing bugs?
17 views
Replies
Two at most, and that cap started for a dull reason: more than two burns through my plan's usage limits fast. It turned out to be about the number of diffs I can actually read in one sitting too. Past that I'd be approving code I never looked at.
@wwenioaguiar Two sounds like a good balance. I think the real challenge is not how much code the agents can produce, but how much we can properly review without missing something important. It's easy to get carried away when everything moves so fast.
losing track of what belonged where bit us in git too.. a plain commit from one session picked up files another session had staged. now each one stages only its own files by exact path, and gets its own worktree. were yours all on one checkout?
@neelagiri_chettiyar Yes, they were all running on the same checkout, which probably made things even more confusing. Giving each session its own worktree sounds like a much cleaner approach. I''ll definitely keep that in mind for my next run.
I've found that separate worktrees solve only part of the problem. There are a few less obvious ways parallel sessions can interfere with each other:
A Playwright run with reuseExistingServer silently picks up a dev server another session started on the same port, so one agent ends up testing another agent's code. Giving each checkout its own port and checking which process owns it helps.
Benchmarks: If all sessions share the same machine, performance measurements become unreliable. I once saw a benchmark run 4–5x slower simply because three other sessions were building in parallel.