O Git não vai acabar: o que a Anthropic m…

No dia 13 de outubro publiquei no LinkedIn um post com o título “E A IA ACABOU TAMBÉM COM O GIT…”. O texto resumia um artigo da Anthropic: a empresa passou a fazer mais de 30 mil merges por dia, o Git deixou de dar conta e, em cinco meses, eles montaram um sistema próprio de controle de versões, o Scion.

O título foi escolhido para provocar, e a polêmica veio. Mas vale dizer logo: o Git não vai acabar. Este texto é a versão com nuance que o título não cabia.

Note

Resumo: a Anthropic migrou o seu monorepo do Git para o Scion porque quase todos os clientes do repositório viraram agentes e jobs sempre online. A própria Anthropic diz que o Scion não é um substituto do Git para uso geral.

O que a Anthropic publicou

O artigo Redesigning source control at Anthropic saiu no blog de engenharia da empresa em 13 de outubro de 2026. Os números são os que chamaram atenção:

Em maio de 2026 eram cerca de 2.500 mudanças mergeadas por dia no monorepo. Em setembro, mais de 30 mil.
O histórico da branch principal tem quase 100 GB, e uma cópia de trabalho comprimida passa de 25 GB.
São da ordem de 25 milhões de checkouts por dia só para CI. Feito do jeito ingênuo, isso daria mais de 600 PB de tráfego Git por dia.
No pico, a empresa operava várias centenas de mirrors internos de Git para aguentar a carga.

Junto com o Scion, o mesmo time construiu uma ferramenta de code review chamada Antique, busca de código e um sistema de permissões para o controle de versões. Segundo a Anthropic, sete pessoas fizeram isso em cinco meses, usando o Claude para escrever a maior parte do código.

O que muda no Scion

O ponto central não é “o Git é ruim”. É que o Git foi desenhado para clientes que trabalham offline, cada um com uma cópia completa do repositório. Na Anthropic, quase todos os clientes são agentes e jobs, que estão sempre online por definição. A empresa já usava o Git como um sistema centralizado, com uma cópia autoritativa.

Daí saem os princípios do Scion:

Cliente sempre online. O cliente busca os dados quando precisa, em vez de guardar tudo.
Servidor faz o trabalho pesado. Commits, merges, rebases, histórico e blame acontecem no servidor. Não existe push.
Tudo exposto por API. Um job de CI pode pedir um diff ao servidor sem ter o repositório na máquina.
Checkout opcional e esparso. Quando precisa de arquivos em disco, o cliente só baixa o que lê.

O resultado, pelos números da empresa: infraestrutura 200 vezes menor em CPU e memória do que a dos mirrors de Git, checkouts de CI e pesquisa em segundos em vez de minutos, e 25% de capacidade de CPU liberada no CI.

A Anthropic também dá crédito a quem veio antes. O artigo cita o Piper, do Google, e o Sapling, da Meta, em especial o servidor Mononoke, como referências para as técnicas usadas.

Por que o título provocou

Porque ele inverte o que a própria fonte diz. O artigo afirma, com todas as letras, que o Scion “is by no means a suitable replacement for git for general use”. Os conceitos só fazem sentido para monorepos enormes, com dezenas de milhares de engenheiros ou enxames de agentes escrevendo código. A empresa também reconhece que gasta tokens internamente num volume que nenhum outro negócio gastaria.

E o Scion não está disponível. A Anthropic explica que ele diverge muito do Git e exige code review, busca e CI próprios, então não faria sentido lançar uma versão pública. A The New Stack resumiu bem no título: a Anthropic construiu um substituto do Git, mas você não pode usar.

O título chamativo funcionou como pergunta. A resposta é não.

Por que o Git fica

O que os agentes precisam continua sendo o que o Git oferece: versionar, comparar, revisar e voltar atrás. O Scion não acaba com nada disso. Ele muda onde essas operações rodam.

A própria Anthropic aponta o caminho para o ecossistema. A proposta é levar as partes que deram certo no Scion para dentro do Git, sem abandonar o modelo: servidores Git que não funcionem igual ao cliente, APIs no lado do servidor, talvez padronizadas entre as forjas, e recursos de checkout esparso e raso que se combinem melhor. O artigo fala em trabalhar com GitHub, GitLab e a comunidade open source, e reconhece quase duas décadas de trabalho da comunidade escalando o Git.

O que muda de verdade com agentes

A parte mais útil do artigo, para quem não tem 30 mil merges por dia, está nas lições:

O gargalo saiu do código. Escrever código deixou de ser o limite. O limite virou a infraestrutura feita para escala humana: controle de versões, build e CI.
Merge queue perde sentido. Com centenas de mudanças entrando enquanto os testes rodam, a Anthropic trocou o lock global da fila por testes automatizados depois do merge e antes do deploy. Conflitos acontecem, e o Claude resolve.
Revisão muda de foco. Os engenheiros ainda revisam cada mudança do sistema, mas olham a intenção da mudança, não cada linha. E muitas vezes o papel deles foi dizer “não” ao Claude quando ele violava uma restrição do sistema.
Permissão fina vira requisito. O Scion aplica permissões por diretório, e o code review distingue mudança só de comentário de mudança lógica sensível.

A Anthropic estima que esse tipo de problema fique comum nos próximos 6 a 12 meses. Vale prestar atenção, mesmo usando Git.

Era isso que eu queria dizer quando escrevi que é mais um sinal para repensar o dia a dia. Não é trocar de ferramenta. É olhar para o pipeline inteiro como se o principal usuário dele fosse um agente.

Se o tema te interessa, escrevi antes sobre vibe coding e engenharia de contexto e sobre IA como alavancagem, a partir de um commit do Linus Torvalds.