DORA 2026: o ROI da IA no desenvolvimento passa pelo code review

A IA já faz parte da rotina de muitos times de engenharia. E, para mim, a discussão mais interessante já não é se ela ajuda a escrever código mais rápido. Isso está cada vez mais claro.

A pergunta é o que acontece com essa velocidade depois.

Foi isso que mais me chamou atenção no relatório DORA 2026, “The ROI of AI-assisted Software Development”. Em vez de parar na produtividade individual, o relatório olha para o fluxo completo e tenta entender quando o uso de IA realmente se transforma em retorno para o time e para o negócio.

Porque escrever mais código e abrir PRs mais rápido, sozinho, não garante que a empresa está entregando mais valor.

Se o restante do processo não acompanha, o ganho começa a aparecer em outros lugares como custo: mais mudanças esperando revisão, mais retrabalho, mais testes quebrando e mais risco chegando à produção.

É por isso que eu não vejo a IA como algo que elimina gargalos. Muitas vezes, ela só desloca o problema para a etapa seguinte.

E é aí que o code review fica ainda mais importante.

Se o time aumenta o volume de código, mas continua revisando do mesmo jeito, com pouco contexto e poucos sinais claros de risco, parte da velocidade conquistada na escrita se perde durante a validação.

A mudança chega mais rápido ao PR, mas pode ficar parada na revisão, nos testes, na aprovação ou aparecer depois como problema em produção.

Nesse artigo vou trazer os principais insights que tirei desse relatório, espero que te ajude.

A IA aumenta o que o time já tem

Uma das ideias mais interessantes que o relatório traz é sobre tratar IA como um amplificador.

Em um time com bons testes, PRs pequenos, contexto técnico acessível e um fluxo de entrega saudável, a IA tende a ampliar a capacidade de entrega. Já em um time com revisão lenta, testes frágeis, excesso de aprovações manuais e arquitetura pouco documentada, ela tende a ampliar os problemas que já existem.

O relatório também lembra uma coisa simples, mas fácil de ignorar: código pode se tornar passivo. Mais código significa mais coisa para manter, revisar, proteger e operar. Então, quando a IA aumenta o volume de código sem uma camada proporcional de verificação, o time paga depois. Paga em retrabalho, incidente, dívida técnica e tempo de engenharia preso em correção.

Para quem lidera engenharia, medir o retorno da IA exige olhar além da licença. Também entra na conta o tempo gasto para entender, validar e corrigir o código que ela produz.

A J-Curve explica a queda inicial de produtividade

O relatório usa a ideia da J-Curve para explicar a adoção de IA no desenvolvimento. No começo, é normal o time sentir uma queda temporária de produtividade antes de capturar valor.

Essa queda costuma vir de coisas bem concretas:

• tempo para aprender a usar melhor as ferramentas;
• adaptação do fluxo de trabalho;
• esforço extra para revisar código gerado;
• mais pressão sobre testes, pipelines e aprovações.

DORA chama parte disso de taxa de verificação: o esforço adicional para checar se o código gerado pela IA é confiável, seguro e coerente com a arquitetura do sistema.

Isso é importante porque evita uma leitura errada da adoção. Se a liderança espera um retorno imediato, pode interpretar essa queda inicial como um fracasso. Mas, em muitos casos, ela é o custo de aprender a operar a IA dentro do sistema de engenharia. O problema começa quando esse custo não foi planejado e ninguém está medindo onde ele aparece.

Code review virou uma alavanca de ROI

Quando a IA acelera a geração de código, o code review se torna ainda mais importante para controlar risco e manter a consistência das mudanças.

Ele continua protegendo qualidade, claro. Isso já fazia parte do trabalho: pegar problemas de lógica, arquitetura, segurança, legibilidade e impacto em produção.

Mas, com IA, o code review também passa a proteger o retorno do investimento.

Se uma mudança fica parada por dias esperando revisão, a velocidade conquistada na escrita não se transforma em entrega. Se PRs grandes são aprovados sem contexto e sinais suficientes de risco, essa velocidade pode aparecer depois como retrabalho, incidentes e instabilidade.

