A Anthropic trocou o git pelo Scion. O que muda pra você

A Anthropic trocou o git por um sistema de controle de versão próprio, o Scion, depois que o código escrito por agentes levou o monorepo da empresa de 2.500 merges por dia em maio de 2026 pra mais de 30.000 em setembro. Sete engenheiros construíram tudo em cinco meses. A lição pra todo mundo não é "faça o seu próprio git" — é que código gerado por agente quebra o seu pipeline de entrega muito antes de quebrar o seu produto, e o pipeline é justamente onde quase ninguém investiu.

O que o Scion é — e o que ele não é

Scion é um sistema de controle de versão centrado no servidor, feito pra um único monorepo dentro da Anthropic. Ele inverte a premissa fundadora do git. O git é offline-first e entrega uma cópia completa do histórico pra cada cliente; o Scion assume que os clientes estão sempre online, porque a maioria deles são jobs de CI e agentes de código, não notebooks dentro de um avião.

As decisões de arquitetura, segundo o artigo de engenharia da Anthropic:

• Histórico com autoridade no servidor. Blame, histórico de arquivo, merges e commits são respondidos pelo servidor, não reconstruídos a partir de um clone local.
• API-first. Toda consulta de controle de versão é exposta por API, então as ferramentas não mantêm repositório local nenhum.
• Checkout esparso e virtualizado. O cliente baixa só os diretórios que pediu; os arquivos se materializam sob demanda.
• Três camadas de cache. Um daemon no nó, um cache regional e os servidores autoritativos — cada camada com taxa de acerto acima de 99%.
• Sem merge queue. As mudanças entram em paralelo e os conflitos são resolvidos depois.

O que o Scion não é: disponível pra você. A Anthropic diz com todas as letras que ele "não é, de forma alguma, um substituto adequado do git pra uso geral", e não vai abrir o código. A recomendação deles pro ecossistema é mais estreita e muito mais útil: servidor de git não precisa funcionar como cliente de git. As forges podem oferecer RPCs server-side e uma arquitetura de servidor melhor sem pedir a ninguém que abandone o git.

Os números que forçaram a reescrita

Clone raso, checkout esparso e snapshots de seed ajudaram — e todos chegaram no limite. No pico, a Anthropic mantinha algumas centenas de mirrors internos de git só pra servir clones. O repositório não virou um caso patológico porque o produto ficou complicado; virou porque a taxa de mudança multiplicou por doze em quatro meses.

O gargalo real é review, CI e merge

A frase mais importante do artigo não é sobre armazenamento. É esta: "uma merge queue de verdade... não faz muito sentido em escala de agente. O que é CI, afinal, quando centenas ou milhares de mudanças podem entrar enquanto os testes estão rodando?"

Essa pergunta não tem nada a ver com git e tudo a ver com o seu pipeline. Uma merge queue é um lock global. Ela serializa a integração pra que cada commit seja testado exatamente contra o estado em que vai cair. É um bom trade quando você faz 20 merges por dia. Em 200, ela vira o caminho crítico. Em 2.000, é simplesmente impossível — o teto de throughput da fila é o teto de throughput da sua engenharia, não importa quão rápido os agentes escrevam.

A resposta da Anthropic foi parar de serializar: mudanças entram em paralelo, o teste vai pra depois do merge e os conflitos são reparados automaticamente. Nas palavras deles, "mudanças concorrentes podem conflitar, mas o Claude normalmente resolve esses conflitos mais rápido do que humanos conseguem nem identificar".

Você não precisa concordar com esse trade-off. Mas precisa saber onde está o seu teto, porque os agentes vão encontrá-lo.

O que fazer se você não é a Anthropic

Você quase certamente não deveria construir um controle de versão. Deveria fazer o trabalho sem glamour que compra a mesma folga:

1. Instrumente throughput, não output. Acompanhe merges por dia, tempo de espera na fila, tempo de CI verde até produção e taxa de revert. Linha de código escrita por agente é métrica de vaidade; mudança mergeada e que sobreviveu é a métrica real.
2. Ache os seus locks globais. Uma merge queue, um único ambiente de staging, uma aprovação manual de release, uma pessoa que revisa tudo. Cada um é um ponto de serialização que limita o throughput independentemente de quanto código é gerado antes.
3. Deixe o CI seletivo e cacheado. Análise de impacto de teste, cache remoto de build e checkout esparso já são ferramental padrão. Os 25% de CPU que a Anthropic recuperou vieram de parar de fazer trabalho redundante, não de comprar máquina.
4. Reduza o custo de estar errado. Revert rápido e sem drama, feature flags e rollout progressivo valem mais que certeza pré-merge quando o volume sobe. Se desfazer uma mudança ruim é barato, você pode se permitir mergear no otimismo.
5. Gaste review humano no raio de dano. Fronteiras de autenticação, migrações de dados, caminhos de pagamento, qualquer coisa que toque dado de cliente. Formatação, nomenclatura e refactor mecânico são exatamente o que linter e máquina deveriam assumir.

