Todo engenheiro com quem converso esse ano me diz a mesma frase. A IA deixou ele mais rápido. Aí eu olho o board do time inteiro e a entrega está mais ou menos onde estava no ano passado. Por muito tempo isso ficou só como sensação, conversa de corredor. Agora tem dado.
Saíram três relatórios em 2026 que medem isso com telemetria de verdade, não com pesquisa de opinião. Gente olhando pull request, incidente, tempo de review, retrabalho. E os três apontam para o mesmo canto. A IA não acelerou a entrega de ponta a ponta. Ela pegou o gargalo, que nunca esteve na digitação, e empurrou pra frente com mais pressão.
O gargalo nunca foi escrever código
Eu já tinha escrito por aqui, falando do V-Bounce e do 70/30, que o valor da engenharia migrou da execução para a intenção e a validação. A parte de gerar código comprimiu. O que ficou caro foi decidir o que construir e provar que está certo. Pois é exatamente isso que os números de 2026 mostram, só que de forma mais crua do que eu esperava.
O relatório da Faros, com telemetria de 22 mil desenvolvedores em mais de 4 mil times ao longo de dois anos, é o mais brutal. O tempo mediano de review subiu 441%. A razão de incidentes por PR subiu 242%. O churn de código, ou seja, código que entra e é refeito ou removido logo depois, cresceu 861%. E aqui está o número que mais me incomoda: 31% a mais de código está entrando em produção sem nenhuma revisão.
Repara no que aconteceu. A geração ficou barata, então o volume explodiu. Só que tudo que vem depois de gerar, revisar, validar, estabilizar, continua dependendo de gente. O gargalo não sumiu com a IA. Ele se mudou para o lugar mais difícil de automatizar e ficou maior.
Rápido pra mim não é rápido pra empresa
Tem uma armadilha aqui que vale separar. A produtividade individual subiu de verdade. O problema é achar que ela soma direto na produtividade da empresa.
O estudo da DX, olhando mais de 400 empresas, coloca isso em números honestos. O desenvolvedor economiza em média 3,9 horas por semana com IA. Real, mensurável. Mas o ganho de throughput do time fica em torno de 8%, e o ganho de produtividade que sobra no fim do funil costuma ficar entre 5% e 15%. Não os 3x, 10x que o marketing de ferramenta promete. Algumas empresas chegaram a relatar até 50% mais defeitos depois de adotar IA.
A conta não bate porque o trabalho de um vira fila para o outro. Eu gero três PRs no tempo que antes gerava um. Que ótimo pra mim. Só que alguém precisa revisar esses três. E esse alguém, em geral o engenheiro sênior, virou o novo ponto de estrangulamento do time. A velocidade individual virou lentidão coletiva.
O instrumento de medição quebrou
Essa para mim é a parte mais séria, porque é a que ninguém vê de cara. Não é só que a entrega não acelerou. É que a gente perdeu o instrumento de saber se acelerou.
O relatório da Harness é direto nisso. 89% dos líderes de engenharia dizem que a produtividade melhorou depois da IA. Beleza. Mas 94% admitem que fatores como dívida técnica, tempo de validação e burnout estão de fora das métricas que eles usam. 81% dizem que os desenvolvedores passaram a gastar mais tempo em review. E perto de 31% do tempo de trabalho é o que eles chamam de trabalho invisível, coisa que a organização nem rastreia.
Pensa no que isso significa. As métricas clássicas, linhas de código, frequência de deploy, velocity, lead time, foram desenhadas para um mundo onde digitar era o trabalho. Quando a IA escreve metade do código, esses indicadores não ficam só imprecisos. Eles ficam enganosos. Seu dashboard mostra o gráfico subindo justamente porque está medindo a parte que ficou barata, e está cego para a parte que ficou cara. É como medir a saúde de uma fábrica pela quantidade de peça que sai da primeira máquina, ignorando que o estoque de peça com defeito está estourando no fim da linha.
Parar de contar linhas, começar a medir validação
Não escrevo isso para dizer que IA não vale a pena. Vale, e muito. Escrevo porque a gente está otimizando a métrica errada, e métrica errada não é neutra. Ela financia o problema.
Se o gargalo migrou para a validação, é a validação que precisa entrar no painel. Na prática, eu olharia para quatro coisas que quase ninguém coloca lado a lado: tempo de validação por mudança, taxa de retrabalho e churn, latência de review (quanto tempo um PR fica parado esperando um humano) e defeito que escapa para produção. Essas medem o gargalo de hoje, não o de dez anos atrás.
E tem a disciplina por trás do número, que é onde o Spec-Driven Development entra. Se a especificação é a fonte da verdade, validar deixa de ser ler 600 linhas que a IA cuspiu e vira conferir se o resultado bate com a intenção escrita. A validação fica mais barata na origem, não no fim. Volume de código nunca foi sinal de progresso. Hoje, com a IA gerando tanto, ele virou quase um sinal de alerta.
O ponto que fica é esse. A IA cumpriu a promessa dela, ficou mais fácil produzir software. Só que produzir nunca foi o difícil. Se o seu painel ainda premia volume, você está pagando para alimentar exatamente o gargalo que precisa resolver.
Referências
- Faros Research, Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash. Faros AI, 12/04/2026.
- Harness, Harness Report Reveals AI Has Outpaced How Engineering Organizations Measure Developer Productivity. PR Newswire, 13/05/2026.
- Taylor Bruneaux, How to measure AI performance in software engineering. DX, 19/05/2026.
- Cory Hymel, The AI-Native Software Development Lifecycle (modelo V-Bounce). arXiv 2408.03416, 2024.