Publicado em

82% do gasto com IA não chega ao produto. E isso era exatamente o esperado.

Os números do desperdício com IA estão certos, a leitura é que não, porque é assim que toda transição tecnológica se parece nos primeiros três anos.

Em

Tags

Os números estão certos. A leitura é que não.

O dado vazou essa semana e viralizou nos lugares óbvios. Uma análise da EntelligenceAI em 2.444 empresas mostrou para onde vai cada dólar gasto em desenvolvimento assistido por IA:

  • $0,44 – corrigindo bugs gerados pela própria IA
  • $0,27 – reescrevendo código que não atendeu
  • $0,11 – em fricção de review, context switching, merge
  • $0,18 – efetivamente entregando valor ao usuário final

82% do gasto não chega ao produto.

A leitura preguiçosa foi imediata: IA é hype, não funciona, todo mundo enganado, voltem para o Stack Overflow.

Essa leitura ignora 36 meses inteiros de como essa indústria está operando – e o que ela está aprendendo a fazer.

A história tem 3 anos

A linha do tempo do tooling que de fato mudou o trabalho:

  • GitHub Copilot – 2022. Autocomplete contextual baseado em LLM. Primeira vez que sugerir-código-em-tempo-real virou produto mainstream.
  • Cursor – 2023. IDE inteiro reconstruído ao redor do modelo. Conversa com codebase, edição multi-arquivo, comandos por linguagem natural.
  • Windsurf – 2024. Cascade, primeira tentativa séria de agente colaborativo dentro do editor.
  • Claude Code – 2025. Agente autônomo no terminal, operando sobre o repositório com permissão de executar comandos.

Não são versões incrementais da mesma coisa. Cada um propõe um modelo diferente de relação entre desenvolvedor e código. A indústria nem chegou em consenso sobre qual abordagem ganha – e nem deveria, porque ainda não terminou de explorar o espaço de soluções.

E o Spec-Driven Development, que voltou à tona em 2025 como a “forma certa” de usar IA para programar? Existe desde 2004. Ninguém inventou nada – a indústria redescobriu uma prática antiga porque o custo de não usá-la subiu drasticamente com agentes que produzem código em volume.

Tradução: engenharia de software assistida por IA tem, na prática, 3 anos de existência madura. E estamos cobrando dela métricas como se tivesse 30.

Por que esses 82% são exatamente o esperado

Pegue qualquer transição tecnológica relevante das últimas décadas e olhe os primeiros 3 anos.

Quando frameworks SPA (React, Angular, Vue) começaram a substituir jQuery e renderização server-side por volta de 2014-2016, milhares de projetos foram reconstruídos em SPA simplesmente porque era a moda. A maioria não precisava ser. Aplicações simples de CRUD viraram bolas de neve de complexidade, estado client-side mal gerenciado, problemas de SEO descobertos tarde demais. Quantas horas foram queimadas reescrevendo dashboards de Angular 1.x para React, e depois para Next.js? Quantos blogs viraram Gatsby antes de virarem Next antes de voltarem para WordPress?

Quando microsserviços se tornaram a tendência arquitetural por volta de 2015-2018, empresas que tinham monolitos perfeitamente funcionais os decompuseram em 30, 50, 100 serviços porque era o que o Netflix fazia. A maioria não tinha problema de escala que justificasse a decisão. Anos depois, vimos a onda inversa: “modular monolith”, “back to the monolith”, consultores caros refazendo o que outros consultores caros tinham desfeito.

Quando a cloud chegou ao mainstream por volta de 2012-2015, milhões foram queimados em lift-and-shift mal feito – migrar máquinas virtuais como se fossem servidores físicos, ignorar que cloud cobra por uso, descobrir contas absurdas no terceiro mês. Anos depois a indústria aprendeu o que era workload cloud-native, FinOps virou disciplina, e os primeiros projetos foram reescritos.

Cada uma dessas ondas teve seu “82% do gasto não vira produto”. Nenhuma teve dashboard pronto para circular no LinkedIn no calor do momento.

A diferença da IA é que o ciclo está visível em tempo real. Os tokens são contáveis. A telemetria é granular. O desperdício é mensurável por empresa, por sprint, por commit.

Isso não é um problema. É um privilégio.

Pela primeira vez na história da indústria de software, conseguimos medir o custo do aprendizado coletivo enquanto ele acontece. E ainda assim a leitura dominante é a do espanto – como se a existência do desperdício invalidasse a tecnologia, em vez de provar que ela está sendo de fato experimentada.

O que separa quem está aprendendo de quem só está pagando

A pergunta interessante não é “por que tem desperdício”. É outra:

Das equipes queimando esses 82% hoje, quais vão estar entregando 60% de valor daqui a 18 meses – e o que elas estão fazendo diferente das que vão continuar queimando 82% para sempre?

A resposta começa a aparecer em padrões observáveis nas equipes que estão saindo da curva.

Spec-driven, não vibe-driven. Antes do prompt, existe uma especificação. Antes da especificação, existe um problema claramente formulado. Equipes que tratam IA como gerador de código sem essa estrutura ficam presas no loop infinito “gerar, testar, ajustar prompt, gerar de novo”. Equipes que partem de spec usam a IA para implementar, não para descobrir o que precisa ser feito.

Eval harnesses, não confiança cega. Código gerado por IA é testado antes de chegar perto de produção – não com revisão humana ad hoc, mas com suítes automatizadas que medem comportamento. Bugs gerados por IA são caros, mas previsíveis. Quem investe em verificação automatizada paga uma vez; quem revisa caso a caso paga toda sprint.

Escopo cirúrgico, não rewrite total. A tentação de pedir “reescreve esse módulo inteiro usando IA” é exatamente o que produz os 27% de rework. Equipes maduras usam IA em escopos limitados – uma função, um teste, um refactor pontual – e mantêm humanos como integradores arquiteturais.

Tooling estável, não chase the shiny. Parte da diferença entre uma equipe que aprende e uma que só gasta é quanto tempo ela permanece em um workflow antes de pular para o próximo. Times que mudam de Copilot para Cursor para Claude Code para Windsurf a cada três meses não aprendem nenhum profundamente.

Nenhum desses pontos é novo. Nenhum é segredo. Mas eles separam o 18% que entrega do 82% que aprende.

Fechamento

Os números do gráfico não estão errados. A leitura é que está.

Quem olha para 82% de desperdício e vê fracasso está medindo uma indústria de 3 anos com padrões de 30. Está confundindo o snapshot com a curva.

A curva é o que importa. E ela tem uma forma reconhecível: investimento alto, retorno baixo, ajuste de prática, retorno crescente. Já vimos esse filme com SPAs, com microsserviços, com cloud. Vamos ver com IA também.

Ainda estamos aprendendo a usar IA para construir software em produção – não para autocompletar função, mas para entregar produto com qualidade e em escala. Aprender isso é como construir um foguete do zero: você vai explodir vários antes de lançar o primeiro de verdade.

Os 44% queimados em correção de bugs são os foguetes explodindo na plataforma. Os 27% em rework são os foguetes que decolaram torto. Os 11% em fricção de review são a equipe terrestre brigando sobre qual válvula apertar enquanto o cronograma derrapa.

Não importa.

O que importa é que algumas equipes estão pegando os destroços, identificando o que falhou, e ajustando o próximo foguete. E outras estão olhando o gráfico de explosões, concluindo que foguetes não funcionam, e voltando para o transporte por caravela.

Foguete novo explode. O que decide quem chega na lua é o que se faz depois.