Guide · Agent orchestration
Stop AI Coding Agents from Overwriting Each Other
Use clear file ownership, separate workspaces, and one integration step when several coding agents work on the same project.
Two agents can each make a reasonable edit and still leave the project broken. One changes a shared type while another builds against the old version. One formats a file while another replaces a section. The problem is often ownership: both workers believe they are responsible for the same surface.
Assign a patch boundary before editing
Consider a hypothetical settings-page change. One worker owns the interface and another owns the persistence layer. Before they start, agree on the request shape, response shape, and error behavior. Put that agreement somewhere both workers can read, and name the person or coordinator who can approve a change to it.
List shared files explicitly. A schema, route registry, package file, or global stylesheet can affect several assignments at once. Give one worker responsibility for each shared edit. Other workers can propose changes or report a dependency instead of silently making their own versions.
The assignment should also say what to do when the work crosses its boundary. A UI worker that discovers a missing backend field can return the need with an example. It should not have to choose between ignoring the problem and taking over a sibling's task.
Separate workspaces, then integrate deliberately
Separate Git worktrees or checkouts can prevent workers from directly overwriting the same working file. They do not solve disagreements about behavior. Two patches may apply cleanly while using different field meanings or incompatible assumptions about error handling.
Keep a source revision with each assignment. When a worker finishes, ask for the patch, the checks it performed, and any shared decisions it relied on. Integrate one accepted result at a time, then check the combined behavior. A passing test in an isolated checkout is evidence about that checkout, not automatic evidence about the merged project.
Avoid merging large batches of unrelated edits at the end of a long run. Smaller integration steps make it easier to identify which assumption changed when something stops working. Keep unrelated work outside the patch so the reviewer can understand what the assignment actually produced.
Handle a collision without losing work
If workers collide, preserve both versions before resolving the conflict. Read the original requirement and inspect the intended behavior of each patch. Choosing the newest file wholesale can discard a valid fix that happened to finish earlier.
After resolution, tell the affected workers which interface or artifact is now authoritative. Otherwise, a still-running worker may restore an older assumption in its next edit. Mark obsolete assignments or results so they cannot be accepted later by mistake.
Record the cause of the collision in the workflow notes. If it came from a shared file that was never assigned, fix the ownership rule. If it came from an interface that kept changing, settle that decision earlier next time. Those changes will help more than simply telling every agent to be careful.