OpenAI escala o Git para a Era dos Agentes de IA com o novo backend Pando

A automação da escrita de código por inteligência artificial ultrapassou os limites da infraestrutura tradicional de engenharia de software. Em 2 de novembro de 2026, a OpenAI anunciou oficialmente o Pando, um novo backend de controle de versão construído especificamente para lidar com a carga de trabalho massiva gerada por seus engenheiros e pelos agentes autônomos baseados no modelo Codex. Desenvolvido em um período de apenas 10 semanas pelos membros da equipe técnica Aaron Friel, Taylor Blau e Ted Nyman, o sistema mantém compatibilidade integral com o protocolo e o cliente Git padrão, mas altera radicalmente a forma como os dados são processados e distribuídos nos servidores da empresa.

O Pando foca em resolver dois problemas fundamentais da escalabilidade do Git: a escrita horizontalmente escalável, otimizando pushes simultâneos em múltiplos branches sem bloqueios concorrentes, e a maximização do throughput de leitura, saturando a largura de banda da rede através do uso intensivo de caches de packfiles. A transição para a nova infraestrutura ocorreu sem a necessidade de interrupções no trabalho ou alterações nos fluxos das equipes de desenvolvimento.

Contexto e antecedentes: A crise do monorepo da OpenAI

O desenvolvimento tradicional de software utilizando Git foi concebido nos anos 2000 por Linus Torvalds, inicialmente desenhado para uma comunidade que trocava patches de kernel de sistemas operacionais via e-mail. Antes de 2025, o fluxo de trabalho dentro da OpenAI operava dentro dos limites normais esperados para repositórios de grande porte.

No entanto, a introdução do modelo Codex e a proliferação de agentes de IA mudaram a equação. Um único engenheiro passou a ter múltiplas alterações prontas para integração contínua (CI) simultaneamente, com cada push acionando dezenas de trabalhos paralelos que precisavam realizar o fetch do mesmo commit. A automação multiplicou o tráfego de dados no repositório.

A cronologia do colapso e reconstrução da infraestrutura da OpenAI ocorreu da seguinte forma:

• Pré-2025: O fluxo de desenvolvimento seguia o padrão do setor, suportado pelos backends convencionais de Git.
• Final de 2025: O sistema anterior entrou em colapso devido a gargalos severos. Ocorreram lentidões críticas em fetches e pushes, além de falhas sistêmicas em processos de merge. A confiabilidade do sistema despencou, chegando a cair abaixo de 90% em momentos de pico.
• Q1 2024 a Q4 2026: Registrou-se uma explosão estatística no volume de commits trimestrais, com um salto acumulado de 2.442%.
• Q3 2026: Diante do limite técnico imposto pelo crescimento dos agentes autônomos, a equipe técnica da OpenAI desenvolveu o Pando em uma janela de 10 semanas, substituindo a infraestrutura subjacente.
• 2 de novembro de 2026: A OpenAI torna pública a arquitetura do Pando e os dados de sua implementação.

Arquitetura técnica e dados concretos

O Git tradicional sincroniza repositórios gerenciando "objetos" (blobs, árvores, commits e tags) e "referências" (refs, como branches e tags). Quando múltiplos usuários (ou milhares de agentes de IA) tentam atualizar refs simultaneamente, os sistemas padrão que impõem uma ordem única de gravação através de metodologias como Three-phase commit (3PC) ou Write-ahead logs (WAL) em armazenamento de blobs criam gargalos. Um push acaba esperando o outro, mesmo em branches não relacionados.

O Pando contornou essa limitação arquitetural coordenando atualizações para cada branch de forma totalmente independente. Atualizações em ramificações não relacionadas procedem em paralelo. Para leituras, em vez de gerar um arquivo compactado (packfile) individualmente para cada cliente que solicita dados, o Pando reutiliza packfiles armazenados em cache distribuído (como os Express Caches regionais), servindo os mesmos bytes brutos para múltiplos clientes com custo computacional próximo a zero para o servidor.

Os resultados reportados pela implementação do Pando são absolutos em termos de volume de dados e performance:

• Volume diário: O sistema entrega quase 1 petabyte de dados Git por dia.
• Pico de tráfego: Em um período de alta demanda, o sistema serviu mais de 57 terabytes de dados em apenas uma hora. Mais de 99% desses bytes foram entregues diretamente a partir do cache.
• Confiabilidade: A taxa de sucesso em merges e disponibilidade do sistema subiu dos preocupantes <90% em 2025 para 99,99% atualmente.
• Redução de latência: A latência mediana de push foi reduzida drasticamente. No entanto, existe uma ligeira divergência técnica nas métricas publicadas: enquanto a fonte oficial da OpenAI relata um corte de "quase 5x", análises externas reportam a redução como "quase 80%".

É vital observar que pesquisadores de infraestrutura independentes (como relatado pela Kingy.ai) destacam que todos os números de capacidade e latência são métricas de "primeira mão". Até o presente momento, não houve reprodução independente ou testes de estresse externos que auditem os números divulgados pela OpenAI.

