Pedir para a mesma IA que escreveu o código revisar o próprio código tem uma falha estrutural conhecida: ela tende a confirmar as premissas que já usou para escrever. A revisão adversarial resolve isso trocando quem audita.
O ponto cego da autorrevisão
É um problema bem documentado em engenharia de software, muito antes de qualquer IA existir: quem escreve um trecho de código carrega consigo o modelo mental que usou para escrevê-lo, e esse mesmo modelo mental tende a filtrar a releitura. Erros que decorrem de uma premissa errada raramente são pegos por quem fez a premissa — porque, para quem escreveu, aquilo nunca pareceu uma suposição, pareceu um fato.
Com modelos de linguagem o efeito se repete de um jeito específico: o mesmo modelo, na mesma sessão, tende a manter consistência com o que já gerou. Pedir “revise seu próprio código” tende a produzir uma confirmação educada, não uma investigação genuína.
O padrão de revisão adversarial
A alternativa que usamos internamente é simples de descrever e mais difícil de manter disciplinada: separar quem implementa de quem audita, e fazer o auditor operar com um objetivo diferente do implementador — não “ajudar a terminar”, mas “tentar provar que está errado”.
Hipótese não revelada como fato
Quem implementou não apresenta sua própria conclusão ao auditor como se fosse verdade estabelecida. O auditor investiga a partir da evidência bruta, forma sua própria leitura, e só depois as duas versões são comparadas.
Auditor somente leitura por padrão
Quem audita não deveria precisar de permissão de escrita para encontrar um problema. Investigação e remediação são papéis diferentes, e misturá-los cria pressão para “já corrigir” em vez de entender a causa raiz primeiro.
Severidade estruturada, não opinião solta
Cada achado é classificado numa escala objetiva (do bloqueador real ao ajuste cosmético), com evidência e cenário de falha concreto anexados — não uma lista de preferências de estilo disfarçada de revisão de segurança.
A palavra final continua sendo humana
Nem a implementação nem a auditoria decidem sozinhas o que é aceito, rejeitado como falso positivo, ou adiado para depois. Divergência entre as duas partes é reportada como tal, não resolvida silenciosamente por qualquer um dos lados.
Por que isso se parece com o Human Gate
Quem já leu sobre o Human Gate do IVE vai reconhecer a estrutura: uma ação proposta não vira ação executada sem passar por uma verificação independente, e o resultado dessa verificação fica registrado — o mesmo raciocínio por trás do Execution Receipt. A revisão adversarial de código é essa mesma lógica aplicada a uma etapa anterior no ciclo: antes de uma mudança chegar perto de produção, ela já passou por um portão de verificação com identidade própria, não pelo crivo de quem a propôs.
Este é o fluxo de trabalho que efetivamente usamos para mudanças não triviais no desenvolvimento assistido por IA nesta operação.
Isso não elimina a necessidade de revisão humana, não garante ausência de bugs, e tem um custo real de tempo e reprocessamento. O ganho é reduzir uma classe específica de erro — o viés de confirmação da autorrevisão — não eliminar todas as classes de erro possíveis.