A mesma métrica, números diferentes: por que ainda é difícil confiar na medição de IA
Medir IA na engenharia é novidade para o setor inteiro, inclusive para as ferramentas que se propõem a fazer isso. Cada uma reporta um número diferente para a mesma métrica. Quase todas medem o uso da ferramenta, quando o que o board pergunta é o resultado.
Um Engineering Manager abre três painéis para responder a uma pergunta que o board fez de manhã: o quanto a IA está ajudando o time. O primeiro dá um número. O segundo dá outro. O terceiro não bate com nenhum dos dois. Os três dizem medir “uso de IA”, e cada um definiu isso à sua maneira. No fim do dia, a resposta que sobe é honesta no tom e frágil no dado: a gente sente que está ajudando.
Fomos atrás dessa cena conversando com líderes de engenharia, para ouvir onde a medição dói de verdade. Um padrão se repetiu, mesmo entre empresas de contextos bem diferentes: quando os números de ferramentas diferentes não batem, a primeira coisa que se perde é a confiança em qualquer um deles.
Por que essa conta ficou urgente agora
Usar IA para escrever código deixou de ser novidade. Um levantamento da Pragmatic Engineer de 2025 aponta que 85% dos desenvolvedores já usam essas ferramentas no trabalho. A adoção já é grande. O que mudou foi o preço da pergunta seguinte. Token custa, licença custa, e o orçamento de IA virou linha que alguém acima do EM quer ver justificada. Quando o custo aparece, “a gente acha que ajuda” para de ser resposta suficiente.
E essa dificuldade não é de um time só. Num levantamento da LeadDev feito com a DX, ouvindo mais de 880 líderes de engenharia, a falta de métricas claras aparece entre os maiores desafios de quem adota IA. O EM que trava na hora de justificar está diante de um problema estrutural, não de um lapso pessoal.
Medir IA é novo para o setor inteiro, inclusive para as ferramentas
Duas camadas costumam cair no mesmo balde. Vale separá-las.
Nas métricas clássicas de engenharia (fluxo de entrega, tempo de ciclo, cobertura de teste, change failure rate), o mercado ao menos concorda sobre o que medir. Existe uma linhagem de mais de uma década, de DORA a SPACE, e ferramentas construídas em cima disso. Dá para discutir o número, mas a definição é compartilhada, e é ela que deixa o número comparável de um mês para o outro.
Na camada de IA, não existe nem esse consenso. Falta acordo sobre o que conta como “uso de IA”, “produtividade com IA” ou “qualidade do que a IA escreveu”. E isso não é só percepção de campo. Ao mapear como 18 grandes empresas de tecnologia medem o impacto da IA, a DX encontrou empresas parecidas, do porte de Microsoft e Google, medindo coisas diferentes, sem uma prática única que sirva de referência. Se quem tem times enormes e orçamento de sobra ainda está experimentando, o EM de um time menor não está atrasado. O terreno é novo para o setor inteiro ao mesmo tempo.
Some a isso um agravante herdado: medir produtividade de engenharia já era um problema não resolvido antes da IA. O setor discute isso há mais de uma década sem chegar a uma métrica única e confiável, e a IA chegou sobre um terreno que já estava instável.
O que essas métricas estão contando
Se a definição não é compartilhada, cada ferramenta preenche a lacuna do seu jeito. E aqui aparece a parte que os líderes menos gostam de admitir: o número que você recebe é o número que o fornecedor consegue medir. Um líder do Monzo colocou isso de forma direta ao Pragmatic Engineer, dizendo que o fornecedor mede o que dá, e é esse o número que chega até você.
O que quase todas essas ferramentas conseguem medir é a mesma coisa: o anel em volta do código. Uso da ferramenta, sugestões aceitas, sessões, tokens, teclada. Sinais de atividade, capturados da telemetria do editor ou do plugin. São baratos de instrumentar e, por isso mesmo, cada um recorta do seu jeito, o que explica por que a mesma métrica sai com valores distintos conforme a origem. Enquanto a conta olhar a atividade, ela vai continuar sem convergir, porque atividade é justamente a parte que cada fornecedor define como quiser.
E atividade responde à pergunta errada. O board não pergunta o quanto a IA foi usada. Pergunta o que ela deixou no produto. Esse sinal está num lugar diferente do anel de telemetria: está no que o time de fato entregou e com que qualidade, no código que foi mergeado e ficou de pé. Um artefato é mais difícil de recortar do que uma métrica de uso: ele é aquilo que ficou pronto.
Há ainda o reflexo mais antigo do mercado: na falta de uma definição boa, corre-se para a métrica fácil. Foi assim que a indústria voltou a se fixar em linhas de código e em “percentual de código escrito por IA”, números que rendem boa manchete e quase nada de leitura sobre qualidade ou resultado. “Percentual de código escrito por IA” é o retrato acabado disso: conta o volume que a IA gerou, sem uma palavra sobre se aquilo prestava.
A armadilha da taxa de aceitação
A taxa de aceitação de sugestões é o exemplo mais puro de contar o anel, e por isso vem perdendo espaço. Laura Tacho, CTO da DX, resume a armadilha numa pergunta: estamos confundindo atividade de IA com impacto de IA? A aceitação olha o instante em que a sugestão aparece e ignora o que vem depois: se o código se manteve, se foi revertido, se introduziu um bug. Ela registra que a IA foi usada. O que a IA deixou no fim fica de fora. Um número que sobe sem dizer se as coisas melhoraram não sustenta decisão, por mais preciso que pareça na tela.
O feeling não fecha a conta
Se o dado das ferramentas é frágil, a saída natural do EM é confiar na percepção do time. Aqui mora a última armadilha. Num experimento controlado do METR, no começo de 2025, desenvolvedores experientes trabalharam em repositórios que conheciam bem, metade das tarefas com IA liberada, metade sem. Eles se sentiram cerca de 20% mais rápidos usando IA. Na medição, levaram cerca de 19% mais tempo. O próprio METR trata o resultado como o retrato de um momento específico e já publicou números mais novos depois. O que interessa aqui é o descompasso, não a direção do efeito: a percepção, mesmo de quem está com a mão no código, é um instrumento pouco confiável para dizer se a IA está ajudando.
Painel e feeling falham pela mesma razão. Os dois olham a atividade: o painel pela telemetria, o feeling pela impressão de quem trabalhou. Nenhum dos dois olha o resultado que ficou. Medir mal não empurra para largar a medição. Empurra para mover a régua da atividade para o resultado.
Medir o quê, já que medir bem é difícil
A medição de IA vai continuar imperfeita por um bom tempo. O consenso não chega amanhã, e cada ferramenta vai seguir com o seu recorte. Quem lidera engenharia não vai escolher a medição perfeita. Vai escolher que pergunta vale a pena perseguir enquanto o consenso não vem.
Perseguir o uso é perseguir um número que sobe sozinho e não diz nada sobre o produto. Perseguir o resultado, o que o time entregou e com que qualidade depois que a IA entrou, é uma pergunta mais difícil de responder e a que o board de fato faz. A diferença entre um time que sabe conversar sobre IA com a liderança e um que responde no feeling costuma estar aí, em qual das duas perguntas ele decidiu levar a sério.
É esse o problema que a gente investiga no WeLuvCode: enxergar, direto do código, o que o time entrega e com que qualidade, a partir de uma definição estável de onde os números vêm, para que a evidência sirva a quem decide sem virar mais um painel para comparar. Ler o impacto da IA nesse mesmo eixo é uma frente que estamos construindo. Seria bom ouvir como outros times de engenharia estão lidando com isso à medida que a adoção amadurece.