Nos dois casos, o valor gerado pela IA se perde antes de chegar à produção.

O relatório conecta isso com duas dimensões de entrega: throughput e instability. Throughput mostra o volume e a velocidade das mudanças passando pelo sistema. Instability mostra o custo quando essas mudanças falham, geram incidente ou exigem recuperação.

Na prática, o objetivo não é fazer o time abrir mais PRs só para parecer mais rápido. O objetivo é aumentar throughput sem empurrar a instabilidade para cima.

A métrica precisa olhar para o fluxo inteiro

Uma coisa que tenho visto bastante na adoção de IA é o time medir o impacto só pelo tempo economizado por desenvolvedor. Esse número ajuda, claro, mas sozinho não diz se a engenharia está entregando melhor.

Um dev pode economizar uma hora por dia com IA. Mas, se essa velocidade gera PRs maiores, revisões mais lentas e mais retrabalho, o ganho não se transforma em resultado para o negócio. Ele se perde no processo.

Por isso, o retorno precisa ser medido ao longo do fluxo inteiro de desenvolvimento. Para times de engenharia, alguns sinais ajudam a mostrar se a velocidade conquistada está realmente virando entrega:

• lead time for changes;
• deployment frequency;
• change failure rate;
• failed deployment recovery time;
• tempo médio em review;
• tamanho dos PRs;
• taxa de retrabalho depois do review;
• volume de comentários repetitivos em PR.

Essas métricas ajudam a separar ganho real de uma simples sensação de velocidade. E acho essa diferença importante, porque a IA faz o processo parecer mais rápido muito cedo.

Você escreve mais rápido e coloca mais mudanças em revisão, mas isso ainda não quer dizer que o time está entregando melhor. O ganho só aparece de verdade quando o restante do fluxo acompanha e a mudança chega à produção sem trazer mais retrabalho, instabilidade ou custo depois.

O exemplo financeiro do relatório mostra como o ROI da IA se perde no fluxo

O relatório traz uma calculadora de ROI com números demonstrativos. Ela não deve ser copiada como benchmark, mas ajuda a entender a lógica.

No exemplo, uma organização com 500 pessoas técnicas estima um ganho líquido de 12,5% de tempo por desenvolvedor, algo próximo de uma hora por dia. Ao mesmo tempo, a conta considera uma queda inicial de produtividade de 15% por três meses, por causa da J-Curve.

Depois entra o custo da instabilidade. O exemplo aumenta os deployments de 50 para 56 por ano, mas também aumenta o change failure rate de 5% para 6%. Com downtime estimado em US$ 100 mil por hora e quatro horas de recuperação, essa instabilidade gera impacto negativo.

Mesmo assim, no cenário de exemplo, o relatório chega a US$ 11,6 milhões de valor anual, US$ 8,4 milhões de investimento no primeiro ano, benefício de US$ 3,3 milhões, ROI de 39% e payback de cerca de oito meses.

O número final chama atenção, mas eu olharia mais para a composição da conta. O ROI depende do tempo recuperado, só que também depende de quanto desse ganho é consumido por instabilidade, revisão pesada e retrabalho. É aí que muita adoção de IA parece boa no começo e decepciona depois.

Como trazer isso para o fluxo de PR

Para um time que já usa IA para escrever código, eu começaria por uma pergunta simples: em que parte do fluxo esse ganho de velocidade está se perdendo?

Eu começaria olhando para os PRs. Se eles ficaram maiores depois da adoção de IA, é bem provável que o custo da revisão também tenha aumentado. Mudanças grandes exigem mais contexto, cansam quem revisa e tornam os riscos mais difíceis de perceber.

Não por acaso, o relatório volta várias vezes à importância de trabalhar em lotes menores. PRs menores facilitam a revisão e ajudam o time a encontrar problemas antes que eles cheguem ao usuário.

Depois, eu olharia para o tipo de comentário que aparece nos reviews. Se boa parte deles ainda está presa em padrão, estilo, cenários sem cobertura, validações simples ou riscos já conhecidos, esse primeiro filtro pode ser automatizado.

Acho que quem está revisando deve usar esse tempo nas decisões que realmente exigem sua atenção: arquitetura, regra de negócio, segurança, impacto para o usuário e manutenção.

