On using worktrees

10 May, 2026

Worktrees are a git device that allows you to work on several branches simultaneously. Since this Boris Cherny tweet (and, as far as I can tell, largely because of it), worktrees have become a standard recommended device for agentic programming.

I agree with the apparent consensus that worktrees are an essential tool in modern programming. When you need them, they're vastly better than alternatives. But I don't use them very much, for a few reasons:

1. Work that can be done in parallel can often be done on a single branch without conflicts.
2. Work that cannot be done in parallel without conflict often benefits from being addressed together, either as part of a larger single task or as a serial set of tasks. (Putting these two points as a dilemma: tasks either operate mostly independently on your codebase, in which case there's no harm in keeping them on one branch, or they don't, in which case it's often better not to defer the conflict.)
3. Relatedly: LLMs are better and better at handling larger and longer-running tasks, so it's more and more reasonable to aggregate tasks that would previously have been better addressed on separate worktrees.
4. LLMs are better at figuring out when they're "fighting with" other LLMs on a given branch and taking reasonable steps when this happens.
5. LLMs are faster overall, which means that the limiting factor is more often me. I used to use so many worktrees because I could state clearly what I needed so much faster than the LLM could implement it. LLMs are getting faster and faster, so that situation doesn't come up as much.
6. The previous point is even more relevant if you work with both a flagship model and a pretty-good-and-much-faster model to hand. (And you should!) Even if you really do have a set of six worktree-apt things to do, you can probably use the much faster model for at least a few of them.
7. And, when none of the above applies, I am often working with Claude Code on the web,¹ Codex cloud,² or similar, which handles all the isolation for me.

Some of those depend heavily on my specific patterns of work. I don't at all doubt that worktrees are an essential tool for Cherny and many others. Again: when I need them, they're invaluable; it's just that I don't need them very often anymore.

Beyond my first-order professional interest in this subject, I find it psychologically and sociologically revealing. I'm a little sad not to need worktrees more: it's a tangible, desmonstrable bit of knowledge that makes me feel that I'm adapting to AI engineering. Simon Willison absolutely nailed it, I think, when he noted that "one of the reasons [MCP] took off is that every company knew they needed an 'AI strategy,' and building (or announcing) an MCP implementation was an easy way to tick that box."³ I suspect that my pleasure in worktrees came from an analogous place. Learning new techniques is great, and even essential, but they constitute only a small part of the craft we need to be mastering.

#generative AI #nuts and bolts #psychology of software #software