Why Running Agents on a Single Branch Can Be Faster Than Worktrees
For Joel's [[agent-loop]] flow, this is a concrete policy: keep loops on one [main branch](https://git-scm.com/docs/git-branch) with strict task boundaries first, then switch to sandboxed parallelism when concurrent GUI testing causes collisions.
Ben Holmes’s note on his X thread is a sharp counterpoint to the “more branches + more orchestration” instinct. In Peter Steinberger’s setup, there is one Git repository, one live dev server, one checked-out main branch, and multiple OpenAI Codex-style agents at once.
The move is subtle but useful: complexity shifts from infrastructure to task boundaries. He gives each agent a narrowly defined job, lets them commit changes on shared ground, and validates with atomic, file-scoped commits. That keeps output reviewable without paying branch and worktree overhead just to make multiple agents move in parallel.
The weak point appears when concurrency needs direct UI control. The post explicitly calls out native app testing as the moment where parallel on one branch becomes brittle. In practice for joelclaw, the useful pattern is clear: start lean with one branch, then add Git worktrees or cloud sandboxing only when interaction collisions rise.
Key Ideas
- One branch is viable when tasks are explicit: keep agent orchestration in the task definitions and you can avoid a lot of branch churn while still preserving safety.
- Atomic, file-scoped commits are a practical brake: each agent’s touched files become the merge unit, reducing cross-agent ambiguity and lowering review friction.
- Parallelism should be constrained by test mode: when work is GUI-bound or requires a real cursor/mouse loop, moving some agents to isolated runtime environments prevents accidental clobbering.
- Branch-per-agent is a scaling lever, not a starting point: treat isolation as escalation, not default, and keep the developer loop fast until contention proves the extra ceremony is worth it.