Como medir produtividade de desenvolvedores com IA

Medir produtividade de desenvolvedores com inteligência artificial exige comparar tarefas parecidas e olhar além da primeira entrega. A pergunta não é se a IA escreveu código mais rápido, mas se o trabalho chegou ao aceite com menos tempo total, sem empurrar custo para revisão, retrabalho ou suporte. Um bom começo é registrar três dimensões por tipo de tarefa: tempo até entrega revisável, esforço de revisão e alterações necessárias até cumprir o critério combinado.

Por que a produtividade com IA parece maior antes de ser medida

A percepção inicial costuma ser forte. A pessoa desenvolvedora descreve a mudança, a ferramenta sugere uma solução, os arquivos aparecem modificados e a primeira versão chega antes. Para quem acompanha o fluxo de longe, isso parece produtividade.

Mas produtividade em engenharia não termina quando existe código. Termina quando a mudança avança o sistema de forma verificável, dentro de um padrão aceito pela equipe. Entre a primeira versão e esse ponto entram perguntas que a velocidade de geração não responde: o código cobre o caso certo? Os testes protegem o comportamento esperado? A solução respeita decisões anteriores de arquitetura? A revisão ficou mais simples ou mais difícil?

É aí que a medição precisa ser menos seduzida pela demonstração e mais útil para decisão. Linhas de código, quantidade de commits e velocidade percebida podem mostrar atividade, mas não mostram avanço validado. Um fluxo com IA pode reduzir a implementação inicial e aumentar o esforço de revisão. Também pode fazer o contrário. Sem medir o caminho completo até o aceite, a liderança fica discutindo sensação.

Essa distinção conversa com uma ideia recorrente em qualidade de software: qualidade não deve aparecer apenas no fim. O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade, e também recomenda manter e revisar suítes de teste. Para medir produtividade de desenvolvedores com IA, isso importa porque o ganho real precisa sobreviver ao processo de verificação, não apenas à etapa de geração.

O que comparar: tarefas equivalentes, não médias genéricas

A forma mais rápida de medir mal é misturar tarefas diferentes e calcular uma média confortável. Uma correção simples de interface não deveria ser comparada com uma mudança em regra de domínio cheia de dependências. Um ajuste de teste não tem a mesma natureza de uma evolução de produto. Uma alteração em área estável do sistema não equivale a mexer em um módulo pouco conhecido.

A comparação útil começa por grupos de tarefas equivalentes. Não precisam ser idênticas, porque desenvolvimento real raramente oferece clones perfeitos. Mas precisam ser parecidas o suficiente para sustentar uma decisão prática.

Alguns critérios ajudam:

Tipo de trabalho: correção de bug com correção de bug, pequena evolução com pequena evolução, ajuste de teste com ajuste de teste.
Área do sistema: comparar tarefas dentro de partes semelhantes do produto, com padrões e dependências conhecidos.
Complexidade percebida: separar mudanças simples, moderadas e incertas, sem misturar tudo em uma média única.
Dependências externas: considerar se a tarefa exigia decisão de produto, resposta de outra equipe, mudança de ambiente ou ajuste de API.
Critério de aceite: só comparar tarefas que tinham uma definição mínima do que seria considerado concluído.

Essa separação evita uma armadilha comum: atribuir à IA uma diferença que veio do tipo de tarefa. Se as atividades com IA eram menores, mais repetitivas ou mais bem especificadas, a comparação fica enviesada. Se as tarefas sem IA eram mais ambíguas, o resultado também não diz muito.

A atualização da METR de fevereiro de 2026 é uma boa lembrança de cautela. A organização considera os novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades como seleção de participantes e tarefas, além de problemas para medir tempo com agentes concorrentes. Isso não decide o que acontecerá na sua equipe. Mas reforça que medir produtividade com IA exige desenho cuidadoso, principalmente na escolha das tarefas comparadas.

Três medidas mínimas: tempo, revisão e retrabalho

Para uma liderança de engenharia, qualidade ou produto, a medição precisa caber no fluxo. Se depender de um aparato pesado, a equipe abandona o registro ou passa a trabalhar para a métrica. O conjunto mínimo deve responder a uma pergunta: a IA reduziu o custo total de levar tarefas comparáveis até um aceite confiável?

A primeira medida é o tempo até entrega revisável. Ela vai do início efetivo da tarefa até o momento em que outra pessoa poderia revisar a mudança. Essa métrica captura a velocidade inicial. É útil, mas incompleta. Uma entrega revisável ainda pode estar errada, frágil ou difícil de entender.

