Quando os agentes de código de uma empresa começam a abrir branches e a rodar tarefas em paralelo em escala, a parte silenciosa da cadeia de ferramentas em que ninguém pensa, o controle de versões, vira o que quebra. A OpenAI diz que foi exatamente isso que aconteceu com o seu próprio serviço de Git, e sua resposta foi construir um novo backend do zero. O sinal útil aqui não é a ferramenta em si, mas o padrão de carga, que qualquer equipe que amplie o uso de agentes vai encontrar na sua própria integração contínua e controle de versões.
A pressão veio do Codex, que permitiu aos engenheiros da OpenAI fazer muito mais trabalho ao mesmo tempo: mais branches, mais pushes, mais fetches de ambientes de desenvolvimento, tarefas de pesquisa e CI. A partir do fim do ano passado, os sistemas por trás do seu monorepo sofreram, com a confiabilidade às vezes caindo abaixo de 90%, ou seja, pushes e merges lentos ou falhos. Em vez de abandonar o Git, a OpenAI manteve o fluxo de trabalho familiar e reconstruiu o backend por baixo, chamando o resultado de Pando. As metas de projeto eram escalar as escritas em muitos branches ao mesmo tempo e servir o mesmo histórico a muitos leitores a partir de cache.
Os resultados relatados são substanciais. O Pando reduziu a latência de um push mediano em quase 80%, e agora serve perto de um petabyte de dados Git por dia, com mais de 57 terabytes em uma única hora e mais de 99% desses bytes vindos do cache de disco local. A OpenAI o construiu em Rust sem dependências legadas, e diz ter ido do início à produção em cerca de 10 semanas, com o próprio Codex e uma mistura de modelos fazendo boa parte do trabalho. Começou a servir tráfego de produção em abril.
A relevância para o resto de nós é o padrão, não o produto. O Pando não é de código aberto, então a maioria das equipes não pode adotá-lo. Só as melhorias do lado do cliente que a OpenAI devolveu ao Git são públicas, por meio do seu próprio fork, o que significa que isso se lê mais como um aviso do que como uma ferramenta: os sistemas em torno do Git foram moldados por duas décadas de fluxos de trabalho humanos, e enxames de agentes os pressionam de formas para as quais essas ferramentas não foram dimensionadas.
As ressalvas honestas são as de sempre em um post de engenharia de um fornecedor. Os números de confiabilidade e latência são da própria OpenAI e não foram verificados de forma independente, e um backend ajustado para um monorepo muito grande pode não se transferir para repositórios menores ou de formato diferente. Ainda assim, à medida que mais equipes apontam agentes para suas bases de código, a lição de que o trabalho paralelo das máquinas pressiona a CI e o controle de versões de formas novas vale levar a sério antes que apareça como merges falhos seus. Nós analisamos o OpenAI Codex, o agente que criou essa carga em primeiro lugar.