Anthropic troca Git por Scion: o que 30 mil mudanças por dia ensinam sobre criar com IA

A Anthropic substituiu o Git pelo Scion no seu repositório principal depois que o volume de alterações integradas passou de cerca de 2.500 por dia, em maio, para mais de 30 mil em setembro de 2026. O motivo, segundo a empresa, foi o aumento da produção de código com Claude: guardar, distribuir, testar e juntar esse trabalho virou um gargalo.

O relato oficial saiu em 13 de outubro e ganhou nova cobertura em 14 de outubro. Esta é uma leitura do caso para quem cria produtos com IA, com os números atribuídos à Anthropic e uma ressalva que muda a interpretação da notícia: a própria empresa diz que o Scion não serve como substituto geral do Git.

Por que a Anthropic decidiu substituir o Git?

A Anthropic descreve uma combinação incomum: um repositório enorme, dezenas de milhões de operações diárias para preparar arquivos e agentes produzindo alterações continuamente. Nesse cenário, o custo de manter cópias e distribuir o histórico passou a limitar o trabalho, segundo o texto da equipe de engenharia.

Git é o sistema que guarda versões do código e permite comparar alterações, voltar a uma versão anterior e juntar contribuições de pessoas diferentes. No modelo distribuído, uma cópia completa também pode consultar o histórico e trabalhar sem conexão permanente com um servidor.

Essa autonomia é parte do valor do Git. A Anthropic reconhece isso no próprio anúncio, mas diz que sua carga de trabalho foi se afastando desse cenário: quase todos os clientes envolvidos eram agentes e tarefas automatizadas que já precisavam estar conectados.

A escala ajuda a entender o problema. Segundo o relato, só o histórico da linha principal do repositório já se aproximava de 100 GB, enquanto uma cópia de trabalho comprimida ultrapassava 25 GB.

A empresa também afirma realizar algo na ordem de 25 milhões de preparações de cópias de código por dia apenas para integração contínua, a rotina que executa verificações automáticas quando o software muda. Esse número não inclui ambientes dos desenvolvedores, espaços dos agentes e tarefas de pesquisa.

Se cada operação baixasse tudo de forma ingênua, o tráfego passaria de 600 petabytes por dia, calcula a Anthropic. É um cenário hipotético usado para mostrar a dimensão da carga, não uma declaração de que a empresa efetivamente transferia esse volume.

Antes de construir o Scion, a equipe tentou recursos do Git para baixar apenas partes do repositório, manter cópias internas e reaproveitar versões preparadas dos arquivos. No pico, operou centenas de espelhos internos, de acordo com a mesma fonte.

Essas soluções compraram tempo. O problema foi que, com alterações entrando cada vez mais rápido, as cópias preparadas ficavam desatualizadas e as consultas ao histórico exigiam mais cuidado para continuar funcionando sobre cópias parciais.

O que é o Scion e como ele muda esse trabalho?

Scion é um sistema interno de controle de versões que concentra no servidor operações como criar alterações, juntar contribuições e responder perguntas sobre o histórico. O computador que pede os arquivos mantém uma quantidade limitada de dados e busca o restante conforme precisa, segundo a descrição técnica da Anthropic.

A diferença aparece numa tarefa simples. Se uma verificação automática só precisa saber quais arquivos mudaram, ela pode perguntar isso diretamente ao serviço, sem preparar uma cópia local do repositório para calcular a resposta.

Se precisa ler uma pasta específica, solicita aquela parte. Se precisa de um arquivo durante a execução, o sistema pode trazer o conteúdo naquele momento.

Pense num exemplo hipotético de um app de agenda para uma clínica. Uma mudança no texto de confirmação de consulta pode exigir testar o envio da mensagem, mas não necessariamente baixar todos os arquivos históricos do painel financeiro.