A segunda medida é o tempo de revisão. Aqui entram leitura, comentários, perguntas, testes manuais, validações locais e discussões necessárias para aceitar ou rejeitar a mudança. Se a IA acelera o autor, mas torna a revisão mais longa, o ganho pode ter sido apenas transferido para outra pessoa. Em equipes pressionadas, esse custo aparece como fila, interrupção ou revisão superficial.

A terceira medida é o retrabalho até aceite. Retrabalho é tudo que precisa mudar depois da primeira entrega para cumprir o critério combinado. Pode ser correção funcional, ajuste de teste, simplificação de código, remoção de dependência desnecessária, tratamento de erro esquecido ou alinhamento com padrão técnico.

Essas três medidas evitam uma leitura rasa. Uma tarefa pode ter entrega inicial rápida e retrabalho alto. Outra pode começar mais devagar e passar pela revisão com menos ajustes. A decisão não nasce de preferir uma dessas etapas isoladamente, mas de entender onde o esforço se desloca.

Essa abordagem também conversa com a fronteira entre medir produtividade e discutir qualidade. Para aprofundar os mecanismos de validação, consulte o guia de qualidade de software com IA, sem transformar toda medição de produtividade em uma discussão completa sobre testes, revisão ou avaliação de agentes.

Como registrar dados sem transformar a equipe em laboratório

O registro deve ser leve o suficiente para acontecer no trabalho real. A equipe não precisa fingir precisão científica se o objetivo é decisão operacional. Precisa de consistência, honestidade e contexto.

Um bom registro por tarefa pode conter:

Tipo de tarefa.
Área do sistema.
Escopo resumido.
Uso de IA: sim ou não.
Tempo aproximado até entrega revisável.
Quantidade de ciclos de revisão.
Principais causas de retrabalho.
Decisão final: aceito, devolvido, dividido, suspenso ou refeito.

O ponto mais delicado é registrar causa, não apenas volume. Se o retrabalho veio de ambiguidade no pedido, culpar a IA é preguiça analítica. Se veio de teste insuficiente sugerido pela ferramenta, ignorar o papel da IA também é. Se a revisão cresceu porque o revisor não conhecia a área, a métrica está capturando um problema de conhecimento distribuído, não necessariamente de geração assistida.

A liderança deve tratar esses dados como sinais para conversa, não como placar individual. Medir produtividade de desenvolvedores com IA por pessoa, sem contexto de tarefa, incentiva comportamento defensivo. Medir por tipo de trabalho ajuda a decidir onde a IA entra no fluxo padrão, onde permanece opcional e onde deve ser restringida.

Há uma frase que vale manter na parede, mesmo que não vire regra formal: se a IA reduz o esforço visível de quem entrega e aumenta o esforço invisível de quem valida, a produtividade do sistema pode não ter melhorado.

Exemplo fictício: duas correções parecidas, resultados diferentes

Imagine um exemplo fictício em um produto de comércio eletrônico. A equipe precisa corrigir duas validações de formulário em áreas parecidas do sistema. As duas tarefas têm escopo pequeno, dependem de componentes conhecidos e possuem critério de aceite semelhante: impedir entradas inválidas, preservar mensagens de erro existentes e manter os testes relevantes passando.

Na primeira tarefa, a pessoa desenvolvedora usa IA para gerar a alteração inicial. A entrega revisável aparece rapidamente. Na revisão, porém, surgem dúvidas: um caso de erro não foi coberto, uma mensagem mudou sem necessidade e o teste criado verifica o comportamento de forma frágil. A tarefa volta para ajuste. Depois de nova rodada, outro ponto aparece: a solução tratava o caso comum, mas não preservava uma variação já existente no componente.

Na segunda tarefa, sem IA, a primeira entrega demora mais. A pessoa consulta o padrão usado em validações anteriores, altera menos arquivos e cria um teste mais próximo do comportamento esperado. A revisão ainda encontra ajustes, mas eles são menores e não mudam a direção da solução.

Esse exemplo não prova que IA atrapalha. Também não prova que trabalhar sem IA é melhor. Ele mostra por que a pergunta certa não é “qual primeira versão saiu antes?”. A pergunta é: em tarefas comparáveis, qual caminho levou ao aceite com menor custo total e risco aceitável?

Também poderia acontecer o oposto. Em uma tarefa repetitiva, bem especificada e com padrão claro, a IA pode acelerar a primeira versão sem aumentar revisão nem retrabalho. O critério é o mesmo: medir o percurso até o aceite, não defender uma preferência anterior.

Quando o ganho aparente não deve orientar a decisão

Há situações em que a medição deve ser lida com cautela. Não porque os dados sejam inúteis, mas porque podem estar respondendo a outra pergunta.

A primeira é a mistura de tarefas. Se o grupo com IA concentra ajustes simples e o grupo sem IA concentra mudanças ambíguas, a comparação está comprometida. A segunda é a curva de aprendizado. Nas primeiras semanas, parte do tempo mede adaptação à ferramenta, não o fluxo estabilizado. Isso pode piorar ou melhorar artificialmente a percepção.

