Você Não Está Matando o Code Review. Está Renomeando Governança.

Ankit Jain, CEO da Aviator, publicou um artigo no Latent.Space com o título “How to Kill the Code Review.” A tese: revisão de código é obsoleta. Desenvolvedores não conseguem acompanhar o volume de código gerado por IA, então a solução é mover a supervisão para especificações, não para o código em si.

O diagnóstico está correto. A prescrição não se sustenta pelas próprias evidências que ele apresenta.

O Que Jain Propõe

Em vez de revisão humana, Jain sugere cinco camadas de verificação automatizada:

Agentes competidores. Múltiplos agentes geram soluções para a mesma especificação. Vence a que passa em mais testes.
Guardrails determinísticos. Linters, análise estática, regras codificadas. Controles que não dependem de julgamento.
Critérios de aceitação BDD. Testes escritos a partir de especificações comportamentais.
Escopo de permissões. Agentes operam com acesso mínimo. Cada agente só pode modificar o que lhe foi permitido.
Verificação adversarial. Agentes revisam o trabalho de outros agentes, buscando falhas e vulnerabilidades.

O modelo é sofisticado. Cada camada aborda um tipo diferente de risco. E nenhuma delas é code review.

Ou é?

Leia os Dados Que Ele Omitiu

Jain cita o relatório da Faros.ai (10 mil desenvolvedores, 1.255 equipes) para defender sua posição. Os números que ele destaca: +21% em conclusão de tarefas, +98% em PRs mesclados.

Os números que ele não menciona: +9% em bugs por desenvolvedor. +154% no tamanho médio do PR. E a descoberta principal do relatório, em letras claras na própria pesquisa: nenhuma correlação significativa entre adoção de IA e melhoria em nível organizacional.

Mais PRs não significa melhor software. Significa mais código para governar.

Os dados do LinearB confirmam isso por outro ângulo. Em 8,1 milhões de pull requests analisados, PRs gerados por IA têm taxa de aceitação de 32,7%. PRs manuais: 84,4%. Código de IA espera 4,6 vezes mais para ser revisado. Os revisores humanos já estão tratando código de IA com desconfiança. Eliminar essa camada de escrutínio não resolve a desconfiança. Apenas a esconde.

Como exploramos em A Dívida de Verificação da IA, o problema central é que 96% dos desenvolvedores não confiam em código gerado por IA, mas apenas 48% verificam de fato. Jain propõe remover o mecanismo de verificação mais visível sem resolver a causa da desconfiança.

O Paradoxo do Swiss Cheese

Jain cita o modelo Swiss Cheese de James Reason para justificar suas cinco camadas: empilhe defesas imperfeitas e a probabilidade de um defeito atravessar todas cai exponencialmente.

Depois, argumenta que devemos remover uma camada.

O modelo de Reason existe exatamente para o argumento oposto. Cada camada tem buracos. Quanto mais camadas independentes, menor a chance de alinhamento dos buracos. Remover uma camada aumenta a probabilidade combinada de falha. Isso não é interpretação minha. É o ponto central do framework.

Jain reconhece, em nota no artigo, que “não chegou lá ainda.” A honestidade é bem-vinda. Mas ela contradiz o título.

BDD Não É o Que Ele Pensa Que É

A terceira camada de Jain depende de BDD (Behavior-Driven Development) como garantia de correção. Se os critérios de aceitação passam, o código está correto.

A literatura acadêmica discorda. Um estudo publicado na ScienceDirect em 2021 conclui que evidência empírica da utilidade do BDD em projetos de larga escala é ausente. O artigo de Fowler e Bockeler sobre spec-driven development é ainda mais direto: especificações não substituem code review. Passar em testes de especificação não garante software correto.

Há uma razão para isso. 75% dos defeitos encontrados em code review afetam manutenibilidade e evoluibilidade, não funcionalidade. BDD testa comportamento. Não testa se o código é sustentável, legível, ou se cria dívida técnica para a próxima equipe. Os defeitos que code review captura são, em grande parte, invisíveis para testes automatizados.

Quando a IA Escreve os Testes Também

Simon Willison faz a pergunta que Jain não responde: como provar que o software funciona se tanto a implementação quanto os testes são escritos por agentes de IA?

Se o agente que gerou o código também gera os testes, há correlação estrutural entre os erros. O mesmo viés que produz um bug pode produzir um teste que não o captura. Verificação adversarial (camada 5) mitiga isso parcialmente, mas depende de agentes suficientemente diferentes para que seus erros sejam independentes. Essa independência é uma premissa, não uma garantia.

O estudo da METR adiciona contexto. Em um ensaio clínico randomizado com desenvolvedores experientes, o uso de IA resultou em produtividade 19% menor. Esses mesmos desenvolvedores acreditavam ser 24% mais rápidos. A percepção de velocidade não correspondeu à realidade. Se desenvolvedores humanos não conseguem avaliar corretamente a qualidade do que produzem com IA, transferir a avaliação inteiramente para agentes (que também usam IA) não resolve o problema de calibração.

