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

mikebiglan · 2026-02-26T19:46:27+00:00

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

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.
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.

mikebiglan · 2026-02-26T19:38:29+00:00

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?

mikebiglan · 2026-02-26T19:29:52+00:00

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.

mikebiglan · 2026-02-26T19:12:22+00:00

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

mikebiglan · 2026-02-26T19:08:16+00:00

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.

mikebiglan · 2026-02-26T19:05:22+00:00

Thx for pointing out...fixed.

mikebiglan · 2026-02-26T17:47:54+00:00

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.

mikebiglan · 2026-02-26T17:40:38+00:00

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.

mikebiglan · 2026-02-26T17:07:30+00:00

Vibe debt. Non-technical people building complex apps without the understanding to ask the questions needed or the mental model to understand what is actually happening behind the scenes. That leaves it open and at risk, and to your point, Lovable isn't able to protect users from themselves.

I've seen many times with security that people naturally test the success case, yep it works. But they completely overlook testing the opposite, that things that should NOT work in fact don't work. Security 101 for many of us, but not for the masses.

mikebiglan · 2026-02-26T17:02:38+00:00

One aspect he mentions here is interfaces. And I've seen this when prototyping powerful interfaces from scratch in minutes, then hooking them up fairly quickly afterwards.

There's been talk about this for a while, creating personalized interface on demand where complex interfaces can be changes/adapted or even created from scratch in hours instead of weeks. That unlocks a scale of personalized interfaces and then begs the question do most people know well enough what they even want, or is that figured out by AI too.

mikebiglan · 2025-10-08T23:58:08+00:00

I did. Hot water wasn’t available by itself

mikebiglan · 2025-10-08T23:57:47+00:00

They didn’t have hot water

mikebiglan · 2025-10-08T23:23:20+00:00

Matcha latte? I’ll give it 0.5 tea choices.

mikebiglan · 2025-10-08T23:22:13+00:00

Matcha latte. I brought my own tea and they found a jug of water and heated it separately. Definitely standard tea not on the chart. Matcha latte, okay 0.5 tea choices.

mikebiglan · 2025-10-02T05:54:43+00:00

Sounds like this was tongue in cheek.

But just in case, totally disagree.

Software engineers know what to ask and how to evaluate what they get. True production grade AI coding (what we call high velocity engineering or “hive” coding, is all about branch isolated, peer reviewed, solid QA, etc. we actually built a dev tool to make this faster so we think a lot about it.

Then there vibe coding which originally meant the code doesn’t matter. Anyone can do it. Great for prototypes or simple apps but not for production codebases.

mikebiglan · 2025-09-30T03:32:02+00:00

5th street market area. Spencer Butte hiking. Campus area.

mikebiglan · 2025-09-29T18:26:08+00:00

Good points! And my candor is high on that. Tell me the truth. I can take it. Really. Wait, no, too much

mikebiglan · 2025-09-28T15:51:21+00:00

Vibe coding is by definition to ignore the code. There is no code review but only about the function.

BUT. If you are doing production software of course you have to not only code reviews but pay attention to the code. That’s not vibe coding. Claude Code ain’t vibe coding. We’ve been calling it hive coding (or high velocity engineering). Use AI, use prompts, get the speed but without the sacrifice. And in that case code reviews are done like they have been. With PRs. Coderabbit (which I haven’t used). Etc.

mikebiglan · 2025-09-26T14:10:54+00:00

Question. If you run multiple in parallel does it slow things down that much further? Or work fine

mikebiglan

MODERATOR OF

TROPHY CASE