Seu time entrega mais código com IA e o produto continua no mesmo lugar

O volume de PR sobe e o produto não anda. Quatro medições que mostram onde a IA vira dívida: fila de review, retrabalho em 30 dias, mutation score e uso real pelo cliente.

O volume de pull request subiu e a fila de revisão é onde o ganho da IA some.

A LeadDev publicou na semana passada um texto com o título "AI-powered teams ship more code but deliver less". A explicação curta é essa: escrever código nunca foi o gargalo da sua entrega. O gargalo é revisar, integrar, corrigir o que quebrou e sustentar aquilo pelos próximos dois anos. A IA acelerou a etapa mais barata do processo e despejou volume em cima das três mais caras.

Se você quer saber se isso está acontecendo na sua empresa, ignore linhas escritas e ignore a percepção do time. Olhe para quatro números: quantos pull requests abrem por semana contra quantas mudanças chegam em produção, quanto tempo um PR fica parado esperando revisão, quanto do que entrou volta como bug ou retrabalho em 30 dias, e quanto dos seus testes de fato falha quando o código quebra. Os três primeiros saem do seu board numa tarde. O quarto costuma estragar o dia.

Chegou mais material no canteiro e a obra continua no mesmo andar

Em obra, caminhão descarregado no canteiro não conta como andamento. No board também não deveria.

Antes de software, eu respondia tecnicamente pela montagem de estruturas metálicas. Em obra, ninguém mede andamento por caminhão descarregado no canteiro. Mede por trecho montado, alinhado e liberado pela inspeção. Material empilhado no chão é estoque, e estoque em obra ocupa espaço, enferruja e atrapalha a passagem de quem está trabalhando.

Pull request esperando revisão é estoque. Trabalho já pago que ainda não virou produto, e que envelhece rápido: a cada dia parado, mais chance de conflito com o que outro dev mexeu, mais contexto perdido na cabeça de quem escreveu, mais caro o retorno do revisor. Um time que dobrou o volume de PR sem dobrar a capacidade de revisão não ficou duas vezes mais produtivo. Ficou com o dobro de coisa parada.

O cruel é que o painel fica bonito nesse cenário. Commit sobe, gráfico de atividade verde, todo mundo com sensação de velocidade. O que não se move é a data em que o cliente usa a coisa. Quando a gente olhou o que mudou em time to market entre 2025 e 2026, a distância entre atividade e entrega era justamente onde os times se enganavam.

A fila de review é onde o ganho evapora

Uma CLI de code review com IA juntou 284 pontos e 73 comentários no Hacker News. Ferramenta nova só faz esse barulho quando o problema já está doendo em muita gente ao mesmo tempo. E o problema é fácil de descrever: você multiplicou a produção de código por um fator alto e manteve o mesmo número de pessoas capazes de dizer "isso aqui está errado".

Robô ajuda na primeira camada. Ele pega padrão, estilo, chamada esquecida, dependência estranha, o import que ninguém usa. O que ele não pega é a regra de negócio que alguém combinou com o comercial em 2019 e nunca escreveu em lugar nenhum. Já escrevi em detalhe sobre onde a revisão automática substitui humano e onde não substitui, e a linha continua no mesmo lugar mesmo com modelo melhor.

Então meça a fila, que é barato. Tempo mediano entre abrir o PR e receber o primeiro comentário de gente. Se passa de um dia útil de forma consistente, a escrita deixou de ser o seu gargalo faz tempo, e contratar mais gente para escrever vai piorar a conta. Vale comparar com o benchmark de tempo de review em time remoto antes de discutir com o time se o número está bom ou ruim.

92% de cobertura e 41% de mutation score

92% de cobertura no relatório e perto de 41% de mutation score no módulo que sustenta o faturamento.

Peguei um projeto com 92% de cobertura de testes no relatório. Número que faz qualquer comitê relaxar. Rodei mutation testing na parte que sustenta o faturamento e perto de 41% dos mutantes morreram. Traduzindo para quem decide orçamento: dava para alterar mais da metade do comportamento do sistema e a suíte continuava verde, e o deploy passava.

