DORA Metrics em 2026: IA Melhorou ou Só Gerou Retrabalho?

Thoughtworks colocou DORA metrics em Adopt no Technology Radar Vol. 34 e amarrou o tema diretamente à era de desenvolvimento assistido por IA. Faz sentido. Se coding agents aumentam volume de código, precisamos medir resultado, não barulho.

Linhas geradas, prompts aceitos, PRs abertos e "tempo economizado" são métricas sedutoras. Também são perigosas. Elas medem atividade, não entrega.

A pergunta certa é: o time entrega mudanças mais rápido, com mais frequência e menos instabilidade? Se a resposta for não, a IA só mudou onde o retrabalho aparece.

---

Por Que DORA Voltou Ao Centro

DORA metrics já são conhecidas: lead time for changes, deployment frequency, failed deployment recovery time, change failure rate e deployment rework rate.

O Radar reforça que essas métricas são bons indicadores de performance organizacional porque olham para fluxo e estabilidade. Elas não perguntam se alguém digitou muito. Perguntam se software chega em produção com qualidade.

Na era de IA, isso ficou ainda mais importante. Um agente pode gerar mais código em menos tempo e, ao mesmo tempo, aumentar review, regressão, hotfix e suporte.

Produtividade real aparece no sistema inteiro. Não no editor.

---

Rework Rate É A Métrica Que Faltava

Deployment rework rate mede quanto do pipeline é consumido por retrabalho não planejado para corrigir algo que já foi considerado pronto. Bug em produção, regressão, correção emergencial e ajuste pós-release entram nessa conta.

Essa métrica é especialmente útil para IA. Se agentes aceleram implementação mas aumentam correções posteriores, lead time pode até parecer bom no curto prazo. Rework rate denuncia a dívida.

Pense no caso clássico: agente abre cinco PRs rápidos. Todos passam CI. Dois geram bugs sutis e exigem hotfix. O throughput subiu, mas a estabilidade caiu.

Sem rework rate, o dashboard celebra. Com rework rate, o time aprende.

---

Coding Throughput É Armadilha

Thoughtworks também colocou coding throughput como medida de produtividade em Caution. É um alerta direto contra medir linhas de código, commits ou volume de PR.

IA torna essa armadilha pior. Gerar mais ficou barato. Revisar, entender, manter e operar continua caro.

Um time pode dobrar volume de código e reduzir capacidade real de entrega porque review ficou congestionado, arquitetura ficou mais difícil e bugs começaram a escapar.

Métrica boa precisa resistir à automação. DORA faz isso melhor porque mede resultado de fluxo, não produção textual.

---

Como Medir Sem Virar Refém De Dashboard

O próprio Radar alerta: use DORA para reflexão e aprendizado, não para criar dashboard punitivo. Isso é crucial.

Se você transforma DORA em ranking de times, as métricas serão jogadas. Times vão reduzir escopo artificialmente, esconder falha, adiar deploy ou manipular classificação.

Use em retrospectiva. Pergunte: lead time subiu? Por quê? Deploy ficou menos frequente? Review travou? Rework cresceu após adoção de agentes? Qual tipo de tarefa mais gera correção?

O objetivo é melhorar sistema, não punir dev.

---

IA Como Amplificador

DORA research e análises recentes apontam para um padrão: IA amplifica práticas existentes. Time com bons testes, review e CI tende a ganhar. Time com processo fraco tende a acelerar bagunça.

Isso bate com experiência real. Agente em repo bem estruturado lê instrução, roda teste, corrige erro e entrega diff menor. Em repo sem teste e sem padrão, ele inventa caminho feliz.

Por isso DORA e curated shared instructions combinam. Instrução guia o agente. DORA mede se o sistema melhorou.

Um sem o outro fica incompleto.

---

Plano Prático Para Tech Leads

Comece com baseline antes de expandir IA. Meça lead time, deployment frequency, recovery time, change failure rate e rework rate por algumas semanas.

Depois escolha uma área para adoção controlada de agentes. Não coloque tudo de uma vez. Compare tendência, não episódio isolado.

Adicione classificação simples de PR: humano, agente assistido, agente autônomo. Não para fiscalizar pessoas, mas para entender efeito no fluxo.