A terceira aparece quando agentes executam ações concorrentes. Se uma ferramenta abre arquivos, altera trechos, roda comandos e relata conclusão, medir tempo fica mais difícil. Além disso, uma mensagem dizendo que terminou não comprova o resultado. A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente e descreve avaliações com entradas, critérios de sucesso e verificadores. Para produtividade, a implicação prática é simples: só conte como concluída a tarefa cujo efeito foi verificado.

A quarta situação é critério de aceite fraco. Quando ninguém sabe exatamente o que seria aceito, qualquer medição vira disputa narrativa. A IA pode produzir uma solução plausível para um pedido ruim, e a revisão pode virar descoberta tardia de escopo. Isso não é uma boa medida de produtividade. É um sintoma de definição insuficiente.

A quinta é mudança simultânea de ferramenta, processo ou pressão de prazo. Se a equipe trocou biblioteca, alterou política de revisão e adotou IA na mesma janela, isolar o efeito da IA fica improvável. Nesse caso, a melhor decisão pode ser reduzir a ambição da conclusão: observar sinais por tipo de tarefa, não declarar ganho ou perda geral.

Há ainda uma fronteira com lançamento e exposição de funcionalidades. O capítulo de Google SRE sobre canarying trata de avaliar uma mudança em uma parcela do tráfego antes de ampliar a exposição e distingue disponibilizar código de ativar funcionalidades. Embora esse tema não seja uma métrica de produtividade individual, ele lembra que entregar código não é o mesmo que liberar impacto para todos os usuários.

Checklist para medir produtividade de desenvolvedores com IA

Este checklist é uma proposta aplicada para a decisão de engenharia. Ele não é uma conclusão das fontes consultadas.

Comparabilidade da tarefa

A tarefa comparada tem tipo de trabalho, área do sistema, nível de dependência e critério de aceite semelhantes? Se a resposta for não, não use a comparação para concluir ganho ou perda de produtividade.

Tempo até entrega revisável

Quanto tempo passou entre iniciar a tarefa e entregar algo que outra pessoa poderia revisar? Use essa medida para avaliar velocidade inicial, não produtividade completa.

Tempo de revisão

Quanto esforço foi gasto para entender, questionar, testar ou corrigir a entrega? Se a revisão cresce muito, a IA pode estar transferindo trabalho do autor para o revisor.

Retrabalho até aceite

Quantas alterações foram necessárias depois da primeira entrega para cumprir o critério combinado? Retrabalho recorrente indica que a geração acelerou a primeira versão, mas não necessariamente a entrega final.

Resultado no ambiente

A tarefa realmente produziu o efeito esperado no sistema, e não apenas uma mensagem ou descrição de conclusão? Só conte como concluída quando o resultado puder ser verificado.

Causa do ajuste

O retrabalho veio de erro funcional, cobertura de teste insuficiente, decisão de produto, padrão técnico ou ambiguidade no pedido? Separar a causa evita culpar ou celebrar a IA por problemas de escopo, revisão ou processo.

Decisão sobre o fluxo

O uso de IA reduziu o tempo total sem aumentar risco, revisão ou retrabalho de forma relevante? Se sim, considere ampliar para esse tipo de tarefa. Se não, restrinja, redesenhe instruções ou mantenha o uso como experimento controlado.

Critério para decidir se a IA deve entrar no fluxo padrão

A decisão mais útil não é autorizar ou proibir IA de forma genérica. É definir em quais tipos de tarefa ela entra como prática padrão, em quais fica como apoio opcional e em quais exige cuidado adicional.

Avance quando tarefas comparáveis mostrarem redução ou estabilidade do tempo total até aceite, sem aumento relevante de revisão e retrabalho. Restrinja quando a economia na implementação migrar para revisores, qualidade ou suporte. Reavalie quando os dados estiverem contaminados por tarefas diferentes, critérios fracos ou mudanças simultâneas no processo.

A liderança deve transformar esse resultado em regra de uso por tipo de tarefa, com revisão periódica. Para organizações que estão estruturando adoção de IA além da engenharia, o artigo sobre como criar uma estratégia de inteligência artificial conectada ao negócio ajuda a ligar escolhas técnicas a prioridades organizacionais. Para diagnosticar o ponto de partida, o guia de maturidade em IA pode apoiar a conversa sem substituir a medição local.

Para o próximo ciclo, escolha um tipo de tarefa comparável, registre tempo até entrega revisável, tempo de revisão e retrabalho até aceite, e só amplie o uso quando o ganho não for apenas deslocamento de esforço.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.