Como medir a produtividade quando IA escreve o código
A IA pode tornar uma mudança de código proposta mais barata de produzir sem tornar essa mudança mais barata de confiar. Essa distinção importa porque organizações de engenharia não entregam sugestões, prompts ou completions aceitas. Elas entregam mudanças que passaram por revisão, checks automatizados, deploy e pelas consequências que aparecem depois.
Aqui, economia da verificação nomeia uma restrição específica: a IA aumenta a taxa de mudanças propostas mais rápido do que um sistema de engenharia consegue validá-las com confiança. A expressão é um enquadramento editorial, não um padrão estabelecido de engenharia de software; a mesma expressão já apareceu em trabalhos recentes sobre economia da IA, portanto não é exclusiva da DevStats.
A tese é condicional. Um estudo randomizado da METR encontrou que desenvolvedores experientes de open source levaram 19% mais tempo nas tarefas estudadas com ferramentas de IA do início de 2025; uma atualização posterior disse que efeitos de seleção impediram uma estimativa confiável para ferramentas mais novas. A DORA também descreve a IA como amplificador, não como melhoria garantida de performance.
A pergunta operacional é: o sistema consegue verificar e entregar mudanças com confiança na mesma velocidade em que consegue propô-las? Este artigo transforma essa pergunta em um scorecard de verificação com cinco partes.
O que a economia da verificação significa para engenharia
A restrição muda o lugar onde a capacidade de engenharia é consumida. A geração de código pode ficar mais rápida ou barata em alguns fluxos, mas a entrega ainda depende de pessoas e sistemas estabelecerem que uma mudança é compreensível, correta o suficiente para seu risco, compatível com seu ambiente e segura para liberar.
A pesquisa com desenvolvedores da Sonar oferece um sinal dessa tensão. Em um survey online com 1.149 profissionais de tecnologia que haviam usado IA no trabalho, os respondentes disseram que 42% do código que commitavam ou para o qual contribuíam era gerado ou significativamente assistido por IA; essa pergunta teve 979 respondentes.
O mesmo relatório afirma que apenas 4% concordaram completamente que código gerado por IA é funcionalmente correto. Outros 48% concordaram completamente que sempre verificam código assistido ou gerado por IA antes do commit, e 38% disseram que revisar código gerado por IA exige mais esforço do que revisar código escrito por desenvolvedores.
Esses são resultados autorreportados de survey, não telemetria de repositório, e a fonte é um fornecedor com interesse comercial em ferramentas de verificação. Portanto, devem ser lidos como evidência de pressão percebida sobre a verificação, não como prova de que toda organização tem o mesmo gargalo.
A DORA coloca essa pressão percebida em um sistema mais amplo. Ela trata a IA como amplificador: feedback loops fortes podem converter aceleração local em melhores resultados, enquanto sistemas fracos podem amplificar instabilidade. Sua orientação de entrega separa throughput de instability em vez de tratar velocidade como suficiente.
A economia da verificação, portanto, cobre todo o sistema que transforma uma mudança proposta em uma mudança que a organização está preparada para assumir.
Por que a IA quebra métricas de engenharia baseadas apenas em output
A IA torna várias medidas familiares de atividade mais fáceis de aumentar. Um time pode produzir mais sugestões, aceitar mais completions, abrir mais pull requests ou alterar mais linhas sem necessariamente melhorar a entrega.
Isso cria uma armadilha de measurement: a atividade pode se mover para cima enquanto o custo se move para baixo no fluxo.
Sugestões aceitas confirmam o uso da ferramenta, mas deixam desconhecidos o tempo de espera por revisão, o trabalho corretivo, a taxa de falhas e os outcomes de deploy. Um número crescente de PRs acrescenta contexto de throughput sem medir se os revisores têm capacidade suficiente para avaliar esses PRs bem. Linhas de código são um sinal de produtividade ainda mais fraco porque recompensam volume independentemente do valor, risco ou manutenibilidade da mudança.
O framework SPACE trata a produtividade de desenvolvedores como multidimensional e alerta contra reduzi-la a uma única medida de atividade. A DORA aplica o mesmo princípio no nível do sistema de entrega: throughput e instability precisam ser interpretados juntos.
A METR oferece um contraexemplo a claims automáticos de produtividade: no contexto estudado, desenvolvedores experientes levaram 19% mais tempo com IA. O resultado não se generaliza para a engenharia como um todo, e a METR depois alertou contra extrapolá-lo para ferramentas mais novas por causa de efeitos de seleção. Isso mostra por que o efeito precisa ser medido, não presumido.
O scorecard precisa de pelo menos três tipos de evidência:
| Sinal | O que pode dizer | O que não pode dizer sozinho |
|---|---|---|
| Uso de IA | Se as pessoas estão usando ferramentas de IA | Se os resultados de engenharia melhoraram |
| Fluxo | Como mudanças passam por coding, pickup, review, merge e deploy | Se fluxo mais rápido está produzindo resultados estáveis |
| Qualidade/retrabalho downstream | Se mudanças entregues criam trabalho corretivo ou falha | Qual causa upstream produziu o resultado sem linkage confiável |
As cinco métricas de um scorecard de verificação
Nenhuma métrica isolada captura a verificação. O scorecard precisa de sinais complementares para fluxo, demanda de revisão, trabalho corretivo e concentração de atenção humana.
Estas cinco métricas são propostas como um framework de measurement, não como padrões da indústria. Suas definições precisam ser adaptadas aos eventos que uma organização consegue realmente observar.
| Métrica | Pergunta central | Unidade | Instrumentação mínima | Principal modo de falha |
|---|---|---|---|---|
| Throughput Verificado | Estamos entregando mais mudanças sem comprar mais correção downstream? | mudanças/período + taxa | deploy + quality gates + linkage de outcome | atribuição fraca da falha de volta à mudança |
| Tempo de Verificação | Quanto tempo uma mudança espera e percorre a verificação exigida? | tempo decorrido | ready-for-verification + review + checks obrigatórios | contar duas vezes tempos de review/check sobrepostos |
| Demanda de Revisão por Revisor Ativo | A demanda de review cresce mais rápido que o conjunto de revisores? | reviews/revisor/período | pedidos de review + definição de revisor ativo | tratar participação individual como produtividade |
| Taxa de Retrabalho de Mudanças Assistidas por IA | Mudanças assistidas por IA geram mais correção que um cohort comparável? | percentual | provenance de IA no nível do PR + deploy + linkage de retrabalho | usar adoção de IA no nível do usuário como atribuição do PR |
| Concentração de Revisores | A verificação depende de um grupo pequeno de pessoas? | share/índice | distribuição de reviews por time/repo/janela | chamar concentração de "saturação" sem dados de capacidade |
1. Throughput Verificado
Throughput Verificado pergunta quantas mudanças entregues permanecem aceitáveis depois da janela de verificação e pós-deploy que você definiu.
Uma implementação defensável reporta uma contagem e uma taxa:
mudanças verificadas no período
e
mudanças verificadas / mudanças deployadas
A definição de verificada determina a métrica. Declare quais gates contam, quais outcomes downstream desqualificam uma mudança e quanto dura a janela de observação. Uma mudança pode precisar passar por CI e revisão humana e depois permanecer livre de rollback, hotfix ou incidente qualificável ligado a ela durante uma janela W. Não existe um valor universal para W; ele precisa se adequar ao sistema medido.
A separação da DORA entre throughput e instability segue o mesmo princípio: entrega mais rápida não deve ser interpretada sem um contra-sinal de outcomes negativos. Throughput Verificado estende essa lógica para um scorecard orientado à verificação; não é uma métrica DORA existente.
O limite está na fragilidade do vínculo causal. Se um incidente não puder ser ligado de forma confiável à mudança que o causou, descreva a métrica como incompleta em vez de repará-la com suposições.
2. Tempo de Verificação
Tempo de Verificação mede o tempo decorrido entre "pronto para verificação" e o momento em que todas as etapas obrigatórias de verificação pré-merge estão concluídas.
Isso pode incluir pickup humano, review, CI, testes, security checks ou outros gates obrigatórios. Como alguns acontecem em paralelo, use como medida principal o tempo de relógio entre dois eventos definidos:
timestamp de verificação concluída - timestamp de pronto para verificação
Use tempo de fila, review ativo e checks automatizados como componentes diagnósticos, sem simplesmente somá-los.
Use essa métrica para perguntar: onde reaparece o tempo economizado durante a geração?
Se o coding time cai enquanto o Tempo de Verificação aumenta, o sistema pode ter deslocado trabalho em vez de removê-lo. Se ambos caem enquanto outcomes downstream permanecem estáveis, a organização tem evidência mais forte de melhoria no nível do sistema.
Sistemas de PR cycle time normalmente observam etapas de pickup e review, mas uma organização não deve chamar isso de Tempo de Verificação completo a menos que todos os eventos obrigatórios de verificação estejam representados.
3. Demanda de Revisão por Revisor Ativo
Demanda de Revisão por Revisor Ativo mede a pressão entrando na revisão humana sem fingir que a capacidade de review é conhecida quando ela não é.
Uma versão simples é:
PRs entrando em review no período / revisores ativos no período
ou, quando pedidos de review são diretamente observáveis:
pedidos de review no período / revisores ativos no período
Leia o resultado junto com tamanho de PR ou outro sinal de complexidade da mudança. Vinte mudanças minúsculas e vinte mudanças grandes não representam a mesma carga de revisão.
Demanda de Revisão por Revisor Ativo substitui o nome original Review Capacity Ratio porque capacidade tem unidades. Se uma organização conhece o número planejado de horas de review por semana, pode estimar horas de demanda divididas por horas de capacidade planejada. Sem esse denominador, "capacity ratio" exageraria o que os dados sabem.
Mantenha essa métrica no nível de time, repositório ou serviço. Um número baixo de reviews pessoais não é evidência de baixa produtividade, e um número alto não é evidência de alta performance. O modelo multidimensional do SPACE é uma razão para não transformar dados de participação em rankings individuais.
4. Taxa de Retrabalho de Mudanças Assistidas por IA
A Taxa de Retrabalho de Mudanças Assistidas por IA compara trabalho corretivo após mudanças assistidas por IA com trabalho corretivo após um cohort de comparação apropriado.
Uma fórmula conceitual é:
mudanças assistidas por IA deployadas com retrabalho definido dentro de W / total de mudanças assistidas por IA deployadas
O mesmo cálculo pode ser feito para um cohort manual ou menos assistido por IA.
A Taxa de Retrabalho de Mudanças Assistidas por IA falha sem provenance de IA no nível da mudança. Saber que um desenvolvedor usa um assistente não prova que um PR específico foi assistido por IA. Adoção, sugestões aceitas, linhas geradas e PRs assistidos por IA são populações diferentes.
Defina retrabalho como um evento corretivo rastreável, como rollback ou hotfix ligado à mudança. Os cohorts de comparação também precisam de contexto porque mudanças assistidas por IA e manuais podem diferir em tipo de tarefa, codebase, risco ou experiência. Uma diferença de taxa justifica investigação; não estabelece automaticamente um efeito causal da IA.
Sem provenance no nível do PR e linkage confiável de retrabalho, essa taxa deve permanecer indisponível em vez de ser aproximada por adoção de IA no nível do usuário.
5. Concentração de Revisores
Concentração de Revisores pergunta se uma parcela desproporcional da verificação depende de um grupo pequeno de pessoas.
Ela pode ser expressa como uma medida simples de top-share, como a porcentagem de reviews realizada pelos 20% de revisores com maior participação, ou como um índice de concentração como HHI. O método escolhido deve ser documentado e mantido estável na janela de comparação.
Concentração e saturação são medidas diferentes.
Concentração é observável pela distribuição de reviews. Saturação significa que a demanda se aproxima ou excede a capacidade. Não é possível inferir saturação sem saber algo significativo sobre a capacidade disponível.
Concentração crescente pode sinalizar gargalos de especialistas, lacunas de ownership ou um sistema de review dependente de poucas pessoas. Deve provocar uma pergunta sistêmica: Por que a verificação depende desse conjunto estreito de revisores? A resposta deve orientar mudanças no processo, não um leaderboard.
Instrumentação vem antes de atribuição
Qualquer comparação entre mudanças assistidas por IA e manuais começa pela provenance.
Telemetria de uso pode dizer que pessoas estão usando IA. Ela pode contar sugestões, acceptances, sessões de chat, inserções ou eventos semelhantes quando a ferramenta os expõe. Mas adoção no nível do usuário não é suficiente para comparar mudanças assistidas por IA e manuais.
Para atribuição mais forte, prefira evidência no nível da mudança aproximadamente nesta ordem:
- metadata explícita do PR ou da mudança marcando assistência de IA;
- eventos de auditoria da ferramenta ligados de forma confiável a um PR ou commit;
- metadata de commit/mudança com método de atribuição documentado;
- adoção de IA no nível do usuário apenas como contexto, não como provenance no nível do PR.
A atribuição downstream tem o mesmo requisito. Um rollback ou incidente não é útil para Throughput Verificado ou Taxa de Retrabalho de Mudanças Assistidas por IA se o sistema de measurement não puder relacionar esse outcome à mudança relevante com um nível aceitável de confiança.
Uma comparação antes/depois pode confundir a adoção de IA com mudanças em arquitetura, staffing, política de review, cadência de release ou workload. Segmente por contexto, preserve uma baseline e faça claims causais apenas quando o desenho do estudo permitir. Quando a instrumentação não sustentar a comparação, reporte não mensurável com a instrumentação atual.
Como ler o scorecard como um sistema
O scorecard se torna útil quando as métricas são lidas em tensão umas com as outras.
| Padrão | Interpretação possível | Próxima pergunta |
|---|---|---|
| Throughput sobe e Tempo de Verificação sobe | Mais mudanças estão chegando a um sistema restrito de review/validation | Qual componente da verificação está acumulando tempo? |
| Throughput sobe e retrabalho/falha sobe | A aceleração pode estar instável | Quais tipos de mudança ou cohorts criam a correção downstream? |
| Demanda de review sobe e Concentração de Revisores sobe | A verificação pode depender de um grupo cada vez menor | Ownership ou conhecimento especializado está virando gargalo? |
| Uso de IA sobe enquanto outcomes de entrega ficam estáveis | Adoção aumenta sem ganho demonstrado no sistema | Para onde tempo ou esforço está sendo realocado? |
| Tempo de Verificação cai enquanto falhas sobem | Gates podem estar enfraquecendo ou sendo contornados | Quais checks mudaram e coverage ou profundidade de review caiu? |
Essas são interpretações diagnósticas, não conclusões causais.
Throughput crescente junto com Tempo de Verificação crescente não prova que IA criou o gargalo. Diz que a verificação demora mais enquanto o output cresce; depois, segmente por provenance de IA, repositório, tipo de trabalho, tamanho de PR ou outra dimensão relevante.
Um único "AI productivity score" é, portanto, um alvo ruim. A separação da DORA entre throughput e instability e a visão multidimensional do SPACE sustentam um portfólio de sinais, não um único número.
Guardrails de measurement para a era da IA
Measurement de IA deve ajudar times a melhorar o sistema de entrega, não fazer indivíduos otimizarem o número que a gestão decidiu expor.
Cinco guardrails mantêm o scorecard de verificação útil:
- Meça o sistema antes da pessoa. Prefira unidades de time, repositório, serviço ou value stream para demanda de review, retrabalho e verificação.
- Nunca iguale atividade a produtividade. Sugestões aceitas, commits, linhas alteradas, PRs abertos ou reviews concluídos podem ser contexto. Nenhum é uma medida independente de produtividade.
- Publique denominadores e janelas. Uma taxa sem sua população e seu período de observação é difícil de interpretar e fácil de manipular.
- Pareie velocidade com consequência. Coding, review ou deploy mais rápidos só se tornam um resultado mais forte quando instability e trabalho corretivo não crescem junto.
- Use baselines locais antes de thresholds universais. O scorecard de verificação é um framework. Ele não vem com valores universais defensáveis de "bom" para estas cinco métricas.
Esses guardrails direcionam a atenção para onde o trabalho espera, como a confiança é estabelecida, onde o trabalho corretivo aparece e qual restrição do sistema precisa de mais capacidade ou melhor automação.
O que a DevStats consegue observar e o que ainda precisa ser derivado
A DevStats já expõe vários sinais que se encaixam no scorecard de verificação, mas o framework não deve ser confundido com cinco métricas prontas do produto.
Para review e fluxo, a DevStats apresenta atividade de code review e tamanho de PR e divide o PR cycle time em etapas como Coding, Pickup, Review, Merge e, quando há dados de deploy disponíveis, Deploy. Também apresenta sinais de throughput e atividade como PRs merged, PRs opened, reviews, commits e code changes.
Para trabalho assistido por IA, a DevStats consegue comparar PRs identificados como assistidos por IA e PRs manuais em sinais de fluxo como cycle time e throughput. Também apresenta sinais relacionados à qualidade para trabalho assistido por IA, incluindo padrões de review, sinais de bug rate e resultados de security scans.
Para correção downstream e estabilidade, a DevStats apresenta rework como parte de sua análise de engenharia. Quando deployment e incident tracking estão configurados, também consegue calcular sinais de instabilidade de entrega como Change Failure Rate e Mean Time to Recovery.
| Métrica do scorecard | O que é observável | O que ainda exige derivação ou configuração |
|---|---|---|
| Throughput Verificado | throughput, contexto de deploy, sinais de incident/rework | definição de verificada, janela de observação e linkage confiável entre outcome e mudança |
| Tempo de Verificação | etapas de pickup/review/cycle time | timeline completa dos checks obrigatórios se conclusão de CI/security/tests não estiver representada |
| Demanda de Revisão por Revisor Ativo | atividade de review e tamanho de PR | denominador de revisores ativos e definição de demanda escolhida |
| Taxa de Retrabalho de Mudanças Assistidas por IA | cohorts AI-assisted/manual e sinais de rework | join confiável entre provenance de IA, mudança deployada e janela de retrabalho |
| Concentração de Revisores | distribuição de participação em reviews | método de concentração escolhido e janela de análise estável |
O valor prático vem de conectar adoção de IA, fluxo de entrega, pressão de review, retrabalho e estabilidade sem reduzir performance de engenharia a atividade.
Se sua organização está tentando entender se a IA melhora o sistema de entrega inteiro ou apenas desloca trabalho downstream, conheça a DevStats.
Uma forma verification-first de avaliar engenharia com IA
Faça uma pergunta:
O sistema de engenharia consegue validar e entregar mudanças confiáveis na mesma velocidade em que consegue propô-las?
Use a adoção de IA como contexto. Leia throughput contra instability, relacione demanda de review à concentração de revisores e espere por provenance confiável no nível do PR antes de comparar trabalho assistido por IA e manual.
Quando a verificação acompanha e a correção downstream permanece estável ou melhora, uma taxa maior de mudanças propostas sustenta um ganho no nível do sistema. Quando filas, concentração de revisores, retrabalho ou falhas crescem, o scorecard mostra onde o ganho esperado foi absorvido.
É isso que a economia da verificação acrescenta ao measurement de produtividade com IA: visibilidade sobre o custo de estabelecer confiança.