Many agents, one codebase, at once.
Teams now run several autonomous coding agents in parallel, each making changes as fast as it can think. The hard part is no longer writing the code. It is keeping one shared codebase consistent while concurrent, adaptive agents all write to it at high velocity. That is a distributed-systems problem, and most of the clashes it creates are invisible to git.
of AI agent pull requests are open at the same time as another agent’s, across 33,596 agent pull requests on GitHub. Xu et al., 2026
overlapping agent pull requests stop with a conflict when git merges them, from our replay of 733 real pairs on public projects. How we measured
The textual conflicts are the easy half.
When two agents edit the same lines, git stops and tells you. That is the visible quarter above, and a person can resolve it. The dangerous clashes are the ones git merges without complaint: two changes that each pass their own tests, touch different lines, and are incompatible in meaning. One agent widens a shared type. Another writes new code against the old shape. Both compile. Both merge clean. The build breaks on main, and nothing in the merge pointed at why.
This is a semantic conflict, not a textual one. Textual merge, which is all git performs, resolves character ranges. It has no model of what a function returns, which callers depend on a field, or what a type now requires. As the number of concurrent agents grows, the share of clashes that are semantic grows with it, because independent agents generate changes that are locally correct and globally incompatible.
Why velocity makes it worse.
A single developer serializes their own work: they finish a change, then start the next. A fleet of agents does the opposite. They write in parallel, continuously, against a codebase that is moving under each of them. The write velocity to shared code rises with every agent you add, and so does the chance that two in-flight changes depend on the same thing. Past a few agents, coordination, not raw output, is the bottleneck, and the failure mode is a codebase that is individually green and collectively broken.
What gitta does about it.
gitta treats this as the coordination and consistency problem it is. It gives each agent the one thing a parallel worker needs and a diff cannot provide: the news that something its work relies on has changed, at its next step, so the agent adapts while the change is still small. That keeps the agents adaptive instead of blind to each other.
Then, at the point of integration, gitta runs your own tests on the combined work inside the git merge, and a merge that fails stops before main changes. Textual or semantic, a clash that two changes create together is caught when they meet, not after a build window fails. It is the same guarantee a distributed system wants under concurrent writes: no writer lands work that leaves the shared state inconsistent.