Desenvolvimento de software com IA: quando a vazão de merges multiplica por 12, o gargalo vira a verificação

A Anthropic saltou de 2.500 para mais de 30 mil merges por dia em quatro meses. Os três números do seu repositório que mostram se a verificação ficou para trás.

A fila de revisão é a primeira coisa que trava quando a escrita de código acelera

Se a IA multiplicou a quantidade de mudança que entra no seu sistema, a pergunta da reunião deixa de ser quanto o time entregou e passa a ser quanto do que entrou foi verificado antes de entrar. Três contas respondem isso, e as três saem do seu próprio repositório: quantas mudanças chegaram em produção no último mês, quantas tiveram um humano olhando antes do merge, e quanto tempo passou entre abrir e aprovar. Se o primeiro número subiu e o terceiro caiu, a sua fila de revisão virou carimbo, e você já está acumulando conta sem saber o tamanho dela.

Esse não é um problema teórico de empresa gigante. Em 13 de outubro, Simon Willison publicou o relato da Anthropic sobre por que eles redesenharam o controle de versão interno: em maio de 2026 a empresa mergeava algo em torno de 2.500 mudanças por dia, e em setembro passou de 30.000 por dia. Doze vezes mais em quatro meses. O Git, que foi desenhado para o ritmo de gente escrevendo código, deixou de dar conta do ritmo de agente escrevendo código, e eles escreveram outra coisa. O GitHub Blog anunciou movimento na mesma direção, reconstruindo a infraestrutura Git pensando em escala de agente. Duas peças do mesmo fato.

2.500 em maio, mais de 30 mil em setembro

Em estrutura metálica o ensaio é por amostragem conforme a criticidade da junta, e revisão de código funciona igual

O número bonito é o 30 mil. O número que interessa para quem paga a conta é outro, e ele não está publicado: quantas daquelas 30 mil mudanças alguém leu antes de entrar.

Quando a vazão multiplica por doze, nenhuma das suas outras capacidades multiplica junto. O time de revisão continua do mesmo tamanho. A quantidade de ambiente de homologação continua a mesma. A sua tolerância a incidente no horário comercial continua a mesma. O que acontece é previsível: a verificação vira amostragem involuntária. Ninguém decide revisar menos, a fila simplesmente anda mais rápido do que a leitura, e o que passa sem olhar passa porque o teste ficou verde.

E aí a conta não aparece no mês seguinte. Ela aparece quando alguém precisa mudar aquele pedaço e descobre que ninguém sabe explicar por que ele está daquele jeito. É o mesmo mecanismo de dívida técnica de software feita por agente de IA, só com o volume no último ponto do dial.

O que a conversa pública sobre versionamento ainda está discutindo

Vale olhar o contraste, porque ele diz onde a maior parte do mercado está de verdade.

Enquanto uma empresa reescreve o Git por causa de volume de agente, as perguntas sobre controle de versão que mais gente lê no Software Engineering Stack Exchange são de outra década. Uma delas, sobre como manter chave de API fora do controle de versão, tem 228 pontos e perto de 71 mil visualizações. Outra, com 150 pontos e algo em torno de 28 mil visualizações, pergunta se é estranho uma empresa com 15 desenvolvedores não usar versionamento gerenciado. Trinta e uma respostas nessa.

Não estou rindo de ninguém. Estou dizendo que a distância entre a ponta e o chão de fábrica é enorme, e que ler a notícia da Anthropic como receita é o erro mais caro aqui. Se o seu time ainda está resolvendo chave vazada no histórico, a sua prioridade não é a ferramenta de merge. É a disciplina do que entra.

Em estrutura metálica ninguém ensaia 100% das soldas

A regra de quais mudanças exigem leitura humana cabe em uma página, e quase ninguém escreve ela

Antes de software, eu fui responsável técnico pelas estruturas metálicas de um autódromo e passei por montagem de fábrica de cimento. Em estrutura metálica você não ensaia todas as soldas. Seria inviável em prazo e em custo, e a norma não pede isso. O que você faz é classificar as juntas por criticidade e definir um percentual de ensaio para cada classe. Junta que sustenta carga de gente em cima: ensaio em cima de tudo. Junta de fechamento que, se trincar, cai um painel: amostragem.

Revisão de código com volume alto funciona igual, e quase ninguém escreve essa regra. O que vejo é o oposto: ou o time tenta revisar tudo com o mesmo rigor e a fila trava, ou desiste e aprova tudo com o mesmo rigor de nada.

