Guide
AI coding agents and merge conflicts: how to prevent them
In shortTeams of AI coding agents hit merge conflicts and broken builds because each agent sees only its own checkout and conversation. Two agents edit the same file at once, or one changes a function another is about to call. Worktrees and branches delay the problem to merge time. Preventing it needs two things before the edit happens: a short lock per file so edits take turns, and shared context so each agent knows what the others are changing.
The new kind of conflict
Merge conflicts are as old as version control. Coding agents change two things about them.
First, the volume. An agent can change a dozen files in a minute, and a team where each person runs one or two agents produces far more concurrent edits than the same team typing by hand.
Second, the blindness. A person working next to a teammate hears "I'm renaming the session helpers" at standup. An agent hears nothing. It reads the code as it is on disk when it starts and writes against that version, however long its task runs.
Three ways agents collide
Two agents, one file, the same minute
Ana's agent and Bea's agent both edit src/session.ts. Each reads the file, changes it in memory and writes it back. The second write replaces the first. If both work in the same checkout, Ana's change is simply gone. In separate checkouts, it becomes a merge conflict later.
One agent changes what another depends on
Ana's agent renames getUser to fetchUser, updating every caller it can find. A minute later Bea's agent writes a new file, src/handlers/invoices.ts, that calls getUser. There is no conflict for git to find, because the two agents never touched the same file. Both report success. The build breaks after the merge.
This is the harder case, and the more common one as agents take on larger tasks. A lock on files cannot catch it.
Nobody knows what is running
Without a shared view, people find out about overlapping work from conflict markers and failed CI runs. By then the agents' context is gone and a person has to work out what each one meant.
What does not fix it
Branches and worktrees per agent. They keep agents from overwriting each other on disk, which is useful. But every branch still has to merge, and the two collisions above simply move to merge time. See Lanes vs git worktrees.
Telling agents to pull often. A pull brings in pushed work only, and an agent pulling mid-task can lose track of its own changes.
Plain file locks. A lock that refuses an edit makes the agent stop. In Lanes' early tests, 4 of 13 agents whose edit was refused stopped and asked their human what to do. A lock also cannot catch a rename in another file.
What prevents it
Prevention has to happen before the edit, while the agent can still change course.
- Make edits to one file take turns. A lease that lasts one edit means a second agent waits about a second instead of overwriting. It must never refuse the edit, or agents stop and ask.
- Sync before the waiting agent edits. When the lease is handed over, bring the first agent's change into the second agent's checkout, so it edits the current version.
- Share what each agent is working on. Give every agent a short brief at each prompt: teammates' tasks and the files they touch.
- Warn before a stale read or edit. When an agent is about to read or edit a file a teammate is changing, tell it who and what, and ask it to write code that matches the change.
- Publish small and often. Commit and push each edit to a shared branch, so the next agent starts from it.
How Lanes does it
Lanes is a free, open-source tool that does these five steps for Claude Code, Codex, Cursor, Gemini CLI and 15 more agents. Its hooks take a one-edit lease and queue behind a teammate's agent, sync the file, then commit the edit as the person and push it to lanes/main on your own remote. With lanes team on, each agent also gets the brief and the heads-ups.
In the rename scenario above, file locks alone broke the build in 6 of 13 runs. With Lanes' shared context, 0 of 10. The benchmark page has every run.
lanes init --agents claude,codex,cursor
lanes team onQuestions
Do git worktrees prevent merge conflicts between agents?
No. Worktrees stop agents from writing over each other's files on disk, because each has its own copy. The edits still meet at merge time, and a conflict or a broken build shows up then, after both agents have finished.
Can I just tell my agent to pull before editing?
It helps a little. The agent still cannot know what a teammate's agent is about to change in the next minute, and pulling in the middle of a task can confuse it. A pull also does nothing about a change that is not pushed yet.
How often does this happen?
In Lanes' benchmark, when one agent renamed a function while another wrote a new caller in a different file, the build broke in 6 of 13 runs with file locks alone. With shared context it broke in none of 10.