Como medir produtividade em projetos com IA

Ferramentas de inteligência artificial para programação viraram rotina em muitas equipes. A pergunta que vem logo depois é simples de fazer e difícil de responder: o time ficou mais produtivo?

A resposta honesta costuma ser “depende de como você mede”. Uma equipe pode escrever mais código, fechar mais tarefas e, ao mesmo tempo, quebrar mais coisas em produção. Outra pode se sentir mais rápida sem estar. Este texto mostra como montar uma medição que resista a essas armadilhas.

Se o seu interesse é saber quanto das tarefas de programação a IA já consegue fazer, veja também IA na programação. Aqui o foco é outro: como medir o efeito no seu próprio projeto.

Por que a sensação de ganho não basta

O dado mais citado sobre o tema vem de um estudo da METR, organização de pesquisa que avalia sistemas de IA. Em julho de 2025, ela publicou um experimento controlado randomizado (estudo em que o acaso decide quem recebe o tratamento) com 16 desenvolvedores experientes de projetos de código aberto. Eles resolveram 246 tarefas reais em repositórios que conheciam bem, e cada tarefa foi sorteada para permitir ou proibir ferramentas de IA do início de 2025.

O resultado contrariou as expectativas. Antes do estudo, os participantes previam que a IA reduziria o tempo das tarefas em 24%. Depois, estimaram que ela tinha reduzido em 20%. Medido no relógio, o tempo com IA foi 19% maior.

A própria METR, no texto de divulgação do estudo, lista o que o resultado não mostra. Ele não prova que a IA atrasa a maioria dos desenvolvedores, a amostra é pequena e o cenário (pessoas veteranas em bases de código maduras) não representa todo tipo de trabalho. A lição que interessa aqui é de método: a percepção de quem usa a ferramenta pode divergir bastante do efeito medido.

O quadro também muda rápido. Em fevereiro de 2026, a METR informou que a continuação do estudo, com ferramentas do fim de 2025, deixou de produzir dados confiáveis. Muitos desenvolvedores se recusaram a trabalhar sem IA, o que distorce a amostra. As estimativas novas apontavam ganho de velocidade (redução de 18% no tempo para quem voltou ao estudo e de 4% para novos participantes), mas com intervalos de confiança que incluem zero, ou seja, sem conclusão firme. A organização avalia que o ganho provavelmente aumentou desde o início de 2025, mas diz que seus dados são evidência muito fraca do tamanho dessa mudança.

As métricas que enganam

Linhas de código

Mais código não significa mais valor. O artigo que apresentou o modelo SPACE, publicado na ACM Queue em 2021 por pesquisadores do GitHub, da Microsoft e da Universidade de Victoria, lembra que quem produz muito código pode não estar produzindo código de qualidade. Com IA, o problema cresce: gerar texto ficou barato, e um contador de linhas premia exatamente o que ficou barato.

Taxa de aceitação de sugestões

A taxa de aceitação é a fração das sugestões de código da IA que o desenvolvedor aceita. Ela parece um bom indicador, e há um motivo. Um estudo de 2022 com usuários do GitHub Copilot, de Ziegler e coautores, concluiu que essa taxa era a métrica que melhor acompanhava a produtividade percebida pelos usuários.

Repare na palavra “percebida”. A taxa diz quanto a pessoa gostou das sugestões, não se o software ficou melhor, se chegou mais cedo à produção ou se precisou ser refeito depois. Como vimos no estudo da METR, percepção e resultado podem andar separados.

Tarefas fechadas e story points

Contar tarefas concluídas ou pontos de estimativa (story points) também é medir atividade. O artigo do SPACE alerta que métricas de atividade nunca devem ser usadas isoladamente para premiar ou punir desenvolvedores, e que um time avaliado só por pontos tende a otimizar os próprios pontos em detrimento do trabalho invisível, como ajudar colegas.

O que medir: entrega e estabilidade (DORA)

O DORA (DevOps Research and Assessment) é um programa de pesquisa ligado ao Google Cloud que estuda o desempenho de entrega de software e publicou em 2024 seu décimo relatório anual. As métricas dele medem o sistema de entrega, não o indivíduo.

Durante anos o programa falou em “quatro chaves”. Segundo o guia de métricas do DORA, atualizado em janeiro de 2026, o conjunto atual tem cinco, divididas em dois grupos:

• Vazão (throughput): tempo de espera da mudança (do commit até a produção), frequência de implantação e tempo de recuperação de uma implantação que falhou.
• Instabilidade: taxa de falha de mudanças (implantações que exigem intervenção imediata, como reverter a versão) e taxa de retrabalho de implantação (implantações não planejadas, disparadas por incidentes em produção).

Essa divisão é útil para avaliar IA porque captura o efeito colateral típico: andar mais rápido e quebrar mais. O próprio guia faz alertas que valem para qualquer medição: metas numéricas convidam a “jogar” com o indicador (a chamada lei de Goodhart), uma métrica isolada engana, e comparar aplicações ou times diferentes entre si distorce a leitura. A ideia é comparar o seu time com ele mesmo ao longo do tempo.

O que os relatórios DORA encontraram

Os dados do DORA mostram por que olhar só a velocidade é arriscado. No relatório de 2024, a equipe estimou que um aumento de 25% na adoção de IA estava associado a melhora de 7,5% na qualidade da documentação e de 3,4% na qualidade do código, mas também a queda de 1,5% na vazão de entrega e de 7,2% na estabilidade.