O exemplo é nosso, não um teste realizado pela Anthropic. Ele ilustra a ideia de pagar pelo conteúdo que uma tarefa realmente usa, em vez de repetir preparações completas para consultas pequenas.

No Scion, a unidade de alteração registra os arquivos modificados em relação ao primeiro ancestral e aponta para seus conteúdos comprimidos. A equipe chama essa unidade de changeset, um conjunto de mudanças.

O sistema também prepara estruturas auxiliares para responder quem alterou uma linha, quais mudanças atingiram um arquivo e como duas versões se relacionam. Essas estruturas ficam por trás do serviço, de modo que a equipe pode otimizá-las sem exigir que cada cliente conheça sua organização interna.

Há um custo nessa escolha: o Scion parte da premissa de que o servidor está acessível. A flexibilidade de trabalhar com um repositório completo offline deixa de ser o centro do desenho.

Para a Anthropic, essa troca combina com agentes e tarefas conectadas. Para um criador trabalhando com poucos colaboradores, o mesmo compromisso pode não fazer sentido.

Quais resultados a Anthropic divulgou?

A Anthropic afirma que a infraestrutura do Scion exige 200 vezes menos CPU e memória do que a antiga infraestrutura de espelhamento do Git. Também relata preparações de código cerca de duas ordens de grandeza mais rápidas, passando de minutos para segundos, no seu ambiente interno.

Esses resultados têm escopos diferentes. A tabela ajuda a evitar a leitura de que todo o processo de desenvolvimento ficou 200 vezes mais rápido.

Medida divulgada	Resultado relatado	O que ela mede
Alterações integradas por dia	Cerca de 2.500 em maio para mais de 30 mil em setembro	Volume de mudanças incorporadas, não receita ou qualidade do produto
CPU e memória da infraestrutura de versões	Necessidade 200 vezes menor	Comparação com o espelhamento de Git usado anteriormente pela empresa
Preparação de arquivos para tarefas automáticas	Cerca de 100 vezes mais rápida	Acesso ao código, não execução integral de todos os testes
Capacidade de CPU na integração contínua	Ganho de 25%	Efeito nessa parte da infraestrutura

A empresa atribui parte do ganho ao reaproveitamento de dados. Um serviço no computador compartilha objetos entre tarefas, uma camada regional atende pedidos repetidos e o servidor principal só é consultado quando falta alguma coisa.

Segundo o relato, cada camada mantém uma taxa de acerto do cache acima de 99%. Cache, aqui, é apenas uma cópia reaproveitável: se dez tarefas pedem o mesmo conteúdo, o sistema tenta entregá-lo sem reconstruir ou buscar tudo outra vez.

A divisão entre camadas também busca conter falhas. A Anthropic descreve restrições para evitar que a queda de um cache regional despeje todos os pedidos nos servidores centrais e derrube o conjunto.

Todos esses números são resultados divulgados pela própria Anthropic. Não fizemos uma comparação independente, e o artigo não apresenta uma conta pública que permita converter o ganho de infraestrutura em economia mensal para outro negócio.

Também não dá para extrair desses dados que qualquer equipe com Claude terá o mesmo resultado. O ponto de partida era uma operação com centenas de espelhos e milhões de tarefas diárias, muito distante de um primeiro app.

Foi a IA que criou o próprio substituto do Git?

Claude ajudou a equipe a desenvolver o Scion, mas houve sete pessoas responsáveis por construir os sistemas e conduzir a migração. O projeto levou cinco meses e incluiu o Antique, ferramenta interna de revisão, além de busca de código e outros componentes, informa a Anthropic.

Uma das histórias divulgadas envolve o mecanismo que transportava o histórico do Git para o novo sistema. A primeira versão havia sido majoritariamente escrita à mão.

Quando a equipe teve acesso a uma versão interna inicial do Claude Mythos Preview, pediu uma reescrita. Segundo a empresa, o resultado consumiu 20 vezes menos memória e ficou quatro vezes mais rápido, preservando condições importantes da migração.

