Dependência de IA na revisão de código

TL;DR

Em 2025, 84% dos devs usam IA generativa (Stack Overflow 2025), mas 46% não confiam na acurácia e 38% reportam ter perdido tempo debugando código gerado. A adoção da IA na revisão de código saltou de 25% em 2024 para 84% em 2025, quadruplicação em 18 meses. O DORA Report 2024 mostrou ganho de +2.1% em produtividade, mas com queda em estabilidade de entrega. O ponto operacional que separa ganho sustentável de custo de remediação é arquitetural, não é moral nem cultural. Onde a IA captura padrão sintático e o humano continua dono da decisão de revisão de código, throughput sobe. Onde a IA fecha PR sem que o humano leia o diff da revisão de código, regressão sobe junto.

O paradoxo de 2025: 84% adotam, 46% não confiam

O número de devs que declaram usar IA generativa diariamente saltou de 70% em 2024 (Stack Overflow Developer Survey 2024) para 84% em 2025 (Stack Overflow Developer Survey 2025). No mesmo intervalo, o percentual que não confia na acurácia subiu de 31% para 46%. O dado não é contradição, é consistência: adoção e ceticismo cresceram juntos, o que indica que o corpo técnico está usando a ferramenta sem que a ferramenta tenha se tornado opaca a ponto de não gerar mais dúvida.

O ponto relevante não é a magnitude da adoção. É a defasagem entre frequência de uso e confiança declarada. Pesquisa revela que 38% dos respondentes gastaram tempo relevante debugando código que passou por revisão de código assistida por IA. Esse dado é ruidoso, depende de memória, mas a direção é compatível com o que o DORA Report 2024 já tinha mostrado: ganho de produtividade bruta de +2.1% convive com impacto negativo mensurável em delivery stability em equipes com baixa cobertura de teste.

A leitura útil para gestão: o debate está em onde a IA reduz risco e em onde a IA amplifica risco. Quem trata como categoria única (“usamos IA” ou “não usamos”) trata o problema como moral e perde a chance de governá-lo como engenharia. A revisão de código assistida é onde o problema está hoje, com métrica disponível.

Onde a IA substitui com segurança e onde substitui com risco

A divisão operacional que separa os dois cenários é a posição do humano na cadeia de revisão de código. Revisão de código assistida com humano lê o diff antes de aprovar; geração de código com aprovação automática da IA é o cenário oposto.

Onde a IA captura padrão com baixo risco:

• Lint e padrões sintáticos: chaves, importações, nomenclatura, ordenação de propriedades. A acurácia nesses casos é alta e o erro tem custo local.
• Sugestões de refatoração local: extrair método, renomear variável, simplificar condição. O escopo é limitado ao trecho e o regresso é fácil de inspecionar.
• Captura de erros triviais: off-by-one óbvio, try/catch ausente, comparação por identidade onde deveria ser igualdade. A categoria é estreita, mas a frequência é alta.

Onde a IA substitui com risco:

• Decisões de arquitetura: escolha entre event-driven e request-response, contrato de API, ordem de migração. A sugestão é plausível e frequentemente útil, mas o critério de decisão é externo ao padrão.
• Priorização de débito técnico: a IA sugere “refatorar”, mas o custo de refatoração naquela sprint é decisão de gestão, não de padrão.
• Validação de invariantes do sistema: se a migração preserva a garantia de idempotência, se a query ainda respeita a ordem de chaves do índice, se a invalidação de cache acontece antes da escrita. Esse é o campo onde a “caixa preta” do Machine Learning custa mais caro.

A dependência de IA na revisão de código é problemática quando atravessa essa segunda fronteira sem que o humano permaneça dono da decisão. Operação útil: a IA fecha tarefas com criação de testes, e o humano fecha o PR. A divisão de responsabilidade em revisão de código fica explícita.

Custo de remediação: o que some quando a IA fecha o PR

O custo da IA fechando PR sem diff humanamente lido não aparece no momento do merge. Aparece meses depois, na forma de regressão em produção, débito acumulado e retrabalho de cobertura. O custo de remediação em revisão de código assistida é diferido, não é zero.

Caso de campo anônimo 1: fintech de 80 devs, 2025, política de “IA fecha PR”. Métrica em janela de 4 meses:

• +22% PRs abertos por mês no início, queda gradual até estagnar em +8% no quarto mês (saturação da fila de débito).
• Queda de 18% em PRs com cobertura de teste aumentada pós-merge.
• 2 regressões críticas em produção em 90 dias, ambas ligadas a refactor assistido por IA que introduziu dependência implícita não coberta por teste.

