O substituto do Git da Anthropic: quando o volume de código ultrapassa a revisão humana

Quando a ferramenta feita para o ritmo humano encontra o ritmo da máquina

Segundo relatos que remontam ao registro dessa mudança feito por Simon Willison, a Anthropic construiu seu próprio substituto para o Git. O gatilho não foi um bug nem um incidente de segurança. Foi o volume. A taxa de mudanças que chegavam à base de código da empresa subiu com força, e em maio de 2026 chegava a uma média de cerca de 2.500 requisições por período, uma carga para a qual o controle de versão convencional não foi projetado.

É fácil arquivar isso entre as ferramentas internas e seguir em frente. Seria um erro. O Git é uma das peças de software mais importantes já escritas, e está construído sobre um conjunto de suposições sobre como o código muda que agora estão sendo violadas na prática.

As suposições sobre as quais o Git foi construído

O projeto do Git codifica uma crença sobre o comportamento humano. As mudanças chegam a um ritmo que uma pessoa consegue olhar. Um branch representa uma intenção que dura o suficiente para ser nomeada. O histórico é precioso, então nada é jogado fora. Um mantenedor consegue ler um diff e formar uma opinião antes de fazer o merge.

Cada uma dessas suposições enfraquece quando agentes escrevem código.

Agentes não se cansam, então produzem mudanças continuamente em vez de em lotes do tamanho de um dia de trabalho. Não sustentam uma intenção por dias, então os branches se tornam tão efêmeros que nomeá-los é só custo. Geram muito mais diffs do que um revisor humano consegue ler de forma significativa, o que faz da etapa de revisão, em torno da qual todo o fluxo de trabalho do Git é organizado, um gargalo em vez de uma salvaguarda.

O resultado é um sistema operando bem fora do seu envelope de projeto, enquanto todos insistem que nada mudou. O repositório continua funcionando. O processo ao seu redor deixa de significar o que significava.

O que de fato quebra primeiro

A preocupação ingênua é o armazenamento. Acontece que é o menor dos problemas. Disco é barato, e o Git comprime bem.

A primeira vítima real é a revisão. Um pull request cujo diff de 4.000 linhas foi gerado por um agente é tecnicamente revisável e praticamente não é. Os revisores fazem o que humanos sempre fazem sob sobrecarga: passam os olhos, confiam no resumo, aprovam. A revisão sobrevive como cerimônia enquanto perde sua função, o que é pior do que removê-la, porque a cerimônia cria uma confiança falsa.

A segunda vítima é a identidade. O histórico do Git é um registro de quem decidiu o quê e quando. Quando a maioria dos commits é escrita por um modelo agindo sobre um prompt, o histórico ainda tem nomes, mas os nomes já não respondem à pergunta para a qual o histórico existe. Você não pode perguntar a um agente por que escolheu uma abordagem seis semanas atrás, porque ele não se lembra, e a mensagem do commit foi gerada pelo mesmo sistema que fez a escolha.

A terceira vítima é o próprio branch. Criar branches é barato no Git e caro em atenção humana. Se os branches se multiplicam mais rápido do que qualquer um consegue acompanhar, você acumula intenções que ninguém está sustentando, o que é uma falha diferente de um conflito de merge e mais difícil de enxergar.

Por que um substituto é mais do que um Git mais rápido

Se o problema fosse a vazão, a solução seria um servidor mais rápido. O fato de a Anthropic construir algo novo sugere que o problema é estrutural.

Um sistema de controle de versão otimizado para mudanças no ritmo da máquina seria diferente em pontos específicos. Assumiria que a maioria das mudanças é efêmera e deveria ser barata de criar e de descartar. Trataria o diff como um resumo, e não como o artefato, e ligaria a cada mudança uma intenção legível por máquina para que um agente possa encontrá-la depois sem ler o código. Seria construído para recuperação, não para arqueologia.

Também precisaria responder a uma pergunta que o Git nunca teve de responder. O Git pressupõe que o artefato interessante é o estado final do código. Em um fluxo de trabalho guiado por agentes, o artefato interessante costuma ser o raciocínio que produziu uma mudança e as verificações que a validaram. Se esses elementos vivem fora do controle de versão, então o controle de versão registra apenas metade do histórico.

O registro em que ninguém pensa até precisar dele

O controle de versão não é apenas um sistema de arquivamento. É o substrato para cobrança, conformidade e resposta a incidentes. Auditores querem saber quem mudou o quê e quando. Setores regulados querem um registro defensável que resista a uma revisão. Equipes de segurança reconstroem linhas do tempo a partir dos commits.

Se a resposta honesta a essas perguntas passa a ser "um agente fez, em um branch que já não existe, e o raciocínio vivia em uma janela de contexto já descartada", então o registro tem um buraco. Buracos em registros são exatamente o que as auditorias existem para encontrar, e uma ferramenta que os produza sem que ninguém perceba seria um problema sério muito antes de virar escândalo.

O sinal mais amplo

A Anthropic não é a única a sentir essa pressão, e as versões menores da mesma história já são visíveis em outros lugares. O GitHub recentemente reformulou sua API de histórico de estrelas de repositório para que os dados de tendência voltem em 24 requisições, em vez de cerca de 2.500, sem exigir trabalho ilimitado de banco de dados nem expor usuários individuais que deram estrela. O GitHub também lançou um classificador de detecção de segredos sensível ao contexto que elevou a taxa de aceitação de achados reais em 11,5 por cento e reduziu o tempo mediano de varredura em 86 por cento.

Ambos são respostas à mesma condição de fundo: o volume de código no mundo está subindo, e as ferramentas construídas quando os humanos eram os únicos autores começam a mostrar a idade. A detecção de segredos é uma boa ilustração. O risco de uma credencial vazada escala com a quantidade de código sendo escrito, então um sistema que bastava em ritmos de produção humanos deixa de bastar em ritmos de produção de agentes, mesmo que nada em seu projeto tenha mudado.

A parte que ninguém quer dizer em voz alta

Há uma versão dessa história em que a IA torna as equipes de software drasticamente mais produtivas, as ferramentas acompanham, e todo mundo fica bem.

Há outra versão em que o volume de código gerado ultrapassa a capacidade humana de entendê-lo, e o setor acaba com repositórios que nenhuma pessoa sozinha compreende, sustentados por testes que ninguém escreveu e revisões que ninguém fez. O indício dessa versão não é um colapso. É uma deriva lenta, em que a base de código continua funcionando e o número de pessoas que entendem por quê continua caindo.

Substituir o Git é, sob essa luz, um sintoma que vale notar. Significa que uma das empresas mais criteriosas do setor decidiu que a ferramenta padrão havia se tornado um passivo justamente na camada em que a correção é rastreada. Não é uma admissão pequena. É um sinal de que se está pedindo que a infraestrutura de software mude mais rápido do que suas suposições conseguem acompanhar.

A resposta prática para todo o resto é pouco romântica. Meça quanto do seu código é escrito por máquina. Observe se sua etapa de revisão ainda muda alguma coisa. Note se seu histórico ainda consegue responder ao porquê. São perguntas baratas, e as respostas vão dizer se você precisa de uma ferramenta nova ou apenas de um hábito novo.