A causa era teste sem expect. Código que chama a função, não afirma nada sobre o resultado e passa. Cobertura mede linha visitada. Comportamento garantido é outra medição, e quase ninguém faz. É o mesmo teatro do endpoint de saúde que responde 200 sem checar banco, fila ou integração externa: por fora completo, por baixo vazio.

O que a IA fez com isso foi barateamento. Gerar 300 casos de teste hoje custa dois minutos, e uma parte nasce sem asserção que importe. A cobertura sobe, a sensação de segurança sobe junto, e o número de incidentes que chega ao cliente fica igual. Nas codebases quebradas que a gente abriu e mediu, esse par de sintomas aparece com frequência quase entediante.

"Mas meu time está entregando mais rápido desde que adotou IA"

Provavelmente está mesmo. E em boa parte das frentes isso é verdade sem armadilha nenhuma: script interno, migração mecânica de arquivo, boilerplate de CRUD, glue code de integração, primeira versão de um teste que um sênior depois endurece. Aí a IA devolve horas reais para o time, e quem recusa isso por princípio está brigando com a régua errada.

A conta muda quando a mesma velocidade é aplicada onde a decisão importa: modelagem de dados, controle de concorrência, limite de transação, o que o sistema faz quando a integração do parceiro devolve 500 no meio do fluxo. Nessas partes, escrever era uns 20% do trabalho. O resto é entender o negócio e decidir o comportamento no dia ruim. Foi assim que nasceu boa parte do que a gente encontra depois, incluindo o banco que só fica lento quando o produto dá certo.

Um limite do meu próprio argumento, para não vender rigor onde ele atrapalha: se você tem três pessoas, nenhum legado e está atrás de tração, medir mutation score toda semana vai te custar mais do que te proteger. Esse cuidado todo é para quem já tem cliente pagando e sistema que não pode cair na quinta-feira de fechamento.

Os quatro números, e como tirar cada um nesta semana

1. Pull requests fechados no mês contra mudanças que um cliente efetivamente usou no mesmo mês. Se a primeira coluna cresceu 60% e a segunda ficou parada, você tem estoque, e não produtividade.
2. Tempo mediano entre abrir o PR e o primeiro comentário humano. Tire do próprio Git, sem ferramenta nova, e olhe a mediana em vez da média, porque um PR esquecido de três semanas distorce tudo.
3. Percentual do que entrou em produção e voltou como bug, hotfix ou revert em 30 dias. Esse é o número que mostra se a velocidade foi real ou se você antecipou trabalho para o mês seguinte.
4. Mutation score de um módulo crítico, um só, o que mexe com dinheiro. Roda uma vez, compara com a cobertura e você descobre em uma tarde se a sua suíte é garantia ou enfeite.

Nenhum dos quatro exige comitê, ferramenta paga ou projeto de seis meses. Exige alguém disposto a olhar o resultado e não gostar dele.

A conta não chega na sprint, ela chega no contrato

Nada disso é problema de ferramenta. É problema de incentivo. O modelo de contratação mais comum aqui paga por entrega fechada, com prazo curto e sem previsão de quem sustenta aquilo depois. Nesse desenho, volume de código é ótimo para o fornecedor e péssimo para você, e a IA apenas deixou o desalinhamento mais barato de executar. Ninguém precisa de má-fé para isso acontecer, basta o contrato pagar pela coisa errada.

Quando quem escreve é a mesma pessoa que responde pelo incidente de terça de madrugada, a régua muda sozinha. Ninguém aprova 900 linhas geradas em quatro minutos sabendo que vai ser acordado por elas. É por isso que a gente trabalha com squad embarcado no time do cliente, com nome e sobrenome de quem está no repositório, e é por isso que saber qual time vai realmente entregar pesa mais na decisão do que a diferença de preço entre duas propostas.

Na sua próxima reunião de time, faça duas perguntas nesta ordem: quantos pull requests fechamos no último mês, e quantas dessas mudanças um cliente usou. Se a segunda resposta demorar mais que a primeira, o material já está descarregado no canteiro e a obra continua no mesmo andar.