Se rework rate subir, não culpe o modelo imediatamente. Olhe instruções, testes, review, escopo da tarefa e permissões do agente.

---

Como Definir Baseline Sem Sofrer

Não comece tentando criar dashboard perfeito. Comece com dados que você já tem: GitHub, GitLab, CI, incidentes, deploys e tickets. O objetivo inicial é direção, não precisão acadêmica.

Lead time pode começar como tempo entre primeiro commit e deploy. Deployment frequency pode vir do histórico de releases. Change failure rate pode ser aproximado por deploys que exigiram rollback, hotfix ou incidente. Recovery time pode vir dos registros de incidente.

Rework rate exige um pouco mais de disciplina. Você precisa marcar trabalho não planejado causado por mudança recente. Não precisa ser perfeito no começo. Uma tag simples em issue ou PR já ajuda.

Depois refine. O erro é esperar telemetria perfeita antes de aprender. Baseline aproximado já mostra tendência.

---

Separando Ganho Real De Deslocamento De Custo

IA muitas vezes desloca custo. Ela reduz tempo de escrita e aumenta tempo de review. Reduz tempo de implementação e aumenta tempo de debugging. Reduz esforço individual e aumenta carga de coordenação.

DORA ajuda a enxergar esse deslocamento. Se lead time caiu, mas change failure rate subiu, o ganho é suspeito. Se deployment frequency aumentou, mas recovery time piorou, o sistema ficou mais instável.

Também olhe para filas. Review acumulou? QA virou gargalo? Produto recebe mais bug report? Suporte reclama de regressão? Esses sinais não aparecem em acceptance rate de sugestão.

Produtividade de software é sistema. Agente melhora parte do sistema, mas pode pressionar outra.

---

O Perigo De Medir Dev Individual

DORA não foi criada para ranquear dev. Usar essas métricas para avaliar indivíduo cria comportamento ruim. Pessoas passam a otimizar indicador, não entrega.

Com IA, isso fica pior. Se você mede PRs por dev, agentes aumentam PR. Se mede linhas, agentes aumentam linhas. Se mede velocidade sem qualidade, agentes produzem velocidade frágil.

Métrica deve ser usada em nível de fluxo, time e sistema. A pergunta é: nosso processo melhorou? Não: qual dev usou mais IA?

Isso também protege confiança. Devs precisam se sentir seguros para reportar falhas de agentes. Se toda falha vira punição, ninguém documenta risco.

---

Como Classificar PRs Com IA

Uma classificação leve já ajuda muito. human-only, ai-assisted e agent-generated podem ser suficientes no começo.

human-only é mudança feita sem IA relevante. ai-assisted é humano conduzindo e editando com ajuda de modelo. agent-generated é quando agente produziu parte substancial do diff ou abriu PR.

Depois compare indicadores. PRs agent-generated demoram mais para review? Têm mais rework? Quebram mais testes? Ou aceleram tarefas mecânicas sem piorar qualidade?

Essa análise evita discussão ideológica. O time olha dados do próprio fluxo.

---

Rework Rate E Dívida Cognitiva

Thoughtworks também fala de cognitive debt gerado por IA. É quando o time aceita código que funciona superficialmente, mas entende menos o sistema depois.

Rework rate captura parte disso, mas não tudo. Um sistema pode não quebrar imediatamente e ainda ficar mais difícil de manter.

Por isso combine DORA com sinais qualitativos: reviews mais longos, dúvidas repetidas, aumento de complexidade, documentação desalinhada e medo de alterar certas áreas.

Agente pode gerar código correto localmente e aumentar carga cognitiva global. Métrica boa precisa deixar essa conversa aparecer.

---

O Que Fazer Quando Métricas Pioram

Se métricas pioram após adoção de IA, não corte tudo automaticamente. Faça diagnóstico.

O problema pode estar no tipo de tarefa. Talvez agentes estejam pegando trabalho grande demais. Pode estar no contexto. Talvez AGENTS.md esteja fraco. Pode estar nos testes. Talvez o agente não tenha sensor suficiente.

Também pode estar na revisão. Se reviewers não sabem revisar PR de agente, bugs passam. Review de IA exige atenção a intenção, escopo e validação, não só estilo.

