Now I can't imagine how are people using like 20 parallel Claude instances, I can't think of 2 on the same project. What am I missing? Do I need to take a step back and relearn how I think about projects. Did you have to change the way you think to parallelize the development.
It would be great if you can share some use cases from your workflow and how you are organizing your thoughts to leverage the available parallelization at hand.
Thanks!
I tend to go for parallel agents when the task I have can easily be split into non overlapping chunks, preferably if one chunk doesn't depend on another. Let's say I'm working on a new feature which will require changes to both frontend and backend. I can first define a shared contract between them (how the API endpoint will look, what inputs it will receive, what it will output) and then spin up one agent to work on each separate part.
Or maybe you're refactoring a part of the system that has hard coupling with other components (think maybe a notification system). You could spin multiple agents for each to handle a different coupling point.
In general I think that the same good software engineering practices that help with teams can help with parallel agents. It's important to remember though, with each agent you have more code to review (using shared interfaces could help your review process) and if you don't do a good enough division you'll get a fair share of merge conflicts to fix later. Also it's important to have each agent on it's own git work tree to avoid concurrent edits to the same file
One last workflow I have for parallel agents is getting up to speed on a codebase. I can divide the codebase into discrete groups and ask each agent to read it and report the findings. This one is an easier workflow since it doesn't really matter if the agents overlap on a few files since they aren't editing it.
For me it's been mostly trial and error trying to get to a good balance between multiple agents and the overhead it brings
Just launching multiple AI instances does not scale because you loose the overview an context of each task. Also you need git worktrees to isolate the agent from each others work.
My solution was a tool around VSCode, handling worktree creation and notifications for idle agents. A MCP which can interact with VSCode allows the agent to prepare any outcomes for preview or show a notification what to test or to do next. That way I cycle through agents answer the questions it has or review its work. I regularly work with ~5 parallel task (sometimes up to 10).