Como o Scion da Anthropic substituiu o Git

O Scion da Anthropic um sistema de controle de versão interno que substituiu o Git no monorepo da empresa em cinco meses. A motivação foi escala: os merges diários saltaram de cerca de 2.500 em maio de 2026 para mais de 30.000 em setembro do mesmo ano, segundo o blog oficial da própria Anthropic. Este artigo explica por que o Git virou gargalo e o que mudou na arquitetura.

O que é o Scion da Anthropic por que ele existe

O Scion da Anthropic um sistema de controle de versão interno que substituiu o Git no monorepo da empresa em cinco meses, segundo o próprio blog da Anthropic. Ele foi construído para um cenário específico: agentes de IA, e não humanos, fazem a maior parte das mudanças de código.

Os números que motivaram o projeto são relatados pela própria empresa. Em maio de 2026, a Anthropic mesclava cerca de 2.500 mudanças por dia. Em setembro do mesmo ano, o volume passou de 30.000 por dia. O gargalo deixou de ser escrever código e passou a ser a infraestrutura de desenvolvedor, feita para escala humana.

Junto do Scion, a equipe entregou o Antique, uma superfície de code review, além de busca de código e pipelines de bisect e revert automatizados. Tudo isso em cinco meses, por uma equipe de sete pessoas, enquanto o volume diário de merges crescia 10x.

Por que o Git virou gargalo no monorepo

O Git virou gargalo porque suas propriedades distribuídas, excelentes para trabalho offline, não combinam com clientes que estão sempre online. Os clientes do monorepo da Anthropic majoritariamente agentes e jobs de CI, que por definição dependem de rede para funcionar.

A escala do repositório conta a história. O histórico apenas da branch main tem quase 100 GB, e uma cópia de trabalho comprimida passa de 25 GB. São cerca de 25 milhões de checkouts de código por dia só para CI, números divulgados no post da Anthropic. Buscados de forma nativa, isso significaria tráfego Git na casa dos petabytes diários.

A empresa tentou os contornos padrão: clones rasos, sparse checkout e, no pico, várias centenas de espelhos Git internos. Funcionou por um tempo, mas a operação ficou cada vez mais delicada conforme o volume de merges subia e os dados dos espelhos ficavam defasados em relação à ponta da main.

Os princípios de design do Scion

O Scion parte de uma premissa oposta à do Git: o servidor está sempre acessível, e o cliente busca dados só quando precisa. Não existe push. Cada commit, rebase ou merge acontece no servidor, o que elimina a sincronização de estado entre cópias.

A assimetria cliente-servidor é deliberada. O servidor responde perguntas sobre histórico, blame, diffs e merges. O cliente mantém um cache local limitado, escreve os arquivos em disco e pouco computa por conta própria. Em troca, precisa de muito menos dados localmente.

Outras decisões seguem a mesma lógica: commits precisam ser baratos, incrementais e sem locks, porque 500 agentes Commitando não podem bloquear outros 500. Refs globais como branches e tags são desencorajadas, exceto a main e branches de release. E a cópia de trabalho é opcional e esparsa: um job de CI pode pedir só o diff entre dois commits, sem materializar nada.

Quem conhece histórico do setor não se surpreende. O Google tem o Piper e a Meta construiu o Sapling, derivado do Mercurial, para seus monorepos gigantes. Ferramentas como o JJ exploram ideias parecidas fora das big techs.

Como o Scion funciona por dentro

A unidade de trabalho do Scion é o change set, que guarda a lista de arquivos alterados em relação ao primeiro pai, com ponteiros endereçados por conteúdo para os arquivos comprimidos em blob storage. O conteúdo completo do arquivo é armazenado, não o diff; o diff é calculado sob demanda comparando blobs.

O metadado vive no Spanner, o banco distribuído do Google Cloud, e os blobs em armazenamento de objetos. Change sets são imutáveis e endereçados por conteúdo, então qualquer servidor pode cachear sem coordenar com os outros.

Perguntas como "quem alterou esta linha" exigem estruturas derivadas, construídas recursivamente a partir dos change sets: índices de blame, histórico de caminhos e skip lists para o grafo de commits. Como o cliente nunca vê os internos, a empresa pode adicionar ou otimizar índices sem mudar nada nos clientes.

A camada de infraestrutura tem três níveis. Servidores Scion autoritativos leem do Spanner e do blob storage. Caches regionais atendem máquinas de desenvolvedor. E um daemon por nó, com snapshots periódicos, serve os jobs de CI. Todas as camadas respondem aos mesmos RPCs, mas o tiering é rigidamente respeitado para isolar domínios de falha.

Resultados relatados: performance e custo

Os ganhos abaixo são relatados pela própria Anthropic verificados de forma independente. A empresa diz que cada camada de cache tem hit rate acima de 99% e que a nova infraestrutura é 200x menor em CPU e memória que a antiga fazenda de espelhos Git. Jobs de CI e de pesquisa fazem checkout duas ordens de magnitude mais rápido, em segundos em vez de minutos.

Na comparação de comandos do dia a dia entre o cliente SCN e o Git, também divulgada pela Anthropic destaques são estes:

Operação	Ganho relatado
Pull (ambiente de desenvolvedor)	25x mais rápido
Checkout	14x mais rápido
Status	207x mais rápido
Commit	30% mais rápido
Diff	6x mais rápido
Novo worktree	84x mais rápido
Status (ambiente de agente)	20x mais rápido