Corrija o sistema e rode novo ciclo. O valor de DORA é mostrar onde olhar.

---

Exemplos De Decisões Baseadas Em DORA

Se lead time caiu e rework rate ficou estável, você pode expandir uso de agentes naquela classe de tarefa.

Se deployment frequency subiu, mas change failure rate subiu junto, reduza autonomia e melhore validação antes do merge.

Se recovery time piorou, talvez mudanças geradas por IA estejam difíceis de entender. Exija resumo melhor, menor diff e documentação de decisão.

Se review virou gargalo, limite tamanho de PR gerado por agente e crie checklist específico. Não adianta produzir mais PR do que o time consegue revisar.

---

DORA Não Substitui Produto

Também é importante lembrar: DORA mede capacidade de entrega, não valor de negócio. Um time pode entregar rápido e estável algo que ninguém quer.

Para avaliar IA de verdade, combine DORA com métricas de produto: adoção, receita, retenção, satisfação, tempo de atendimento, conversão ou redução de custo operacional.

IA pode melhorar engenharia sem melhorar produto. Ou pode melhorar produto às custas de instabilidade técnica. O equilíbrio depende do contexto.

Tech lead deve levar DORA para conversa com produto e negócio. Não deixar métricas presas ao dashboard de engenharia.

---

Como Comunicar Para Liderança

Liderança quer saber se IA está valendo investimento. Evite responder com "usamos em 70% dos PRs". Isso mede uso, não impacto.

Mostre antes/depois: lead time, frequency, failure rate, recovery time e rework. Conte também exemplos concretos de tarefas onde IA reduziu esforço e onde gerou retrabalho.

Essa transparência cria confiança. Ela mostra que o time não está comprando hype, está administrando mudança tecnológica.

Em 2026, maturidade em IA será menos sobre usar mais e mais sobre medir melhor.

---

Exemplo De Leitura Semanal

Uma leitura semanal simples já muda comportamento. Pegue os deploys da semana, separe mudanças com IA assistida e compare com o restante. Não precisa virar auditoria pesada.

Pergunte: quais mudanças chegaram mais rápido? Quais exigiram mais review? Quais geraram correção depois? Quais falharam em CI? Quais precisaram de rollback?

Depois transforme achado em regra. Se PRs de agente com mais de 500 linhas geram retrabalho, limite tamanho. Se mudanças sem teste quebram mais, fortaleça sensor. Se refactors amplos travam review, quebre tarefa.

Esse ciclo curto evita que a empresa só descubra problema depois de meses de adoção.

---

Métrica Boa Deve Mudar Decisão

Uma métrica só vale se muda decisão. Se o dashboard mostra rework alto e nada acontece, ele virou decoração.

Antes de coletar, defina gatilhos. Se change failure rate subir acima de certo nível, reduzimos autonomia. Se recovery time piorar, exigimos plano de rollback. Se lead time não melhorar após quatro semanas, revisamos tipos de tarefa delegada.

Isso torna adoção de IA operacional. Não é fé, nem medo. É experimento com regra de ajuste.

Times bons não acertam tudo de primeira. Eles detectam rápido e corrigem rota.

Esse é o ponto central: IA deve entrar como experimento operacional, não como decreto. Métrica boa dá permissão para avançar quando funciona e freio quando o custo escondido aparece.

---

Principais Aprendizados

• DORA mede resultado de entrega, não volume de código.
• Rework rate é essencial para detectar instabilidade gerada por IA.
• Coding throughput é métrica perigosa em times com agentes.
• Métricas devem apoiar aprendizado, não punição.
• IA amplifica práticas existentes: boas ou ruins.

---

Conclusão

O jeito mais honesto de medir IA em desenvolvimento é olhar para o sistema de delivery. Se lead time melhora, deploy fica mais frequente e estabilidade se mantém, há ganho real.

Se PRs aumentam, mas rework cresce junto, a IA só mudou a forma da dívida. DORA metrics ajudam a separar produtividade de ilusão.

---

Fontes e Referências

• Thoughtworks Radar - Techniques
• DORA - Software delivery performance metrics
• DORA - Quick Check updates
• Thoughtworks - Combat AI cognitive debt with engineering fundamentals
• Thoughtworks - Macro trends in the tech industry April 2026