A regra que presta é chata e cabe em uma página. Mudança que toca cálculo de preço, permissão, movimentação de dinheiro, dado pessoal ou migração de banco: revisão de gente sênior, sempre, sem exceção de prazo. Mudança de texto, de layout, de teste, de dependência de desenvolvimento: automação decide, e um humano olha por amostra, uns 10% ou 20% delas. O que você ganha com isso é previsibilidade de onde o erro vai doer, e isso vale mais que a sensação de que tudo foi revisado. A hora de quem sabe revisar aquele primeiro grupo é caríssima, e você consegue estimar quanto custa olhando o que paga um desenvolvedor sênior no Brasil hoje. Gastar essa hora lendo ajuste de CSS é desperdício. Não gastar nenhuma lendo a rotina de cobrança é outra coisa.

"Meu time faz 40 merges por semana, isso não é problema meu"

É a objeção certa, e ela está meio errada.

Meio certa porque 40 merges por semana cabem na cabeça de uma pessoa. Dá para ler tudo, dá para conversar, dá para lembrar. Meio errada porque o seu número de hoje não é o número de daqui a seis meses. A Anthropic levou quatro meses para multiplicar por doze. Ninguém no mercado está planejando usar menos agente no ano que vem.

E existe uma versão silenciosa desse problema que já está na sua casa, mesmo com volume baixo. O sintoma não é incidente. É prazo. Quando a escrita acelera e a verificação não, o tempo que antes aparecia na linha de desenvolvimento migra para retrabalho, e o retrabalho não tem card no board. Você continua ouvindo que a sprint fechou, e continua achando que a entrega demora mais do que deveria. É o mesmo nó que aparece quando alguém pede uma estimativa de prazo e a resposta nunca bate.

Os três números que você tira do repositório nesta semana

Nenhum deles precisa de ferramenta nova e os três cabem em uma tarde:

1. Volume e crescimento: quantos merges entraram na branch principal nos últimos 30 dias, comparado com os 30 dias de seis meses atrás. O que importa é a inclinação, não o valor absoluto.
2. Cobertura de leitura humana: dos merges do último mês, em quantos existe pelo menos um comentário de revisão que não seja aprovação automática. Aprovação com zero comentário em 90% dos casos é um dado, não um elogio ao time.
3. Tempo entre abrir e aprovar: a mediana, nunca a média. Mediana de poucos minutos em mudança que mexe em dinheiro significa que ninguém leu, e você vai descobrir o resultado disso pelo caminho mais caro, que é o cliente avisando da queda antes de você.

Se o número 1 subiu, o 2 caiu e o 3 encurtou, você tem a resposta sem precisar de consultoria. A sua capacidade de verificar ficou para trás da sua capacidade de produzir.

Trocar a ferramenta é a última decisão, não a primeira

A leitura preguiçosa do caso da Anthropic é "o Git está obsoleto". Não está. Eles trocaram porque bateram num limite real, com um time capaz de manter uma alternativa para sempre, e com volume que justifica o custo disso. Você provavelmente não tem nenhuma das três coisas, e escrever o seu próprio controle de versão seria a pior decisão de arquitetura do seu ano.

O que o caso ensina é anterior à ferramenta: quando a vazão muda de ordem de grandeza, o processo desenhado para a ordem anterior para de funcionar, e insistir nele é que fica caro. Vale para merge, vale para deploy, vale para onboarding de pessoa nova. E quando a decisão de trocar chega de verdade, ela se parece muito com qualquer outra mudança estrutural, com os mesmos dois caminhos possíveis e as mesmas contas: um pouco por sprint ou tudo de uma vez.

Uma coisa que eu não sei dizer, e não vou fingir que sei: onde exatamente fica o limite. Não tenho um número de merges por dia a partir do qual o Git começa a doer para um time de dez pessoas. Suspeito que quase nenhum cliente nosso chegue perto disso antes de o problema de revisão explodir primeiro.

O mês 14 é de quem assinou

Na hora de contratar engenharia, a conversa é sobre velocidade. Quanto você entrega por sprint, quantas telas no mês, quanto a IA acelera. Nenhuma proposta comercial do mercado tem uma linha dizendo quem responde pelo que o agente escreveu, e o fornecedor que entrega volume sem régua de verificação está fazendo exatamente o que o modelo de contratação pede dele.

Quem paga a conta no mês 14 é você. Então leve uma pergunta para a próxima reunião com quem desenvolve o seu sistema, e peça o número, não a opinião: das mudanças que entraram em produção no último mês, quantas um humano leu antes, e quais são as classes de mudança em que isso nunca é opcional. Se ninguém souber responder na hora, essa é a primeira coisa a arrumar, bem antes de trocar qualquer ferramenta.