Claude Gerou Tanto Código que a Anthropic Teve que Matar o Git

De 2.500 para 30.000 merges por dia em cinco meses. Sete engenheiros. Um monorepo de 100 GB. E a conclusão incômoda de que o Git, a ferramenta que todo dev trata como sagrada, simplesmente não aguenta o ritmo dos agentes de IA.

A Anthropic publicou um post de engenharia nesta semana detalhando como construiu o Scion, um sistema de controle de versão interno que substituiu o Git por completo. E antes que você pense “ah, é só mais um wrapper”, não. Eles jogaram fora o modelo inteiro: repositório local, push, fetch, packfiles. Tudo.

Eu já vi empresas grandes sofrerem com monorepos no Git. Google, Meta, Microsoft, todas acabaram criando soluções próprias. Mas o que torna o caso da Anthropic diferente é o motivo: não foram milhares de engenheiros humanos que estouraram o limite. Foram agentes de IA.

O Problema que Ninguém Previu

Vamos aos números, porque eles falam sozinhos.

Se você fizesse esses 25 milhões de checkouts diários usando o protocolo padrão do Git, geraria mais de 600 petabytes de tráfego. Seiscentos petabytes. Por dia. A Anthropic mantinha centenas de mirrors internos do Git só pra aguentar, e mesmo assim o sistema estava no limite.

O Git foi projetado nos anos 2000 para um mundo onde desenvolvedores trabalham offline, fazem commits locais e eventualmente sincronizam com o servidor. Cada clone carrega o histórico completo. Cada push recalcula packfiles. Cada merge assume que conflitos são raros e resolvidos por humanos.

Quando Linus Torvalds criou o Git em 2005, o cenário era claro: dezenas ou centenas de desenvolvedores contribuindo para o kernel Linux, cada um com seu fork, fazendo push de patches. O protocolo de fetch funciona assim: o cliente diz ao servidor “tenho esses objetos, me manda o que falta”. Isso é elegante quando você tem um desenvolvedor fazendo pull uma vez por dia. Mas quando você tem milhares de agentes de IA fazendo isso a cada poucos segundos, o servidor precisa calcular o delta pra cada um. É como se o garçom tivesse que decorar o pedido individual de 25 milhões de clientes por dia.

Agora imagina centenas de instâncias do Claude codando em paralelo, 24 horas por dia, cada uma precisando de acesso ao repositório. O modelo distribuído do Git, que é uma das suas maiores qualidades, virou o gargalo. E não é um gargalo que se resolve com mais hardware. É uma limitação arquitetural.

Scion: O Git ao Contrário

O Scion inverte basicamente tudo o que você conhece sobre Git. A filosofia central é uma frase que soa óbvia mas muda tudo: “clientes estão sempre online”.

Se o cliente está sempre conectado, por que ele precisa de uma cópia completa do repositório? Resposta: não precisa.

No Scion:

• Commits acontecem no servidor. Não existe “commit local” seguido de push. O cliente envia as mudanças, o servidor cria o commit. Sem push, sem conflito de push.
• Checkouts são sparse por padrão. Você baixa só os diretórios que precisa. Quer trabalhar em src/api/? Baixa só isso. O resto não existe no seu disco.
• Checkouts virtualizados. Alguns workloads nem precisam de checkout: materializam arquivos sob demanda ou operam 100% via API.
• Nenhum packfile. O Git comprime objetos em packfiles que crescem com o repositório e precisam de manutenção. No Scion, cada objeto é armazenado com endereçamento por conteúdo em blob storage distribuído.
• Sem refs globais. O Git depende de refs (branches, tags) como estado global que todos os servidores precisam concordar. No Scion, refs globais são desencorajados porque “estado global que todo servidor precisa concordar é um problema de escala à espreita.”

Comparando lado a lado:

A Unidade Fundamental: Changesets

Se o Git tem commits referenciando tree objects, o Scion tem changesets. Um changeset é uma entrada num write-ahead log que armazena a lista de arquivos modificados em relação ao primeiro pai, junto com ponteiros content-addressed para blob storage comprimido.

