OpenAI acelera os pushes do Git em quase cinco vezes com o Pando

Um agente terminou uma alteração, mas os testes ainda não começaram: primeiro, é preciso enviar as alterações e baixar o código no ambiente de testes. Com dezenas de tarefas em paralelo, a espera pelo Git pode consumir parte do ganho obtido com a geração rápida de código. O caso do Pando é útil para equipes que estão aumentando o número de agentes e querem entender onde surgirá a próxima fila.

O que a OpenAI apresentou

Em uma análise técnica publicada em 2 de novembro, a OpenAI descreveu o Pando, seu backend interno do Git. A empresa relata uma redução de quase cinco vezes na latência mediana de push e a distribuição de quase um petabyte de dados do Git por dia. A compatibilidade com o cliente e o protocolo do Git foi preservada.

O sistema se apoia em duas decisões: atualizações independentes de diferentes branches e reutilização de pacotes de dados já preparados nas operações de leitura. No entanto, ler várias branches não garante uma única imagem de todo o repositório em um mesmo instante. O Pando funciona dentro da OpenAI; a empresa estuda maneiras de compartilhar a tecnologia, mas não informa um prazo de lançamento.

Para aplicar essas ideias na prática, o escopo da medição importa. A latência mediana de push descreve a demora típica de uma operação. Ela não permite calcular quanto mais rápido uma equipe entrega seu produto. Entre o envio das alterações e o lançamento, ainda há testes, revisões, correções e aprovações. Acelerar essa etapa em quase cinco vezes não promete, por si só, uma aceleração equivalente no desenvolvimento.

Exemplo: agentes preparam várias alterações

Imagine a equipe de desenvolvimento de uma loja virtual. Um agente modifica a busca, outro corrige o carrinho e um terceiro atualiza as dependências. Cada um trabalha em sua própria branch. Depois do envio das alterações, o sistema de testes precisa obter a versão correta do código e executar os testes. Se as verificações começarem ao mesmo tempo, vários leitores acessarão o mesmo histórico do repositório.

Separar o trabalho por branches permite tratar essas operações de forma independente. Uma alteração na busca não precisa esperar por uma atualização do carrinho só porque ambas estão no mesmo repositório. Já a distribuição repetida de um pacote pronto se assemelha ao envio do mesmo arquivo compactado a vários destinatários: o servidor se beneficia ao reutilizar os dados que já preparou. Essa é uma ilustração simplificada dos dois princípios do Pando, e não uma descrição da infraestrutura de uma loja específica.

Mas outra fila continua existindo: as alterações ainda precisam ser integradas. Se dois agentes modificarem o mesmo trecho de código, um servidor rápido não decidirá pela equipe qual versão aceitar. Isso exige regras de responsabilidade pelas tarefas, verificação de conflitos e um procedimento claro de merge. O desempenho do armazenamento e a qualidade da colaboração devem ser medidos separadamente.

Há também uma implicação para a automação. Se um processo toma decisões envolvendo várias branches ao mesmo tempo, é preciso definir explicitamente quais versões ele compara. Por exemplo, uma verificação de compatibilidade entre duas alterações deve fixar commits específicos. Caso contrário, uma nova execução poderá verificar outra combinação de código, dificultando a reprodução do resultado pelo desenvolvedor.

O que verificar no seu próprio fluxo de trabalho

Comece medindo uma tarefa completa, desde a alteração pronta até o resultado dos testes. Divida o tempo entre o envio das alterações, a obtenção do código, a espera por um executor disponível e os próprios testes. Esse detalhamento mostrará qual etapa está realmente atrasando o trabalho. Se a maior parte da demora estiver na fila de testes, substituir o servidor Git terá um efeito limitado.

Depois, repita a medição com os níveis habituais e de pico de paralelismo. Para a equipe, o que importa é identificar o momento em que agentes adicionais deixam de reduzir o tempo de conclusão das tarefas. Vale observar tanto as latências típicas quanto as esperas longas ocasionais: são estas que podem atrasar uma correção urgente. Os resultados devem ser comparados usando as mesmas tarefas e o mesmo número de verificações.

Esses dados ajudarão gestores de produto e fundadores a avaliar o custo de acelerar o trabalho. Um agente adicional gera valor quando seu resultado percorre todo o processo até se tornar uma alteração aceita. Se apenas o número de branches e de verificações pendentes estiver crescendo, vale resolver a fila primeiro. A lição prática do Pando é incluir o Git e a entrega do código na medição da produtividade do desenvolvimento com agentes. A decisão sobre uma nova infraestrutura deve então se basear nas próprias medições.