Somewhere in the first quarter of 2026, git worktrees became load-bearing for AI coding. As soon as two agents edit the same repository for more than ten minutes, a single working directory stops working. They race each other on lockfiles, run tests against each other's half-written code, and overwrite work between runs.
Why one directory cannot hold two agents
It is not a subtle failure. Both agents need the same files to be in the same state, and neither of them knows the other exists. One installs a dependency while the other is mid-edit, the lockfile changes under a running test, and the results describe a codebase that never existed on disk. Add you, typing in the same folder, and the state space gets worse fast.
Git worktrees solve it without duplication. A worktree is a second directory checked out to a different branch, sharing the one .git object database. History, remotes and objects are shared, so you are not cloning, and each agent gets a directory it can trash freely.
Image goes here
/blog/parallel-coding-agents-worktree-layout.png
Directory layout showing one repository with several worktrees on separate branches
Show generation prompt
Editorial technical diagram, 16:9, flat vector. A stylized directory tree abstracted as nested rounded rectangles: one parent directory at the top-left, three child worktree directories branching to the right at staggered depths, each labeled by a small folder icon and connected back to a single shared object-database cylinder. Charcoal (#121212) background, grey (#8c8c8c) outlines, the shared-connection lines in indigo (#5560d4), ordered-dither dot texture in the background, generous negative space. Mood: filesystem-level, clear. No readable text, no logos, no watermark.
What makes a parallel run behave
- A worktree per task, not per agent. Give each thread its own directory and its own branch, and merging becomes a normal review instead of a conflict resolution exercise.
- Reads parallel, writes serialize. Consecutive read-only calls can be dispatched together because they cannot affect each other. Writes keep the model's order so the sequence it reasoned about is the sequence that happens.
- A session-wide terminal lock. Two threads sharing one shell will interleave output. Sequentializing the shell preserves audit order without blocking anything else.
- Collision detection before writing. If you are not going to force isolation, you need at least to notice when two threads touch the same file, ideally comparing what each one last read against what the other wants to write.
- Port collision awareness. Two agents each starting a dev server on the same port is the most common parallel failure, and it is invisible to anything that only watches the filesystem.
That fourth point is the one worth arguing about. Isolation is clean but rigid: two threads cannot share a finding or split one investigation across two models. Collision detection lets them, at the cost of needing a reliable way to know when they are about to conflict.
The fork problem
The interesting version of this is forking one task into several approaches at once. Three models, same starting state, same budget, pick the patch that survives. It works only if the divergence is clean: the fork must happen from a snapshot rather than from live state, each child needs its own directory, and the comparison has to be against the same inputs or the comparison is meaningless.
This is also where benchmarks stop being abstract. Running the same task across several models in parallel is the cheapest honest way to find out which one suits your repository, which is the argument for measuring against your own history rather than a public leaderboard.
How Quaka isolates a run
Threads get isolated by worktree. When a task needs a worktree, Quaka creates one under the application's own storage directory, with a branch that names the task, and cleans it up when the task ends. It never stages, commits, or runs destructive git inside the user's primary repository while setting one up.
- Each thread owns its directory. Threads read and write in isolation by default, so parallel runs do not share a working copy.
- Concurrent threads are capped. A limit keeps fan-out from turning into a resource problem on your own machine.
- A collision guard watches the original repository. When two threads touch the same path, one is paused and asked rather than both racing.
- History stays shared. Worktrees share the object database, so a fork or a merge is cheap and the provenance of each change is still readable.
Parallel runs multiply the review problem too. When three threads have each written a branch, the diff a human reads has to make clear which step produced which hunk, which is the argument for verified completion over a confident summary.
Get an invite
Quaka is in private beta.
One email when your invite is ready. macOS, Windows and Linux, bring your own key.
Read the source on GitHubCommon questions
Can two AI coding agents work on the same repository at once?
Not safely in one working directory. Within minutes they race on lockfiles, run tests against each other's unfinished edits and overwrite work. Give each agent its own git worktree on its own branch, sharing the object database, and they can run in parallel with normal merging afterwards.
What is a git worktree in simple terms?
A second working directory attached to the same repository, checked out to a different branch. You get a separate set of files to edit while history, remotes and objects stay shared, so there is no second clone and no extra disk cost for the objects.
How do I stop parallel agents from conflicting?
Either isolate them fully with a worktree each, which is the reliable option, or track file access per thread and pause a run when it wants to write something another thread has read. Most teams do the first and add collision detection for the cases where threads must share state.