---
title: "Is OpenAI Replacing Git? What Agent-Scale Coding Breaks"
url: "https://goremy.ai/blog/articles/openai-agents-replace-git-codex-engineering"
author: Luis Chavez-Mattos
editor: Luis Chavez-Mattos
editor_title: Director, Product
published: "2026-11-10T10:40:14.269Z"
updated: "2026-11-10T16:58:58.363Z"
topic: AI Coding Tools
description: "OpenAI's Vijay Raji says agent-generated code overwhelmed Git in its monorepo. Here is what broke, what the new system changes, and where review and CI strain."
---

# Is OpenAI Replacing Git? What Agent-Scale Coding Breaks

> OpenAI's Vijay Raji says agent-generated code overwhelmed Git in its monorepo. Here is what broke, what the new system changes, and where review and CI strain.

Edited by Luis Chavez-Mattos, Director, Product · Published 2026-11-10

## Is OpenAI replacing Git?

Inside the company, yes. Vijay Raji, CTO of Applications at OpenAI, says the volume of code flowing through OpenAI's monorepo grew past what its repository system was built to handle, so an internal team built a replacement with different assumptions. Git was designed around offline developers who work on local branches and push later. Agents are online all the time. Raji says all of OpenAI's engineers now work on top of the new system. He did not say it is a public product.

## TL;DR

- OpenAI says its monorepo traffic grew **more than an order of magnitude** beyond what the old system was designed to support.
- Raji describes Git as built for **offline, branch-then-push workflows**, which is a poor fit for agents that are always connected.
- The new internal system targets roughly **two orders of magnitude more throughput**, according to Raji, and now backs the whole monorepo.
- Early bottlenecks included **sparse checkout** and the need for **caches** so agents stop hammering main.
- Cheap code moves the pain downstream to **code review, CI/CD, testing and instrumentation**.
- Raji says frontier-lab token usage grew **17x in a year**, versus about 2x at typical software shops. He calls token usage a rough proxy, not a productivity measure.

## What changed at OpenAI to cause this?

Raji points to February 2026 as the turning point. Stronger models combined with Codex, which runs multiple agents in parallel using work trees, led to a sharp rise in pull requests from engineers. Agents also pull code regularly, run tests, and push back to main.

He is careful about the 17x figure. Token usage is one-dimensional, he says, but it shows how broad and deep AI use is across a team. Frontier labs saw about 17x growth over the past year. Typical software shops saw about 2x. His explanation is that teams that find good ways to use the tools get much more productive, much like moving from Emacs to an IDE.

## Why does Git struggle with coding agents?

Git's core model assumes a person checks out code, works locally across several branches, and pushes when finished. Raji says most of its concepts rest on that offline story.

Agents break that assumption in a few ways:

- They are connected continuously, so there is no long offline stretch to absorb sync costs.
- Many run at once, each checking out code and pushing results.
- They pull and push on a regular cadence, so traffic into and out of a single monorepo multiplies.

Raji says the amount of code moving in and out went over an order of magnitude past what the existing setup was designed for. That is a statement about OpenAI's monorepo and its specific infrastructure, not a claim that Git fails for every team. Most teams are nowhere near this load.

## What does the replacement system do differently?

Raji shared design assumptions, not implementation details. A team was set up internally to solve the problem "with fundamentally different assumptions." The goal was a repository built for an always-online, agentic workflow, with about two orders of magnitude more capability and throughput than before.

Two problems stood out when the team profiled the system.

**Checkout throughput.** Raji says collisions on main are a real problem, but not the biggest one. If you are not locking on main, the transactions themselves can run at high throughput. The harder issue is how fast agents can check out code. That means solving sparse checkout first, so an agent only fetches the part of the monorepo it needs.

**Caching.** He says caches are needed across the board so agents can pull from them instead of constantly hitting main.

The migration was also hard in its own way. Raji describes keeping existing systems running for demanding internal engineers while moving them to the new one, which he compares to swapping out a scaled system for another scaled system.

## What breaks downstream when code gets cheap?

The repository was one bottleneck. Raji frames it as a second or third order effect of making code faster to write.

When coding was the long pole, teams spent a lot of conversation up front. Now people generate many more prototypes, and more code gets thrown away than before. At the same time, AI-assisted engineers are putting up far more code (he cites 5x as an example), which raises uncomfortable questions:

1. How do you review that much code?
2. How do CI and CD keep up?
3. How do testing and instrumentation scale with it?

OpenAI's answers so far are an auto-review system that teams can turn on, and a rethink of its CI/CD infrastructure. Raji says CI/CD, along with review, testing and instrumentation, becomes a bottleneck when output jumps. He gave no numbers on either fix.

## How did OpenAI organize the fix?

The interviewer noted that the team was given a mission, not a method. Raji agreed that this is typical. The problem was a side effect of internal AI adoption, nobody knew the solution, and a dedicated team was told to go solve it. Raji also notes that internal engineers are the company's "hardest customers," which raised the bar for a migration that could not interrupt daily work.

## Does this matter if you are not OpenAI?

Probably in a smaller form. Your repository may not buckle, but the pattern Raji describes will likely show up at any scale where agents write code:

| Pressure point | What Raji described | What to watch in your own setup |
|---|---|---|
| Repo access | Sparse checkout and caching needed for agent traffic | Slow clones, fetch load on your main remote |
| Merge flow | Collisions on main are real but solvable | Frequent rebases, queue backups |
| Review | AI-assisted engineers produce much more code | Review queue age, reviewer fatigue |
| CI/CD | Infrastructure had to be rethought | Build queue times, flaky tests |
| Prototypes | More code is discarded | Wasted CI runs on throwaway branches |

Raji also described using Codex himself to prototype a voice-first ChatGPT experience before taking it to his team. That is a useful hint at where extra load comes from: leaders and non-specialists now generate code too.

## What are the limits of this account?

This comes from one interview. The new system has no public name or documentation in the source, and the performance claims ("two orders of magnitude") are Raji's own characterization. Treat the lessons about bottlenecks as more reliable than any specific number.

## Frequently Asked Questions

### Did OpenAI really replace Git?

According to Raji, OpenAI built an internal repository system that supports its entire monorepo, and all its engineers use it. He presented it as a replacement for the system they had, designed for always-online agents. It is not described as a released product.

### Why can't Git handle coding agents at that scale?

Raji says Git's model assumes offline work with local branches and a push at the end. Agents are online constantly and push and pull often, which drove traffic more than an order of magnitude beyond what the existing setup supported.

### What is sparse checkout and why does it matter here?

Sparse checkout lets a client fetch only part of a large repository. Raji says the throughput of agents checking out code is a major problem in a monorepo, so solving sparse checkout comes first, along with caches that keep agents from constantly hitting main.

### What is the 17x token usage number?

Raji says token usage at frontier labs grew 17x over the last year, compared with about 2x at average software shops. He treats it as a proxy for how broadly and deeply AI is used, not a direct measure of engineer productivity.

### Which parts of the pipeline break first when agents write more code?

Beyond the repository, Raji names code review, CI/CD, testing and instrumentation. OpenAI responded with an optional auto-review system and a redesign of its CI/CD infrastructure.
