I want to share an interesting workflow I experimented with recently while working with Claude Code and git worktrees.

Background

I had a lot on my plate with deadlines approaching. I had to fix 3 bugs and complete 2 feature implementations.

And it was not just implementation work. I had to write new unit tests, update existing test cases, manually verify everything, and make sure fixing one thing was not breaking another.

Initially it did not feel like too much. But once I properly analysed everything that needed to be done, I realised the approaching deadline could easily turn this into a mess if I handled it poorly.

I wanted to experiment that day.

How would I have approached this earlier

Normally I would have started with one task, completed it, raised a PR, and then moved on to the next one.

If I got PR comments, I would stash or commit my current work, switch back to the other branch, fix the comments, and iterate on that again. Then I would come back to my original task and continue implementing.

This process itself is not necessarily bad. Always moving fast is not the solution.

The real problem was that these were new implementations. And in my experience, implementing something new usually requires significantly more thinking, exploration, and iteration. If I spiralled on one task, it could easily consume a huge amount of time while everything else remained blocked behind it.

This would have easily taken me 3-4 days.

The moment of realisation

I paused for a while that day and went through multiple possible approaches in my head.

I cannot work on all of them in parallel myself. That is just a fact.

But AI can. But the problem was how do I actually make this practical?

• Should I run multiple Claude Code sessions and ask each one to handle a different task
  But that would quickly become a mess. All of them editing the same working directory and modifying overlapping files was guaranteed to create conflicts.

• Then I thought, what if I ask Claude Code to not make edits and only work in memory?
  But that was not practical either. I could not properly verify anything, test changes, or realistically iterate on the implementation.

• What if I clone the repository multiple times and run separate Claude Code sessions in each copy?
  That probably would have worked. But it felt extremely clunky and difficult to manage.

At that point I decided to simply ask Claude Code itself how to solve this problem.

That was the moment it introduced me to git worktrees.

So What are git worktrees

I had never used git worktrees before this. I vaguely knew they existed but never had a reason to try them seriously.

Interestingly, I didn’t even manually set this up myself initially. Claude Code already knew how to work with git worktrees. I simply asked it to help me create a parallel workflow for multiple tasks in the same repository and it handled most of the git setup.

The idea is actually pretty simple.

Normally, we work on one branch at a time. Switching between tasks means stashing changes, checking out another branch, rebuilding context, running the project again, and mentally reconnecting with what we were doing.

Git worktrees solve this differently.

Instead of switching branches in the same directory, you create multiple working directories attached to the same repository. Each directory has its own branch checked out independently.

git worktree add ../project-feature-1 feature/feature-1
git worktree add ../project-bug-1 fix/bug-1

After this, I effectively had five copies of the same project open at once — each isolated to its own task.

One thing I liked here is that I didn’t need to become a git worktree expert before trying this workflow. Claude Code already understood the setup pretty well and guided most of it.

Running Claude Code in parallel

I opened a separate Claude Code session in each worktree directory. I am no expert in prompts.

For the bugs, I gave each session proper context:

• what the issue was
• how to reproduce it
• what I suspected the root cause might be
• what I had already checked

For the features, I described the expected behaviour, edge cases, and which parts of the codebase would probably be involved.

Then I let them run in parallel.

But honestly, this was not some magical “everything worked perfectly” workflow.

Managing five parallel sessions was mentally exhausting initially. There was a lot of context switching. One session would ask for clarification while another had already generated code that needed verification while another was going in the wrong direction entirely.

The interesting part was learning how to drive the sessions properly.

If Claude Code was drifting away from what I wanted, I had to steer it back with more precise instructions. Sometimes the difference between a useful output and a useless one was simply giving better constraints or explaining the intent more clearly.

Over time, I noticed something unexpected, it started becoming easier.

The first hour felt chaotic. Later it started feeling surprisingly natural.

What actually became the bottleneck

At some point I realised the bottleneck had shifted.

Claude Code was generating implementations faster than I could comfortably review and verify them.

I was moving between worktrees continuously:

• checking diffs
• testing fixes
• reproducing bugs
• validating edge cases
• correcting prompts
• answering follow-up questions from another session

The limiting factor was no longer typing speed.

It was my ability to:

• make decisions quickly
• maintain context across multiple tasks
• verify correctness without losing focus

That felt very different from normal development work.

Verification

I manually verified everything. Every bug fix I reproduced the original issue first, confirmed it was gone, checked for obvious regressions. Every feature I tested the happy path and the edge cases I actually cared about.

This would have become more easier with better agent harness. I learnt about this later, maybe will write about this as well in some future blogs.

Result

I was able to ship all 5 requirements with production quality in a single day. That genuinely made me very happy.
The entire workflow felt fascinating to me, so I thought I should share the experience.

How I work now

Now, it’s not like I always run things in parallel. Honestly, even after getting familiar with the workflow, it is still mentally exhausting sometimes. But now I know that if I ever need to move fast, there is actually a practical way to do it.

One thing this experiment made very obvious to me is how important understanding the codebase becomes in this kind of workflow.

• The better I understood the codebase, the easier it became to guide Claude Code properly.
• The better I understood the bugs, the faster I could identify when an implementation was incorrect.
• The clearer my instructions were, the better the parallel execution worked.

That shift was probably the most interesting part of the entire experiment.