I've been putting off writing this one for weeks because every time I sit down to explain my setup it sounds more complicated than it actually is once you're living inside it. But enough people have asked "wait, how do you run three coding agents at once without them destroying each other's work" that I figure it's worth just typing it out.
The short version: git worktrees. The slightly longer version is everything below.
The problem I kept running into
If you've been using an AI coding agent for any real chunk of your day, you've probably hit this. You've got an agent chewing through a gnarly refactor in one terminal tab, and you want to quickly spin up a second agent to fix an unrelated bug someone just filed. Easy enough, you think — just open another terminal, cd into the same repo, and go.
Except now both agents are looking at the same working tree. One of them stashes something, or half-finishes an edit, and the other one reads a file mid-change and gets confused, and suddenly you're debugging a mess that has nothing to do with either actual task. I lost probably two hours to this exact scenario back in May, chasing a "bug" that was really just two processes fighting over the same files. Not fun. Also entirely avoidable, which is the annoying part.
Worktrees fix this cleanly
git worktree has been sitting in git since basically forever, but I never had a real reason to use it until agents started running in parallel on my machine. The idea is simple: instead of one working directory tied to your repo, you can check out multiple branches into multiple directories, all sharing the same .git history underneath.
So instead of this:
cd ~/projects/techpad-app
I do something like:
git worktree add ../techpad-refactor refactor-comments
git worktree add ../techpad-hotfix fix-rss-bug
Now I've got two completely separate directories, techpad-refactor and techpad-hotfix, each checked out to its own branch, each with its own untracked files and half-finished edits, and neither one has any idea the other exists. I point one agent at each directory and just let them run. No stashing, no stepping on each other, no mystery bugs from shared state. When a task's done I merge the branch back and delete the worktree with git worktree remove.
It sounds almost too simple to be worth a blog post, and honestly maybe it is, but I went years not knowing this was the intended fix for exactly this problem, so I'm assuming I'm not the only one.
A couple of things that tripped me up
Worktrees don't like sharing a branch. If branch main is already checked out in one worktree, you can't check it out again in a second one — git will just refuse. Which makes sense once you think about it (two directories can't both claim to be the canonical state of the same branch) but it caught me off guard the first time and I spent a good ten minutes convinced I'd broken something.
Also, your node_modules (or venv, or whatever) doesn't come along for the ride. Each worktree is its own directory on disk, so if you need dependencies installed, you're installing them fresh in each one. I keep a small script that just runs the install command whenever I spin up a new worktree, mostly because I forgot to do it manually about four times in a row before I got annoyed enough to automate it.
One more small gripe while I'm here: some GUI git clients still handle worktrees badly, or don't show them at all, which means I end up doing worktree management from the terminal even on days when I'd rather click around. Not a huge deal, just mildly irritating given how long worktrees have technically existed.
Where I've landed
These days my directory structure looks less like one repo and more like a little cluster of them, each one doing its own thing, each one disposable once the branch merges. It's a small change to how I organize my filesystem, but it's removed an entire category of dumb, self-inflicted bugs from my week. If you're running more than one agent (or honestly even just juggling a hotfix and a feature branch as a human), it's worth the twenty minutes it takes to get comfortable with the commands.
I'll probably write a follow-up at some point about the script I use to spin these up and tear them down automatically, once I've cleaned it up enough that I'm not embarrassed to paste it here.