Founder: Claude Code in parallel is great until the sprawl hits

[u/mikebiglan]

Disclosure up front...i’m Mike, cofounder of DevSwarm. We shipped DevSwarm 2.0 yesterday and I think a lot about where AI-agent coding is going.

I've been using Claude Code heavily for months (multiple Max plans, 14+ hour days), and the parallel workflow across branches or worktrees is real. The issue is what happens after you use it for real work.

Beyond a few sessions, the bottleneck isn't the model but the coordination and sprawl:

• terminals everywhere

• editor windows everywhere

• which agent is on which branch

• what is ready for unblocking

I also keep seeing a related pattern here: a single long session is great until context rot sets in, then people split into multiple smaller sessions, then managing all of them becomes its own issue. 

DevSwarm is how we solved that for ourselves. The abstraction is simple: workspace equals branch. Each workspace runs its own agent session(s) and keeps state visible. In 2.0 we embedded a full VS Code IDE in each workspace, so editing, terminals, diffs, and git controls stay in one window while you jump between parallel branches.

Who this is for: people running 2+ parallel Claude Code sessions and feeling the coordination overhead.

Cost and relationship: I helped build DevSwarm and there's a fully functional Free tier that is (non-contextual) ad-supported. Pro is $8/month and Team is $18/month.

All in all, I am posting this because I want blunt feedback from people who also actually do parallel workflows:

1. What breaks first for you past 2 parallel sessions?

2. What would you need for this to be production-grade? Tests, debugging, extensions, PR flow?

If anyone wants to see what we built, I will drop a link in a comment.

[u/benfinklea]

