Ask HN: How to think in terms of parallel Claude agents
7 comments
I like to think in parallel Claude instances the same as software threads. Sometimes adding more threads will make the program faster, but sometimes the overhead of managing them will not be worth it.
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
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
Thanks for sharing a realistic workflow in detail, I think that would be very useful, specially thinking in terms of "same good software engineering practices" and maybe even going a step further to decouple things when designing future projects.
Thinking about it again, when i tried to use parallel agents last time, I ended up having a lot of overhead in merging and testing the features. Maybe part of it is to either allocate small tasks to each agent, when complete isolation of codebase is not expected, to make the changes easy to test.
I definitely feel a bit more encouraged to try out a bit more parallalization in my work by being more mindful of the surface area of the feature.
Thinking about it again, when i tried to use parallel agents last time, I ended up having a lot of overhead in merging and testing the features. Maybe part of it is to either allocate small tasks to each agent, when complete isolation of codebase is not expected, to make the changes easy to test.
I definitely feel a bit more encouraged to try out a bit more parallalization in my work by being more mindful of the surface area of the feature.
I had primarily the issue, that when working only on one task at a time, I had nothing to do, when my AI was thinking or implementing a plan.
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).
https://github.com/stefanhoelzl/codehydra
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).
https://github.com/stefanhoelzl/codehydra
Wow this looks very promising. Clean and simple enough to try today instead of saving it for later in a bookmark.
Honestly, I came across some tmux based tools earlier like agent-deck, their text-clutter and workflow learning curve repelled me because of the very small context window of my brain.
Thanks for sharing!
Honestly, I came across some tmux based tools earlier like agent-deck, their text-clutter and workflow learning curve repelled me because of the very small context window of my brain.
Thanks for sharing!
Thanks for giving it a try!
If you have any questions or problems just open a issue on github!
If you have any questions or problems just open a issue on github!
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!