The git worktrees feature has first garnered public attention since anthropic mentioned it in its claude code good practices. Until then it was just one of these obscure git features most professionals have never heard of. Now all these agents and claude code wrappers are trying to make use of git worktrees - but in all honesty - it's overcomplicating most workflows more than being of a real use for agentic coding. The bottleneck was - for most workflows - never the ai not being able to write 10 different poc of my feature simultaneously - but the human factor - needing to carefully review what ai produced and still steering ai in the right direction. git worktrees doesn't help solve any of these problems. it just adds an unnecessary layer on top.

This is what I’ve been thinking about recently.

Babysitting one process, but giving it all of my attention[1] can lead to rapid progress.

Pushing forward multiple efforts simultaneously can lead to rapid progress if code is largely unrelated and you keep a sharp eye on branching and commits.

However, it’s remarkably easy to make a mistake and be enamored by how well the AI can use git to fix your mistake.

But the cost ends up being adherence to it, specification or architecture, or being distracted into scope creep.

The new scope might be useful for factoring, but that is also the kind of thing that interfere with your Main processor trying to handle.

And it’s remarkably easy to get lost in the state when you have to manage validation well.

The more mature the project and more intense the expectation of scm hygiene, the more punitive small mistakes can become.

It is not really a problem in my process prior to Claude code, which was almost entirely turned based chat.

I still have configured fairly complex and detailed session workflows to preserve state amidst the regular threat of auto compact.

Even I even have documentation, describing a plan to migrate into git worktrees myself, but haven’t been able to justify the move, as I continue to learn to be productive with a single main session focus.

[1] I don’t know if there is such a thing as constant focus on a complex genetic programming effort because of the delays involved. You can stare at the funny verbs anthropic picks while the tokens go brrrr for only so long.

Agree and disagree.

Yes, the bottleneck is going to still be human review. But with only a single Claude Code (or Cursor), I spent a lot of time (a couple minutes at a time) waiting for the agent to run through its loop completing what I asked it to do. In this time I found I was naturally switching context, but not always productively (checking slack, email, whatever). I called it "agent lag" time.

Now with these worktrees tools, I can easily bounce between tasks I have the agents working on during these natural lulls. Overall I'm able to get more done and spend my time more efficiently.

Also, Cursor has had the option to run multiple agents for a while (in tabs), but I always found it cumbersome because all the agents are operating on the same git checkout, so you have to take special care for them not to conflict with each other. Worktrees completely solve that problem.

Yes I had a similar experience. the thing that tripped me up with git worktrees, which is maybe obvious in retrospect, is that they don’t include things that are not tracked by git - e.g. .env.development.local

So starting a new worktree requires additional setup and isn’t as simple as just checking out a new branch

Sorry about that! We’re working on making this more intuitive.

Internally our workflow looks like this: - we have a script that sets up a repo — copies env variables, runs pnpm i, inits a db, etc - we have a field in the repo settings called “setup script.” every time you make a new workspace, that script runs

Hopefully will be much improved over the next week or two!

I'm working on a little wrapper that solves this problem. I have similar needs with .env files, and in my case running 'uv sync' to install dependencies. I linked it elsewhere in this thread so I won't repeat the URL (autowt). It's definitely possible to make this workflow effective with some scripting.

Could you group the main repo and its worktrees under a common parent directory that contains your .env.development.local?

Ah that’s a good idea I’ll have to try that out

But that is also the selling point of worktrees - I have them for multiple features I am working on, I just spin up services that I need for each feature separately, like databases, etc. How else are you going to isolate migrations, configuration changes, etc.

check out https://github.com/dagger/container-use! it uses worktrees under the hood, but hides them from the user and agent. it basically gives you containers tracked by git branches and plugs into any MCP-compatible agent. you're then free to make your own worktrees from those branches, but you can also just use them in your normal checkout.