Em 13 de outubro, a Anthropic publicou uma retrospectiva de engenharia revelando que levou cinco meses para migrar todo o seu monorepo do git para o Scion, um sistema de controle de versão desenvolvido internamente. No mesmo período, também construiu uma ferramenta de revisão de código chamada Antique. A equipe principal tinha apenas 7 pessoas.
O motivo foi o volume de merges. Em maio de 2026, o monorepo da Anthropic recebia cerca de 2.500 merges por dia; em setembro, o número passou de 30 mil. A retrospectiva afirma:
"As our merges per day grew more than tenfold, source control became our biggest development bottleneck."
Quando nossos merges diários cresceram mais de dez vezes, o controle de código-fonte se tornou o maior gargalo do nosso desenvolvimento.
Escrever código já não é o que trava. O que trava é o controle de código-fonte, o build e a CI.
Onde o git não aguenta
A Anthropic apresenta alguns números: o histórico da linha principal chega perto de 100 GB, a cópia de trabalho compactada passa de 25 GB e a CI faz cerca de 25 milhões de checkouts por dia. Se cada um deles baixasse tudo, o tráfego diário de git ultrapassaria 600 PB. Nos horários de pico, a empresa mantém várias centenas de espelhos internos de git; quanto mais rápido os merges acontecem, mais difícil fica manter espelhos e snapshots pré-preparados.
A causa raiz apontada na retrospectiva é a incompatibilidade de objetivos de projeto. O git nasceu para a colaboração offline e distribuída entre pessoas, em que cada um tem um repositório completo; os principais clientes da Anthropic hoje são agentes e tarefas automatizadas que ficam sempre online.
Por isso, o Scion segue a lógica oposta: histórico, blame, commits, merges e rebases ficam todos no servidor, e o cliente mantém apenas um cache local e uma cópia de trabalho limitados, com os dados buscados sob demanda. O commit é concluído no servidor, e o custo depende do tamanho da alteração, não do tamanho total do repositório. Só existem a linha principal e os ramos de release; mover um ponteiro de ramo equivale a uma operação de comparar e trocar (compare-and-swap) em uma linha do banco de dados. O cliente passa por um daemon local e caches em camadas antes de chegar ao servidor, e a taxa de acerto de cache em todas as camadas supera 99%.
Fazendo as contas
Usando os números da retrospectiva para um cálculo aproximado: 600 PB divididos por 25 milhões de checkouts dão cerca de 24 GB por checkout, o que bate com a cópia de trabalho de mais de 25 GB. Isso indica que os 600 PB são um teto estimado, assumindo download completo a cada vez.
Distribuídos em 24 horas, 30 mil merges dão pouco mais de 20 por minuto. No modelo de push do git, cada push exige sincronizar antes com o remoto; com essa frequência, as novas tentativas por conflito entopem a fila. O Scion move o merge para o servidor e elimina a etapa de push. A Anthropic também abriu mão do bloqueio global de merge, passando a confiar em testes automatizados depois do merge e antes do deploy, e, quando alterações simultâneas colidem, deixa o Claude resolver.
O resultado, segundo a empresa: a infraestrutura do Scion usa cerca de 200 vezes menos CPU e memória do que o antigo cluster de espelhos git; os checkouts para CI e tarefas de pesquisa caem de minutos para segundos; só na CI, liberam-se cerca de 25% da capacidade de CPU.
O que o Claude fez nesse processo
A própria migração também usou o modelo. O pipeline de importação de git para Scion, escrito à mão no início, foi reescrito pelo Claude Mythos Preview, e o uso de memória caiu para 1/20 do original, com velocidade cerca de 4 vezes maior. A retrospectiva afirma que o Claude também encontrou otimizações no nível dos algoritmos e escreveu grande quantidade de testes, simulações e testes de fuzzing; o trabalho dos engenheiros passou a ser manter a intenção do projeto, vetar soluções pouco razoáveis e revisar a intenção das alterações em vez de ler o código linha a linha.
A retrospectiva não detalha o Antique; menciona apenas que ele permite definir regras semânticas para aprovações, separando commits que só alteram comentários dos que mexem em lógica sensível, para que a revisão humana se concentre nos últimos.
O Scion não é de código aberto. A Anthropic é direta: "Scion is by no means a suitable replacement for git for general use." Os componentes internos são personalizados demais para serem empacotados para terceiros. A empresa espera que GitHub, GitLab e a comunidade de código aberto aproveitem ideias como RPC no servidor e sparse checkout para melhorar o git. O Piper, do Google, e o Sapling, aberto pela Meta, trilharam caminhos parecidos; a diferença é que, desta vez, a pressão para reescrever vem do volume de código produzido por IA.
Fontes: Anthropic Engineering Blog, CocoLoop; os merges diários, o número de checkouts e os fatores de uso de recursos são números informados pela própria Anthropic, e o tamanho de cada checkout é um cálculo aproximado da redação com base nesses dados.