Redesenhando o controle de código-fonte na Anthropic: Claude superou o Git

A Anthropic substituiu o Git depois que Claude ajudou a levar seu monorepo de cerca de 2.500 merges diários, em maio de 2026, para mais de 30.000 em setembro. Esse salto faz de Redesenhando o controle de código-fonte na Anthropic mais do que uma história de migração de infraestrutura. Ele mostra o que acontece quando a IA gera código mais rápido do que os sistemas de desenvolvimento conseguem absorvê-lo com segurança.

A empresa criou o Scion, um sistema interno de controle de código-fonte projetado para agentes online, operações no lado do servidor e acesso esparso a um repositório gigantesco. Sete engenheiros também desenvolveram o Antique, um novo sistema de revisão de código, além de vários serviços relacionados. A Anthropic afirma que a equipe concluiu a migração em cinco meses.

O conflito importante não é simplesmente Scion versus Git. É a produção de código em escala de agentes versus práticas de desenvolvimento projetadas em torno da atenção humana. Google e Meta já construíram sistemas especializados para monorepos enormes. A Anthropic chegou a um destino semelhante por uma fonte de pressão diferente: enxames de agentes de software que nunca precisam trabalhar offline.

O redesenho do controle de código-fonte na Anthropic começou com 30.000 merges diários

A Anthropic não abandonou o Git porque seus engenheiros não gostavam dele. Ela o abandonou porque Claude mudou a forma e o volume do tráfego do repositório.

Segundo o relato de engenharia da Anthropic, os merges diários cresceram mais de dez vezes entre maio e setembro de 2026. A empresa apresenta esse crescimento como uma demanda contínua, e não como um pico temporário causado pela migração.

A carga de trabalho resultante foi muito além da criação de commits. O histórico do branch principal da Anthropic se aproximava de 100 GB, enquanto uma cópia de trabalho compactada ultrapassava 25 GB. A integração contínua, ou CI, realizava cerca de 25 milhões de checkouts de código por dia antes mesmo de contabilizar ambientes de desenvolvimento, sandboxes de agentes e trabalhos de pesquisa.

Buscar esses checkouts de forma ingênua geraria mais de 600 petabytes de tráfego diário de Git, calculou a Anthropic. A empresa usou clones rasos, checkouts esparsos, snapshots de repositório e várias centenas de espelhos internos de Git para controlar esse custo.

Essas medidas ganharam tempo, mas o repositório continuou mudando mais rápido. Os snapshots ficavam obsoletos entre as atualizações. Os clones parciais também complicavam operações como buscas no histórico, diffs e blame, que identifica quem alterou uma linha pela última vez.

O problema da empresa surgiu de um descompasso entre os pontos fortes do Git e os clientes dominantes da Anthropic. O Git fornece a cada clone informações suficientes para operar como um repositório autossuficiente. Esse projeto oferece suporte ao desenvolvimento offline, ao histórico local e à colaboração descentralizada.

Os agentes e trabalhos automatizados da Anthropic já estavam online. Eles não precisavam de um histórico local completo nem da capacidade de atuar como servidores independentes. Ainda assim, a infraestrutura distribuía e mantinha repetidamente dados do repositório como se cada cliente fosse um desenvolvedor humano usando um laptop.

O Scion inverte essa premissa. Seu servidor realiza consultas de histórico, cria commits, calcula diffs e processa merges ou rebases. Um cliente leve mantém um cache limitado e materializa apenas os arquivos exigidos pela tarefa atual.

Essa diferença importa quando um trabalho de pesquisa precisa de um diretório, e não do monorepo inteiro. Também importa quando um serviço de CI precisa apenas de um diff ou de um cálculo de merge-base. O Scion pode responder a essas solicitações por meio de uma API sem criar uma cópia de trabalho tradicional.

A nova arquitetura produziu ganhos internos substanciais, segundo a Anthropic. Cada camada de cache supostamente mantém uma taxa de acertos superior a 99 por cento. A infraestrutura utiliza 200 vezes menos CPU e memória do que a frota anterior de espelhos Git.

A Anthropic também afirma que os checkouts de CI e pesquisa caíram de minutos para segundos. A mudança devolveu 25 por cento da capacidade de CPU de CI à frota computacional mais ampla.

Essas são medições relatadas pela empresa a partir de um sistema interno. Pesquisadores externos não podem reproduzi-las sem acesso às cargas de trabalho, aos repositórios e à infraestrutura da Anthropic. Ainda assim, os números explicam por que outra rodada de ajustes no Git já não parecia suficiente.

