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?”.
É CEO da Litteris Consulting. Profissional e estudioso de Tecnologia da Informação desde fins da década de 70, com educação formal diversificada, em Economia, mestrado em Ciência da Computação e MBA em Marketing de Serviços, e experiência profissional moldada pela passagem em empresas de porte mundial. Escreve constantemente sobre tecnologia da informação em publicações especializadas como CIO Magazine, Mundo Java, além do iMasters, e apresenta palestras em eventos e conferências de renome. É autor de sete livros que abordam assuntos como Software Livre, Grid Computing, Software Embarcado, Cloud Computing e Big data.
