Build1 publisher2 min readPublished
Andrew Pyle gives each coding agent its own git worktree cut from origin/main
Andrew Pyle runs parallel coding agents in separate git worktrees cut from origin/main, at about a second and a few megabytes each. All the worktrees share the repository's one object store, so setup stays cheap and the remaining coordination happens in a single merge.
The Engineer · Build desk
What happened
- Andrew Pyle's first try at running two coding agents in one directory mixed their half-finished edits and left a build that made no sense.
- His first fix was to make the agents coordinate through locks, turns and a queue, an instinct he now says was wrong.
- He creates a fresh worktree even for a one-character docs fix and puts the cost at about a second and a few megabytes.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Provisioning is no longer a reason to limit how many agents run. The cost that grows as agents are added is the effort of the final merge.
- constraint Parallel agents help only as far as a job splits into tasks on separate files. Breaking the work up becomes the planning step that decides how many agents to run.
- decision When worktrees are cut from origin/main, an agent sees only work that has already reached origin/main. Anything it depends on has to land there before the agent starts.
"The problem wasn't a lack of coordination. It was shared state," Pyle wrote [3]. His objection to locks and queues is about how they grow. "This works for two and becomes a nightmare at ten," he wrote. Each added agent is another party to the negotiation and another way for the scheme to deadlock or starve [4][5]. In his words, that turns "a parallelism problem into a distributed-systems problem, and distributed-systems problems are where good weekends go to die" [13].
A worktree duplicates only the checked-out files. History stays in the repository's single object store, and every worktree reads from it [6]. Each directory holds its own uncommitted changes. The other agents cannot see those changes until they are merged [7]. Pyle credits the shared store with both halves of the design. New worktrees are cheap to stand up. At the end, git already has every branch in one history and can reconcile any two of them [8].
The detail I would copy is the last argument of his command:
``` git worktree add ../ajp-og-cards -b feat/per-page-og-cards origin/main ```
`-b` names a fresh branch for the agent, and `origin/main` fixes where it starts [11]. Pyle added the start point after getting burned. His main checkout usually held uncommitted work from an hour earlier. An agent that branched from it carried that unrelated work into its own commits [10]. With the start point pinned, every agent begins from the same known baseline, whatever the local checkout looks like at that moment [11].
The scaling claim needs more care. Pyle's summary is that ten agents mean "ten independent workspaces and one merge step" [9]. That is an argument from one developer's projects, and the post reports no conflict counts or merge times. Worktrees stop agents from seeing each other's half-finished edits. They do not change what happens when two finished branches edit the same lines. In my view the claim transfers to a team only when the fanned-out tasks touch mostly separate files. I'd expect two agents that rewrite the same function to collide in the merge step, where someone still has to resolve it.
I think this is the right default for running more than one agent on a repository, and the cost figures support it. At Pyle's estimate of about a second per worktree, fanning out to ten agents takes roughly ten seconds of setup [1]. Because adding an agent costs so little, he treats the choice between spreading a task across five workers and grinding through it with one as a decision to make task by task [14].
What to watch
- Conflict counts and merge times from runs where fanned-out agents edit overlapping files. The post reports neither.
- Whether the same isolation approach extends to shared resources outside the working tree that agents' test runs touch.