O sistema precisava suportar mais do que um repositório grande. Precisava suportar um repositório cujos principais autores, leitores e consumidores automatizados operavam em velocidade de máquina.

Claude transformou a infraestrutura de software no gargalo

O verdadeiro significado do Scion é que a geração de código deixou de ser o recurso escasso da Anthropic. Capacidade de revisão, infraestrutura e julgamento se tornaram as restrições.

Os assistentes de programação com IA inicialmente se encaixavam em um processo de desenvolvimento familiar. Uma pessoa solicitava uma função, inspecionava a saída, executava testes e enviava um pull request. O assistente aumentava a velocidade de digitação de cada desenvolvedor sem alterar o sistema ao redor.

A Anthropic descreve um modelo operacional mais avançado. Segundo relatos, Claude percorre ciclos de pesquisa, otimiza programas complexos, cria serviços, monitora componentes de produção e auxilia em grandes migrações. Cada atividade pode produzir novas mudanças ou exigir novo acesso ao repositório.

Esse padrão cria uma pressão multiplicativa. Um agente pode iniciar outra tarefa enquanto uma mudança anterior avança pelos testes. Revisores automatizados podem solicitar correções, que produzem alterações adicionais. Os sistemas de CI então criam checkouts e acionam mais consultas ao repositório para cada candidato.

O gráfico destacado por Simon Willison mostra um aumento acentuado durante 2026. Willison associou a aceleração às gerações mais recentes de modelos internos da Anthropic, distinguindo cuidadosamente a disponibilidade interna das datas de lançamento público.

A Anthropic faz uma conexão mais específica. Ela afirma que o desenvolvimento do Scion começou aproximadamente quando Claude Mythos Preview e Claude Tag passaram a estar disponíveis internamente. Esses modelos supostamente aumentaram a necessidade do Scion enquanto ajudavam a equipe a desenvolvê-lo.

Um exemplo envolveu o pipeline que transferia dados do Git para o Scion. Os engenheiros da Anthropic haviam escrito manualmente um protótipo inicial. Uma primeira versão interna de Claude Mythos Preview então reescreveu o pipeline com pouca orientação adicional.

A substituição supostamente usou 20 vezes menos memória e foi executada quatro vezes mais rápido. A Anthropic afirma que ela preservou requisitos implícitos relacionados à ordem de ingestão e às estruturas de dados. A alegação chama atenção, mas continua sendo um resultado descrito pela empresa, e não um benchmark independente.

O ciclo de feedback mais amplo é mais fácil de estabelecer. A geração mais rápida de código aumentou a atividade do repositório. Essa atividade justificou uma nova infraestrutura. Claude então ajudou a construir a infraestrutura, removendo outro limite à geração de código.

Esse ciclo pressiona todas as etapas do desenvolvimento. Um serviço de build que lida com mudanças no ritmo humano pode se tornar caro quando agentes criam milhares de tarefas simultâneas. Uma fila de revisão se torna menos útil se o repositório avança por centenas de mudanças enquanto uma suíte de testes é executada.

O acesso ao conhecimento também passa a fazer parte da restrição. Agentes precisam de especificações, decisões arquiteturais, histórico de incidentes e contexto de propriedade, não apenas de arquivos-fonte. Equipes que desenvolvem fluxos de trabalho semelhantes precisam de uma base de conhecimento de engenharia pesquisável, ao lado de uma infraestrutura de código mais rápida.

A Anthropic afirma que agora usa monitores persistentes do Claude chamados “superfans” para componentes individuais do Scion. Esses agentes acompanham telemetria e logs por meio de canais dedicados no Slack. Os alertas tradicionais continuam em vigor, enquanto os agentes procuram padrões que limites fixos poderiam não detectar.

Esse modelo operacional eleva o trabalho de engenharia a outro nível. Pessoas definem invariantes, escolhem limites arquiteturais, interpretam falhas e decidem o que deve chegar à produção. Agentes geram implementações e investigam a telemetria dentro desses limites.

A mudança não elimina o engenheiro. Ela transfere a habilidade escassa de produzir código para decidir qual código merece existir.

Scion substitui o modelo offline do Git por um serviço em escala de agentes

O Scion ganha throughput ao abrir mão da simetria definidora do Git: um cliente já não carrega toda a inteligência do repositório.

