AI coding tools become much more useful when they are given clear boundaries.
One practical way to create those boundaries is with Git worktrees.
A Git branch gives you separate history. A worktree gives you a separate working directory connected to that branch.
Instead of making several AI agents share one workspace, you can give each agent its own isolated environment.
What is a Git worktree?
A worktree lets you check out multiple branches from the same repository at the same time.
For example:
git worktree add ../feature-a -b experiment/feature-a
git worktree add ../feature-b -b experiment/feature-b
You now have two separate directories. Claude Code, OpenAI Codex, or another coding agent can work inside each one without constantly switching branches in your main project.
1. Create different versions of a feature
Sometimes there is no obvious best implementation.
Instead of asking one agent to repeatedly rewrite the same code, create separate worktrees:
- Worktree A: simplest implementation
- Worktree B: performance-focused implementation
- Worktree C: implementation that follows a different UI or architecture
You can then compare the actual code, tests, and tradeoffs before choosing a solution.
The unsuccessful versions can be removed without affecting the selected implementation.
2. Give every subagent its own workspace
Multiple agents editing the same directory can easily overwrite files or mix unrelated changes.
A safer setup is:
project/
project-agent-api/
project-agent-ui/
project-agent-tests/
Each agent receives:
- Its own worktree
- Its own branch
- A clearly defined task
- A list of files it is allowed to change
- Its own verification requirements
This makes every agent’s output easier to understand and review.
3. Work on independent tickets in parallel
Worktrees are useful when several tasks do not depend on each other.
For example:
- One agent fixes an API bug
- Another updates a frontend component
- Another adds tests or documentation
These tasks can progress at the same time without repeatedly stashing changes or switching branches.
However, parallel work should still be planned carefully. If two tasks modify the same important files, they may need to be handled in sequence.
4. Separate implementation from review
One worktree can be used for implementation while another agent reviews the resulting diff.
The reviewing agent can look for:
- Missing requirements
- Edge cases
- Unnecessary changes
- Security or performance concerns
- Missing tests
The developer still makes the final decision, but the separate review provides another quality gate before integration.
5. Handle interruptions safely
Imagine an agent is working on a large feature when an urgent bug appears.
Without worktrees, you may need to stash incomplete changes, switch branches, fix the bug, and restore the previous state.
With worktrees, the feature can remain untouched while the urgent fix happens in another directory.
A simple agentic workflow
My general workflow looks like this:
- Break the work into independent tasks.
- Identify dependencies and possible file collisions.
- Create one worktree for each independent task.
- Give every agent explicit requirements and boundaries.
- Review and test each result.
- Integrate only the changes that pass.
Worktrees do not automatically make multiple agents effective. Clear instructions, task boundaries, testing, and human review are still required.
What worktrees provide is isolation.
That isolation creates clearer ownership, fewer accidental collisions, and changes that are easier to compare, accept, reject, or roll back.
Git worktrees can turn AI coding from one long conversation into a more structured engineering workflow.
Top comments (4)
Worktrees are one of the few agent workflow tricks that stayed boring enough for me to keep. The file allow-list matters more than the directory split, though. If two agents can both touch the same config or shared type, the separate checkout only delays the merge fight instead of preventing it.
Exactly 😄 Worktrees give agents separate rooms; file allow-lists stop them from renovating the same wall. Great point, @reidmarlow .
This lines up with something I hit from the other direction — not file collisions, but a shared MCP server across worktrees. Multiple agent windows pointed at isolated worktrees still ended up fighting over the same server-side lock file, because the MCP process itself wasn't worktree-aware. One orphaned process (parent killed, child not) held the lock indefinitely since nothing was watching for that case — 30s hangs on every other agent trying to write.
Worth flagging for anyone going full parallel-worktree + MCP tooling: isolation at the git level doesn't automatically mean isolation at the tooling level. If your agents share any long-running server process (indexer, LSP, MCP server), that's a second axis of collision independent of the file allow-list Reid mentioned below.
Never thought of that collision point 😄 Separate rooms, shared plumbing. Thanks for flagging it, @mansio !