Pular para o conteúdo

Anthropic troca o git pelo Scion quando os merges passam de 30.000 por dia

A Anthropic tirou seu monorepo do git e o levou para o Scion, um sistema de controle de versão interno, depois que os merges diários subiram de cerca de 2.500 em maio de 2026 para mais de 30.000.

Por Tech AI Wire Team

4 min de leitura

XLinkedIn
O post de engenharia da Anthropic Redesigning source control at Anthropic, publicado em 13 de outubro de 2026, descrevendo sua mudança para um sistema de controle de versão interno.

Em números

code changes merged per day in September, up from about 2,500 in May
30,000+
size of the main branch's history
~100 GB
less CPU and memory than the old git mirrors, per Anthropic
~200x
to migrate, with a team of seven
5 months

A Anthropic tirou seu principal repositório de código do git e o levou para o Scion, um sistema de controle de versão que ela mesma construiu. A empresa diz que mesclava cerca de 2.500 alterações de código por dia em maio de 2026 e mais de 30.000 por dia em setembro. O The Register liga esse salto ao Claude escrevendo uma parte maior do código da empresa. O git é construído sobre a ideia de que cada cópia guarda o histórico completo. Isso deixou de fazer sentido quando quase todo usuário passou a ser um agente de IA sempre online. A Anthropic descreveu o sistema em 13 de outubro, mas não vai liberá-lo.

Por que o git deixou de funcionar

“O gargalo, agora, é toda a infraestrutura de desenvolvimento construída para a escala humana”, escreve a Anthropic em seu post de engenharia. Escrever código já não é a parte lenta. As partes lentas são o controle de versão, os builds e a integração contínua (CI), os testes automatizados que rodam a cada alteração.

O repositório é um monorepo, um único repositório que guarda a maior parte do código da empresa. Seu tamanho explica a sobrecarga:

MedidaNúmero
Histórico do branch principalQuase 100 GB
Cópia de trabalho comprimidaMais de 25 GB
Checkouts por dia só para CICerca de 25 milhões
Tráfego git se cada checkout fosse um clone simplesMais de 600 PB por dia
Espelhos internos de git no picoVárias centenas

A Anthropic tentou as soluções de costume. Usou clones rasos (shallow) e esparsos (sparse), que baixam só parte de um repositório, além de espelhos internos e cópias pré-montadas. Cada uma ficou mais difícil de manter à medida que os merges aumentavam. As cópias pré-montadas se afastavam do branch principal, e ferramentas como diff e blame quebravam em clones parciais.

Como o Scion funciona

O Scion parte do princípio de que seus clientes estão sempre online. O servidor cuida do histórico, do blame, dos commits, dos merges e dos rebases. Cada máquina guarda só um cache local limitado e sua cópia de trabalho, os arquivos que ela está de fato editando.

Cada alteração é armazenada como um changeset em um write-ahead log, um registro contínuo de alterações. Ele lista os arquivos que mudaram e aponta para o conteúdo deles no armazenamento de blobs. Os arquivos são buscados sob demanda. Assim, um checkout nunca precisa baixar antes um pacote de vários gigabytes.

O Scion funciona em três camadas: um daemon em cada máquina, um cache em cada região e um servidor autoritativo. A Anthropic diz que cada camada de cache responde a mais de 99% das requisições. O uso de branches além do main e dos branches de release é desencorajado.

O Scion não é um substituto direto do git. Nick G., engenheiro do Scion, explicou essa troca no Hacker News, em trecho citado por Simon Willison. “Como o Claude é de longe o maior usuário do Scion e está necessariamente online, isso simplesmente não era importante de fazer”, escreveu ele. Willison compara o resultado a sistemas centralizados mais antigos, como o Subversion.

O que a Anthropic diz ter ganhado

A Anthropic relata estes resultados em repositórios que rodam nativamente no Scion:

  • Cerca de 200 vezes menos CPU e memória que seus antigos espelhos de git.
  • Checkouts de CI e de pesquisa cerca de 100 vezes mais rápidos, levando segundos em vez de minutos.
  • Um corte de 25% na CPU que seu sistema de CI usa.

Sete pessoas construíram o Scion, uma ferramenta de revisão de código chamada Antique e cerca de meia dúzia de sistemas relacionados. A migração levou cinco meses. O The Register informa que o trabalho no Scion começou em janeiro de 2026.

As outras ferramentas incluem busca de código, permissões de acesso por diretório e uma forma de integrar alterações sem uma fila de merge global única. A equipe as construiu com a ajuda do Claude. Uma reescrita feita pelo Claude do pipeline inicial de importação do git para o Scion usou 20 vezes menos memória e rodou quatro vezes mais rápido, diz a Anthropic.

Pessoas ainda conduziam o trabalho. “Muitas vezes, descobrimos que o papel dos engenheiros era dizer ‘não’ ao Claude”, disse a Anthropic, em trecho citado pelo The Register.

Alguém mais vai ter o Scion?

Não. A Anthropic diz que é difícil oferecer o Scion de uma forma amplamente útil. Diz também que ele não é adequado para uso geral. Em vez disso, a empresa está compartilhando o design e diz que quer trabalhar com o GitHub, o GitLab e a comunidade de código aberto.

O post sugere ideias que os serviços de hospedagem de git poderiam adotar sem mudar o funcionamento do git. Entre elas estão fazer mais trabalho no servidor e facilitar a combinação de clones esparsos e rasos. O próprio git também está mudando: cobrimos o debate sobre o padrão SHA-256 do Git 3.0 no começo deste mês.

O que isso significa para desenvolvedores

  • O git ainda serve para a maioria das equipes. O The Register observa que o git continua sendo a escolha certa para a maioria dos repositórios. O Scion resolve um problema que aparece com dezenas de milhares de merges por dia.
  • Acompanhe os custos de checkout de CI à medida que os agentes escalam. Cerca de 25 milhões de checkouts por dia foi o que quebrou o git aqui. Se seus agentes clonam o repositório a cada tarefa, meça esse tráfego agora.
  • Trate agentes como clientes sempre online. Cópias offline importam para pessoas, não para agentes rodando na nuvem. Ferramentas que buscam arquivos sob demanda podem reduzir o custo de cada execução de agente.
  • Espere que os serviços de hospedagem de git adotem essas ideias. A Anthropic quer que o GitHub e o GitLab adotem partes do design. Operações no servidor e clones parciais melhores são os primeiros passos prováveis.
  • Mantenha humanos na revisão. Os engenheiros da Anthropic passaram boa parte do tempo rejeitando sugestões do Claude. Planeje essa carga de revisão quando agentes escreverem a maior parte do código.

Fontes

  1. Redesigning source control at Anthropic - Anthropic
  2. Anthropic reinvents source control as Claude floods the world with code - The Register

Artigos relacionados