From Mexico, here’s a problem I didn’t expect to read about this year: coding agents breaking Git. Not Git the tool, but the servers behind it. On November 2, OpenAI published “Scaling Git at OpenAI”, a long engineering post about Pando, a new backend it built for its monorepo because Codex changed how much work runs in parallel.
The authors put it plainly. One engineer now has several changes ready for CI at once, and each push can set several jobs fetching the same commit. Starting around the end of last year, the old systems struggled: slow fetches and pushes, failed merges, and reliability that at times fell below 90%.
What Pando changes
Pando keeps the Git protocol and client, so engineers and agents still run a normal git push. What changes is the server side, and it comes down to two tradeoffs. First, Pando coordinates each branch on its own, so pushes to unrelated branches don’t wait on each other. The cost is that a reader looking at several branches can see them at different points in time. OpenAI’s argument is that users and agents care about the order of updates to one branch, not a global order across the repo.
Second, instead of building a custom packfile for every client, Pando stores the packs it receives on push and serves those same packs on fetch, from regional caches. A client may download a few objects it already has, but the server barely has to compute anything. In the background, small packs get combined into bigger ones, a bit like compaction in a log-structured database, so a client that’s far behind doesn’t need thousands of tiny files.
The numbers, and who reports them
All of these come from OpenAI’s own post, not an independent test. OpenAI says Pando cut median push latency by nearly 5x (nearly 80%), improved merge reliability, delivers close to a petabyte of Git data per day, and once served more than 57 terabytes of packs in a single hour with over 99% of bytes from local disk cache. The interactive simulation in the post is labeled as a teaching model, not a production benchmark. Pando itself runs inside OpenAI; the post says the company is “exploring ways to share the technology” with users, but doesn’t say how or when. The New Stack has a good walkthrough of the per-branch design.
Built with the agents that caused the problem
The part I keep thinking about is how it was built. OpenAI says Pando went from kick-off to production in 10 weeks with Codex: one engineer designed the core, teams of agents implemented it, and a handful of engineers deployed it. It’s written in Rust, with a conformance test suite so agents could check their changes against standard Git behavior, plus deterministic simulation testing to catch race conditions. They also say agents wrote Lean and TLA+ specs to find bugs and prove properties of the system. It started as a read- and write-through proxy in front of the old system, so traffic could move over without downtime, and Codex skills helped teams migrate their own checkouts.
What I take from it
- If your team runs agents in parallel, watch your Git host and CI fetch load, not just token bills. More branches and more fetches add up fast.
- Agents that push many small branches against trunk fit this design well. Stacked branches and repeated pushes to one branch cost more bandwidth here, and OpenAI says so.
- The guardrails are the real lesson: a conformance suite and simulation tests are what let agents write infrastructure this sensitive.
- Some client improvements are already upstream in Git, and OpenAI keeps a public patch tracker, so regular Git users may benefit even without Pando.
Most agent news is about what the agent can do. This is about what breaks around it once it works. I think more teams will hit these limits sooner than they expect.
Sources: OpenAI, “Scaling Git at OpenAI,” November 2, 2026; The New Stack, “OpenAI built itself a new Git backend, too”. Hero image: Bare branches against a white sky, Quebec City by Wilfredor, Wikimedia Commons, CC0; cropped and resized.
