Run several coding agents on one repo without conflicts

One coding agent at a time is slow when there are five things to do, so the obvious move is to start a few side by side: one on the checkout bug, one on the new settings page, one on the tests. It works until two of them change the same function in different ways, and someone has to untangle it.

This guide covers why that happens, what the usual fixes do and don't solve, and how Gaitro keeps several agents in one project out of each other's way.

Why agents collide

They share files. Two agents in one folder edit the same files on disk, and one's changes can vanish under the other's next save. Neither notices; both report success.

They don't know about each other. Give each agent its own copy and the files stop clashing, but neither knows what the other is doing. Both find the same untidy function, and both tidy it.

The collision shows up late. With a branch each, you find out at merge time, as a conflict in a file. By then each agent has built more on its own version, and the fix is to pick one and redo the other.

Files are the wrong size. Two agents can safely change different functions in one file. They can't safely change the same function, or change what a function takes while another agent adds code that calls it. Merge tools only see lines.

What people try first

Approach	What it fixes	What it doesn't
A separate copy or git worktree per agent	Agents stop overwriting each other's files	Neither knows what the other is changing, so overlaps surface at merge
Splitting the work by folder: one agent on the API, one on the pages	Most overlaps, while each task stays in its lane	Tasks that cross the line, and shared files like config and types
Small changes, merged often	Shrinks the window for a collision	Doesn't close it, and someone still has to review every merge
A file listing who's doing what, which the agents read	Agents can see what's taken, if they remember to look	Agents forget to read or update it, and it works by file at best

Each of these helps. What they're reaching for is the same: every agent should know, while it works, what the others are changing, by function rather than by file, with a rule for who goes first.

How Gaitro does it

Gaitro is a code repository built for this. Each request becomes a draft, and the code a draft changes is reserved for it.

1. One working copy per agent. Each agent works in its own folder: run gaitro clone <company>/<project> <folder> once for each agent you'll run at the same time. Each agent then opens a draft for its task with gaitro start "<the request>".
2. What an agent edits is reserved as it saves. A function, route, database table, config key, CSS rule or doc heading, not a whole file, so two agents can work in one file as long as they change different things in it. Nobody has to remember to reserve anything first.
3. The second agent waits its turn. When an agent edits something another draft is already changing, it hears about it within seconds and its draft waits: the code becomes its own when the other draft ships or lets go, and it can't ship before then. Meanwhile it can leave that code alone, take its edit out, or ask for it with gaitro claim <symbol> --ask "<why>".
4. Changing what others use counts too. A change to what a function takes or returns, or to a table's columns, is weighed against the drafts that use it. If another draft relies on the old version, the change waits for that draft as well.
5. You can see it. The project page shows each open draft and the files it's changing, updating as agents work, and marks a file two drafts are both changing.
6. Checks run on the combined result. Before a draft ships, the project's checks run on it merged with the live version, so two changes that are fine on their own can't break the project together. If the live version moved under a draft, gaitro replay re-applies it there; if two finished changes really do overlap, a person picks between them side by side.

Nothing ships until a person says so: an agent runs gaitro ship only when you tell it to, or you press Ship it on the draft.

Setting it up

1. Sign up, install the CLI and log in (Get started).
2. Bring your project in by running gaitro init in its folder (Already building?), or start a new one.
3. Connect your agents: Claude Code, Codex, Cursor or anything with a command line (Connect your agent).
4. Clone a working copy for each agent, and give each one its task.

Each agent reads GAITRO.md in the project, which tells it the workflow, so there's nothing to explain to them.

Questions

Can two agents edit the same file? Yes. Reservations are for functions, routes, tables and the like, so agents only wait for each other when they change the same thing.

Do the agents have to be the same kind? No. Claude Code, Codex and Cursor can work in one project at once; each just needs to be connected to Gaitro.

What if an agent ignores a wait? Its draft can't ship while it's waiting, whatever the agent does, and the draft shows what it's waiting for.

Can people work alongside agents? Yes. A person working through the gaitro CLI has a draft like any agent's, and what they change is reserved the same way.