A sacada aqui é que aceitar um changeset no servidor não exige packfiles, locking ou coordenação entre servidores. Isso permite throughput alto sem gargalos.

O sistema ainda computa dados derivados (blame, histórico de path, skip lists no grafo de commits) através de um mecanismo recursivo genérico. Esses dados podem ser computados eagerly ou lazy, permitindo otimizações sem mexer no cliente.

Arquitetura de Cache em Três Camadas

O Scion usa uma arquitetura de cache hierárquica que mantém taxa de hit acima de 99%:

Camada 1: scion-daemon

Roda em cada nó. Armazena objetos para toda a máquina. Inicializa a partir de snapshots periodicamente renovados.

Camada 2: scion-cache

Servidores de cache regionais que fazem streaming de objetos diretamente da memória em formato de disco.

Camada 3: scion-server

Servidores autoritativos lendo do Spanner ou cloud storage.

A Anthropic impõe rigorosamente o tiering entre camadas. Nenhuma camada pula direto para outra. Se o scion-cache regional falha, ele não pode sobrecarregar os scion-servers e derrubar o sistema inteiro.

O protocolo do cliente scn também é radicalmente diferente do Git. Em vez de dizer ao servidor “tenho esses objetos, me manda o que falta” (como o fetch do Git), o cliente pede árvores e blobs específicos. A partir de uma root tree, ele requisita recursivamente os objetos que não tem. Isso permite caches tradicionais em camadas, consumindo significativamente menos CPU no servidor que o Git.

Os Números do Resultado

Depois de cinco meses de desenvolvimento, os resultados:

• Footprint de infraestrutura: 200x menor que os mirrors do Git em CPU e memória
• Velocidade de checkout: duas ordens de magnitude mais rápido (segundos em vez de minutos)
• CPU do CI: redução de 25%
• Cache hit rate: acima de 99% em todas as camadas
• Consumo de memória: 20x menor no pipeline de ingestão git-to-Scion
• Velocidade de ingestão: 4x mais rápido

E isso foi construído por sete engenheiros. Sete. Incluindo o Antique, a ferramenta de code review que acompanha o Scion.

O Antique e o Problema do Code Review

O Antique é o sistema de code review da Anthropic, construído junto com o Scion no mesmo período de cinco meses. Ele inclui:

• Controle de acesso granular por diretório
• Distinção semântica entre mudanças “só comentário” e mudanças lógicas sensíveis
• Mecanismos de landing para volumes grandes de código revisado
• Busca integrada de código

Quando você tem 30.000 merges por dia, o conceito de CI tradicional não faz sentido. Como a Anthropic mesmo pergunta: “O que CI sequer significa quando centenas ou milhares de mudanças podem ser mergeadas enquanto os testes estão rodando?”

A resposta deles: testes pós-merge e pré-deploy automatizados. E quando conflitos surgem, Claude tipicamente resolve mais rápido do que humanos conseguem identificar.

Claude Construindo o Sistema que Claude Precisava

Tem uma ironia deliciosa aqui. O Claude gerou tanto código que o Git não aguentou, então a Anthropic usou o Claude para construir o sistema que substituiu o Git.

O caso mais impressionante: quando o Claude Mythos Preview ficou disponível internamente, a equipe pediu para ele otimizar o pipeline de ingestão git-to-Scion que tinha sido escrito à mão. O resultado? 20x menos memória e 4x mais rápido, preservando todas as invariantes de ordenação e estruturas de dados.

E aqui vem a parte que vai incomodar muito dev: todos os engenheiros que trabalharam no Scion classificam o Claude como melhor em escrever código do que eles mesmos. Todos. Mas esses mesmos engenheiros foram essenciais por um motivo diferente: entendimento de alto nível dos componentes inter-sistemas e trade-offs de design.

O papel do engenheiro mudou. Em vez de escrever código, o trabalho passou a ser dizer “não” quando os agentes violavam restrições fundamentais. Definir constraints, não digitar.

Superfans: Agentes que Obsessivamente Monitoram

