Radar Tech: 30 mil merges por dia e o gargalo mudou de lugar — quando a infra de dev feita para humanos vira o limite do time

Em maio de 2026, a Anthropic integrava cerca de 2.500 mudanças de código por dia no seu monorepo. Em setembro, eram mais de 30.000 por dia. O número não veio de um time maior: veio de agentes escrevendo código em volume que nenhuma ferramenta de desenvolvimento construída na escala humana aguenta de pé.

O caso, publicado pela própria Anthropic, é menos sobre "IA escreve código" e mais sobre uma pergunta de arquitetura que quase ninguém fez ainda: o que acontece com a infraestrutura de desenvolvimento quando o gargalo deixa de ser a escrita e passa a ser o encanamento?

O que quebrou primeiro

Quando o volume de mudanças cresce dez vezes, a conta de controle de versão explode junto. O histórico do branch principal do monorepo passou de 100 GB, a cópia de trabalho comprimida passa de 25 GB, e o CI fazia algo como 25 milhões de checkouts por dia. Buscado de forma ingênua, isso daria mais de 600 PB de tráfego de git por dia.

Os remédios clássicos para monorepos grandes — shallow clone, sparse checkout, mirrors internos, snapshots em blob storage — foram todos usados e mesmo assim não fecharam a conta: em determinado momento a empresa operava centenas de mirrors internos de git só para se manter de pé. Era um sistema desenhado para um clone completo e offline por desenvolvedor, sendo usado por milhares de agentes e sandboxes que não precisam de histórico nenhum.

A resposta foi trocar a peça, não afinar o parafuso: um sistema de controle de versão próprio, com clientes leves que não carregam o histórico por padrão, migração completa do monorepo em cinco meses, e junto dele uma superfície de revisão, busca de código e gestão de identidade para o próprio controle de versão.

A lição de arquitetura (que vale mesmo sem 30 mil merges)

Você não precisa ser a Anthropic para esse problema bater na porta. A ordem em que ele chega é previsível:

• Controle de versão é o primeiro a ceder, porque assume um clone completo e um humano que clona uma vez por dia.
• CI vem em seguida: filas de build dimensionadas por push humano não sobrevivem a um agente que abre PR de cada micro-otimização.
• Revisão de código é o gargalo cultural: se o volume de mudanças sobe dez vezes e o número de revisores humanos não, a revisão vira uma fila que ninguém esvazia.
• Build e cache por último: cache quente por branch deixa de fazer sentido quando branches nascem e morrem em minutos.

O ponto de arquitetura não é "copie o Scion". É reconhecer que, quando agentes entram no fluxo, os pressupostos embutidos na plataforma de desenvolvimento passam a ser decisões que ninguém documentou. Volume de merges, custo de clone, tamanho de histórico e política de revisão deixam de ser operação e passam a ser decisão de arquitetura com consequências visíveis — a peça que quebra primeiro é sempre a que ninguém tinha escolhido de propósito.

Um antídoto barato: trate a plataforma de desenvolvimento como você trata qualquer outro sistema crítico. Escreva a decisão antes do incidente — qual é o teto de merges que a sua infra suporta hoje, o que acontece no dia em que você passar dele, e qual peça você troca primeiro. É exatamente o tipo de decisão que uma ADR existe para registrar, não para adivinhar depois do outage.

O que isso sinaliza para os próximos meses

A Anthropic aposta que não é a última empresa a ver pressão na infraestrutura de desenvolvimento: ela só chegou primeiro porque usa IA para escrever software mais que quase todo mundo. Se essa leitura estiver certa, o próximo ciclo de investimento em plataforma não vai para mais um gerador de código, e sim para o encanamento que segura o código que já está sendo gerado — controle de versão leve, CI elástico, revisão assistida e métricas que mostrem onde a fila está estourando antes que ela estoure.