How to Run Many AI Coding Agents on One Codebase

One AI coding agent is useful. Five of them working at the same time can get a lot more done in an afternoon. But there is a catch: if two of them change the same file, one of them will quietly undo the other.

This post shows a simple way to avoid that. It takes a little planning.

Why agents get in each other’s way

Picture a shared Google Doc where five people are all rewriting the same paragraph. Everyone is working hard. The result is a mess.

AI agents do the same thing, only faster. Each one starts editing without knowing another is in the same file. When both finish, you get one of three outcomes:

1. One agent’s work overwrites the other’s, and nobody tells you.
2. Both changes are saved, but they don’t fit together, and the code breaks.
3. You spend your evening sorting out which change should win.

You can keep all five agents running. Just give each one its own space.

The kitchen analogy

Think of a restaurant kitchen. One cook does the salads. One does the grill. One does the desserts. They share a kitchen, but each one has a station, and nobody reaches into someone else’s pan.

A codebase works the same way. It already has “stations”: the login code, the payment code, the settings page, the tests for each of those. Your job is to hand each agent one station.

Step 1: Split the work into areas

Before you start any agent, write down the pieces of the job. For each piece, ask: which files will this touch?

Example: you want to add a “dark mode” setting.

• Area A: the settings page (the toggle).
• Area B: the colour styles used across the app.
• Area C: saving the choice to the user’s profile.

Three different places in the code, so three agents can work at once.

A bad example: “fix all the typos” and “rename the Save button” touch the same screen files. Give both to one agent, one after the other.

If you can’t say in one sentence which files a job will touch, it is probably too big. Cut it smaller.

Step 2: One agent per area

Once the areas are clear, give each agent exactly one. Tell it in plain words which folders or files are its own and which are off limits.

It also helps to give each agent its own copy of the project folder to work in. Then even a mistake stays in that copy until you decide to bring it back into the main project. Version control tools such as Git support this directly, so you don’t have to invent anything.

An agent that stays inside its area can only break its own corner.

Step 3: Claim first, then work

Plans only go so far. Halfway through, an agent may find it needs a shared file. A technique that handles this: claim before you edit.

Before an agent starts on an area, it claims it. If the area is already claimed by another agent, the claim is refused, and the agent picks the next free area instead of waiting or forcing its way in. When an agent finishes, it lets go of the claim, and the area is free again.

It’s a sign-up sheet for a meeting room: if the 2 o’clock slot has a name on it, you take 3 o’clock.

On the Ayut website there is a small map of a repository on the Features page. Agents claim areas of it, and when two want the same one, the second is sent to a free area. That map is an illustrative simulation, made to show the technique. It is not a live view of your code.

Step 4: Spot clashes early

Some jobs overlap anyway. A clash found in the first ten minutes costs almost nothing. One found after five agents finish costs the evening.

A few habits help:

• Check the list of files each agent has changed so far. If two agents show the same file, stop one of them now.
• Bring finished work back often, in small pieces. Small changes are easy to combine. Big ones are not.
• Let a second pair of eyes review each piece before it joins the main project. That can be you, or another agent whose only job is to review.
• Give shared files to one agent at a time. Settings, routes and main menus are good examples.

Step 5: Keep the work visible

The more agents you run, the harder it is to remember who is doing what. Keep one place where you can see it all: each agent, its area, what it’s working on, and whether it’s waiting for you.

A plain list works. A tool built for it works better. Keeping it all in your head does not.

A short checklist

1. List the pieces of the job and the files each will touch.
2. If two pieces share files, run them one after the other.
3. Give each agent one area and its own working copy.
4. Have agents claim an area before editing.
5. Check changed files often and review small pieces.

How Ayut approaches this

Ayut is built around this idea: many agents, one project, you in charge. Agents work in separate lanes, you can see every lane in one place, and you decide what happens next.

Watching your agents and approving their work from a browser works today. Running Ayut on a desktop host or on your own server is a preview. The “no collisions” map on the Features page is a simulation that shows the claiming technique; it is not a promise about what will happen in your repository, so keep reviewing the work.

If you want to see how it feels, you can Open Ayut.