Giving a developer more coding agents doesn’t give them more hours to review the output.
It gives them more branches.
That is the interesting thread connecting two announcements from OpenAI last week. Not that Git is suddenly obsolete, or that every team needs a new source-control platform. The systems around our code are being asked to handle a different pattern of work.
Writing the change is becoming easier. Getting several changes safely back together is still engineering.
Same Git, different workload
On 2 November, OpenAI described Pando, its new backend for Git repositories. It keeps compatibility with the Git client and protocol while changing how the server handles concurrent work.
The important choices are surprisingly practical. Updates to unrelated branches can proceed independently. Stored packfiles, the bundles Git uses to transfer repository objects, are reused across downloads rather than freshly assembled for every client.
There are trade-offs. Reading several branches does not guarantee a single repository-wide snapshot. Reusing packs can mean transferring objects a client already has.
OpenAI reports a reduction of nearly 80% in median push latency. That is a result from its own production environment, not a promise for anyone else’s repository.
The lesson is not “Git is broken”. It is that familiar interfaces can survive a substantial change underneath them.
Two days later, OpenAI announced it would acquire Pierre, whose Trees and Diffs libraries already support file browsing and change review in Codex.
The acquisition announcement is about tools around Git, too. The storage, browsing and review experience matters alongside the agent producing the patch.
Most teams don’t need a new Git backend
A small team is unlikely to wake up with OpenAI’s source-control traffic.
It can still wake up with five changes that looked sensible separately and become awkward together.
Imagine one agent updating an API response, another changing the component consuming it, and a third refactoring the shared types. Each task can have a plausible implementation. That does not establish that the combination behaves correctly.
Parallel execution and safe integration are different problems.
Git worktrees help with the first. They let you check out multiple branches into separate working directories while sharing repository data. An agent can work without trampling another task’s uncommitted edits.
They do not resolve disagreements about what the software should do.
Nor does a green check on an isolated branch prove that it will remain green alongside everything else waiting to merge.
Make the return journey explicit
My practical takeaway is to design the route back to main before increasing the number of agents:
- Give each task a boundary. Name the behaviour being changed and what should remain untouched. “Improve this area” is a poor contract for parallel work.
- Keep changes reviewable. Separate the feature from unrelated tidying. A reviewer should be able to explain the purpose of the diff without reconstructing the entire conversation that produced it.
- Test the combination. Check interactions between changes, not just whether each patch passes alone.
- Keep a clear merge owner. Someone must decide whether the result belongs in the product, even when much of the mechanical checking is automated.
For busy repositories, a merge queue can help with that integration step. GitHub’s queue checks changes against the latest target branch and the pull requests ahead of them. It is not a replacement for a useful test suite, and availability depends on repository ownership and plan.
More output isn’t the finish line
A faster push is useful. So is a faster coding agent.
Neither tells you whether the change should ship.
The number I would watch is not how many branches the team can create. It is how reliably those branches become understandable, tested changes without leaving a growing queue for someone else to untangle.
Keep Git. Improve the journey back to main.
Sources
- OpenAI, “Scaling Git at OpenAI”, 2 November 2026: https://openai.com/index/scaling-git-at-openai/
- OpenAI, “OpenAI to acquire Pierre Computer Company, Inc.”, 4 November 2026: https://openai.com/index/openai-to-acquire-pierre/
- Git, git-worktree documentation, current documentation checked 10 November 2026: https://git-scm.com/docs/git-worktree
- GitHub, “Managing a merge queue”, documentation checked 10 November 2026: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue
