Anthropic troca o Git pelo Scion: sistema próprio para aguentar 30 mil merges por dia

A Anthropic tirou o Git do caminho crítico da sua engenharia. Em texto publicado em 13 de outubro de 2026 no blog de engenharia da empresa (e atualizado em 15 de outubro), a dona do Claude detalhou o Scion, um sistema de controle de versão construído do zero que substituiu o Git no monorepo interno. O motivo é direto: o volume de merges saltou de cerca de 2.500 por dia em maio de 2026 para mais de 30 mil por dia em setembro, com agentes de IA escrevendo código em um ritmo que a ferramenta criada para humanos não acompanhou. Sete pessoas construíram o Scion e o Antique, a ferramenta de code review que o acompanha, e migraram todo o monorepo para fora do Git em cinco meses.

Por que o Git parou de dar conta

O problema é de escala, não de qualidade do Git. A empresa descreve um monorepo cujo histórico só da branch principal chegou a quase 100 GB, com mais de 25 GB em cópia de trabalho comprimida e algo na casa de 25 milhões de checkouts de código por dia, puxados principalmente por integração contínua (CI) e jobs de pesquisa. Nesse cenário, o modelo distribuído do Git vira peso morto: cada cliente precisa de uma cópia grande do repositório antes de fazer qualquer coisa. Pela conta da Anthropic, servir esse volume de checkouts por Git exigiria mais de 600 petabytes de tráfego por dia.

O Git foi desenhado para desenvolvedores que trabalham offline, commitam localmente e sincronizam depois. Agentes automatizados não trabalham assim: estão sempre conectados, abrem muitas mudanças pequenas em paralelo e não precisam do histórico inteiro na máquina.

O que é o Scion e como ele foi desenhado

O Scion é um sistema de controle de versão cliente-servidor, com três camadas de cache: o scion-daemon, que guarda objetos no nível do nó; o scion-cache, com servidores regionais que entregam objetos direto da memória; e os scion-servers, autoridade final que lê do armazenamento em nuvem. A empresa afirma taxa de acerto de cache acima de 99% nessas camadas.

Os princípios de design, pela descrição da Anthropic, invertem quase tudo o que o Git assume: clientes sempre online, assimetria entre cliente e servidor (o servidor carrega os metadados, o cliente mantém cache limitado), commits baratos e incrementais sem locks, API ampla para acesso programático e cópias de trabalho esparsas opcionais. Os commits viram "changesets" gravados no servidor, que armazenam só as diferenças de arquivo, apontando para blobs endereçados por conteúdo.

Os ganhos relatados pela empresa: uma infraestrutura 200 vezes menor em CPU e memória que o antigo setup de espelhamento de Git, checkouts de CI e de pesquisa duas ordens de magnitude mais rápidos (segundos, não minutos) e 25% de capacidade de CPU extra no CI. São dados divulgados pela própria Anthropic, sem verificação independente.

O Scion não vai virar código aberto

Não espere baixar o Scion. A empresa diz que ele diverge demais do Git e está amarrado às ferramentas e estruturas internas da Anthropic — adotá-lo exigiria migrar todo o ciclo de desenvolvimento, de code review a busca e CI — e que, nas palavras do texto, uma versão pública que tentasse agradar a todos não seria realmente útil. A promessa é compartilhar os princípios de arquitetura para que servidores de Git existentes evoluam na mesma direção, com menção a parceria com GitHub, GitLab e a comunidade de código aberto.

Vale registrar outro ponto do relato, dado o tema: mesmo com o Claude acelerando a implementação, a empresa afirma que os engenheiros humanos continuaram essenciais. Segundo a Anthropic, o papel deles foi em boa parte dizer "não" ao modelo, fornecendo o entendimento de alto nível entre sistemas e as decisões de trade-off de design. Todas as mudanças no sistema seguem passando por revisão de IA e de pessoas.

O que muda para o desenvolvedor brasileiro

Nada muda hoje na sua máquina. O que o caso sinaliza é o tipo de gargalo que aparece quando times adotam geração de código assistida em escala: fila de CI, revisão travada, histórico pesado, branches demais abertas ao mesmo tempo. Quem usa Claude Code, Copilot ou Cursor em equipe já convive com versões pequenas desses sintomas.

Nessa situação, o caminho prático não é trocar de VCS. É reduzir o que cada job precisa baixar: checkouts rasos e parciais, cache de dependências, filtros de caminho no pipeline, separação entre histórico e build. O relato da Anthropic serve de referência de arquitetura para quem chega ao limite — e de recado de que o problema de escala agora vem do volume de mudanças, não do tamanho do time.