Também olharia para quanto tempo o PR fica parado esperando revisão. Esse é um dos pontos em que a velocidade trazida pela IA costuma se perder. O código foi escrito mais rápido, mas a mudança continua esperando alguém olhar. Para o negócio, ela ainda não aconteceu.

IA em code review precisa de contexto

O relatório também chama atenção para a importância de tornar os dados internos acessíveis para a IA.

Sem esse contexto, um review automatizado tende a comentar o óbvio ou gerar ruído. Para identificar riscos relevantes, a IA precisa entender os padrões do repositório, a arquitetura, as dependências, as regras do time e o histórico de decisões. Caso contrário, ela pode até aumentar o volume de comentários, mas sem melhorar a qualidade da revisão.

Os dados da nossa pesquisa sobre AI code review reforçam essa ideia.

Analisamos quase 10 mil regras criadas por times de engenharia e vimos que sugestões baseadas nesses padrões foram implementadas em uma proporção próxima à de sugestões de bugs.

Isso mostra que as regras específicas de cada time não são apenas um complemento do review. Quando a IA conhece esses padrões, ela consegue apontar problemas que realmente importam naquele contexto.

A pesquisa também mostrou que trocar apenas o modelo usado no review teve pouco impacto no resultado.

Ou seja, não basta escolher um LLM mais novo ou mais poderoso. A qualidade da revisão depende muito do contexto que o time consegue fornecer.

Por isso, eu não começaria pela escolha do modelo. Antes, tentaria entender o que o time realmente precisa encontrar nos reviews, onde o processo está perdendo tempo e quais decisões ainda exigem mais contexto de quem revisa:

• Quais problemas queremos detectar antes que o PR chegue a uma pessoa?
• Quais comentários aparecem de forma repetitiva nos reviews?
• Quais regras do time precisam estar explícitas?
• Onde a revisão trava por falta de contexto?
• Quais tipos de mudança deveriam receber mais atenção?

Quando essas respostas ficam claras, a IA deixa de ser apenas mais uma camada de comentários no PR e passa a ajudar de verdade no processo. Ela filtra parte do ruído, identifica riscos mais cedo e leva mais contexto para quem precisa tomar a decisão final.

O que medir depois da adoção de IA

Se eu fosse olhar esse relatório com um time de engenharia, não começaria pelo ROI financeiro direto. Eu começaria pelos sinais que aparecem antes dele.

Algumas perguntas já mostram bastante coisa:

• o tempo em review caiu ou subiu?
• o tamanho médio dos PRs aumentou?
• o change failure rate mudou?
• a recuperação de incidentes ficou mais lenta?
• o time está fazendo mais deploys com a mesma estabilidade?
• os revisores estão gastando menos tempo com comentários repetitivos?
• a IA está reduzindo retrabalho ou só empurrando retrabalho para depois?

Essas perguntas ajudam a entender se o time está apenas passando pela J-Curve ou se a IA criou um novo gargalo no processo. E, honestamente, é isso que separa uma mudança real na forma de trabalhar de uma simples compra de ferramenta.

O ponto para times de engenharia

O relatório DORA 2026 traduz o ROI para uma linguagem mais próxima da liderança, mas, para quem está em engenharia, o recado é simples: a IA só gera retorno quando o restante do fluxo consegue acompanhar.

O code review é uma das partes mais sensíveis desse processo. Se continua lento e manual demais, vira um gargalo para todo o código produzido com IA. Mas, quando tem contexto, regras claras e bons sinais de risco, ajuda a reduzir ruído, encontrar problemas mais cedo e deixar as decisões mais importantes para quem revisa.

Por isso, eu olharia menos para a ferramenta isolada e mais para o sistema ao redor: PRs menores, testes confiáveis, contexto técnico acessível, regras explícitas e métricas que acompanhem velocidade e estabilidade ao mesmo tempo.

Pra mim, essa é a principal mensagem do relatório: não basta escrever código mais rápido. O retorno da IA precisa aparecer em todo o ciclo de desenvolvimento, desde a abertura da mudança até a entrega em produção.