Os commits do Git contêm ponteiros para árvores completas de diretórios. Clientes trocam coleções compactadas de objetos chamadas packfiles, permitindo que repositórios locais preservem o histórico e operem de forma independente. Esse modelo continua adequado para a maioria dos projetos de software.

O Scion usa um changeset, uma entrada em um log write-ahead que registra arquivos alterados em relação a um pai. Os conteúdos dos arquivos são compactados, endereçados por conteúdo e armazenados separadamente. O endereçamento por conteúdo significa que a chave de armazenamento deriva dos dados, de modo que objetos imutáveis podem ser armazenados em cache com segurança.

Os changesets são criados no servidor e ficam disponíveis em todo o sistema. Eles não exigem que um cliente construa e faça upload de um grande packfile. Também evitam mover um ponteiro global de branch durante cada operação de commit.

O Scion ainda oferece suporte a referências, ou seja, ponteiros como branches e tags. No entanto, a Anthropic desestimula a maior parte das referências além da linha principal e dos branches de lançamento. O estado coordenado globalmente se torna cada vez mais caro à medida que as taxas de commit aumentam.

O sistema calcula as informações de histórico separadamente, como dados derivados. Ele cria índices dedicados para histórico de arquivos, blame, cópia e relações dentro do grafo de commits. Esses índices podem ser gerados imediatamente ou adiados até que um consumidor os solicite.

Essa separação permite que a Anthropic altere um índice sem mudar todos os clientes. Ela também permite que o serviço evite calcular dados que nenhuma tarefa precisa.

O protocolo de checkout do Scion segue o mesmo princípio. Clientes solicitam árvores e objetos de arquivo específicos, em vez de negociar uma visão completa do que já possuem. Servidores de cache regionais podem atender à maioria das solicitações porque os objetos armazenados nunca mudam.

Um daemon em cada nó de computação compartilha objetos em cache entre trabalhos locais. Serviços de cache regionais ficam então entre esses daemons e os servidores Scion autoritativos. A Anthropic impõe essa hierarquia para evitar que uma falha de cache regional sobrecarregue o serviço central.

Checkouts esparsos solicitam apenas diretórios selecionados. Checkouts virtualizados criam arquivos quando um processo os lê. Alguns trabalhos ignoram inteiramente o sistema de arquivos e pedem à API um diff, um resultado de histórico ou uma merge base.

Esse projeto se assemelha a respostas anteriores à escala dos monorepos. O Google descreveu o Piper como parte da infraestrutura que dá suporte a uma enorme base de código centralizada. Sua análise de monorepo publicada documentou as vantagens do código compartilhado, das dependências unificadas e das mudanças em toda a organização.

A Meta seguiu outro caminho com o Sapling, um sistema que preserva conceitos familiares de controle de código-fonte distribuído enquanto escala para seu repositório interno. A Meta afirma que seu servidor pode lidar com dezenas de milhões de arquivos, commits e branches. O projeto público do Sapling também oferece suporte a repositórios Git e fluxos de trabalho locais de desenvolvedores.

Scion toma emprestadas lições de ambas as histórias, mas sua premissa central é mais restrita. O cliente dominante está sempre online, frequentemente é automatizado e dificilmente precisará de um repositório inteiro. Isso transforma o servidor em um banco de dados de controle de versão e serviço de computação, em vez de um parceiro de sincronização.

A contrapartida é a dependência. Um cliente Scion não consegue reproduzir todo o comportamento offline do Git porque deliberadamente mantém menos dados e executa menos operações localmente. Portanto, uma falha de rede ou do serviço central tem um impacto diferente.

Os custos de migração também vão além do cliente de linha de comando. A Anthropic precisou desenvolver busca de código, controles de identidade e acesso, integrações de CI e Antique. Uma empresa que adotasse o mesmo design precisaria substituir grande parte de sua plataforma de desenvolvimento.

Isso explica por que Scion não é uma alternativa da Anthropic ao Git para equipes comuns. É um sistema verticalmente integrado para uma carga de trabalho excepcional.

Merges Mais Rápidos Tornam a Revisão de Código o Problema Mais Difícil

A questão não resolvida não é se Scion consegue aceitar 30.000 mudanças. É se a Anthropic consegue preservar a responsabilização nessa velocidade.

A Anthropic afirma que cada mudança no Scion ainda recebe revisão humana. Agora, os revisores se concentram na intenção de uma mudança, em vez de ler cada linha. Essa escolha decorre do volume, mas também desloca a confiança para testes, explicações dos agentes e análise automatizada.

