For a long time, my workflow with Claude looked exactly like everyone else's: open a chat, hand over a ticket, wait, read the output, adjust the prompt, and wait again. It felt productive because something was always happening on my screen, but most of that "something" was Claude working, not me. I was trapped in a serial loop.
Then, I tried an experiment by running four Claude instances simultaneously, each confined to its own isolated Git worktree. A week into this setup, I am never going back. This post is about that shift: from one Claude to four, from serial work to parallel work, and from a single branch on my machine to a fresh worktree per task. It is also about what it actually feels like to keep four agents in flight at once.
The Old Loop: The Repo Bottleneck
The traditional, single-Claude workflow has a familiar rhythm to it: prompt, wait, check, adjust. You don’t lose the thread of what you're doing, but you sit there knowing you could be doing something else.
The real problem with this setup isn't just the dead time spent waiting; it's that you can't easily kick off a second feature while the first one is processing. If you try to work on multiple things at once within the same directory, you quickly run into a mess of conflicting file changes, uncommitted code, and broken states in your repository. You are effectively forced to work on a single track.
Keeping Multiple Tasks in Flight
To get around this, I keep four separate Claude instances open, but I use Git worktrees to isolate the actual code execution. Without worktrees, running multiple coding instances at the same time would just create file chaos.
Instead of forcing every instance to look at the same directory, a Git worktree lets you check out multiple branches of the same repository into separate folders on your machine. When I want an instance to actually make code changes, I just instruct that specific Claude to spin up a fresh directory:
git worktree add ../project-some-task feature/some-task
Because these folders are physically separate but share the same Git history underneath, there is no stashing, no overlapping code changes, and no risk of file conflicts. Each instance gets pointed at its own dedicated folder.
The work stops being one thing at a time and starts being multiple things in flight. While Instance 1 is busy implementing a feature in its assigned folder, Instance 2 is researching an approach, Instance 3 is being briefed on a bug, and Instance 4 is waiting for me to review a diff.
Each window strictly owns its own branch and directory, meaning they never collide, and I can switch between the instances whenever one is processing.
The Cognitive Load
You would think running four instances would be cognitively exhausting, but it isn't. Because Claude is already offloading the bulk of the heavy lifting on each task (reading the code, holding the specific API syntax in memory, and writing the boilerplate) the mental load changes.
What's left for me is high-level architectural work: reviewing approaches, making critical decisions, and steering. Because that work is light enough, I have plenty of headroom to manage four contexts at once. The infrastructure does the remembering for me; my job is simply knowing which of the four problems needs my input next.
How I Actually Start a Task: The Power of the Brief
To make parallelism work without collapsing into chaos, you need a strict system. For me, that system relies on a reliable technical approach step.
I never let Claude jump straight into coding. Instead, I hand it a Jira ticket, and the first thing it must do is produce a technical approach document. It outputs a short summary detailing:
- Which files will be involved.
- The exact structural changes it proposes.
- Potential risks or edge cases.
I read the approach against the ticket, sanity-check the logic, push back where it’s off, and only then do I let it move into implementation.
By the time I hit "go," I already trust the plan. Because the blueprint is solid, the instance doesn't need much from me while it works, allowing me to move on and brief the next one.
As part of this kickoff, when I want Claude to make the actual code changes, I explicitly instruct it to spin up the fresh Git worktree before it starts implementing. It's one worktree per task, whenever I start something new that I don't want bumping into work already in flight. When the task is completed and the PR is merged, I simply remove the worktree directory and move on.
What It Actually Feels Like
Honestly, it feels like being a Tech Lead managing a team of three or four engineers, except the engineers work at lightning speed and never get tired.
You aren’t always running four at once. Sometimes it's two, sometimes three, but having the architecture ready to leverage when the workload allows is where the productivity gains show up.
The shape of my workday has fundamentally changed. I used to finish a day with one task moved forward significantly. Now I finish with three or four in some state of progress, and a couple of them entirely done. This isn't a clean 4x multiplier. I am still the ultimate bottleneck for code reviews and decisions, but it is materially more than 1x, and the compounding effect over a week is real.
What I'd Tell Someone Starting
If you want to transition from serial to parallel work, keep these three things in mind:
- Use Git Worktrees from Day One: Do not try to hack this using a single directory. The friction of managing multiple features in one workspace will kill the experiment immediately.
- Invest Heavily in the Brief: Set up a workflow that forces a proper technical approach before a single line of implementation code gets written. The quality of that initial blueprint sets the ceiling for the AI's output, and when running parallel tasks, a poor plan becomes punishing very quickly.
- Don't Force the Number Four: The goal isn't to keep four balls in the air at all times just for the sake of it. It's to build an environment where, the moment you do have multiple things to handle, you can actually execute them in parallel instead of queuing them up behind each other.
Four Claudes and a worktree per task. A small change in setup, but a massive change in how a day of development feels.