A equipe criou um conceito chamado “superfans” usando o Claude Tag: instâncias do Claude atribuídas a monitorar obsessivamente componentes individuais do sistema. Existe um superfan do scion-daemon, um superfan do scion-cache, e por aí vai. Cada um analisa telemetria e logs continuamente.

Quando você para pra pensar, é um sistema construído por IA, para IA, monitorado por IA. O loop se fecha de um jeito que faz a gente repensar o que “infraestrutura de desenvolvimento” vai significar daqui pra frente. Quem mantém o sistema não é um time de SREs olhando dashboards. São agentes especializados reagindo a anomalias em tempo real, sem fadiga, sem hora do almoço.

O Que Isso Significa Pro Resto de Nós

A Anthropic é clara: o Scion não é pra uso geral. Nas palavras deles, “os conceitos que descrevemos aqui só fazem sentido para monorepos verdadeiramente enormes, com dezenas de milhares de engenheiros ou enxames de agentes escrevendo código prolificamente.”

Mas aí vem o aviso que importa: a Anthropic projeta que esse desafio de escala vai se tornar comum nos próximos 6 a 12 meses para times que usam agentes de IA pesadamente.

Se você está num time de 5 pessoas usando Claude Code ou Copilot Workspace, relaxa. Git funciona perfeitamente. Mas se a sua empresa está começando a escalar agentes de IA para gerar código em massa, vale prestar atenção.

A Anthropic sugere que os servidores Git não precisam funcionar do mesmo jeito que os clientes Git. Arquiteturas de servidor inovadoras podem trazer melhorias significativas de escala. Plataformas Git (GitHub, GitLab) poderiam fornecer RPCs server-side abrangentes, talvez até padronizados entre forges.

Google, Meta e Microsoft Já Passaram Por Isso

Se você acompanha engenharia de infra, esse papo não é 100% novo. O Google tem o Piper, um monorepo que guarda bilhões de linhas de código com um sistema de controle de versão customizado desde os anos 2010. A Meta usa o Sapling, um fork do Mercurial otimizado para escala. A Microsoft construiu o VFS for Git (agora chamado Scalar) porque o repositório do Windows tinha mais de 300 GB.

A diferença é que essas empresas levaram anos para chegar nesse ponto, com equipes de centenas ou milhares de engenheiros humanos empurrando o limite gradualmente. A Anthropic foi de 2.500 para 30.000 merges em cinco meses. Não foram humanos sendo contratados. Foram agentes de IA sendo ligados.

Essa velocidade de escalonamento é inédita. E ela coloca uma pergunta interessante na mesa: se a infraestrutura de desenvolvimento foi desenhada para a velocidade humana, o que acontece quando agentes de IA se tornam os contribuidores majoritários de um codebase?

O Git Vai Morrer?

Não. Ponto.

O Git é perfeito para 99,9% dos casos de uso. Open source, times distribuídos, projetos de qualquer tamanho razoável. O Linus Torvalds sabia o que estava fazendo.

Mas o que o caso da Anthropic mostra é que estamos entrando numa era onde a velocidade de geração de código supera a capacidade das ferramentas que construímos para gerenciá-lo. Quando o gargalo deixa de ser “quão rápido humanos escrevem código” e passa a ser “quão rápido a infraestrutura processa código”, as premissas mudam.

O Scion é um sinal. Não de que o Git está obsoleto, mas de que a escala dos agentes de IA está criando problemas que ninguém tinha previsto. E se a Anthropic, com toda a sua expertise, precisou de um sistema completamente novo, empresas menores que tentarem escalar agentes sem pensar em infraestrutura vão bater numa parede.

A própria Anthropic projeta que esse desafio vai se tornar comum nos próximos 6 a 12 meses para empresas que usam agentes de IA pesadamente. Eles sugerem que plataformas como GitHub e GitLab poderiam implementar RPCs server-side mais robustos, quem sabe até padronizados entre forges. É uma forma educada de dizer “vocês vão precisar se reinventar também”.

Quanto tempo até o GitHub ou o GitLab lançarem features inspiradas no Scion? Meu chute: menos de um ano. E quando isso acontecer, lembre que sete engenheiros na Anthropic já tinham resolvido o problema antes.