OpenAI rewrites its Git backend: lessons for your SMB

OpenAI has detailed how it built a new Git backend for its monorepo. The project, dubbed Pando, stems from a very specific problem: its traditional Git infrastructure was falling short given the volume of commits generated by its developers and, above all, by its code agents. According to the company, quarterly commits to its monorepo will have grown more than 2,400% by the end of this year compared with the first quarter of 2024. And its previous backend had dropped below 90% reliability, with slow fetches and failed merges.

OpenAI's decision was not to abandon Git, but to rewrite the way it is served. The team asked itself whether they had reached a limit of Git itself or of how they served their monorepo. The answer: the Git client and protocol were not the problem, but rather the architecture of conventional Git servers. Pando maintains compatibility with Git, something they cared about because they have spent more than two decades building tools around that ecosystem.

What Pando changes compared with a standard Git server

Pando eliminates two assumptions that almost all Git servers treat as mandatory. The first is keeping all branches of the repository in a consistent state at the same time. The second is generating a custom packfile for each client that performs a fetch. In Git, a branch is a pointer to the latest commit, and moving that pointer is the only part of a push that requires coordination. Conventional servers order those updates across the entire repository, so a push to an agent's branch can end up waiting for another. Pando, by contrast, manages each branch separately, so pushes to unrelated branches do not block each other.

The tradeoff OpenAI accepts is that a client looking at several branches at once may see them at slightly different instants. In practice, they argue, both people and agents only care about the order of updates within the same branch. When pushing, Pando validates the incoming packfile while transmitting it to blob storage, without unpacking it into a local repository. It records the new branch tip, the packfile location and its dependencies in a metadata store. By default, it only advertises the trunk branch as the base for feature branch pushes, which makes each pack reusable by other clients that already have that history.

On reads, Pando selects the stored packs each client needs based on the history it already has and returns download links via packfile-uri, a Git protocol feature that allows packs to be downloaded separately. A caching service called Express serves them from regional caches with a hit rate above 99%, according to the company. On standard cloud virtual machines, clones and fetches can saturate a 10 Gbps network link. Background workers merge small packs into larger ones over time, in a way similar to how a log-structured database compacts its data.

Why this matters to an SMB

It may seem like a hyperscale problem, but the trend affects us sooner than it seems. OpenAI built Pando in Rust in 10 weeks, with one engineer designing the core and Codex agent teams implementing it, and it went into production in April. You don't need to be OpenAI to notice that code agents multiply commits. If your team starts using assistants that open branches and push automatically, the bottleneck can appear sooner than expected.

For an SMB or a mid-sized IT team, the lessons are more about hygiene than extreme engineering:

• Measure before optimizing. If clone, fetch or push times degrade, check whether the problem is the network, the repository size or the number of active branches. Don't assume Git is to blame.
• Control branch proliferation. Agents tend to create ephemeral branches. A cleanup policy and clear naming prevent the server from having to advertise thousands of references.
• Evaluate monorepos with judgment. A monorepo makes consistency easier, but it requires packaging and caching discipline. If your team is small, you may not need a monorepo, but you do need a well-tuned continuous integration flow.
• Review AI code review. When agents generate commits, human and automated verification becomes critical. At ForgeNEX we have already discussed AI code review: verify agents, people decide, and this case reinforces it.
• Don't rule out managed infrastructure. GitHub is also investing in improving its infrastructure. For many SMBs, the sensible option is to rely on a provider that is already solving these problems, instead of setting up your own backend.

Our recommendation from ForgeNEX

The news confirms a trend: generative AI is changing not only what we write, but how we version it. If you are introducing agents into your development cycle, start by measuring the impact on your repository and your pipelines. Set branch limits, automate cleanup and review your token and compute bill. As we discussed in Hybrid AI: the PC with agents curbs the token bill, not everything should go to the cloud without control.

Pando is not a tool you are going to install tomorrow at your SMB, but it is a signal of where agent-assisted development is heading. Keep Git compatible, measure the latency of your operations and don't let the convenience of agents create an unmanageable monorepo for you. Infrastructure is designed too.

Source: The New Stack. Analysis and adaptation: ForgeNEX.