A revisão de intenção pergunta se uma mudança proposta corresponde aos objetivos do sistema e às regras arquiteturais. A revisão linha a linha pergunta se sua implementação se comporta corretamente. Verificações automatizadas robustas podem conectar esses níveis, mas nenhuma suíte de testes captura todos os requisitos ocultos.

A Anthropic reconhece que engenheiros frequentemente precisavam dizer “não” ao Claude. Às vezes, os agentes selecionavam padrões localmente plausíveis que violavam restrições de todo o sistema. Alguns componentes gerados tentavam percorrer o log de commits linearmente em vez de consultar o Antique para obter um horário de merge autoritativo.

A revisão adversarial criou outro modo de falha. O Claude podia responder a riscos hipotéticos com validação e complexidade excessivas. Engenheiros humanos precisavam decidir quando a programação defensiva deixava de melhorar o sistema.

Esses exemplos complicam a afirmação simples de que modelos melhores produzem diretamente software melhor. Agentes podem encontrar otimizações valiosas e, ao mesmo tempo, criar mecanismos desnecessários. Uma produção elevada amplifica ambos os comportamentos.

A Anthropic afirma que sua equipe desenvolveu simulações, testes de fuzzing e limites de taxa para Scion. O fuzzing fornece entradas inesperadas para expor defeitos, enquanto simulações herméticas reproduzem o comportamento da infraestrutura em ambientes isolados. Esses controles oferecem evidências mais sólidas do que apenas contagens de merges.

Ainda assim, o volume de merges não é uma métrica de qualidade. Uma mudança pode ser pequena, experimental, gerada, revertida ou não estar relacionada ao progresso voltado ao cliente. Trinta mil mudanças diárias revelam uma atividade extraordinária, mas não demonstram de forma independente confiabilidade ou valor para o negócio.

As reações públicas de desenvolvedores se concentraram nessa distinção. Na discussão no Hacker News, alguns leitores questionaram se a Anthropic deveria reconsiderar seu monorepo. Outros argumentaram que intenção, proveniência e verificação contínua importam mais do que a mecânica tradicional de commits.

Um engenheiro da Anthropic que respondeu nessa discussão defendeu as ferramentas consistentes e as mudanças atômicas do monorepo. O mesmo engenheiro esclareceu que Scion bloqueia conflitos textuais, mas não consegue eliminar conflitos semânticos entre mudanças simultâneas.

Um conflito semântico ocorre quando duas edições individualmente válidas produzem, juntas, um comportamento incorreto. Uma mudança pode alterar uma função e atualizar seus chamadores, enquanto outra adiciona simultaneamente um novo chamador. Os arquivos podem ser mesclados sem problemas, embora o programa combinado esteja errado.

Filas de merge tradicionais reduzem esse risco ao testar um estado proposto do repositório antes de aceitar o próximo lote. A Anthropic afirma que um bloqueio global do repositório se torna impraticável quando centenas ou milhares de mudanças são integradas durante a execução de um teste.

A empresa transferiu investimentos para testes pós-merge e pré-implantação. Essa abordagem permite que a taxa de processamento do repositório continue enquanto as verificações determinam o que pode chegar à produção com segurança.

Essa é a principal contrapartida em Redesenhando o controle de versão na Anthropic. Scion remove a serialização do controle de versão, mas alguma forma de serialização ainda existe na implantação, na migração de dados ou nos pontos de decisão humana. O risco se desloca em vez de desaparecer.

A Anthropic afirma que Claude consegue resolver conflitos simultâneos mais rapidamente do que as pessoas conseguem identificá-los. Essa resposta aborda a velocidade de reparo, não o custo de uma interação não detectada. A segurança depende de quão rapidamente o monitoramento detecta um problema e de quão eficazmente os sistemas o isolam ou revertem.

Controles de acesso no nível de diretório e regras de aprovação semântica ajudam. Segundo a Anthropic, Antique consegue distinguir uma mudança que altera apenas comentários de uma mudança em lógica sensível. A atenção humana pode então se concentrar em mudanças com consequências maiores.

A lacuna de verificação restante é substancial. A Anthropic não publicou taxas independentes de defeitos, frequência de rollbacks, tendências de incidentes ou a proporção de mudanças escritas e revisadas por agentes. Sem essas medidas, observadores externos não conseguem comparar os ganhos de throughput com o risco posterior.

