The Worktree Trap

Noah is on a roll.

He just discovered git worktrees. The idea is elegant — instead of switching branches and losing context, you check out each branch into its own directory. One folder for the authentication fix, another for the new dashboard, a third for that API refactor he’s been putting off.

Three streams of work. Three clean directories. One developer who feels like he just unlocked a cheat code.

By Wednesday he has worktrees for everything. His terminal has six tabs open. Claude is helping him write code in two of them simultaneously. He’s shipping features in parallel. This is what productivity looks like.

Except it isn’t.

The Coffee Problem

Thursday morning, Noah steps away to take his kids to school. Twenty minutes. No big deal.

He comes back, sits down, and stares at his screen. Six terminal tabs. Three worktrees. Which one was he working on? He clicks through them. The authentication worktree has uncommitted changes — was he in the middle of something, or did he leave it in a working state? The dashboard branch has a failing test. Was he about to fix it, or did he just discover it?

He spends fifteen minutes reconstructing where he was. Not writing code. Not thinking about the problem. Just figuring out which problem he was thinking about.

This happens every time he steps away. Grab coffee — where was I? Take a phone call — where was I? Come back the next morning — where was I?

With one branch, the answer is obvious. You open your editor and you’re looking at the thing. With three worktrees, you’re playing detective in your own codebase.

Depth vs. Breadth

The real cost isn’t the fifteen minutes of reorientation. It’s what happens to the quality of your thinking.

When Noah is focused on one feature, he holds the whole shape of it in his head. He sees the edge case before he writes the code. He notices that the API contract doesn’t quite match what the frontend expects. He makes the design decision once, with full context, and moves on.

When he’s toggling between three features, he makes shallow decisions. He skips the edge case because he’s eager to get back to the other worktree. He merges something that’s 90% right because two more branches are waiting. Each feature gets a third of his attention, and the result shows.

AI assistants make this worse, not better. When Claude can write code fast, the temptation is to open more streams. More worktrees, more agents, more parallel progress. But speed of code generation was never the bottleneck. Understanding is the bottleneck. And understanding doesn’t parallelize.

Worktrees Solve a Team Problem

Git worktrees were designed for a real problem — just not Noah’s problem.

On a team, worktrees let you review a colleague’s PR without stashing your own work. You check out their branch in a separate directory, run the tests, leave comments, and switch back. Your work is untouched. That’s genuinely useful.

But Noah isn’t reviewing someone else’s code. He’s trying to be three developers at once. And the fundamental constraint hasn’t changed: he has one brain, and it can only hold one problem at a time.

The Parallel Productivity Illusion

The pattern with worktrees is the same pattern that shows up everywhere in AI-assisted development: a tool removes a technical constraint, and you mistake that for removing the human constraint underneath it.

Worktrees remove the friction of branch switching. But the actual cost of working on three things isn’t switching branches. It’s splitting your attention. The git operations took seconds. The context switch takes minutes — and degrades every decision you make until you’ve fully reloaded the problem into your head.

I’ve watched this play out on my own team. Engineers who are genuinely more productive with AI tools, running multiple streams of work because the code generation is fast enough to support it. And the output looks impressive — lots of PRs, lots of activity, lots of motion. But when you look at what actually ships clean — tested, reviewed, integrated without issues — it’s often less than when they focused on one thing at a time.

You feel busy. You feel like you’re getting more done. The terminal is full of tabs and the commit history is active. But volume isn’t velocity. Three half-finished features aren’t better than one finished one.

One Thing at a Time

Noah eventually figured this out. He deleted four of his six worktrees on a Thursday afternoon. The two features he finished that week shipped cleaner than anything from his “parallel productivity” phase.

The lesson isn’t that worktrees are bad. They’re useful for what they were designed for — quick PR reviews, isolated experiments, a hotfix while you’re mid-feature. The lesson is that the tool that promises to remove constraints often just hides them.

Worktrees hide the cost of context switching. Task lists hide the absence of a hypothesis. Velocity metrics hide the difference between motion and progress. And AI coding tools hide the difference between generating code and understanding what you’re building.

If you’re a solo developer, or a small team working with AI, resist the urge to parallelize your thinking. Parallelize your builds, your tests, your deployments. But your attention? That’s sequential. Protect it.