A Anthropic substituiu o git por um sistema de controle de versão próprio, o Scion, construído por sete engenheiros em cinco meses. O motivo: o Claude escreve tanto código que o excesso de fusões quebrou a ferramenta que quase todo mundo usa.
O que a Anthropic construiu com o Scion
A Anthropic publicou em seu blog de engenharia como redesenhou o controle de versão da empresa. O problema é direto: o Claude escreve código sozinho, em alta velocidade, e a infraestrutura pensada para humanos começou a travar. Não só o controle de versão, mas também as compilações e a integração contínua.
Para lidar com isso, a empresa construiu o Scion, um sistema de controle de versão interno, e migrou todo o seu monorepo a partir do git, ou seja, do repositório único que reúne o código de vários projetos. A migração completa levou cinco meses. No mesmo período, o time também entregou o Antique, interface de revisão de código, a busca de código, um sistema de permissões e outras ferramentas.
Vale situar os números. Em maio de 2026, a Anthropic fazia em média cerca de 2.500 fusões de código por dia, ou seja, alterações aprovadas e incorporadas ao projeto. Em setembro, passou de 30.000 por dia. É um salto de mais de dez vezes em poucos meses, e a empresa diz que não espera desaceleração.
Uma escala que nenhuma equipe humana acompanha.
Por que o git deixou de dar conta na Anthropic
O git foi desenhado para funcionar de forma descentralizada: cada cópia do repositório é completa e funciona offline. Para a maioria dos projetos, é a escolha certa, e é por isso que virou padrão. O problema aparece quando o repositório cresce demais.
Na Anthropic, só o histórico do ramo principal tem quase 100 GB, e uma cópia comprimida de trabalho passa de 25 GB. A empresa faz cerca de 25 milhões de checkouts de código por dia só para a integração contínua, processo que testa o código automaticamente. Buscado da forma ingênua, isso daria mais de 600 PB de tráfego de git por dia.
Os paliativos conhecidos do git, como clones superficiais e espelhos internos, ajudaram por um tempo. No pico, a empresa mantinha várias centenas de espelhos internos. Só que, conforme o ritmo de fusões subia, esses espelhos ficaram difíceis de operar e deixaram de escalar quando o repositório passou do limite de disco e memória deles.
A solução antiga simplesmente parou de funcionar.
Git
- Cliente tem cópia completa do repositório
- Funciona offline, servidor opcional
- Paliativo: espelhos internos e clones superficiais
- Operações de histórico rodam no cliente
Scion
- Cliente busca dados sob demanda, sempre online
- Servidor responde a histórico, blame e merges
- Sem cópia completa do repositório em lugar algum
- Sem packfiles, sem manutenção de repositório
Como o Scion funciona na prática
A ideia central do projeto foi assumir que os clientes estão sempre online. Quase todos os "usuários" do sistema são agentes e tarefas automáticas, não pessoas trabalhando offline. Com isso em mente, o Scion inverte o modelo do git: o servidor faz o trabalho pesado, e o cliente só mantém um cache local limitado.
Quem manda agora é o servidor.
No Scion, a unidade de trabalho é o "changeset", que registra apenas os arquivos que mudaram em relação ao pai anterior, junto com ponteiros para o conteúdo comprimido. Como não há packfiles nem travas entre servidores, o sistema aceita mudanças em ritmo muito alto. Perguntas como "quem editou esta linha por último" são respondidas por estruturas de dados derivadas, calculadas sob demanda.
A empresa diz que a nova infraestrutura usa 200 vezes menos CPU e memória que o antigo esquema de espelhos do git. As tarefas de integração contínua e pesquisa passam a fazer checkout em segundos, não em minutos, e só a integração contínua ganhou 25% de capacidade de CPU.
O time pequeno e o papel dos engenheiros no Scion
Um dado que resume o momento: sete pessoas construíram tanto o Scion quanto o Antique e migraram tudo em cinco meses, enquanto o volume de código fundido por dia crescia dez vezes. Segundo o relato, todos esses engenheiros hoje diriam que o Claude escreve código melhor do que eles.
Mas os engenheiros não ficaram de fora. A Anthropic descreve o papel deles como fornecer a compreensão dos sistemas em alto nível e das decisões de projeto. Em muitos casos, o trabalho era dizer "não" ao Claude, que às vezes tentava violar restrições básicas do sistema para satisfazer um padrão que nunca deveria ter sido permitido.
Um exemplo citado no texto: a primeira versão do pipeline que ingeria código do git no Scion foi escrita à mão e parecia boa. Quando o time pediu para o Claude reescrevê-la, sem mais instruções, ele produziu uma versão que consumia 20 vezes menos memória e rodava quatro vezes mais rápido, mantendo todas as regras implícitas de ordenação e estrutura de dados.
O que o Scion significa para o resto do mercado
A própria Anthropic deixa claro que o Scion não é uma alternativa ao git para uso geral. Os conceitos só fazem sentido em monorepos realmente gigantes, com dezenas de milhares de engenheiros ou enxames de agentes escrevendo código sem parar. A empresa também gasta tokens internamente em um nível que nenhuma outra companhia provavelmente querer gastar.
Será que o seu projeto precisa disso? Provavelmente não.
Ainda assim, a discussão importa para quem programa com IA. A Anthropic aposta que esse tipo de gargalo vai ficar comum nos próximos 6 a 12 meses e que cada empresa enfrentá-lo sozinha seria desperdício. Por isso, publicou o que aprendeu, sugerindo que partes do Scion podem ser aproveitadas no próprio git, com servidores que trabalham de forma diferente dos clientes.
Fique de olho em como GitHub e GitLab respondem a esse cenário. Se a leitura da Anthropic se confirmar, o problema que ela resolveu agora vai bater na porta de qualquer equipe que use ferramentas de programação com IA em escala.
