--- title: "OpenAI cria o Pando, novo back end de Git para escalar o código" author: "André Iglesias" date: "2026-11-03 06:21:52.615-03" category: "Tecnologia & Desenvolvimento" url: "http://desbugados.scale.press/portal/desbugados/post/2026/11/03/openai-cria-o-pando-novo-back-end-de-git-para-escalar-o-codigo/md" --- ## Resumo - A OpenAI criou o Pando, um back end proprietário de Git para seu monorepo. - O volume de commits da empresa cresceu 2.400% desde o primeiro trimestre de 2024. - O sistema foi desenvolvido em Rust em 10 semanas e entrou em produção em abril de 2026. - O Pando serve quase um petabyte de dados Git por dia e reduziu a latência de push em quase cinco vezes. - A arquitetura usa consistência causal para processar atualizações de branches de forma paralela. - O sistema mantém compatibilidade com o cliente e o protocolo Git padrão. - A OpenAI não abriu o Pando, mas enviou melhorias ao projeto Git existente. --- A **OpenAI** criou o **Pando**, um novo back end de Git para administrar o repositório de código da empresa. Essa camada de servidor recebe e entrega dados do Git, mas aqui ela também precisa acompanhar o volume produzido por engenheiros e agentes de IA. A mudança interessa a qualquer equipe que esteja tentando entender o que acontece quando o fluxo de desenvolvimento cresce mais rápido do que as ferramentas que o sustentam. ## O volume de código empurrou o Git até o limite O monorepo da OpenAI, um repositório único que reúne grande parte dos projetos da empresa, registrou um aumento de [**2.400% nos commits desde o primeiro trimestre de 2024**](https://openai.com/index/scaling-git-at-openai). Commit é o registro de uma alteração no código. Minha leitura é que esse número explica melhor a criação do Pando do que qualquer promessa de desempenho: havia um problema concreto de escala, provocado pela quantidade de mudanças que precisavam ser gravadas e consultadas. O projeto avançou depressa. [**O Pando foi desenvolvido em Rust em 10 semanas, entrou em produção em abril de 2026, serve quase um petabyte de dados Git por dia e reduziu a latência de push em quase cinco vezes**](https://thenewstack.io/openai-pando-git-backend). O design central ficou a cargo de um engenheiro, enquanto equipes de agentes de IA, incluindo o Codex, participaram da implementação. A divisão deixa clara a proposta documentada: usar agentes para produzir código sem abandonar uma infraestrutura capaz de receber esse trabalho. ## O que muda por baixo do comando Git Por baixo da interface conhecida pelos desenvolvedores, o Pando adota a **consistência causal**, modelo que permite processar atualizações de branches de forma independente e paralela. O Git convencional exige coordenação global do repositório para certas operações. A OpenAI tentou retirar esse ponto de espera sem obrigar as equipes a reaprenderem o básico: o sistema continua compatível com o protocolo e com o cliente Git padrão. Outra escolha está nos **packfiles**, arquivos que agrupam objetos do histórico do Git para facilitar o armazenamento e a transferência. Em vez de gerar um pacote personalizado para cada cliente, o Pando reutiliza arquivos já preparados. Essa abordagem reduz a carga de computação no servidor e melhora o fluxo de leitura, enquanto a escrita passa a aceitar pushes concorrentes em vários branches. É uma alteração de infraestrutura, não um novo aplicativo que o desenvolvedor precise aprender a usar. ## O próximo passo está fora do Pando A OpenAI não abriu o código do Pando. Em paralelo, porém, a empresa enviou correções para o projeto Git existente, incluindo melhorias no tratamento de downloads concorrentes e no comportamento após transferências interrompidas. O alcance imediato da iniciativa, portanto, está dividido entre uma solução proprietária para a operação interna e contribuições que podem chegar ao Git usado por outras equipes. O fato comprovado termina aí; qualquer previsão sobre a adoção do Pando por outras empresas ainda seria aposta. O que vale acompanhar é o rastreador público de patches mantido pela OpenAI e a evolução dessas melhorias no Git. A pergunta para os próximos anos é simples: quantos outros sistemas de desenvolvimento precisarão de uma camada parecida quando agentes de código passarem a gerar mudanças em escala semelhante?