Git worktrees are now load-bearing in how I ship code every single day, and I want to write down how I got here, because I bounced off them twice first. The reason they eventually clicked had almost nothing to do with worktrees.
Multiple clones and one tired human
Before goldengoose, my coding-agent life was one thread at a time: Claude Code or Codex in a terminal, serially. The itch for parallelism showed up almost immediately. I’d have three unrelated changes in my head and one agent plodding through the first, so I did the crude thing: multiple full checkouts of the same repo, side by side, with a different agent working in each.
This was terrible in every way it sounds terrible. Full clones drift. Dependencies install three times and disagree. Terminal windows stop being distinguishable. I was the process manager, the router, and the merge strategy, and all three of those jobs were competing for the same attention I was supposedly freeing up.
Worktrees were the obvious recommended fix; everyone running agents in parallel was converging on them at the time, and of course I tried. Twice, they didn’t stick. First for a mundane reason: the manual plumbing. Adding a worktree, naming it, setting up its environment, remembering to tear it down, all per task and all by hand. That friction was heavier than the serial workflow it was replacing. And second, for a structural reason I only understood later: even when I instructed the agents to use worktrees themselves, isolation worked and shipping didn’t. The changes still had to come back together, and now they came back from further apart.
Parallelism is a loan
That second failure is the one worth dwelling on, because I think most people running parallel agents today are exactly where I was and haven’t noticed.
Worktrees, branches, parallel checkouts: every one of these is just a way of trying to do more work in the same window of time, and all of that work merges into the same branch at the end. The isolation is the cheap half. The bill arrives at integration, and it arrives with interest when the parallel tracks touched overlapping code. Multitasking across four worktrees feels like productivity; nobody stands next to that feeling with a stopwatch when the PRs conflict. In my case the failure mode got ridiculous enough to be clarifying: two agents would produce conflicting PRs, and I’d send a third agent to reconcile them, one with no context on either change or on what I actually wanted, doing archaeology on two strangers’ diffs. The two parties who understood the conflict were right there, and the one sorting it out knew nothing.
Parallelism without an integration story isn’t a speedup. It’s a loan against the merge, at a rate you don’t see until you owe it.
What changed
The turn came while building goldengoose, when the RPI workflow and the lead workflow fell into place together. Between them, they took over both halves I’d been doing by hand.
Isolation stopped costing anything. In goldengoose, worktree plumbing is the runtime’s job, running in Rust in the background: when I add an agent there’s a checkbox, separate worktree or not, and unchecked just means it spawns on the current branch. The agents have the same affordance through the same team tool: an agent adding a teammate can name a worktree for it, or say nothing and get the current branch. That default matters more than it looks: a supervisor spawning implementers into its own feature branch is one omitted parameter, not a git incantation. I haven’t run a worktree command by hand in months. The concept I found too fiddly to adopt became invisible.
And integration stopped being mine. The lead owns it: when branches come back, it cherry-picks them onto main in rounds, runs the checks on the integrated result rather than each branch in isolation, and pushes only on green. When two branches conflict, the fix is the thing I’d been missing all along: the lead tells the two agents who wrote the code to message each other and sort it out. The two parties with the most context resolve it directly, update their branches, and hand back new commits. The clueless third agent doing conflict archaeology is gone from my life, replaced by the conversation that should have been happening in the first place.
The org chart I was reinventing
It took me embarrassingly long to see what this arrangement was: how human engineering teams already work. Engineers work in isolated branches of a shared repo. They align in shared channels. A lead integrates everyone’s changes after review. Nobody hands two colleagues’ merge conflict to a stranger; the two colleagues talk. Worktrees are just the agent version of “everyone has their own dev environment,” and a dev environment was never, by itself, what made a team parallel. The organization around it was. I’d been adopting the isolation half of a working system and wondering why the whole system didn’t materialize. (My flat-team argument reaches the same conclusion from the architecture side: git and Slack, for agents. I lived it from the workflow side first, one merge conflict at a time.)
The UI seals it, because visibility was the other thing multiple clones never gave me. The goldengoose sidebar shows every agent in the team, each with its own name (“ask silk spider to rebase” is a sentence), and for each one: which worktree it’s in, live line counts, and the full diff of everything changing there right now. Parallel work I can actually see is parallel work I can leave alone.
Where it landed
Daily shipping now looks like this: I talk to the lead. I keep feeding it feature requests and bug fixes as they occur to me, without waiting, and parallel tracks spin up and advance without my involvement: research-plan-implement pipelines here, a browser-testing loop there. I can open any agent’s thread and talk to it directly, and knowing I can is most of the value, because I almost never do. Conflicts get routed between the agents who own them. Integration rounds land on main behind a green gate. My attention goes to deciding what to build.
So yes: worktrees, essential, use them. But if you’re bouncing off them the way I did, the tool probably isn’t your problem. Worktrees make agents isolated, and isolated was never the goal. Parallel is an organizational property, and the organization is the part I had to build.