No relatório de 2025, baseado em quase 5 mil respostas, 90% dos participantes disseram usar IA no trabalho e mais de 80% acreditavam que ela aumentou sua produtividade. Dessa vez, a relação entre adoção de IA e vazão de entrega apareceu positiva. A relação com a estabilidade continuou negativa. A explicação do relatório é que mais volume de mudanças tende a gerar instabilidade quando faltam testes automatizados fortes, controle de versão maduro e retorno rápido. A frase-síntese do DORA é que a IA amplifica o que já existe no time, para o bem e para o mal.

Uma ressalva: são pesquisas de opinião com associações estatísticas, não experimentos. Elas mostram tendências, não provam causa.

O que medir: as pessoas (SPACE)

O modelo SPACE complementa o DORA olhando para as pessoas e o fluxo de trabalho. O nome vem das cinco dimensões, segundo o artigo original:

• Satisfação e bem-estar: quão satisfeitas as pessoas estão com o trabalho, as ferramentas e a equipe, e sinais de esgotamento.
• Desempenho (performance): o resultado do trabalho, como qualidade, confiabilidade e impacto para o cliente.
• Atividade: contagens de ações, como commits, revisões de código e implantações.
• Comunicação e colaboração: como as pessoas trocam informação e integram o trabalho umas das outras.
• Eficiência e fluxo: capacidade de avançar sem interrupções, esperas e repasses.

Duas recomendações do artigo são diretamente aplicáveis. Primeiro, use métricas de pelo menos três dimensões diferentes, para que elas se contrabalancem. Segundo, inclua ao menos uma medida de percepção, como uma pesquisa interna. Os autores também pedem que os resultados sejam divulgados de forma agregada e anônima, por time, e não por pessoa.

Note a aparente contradição: depois de ver que a percepção engana, por que medir percepção? Porque ela mede outra coisa. A satisfação e a sensação de fluxo importam por si mesmas e podem antecipar problemas como esgotamento. O erro é usar a percepção como substituta do tempo ou da qualidade medidos.

Como montar um experimento no seu time

Na avaliação da redação, um desenho simples, inspirado nas práticas dos estudos citados, cabe na maioria das equipes:

1. Defina a pergunta. “A IA nos ajuda?” é vago demais. Prefira algo como “o assistente de código reduz o tempo de espera de mudanças sem piorar a taxa de falha?”.
2. Registre uma linha de base. Antes de mudar qualquer coisa, colete algumas semanas das métricas escolhidas. Sem o “antes”, não existe “depois”.
3. Crie uma comparação justa. O ideal é sortear, como fez a METR, tarefas ou períodos com e sem a ferramenta. Comparar um time que adotou IA com outro que não adotou mistura o efeito da ferramenta com diferenças entre os times.
4. Escolha métricas em tensão. Por exemplo: tempo de espera da mudança (vazão), taxa de falha de mudanças (instabilidade) e uma pesquisa curta de satisfação (percepção).
5. Meça o tempo real, além do estimado. Peça às pessoas que estimem o ganho e compare com o que foi medido. A diferença entre as duas coisas já é um resultado.
6. Dê tempo para o aprendizado. Os resultados podem mudar à medida que a equipe aprende a usar a ferramenta; a METR cita efeitos de aprendizado como uma das limitações do seu estudo.
7. Revise o desenho do experimento. O próprio caso da METR em 2026 mostra que, quando todo mundo passa a usar IA, fica difícil manter um grupo sem ela. Planeje isso.

Cuidado também com experimentos de laboratório. Num estudo controlado de 2023, Peng e coautores mostraram que desenvolvedores com o GitHub Copilot implementaram um servidor HTTP em JavaScript 55,8% mais rápido que o grupo de controle. É um resultado legítimo, mas para uma tarefa isolada e bem definida. Projetos reais têm código legado, revisão, integração e manutenção, que o laboratório não captura.

Qualidade e retrabalho entram na conta

Velocidade sem qualidade é só retrabalho adiado. Um levantamento da METR de agosto de 2025 ilustra o ponto. Um agente baseado no Claude 3.7 Sonnet passou nos testes automatizados escritos pelos mantenedores em 38% das execuções, em 18 tarefas de dois repositórios. Mas, das soluções revisadas manualmente, nenhuma estava pronta para ser incorporada sem ajustes: faltavam testes, documentação ou padrão de código. A estimativa de correção foi de 26 minutos, em média, mesmo nas que passaram nos testes. A amostra é pequena e os repositórios têm padrões exigentes, mas o recado é claro: “passou no teste” não é o mesmo que “está pronto”.

Para capturar isso no seu time, acompanhe:

• Taxa de falha de mudanças e retrabalho de implantação, do DORA.
• Rodadas de revisão por pull request (pedido de incorporação de código) e tempo gasto em revisão. Se a IA gera mais código, alguém precisa revisá-lo.
• Defeitos encontrados depois da entrega, por período.
• Código reescrito pouco tempo depois de entrar, se as suas ferramentas permitirem medir.

Para critérios de checagem do que a IA produz, veja como avaliar respostas de IA. E, se a sua equipe usa agentes que executam tarefas inteiras sozinhos, leia agentes autônomos: onde funcionam e onde falham.

O que levar deste texto

Produtividade de software não cabe num número só, e a IA torna isso mais evidente. Linhas de código e taxa de aceitação são fáceis de coletar, mas medem atividade e gosto, não resultado.

Uma medição útil combina vazão e estabilidade (DORA) com várias dimensões humanas (SPACE), parte de uma linha de base, compara de forma justa e trata qualidade e retrabalho como parte do custo. Os estudos citados são de 2021 a 2026 e as ferramentas mudam a cada poucos meses, então o resultado de hoje no seu time pode não valer daqui a um ano. Meça de novo.