A IA não tornou a engenharia mais barata. Empurrou a fatura para jusante.
Qualquer pitch de uma ferramenta de programação com IA vende-te a mesma coisa: velocidade. Escreve a funcionalidade em minutos, não em dias. Entrega mais com menos gente. As demos são reais — o primeiro rascunho chega mesmo em segundos.
Depois fecha o trimestre, e a fatura aparece num sítio onde não estavas a olhar.
Um novo estudo da Entelligence — um fornecedor, e já volto a isto — pôs um número em onde é que ela aparece. Ao longo de mais de um milhão de pull requests de 2.444 organizações de engenharia, mapearam onde aterra de facto o esforço de engenharia assistida por IA. A conclusão de destaque: por cada dólar que uma equipa gasta em programação com IA, cerca de 18 cêntimos viram produto entregue. Os outros 82 são consumidos antes de uma única funcionalidade chegar a um utilizador — gastos a corrigir, refazer e rever o que as ferramentas geraram.
Não leio este número da cadeira do investidor, nem da do fornecedor. Leio-o da que ocupo há vinte anos: a pessoa que tem de defender uma rubrica de custo de IA frente a um CFO e gerir a rotação de on-call que apanha aquilo que as ferramentas entregaram. E dessa cadeira, os 82 cêntimos não são desperdício. São a parte do trabalho que não ficou automatizada — e é o argumento mais forte que vi este ano para perceber porque é que o engenheiro é a parte que não consegues tornar mercadoria.
A IA tornou barata exatamente uma coisa: o primeiro rascunho
Tira o marketing de cima de um assistente de programação com IA e o que ele vende é um primeiro rascunho mais rápido. Gera código plausível a partir do contexto local — o ficheiro em que estás, a função acima, os padrões que viu um milhão de vezes. Isso é genuinamente valioso, e é genuinamente barato agora.
O que ele não consegue é saber qual desses padrões já falhou na tua produção no mês passado. Escreve a partir do repositório, nunca a partir da realidade: que edge case experimentaste e reverteste, que retry «óbvio» derrubou o serviço de pagamentos em março, porque é que aquele null check que toda a gente teima em apagar é estrutural. O modelo é o motor, e o motor ficou barato — já argumentei longamente porque é que um motor barato não é um carro barato. Gerar código sempre foi a parte fácil. Tornar o código gerado verdadeiro em produção é a parte difícil, e nada num primeiro rascunho mais rápido a torna mais fácil.
Os 82 cêntimos são a parte que só os teus engenheiros conseguem fazer
Olha para como o estudo reparte o dólar e o enquadramento de «desperdício» desfaz-se. Desses 82 cêntimos: aproximadamente 44 vão para trabalho reativo — corrigir bugs e manter os sistemas a funcionar —, 27 para refazer código que não sobreviveu ao contacto com a realidade, e 11 para revisão. Cada um deles é uma decisão de discernimento a jusante da geração. Cada um é o trabalho de decidir se a coisa plausível que o modelo escreveu é a coisa correta para entregar.
Aquele dólar não desapareceu. Mudou de sítio — de escrever o código para o verificar, integrar e operar. É o mesmo movimento para que não me canso de apontar: o valor sobe pela stack, da camada que o modelo te entrega para a que ele não consegue. Quanto mais barata fica a geração, mais do teu dólar se concentra na parte que precisa de um humano que já entregou antes. Chama-lhe a quota de trabalho reativo — e na organização mediana deste conjunto de dados, são 44% de toda a capacidade de engenharia, antes de contares a cauda longa onde passa dos três quartos.
Os reverts crescem mais depressa do que o trabalho que os cria
Aqui está o número que devia preocupar um CTO mais do que os 82 cêntimos. Ao longo de doze semanas, o estudo viu o volume semanal de pull requests subir 2,6× — e os PRs revertidos subir 3,7×. A falha está a compor-se mais depressa do que a saída. Não estás só a entregar mais; estás a entregar mais coisa que tem de ser puxada para trás.
O mecanismo não é misterioso, e não é que os engenheiros tenham piorado. É que a camada de revisão nunca escalou com o volume. Quando multiplicas o input de um processo de verificação 2,6× sem fazer crescer a verificação, a taxa de escape sobe por definição. O próprio relatório mostra-o sem rodeios: quase metade dos PRs são aprovados em menos de uma hora, a maioria dos comentários de revisão é ruído gerado por bots, e só cerca de um quinto dos comentários chega a ser tratado. Uma em cada quatro linhas escritas por semana é descartada dentro dessa mesma semana. Consegues gerar código à velocidade da máquina. Não consegues revê-lo à velocidade da máquina e continuar a chamar-lhe revisão — e o intervalo entre essas duas velocidades é exatamente de onde vêm os reverts.
Este número é de um fornecedor — eis porque continuo a confiar na forma
Agora a parte que a maior parte da cobertura saltou. A Entelligence vende a cura. O produto deles fecha «o ciclo entre o código e a produção» — que é, convenientemente, exatamente aquilo que o relatório conclui que te falta. Quando o vendedor de um número lucra com o teu alarme, descontao. Sempre.
Mais duas ressalvas que o relatório é honesto o suficiente para enunciar, e a que deves agarrar-te. Não há baseline pré-IA — isto é uma diferença de ritmo ao longo de doze semanas, não um antes-e-depois, por isso «a IA tornou as equipas mais lentas» é uma leitura plausível dos dados, não uma leitura provada. E «82 cêntimos de cada dólar de IA» é um modelo de para onde vai o esforço de engenharia em IA; não são 82% do dinheiro da tua empresa a arder. O relatório até inclui os números que cortam contra o seu próprio alarme: 18 cêntimos chegam mesmo aos utilizadores, e aquela taxa de aprovação em menos de uma hora tanto pode ser sinal de uma equipa saudável e bem equipada como de uma negligente.
Por isso não confio no número porque um fornecedor me desenhou um gráfico. Confio na forma — geração barata, verificação cara, falha a compor-se — porque bate certo com o que vejo acontecer em produção todos os meses. (Escrevi à parte sobre como essa mesma forma foi torcida até dizer algo que não diz no caminho para um título da Yahoo; o enquadramento é uma lição por si só.)
Já vimos este filme — é a fatura da cloud, uma camada acima
Se isto soa familiar, devia. Quando a cloud tornou o compute barato, o gasto não caiu — mudou de sítio, e cresceu, e passámos uma década a inventar FinOps para governar aquilo que tínhamos tornado fácil de consumir. A programação com IA é esse mesmo movimento uma camada acima na stack: tornou barato gerar código, e o custo mudou-se para verificá-lo e operá-lo. Os tokens são a nova rubrica e — como já argumentei antes — são um custo a governar, não uma produtividade a celebrar. O engenheiro continua a ser o multiplicador. A fatura só mudou de morada.
O que eu faria este trimestre se fosse o teu CTO
Um diagnóstico sem ação não passa de uma opinião. Cinco apostas concretas:
- Mede o change-failure-rate, não o volume. As ferramentas otimizam para o número de PRs; o negócio paga pelo número que é revertido. Põe métricas de resultado ao estilo DORA no dashboard que a tua liderança lê de facto, e vigia a taxa de falha contra a velocidade, não em vez dela.
- Trata os PRs escritos por IA como uma classe de defeitos própria. Etiqueta-os. Compara a sua taxa de revert e o tempo de vida dos bugs com as alterações escritas por humanos. Não consegues gerir um risco que te recusas a separar da média.
- Financia o harness, não só o gerador. Os 82 cêntimos são revisão, verificação e feedback de produção. Gasta aí. Em concreto: fecha o teu próprio ciclo — realimenta aquilo que realmente falhou e foi revertido para o contexto a partir do qual as tuas ferramentas geram, para que o próximo rascunho seja escrito a partir da realidade em vez do repo.
- Soma engenheiros, não os cortes. As equipas que cortam pessoal porque «a IA agora escreve o código» estão a despedir as únicas pessoas que tornam o código verdadeiro. Quem cortar mais fundo hoje passa 2027 a recontratar — o trabalho reativo não desaparece quando os revisores desaparecem, só vai parar primeiro aos teus utilizadores.
- Governa-a como cloud. Atribuição de tokens por workflow, um kill-switch em cada agente, e uma camada de routing que envia as tarefas triviais para o modelo mais barato que basta. O custo descontrolado numa organização com IA raramente é um engenheiro falador; é um agente preso num retry loop.
A linha que traço
A IA tornou o primeiro rascunho gratuito. Não tornou gratuita a versão entregue, verdadeira, que sobrevive — tornou-a mais valiosa, e há mais dela para construir do que alguma vez houve. Os 18 cêntimos que chegam aos teus utilizadores são a parte fácil. Os 82 que não chegam são onde a engenharia vive de facto, e fingir que uma ferramenta removeu esse trabalho é como acabas o ano a explicar uma taxa de revert ao teu conselho.
O modelo ficou barato. O discernimento não. Se a tua estratégia de IA confunde os dois, não tens uma equipa mais rápida. Tens uma limpeza maior.
A ver a tua taxa de revert subir mais depressa do que a velocidade desde que lançaste ferramentas de IA? Fala com um CTO — ajudamos-te a construir a camada de revisão e verificação que transforma um primeiro rascunho mais rápido em algo que consegues mesmo entregar.
