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

> Published 2026-10-18T12:43:59.600Z on https://www.crazystack.com.br/pt/p/anthropic-scion-5-licoes-do-fim-do-git-no-monorepo/
> Source video: https://www.youtube.com/watch?v=BdpkjjEArxs

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](https://www.anthropic.com/engineering), 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](https://git-scm.com/about) 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](https://www.anthropic.com) 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](https://github.com/microsoft/VFSForGit) | Baixa só os arquivos em uso |
| Facebook | 2014 | Escalar o [Mercurial](https://www.mercurial-scm.org) | 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](https://cloud.google.com/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](https://claude.ai) 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](https://nicholas.carlini.com), do time de safeguards da Anthropic, usou quase 2 mil sessões do [Claude Code](https://github.com/anthropics/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](https://news.ycombinator.com) 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](https://subversion.apache.org), o sistema centralizado mais antigo. Outros perguntaram por que não usar [Perforce](https://www.perforce.com) ou o [Sapling](https://github.com/facebook/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](https://www.youtube.com/watch?v=BdpkjjEArxs)