When Agents Write Code, Git Becomes the Bottleneck

A coding agent can produce a patch much faster than a person can understand, test, and merge it. That does not mean the agent has made software delivery equally faster. It means the constraint has moved.

This article’s argument is that agent-assisted teams should measure success at the point where a change is safely integrated, not where code generation ends. The available evidence does not yet show how many agent pull requests teams can absorb, how often those changes conflict, or whether new source-control systems outperform established Git workflows. What it does offer is a useful combination: established branching principles and a recent signal that coding-agent companies are investing in code-storage and review infrastructure. [S1][S2]

More branches defer integration; they do not remove it

Martin Fowler describes branching as a way to isolate work while also delaying integration. The longer a branch stays apart from the mainline, the more opportunity there is for the two to diverge and the harder reconciliation can become. Frequent mainline integration keeps that gap smaller. [S2]

Now consider a hypothetical agent working on several backlog items at once. It could create separate branches that each look reasonable in isolation. If those branches touch a shared interface, configuration, or dependency, accepting one can change the assumptions under which the others were written. The agent may have finished generating every patch, but the team has not finished integrating them.

The number of possible interactions also grows faster than the number of branches. With four concurrent branches, for example, there are six branch pairs that might affect one another. That does not mean all six will conflict. It means branch count alone is a poor measure of useful throughput.

A clean textual merge can still be wrong

Git’s three-way merge compares textual changes; it does not understand the intended behavior of a program. Fowler distinguishes textual conflicts from semantic conflicts: two branches can merge without conflict markers and still produce incorrect behavior. One branch might change a function’s contract while another adds a caller based on the earlier contract. [S2]

That problem becomes especially important when changes arrive quickly. A green textual merge only establishes that Git could combine the files. It does not establish that the combined program builds, passes its tests, preserves an interface, or respects an architectural boundary.

For agent-generated changes, this suggests a simple rule: execution should precede human review whenever practical. Code that has not run against the relevant build and tests is still a proposal. Running it does not prove correctness, but it prevents reviewers from spending attention on failures that automated verification could have exposed first.

An isolated sandbox or worktree is one possible implementation, not a requirement established by these sources. The design goal is more general: preserve a reproducible environment in which a proposed change can be built and tested before it enters the shared review queue.

What OpenAI’s planned Pierre acquisition signals

OpenAI announced an agreement to acquire Pierre Computer Company, subject to customary closing conditions including regulatory approval. OpenAI says it intends to use Pierre’s Git and code-review technology to adapt source-control workflows for teams working with coding agents. [S1]

Pierre develops Code Storage and open-source libraries called Trees, Diffs, and Highlights. OpenAI says those open-source projects will remain open source and that Code Storage will continue operating while planned features are integrated into Codex. [S1]

These are intentions, not completed Codex capabilities or evidence that a new architecture has solved multi-agent integration. The announcement nevertheless identifies the part of the stack that model benchmarks overlook: teams need a way to store, compare, review, and accept concurrent changes. Better code generation cannot make that coordination disappear.

Review the consequence, not every token equally

Line-by-line review remains useful, but it should not carry the entire safety burden. A large diff can be syntactically tidy while hiding a small, high-consequence change. Conversely, a mechanical update may touch many lines without changing business behavior.

A more useful agent-review packet would combine the diff with three kinds of context:

• Intent: What requirement is the change meant to satisfy, and which tests demonstrate it?
• Invariants: Which interfaces, permissions, schemas, and business rules must remain true?
• Consequence: What could happen if the change is wrong, and how easily could it be reversed?

Those are recommendations from this analysis, not claims made by the two sources. They shift review from “Did I read every generated line?” toward “Do the evidence and controls match the risk of this change?”

A practical integration policy for coding agents

Teams experimenting with coding agents can start with four boundaries:

1. Keep unfinished exploration isolated. Let agents iterate in local worktrees or disposable environments rather than filling shared branches with every attempt.
2. Require build and test evidence before review. Attach the commands run, their results, and any relevant environment details to the proposed change.
3. Integrate frequently. Prefer small changes that reconcile with the mainline often, consistent with the branching principles Fowler describes. [S2]
4. Escalate by consequence. Automate checks for routine, reversible work while reserving explicit human approval for security policy, data migrations, core business logic, and other costly-to-reverse changes.

None of these steps eliminates semantic conflicts. They make conflicts and review debt visible earlier, before a queue of individually plausible patches becomes an integration project of its own.

What remains unproven

There is little independent comparative evidence on agent-generated pull-request volume, semantic-conflict rates, review time, or long-term maintenance cost. OpenAI’s announcement is prospective, and Fowler’s analysis concerns established human development practices rather than autonomous agents. [S1][S2]

So “Git becomes the bottleneck” should be read as a design warning, not a measured industry verdict. As agents make code generation cheaper, teams should watch whether integration time, failed builds, reviewer intervention, and reversal rates rise with it. The meaningful competition is not how quickly a model can produce a diff. It is how safely an organization can turn that diff into working software.