Impacto para o setor, usuários e o mercado latino-americano

A reengenharia do Git pela OpenAI reverbera em múltiplas camadas do ecossistema de tecnologia, criando precedentes para empresas que integram Inteligência Artificial na base de seus processos de engenharia corporativa.

Para os Engenheiros da OpenAI, o impacto é direto e quantificável: o fim dos bloqueios de merge e a aceleração do ciclo de feedback da CI/CD permitem que o trabalho humano acompanhe o ritmo de produção de código gerado por máquinas, sem interrupções por quedas de serviço.

Para os Agentes de IA (Codex), a mudança garante a infraestrutura necessária para a operação contínua. Sem o Pando, os agentes passavam a competir por recursos de rede e locks de banco de dados, resultando em timeouts que anulavam o ganho de produtividade da inteligência artificial. O novo backend viabiliza a execução de "enxames" de agentes autônomos simultâneos testando hipóteses de código em sandboxes isoladas.

No que tange à Comunidade Open Source, o impacto será progressivo. O desenvolvimento da tecnologia expõe a "dívida técnica" histórica do Git frente a cargas de trabalho não-humanas. Como os autores Friel, Blau e Nyman deixaram explícito, a OpenAI planeja extrair as melhorias de performance criadas no cliente interno e enviá-las (upstream) para a árvore oficial do projeto Git.

Para o mercado de software latino-americano, a adoção do Pando serve como um alerta antecipado (early warning). Startups e unicórnios no Brasil, México e Colômbia que estão implementando as chamadas AI coding factories (fábricas de software guiadas por IA) inevitavelmente encontrarão os mesmos gargalos arquiteturais à medida que escalarem as submissões automatizadas de código. Entender como a OpenAI fragmentou a coordenação de refs em atualizações independentes e adotou caching agressivo de packfiles guiará a infraestrutura DevOps dessas companhias nos próximos três anos.

O que ainda não se sabe

Apesar da riqueza de detalhes operacionais do material divulgado pela OpenAI, lacunas substanciais persistem na adoção ampla da tecnologia:

• Licenciamento e Código Aberto: O briefing da OpenAI e a declaração de seus engenheiros focam em enviar patches pontuais de volta ao projeto Git (upstream). Contudo, não está claro se a totalidade do backend Pando será disponibilizada sob uma licença Open Source ou se permanecerá estritamente como uma vantagem competitiva proprietária da infraestrutura interna da empresa.
• Copiar
  Arquitetura Exaustiva: A estrutura interna exata de armazenamento em blobs, o formato das coberturas hierárquicas (hierarchical covers) e a gestão de metadados de push em complexidade O(1) foram descritas em termos matemáticos amplos, mas carecem do detalhamento exaustivo necessário para replicação autônoma por arquitetos de sistemas terceirizados.
• Testes de Terceiros: A verificação empírica da performance do Pando sob cargas de trabalho adversas que não sejam especificamente as do monorepo da OpenAI ainda não foi documentada.

O que esperar a seguir

O cronograma prático para as tecnologias de controle de versão derivado do caso Pando aponta para as seguintes ações concretas nos próximos trimestres de 2027:

• Integração de Patches Upstream: A comunidade Linux e os mantenedores do projeto Git deverão receber pull requests específicos originários do fork interno da OpenAI (ttaylorr/git), com foco imediato na eficiência da negociação de packfiles no protocolo de transferência e otimização da leitura de metadados em complexidade O(log Δ).
• Evolução do Ferramental DevOps: Empresas como GitHub (Microsoft) e GitLab inevitavelmente responderão à documentação divulgada pela OpenAI adaptando conceitos do Pando (como o Express Cache regional) em suas ofertas voltadas para instâncias corporativas pesadas, preparando terreno comercial para a integração nativa de agentes de IA nos fluxos de clientes B2B.

Perguntas frequentes

Por que o controle de versão da OpenAI falhou no final de 2025? O sistema antigo foi projetado para operações humanas. Com a introdução intensa do modelo Codex e de múltiplos agentes autônomos desenvolvendo código paralelamente, o tráfego saltou 2.442%, gerando gargalos nos fetches e falhas nos merges, derrubando a confiabilidade do sistema para menos de 90%.

O que o Pando faz de diferente do Git tradicional? Enquanto o Git tradicional coordena todos os repositórios impondo uma ordem linear restrita ou com múltiplos nós exigindo aprovação (como em Three-phase commit), o Pando permite a gravação em múltiplos branches simultaneamente sem que um interrompa o outro e reutiliza arquivos compactados (packfiles) em servidores de cache, desafogando o poder computacional.

Os engenheiros precisam reaprender a usar comandos do sistema Pando? Não. O Pando atua exclusivamente no backend (nos servidores). Ele foi construído para manter 100% de compatibilidade com o protocolo e com o cliente Git padrão, de modo que os desenvolvedores e os agentes continuam utilizando os mesmos comandos e ferramentas convencionais de suas rotinas sem perceber a mudança estrutural.