[4/4] Code with LLMs in parallel

I have the strong feeling that this is one of the core skills to develop in the next couple of years as an engineer. The tooling is not great yet, but by the time you read this, it might be, so take this more as a primer and look under the hood of how future tools will and current tools already work to run agents in parallel.

I tried four methods of running agents in parallel, and I will explain why I currently prefer custom scripts or manual management over existing GUI/TUI tools.

If you haven't delved into planning and swarms extensively, you may not have encountered the scenario where you need parallel workers. But once your agents start to take on bigger tasks, you might start thinking about it. I encourage you to go back and especially look into the PLAN.md -> Implement -> Iterate technique:

[1/4] Code with LLMs and a PLAN

I’m fortunate enough to work every day with the state-of-the-art coding agents, most recently Claude Code, and I’ve also explored various resources from developers who push the boundaries and produce significant work with top-tier agents. We all need to level up together in this wild west of AI coding and

RichStone Input OutputRich Steinmetz

[3/4] Code with LLM teams

Your LLM agent will launch subagents to perform the tasks you give it in teams. Remember in [1/4] Code with LLMs and a PLAN I talked about how I tweaked an effectively working prompt to skip the step of asking the LLM to first add what it will do

RichStone Input OutputRich Steinmetz

Once you have agents perform tasks that are longer than 10 minutes, you might be eligible to start accustoming your brain to the future of building.

So how does this work in its rawest form?

By now you might have heard of the git worktree command. It allows you to have multiple branches of the same repo checked out simultaneously. Here's how you would do it manually:

# from your project root
project> git worktree add ../project-parallel-1
project> cd ../project-parallel-1
project-parallel-1> claude "destroy computer" --dangerously-skip-permissions

Once in the new directory, you can start your LLM agent and give it some more long running tasks that won't conflict with what's ever going on in the main branch.

You will see project-parallel-1 as a new branch in your git viewer:

> git branch
  another-branch
+ project-parallel-1
+ project-parallel-2
+ project-parallel-3
  master
  more-branches

All the branches marked with a + are separate worktree branches. You can remove them by running git worktree remove project-parallel-1.

That's it. There are several gotchas here.

Depending on your local setup's complexity (think half-local half-Docker/Kubernetes setups) it's not a given that all your tests (unit, integration, system) will run on that worktree without extra commands or that you will be able to spin up a second instance of your app to do manual testing. So depending on what's going on in your main tree you might need to, again, wait until you can merge your changes in to test them. This makes quick iteration difficult.

Managing worktrees manually is cognitively taxing, so it needs to be really worth the effort and you kinda have to know that the agents will be busy for a while. I'm still not at that point, most of the tasks I give it are 10-30 minutes, including running slow tests as the verification mechanism.

I've usually used parallel agents to start new adjacent tasks or small bug fixes from a different topic or create a PLAN.md for the next task. I don't see value yet in tackling multiple projects alongside each other, for the same reason: it's too costly to context switch between two big tasks with the agents performing "small" 10-30 minute tasks.

I've never tried launching Claude Code for the same PLAN.md with multiple agents for tasks where you might be interested in different results (UI, code architecture approaches), but I find this very inspiring: The Future Of Building With Code. I think this is just a tooling problem and we are probably already close to having it solved.

So to solve the tooling problem and free up some mental space, there are some tools out there already. Here's why they don't work for me yet.

GUI Tool: Conductor

It's great to have a GUI for this whole thing. Conductor has some configuration options, but I might not have had enough patience with it and it might be dimensions better since I last used it, but looking at it now, it still won't work for me because I can't --dangerously-skip-permissions with it.

You can create a worktree with a button click which is way cooler than the CLI worktree hassle:

And you'll find yourself in a Claude chat wrapper and a diff viewer.

By default it puts your worktree into the same repo so files duplicate when you search for them in your main tree. I think this is configurable and you should take care of that first.

What's really bad is that it always branches you out from your main/master branch and I might have missed the config to branch from current branch, but that was not funny.

If on each worktree creation you need to run bundle, you can configure this in Conductor which is a nice feat.

The diff viewer isn't useful for me and I don't feel comfortable with the Claude Code wrapper. Looks like it's a wrapper around the API, so commands like /mcp are not available. I need the full Claude Code power house so it's a clear "no no no".

TUI tool: Claude Squad

I think Claude Squad is a bit buggy, see the error at the bottom. :D

What it does better is branching out from your current branch and putting the worktrees somewhere outside your repo plus having a stable naming convention for your branches (Conductor has some weird magic there, so it automatically renames them which messes up the git banch view for me - I end up with some branch soup).

Another nice thing here is that creating new worktrees is fairly intuitive and you stay in the original Claude Code TUI after you've switched to a new tree.

It's almost the ready-to-go solution, except you can't --dangerously-skip-permissions.

I also haven't found much to configure inside, so there's also no option to "always do xyz when creating a new worktree".

So, a no-go as well.

Custom Scripts

This video might have the solution to all of it:

But vibing seemed easier than looking for that repo and trying to adapt it to my setup, so I began to work on a Ruby script that fits my needs:

parallel-agents

GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

It still needs some love and isn't very sophisticated, but a good start for managing a couple of trees. I've tried to solve the issues I had with the other tools and run on the dangerous permissions. The script tells the story of how I would imagine for it to work in its simplest form, not even launching multiple agents in multiple trees at the same time.

In a nutshell, managing worktrees yourself is challenging and the tools aren't there yet, but I'm sure we are close and this will be one of the driving fun factors in the coming months.

Robots, Before They Were Robots

Before Hollywood, before Boston Dynamics, robots were about labor, not lasers.

Signals from Our Futures PastMike Amundsen