O primeiro sinal de que uma equipe entrou de verdade na fase dos agentes não é uma demo bonita. É o repositório ficando mais barulhento. Mais branches abertas, mais pushes, mais jobs de CI buscando o mesmo commit e mais gente esperando uma mudança simples aparecer do outro lado.
Um texto técnico recente da OpenAI descreve esse ponto de atrito sem romantizar a ferramenta: quando o trabalho paralelo cresceu no monorepo da empresa, fetches e pushes ficaram lentos, merges falharam e a confiabilidade chegou a cair abaixo de 90% em alguns momentos. Não era exatamente “o Git acabou”; era a arquitetura ao redor dele tratando trabalho independente como se tudo precisasse entrar numa única fila.
Isso interessa mesmo para um time que nunca vai construir uma infraestrutura do porte da OpenAI. Agentes de código tornam barato criar tentativas paralelas. O custo aparece depois: revisar, testar, integrar e servir esse volume sem transformar o repositório no ponto mais lento da equipe.
Mais velocidade para escrever não significa mais capacidade para integrar
Um desenvolvedor pode ter mais de uma mudança pronta para CI; um agente pode abrir outras tantas em paralelo. Cada push pode disparar testes, downloads de dependências, verificações de segurança e clones em ambientes efêmeros. O efeito não é linear porque boa parte dessa atividade volta ao mesmo lugar: o histórico e as referências do repositório.
O caso da OpenAI chama esse backend de Pando. A ideia central é separar duas pressões que costumam andar juntas: muitas pessoas (ou agentes) escrevendo em branches diferentes e muitos clientes lendo a mesma história. Em vez de coordenar o repositório inteiro a cada alteração, o sistema trata atualizações de referências diferentes de forma independente e reaproveita pacotes de objetos já enviados.
Há uma troca importante aí. A solução abre mão de uma fotografia única e instantânea de todas as branches ao mesmo tempo, mas preserva a ordem de cada referência. Para uma branch de trabalho, isso costuma ser o que importa; para operações que dependem de uma visão global perfeitamente sincronizada, não necessariamente.
O ponto que times menores podem aproveitar agora
Você não precisa trocar o servidor Git para sentir a lição. A pergunta útil é: o que hoje está serializando trabalho que não precisa ser serial? Em times que adotam agentes, aparecem alguns suspeitos recorrentes:
- Uma fila de CI única. Se todo push disputa os mesmos executores, o agente só produz mais espera.
- Branches enormes e duradouras. Elas aumentam o custo de integração justamente quando há mais mudanças concorrendo.
- Ambientes que clonam tudo sempre. Cache, checkout raso quando compatível e artefatos reutilizáveis fazem diferença antes de qualquer projeto de infraestrutura.
- Revisão sem limite de concorrência. Abrir dez PRs não ajuda se ninguém consegue entender qual deles é seguro fundir primeiro.
- Automação com permissão demais. Um agente que pode alterar qualquer branch transforma velocidade em risco operacional.
O Git continua sendo a interface — mas a operação mudou
A parte mais pragmática do relato é que a OpenAI manteve compatibilidade com o protocolo e o cliente Git. Isso evita pedir que engenheiros e ferramentas aprendam outro fluxo só porque o backend precisou mudar. O GitHub descreveu uma direção parecida ao migrar repositórios para Azure: reduzir coordenação desnecessária e desacoplar armazenamento de computação para que leituras e escritas não disputem o mesmo recurso.
Para o dia a dia, a consequência não é “copie a arquitetura deles”. É tratar controle de versão como capacidade de produção. Se agentes passam a produzir código enquanto o time dorme, o repositório, a CI, os limites de branch e a revisão deixam de ser detalhes de ferramenta. Viram o sistema que decide se esse volume vira entrega ou só vira ruído.
Um teste simples antes de aumentar o número de agentes
Antes de liberar mais sessões, olhe uma semana de dados: tempo de fila e execução da CI, falhas de merge, tempo de checkout, tamanho médio dos PRs e quantidade de mudanças abertas sem revisão. Se esses números já doem com pessoas, agentes apenas deixam a dor mais visível.
O ganho real de trabalhar em paralelo aparece quando cada tentativa tem um escopo pequeno, uma verificação clara e um caminho seguro de volta. Sem isso, a equipe não ganha dez vezes mais capacidade; ganha dez vezes mais coisas esperando para dar errado.
