😻 One Repo, Many Agents
I was catching up with a friend in Seattle earlier today. We have known each other for a while, but I only recently found out he is deep into the same AI coding workflow I am. He has Claude Code, a Max plan, the whole setup. We spent an hour swapping notes on how we use these tools.
At some point I mentioned git worktrees. He had never heard of them.
This surprised me, because worktrees have become such a natural part of how I work that I forgot they are not common knowledge. I had the same reaction when I first learned about them. You mean I can have multiple copies of the same repo, on different branches, sharing the same .git directory, without cloning anything? That has been in git since 2015?
What Worktrees Are
Git introduced git worktree in version 2.5, released in July 2015. The feature lets you check out multiple branches of the same repository into separate directories, all linked to a single .git folder. No duplicate clones. No wasted disk space. Just multiple working directories pointing at the same repo.
# You're on main in ~/projects/my-app
git worktree add ../my-app-feature-auth feature/auth
git worktree add ../my-app-fix-nav fix/navNow you have three directories:
~/projects/my-app/ # main branch
~/projects/my-app-feature-auth/ # feature/auth branch
~/projects/my-app-fix-nav/ # fix/nav branchEach one is a full working tree. You can build, test, and run code in each independently. They share history, remotes, and refs. When you are done, git worktree remove cleans up.
The feature has been in git for over a decade. I only learned about it recently. But once you see it through the lens of AI agents, it becomes essential.
Why This Matters for AI Agents
If you have one AI agent working in your repo, worktrees are a nice convenience. If you want to run two or three agents in parallel on the same codebase, they are a necessity.
Without worktrees, two agents editing files in the same directory will destroy each other’s work. One writes a file, the other overwrites it. One stages changes, the other stages different changes on top. It is chaos.
With worktrees, each agent gets its own directory, its own branch, its own working tree. They can be editing the same files in the codebase and never interfere with each other, because they are literally operating in separate directories on separate branches.
The workflow becomes: tell each agent to work in its own worktree. They can work in parallel on different features, bug fixes, or refactors, all on the same codebase, on the same machine, at the same time.
The PR Workflow, but for Agents
Once your agents are on separate branches in separate worktrees, something familiar emerges. It looks like a normal software engineering team.
Each agent works on a feature branch. When it finishes, you review the diff. If it looks good, you merge to main. If there are problems, you send it back for revisions or throw it away entirely. This is the same pull request workflow that every software company runs, except your team is made of AI agents.
You can take it further. Have one agent review another agent’s branch before merging. If the review passes, merge. After merging, run your test suite on main, because merge conflicts can introduce subtle bugs that did not exist on either branch individually. This is not theoretical. When you have multiple agents merging changes into the same codebase throughout the day, conflicts will happen, and catching them early on main is the same discipline that real engineering teams practice.
The pattern scales. Two agents is manageable without much process. Five agents working on the same codebase needs real change control. Worktrees plus feature branches plus reviews give you that control.
The Vocabulary Gap
My friend and I talked about something else that stuck with me. It feels like there are not a lot of people around us in Seattle who are deep into this workflow. Not zero. But fewer than you would expect for a city full of engineers.
A lot of people are inside companies where this technology has to diffuse down from leadership, and that process is slow. Meanwhile, San Francisco seems further ahead on the adoption curve, probably because the density of people building and using these tools is higher there.
But the more interesting observation is about vocabulary.
The things you can get out of an AI are directly shaped by the words you know how to use. If you have the domain vocabulary for a niche topic, you can prompt things that someone without that vocabulary simply cannot. Not because the AI is incapable of producing it, but because the person does not know how to ask.
Git worktrees are a perfect example. If you do not know the term “worktree” exists, you might ask your AI how to work on multiple branches at once, and it might suggest cloning the repo twice. The concept is right there in the tool, but you need the word to unlock it.
This extends beyond git. The more technical vocabulary you have, the more precisely you can describe what you want, and precision in prompting is everything. Knowing what a semaphore is, what a discriminated union is, what eventual consistency means: these are not just concepts for writing code anymore. They are concepts for talking to something that writes code for you.
It almost feels like knowing your Latin and Greek roots might be becoming more important than knowing how to solve leetcode problems. Your breadth of language determines the ceiling of what you can ask for. And the ceiling of what you can ask for determines the ceiling of what you can build.
I had a HackerRank screen recently. I did not do well. This is a skill I had practiced extensively to get into the companies I have worked at, and it has clearly atrophied. But I do not value it the way I used to. It is something I can outsource right now, and I will be able to outsource it even more effectively in the future. The ability to invert a binary tree under time pressure is not what differentiates you anymore. The ability to describe what you want built, precisely and in the right language, is.
Getting Started
The advice I gave my friend: just ask your AI to do it.
You do not need to memorize the git worktree commands. Tell your agent something like “I want to try implementing this feature. Research how it should work, then set up a new git worktree and build it there.” The agent will create the worktree, check out a feature branch, and start working in it. You can open another terminal, start another agent, and give it a different task in a different worktree. Same repo, no conflicts, full parallel execution.
The feature has been sitting in git for a decade, waiting for a reason to matter this much. AI agents are that reason.
I was catching up with a friend in Seattle earlier today. We have known each other for a while, but I only recently found out he is deep into the same AI coding workflow I am. He has Claude Code, a Max plan, the whole setup. We spent an hour swapping notes on how we use these tools.
At some point I mentioned git worktrees. He had never heard of them.
This surprised me, because worktrees have become such a natural part of how I work that I forgot they are not common knowledge. I had the same reaction when I first learned about them. You mean I can have multiple copies of the same repo, on different branches, sharing the same .git directory, without cloning anything? That has been in git since 2015?
## What Worktrees Are
Git introduced `git worktree` in version 2.5, released in July 2015. The feature lets you check out multiple branches of the same repository into separate directories, all linked to a single .git folder. No duplicate clones. No wasted disk space. Just multiple working directories pointing at the same repo.
```bash
# You're on main in ~/projects/my-app
git worktree add ../my-app-feature-auth feature/auth
git worktree add ../my-app-fix-nav fix/nav
```
Now you have three directories:
```
~/projects/my-app/ # main branch
~/projects/my-app-feature-auth/ # feature/auth branch
~/projects/my-app-fix-nav/ # fix/nav branch
```
Each one is a full working tree. You can build, test, and run code in each independently. They share history, remotes, and refs. When you are done, `git worktree remove` cleans up.
The feature has been in git for over a decade. I only learned about it recently. But once you see it through the lens of AI agents, it becomes essential.
## Why This Matters for AI Agents
If you have one AI agent working in your repo, worktrees are a nice convenience. If you want to run two or three agents in parallel on the same codebase, they are a necessity.
Without worktrees, two agents editing files in the same directory will destroy each other's work. One writes a file, the other overwrites it. One stages changes, the other stages different changes on top. It is chaos.
With worktrees, each agent gets its own directory, its own branch, its own working tree. They can be editing the same files in the codebase and never interfere with each other, because they are literally operating in separate directories on separate branches.
The workflow becomes: tell each agent to work in its own worktree. They can work in parallel on different features, bug fixes, or refactors, all on the same codebase, on the same machine, at the same time.
## The PR Workflow, but for Agents
Once your agents are on separate branches in separate worktrees, something familiar emerges. It looks like a normal software engineering team.
Each agent works on a feature branch. When it finishes, you review the diff. If it looks good, you merge to main. If there are problems, you send it back for revisions or throw it away entirely. This is the same pull request workflow that every software company runs, except your team is made of AI agents.
You can take it further. Have one agent review another agent's branch before merging. If the review passes, merge. After merging, run your test suite on main, because merge conflicts can introduce subtle bugs that did not exist on either branch individually. This is not theoretical. When you have multiple agents merging changes into the same codebase throughout the day, conflicts will happen, and catching them early on main is the same discipline that real engineering teams practice.
The pattern scales. Two agents is manageable without much process. Five agents working on the same codebase needs real change control. Worktrees plus feature branches plus reviews give you that control.
## The Vocabulary Gap
My friend and I talked about something else that stuck with me. It feels like there are not a lot of people around us in Seattle who are deep into this workflow. Not zero. But fewer than you would expect for a city full of engineers.
A lot of people are inside companies where this technology has to diffuse down from leadership, and that process is slow. Meanwhile, San Francisco seems further ahead on the adoption curve, probably because the density of people building and using these tools is higher there.
But the more interesting observation is about vocabulary.
The things you can get out of an AI are directly shaped by the words you know how to use. If you have the domain vocabulary for a niche topic, you can prompt things that someone without that vocabulary simply cannot. Not because the AI is incapable of producing it, but because the person does not know how to ask.
Git worktrees are a perfect example. If you do not know the term "worktree" exists, you might ask your AI how to work on multiple branches at once, and it might suggest cloning the repo twice. The concept is right there in the tool, but you need the word to unlock it.
This extends beyond git. The more technical vocabulary you have, the more precisely you can describe what you want, and precision in prompting is everything. Knowing what a semaphore is, what a discriminated union is, what eventual consistency means: these are not just concepts for writing code anymore. They are concepts for talking to something that writes code for you.
It almost feels like knowing your Latin and Greek roots might be becoming more important than knowing how to solve leetcode problems. Your breadth of language determines the ceiling of what you can ask for. And the ceiling of what you can ask for determines the ceiling of what you can build.
I had a HackerRank screen recently. I did not do well. This is a skill I had practiced extensively to get into the companies I have worked at, and it has clearly atrophied. But I do not value it the way I used to. It is something I can outsource right now, and I will be able to outsource it even more effectively in the future. The ability to invert a binary tree under time pressure is not what differentiates you anymore. The ability to describe what you want built, precisely and in the right language, is.
## Getting Started
The advice I gave my friend: just ask your AI to do it.
You do not need to memorize the git worktree commands. Tell your agent something like "I want to try implementing this feature. Research how it should work, then set up a new git worktree and build it there." The agent will create the worktree, check out a feature branch, and start working in it. You can open another terminal, start another agent, and give it a different task in a different worktree. Same repo, no conflicts, full parallel execution.
The feature has been sitting in git for a decade, waiting for a reason to matter this much. AI agents are that reason.