É um resultado específico sobre esse componente. Não significa que todo código refeito com Claude consuma 20 vezes menos memória, nem que a migração inteira tenha acontecido sem orientação humana.

O próprio relato faz questão de separar essas coisas. Os engenheiros continuaram definindo compromissos entre sistemas, entendendo restrições e escolhendo quais problemas valia a pena resolver naquela escala.

A equipe também diz que todos os participantes avaliam Claude como melhor do que eles na escrita de código. Essa é uma avaliação dos envolvidos sobre sua experiência, não um estudo comparando o modelo com todos os engenheiros ou uma medida de que ele consiga assumir sozinho todas as responsabilidades do projeto.

O resultado mais interessante para quem cria com IA aparece justamente nessa divisão de trabalho. O modelo acelera implementações, enquanto alguém continua responsável por definir o comportamento esperado e reconhecer uma solução que parece boa isoladamente, mas cria um problema no sistema inteiro.

Por que os engenheiros ainda precisavam dizer não ao Claude?

A equipe relata que agentes às vezes quebravam restrições importantes para seguir um padrão inadequado. Em outros casos, revisões feitas com IA acrescentavam complexidade para proteger o sistema de problemas hipotéticos, segundo o relato oficial.

Um exemplo foi a tentativa de descobrir quando uma mudança chegou à versão principal lendo o histórico inteiro em sequência. Já existia uma ferramenta de revisão que podia responder diretamente à pergunta.

Outro caso envolveu verificações excessivas sobre um serviço interno. A revisão adversarial levantou uma preocupação, e Claude acrescentou validações e complexidade além do que a equipe considerava necessário.

Isso torna a notícia mais útil do que a frase “a IA fez um Git novo”. O mesmo modelo que acelerou a construção também precisou ser redirecionado para respeitar limites, reaproveitar serviços existentes e evitar peças que o problema não exigia.

A Anthropic afirma continuar revisando todos os pedidos de alteração desse sistema. A diferença descrita é que a revisão passou a examinar a intenção da mudança em vez de ler cada linha de código.

Essa é uma prática relatada pela empresa, não uma orientação para que qualquer criador deixe de examinar detalhes sensíveis do seu app. A própria equipe diz ter investido em simulações isoladas, testes que exploram entradas inesperadas e limites de frequência para as operações.

Há ainda controles de acesso por repositório e por diretório. A proposta é proteger partes sensíveis sem obrigar a empresa a separar todo o código em repositórios distintos.

A ferramenta de revisão consegue diferenciar mudanças simples, como comentários, de alterações relevantes na lógica. Segundo a Anthropic, isso ajuda a concentrar atenção humana nas contribuições com maior consequência.

Como testar software quando milhares de mudanças entram juntas?

A Anthropic diz ter reforçado testes depois da integração das alterações e antes da publicação. O motivo é que a fila tradicional, que impede novas integrações enquanto uma sequência de verificações termina, ficou difícil de reproduzir na escala dos agentes, de acordo com o texto da equipe.

Enquanto um teste está rodando, centenas ou milhares de outras mudanças podem ser incorporadas. A versão que terminou de passar na verificação pode já não representar exatamente o conjunto de arquivos que será publicado depois.

A empresa reconhece que alterações simultâneas podem entrar em conflito. Sua aposta é que Claude costuma corrigir esses conflitos mais rápido do que humanos conseguem identificá-los.

Isso descreve uma escolha operacional, com riscos e mecanismos de resposta próprios. O artigo não demonstra que o novo processo elimina defeitos ou que o volume de mudanças equivale a mais valor entregue ao usuário.

No mesmo relato, a equipe conta que usa Claude Tag para observar componentes específicos. Os agentes consultam registros e métricas, com foco contínuo na saúde de uma parte do sistema.

A Anthropic mantém alertas tradicionais também. A alegação é que esses agentes conseguem perceber problemas sutis ou novos que escapam a regras de alerta já definidas.

