Concurrent Agentic Development with Git Worktrees

The software development industry is undergoing rapid change. The way I do my job has changed more in 2026 than any other year of my (now relatively lengthy) career. Most developers have transitioned from manually writing code to at least using AI agents to help write their code, if not having transitioned to having AI agents write pretty much all of their code. The role of the developer has moved towards code reviews rather than code development. As time progresses, even this role is going to become a smaller part of what a software developer does as AI agents also take charge of code reviews and the industry moves towards a fully automated software development workflow and software lifecycles become considerably more automated.

I use a mixed of the above at this point in time. I'm using AI agents to write code and to review code but I still occasionally write the odd line of code (mostly where it's a quick fix that's more speedily done by hand) and I'm still very much in the driving seat when it comes to code reviews, being informed by my agents but ultimately the final decision on merger falls to me.  My software projects involve a lot of development via task trackers and there are times when, with the use of an AI agent, I can be working on multiple tasks at the same time. Previously, concurrent development would be manual. I would be working on several git branches at the same time in my projects. I would manually switch between them, as required, keeping each up-to-date with the main branch via the occasional re-base. AI agent programming has changed this considerably it's mostly no longer me that's working on the code but my agents doing the work instead.

So, how to stop each agent instance from trampling all over the work of another when they're working concurrently?

If they followed the same branching strategy I've always used when programming manually, then they would constantly be tripping over each other as one switches the current branch. One tactic that I started using was to pull a complete new clone of the entire project for each agent. I would have one branch, heading towards one pull/merge request, in one directory. This leads to clear separation, with an individual coding and agent window (e.g. vscode with the Claude Code plugin, IBM's Bob IDE, or Google's Antigravity, amongst others) per branch/directory. This scales to some extent but you can quickly lose track of which window is working on which task as the number of IDE windows you have open increases. It's also a relatively heavy weight approach as you need an entirely new development environment with a separate clone of the code, dependencies installed, virtual environments, container images, and everything else you need to have the code run.

Enter, Git Worktrees.

Until recently, a git worktree is something I've known about but rarely used. When coding manually, you're fairly "single threaded" in as much as you work on a single branch at once and thus switching branch to work on a different task is OK. AI agent based coding changes this when working concurrently, as I explained above. I've found git worktrees to be a great solution as you can have multiple agents, each working in the same clone of your code, but they're separated using a new directory for each branch. The clever bit is that git worktrees allow you keep that one single clone, share the dependencies, virtual environments and everything else to get the code tested and running and thus they're a much lighter-weight solution to an individual clone per branch. You have a single IDE window open with multiple different AI agent conversations running concurrently, so keeping track of what's going on is much easier as well. The difference is that instead of moving between your branches using git switch, you now move between branches simply by changing directory to the directory that contains your git worktree.

There are a few different steps or use cases that I'd like to document for this approach:

0. Configuration

I'm calling this step 0 because there are some prerequisites or configuration that you'll want to get right first. I prefer to have all my git worktrees live under the same top directory. It doesn't matter what you call this directory but I tend to use .worktree in my project root.

Next you'll want to git ignore your worktree directory.  Because we've placed it inside your project root (for convenience in your IDE), all the branches you add there will show up as additional files to git. There's a couple of approaches to this ignore: (1) you just ignore the entire .worktree directory; or (2) you want to commit the top-level .worktree directory to your git repository but ignore all sub-directories (in which case you'll also want to add a .worktree/.gitkeep file so that git allows you keep this empty directory. Personally, I use (1) and just ignore the entire thing.

Most agents are clever enough to figure out that you've created a branch for them and that the branch exists within a worktree.  However, you can write this in your prompt or potentially set up some notes in your general agent markdown instructions file, or even write a skill, such that you say something along the lines of: "Using the `new-branch-name` branch in the git worktree at `.worktree/new-branch-name/`, ... start the rest of your prompt here...".  Obviously, you'd swap out the relevant parts of that prompt to point to your actual branch and worktree as created below.

1. Starting work on a new task in a new branch in a git worktree

When you want to start a new task in a new branch, you would previously have run something that looks a bit like this, to create a new branch:

git checkout -b <new-branch-name>

But with git worktrees, this would change to:

git worktree add -b <new-branch-name> .worktree/<new-branch-name>

Now, instead of changing branches with git switch. You simple change branches by changing directory to .worktree/<new-branch-name>

2. Moving work from an existing branch into a git worktree

The process is a little different if you've already got a branch and now you want to move it into a worktree.  Confusingly, the git CLI reverses the order of the arguments required and thus to move work from an existing branch into a git worktree, you run:

git worktree add .worktree/<existing-branch-name> <existing-branch-name>

Here, you can see that you specify the directory first and branch second where as in (1, above) when starting from scratch you specify the branch first and then the directory.

You get the same result that you now have a new directory under .worktree into which you can navigate and continue working on your branch without the need to run a git switch. 

3. Reviewing or continuing someone else's work from a remote branch in a git worktree

In the  event that you want to pull a remote branch to review and perhaps continue work on it:

git worktree add -b <branch-name> .worktree/<branch-name> origin/<branch-name>

This is the same command as (1, above) but you simply append the remote name and branch name as you normally would for other git commands.