A Anthropic diz que seu monorepo interno passou de cerca de 2.500 alterações integradas por dia em maio para mais de 30 mil em setembro de 2026. Seu relato de engenharia de 13 de outubro apresenta o Scion, um sistema de controle de código-fonte criado para os agentes e tarefas automatizadas por trás de boa parte desse crescimento. A questão de engenharia útil é: que trabalho ainda cabe ao cliente quando um serviço central pode cuidar do histórico, dos commits e dos merges?

A grande mudança

  • O que mudou: A Anthropic migrou seu monorepo do Git para o Scion em cinco meses. Os clientes Scion buscam apenas os objetos necessários e deixam commits, merges, rebases e consultas de histórico para um servidor. A Anthropic o construiu para uma carga dominada por agentes e tarefas online.
  • Por que importa: Uma tarefa de CI pode pedir um diff ou uma base de merge por API, sem manter um repositório local. Quando precisa de arquivos, um checkout parcial ou virtualizado limita o que chega ao disco. Isso transfere custos e responsabilidade operacional para o serviço central.
  • O que observar: A Anthropic relata checkouts mais rápidos e menor uso de infraestrutura em sua própria frota, sem validação independente aqui. A empresa diz que o Scion é um sistema interno personalizado e que a migração também exigiu mudanças em revisão de código, busca e CI.

Por que o Git ficou caro neste monorepo

O projeto distribuído do Git dá a cada clone completo o histórico e os objetos necessários para trabalhar offline. A Anthropic diz que o histórico da ramificação principal de seu monorepo está perto de 100 GB, enquanto uma cópia de trabalho comprimida supera 25 GB. Sua frota de CI faz cerca de 25 milhões de checkouts de código por dia, sem contar ambientes de desenvolvimento, sandboxes de agentes e tarefas de pesquisa. Esses são números da carga da Anthropic, não um limite geral a partir do qual o Git deixa de funcionar.

A empresa já usava clones superficiais, checkouts parciais, espelhos internos e snapshots do repositório. Segundo ela, algumas centenas de espelhos se tornaram difíceis de operar conforme o repositório e o ritmo de merges cresceram. O diagnóstico da Anthropic foi específico: a maioria de seus clientes já eram agentes ou tarefas online, mas as ferramentas ainda arcavam com grande parte do custo de manter um repositório local.

O Scion assume essa conexão online como premissa de projeto. O relato de engenharia diz que o servidor responde a consultas de histórico e autoria de alterações, cria commits e executa merges e rebases. O cliente mantém um cache limitado de objetos, grava no disco os arquivos de trabalho solicitados e monitora alterações locais. Abrir mão da capacidade de executar essas operações de forma independente é uma escolha deliberada para enviar menos dados a cada cliente.

Um checkout pode ser menor ou desnecessário

O Scion expõe por APIs as consultas de controle de código-fonte usadas por seus clientes. A Anthropic diz que uma tarefa de CI que precisa de um diff a partir de uma base de merge pode perguntar diretamente ao servidor. Seus pipelines automatizados de bisect e revert usam o mesmo caminho programático. Para essas tarefas, talvez o job nem precise materializar uma cópia de trabalho.

Quando uma tarefa precisa de arquivos, o Scion oferece checkouts parciais contendo apenas os diretórios solicitados e checkouts virtualizados, que materializam arquivos quando são lidos. O cliente pede recursivamente árvores e blobs específicos que faltam, em vez de negociar um packfile grande. Cada objeto solicitado tem uma identidade imutável endereçada pelo conteúdo, permitindo que caches o retornem sem verificar se o conteúdo mudou. A Anthropic descreve um daemon por nó e caches regionais entre clientes e servidores autoritativos; todas as camadas usam o mesmo protocolo de solicitação de objetos.

Esse projeto estabelece limites de falha e manutenção diferentes dos de um clone local completo. O cliente depende do serviço para operações que o Git pode fazer offline, e o serviço precisa fornecer consultas de objetos e histórico no ritmo da frota. A Anthropic diz que aplica camadas de cache, em parte, para impedir que uma falha regional sobrecarregue os servidores upstream. O artigo não traz medidas de disponibilidade dessa arquitetura.

O que o servidor armazena e calcula

A unidade de trabalho do Scion é um changeset em um log write-ahead. A Anthropic diz que ele registra arquivos alterados em relação a um primeiro pai, com ponteiros para conteúdos comprimidos no armazenamento de blobs. O servidor cria changesets sem mover um ponteiro de ramificação compartilhado a cada gravação. Estruturas derivadas separadas dão suporte a consultas como autoria de alterações em arquivos, histórico de caminhos e ancestralidade de commits; a Anthropic pode calcular algumas imediatamente e adiar outras.

Essa separação importa para o projeto da API. Tarefas podem pedir uma base de merge ou o histórico de um arquivo sem carregar todas as estruturas necessárias para calcular a resposta localmente. O custo de manter essas estruturas também passa para o serviço da Anthropic. A empresa diz que distribui os dados do repositório e escala componentes de forma independente, sem uma cópia totalmente materializada do repositório nem mesmo no servidor.

A Anthropic relata que a infraestrutura do Scion usa 200 vezes menos CPU e memória que sua configuração anterior de espelhamento Git, e que checkouts de CI e pesquisa agora levam segundos, não minutos. A empresa atribui à mudança um ganho de 25% na capacidade de CPU da CI. As comparações são com o sistema interno anterior da Anthropic, sob sua própria carga; a BIG CHANGE não reproduziu as medições nem examinou a telemetria subjacente.

O custo da migração faz parte do resultado

A Anthropic diz que sete engenheiros construíram o Scion, a ferramenta complementar de revisão de código Antique e sistemas relacionados, e migraram o monorepo em cinco meses. O relato também descreve uma nova busca de código, controle de acesso e mudanças na forma como o código é revisado e integrado. Uma organização que avalia o projeto precisa considerar esses fluxos de trabalho adjacentes, além do próprio serviço de controle de código-fonte.

A Anthropic afirma explicitamente que o Scion não serve como substituto geral do Git. Seus componentes internos de revisão, busca e CI são personalizados, e abandonar o Git exigiria mudanças em todo o ciclo de desenvolvimento. A lição mais restrita do relato é arquitetural: um serviço online pode responder a mais perguntas de controle de código-fonte para clientes automatizados, enquanto esses clientes mantêm apenas os arquivos que usam. A Anthropic sugere que algumas ideias, como APIs de servidor mais ricas e uma combinação melhor dos recursos sparse e shallow do Git, poderiam ser aplicadas sem adotar o Scion.

Fontes e leituras adicionais

  • Anthropic Engineering, “Redesigning source control at Anthropic” (13 de outubro de 2026). Relato de primeira mão da Anthropic sobre a arquitetura do Scion, a migração e os números internos de carga e desempenho. A BIG CHANGE não verificou de forma independente as medições e os resultados operacionais relatados; nenhum sistema Scion foi testado para este artigo.