Para um produto pequeno, a pergunta útil é bem concreta: qual versão foi testada, qual foi publicada e como voltar atrás se uma função parar de funcionar? A complexidade da resposta precisa acompanhar o tamanho real do problema.

O Scion foi lançado para qualquer pessoa usar?

O anúncio apresenta um sistema interno e suas decisões de arquitetura, sem oferecer o Scion como substituto público de uso geral. A Anthropic diz explicitamente que a solução só faz sentido para repositórios realmente enormes, com dezenas de milhares de engenheiros ou muitos agentes escrevendo código.

A empresa também reconhece uma vantagem difícil de copiar: sua capacidade de gastar tokens internamente ultrapassa o que outros negócios razoavelmente aceitariam gastar. Parte desse uso atende às necessidades de desenvolvimento, e parte serve para testar as capacidades do Claude.

Esse detalhe limita qualquer comparação de custo. Um resultado viável para um laboratório que produz o próprio modelo não estabelece, sozinho, uma conta sustentável para uma empresa que paga pelo consumo externo.

Também seria necessário migrar mais do que o histórico. Scion depende de revisão, busca de código e integração contínua adaptadas ao seu desenho, e os componentes internos da Anthropic são muito específicos.

O caminho proposto no anúncio é compartilhar ideias que possam melhorar o ecossistema do Git. A equipe menciona inspiração em trabalhos anteriores como o Piper, do Google, e o Sapling, da Meta, e reconhece o esforço da comunidade que sustentou a expansão do Git ao longo dos anos.

Por isso, a manchete “Anthropic abandonou o Git” exige complemento. Ela migrou seu repositório principal para resolver uma carga incomum; o anúncio não determina que o Git tenha deixado de atender aos demais projetos.

O que esse caso muda para quem cria produtos com IA?

O caso mostra como acelerar a escrita pode deslocar o trabalho para revisão, testes e publicação. Minha leitura é que esse é o aprendizado que dá para levar ao primeiro produto sem copiar a infraestrutura de um laboratório.

Num exemplo hipotético, um criador pede ao agente três mudanças num app de agendamento: cobrança, cancelamento e envio de confirmação. O código pode aparecer rápido, mas ainda falta verificar se uma cobrança recusada libera um horário, se um cancelamento interrompe a mensagem e se a publicação reuniu versões compatíveis.

Cada uma dessas perguntas está ligada a um comportamento que o usuário percebe. Contar arquivos alterados ou comandos executados não responde a nenhuma delas.

A própria Anthropic reconhece que a demanda interna por novas alterações continua crescendo sempre que remove um gargalo. Isso reforça a necessidade de medir o que acontece depois da geração: tempo até publicar uma mudança testada, falhas no uso real e esforço para corrigir o que saiu errado.

Para quem está construindo um app, manter alterações compreensíveis, testar o caminho do usuário e guardar uma versão recuperável já resolve problemas imediatos. Uma migração de controle de versões só se justificaria diante de um gargalo concreto que as ferramentas existentes não consigam resolver.

A Formação em Vibe Coding do ibe.IA é voltada a quem quer transformar uma ideia em aplicativo, sistema ou produto digital com IA. Esse é o contexto em que entender revisão, testes e publicação ajuda a transformar código gerado em algo utilizável.

Conheça a Formação em Vibe Coding.

E, para acompanhar análises sobre ferramentas e criação com IA, você pode seguir o ibe.IA no Instagram: @ibe.ia.

Fonte

Anthropic: Redesigning source control at Anthropic, publicado em 13 de outubro de 2026. Fonte primária dos números, escolhas técnicas e limitações descritas.

Mad Robot: Claude writes so much code at Anthropic that git couldn’t keep up, so it built its own, publicado em 14 de outubro de 2026, às 07h51 UTC. Referência da repercussão dentro da janela de notícias desta edição.