Martin Fowler: você não mede a produtividade que a IA promete

Toda diretoria que aprovou orçamento para ferramentas de IA em engenharia agora quer a mesma coisa: o número que prova que valeu a pena. Martin Fowler, uma das vozes mais respeitadas da engenharia de software e autor de clássicos como Refactoring, publicou em 2 de junho de 2026 um lembrete incômodo para quem procura esse número. Ele não existe, e insistir nele piora as decisões em vez de melhorar.

Quem está falando, e por que ouvir

Fowler passou décadas na ThoughtWorks observando times de software de perto e escrevendo sobre o que funciona. Quando ele fala de métricas, não é opinião de arquibancada. É uma posição que ele defende há anos, sintetizada em um texto que virou referência, o CannotMeasureProductivity. A tese é simples e desconfortável: produtividade é produção sobre esforço, e em software ninguém consegue medir produção de forma honesta. O valor real que um time cria depende de tantos fatores fora do controle dele que nenhuma contagem de saída captura o que interessa.

O gancho do fragmento de junho é um post de Greg Wilson, outro nome sério da área, conhecido pelo trabalho em ensino de computação. Wilson escreveu um artigo com o título provocador de doze maneiras de estar errado, listando as métricas que as empresas usam para decidir se as ferramentas de IA valem o custo. Linhas de código geradas. Tickets fechados. Pesquisas perguntando se os desenvolvedores se sentem mais produtivos. Para cada uma, Wilson mostra o vício embutido. Contar linhas premia quem escreve mais código, não melhor. Contar tickets incentiva picar o trabalho em pedaços menores. Perguntar percepção mistura entusiasmo com resultado.

O que Fowler acrescenta

Fowler concorda com a demolição, mas dá um passo além, e é aqui que o texto fica útil. Ele nota que Wilson derruba todas as métricas e não oferece uma alternativa melhor, e completa: na visão dele, como não dá para medir produtividade, qualquer métrica é evidência fraca até no melhor cenário.

O detalhe que salva o argumento de virar niilismo é a confissão seguinte. Fowler admite que ainda usa uma das métricas furadas de Wilson, justamente a de perguntar aos desenvolvedores se eles se sentem mais produtivos. Ele reconhece os problemas dessa medida, mas argumenta que, num ambiente onde medidas decentes são raras, até uma luz fraca é a melhor que existe. Métricas qualitativas assim não são conclusivas, mas são úteis.

Não dá para medir produtividade, então qualquer métrica é evidência fraca. Mas num escuro onde não há luz boa, até uma luz fraca ajuda a andar.

Essa é a diferença entre o cético preguiçoso e o cético útil. O preguiçoso diz que nada pode ser medido e cruza os braços. Fowler diz que nada pode ser medido com precisão, então você trabalha com evidência fraca de forma honesta, sem confundir o termômetro torto com a verdade. É uma postura de engenheiro maduro: aceitar a incerteza e decidir mesmo assim, em vez de fabricar uma falsa certeza para dormir tranquilo.

Por que isso importa para quem opera IA

A tentação que Fowler está combatendo é exatamente a que domina o mercado agora. Empresas gastaram dinheiro real com copilotos e agentes, e a pressão por justificar o gasto empurra todo mundo para o número mais fácil de coletar. O problema é a lei velha de gestão: métrica vira meta, e meta vira jogo. Se você cobra do time linhas de código geradas por IA, vai receber mais linhas. Se cobra tickets fechados, vai receber tickets fatiados. Nenhum dos dois te diz se o software ficou melhor ou se o cliente ganhou algo.

Isso conversa direto com o que já discutimos aqui em outras vozes. Quando Simon Willison observou que escrever código ficou barato mas código bom não, o ponto era o mesmo por outro ângulo: o volume despencou de preço, o julgamento não. Medir volume, portanto, mede a parte que perdeu valor e ignora a que ganhou. E quando a IA vira o ganho de produtividade que o FMI trata com cautela, a lição é a mesma na escala macro: produtividade de IA é difícil de comprovar, fácil de encenar.

Como decidir sem o número mágico

Se a métrica dura é uma ilusão, o que sobra não é o achismo, é o julgamento informado. Três práticas ajudam a operacionalizar a posição de Fowler sem cair no vazio.

A primeira é medir resultado de negócio, não atividade de produção. Fowler mata a métrica de saída, não a de desfecho. Você não consegue medir a produtividade de escrever código, mas consegue acompanhar tempo de ciclo até o cliente, taxa de defeito em produção, retrabalho, satisfação de quem usa. Esses sinais não isolam o efeito da IA, mas dizem se o sistema como um todo melhorou, que é a pergunta que importa. É o mesmo giro de foco que o Lean UX propõe ao medir resultado e não entrega.

A segunda é usar o sinal qualitativo de propósito, como Fowler faz. Perguntar ao time se ele se sente mais produtivo é uma métrica furada, mas é uma leitura barata e recorrente que, cruzada com outras, ajuda a formar um quadro. O erro é usá-la sozinha como prova. O acerto é usá-la como um dos vários termômetros tortos que, juntos, apontam uma direção.

A terceira é assumir a decisão como decisão, não como cálculo. Continuar ou cortar uma ferramenta de IA é uma escolha de gestão que pesa custo, sinal e risco, feita por gente que olhou o trabalho de perto. Fingir que essa escolha sai pronta de uma planilha é terceirizar julgamento para um número que não aguenta o peso. Quem decide precisa bancar a decisão.

Fowler não está dizendo que a IA não ajuda. Está dizendo que a ajuda dela não cabe na métrica que a diretoria quer. Para o operador, isso é libertador quando entendido direito: em vez de caçar a prova impossível, você observa o trabalho, acompanha o resultado do negócio e decide como adulto, com evidência fraca e honesta. É menos confortável que um dashboard verde. É bem mais próximo da verdade.

Se você quer avaliar o retorno da IA no seu time sem se enganar com métrica de vaidade, fala com a gente no WhatsApp.