Um contraponto útil vem de fora. Theo Browne, do canal t3.gg, mediu quanto o próprio CI do T3 Code espera por checkouts Git: quase mil horas, cerca de 42 dias, o que ele estima entre US$ 350 e US$ 600 só de CPU alugada. É um dado de experiência própria do criador do canal, não um benchmark independente do Scion, mas mostra que o problema existe bem abaixo da escala da Anthropic.

Lições de engenharia em escala de agentes

A lição central do post da Anthropic é sobre armazenamento, é sobre o papel do engenheiro. Sete pessoas construíram o Scion e o Antique, e os engenheiros do projeto dizem que Claude modelo de IA da Anthropic, passou a escrever código melhor que eles. O trabalho humano mudou para decisões de design, trade-offs entre sistemas e dizer "não" quando agentes violam restrições.

Os exemplos concretos ilustram bem isso. Um pipeline de ingestão escrito à mão foi reescrito por um snapshot interno do modelo sem instruções extras, com resultado 20x menor em memória e 4x mais rápido, preservando as invariantes. Sistemas automatizados tentavam responder "quando este change merged?" lendo o log de commits linearmente em vez de perguntar ao code review.

A revisão humana também mudou de forma. Pessoas ainda revisam cada change request, mas examinam a intenção da mudança, não cada linha. E a empresa usa revisão adversária entre modelos, reconhecendo que ela pode ser míope e gerar overengineering defensivo, o que exige engenheiros para conter o escopo.

O merge queue tradicional simplesmente não faz sentido nesse ritmo. O que significa CI quando milhares de mudanças podem mesclar enquanto os testes rodam? A resposta da Anthropic investir em testes automatizados pós-merge e pré-deploy, priorizando a capacidade de reverter rápido em vez de empilhar atrito antes do merge.

Segurança, operação e por que o Scion não é open source

O Scion nasceu com controles de acesso por repositório e por diretório, protegendo código sensível sem quebrar as vantagens do monorepo. As ferramentas de review expressam restrições semânticas de aprovação, separando mudanças triviais de comentários das mudanças lógicas sensíveis. Na operação, a equipe usa "superfãs" Claude, instâncias do assistente monitorando cada componente via Slack, além de alertas tradicionais.

Quem espera baixar o Scion vai se decepcionar. A Anthropic explica que ele diverge demais do Git: exigiria migrar todo o ciclo de desenvolvimento, incluindo code review, busca e CI próprios, altamente customizados. E tentar agradar todo mundo numa versão pública provavelmente produziria algo pouco útil.

A empresa deixa claro que o Scion não é substituto do Git para uso geral. As ideias só fazem sentido em monorepos verdadeiramente enormes, com dezenas de milhares de engenheiros ou enxames de agentes. O que a Anthropic propõe ao ecossistema, incluindo GitHub e GitLab, é aplicar os conceitos: servidores Git com RPCs abrangentes do lado do servidor e protocolos de negociação que componham melhor com sparse e shallow clones.

Perguntas frequentes

• O Scion substitui o Git? Não para uso geral. A própria Anthropic afirma que ele só faz sentido em monorepos gigantes com escala extrema de agentes. Para a maioria dos times, o Git continua sendo a escolha certa.

• Quanto tempo levou a migração do Git para o Scion? Cinco meses, incluindo o Scion, o Antique de code review, busca de código e sistemas relacionados, tudo isso com o volume de merges crescendo 10x no período.

• **Quanto maior ficou o volume de merges na Anthropic empresa relata cerca de 2.500 mudanças mescladas por dia em maio de 2026 e mais de 30.000 por dia em setembro do mesmo ano.

• O Scion é open source? Não. A Anthropic argumenta que os componentes internos são tão customizados que uma versão pública seria pouco útil para outras organizações.

• O que o Scion usa de infraestrutura? Metadados de change sets no Spanner, do Google Cloud, conteúdo de arquivos em blob storage, servidores autoritativos, caches regionais e um daemon por nó para jobs de CI.

• Quais ganhos de performance a Anthropic relata? Checkouts 14x mais rápidos, status 207x mais rápido, worktrees 84x mais rápidos e uma infraestrutura 200x menor em CPU e memória que os espelhos Git anteriores. Todos são números relatados pela própria empresa.

• Por que o Git não escala para agentes? Porque foi desenhado para trabalho distribuído e offline, com cada cliente mantendo tudo. Clientes sempre online, como agentes e CI, pagam um custo desnecessário de sincronização e armazenamento local.

• Quem construiu o Scion? Uma equipe de sete pessoas na Anthropic, que também entregou o Antique, a ferramenta de code review, e meia dúzia de sistemas relacionados no mesmo período.

• O que muda para o engenheiro nesse modelo? O foco sai da linha de código e vai para decisões de arquitetura, trade-offs entre sistemas e conter o escopo quando agentes ou revisões automatizadas geram overengineering.

Transforme suas próprias aulas e análises em artigo

Este artigo nasceu de um vídeo de quase uma hora sobre o Scion, destilado em estrutura pesquisável e respondível por mecanismos de busca. Conteúdos assim, imersos em lives, entrevistas e análises longas, costumam morrer no algoritmo sem nunca virar referência escrita.

Se você produz conhecimento em vídeo, o caminho é o mesmo deste artigo: cole a URL do YouTube no Skala Blog, gere a transcrição e transforme-a em um artigo estruturado, com títulos, tabelas e FAQ prontos para revisão.

Source video