A Veracode reportou que 40 a 48% do código gerado por IA contém vulnerabilidades de segurança. Jain responde a isso com “guardrails determinísticos” (camada 2). Mas guardrails determinísticos capturam vulnerabilidades conhecidas. Os 40-48% da Veracode incluem classes de vulnerabilidade que ferramentas estáticas não detectam consistentemente.

O Que Ele Realmente Construiu

Vamos listar o que o sistema de cinco camadas de Jain requer na prática:

Especificações formais antes de qualquer implementação
Múltiplos agentes com supervisão de resultados
Regras codificadas e limites de comportamento
Controle granular de permissões
Agentes auditando agentes
Critérios de aceitação verificáveis

Isso é um sistema de governança. Especificações são políticas. Permissões são controles de acesso. Verificação adversarial é auditoria. Guardrails são regras operacionais. BDD é o equivalente de compliance automatizado.

Jain não matou o code review. Ele decompôs revisão em componentes de governança, deu nomes novos, e declarou que revisão está morta. A função permanece. Alguém (ou algo) precisa validar que o código faz o que deveria, não introduz vulnerabilidades, é sustentável, e opera dentro de limites definidos.

Como já analisamos em Quando a IA Constrói a Si Mesma, a mesma pesquisa da Faros.ai que Jain cita demonstra que mais código de IA sem governança correspondente produz mais bugs, não menos. O volume aumenta. A qualidade não acompanha.

Siga o Dinheiro

Jain é CEO de uma empresa chamada Aviator, que levantou US$ 2,42 milhões e passou pela Y Combinator. Cada uma das cinco camadas que ele propõe mapeia para um produto ou funcionalidade da Aviator. A camada 3 é, literalmente, o Aviator Verify.

Isso não invalida o argumento. Mas contextualiza. Quando o CEO de uma empresa de ferramentas de desenvolvimento argumenta que o processo que sua ferramenta substitui está morto, o conflito de interesse é relevante.

O próprio editor do Latent.Space adiciona uma nota ao artigo: “I am not there yet.” Em tradução livre: não estou convencido.

O Que Falta no Argumento

Jain acerta no diagnóstico. Revisão humana, como praticada pela maioria das equipes, não escala para o volume de código gerado por IA. PRs de dois mil linhas. Revisores sobrecarregados. Tempo de espera triplicado.

Onde ele erra é na conclusão. De “revisão não escala” não decorre “elimine revisão.” Decorre “evolua revisão.” O artigo sobre O Paradoxo dos Benchmarks já demonstra como ferramentas de AI code review falham precisamente onde prometem ajudar. E a análise do BugBot do Cursor mostra que abordagens em camadas funcionam quando complementam revisão humana, não quando a substituem.

O que está faltando no sistema de Jain é o reconhecimento de que suas cinco camadas são governança e devem ser tratadas como tal. Com tudo o que isso implica: responsabilidade, auditabilidade, supervisão humana nos pontos de decisão crítica, e atualização contínua conforme os riscos mudam.

O Que Isso Significa Para Equipes de Engenharia

Se você lidera uma equipe que está sob pressão para “mover mais rápido com IA,” três pontos são relevantes:

Code review não é o gargalo. Governança ausente é. O problema não é que revisores são lentos. É que não há estrutura para lidar com o volume e o tipo de código que agentes produzem. Resolver isso eliminando revisão é como resolver congestionamento removendo semáforos.

Decompor revisão em camadas é uma boa ideia. Eliminar o humano do loop não é. As cinco camadas de Jain são úteis como componentes de um sistema de governança. Cada uma captura um tipo de defeito diferente. Mas humanos precisam estar nos pontos de decisão (não em todo PR, mas onde o risco justifica). O objetivo é revisão proporcional ao risco, não revisão zero.

Cuidado com a renomeação. Se sua organização adota “spec review” em vez de “code review,” certifique-se de que a função de governança sobreviveu à mudança de nome. Especificações são revisadas por quem? Com que frequência? Com que autoridade para bloquear? Se a resposta é “agentes de IA,” você transferiu governança para os governados. Isso tem um nome na teoria de controle: perda de independência do auditor.

O debate sobre code review na era da IA é legítimo e necessário. Mas ele precisa partir de premissas honestas. Revisão não morreu. Ela precisa evoluir. E a primeira condição para essa evolução é reconhecer que o que estamos construindo, independentemente do nome, é governança.

Fontes

Ankit Jain. “How to Kill the Code Review.” Latent.Space, março 2026.
Faros.ai. “AI Software Engineering Productivity Paradox Report.” 2025.
LinearB. “2026 Software Engineering Benchmarks Report.” 2026.
METR. “Measuring AI’s Impact on Experienced Open-Source Developer Productivity.” 2025.
Martin Fowler / Birgitta Bockeler. “Spec-Driven Development Tools.” 2026.

Victorino Group ajuda organizações de engenharia a construir sistemas de IA que podem realmente governar: contato@victorino.com.br | www.victorino.com.br