A lição mais útil para outras equipes, portanto, não é perseguir a contagem de merges da Anthropic. É medir todo o caminho, da especificação à implantação. Indicadores úteis incluem defeitos que escaparam, latência de revisão, mudanças malsucedidas, rollbacks, trabalho duplicado e tempo gasto para restaurar o contexto.

Um fluxo de trabalho de IA pessoal pode ajudar engenheiros a preservar decisões e proveniência à medida que os agentes geram mais material. No entanto, o contexto armazenado só ajuda quando as equipes o conectam a testes aplicáveis, propriedade e política de revisão.

O Que o Experimento de Controle de Versão da Anthropic Muda a Seguir

A próxima fase testará se o desenvolvimento em escala de agentes se torna um modelo de engenharia transferível ou permanece uma exceção cara da Anthropic.

O primeiro sinal a observar é a prometida discussão da Anthropic sobre Antique. O controle de versão explica como as mudanças são armazenadas e recuperadas, mas a revisão de código determina como intenção, propriedade e aprovação sobrevivem a volumes extremos.

Detalhes sobre o modelo de revisão do Antique fortaleceriam o argumento da Anthropic se demonstrarem proveniência clara e intervenção humana baseada em risco. O argumento enfraqueceria se a revisão dependesse principalmente de resumos do modelo sem validação mensurável.

O segundo sinal é a qualidade do software ao longo do tempo. As alegações de infraestrutura da Anthropic terão mais peso se a empresa publicar taxas de rollback, defeitos que escaparam, incidentes de serviço ou outras medidas de resultado junto ao throughput de merges.

Uma confiabilidade estável ou em melhoria sustentaria a ideia de que agentes podem aumentar o volume de mudanças sem elevar proporcionalmente o risco. Um aumento em regressões ou reparos de emergência sugeriria que Scion acelerou a produção mais rapidamente do que a governança.

O terceiro sinal é como plataformas Git e grandes organizações de engenharia respondem. A maioria das empresas não substituirá o Git, mas pode adotar APIs de metadados no servidor, espaços de trabalho virtualizados, revisão consciente de riscos e melhor suporte para agentes paralelos.

O Sapling da Meta já demonstra um caminho que mantém compatibilidade com fluxos de trabalho familiares. O Scalar da Microsoft e melhorias relacionadas ao Git demonstram outro, estendendo o Git para grandes repositórios em vez de substituir seu modelo de dados.

A própria Anthropic espera que essas pressões se disseminem nos próximos seis a doze meses. Essa previsão é uma avaliação da empresa, não uma tendência de mercado medida. Sua relevância depende de outras organizações atingirem limites semelhantes sem o acesso interno a tokens da Anthropic e a concentração incomum de uso do Claude.

Scion também introduz uma dependência estratégica que concorrentes podem evitar. A Anthropic controla o modelo, o serviço de repositório, a superfície de revisão, os agentes de observabilidade e o fluxo de implantação. Essa integração acelera a iteração, mas torna o ambiente de desenvolvimento mais difícil de reproduzir ou substituir.

Para a maioria das organizações, Git continuará sendo o padrão sensato. Ele oferece ampla interoperabilidade, ferramentas maduras, histórico portátil e resiliência offline. A arquitetura do Scion só se torna atraente quando o tráfego do repositório já sobrecarregou essas vantagens.

A mudança mais imediata diz respeito à gestão. Líderes de engenharia precisam parar de tratar o volume de código gerado como o objetivo. Mais produção cria valor apenas quando as equipes conseguem revisá-la, testá-la, implantá-la, observá-la e revertê-la com segurança.

Os desenvolvedores também devem esperar que seu trabalho mude. O relato da Anthropic dá maior peso ao design de sistemas, às restrições arquiteturais, à avaliação e à recusa. O engenheiro define cada vez mais o limite dentro do qual um agente pode se mover rapidamente.

Redesenhar o controle de versão na Anthropic, portanto, oferece um alerta junto com sua história de desempenho. Quando o código se torna barato, cada especificação fraca, teste ausente e limite de propriedade pouco claro pode ser reproduzido à velocidade da máquina.

A questão útil não é se sua equipe precisa do Scion. É se seus sistemas atuais de revisão, CI e conhecimento continuariam confiáveis caso agentes produzissem dez vezes mais mudanças no próximo trimestre. Meça essa capacidade agora, identifique o primeiro controle que falhará e fortaleça-o antes que chegue um volume maior de merges.