Anthropic Scion: 5 lições do fim do Git no monorepo

Se o seu CI clona um repositório inteiro antes de cada teste, o problema que a Anthropic resolveu com o Scion vai chegar até você. O Git assume que cada máquina precisa do histórico completo para trabalhar offline, e agentes de IA nunca trabalham offline. Em setembro de 2026, a empresa desligou esse modelo no próprio monorepo.

O que é o Anthropic Scion e por que ele substituiu o Git

O Scion é o sistema de controle de versão que a Anthropic construiu para substituir o Git no monorepo principal da empresa. Segundo o post de engenharia da Anthropic, quase todos os clientes do repositório deixaram de ser humanos: são agentes de IA e jobs de CI que conversam com um servidor o tempo todo.

A escala explica a decisão. Em maio de 2026, a empresa mergeava cerca de 2.500 mudanças por dia. Em setembro, passava de 30 mil, empurradas por agentes. Com 25 milhões de checkouts diários e uma cópia de trabalho comprimida de pouco mais de 25 GB, um fetch ingênuo a cada checkout geraria algo próximo de 625 petabytes de tráfego em um único dia — o post menciona mais de 600 PB, e a conta fecha na mesma ordem.

Vale separar as camadas do anúncio. O Git, criado por Linus Torvalds, continua intacto e continua sendo a ferramenta certa para quase todo mundo. O que a Anthropic trocou foi o backend do próprio monorepo, uma decisão de escala extrema que a própria empresa desaconselha para uso geral.

A suposição de 2005 que os agentes de IA derrubaram

O Git nasceu em 2005 depois que o BitKeeper retirou a licença gratuita do kernel Linux, e a documentação oficial do Git preserva essa herança: cada clone carrega o histórico completo e funciona sem rede. Em uma entrevista de 2025, Torvalds descreveu o requisito como distribuído e realmente estável, um ajuste perfeito para mantenedores de kernel espalhados por várias máquinas.

O problema é o custo dessa liberdade. Antes de rodar um único teste, o job de CI clona o repositório inteiro. Quando o cliente é um agente que tem um servidor a um ping de distância, pagar por histórico local e trabalho offline em cada checkout vira desperdiço puro. Nada no controle de versão exige esse modelo — foi uma escolha de design, boa para o kernel e ruim para fazendas de CI.

A Anthropic lista os paliativos clássicos que o próprio Git oferece: clones rasos, parciais e esparsos, que baixam menos histórico ou menos arquivos. O relato é que eles pioraram diff e blame em clones parciais, e que a empresa chegou a manter várias centenas de espelhos internos de Git para absorver o tráfego.

Microsoft, Facebook e Google já tinham batido na mesma parede

A Anthropic foi a primeira a descobrir que o Git não escala para monorepos enormes. Três empresas grandes chegaram à mesma conclusão antes, e todas apontaram na mesma direção: pare de copiar tudo para cada máquina e deixe um servidor carregar o peso.

O post compara as soluções assim:

Empresa	Ano	Solução	Estratégia
Microsoft	2017	VFS for Git	Baixa só os arquivos em uso
Facebook	2014	Escalar o Mercurial	Clientes buscam conteúdo sob demanda
Google	interno	Piper	Workspace na nuvem com arquivos tocados
Anthropic	2026	Scion	Commits no servidor e cache de 3 camadas

A Microsoft relatou em 2017 que comandos simples de Git levavam de meia hora a horas no Windows, com cerca de 4 mil engenheiros, e alguns nem terminavam. O Facebook julgou os internos do Git difíceis de escalar e preferiu investir no Mercurial. O Google seguiu por outro caminho e construiu o Piper, seu sistema interno. A diferença do Scion é o cliente: ele foi desenhado para um agente sempre conectado, não para pessoas digitando em notebooks.

Como funciona a arquitetura do Scion

O Scion inverte o modelo do Git: o servidor guarda o histórico, responde perguntas de histórico e blame, e cria commits, merges e rebases. A metáfora é simples — no Git, todo leitor tem uma cópia da biblioteca inteira; no Scion, existe uma biblioteca, e você pede o livro.

Tecnicamente, uma mudança é uma lista de arquivos alterados em relação ao commit pai, apontando para o conteúdo comprimido de cada arquivo por hash de conteúdo no armazenamento de blobs. Como o hash deriva dos próprios bytes, conteúdos idênticos recebem sempre o mesmo nome, e objetos imutáveis podem ser cacheados sem compressão de delta. Blame e histórico de caminhos são dados derivados, calculados pelo servidor sob demanda.

O checkout passa por três camadas que respondem às mesmas perguntas, todas apoiadas em infraestrutura gerenciada:

1. O daemon do Scion, um cache persistente em cada nó.
2. O cache regional do Scion, que transmite objetos da memória no formato de disco.
3. O servidor do Scion, autoridade que lê do Spanner e do armazenamento em nuvem.

O cliente ignora qual camada respondeu. Ele percorre a árvore de pastas desde a raiz e pede só os objetos que faltam, checando o próprio cache antes de cada pedido. Um job de CI pode até pedir só o diff entre um commit e seu merge base, sem fazer checkout de nada. A Anthropic reporta taxa de acerto de cache acima de 99% em cada camada e uma infraestrutura 200 vezes menor em CPU e memória que a antiga frota de espelhos de Git, com checkouts caindo de minutos para segundos — números do próprio fornecedor, sem metodologia publicada.

