Okay, I want to talk about the thing everyone is quietly doing and nobody is being honest about.
There's a whole genre of post going around right now where somebody fires up 20, 50, 371 git worktrees, drops an agent into each one, and declares that the future has officially arrived. And look, I believe them, mostly. I run six agents in parallel on a real production codebase every single day, and honestly it is the biggest change to how I actually work since I gave up arguing about tabs versus spaces. So I'm not here to be the skeptic in the back of the room.
But here's my problem with those posts. Every one of them reads like a trip report written on day one, all wide-eyed and triumphant, and NOBODY ever seems to write the month-four post. So this is the month-four post. This is what actually breaks, in roughly the order it broke for me.
First you try one checkout, and your index starts exploding
Like everybody else, I started the dumb way: three terminals, one repo, a different task in each. And I'll be honest with you, that works beautifully for about ninety minutes.
The first thing to break is boring and mechanical, so let's get it out of the way. Git's index is a single shared mutable file. Two agents run git add at the same moment and one of them just loses. One agent is halfway through a rebase while another one commits, and you land in a state so tangled it took me twenty full minutes of reflog archaeology just to describe what had happened, let alone fix it. Nothing was actually lost. My afternoon, though? Gone.
The second failure is quieter, and it is genuinely so much worse. Agents working on "separate" features are not actually separate, and this is the part people miss. Your route table, your DI registrations, your settings schema, your barrel exports: every codebase alive has four or five files where absolutely everything comes to meet. Both agents WILL touch them. And you will not notice a thing until one agent's build passes cleanly on top of the other agent's half-written change, and now you're staring at a green checkmark sitting on top of code that has never once existed as a coherent whole on any machine anywhere.
Fifteen years ago I watched two actual humans do the exact same thing to a Perforce depot, so I genuinely can't even sit here and blame the robots for this one. The only real difference is throughput. Humans collide maybe once a week. Agents collide once an hour.
Worktrees fix the right problem (and then bite you in new ones)
git worktree add hands every agent its own working directory against the same shared object store. Separate index, separate HEAD, separate build artifacts, one shared history underneath. It is the correct primitive, full stop, and it costs you almost nothing to adopt. If you take exactly ONE thing away from this whole post, take this: stop handing parallel agents a shared checkout.
Now, the sharp edges. And there are several, and I promise you I have bled on every single one.
The dependencies are the hidden tax. A fresh worktree ships with no node_modules, and a full install on our monorepo runs about eleven minutes, which pretty much murders the entire point of cheap, disposable, parallel checkouts. So naturally you get clever. You symlink or junction the root node_modules into each worktree, and it works, and on Windows it also arms a footgun that most people have genuinely never heard of. A recursive delete on Windows will happily follow an NTFS junction. So an agent "tidying up" its own worktree with a naive rmdir /S followed that junction chain right back into the canonical checkout and deleted roughly 1,500 source files. Twice. The second time was the same WEEK. Everything came back clean with git restore (deletions of tracked files are just unstaged changes, thank god), but I now run a hook that flat-out refuses a recursive delete anywhere near a worktree path, and I'd gently suggest you get equally paranoid.
Some of your tooling quietly assumes one checkout. Anything that hardcodes a path, binds a fixed port, or drops a lockfile in a shared location is going to start fighting itself the moment six copies run at once. Our dev server, two separate codegen steps, and a certain very popular ORM's migration tool all needed a stern talking-to. Budget a day for this. It's dull, unglamorous work, but the good news is you only ever do it once.
Native modules will resent you. If two worktrees on different Node versions are sharing a dependency tree, the rebuild churn alone will eat more time than the agents ever save you. Pin your toolchain versions across the worktrees, or keep the trees fully separate. Pick one.
The actual skill was never spawning, it's scoping
Here's the thing the "look at my glorious fleet" posts get completely wrong. Spawning the agents is trivial now. It's a solved problem. Every single incident I've had in months traces back to the exact same root cause: two agents whose tasks were not actually disjoint in the first place.
The one that finally beat the lesson into me: I had one agent fixing a race condition in our session-restore path, and a second agent adding telemetry around that same path, each in its own clean worktree, like a responsible adult. Both diffs were spotless. Both merged. But the telemetry agent had, very reasonably, restructured the exact function that the race fix was surgically threaded through. Individually correct. Jointly wrong. And the recombined version compiled without a peep and then deadlocked in QA.
So now I do something that honestly feels almost embarrassingly old-fashioned. Before I fan anything out, I write the contract down. Which files each task owns. Which interfaces are frozen for the duration. What "done" actually means for each separate lane. Five minutes of typing, tops. And it is the very same discipline as carving up work across a team of juniors, which is not remotely a coincidence, because functionally that is EXACTLY what this is. The agents are fast, tireless, eager juniors with a bad case of anterograde amnesia, and the old tech-lead job of slicing work into clean non-overlapping chunks has quietly become the single highest-leverage thing I do all day.
And when two tasks genuinely cannot be separated? Then I don't parallelize them. Sequential is not a failure state, and I really want that to land. A tightly coupled refactor over one shared schema is ONE task, and pretending otherwise doesn't make it faster, it just relocates the merge conflict out of git and into production.
The merge queue is the real ceiling, and the queue is you
Six agents will produce mergeable branches faster than I can responsibly review and land them. I know that sentence reads like a humblebrag. It is actually the central, defining problem of this entire way of working.
Every branch needs a review (and reviewing agent code is its own whole essay, for another day), but even purely mechanically: each merge shifts the base that the next branch was built against. Land them in the wrong order and branch four's assumptions are already stale by the time it comes up. So I merge sequentially, I re-verify after every single landing, and I hold one hard rule with no exceptions: nothing merges until its tests have run against the CURRENT tip, not the tip it originally branched from. My real throughput was never six agents. It's one merge queue, fed by six agents, and I am the queue.
That one reframe genuinely changed how I spend my attention. I stopped watching the agents type (mesmerizing, completely useless) and started treating my actual job as the two ends of the pipe: careful scoping on the way in, ruthless verification on the way out. The middle, honestly, mostly takes care of itself.
So what should the tooling actually own?
After months of running all of this by hand, with tmux and a pile of shell aliases and a text file I'd literally named WHO_IS_DOING_WHAT.md, I've landed on some pretty strong opinions about which parts of this deserve real tooling and which parts don't.
The worktree lifecycle, for one, because "create it, junction it, guard it, then safely destroy it" is precisely the kind of fiddly, mechanical, easy-to-fumble sequence that humans get wrong at 5pm on a Friday. The guardrails, for another, because "please do not recursively delete across a junction" should be enforced down at the level of a blocked syscall, not left as a hopeful comment buried in some runbook nobody reads. And visibility, most of all, because the genuinely scarce resource here is simply knowing which of your six terminals needs a human RIGHT NOW, and alt-tabbing through all of them one at a time to find out is, frankly, a supervision UI straight out of 1987.
Full disclosure, because you deserve it: I got opinionated enough about all three of those that I stopped hand-rolling them and built the tool I wished I'd had, and this very blog is bolted onto it, so please calibrate for my bias accordingly. It's called Agent Cohort, and honestly every feature in it is just one of the scars above turned into something the machine now handles so I don't have to remember to. It docks all six agent terminals into a single grid, so the one that actually needs a human lights up instead of hiding three alt-tabs deep. It owns the whole worktree lifecycle end to end, create it, junction the dependencies, then tear it down safely, which is the precise 5pm-on-a-Friday sequence I kept fumbling by hand. And that junction-delete disaster that ate 1,500 files twice in a single week? The dock drops a guard into every project the moment you open it, no config and no runbook to forget, that refuses the delete right down at the syscall before it can ever reach your source tree. The part I'm quietly proudest of is how little it asked of me to get there: it wrapped the exact by-hand workflow I was already running, it didn't make me go learn a brand new one.
And I'll stay honest right to the end, same as I've tried to be the whole way through: none of this is magic you can only rent from me. Worktrees, written contracts, one honest merge queue, and hard mechanical enforcement of the handful of things that must simply never happen will get you there with tmux and enough discipline, and that genuinely is the entire trick. I just got tired of rebuilding it by hand in every repo and losing the occasional Friday to the one guardrail I'd forgotten to set up. So if the month four I've just walked you through sounds a lot like where you're currently headed, that's precisely who I built it for. The download is free, it runs on Windows, macOS, and Linux, and it's the shortcut I wish somebody had handed me back in month one: agentcohort.ai/download.
The agents are the easy part now. Everything wrapped around them, all of it, is where the real engineering quietly went.