É esse o trabalho que a gente faz quando leva software construído com IA pra produção: achar os pontos de serialização, endurecer os caminhos que realmente machucam e fazer o pipeline sobreviver ao volume. Dá pra ver como a gente escopa isso em nosso trabalho.

O papel que não foi automatizado

A parte do artigo da Anthropic que merece mais atenção não tem nada a ver com controle de versão. Todos os engenheiros do time do Scion hoje diriam que o Claude escreve código melhor que eles. E ainda assim foram os humanos que trouxeram o "entendimento dos componentes de alto nível entre sistemas e dos trade-offs de design", e a função principal deles, como o próprio texto diz, passou a ser dizer "não" pro Claude quando uma restrição era violada.

Repare também no que esse time não pulou. Em cinco meses, com sete pessoas, eles construíram simulações herméticas de toda interação não trivial de infraestrutura e controle de versão, além de fuzzing e rate limiting sofisticado. A velocidade veio do rigor de teste, não de abrir mão dele. É o oposto de como a maioria dos projetos acelerados por IA se comporta — e é exatamente por isso que esse foi em pé.

Geração virou abundante; julgamento é o que ficou escasso — a mesma realocação que a gente mapeou em quem leva pra produção quando o protótipo é de graça, agora visível na infraestrutura. A habilidade escassa é saber qual restrição importa e estar disposto a impor ela — e é por isso que a gente constrói produtos construindo pessoas em vez de alugar hora.

O git também é só a primeira ideia consolidada a bater no prazo de validade em público. A versão mais ampla desse argumento — o que mais a gente ainda trata como lei e já virou preferência — está em toda ideia consolidada tem prazo de validade.

Principais conclusões

• A Anthropic construiu o Scion, um substituto do git centrado no servidor, porque código gerado por agentes levou o monorepo de 2.500 pra mais de 30.000 merges por dia entre maio e setembro de 2026.
• O Scion não é open source nem serve pra uso geral; a ideia portátil é que servidor de git não precisa funcionar como cliente de git.
• O controle de versão era o sintoma. O problema estrutural é que merge queue, CI e review humano são pontos de serialização que limitam o throughput em escala de agente.
• A Anthropic espera que times em escala muito menor batam nesses limites em seis a doze meses.
• O trabalho humano de maior alavancagem no projeto foi julgamento de design e dizer "não" — não escrever código.

FAQ

O que é o Scion?

Scion é o sistema de controle de versão interno da Anthropic, criado pra substituir o git no monorepo principal. Ele é centrado no servidor: histórico, blame e merges são servidos por uma API sempre acessível em vez de reconstruídos de um clone local completo, e os checkouts são esparsos e virtualizados.

O Scion é open source ou posso usar?

Não. A Anthropic afirmou que não vai abrir o código e que o Scion "não é, de forma alguma, um substituto adequado do git pra uso geral". Adotá-lo exigiria migrar todo o ciclo de desenvolvimento. A sugestão deles é que as forges de git adotem melhorias server-side compatíveis.

Por que o git parou de funcionar na Anthropic?

Volume, não complexidade. Cerca de 100 GB de histórico na branch principal, working copy acima de 25 GB e aproximadamente 25 milhões de checkouts de CI por dia. Servir isso sem otimização daria mais de 600 petabytes de tráfego diário, e no pico a Anthropic rodava algumas centenas de mirrors internos de git pra dar conta.

Meu time deveria trocar o git?

Quase certamente não. Abaixo da escala da Anthropic, o ganho está em CI seletivo, cache de build, checkout esparso, mudanças menores e remoção de pontos de serialização como uma merge queue global única. Trocar o controle de versão é o último recurso, não o primeiro passo.

O que quebra primeiro quando agentes escrevem a maior parte do código?

A merge queue e a capacidade de CI, seguidas pela banda de review humano. Os três são processos serializados logo depois de uma etapa de geração que acabou de ficar muito mais rápida.

Quanto tempo os times têm?

A Anthropic espera que esses problemas de escala se tornem comuns em seis a doze meses. A preparação barata é medição: saiba seus merges por dia, o tempo de espera na fila e a taxa de revert antes de o volume chegar.