Anthropic passou de 2.500 para 30.000 mudanças mescladas por dia. As premissas do Git quebraram antes dele
A Anthropic substituiu o Git internamente pelo Scion após agentes de codificação multiplicarem sua taxa de merge. A maioria das empresas nunca precisará dele; vale revisar as premissas descartadas.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Em maio de 2026, cerca de 2,500 mudanças por dia eram mescladas no repositório principal da Anthropic. Em setembro, mais de 30,000. O histórico do main estava se aproximando de 100 GB, uma cópia de trabalho comprimida ultrapassava 25 GB, e a CI executava cerca de 25 milhões de checkouts por dia, sem contar ambientes de desenvolvedores, sandboxes de agentes e jobs de pesquisa. Buscado da maneira comum, a Anthropic estima que essa carga teria ultrapassado 600 PB de tráfego Git por dia.
O post de engenharia da Anthropic, publicado em 13 de outubro, descreve o que ela fez em seguida: moveu seu monorepo do Git para um sistema interno chamado Scion, construído por um time de sete pessoas em cerca de cinco meses, junto com uma ferramenta de revisão de código chamada Antique. O post é incomumente franco sobre os limites de sua própria lição. A Anthropic diz que seu uso do Claude para codificação, e seus gastos internos com tokens, estão muito além dos orçamentos típicos de empresas, e que o Scion não é um substituto geral do Git. Seu conselho para todos os outros é trazer as ideias úteis para o Git.
Esse conselho é a razão para lê-lo. A parte interessante não é que o Git quebrou. É quais das premissas do Git deixaram de ser verdadeiras.
| Feito para pessoas | Na escala de agentes, segundo a Anthropic | |
|---|---|---|
| Clientes | Desenvolvedores que às vezes trabalham offline com uma cópia completa | Quase todo cliente é um agente ou job sempre online |
| Commits | Feitos localmente, depois enviados | Feitos no servidor; nada para enviar |
| Checkouts | A árvore de trabalho inteira | Apenas os arquivos que um job lê, ou nenhum checkout |
| Ordem de merge | Uma fila que serializa merges | Testes pós-merge e pré-deploy; um lock global é impraticável |
| Revisão | Uma pessoa lê cada linha | Regras de aprovação semântica separam mudanças triviais das sensíveis |
A descentralização parou de valer a pena
O Git foi projetado para que cada desenvolvedor tenha o histórico completo e possa trabalhar desconectado. Na Anthropic, quase todo cliente era um agente ou um job de CI que está sempre online e precisa de alguns diretórios. Carregar o histórico completo para cada um deles era puro custo. O cliente do Scion busca conteúdo sob demanda de um servidor, mantém um cache limitado, e permite que muitos jobs pulem completamente o checkout ao consultar o controle de código-fonte através de APIs. A Anthropic relata checkouts cerca de duas ordens de magnitude mais rápidos, de minutos para segundos, um ganho de cerca de 25% na capacidade de CPU da CI, e um footprint cerca de 200 vezes menor que sua infraestrutura anterior de espelho do Git.
A maioria das empresas não atingirá esses volumes. Muitas atingirão a versão menor: sandboxes de agentes e runners de CI que cada um clona um grande repositório, espelhos que ficam atrás do main, e minutos de build que crescem mais rápido que o time. Checkouts esparsos, clones rasos e operações no lado do servidor já existem no Git, e são as primeiras coisas a tentar.
O gargalo se move para a revisão e o merge
As lições mais transferíveis estão nas duas últimas linhas. Com dezenas de milhares de merges por dia, uma fila de merge que serializa mudanças não consegue acompanhar, então a Anthropic conta com testes pós-merge e pré-deploy, e diz que o Claude geralmente resolve conflitos entre merges concorrentes mais rápido do que as pessoas os notam. E a revisão muda de forma: o Antique suporta regras de aprovação semântica, então uma mudança apenas de comentário não é tratada como uma sensível, e os revisores focam na intenção de uma mudança em vez de ler cada linha.
Para uma empresa, ambas são decisões de governança disfarçadas de ferramentas. Mover testes para depois do merge significa aceitar que o main pode ficar brevemente quebrado e investir em detecção e rollback rápidos. Deixar regras decidirem quais mudanças precisam de um humano significa escrever, antecipadamente, quais caminhos e tipos de mudança são sensíveis. Esse é o mesmo exercício que recomendamos para tratar agentes como autores de mudanças em produção: classes de mudança, com a aprovação que cada uma precisa, decididas antes que o volume chegue.
Onde olhar antes que o volume chegue
A saída de agentes não precisa crescer doze vezes para sobrecarregar seu sistema de entrega. Um time que dobra seus pull requests com agentes de codificação encontrará o limite primeiro nos revisores, depois na capacidade da CI, depois na fila de merge, e só muito mais tarde no próprio controle de código-fonte. A execução noturna de agentes do Google fez o mesmo ponto em pequena escala: de seis mudanças propostas, engenheiros mantiveram duas, e a revisão foi o trabalho.
Três números valem a pena acompanhar mensalmente à medida que os agentes de codificação se espalham: mudanças mescladas por dia, tempo mediano que uma mudança espera por revisão, e minutos de CI por mudança mesclada. Quando o primeiro cresce e os outros dois crescem mais rápido, seu Git está bem. Seu processo é que atingiu o problema da Anthropic, só que mais cedo na curva.