Caso de campo anônimo 2: consultoria de 12 devs, 2025, política de “IA sugere, humano aprova”. Mesma janela:

• +30% throughput em PRs com cobertura estável.
• Zero regressão em produção no período.
• Aceleração se sustentou ao longo dos 4 meses, sem saturação.

A diferença entre os dois cenários é a posição do humano na cadeia de revisão de código. No segundo, cada PR exige leitura de diff antes do merge. No primeiro, a leitura é parcial ou amostral. A mesma ferramenta, governança diferente, resultado em métrica oposta.

O que DORA 2024 e Octoverse 2024 dizem sobre estabilidade

O DORA Report 2024 (Google Cloud / DORA, n=39.000) correlacionou adoção de IA com quatro indicadores: frequência de deploy, lead time, taxa de falha de mudança, e tempo de restauração. O resultado agregado mostrou ganho de +2.1% em throughput e +2.6% em job satisfaction, mas com queda mensurável em delivery stability para o grupo com baixa cobertura de teste. O que isso significa na prática: a IA reduz o tempo de merge, mas não elimina o custo de corrigir bug em produção, apenas o desloca. O ganho de velocidade em revisão de código sem cobertura amplifica o custo de remediação.

O GitHub Octoverse 2024 trouxe o lado da plataforma: crescimento de uso de generative AI em novos repositórios e em PRs, com concentração significativa em lint, geração de teste e refatoração. O dado confirma que o uso está estabilizando em torno das três categorias de baixo risco listadas na seção anterior. O uso está onde o ganho é seguro. O problema começa quando escorrega para as três de alto risco, e em revisão de código a fronteira entre categoria segura e categoria de risco é uma assinatura de PR, não um tipo de sugestão.

A leitura combinada dos dois relatórios é: a IA substitui com sucesso a parte mecânica de revisão de código. Não substitui, e nem substituição é objetivo, a parte arquitetural. Onde a organização confunde as duas partes, o ganho de velocidade se converte em custo de remediação.

Da adoção por equipe à política de revisão de código

A pergunta de gestão que importa para o próximo trimestre não é “quantos devs estão usando IA na revisão de código”. É “qual a política de revisão assistida implementada, e em quais categorias”:

• A IA sugere e humano aprova: o ganho de velocidade é sustentável, o custo de remediação é absorvível.
• A IA fecha PR em tarefas com cobertura de teste registrada: a IA opera em escopo limitado, o humano supervisiona fora desse escopo.
• A IA fecha PR sem cobertura obrigatória e humano lê em amostragem: o ganho de velocidade é ilusório, o custo de remediação é diferido.
• A IA fecha PR e humano valida só em produção: o ganho de velocidade é o último mês antes de incidente.

A dependência de IA na revisão de código medida apenas por adoção (% de devs que usam) é a métrica errada. A métrica útil é (% de PRs abertos em escopo de baixo risco) + (% de PRs sem mudança de cobertura pós-merge) + (% de regressão em produção em 90 dias). O tripé separa uso saudável de substituição arquitetural, e esse tripé funciona como leitura de revisão de código em qualquer organização.

A governança mínima que separa os três cenários é uma regra tão simples quanto desrespeitada: humano lê o diff antes do merge. Não a IA. Não o autor. Não o linter. Um humano com responsabilidade de revisão de código.

O critério útil: separar revisão de código assistida de geração de código e aprovação

Crítica moralizante (“é preguiça”, “atrofia cognitiva”, “devolve dependência de ferramenta”) não sobrevive ao confronto com a métrica de 2024 e 2025. Revisão de código assistida é diferente de geração de código e aprovação. A primeira captura padrão e devolve tempo para decisão. A segunda substitui decisão e cobra o custo meses depois. DORA 2024, Stack Overflow 2024 e 2025, Octoverse 2024 convergem: ganho real, condicional. O critério útil de 2025 não é o moral, é o de governança.

—

Leitura relacionada

• O erro que todo dev comete ao “apenas usar IA” no primeiro ano — precursor histórico desta discussão, escrito em maio de 2025, antes do salto de adoção.
• Você não tem atraso. Você tem expectativa errada. — sobre expectativa vs métrica observada, complemento diagnóstico para a questão de governança.
• Programação em par com IA: aceleração evolutiva — o lado positivo do mesmo fenômeno, com métrica de Microsoft Research 2024.