# Code Review Não Morreu. Está Virando Governança. > Por que camadas de revisão sobrevivem à velocidade da IA. O que dados de 10 mil desenvolvedores e o achado de 75% de evoluibilidade revelam. Releezy Team · 2026-03-04 [Ler no site](https://releezy.com/pt/blog/code-review-is-not-dead) Existe um argumento cada vez mais popular no mundo da engenharia: code review morreu. O raciocínio é este: agentes de IA geram código mais rápido do que revisores humanos conseguem acompanhar, então a solução é mover a supervisão para especificações e substituir o julgamento humano por camadas de verificação automatizada. Um ensaio bastante lido no Latent.Space defendeu exatamente essa tese em março de 2026, propondo cinco camadas: agentes competidores, guardrails determinísticos, critérios de aceitação BDD, escopo de permissões e verificação adversarial. O diagnóstico está correto. O problema de volume é real e não vai desaparecer. Mas a prescrição não se sustenta pelas próprias evidências, e o enquadramento importa mais do que parece. O que essa corrente descreve como matar o code review é, na prática, reconstruir governança com outro vocabulário. ## O Paradoxo do Swiss Cheese O argumento pela morte da revisão costuma citar o modelo Swiss Cheese de James Reason, e o instinto é bom. O modelo de Reason é uma das ideias mais duradouras da engenharia de segurança. A percepção central: nenhuma camada de defesa é perfeita. Toda camada tem buracos. A segurança vem de empilhar camadas imperfeitas para que os buracos nunca se alinhem. E então o argumento pede que a gente remova uma camada. As cinco camadas automatizadas são apresentadas como superiores à revisão humana. Mas o modelo de Reason não diz "substitua camadas fracas por camadas melhores." Ele diz "adicione mais camadas, porque você não consegue prever onde qualquer camada isolada vai falhar." Toda a fundação intelectual do modelo Swiss Cheese argumenta contra reduzir o número de superfícies de verificação. Isso não é uma inconsistência menor. É uma tese contradizendo o próprio framework. ## Leia o Conjunto Completo de Dados A evidência mais forte citada a favor de matar a revisão vem de um estudo da Faros.ai com mais de 10 mil desenvolvedores em 1.255 equipes de engenharia. Os números de produtividade impressionam: +21% em conclusão de tarefas e +98% em PRs mesclados com alta adoção de IA. O mesmo relatório também encontrou +9% em bugs por desenvolvedor e +154% no tamanho médio do PR. E a descoberta principal aponta na direção oposta: nenhuma correlação significativa entre nível de adoção de IA e melhoria de desempenho em nível organizacional. Mais uso de IA não se traduziu em resultados melhores para a empresa. Mais PRs não significou melhor software. Significou mais código para governar. Os benchmarks do LinearB contam a mesma história por outro ângulo. Em 8,1 milhões de pull requests analisados, PRs gerados por IA tiveram taxa de aceitação de 32,7%, contra 84,4% dos PRs manuais, e código de IA esperou 4,6 vezes mais para ser revisado. Os revisores humanos já tratam código de IA com cautela. Remover a camada de escrutínio não resolve essa falta de confiança. Apenas a esconde. ## O Que Code Review Realmente Faz A defesa da morte da revisão se apoia em uma definição estreita do que a revisão realiza: encontrar bugs. Se ferramentas automatizadas encontram bugs melhor, e em muitas categorias encontram, a revisão humana parece redundante. Isso ignora a maior parte do quadro. Um estudo da Springer de 2024 sobre práticas de code review descobriu que três quartos dos defeitos identificados em revisão afetam evoluibilidade e manutenibilidade, não funcionalidade. Coerência de design. Convenções de nomenclatura. Consistência arquitetural. Acoplamento entre módulos. Acúmulo de dívida técnica. São essas as preocupações que determinam se uma base de código continua trabalhável em seis meses ou vira um sistema que ninguém quer tocar. Nenhuma das cinco camadas automatizadas endereça evoluibilidade. Agentes competidores verificam correção funcional. Guardrails determinísticos aplicam regras. Testes BDD confirmam comportamento. Escopo de permissões limita o raio de dano. Verificação adversarial sonda casos extremos. Todas miram "funciona agora?" Nenhuma pergunta "essa base de código ainda será compreensível daqui a um ano?" A revisão também cumpre funções que não têm nada a ver com detecção de defeitos: transferência de conhecimento na equipe, mentoria de engenheiros juniores, construção de entendimento compartilhado da arquitetura, estabelecimento de normas de código. São funções organizacionais. Nenhuma camada automatizada as substitui. ## Quando a IA Escreve os Testes Também A camada de BDD merece um olhar mais atento, porque o argumento se apoia bastante nela: defina especificações de comportamento antes, depois verifique o código gerado contra essas especificações automaticamente. Há dois problemas. Primeiro, a pesquisa acadêmica sobre BDD em escala é escassa. Uma revisão publicada na ScienceDirect em 2021 concluiu que evidência empírica da utilidade do BDD em projetos de larga escala é ausente. BDD funciona bem para comportamentos bem definidos e delimitados. Sistemas corporativos cheios de interações de estado complexas e preocupações transversais são um desafio diferente. Segundo, e mais fundamental: quando a IA gera tanto a implementação quanto os testes, especificações aprovadas não garantem software correto. Simon Willison levantou exatamente essa preocupação. Se o mesmo modelo produz o código e a verificação, existem modos de falha correlacionados. Um viés sistemático do modelo produz código errado exatamente da forma que os testes do modelo esperam. O problema de calibração é mais profundo que ferramenta. O ensaio clínico randomizado da METR com desenvolvedores experientes de código aberto descobriu que o uso de IA os deixou 19% mais lentos, enquanto esses mesmos desenvolvedores acreditavam estar 24% mais rápidos. Se humanos não conseguem avaliar corretamente a qualidade do que produzem com IA, transferir a avaliação inteiramente para agentes de IA não resolve o problema de calibração. Remove o último observador independente. ## O Que Funciona de Verdade O problema de volume merece uma resposta real, e "revisar tudo do jeito antigo" não é essa resposta. A resposta é revisão governada: triagem baseada em risco que direciona a atenção humana para onde ela mais importa. **Pré-triagem automatizada.** Deixe as ferramentas automatizadas cuidarem das categorias em que são boas: consistência de estilo, padrões conhecidos de vulnerabilidade, cobertura de testes, segurança de tipos. Essa camada funciona, e toda equipe deveria tê-la. **Roteamento por risco.** Nem toda mudança carrega o mesmo risco. Um ajuste de CSS e uma mudança em processamento de pagamentos não deveriam passar pelo mesmo processo de revisão. Código sensível a segurança, lógica de manipulação de dados e mudanças arquiteturais recebem revisão humana completa. Mudanças de baixo risco recebem verificação automatizada com amostragem de conferência. **Revisão de arquitetura, não de linha.** Revisores humanos deveriam gastar menos tempo em linhas individuais e mais tempo em decisões de design, fronteiras de sistema e padrões de integração. É aí que o julgamento humano permanece insubstituível, e é aí que vivem os 75% de valor em evoluibilidade. **Independência de verificação.** Quando a IA gera código, a camada de verificação precisa ser genuinamente independente: revisores humanos, modelos separados ou propriedades formalmente especificadas. Nunca o mesmo sistema conferindo o próprio trabalho. Essa abordagem não mata nada. Ela aloca a atenção humana com eficiência dentro de um framework governado. O processo de revisão muda de forma. Ele não desaparece. ## O Nome Importa Dá para argumentar que isso tudo é semântica. Chame de spec review, chame de camadas de verificação, o processo antigo evolui de qualquer jeito. Mas o nome importa. Quando organizações de engenharia ouvem "code review morreu," algumas vão entender "não precisamos de supervisão." Vão cortar investimento em revisão. Vão pular a revisão arquitetural porque o agente passou nos próprios testes. Vão entregar mais rápido, e o dano ficará invisível até a base de código se tornar insustentável e o conhecimento institucional ter evaporado. Os dados da Faros.ai já mostram esse padrão se formando: mais código, mais PRs, mais bugs, revisões mais longas e nenhuma melhoria em nível de empresa. É assim que matar a revisão se parece na prática. Code review não está morrendo. Está virando governança, e merece ser tratado como tal: com responsabilidade clara, julgamento humano nos pontos de maior risco e medição honesta de cada camada, humana ou de IA, contra a mesma régua. As equipes que continuam investindo na camada de revisão, e continuam medindo essa camada, são as que conseguem acelerar com confiança em vez de esperança. Se você tem curiosidade sobre a eficácia real da sua camada de revisão hoje, para revisores humanos e de IA, [descubra o que uma métrica de eficácia de code review pode mostrar](/pt/code-review-effectiveness).