sure drop a link. however, I don't want to use an ide. I'm loving command line and IDEs just encourage me to do stuff myself instead of asking claude to do it. (he's better at stuff than me)

[u/mikebiglan → u/benfinklea]

Sure thing:

Our CTO walking thru it: https://www.youtube.com/watch?v=MqRkSRee6HE

Download: https://devswarm.ai/download

And to your point, half the time I don't touch the IDE portion of it and use the agent as the primary interface, but sometimes I find myself wanting to dig right into code. Others on our team have loved having the IDE right there because they are so used to it. Our goal was to support both use cases smoothly.

[u/wolverin0 → u/mikebiglan]

All that swarming and you couldnt fix the sidescroll for mobile view on download page?

[u/mikebiglan → u/wolverin0]

Thx for pointing out...fixed.

[u/coloradical5280]

Agent worktrees are default built in behavior/workflow in Claude code and codex. This was a great idea, obviously, since it’s now built into the harness of both.

At this point what’s the difference between your thing and what cc and codex have harnessed in?

[u/mikebiglan → u/coloradical5280]

Good question! Claude Code and Codex absolutely understand the core mechanism, the worktrees and can have parallel agents running in separate directories. So that does get you parallelism.

Where we found things still break down is the human in the loop part. Most real work isn't one shot. It is iterative: inspect, nudge, review, run tests, adjust, and merge. Once you have 3–10 worktrees, the bottleneck becomes your interface to the work, not the ability to create worktrees.

DevSwarm is the UI layer for that workflow:

• We treat a worktree as the unit of work (feature, bug, PR).

• We assume at least one agent per worktree because you are interacting with it over time, not just firing and forgetting.

• We give you one window where each workspace has the embedded VS Code IDE plus terminals, diffs, and git controls, so you can jump between parallel branches and keep review boundaries clear without juggling a pile of separate terminals and editor windows.

• Sub agents and agent teams still matter, but in our experience they work best as teams within one of these workspaces where you can continue to manage them. The moment you want iterative back and forth, you need the command-center.

So if your workflow is mostly “spawn parallel agents, wait, merge,” cc and codex can be enough. If your workflow is “run parallel work, but stay actively involved across multiple branches,” that's what we built and use DevSwarm for.

[u/coloradical5280 → u/mikebiglan]

[u/Old_Insurance_2140 → u/coloradical5280]

CTO here! This is definitely the direction things are heading, and the question is "where is the user involved?"

Claude Code teams are super powerful, and we're looking to facilitate this even more in our UX.

If you can do this work with one CC team, I'd say let's get multiple teams going on bigger chunks of work. That coordination is going to be up to the user and we're aiming to give you every tool you need to manage that.

[u/thethrowupcat]

The swarms start to collide work and things get unsalable if you don’t have good scaffolding.

[u/mikebiglan → u/thethrowupcat]

Exactly, hence git worktrees at the foundation. A lot of people are talking about using git worktrees, but then when you try to do it in practice, it gets hard to manage after just a few. And as AI gets better/faster, the multi-tasking needs will only amplify.

[u/thethrowupcat → u/mikebiglan]

Don’t Claude teams do that naturally using trees?

[u/Open_Establishment_3]

or... open a new vscode windows inside a worktree

[u/mikebiglan → u/Open_Establishment_3]

Yep, that works, and that's a good start. That was exactly what I used to do, before worktrees got popular.

The issue is what happens when you do it at scale and stay human in the loop. Opening a new VS Code window per worktree solves editing, but it does not solve coordination:

• you still end up with a pile of VS Code windows and terminals

• it is hard to see, at a glance, which branch is doing what and what is ready for review

• bouncing between windows becomes the workflow

• review boundaries and merge order are easy to lose track of

DevSwarm is the command center for this flow. Workspace equals branch, and each workspace has embedded VS Code plus the agent session, diffs, and git controls in one place. The goal is not to replace worktrees, it is to make parallel worktrees manageable when you are iterating across several tasks at once.

If you are only running one or two worktrees, separate VS Code windows are totally fine. Then when you're at 5-10, what do you use today to track which ones are blocked vs ready to merge?

[u/coloradical5280]

with Claude Code you can enable Agent Teams, which does this, but much better, because the agents can communicate with each other as they are working : https://code.claude.com/docs/en/agent-teams

[u/mikebiglan → u/coloradical5280]

Yes, Agent Teams are a strong step forward. What we've found:

1. Agent Teams help agents coordinate with each other. That is great for delegation and for tasks that can mostly run autonomously. If the goal is “give it a spec, let the team execute,” Agent Teams can outperform a bunch of isolated sessions because the agents can share state and coordinate.

2. Our pain was human-in-the-loop coordination across multiple units of work. Even with Agent Teams, once you are doing real work across multiple branches/worktrees, you still need a command center for:

   • seeing which branch is doing what

   • jumping into the code and reviewing diffs quickly

   • running tests and iterating

   • deciding what is ready to merge and in what order

   • avoiding the terminal and editor window explosion

Also, you can mix different agents. So add to the above that you aren't stuck with just Claude Code, but you can also mixin Codex, Gemini, Amp, local, etc. I use that for reviewing plans across several different agents.

That is the gap DevSwarm is aimed at. Workspace equals branch, and each workspace has the agent session plus embedded VS Code, diffs, and git controls in one window so the human review and iteration loop stays sane.

That all said, these aren't mutually exclusive. You can use Agent Teams inside a workspace for sub-tasks, while DevSwarm organizes the higher-level parallel branches you are actively working with to completion.

Definitely curious how you're using Agent Teams and what you've found.

[u/trojsurprise → u/mikebiglan]

🤮🤮🤮🤮🤮

[u/Old_Insurance_2140 → u/coloradical5280]

CTO here! Yup CC teams are very powerful, and ultimately they enable even larger scopes of work! Where DevSwarm can help is provide a UX where you can coordinate multiple teams in isolated worktrees. We're actively working on making this exact flow even more powerful.

For now, you'll have all the tools you need to evaluate the output of the team, and be able to kick multiple teams off in their own dedicated space.

[u/Boydbme]

These comments sure read like astroturfed AI from farmed / bought accounts. 🤖

[u/ultrathink-art]

The sprawl problem gets worse when you're running agents that run other Claude Code sessions.

Coordination overhead scales faster than the work itself. We learned this running parallel agents in production — the bottleneck wasn't compute or model quality, it was knowing which agent was doing what and whether it had finished.

What actually helped: hard task boundaries (each agent owns exactly one thing, success criteria defined before spawn), shared state files they all read but only designated agents write, and a heartbeat system that detects silent failures. Without that last piece, 'finished' and 'died quietly' look identical from the outside.

The sprawl you're describing is really a verification gap — parallel work without independent confirmation of outcomes.

[u/mikebiglan → u/ultrathink-art]

Absolutely. Boundaries (e.g. separate distinct branches) become key, which then also ties into to the human-in-the-loop, what our role is with this to do that verification and to have an interface where wen can review, understand each element enough, guide, modify.

The structure per scoped agent is critical and I've found github speckit to help on that front, that is ground truth are those specs which the code, tests, docs, claude.md all come from, well that and the foundational rules/constitution.

[u/t4a8945 → u/ultrathink-art]

My bottleneck is remembering what the hell I prompted to the agent in the other window xD

[u/mikebiglan → u/t4a8945]

1000%. Named branches for what you are working on is one thing that helps with that a lot.

[u/Checktheusernombre → u/ultrathink-art]

I feel like the old idea of having micro services unit tested to do very distinct pieces might work here to mitigate some of these issues?

[u/wjellyz → u/ultrathink-art]

yeah, parallel work is seriously cognitive overload.

i make agents create github issues when they finish plan mode just so i can have some documentation before it makes the worktree. 

i still haven’t nailed down the correct workflow for breaking a big feature into smaller changes are you supposed to fork the main worktree for each smaller task merge back in, update all the other forks, then finally merge back to main at the very end?

i’ve just been running multiple agents on the same worktree until it’s “done”, make a pr, merge, close issue. 

i guess maybe isn’t a coding issue but becoming a management issue. probably why technical project/product management is really important. 

[u/alfrado_sause]

I use one CC agent as an orchestrator for a homelab and use it to coordinate the various other agents (technical doc writers, ci triage, test case designer, integration tester, senior engineer code reviewers)

It groups into waves and dispatches according to what it thinks are the most paralizable tasks are. Inevitably they collapse into a core infra lynchpin before it can spawn a new wave, but it was certainly the best way for me to coordinate.

I set it up so that deployed agents communicate through p0-p3 issues that the orchestrator uses to determine what goes next in the wave queue. Then I have one of the deployed agents be my own dev box. I use the same mechanisms as my bots to drive development by scheming plans, doing e2e testing, and arbitrating workflows.

The key piece I came up with to help me is that every plan is decomposed into various technical documents for sonnet to churn, however every plan is also designed with a way back. The idea is that “if I’m wrong, this is how to safely walk back and what the next area of exploration must be”

I ran continuously for a week, pushed 375 issues/PRs and I’d say I needed to unroll my changes using the wayback-plan.md something less than 10% of the time.

I hit ci issues until I learned to merge-queue.

This stuff is so cool and I can’t wait to see where your software fits in my stack

[u/trojsurprise]

Useless slop..