O debate sobre IA em engenharia de software virou uma corrida por métricas rápidas. Toda semana aparece algum número prometendo “30% mais produtividade”, “50% mais velocidade” ou “metade do código agora gerado por IA”. O problema é que quase ninguém parece discutir seriamente o que exatamente está sendo medido.

Se uma empresa quiser provar que seus copilots “funcionam”, o que ela mede?

Linhas de código talvez sejam o exemplo mais antigo de métrica enganosa da engenharia. Mais código não significa necessariamente mais valor. Em muitos casos, o melhor trabalho que um engenheiro faz é justamente remover complexidade. Substituir 2 mil linhas frágeis por 200 linhas simples pode representar um avanço enorme, mas parecer “queda de produtividade” em dashboards superficiais.

O mesmo vale para throughput. IA acelera geração de output, mas software não termina quando o código é escrito. Existe revisão, integração, segurança, debugging, observabilidade, governança, manutenção e dívida técnica. E boa parte desses custos aparece depois.

Outro problema é o uso de tarefas artificiais como evidência científica. Muitos estudos analisam desenvolvedores criando pequenos projetos isolados, sem interrupções, sem legado, sem dependências organizacionais e sem pressão operacional real. Mas desenvolvimento corporativo raramente se parece com isso. A maior parte do trabalho em software não é escrever código “do zero”. É entender sistemas antigos, interpretar requisitos ambíguos, lidar com exceções, coordenar times, revisar mudanças e administrar risco.

E existe ainda um efeito psicológico que quase sempre é ignorado: novidade gera entusiasmo. Ferramentas novas frequentemente produzem sensação de aceleração antes que seus custos de longo prazo apareçam. O desenvolvedor sente que ficou mais rápido. A empresa sente que modernizou o processo. Mas meses depois começam a surgir aumento de complexidade, overload de revisão, código frágil, dependências excessivas e manutenção mais difícil.

E muitas métricas atuais acabam medindo atividade, não valor. Mais commits não significam melhor software. Mais adoção não significa melhor resultado. Às vezes significa apenas que a ferramenta está sendo usada.

Estamos tentando medir IA como ferramenta individual quando desenvolvimento de software é, na prática, um sistema organizacional. Se IA faz um desenvolvedor escrever código 40% mais rápido, mas o tempo total até produção continua igual porque revisão, validação e integração viraram gargalos, então o problema nunca foi apenas geração de código.

No fundo, parte do mercado parece desesperada para encontrar uma métrica simples que prove que “a revolução chegou”. Mas produtividade em engenharia sempre foi um fenômeno multidimensional, difícil de isolar e cheio de variáveis invisíveis.

A pergunta correta não é se “IA aumenta produtividade?”, mas é “produtividade de quem, em qual contexto, medida como, por quanto tempo e com quais custos acumulados depois?”.