O sistema nasceu de um time de sete pessoas em cinco meses, que também entregou uma ferramenta de code review, busca de código e controle de acesso. Depois, o time pediu ao Claude para reescrever o pipeline de ingestão sem instruções extras: a reescrita, segundo a Anthropic, usou 20 vezes menos memória e preservou invariantes implícitas do código original.

Fim do merge queue: testar depois do merge e deixar o Claude resolver conflitos

A decisão mais controversa do anúncio é descartar o merge queue tradicional, que enfileira mudanças e testa cada uma contra a main antes de integrar. Em mais de 30 mil merges por dia — uma mudança a cada poucos segundos, numa conta de guardanapo —, testar uma por uma no portão fica difícil de sustentar.

A alternativa da Anthropic combina três peças: testes automatizados depois do merge e antes do deploy, aceitação de que mudanças concorrentes às vezes conflitam, e uso do Claude para resolver esses conflitos, em geral mais rápido do que humanos levam para identificá-los. Como o Scion trata duas corridas de merge simultâneas não está documentado no post.

Um precedente interno mostra que coordenação via Git puro funciona em escala menor. Em fevereiro de 2026, Nicholas Carlini, do time de safeguards da Anthropic, usou quase 2 mil sessões do Claude Code para construir um compilador com agentes se coordenando só pelo Git, reivindicando tarefas com arquivos de lock. Conflitos de merge foram frequentes, e os agentes os resolveram sozinhos.

“A Anthropic reinventou o SVN?”: as críticas e os limites do Scion

A reação no Hacker News foi forte, com o post passando de 800 pontos no dia seguinte ao anúncio. A crítica mais repetida cabe em quatro palavras: a Anthropic reinventou o SVN, o sistema centralizado mais antigo. Outros perguntaram por que não usar Perforce ou o Sapling, do Facebook.

A comparação com o SVN acerta em parte. O Scion é server-first, então você abre mão de construir histórico offline, que é justamente a tese do Git. Mas ele não é um servidor de checkout burro: objetos são nomeados por hash de conteúdo e cacheados em camadas, algo que o SVN nunca fez. O post não explica por que a Anthropic construiu sobre algo como o Sapling.

A própria empresa delimita o escopo com clareza. O post diz que o Scion não é, de forma alguma, um substituto adequado do Git para uso geral, e que os conceitos só fazem sentido em monorepos enormes. A Anthropic vai abrir o código do Scion e sugere que outros times levem as ideias para dentro do Git. Minha leitura, e aqui é inferência editorial, é que review e manutenção de código em escala de geração por IA são o próximo gargalo do sistema.

O que fazer no seu pipeline: recomendações por tamanho de time

A lição prática do caso não é abandonar o Git. É medir antes de mexer: conte quantos clones completos o seu CI faz por dia e quanto tempo cada um leva. Se esse é o gargalo, comece pelos clones rasos ou parciais, que já vêm no Git, e teste diff e blame em seguida, porque pioram em clones parciais.

O caminho depende do seu contexto:

• Time pequeno com poucos agentes: fique no Git. A coordenação só pelo Git funcionou até no experimento do compilador com quase 2 mil sessões.
• CI que clona repositório grande a cada job: conserte isso primeiro, com clones rasos, parciais ou esparsos.
• Monorepo com enxames de agentes: trate o post da Anthropic como guia de ideias, já que o código não será liberado.
• Merge queue: mantenha o seu. O modelo da Anthropic depende de testes pós-merge e do Claude resolvendo conflitos, e a própria empresa admite que seu gasto de tokens está muito além do que a maioria das empresas aceitaria.

Até os conflitos começarem a se acumular no seu fluxo, a fila de merge continua sendo a aposta mais barata. Se agentes escrevessem dez vezes mais código no seu projeto, o que quebraria primeiro: o checkout, a fila de merge ou o review?

Perguntas frequentes sobre o Scion e o futuro do Git

• O Scion é open source? Não. A Anthropic afirma que não vai abrir o código do Scion e recomenda que outros times transportem as ideias para o Git. O sistema foi feito para as necessidades internas da empresa, não como produto.

• O Git está morto depois do anúncio? Não. A Anthropic explicitamente que o Scion não é um substituto adequado do Git para uso geral e que os conceitos só fazem sentido em monorepos enormes com tráfego de agentes. Para a vasta maioria dos projetos, o Git continua sendo a escolha certa.

• Por que a Anthropic abandonou o merge queue? Com mais de 30 mil merges por dia, testar cada mudança individualmente antes de integrar não escala. A empresa passou a confiar em testes automatizados depois do merge e antes do deploy, com o Claude resolvendo os conflitos que aparecem.

• Quanto a Anthropic economizou com o Scion? Segundo números reportados pela própria empresa, a infraestrutura ficou 200 vezes menor em CPU e memória que a frota de espelhos de Git, e os checkouts caíram de minutos para segundos. O post não publica a metodologia de medição, então trate os valores como dados do fornecedor.

• Meu time deveria migrar para um sistema centralizado? Só se o seu CI fizer clones completos de um monorepo enorme várias vezes ao dia. Para times pequenos e médios, clones rasos e parciais, que já fazem parte do Git, resolvem a maior parte do problema sem trocar de ferramenta.

Source video