Time olha o painel: frequência de deploy subiu, lead time caiu, todo mundo relata se sentir mais produtivo. E mesmo assim, alguém na reunião fala "parece que a gente não está entregando nada de verdade". Roadmap atrasa, revisor sênior está afogado, e ninguém consegue apontar exatamente onde está o problema, porque o painel diz que está tudo bem.
Isso não é impressão errada, e não é exclusividade da sua empresa. É um padrão que o próprio time de pesquisa por trás do DORA documentou em 2026, com nome e causa identificada.
O que o DORA media, e por que funcionava
DORA são quatro métricas — frequência de deploy, lead time para mudança, taxa de falha de mudança e tempo de restauração — criadas por Nicole Forsgren, Jez Humble e Gene Kim no livro Accelerate, de 2018, com base em anos de pesquisa em milhares de organizações de engenharia. Elas funcionaram bem por quase uma década porque partiam de uma premissa sólida: quando um time deploya com frequência, é porque fez o trabalho de disciplina — mudança pequena, pipeline maduro, entrega incremental. Frequência alta era efeito de boa prática, não causa dela.
O que quebrou: a causalidade inverteu
Em 2026, a IA passou a gerar entre 30% e 70% do código commitado em times que adotaram a ferramenta a sério. Isso muda a relação entre a métrica e o que ela deveria significar.
Frequência de deploy alta continua acontecendo — só que agora também acontece quando o time gera volume grande de código rápido, simplesmente porque gerar ficou barato, não porque a disciplina de entrega melhorou. Um caso documentado: um time foi de 5 para 20 deploys semanais depois de adotar ferramenta de IA. O número subiu. Não dá para saber, só olhando o número, se isso é entrega madura acontecendo mais rápido ou se é volume descontrolado indo para produção porque ficou fácil de gerar.
Lead time para mudança sofreu o mesmo problema, de forma mais sutil. Antes, lead time curto significava que o time removeu fricção real do processo. Agora, lead time curto também aparece quando a IA participa de boa parte da escrita — o tempo cai porque a etapa de codar ficou mais rápida, não necessariamente porque o processo em volta melhorou.
As duas métricas continuam subindo. O que elas significam mudou, e o painel não avisa isso.
O gap de atribuição
Existe um problema estrutural por trás disso: DORA, do jeito que a maioria das ferramentas mede hoje, não sabe diferenciar código gerado por IA de código escrito por humano. Um time pode ver frequência de deploy subir e taxa de falha de mudança piorar ao mesmo tempo — porque o código ficou mais difícil de revisar e manter — e não vai conseguir separar, só olhando o painel agregado, se a IA está ajudando ou atrapalhando. Sem essa segmentação, a decisão sobre onde investir fica no escuro.
O que ainda funciona, e o que a própria pesquisa DORA adicionou
Nem tudo quebrou. Tempo de restauração continua confiável — o tempo que leva para recuperar de uma falha não perde significado só porque IA participou da geração do código. Taxa de falha de mudança tem valor parcial: ainda sinaliza problema real, mas de forma isolada não diz se a causa foi código gerado por IA mal revisado ou outra coisa.
O próprio relatório DORA de 2025 — que passou a se chamar State of AI-assisted Software Development, mudança de nome que já é sinal — reconheceu o buraco e adicionou uma quinta métrica: rework rate, a proporção de correção não planejada que volta para produção depois do deploy original. Essa é, provavelmente, a métrica que mais explica a sensação de "não estamos entregando" apesar do painel bonito: se boa parte do que sobe é retrabalho disfarçado de entrega nova, a velocidade aparente esconde o problema em vez de revelar.
O mesmo relatório também passou a tratar sinais de experiência do desenvolvedor — carga cognitiva, peso da revisão, confiança na ferramenta — como indicadores antecedentes, não só resultado colateral. Faz sentido: se o time está exausto revisando volume que a IA gerou, isso aparece primeiro na sensação de sobrecarga, antes de aparecer como número ruim no painel.
O ponto de rigor que vale levar para qualquer discussão sobre isso
O próprio DORA nunca afirmou relação de causa e efeito entre as métricas e performance organizacional — os relatórios originais são explícitos sobre isso. A leitura popular, que virou clichê em apresentação de liderança — "melhorar frequência de deploy causa performance elite" — trata correlação como causa, o que a pesquisa nunca sustentou. Vale a mesma cautela para qualquer afirmação do tipo "adotar IA aumenta seu DORA": aumenta o número, não necessariamente aumenta a performance real que o número deveria representar.
O que fazer com isso, na prática
Três ajustes que fazem sentido para time pequeno ou médio, sem precisar de ferramenta enterprise de atribuição:
* Pare de comemorar frequência de deploy isolada. Ela subiu para todo mundo que adotou IA — deixou de discriminar time disciplinado de time acumulando problema.
* Comece a rastrear retrabalho, mesmo que manualmente. Quantos itens que você marcou como "entregue" voltaram como correção não planejada nas duas semanas seguintes? Esse número, ainda que aproximado, diz mais sobre entrega real do que deploy frequency sozinho.
* Trate sensação de sobrecarga do revisor como dado, não como reclamação. Se a percepção do time é "estamos entregando rápido mas exaustos revisando", isso é sinal antecedente de problema que vai aparecer no painel depois — não é ruído a ignorar até virar número.
A métrica não está mentindo. Ela continua contando exatamente o que sempre contou. O que mudou é que aquilo que ela conta parou de significar o que você presume que significa — e a única forma de perceber isso é olhar além do próprio painel.