It’s the year 2026 and programming has never been as rapid. We transitioned from typing code to plaintext. As a matter of fact, some of our most laborious tasks are done in markdown files. If you told this to a developer of 5 years prior, they would quickly declare you insane—yet the situation is real and most of us are (probably) enjoying it.
The reality is that in 20 minutes you can accomplish what could have taken weeks to implement—but why stop there? The challenge has shifted from writing code to managing multiple agents in parallel.
You may think running multiple agents in the same folder sounds fun, well the joy lasts before the point where they collectively decide to rediscover gravity. Jokes aside, the regressions of the future already have their mind set on haunting you.*
*Though it’s possible to orchestrate multiple agents in a directory, it is advised not to be attempted at home—even trained professionals proceed with caution.
The solution? It’s one you might have been ignoring—worktrees. Likewise, I once doubted it, nevertheless, I’ve reached the point where reverting starts feeling painful.
So What are Worktrees?
Essentially, worktrees are ‘clones’ of a directory, attached to the same repository. It may seem as useful as downloading more RAM, however, one would be appalled at the use cases. A few weeks ago, I was developing a new landing page for PyCollab, unfortunately some elements were incomplete and required more time. This limited my ability to work on other features in the same folder. The actual blocker was not code—it was how I framed the issue.
If a team works on different devices, different folders; connected only by a repo—why can’t your agents do the same? Worktrees give each agent its own workspace, its own environment, its own experimentation. The real shift happens when each task is worked on in a different thread and directory. Especially when it only takes a simple pull request to merge back to main.
That’s when seemingly disorganised reveals a cleaner underlying hierarchy.
Still not convinced? Picture this scenario: you’re working on a maps app. However, you can’t decide between an animated 2D route exploration or an immersive 3D experience. Why not try both out? You spin up 2 worktrees and explore both options. On the other hand, you could work on both tasks in a single thread—it only costs your sanity.
How do I even use them?
To actually use worktrees, you can either ask your agent of choice to help you make them, or use a simple terminal command:
git worktree add ../my-worktree -b my-branch
The command git worktree add takes two parameters, a path (relative to your current working directory), and branch name. The worktree will be created locally at the path specified (in this example, ../my-worktree).
Once finished with a worktree, it can be disposed of with:
git worktree remove ../my-worktree
Much like adding a worktree, removing takes the parameter of a path. Contrastingly, it does not accept a branch parameter: branches have to be removed separately.
Why it matters
The beautiful thing about worktrees is that they let you experiment. They facilitate rapid prototyping—to start working on the next idea without hesitation. With agents, the bottleneck is the amount of tokens you have; code is cheap. The gap between concept and reality has narrowed significantly; it’s never been easier to go from theory to practical.
Worktrees might not be able to help you produce better output, but they do offer freedom to explore. That’s when hesitation becomes a stranger—and attention spans.