Build on what's coming: many AI agents, one codebase
By Soumen Sarkar · October 2026
Several AI agents can work in the same codebase at once without colliding when each one can see what the others are changing, builds against the plan of that work rather than waiting for it, and is told exactly what changed when the work lands.
Here's a common Tuesday. Ana's agent is splitting the checkout into three steps. Ben's agent is adding a coupon box to the checkout. Both pieces of work are good. If neither knows about the other, they meet at merge, and one of them gets thrown away.
The second principle of VibeFlock says: build on what's coming. Unfinished work is a promise, and a promise can be built on. This playbook shows how to run many agents in one codebase so their work fits together the first time.
Why do AI agents collide in a shared codebase?
Because each agent sees the code as it is, not as it's about to be.
An agent reads the files in front of it and builds against them. If a teammate's agent is reshaping those files right now, the first agent is building against something that's about to move. Neither is wrong. They just can't see each other.
At agent pace, the window for this is wide open. Dozens of changes land a day, and many touch the same parts of the product.
How can two agents work on dependent changes at the same time?
By making work in progress visible where it lands, with its plan.
- Say what the work will become. When an agent starts something others might touch, it records the goal and the plan in a sentence or two: "Checkout becomes three steps: details, payment, review. Coupons belong in the payment step."
- Tell the next agent before it starts. When Ben's agent opens the checkout, it learns Ana's work is under way, and what it will look like.
- Build against the plan. Ben's agent builds the coupon box for the payment step, so it fits the moment Ana's work lands.
- Hear what actually landed. When Ana's work finishes, everything built on it is told what landed and how it differs from the plan: "It's called the payment stage, and it validates on submit." Ben's agent adjusts in minutes.
Nobody waited. Nobody's progress was held hostage by anybody else's.
What if the plans genuinely clash?
Then both sides should learn it now, before either has finished.
Sometimes two pieces of work can't both be right. One removes a page the other extends, or two agents decide opposite things ("store money as whole cents" and "store money as decimals"). The earlier that's visible, the cheaper it is. Shown side by side, with the reasons, the call takes a minute: keep one, and the other work adjusts that same day.
That's the seventh principle, decide by doing: decisions are recorded as the work happens, and checked against the ones that stand.
How should I organise a team running many agents?
Organise around areas of the code, not around tickets.
- Name your areas. Use names people use, like "Payments" or "Checkout", tied to the folders they cover. Every agent working in an area should be told what's happening there.
- Keep plans short and public. One or two sentences per piece of work is enough for others to build against.
- Let dependencies close themselves. When work depends on something unfinished, record the dependency once. Don't repeat it every day. When the other work lands, the dependent work is told.
- Look at one page. People should see work in progress, handoffs and anything that needs them in one place, not across five tools.
How does Campfyrr help?
Campfyrr makes work in progress visible to every agent automatically:
- When an agent first touches an area, it's told what's being changed there right now, with each piece of work's goal, plan and expected date.
- start_work records what a piece of work is for and what it will become.
- wait_on links work to something unfinished. When that work lands, the waiting work hears what landed and what changed from the plan.
- Clashing decisions are caught the moment the second is made. The newer call stands, the earlier one is marked replaced, and the change shows on the Activity page.
In short
Many agents can share one codebase when they build on what's coming instead of what's finished. Make plans visible where work lands, build against them, and hear exactly what changed when the work arrives. Unfinished work is a promise, and a promise can be built on.
Add Campfyrr to Claude at https://campfyrr.vercel.app/connect. It takes two minutes. It's free during early access, then $9 per developer a month for teams. Read the seven principles at https://campfyrr.vercel.app/vibeflock.