A IA pode revisar o código que ela mesma escreveu?

Pedir pra mesma IA revisar o código que ela acabou de escrever é meio como pedir pro autor da prova corrigir a própria prova

E ela quase sempre passa 🙂

Só que isso não é achismo de internet, beleza? Tem pesquisa medindo exatamente esse cenário (agente avaliando ação que ele mesmo gerou) e tem recomendação oficial na documentação do Claude Code dizendo pra usar contexto novo na revisão

Então a pergunta "a IA pode revisar o próprio código?" não é opinião, é decisão de fluxo de trabalho

O recorte deste post é esse: quando a auto revisão serve, quando ela falha feio e como escolher quem revisa (mesma sessão, contexto novo, outro modelo, humano)

Por que a IA aprova o próprio código: os vieses que aparecem

O sintoma tu já viu: pede revisão, o modelo lê o que ele mesmo escreveu e volta com "a implementação está correta e segue boas práticas"

Um elogio educado pro próprio trabalho

Tem três causas documentadas por trás disso, e vale separar uma da outra

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

1. Viés de auto-preferência (LLM como juiz)

Existe viés de auto-preferência documentado em LLM usado como juiz: o modelo tende a avaliar melhor a própria saída do que avaliadores humanos avaliariam

E se liga no detalhe mais interessante: a intensidade do viés se correlaciona com a familiaridade do texto (perplexidade mais baixa), não com o julgamento humano

Traduzindo: o texto "soa certo" pro modelo porque ele mesmo produziria aquilo, não porque foi conferido

O GPT-4 apresentou grau significativo de auto-preferência nesse trabalho, mais forte que o de outros modelos testados, com a causa associada à menor perplexidade das próprias saídas

2. Auto-preferência nociva: pior justo quando ele erra

Um estudo com benchmarks verificáveis (raciocínio matemático, conhecimento factual e geração de código) separa duas coisas que costumam ser jogadas no mesmo balde

Auto-preferência legítima é preferir a própria resposta quando ela é objetivamente melhor (isso é ok!)

Auto-preferência nociva é preferir a própria resposta quando ela é objetivamente pior

E a nociva persiste justamente quando o avaliador erra no papel de gerador

Pior: modelos mais fortes exibem auto-preferência nociva mais pronunciada quando erram, o que indica dificuldade maior em reconhecer o próprio erro

Ou seja, o cenário em que tu MAIS precisa da revisão é o cenário em que ela mais falha

3. Viés de auto-atribuição: o gatilho é o turno, não a autoria

Esse aqui é o mais próximo do nosso dia a dia de agente

Uma pesquisa sobre viés de auto-atribuição mede o mesmo trecho em duas condições: avaliado logo depois de um turno do assistente em que ele mesmo gerou a ação, versus o mesmo trecho apresentado em contexto novo, num turno de usuário

Em quatro conjuntos de dados de código e uso de ferramentas, os monitores deixam de reportar ações de alto risco ou de baixa correção com mais frequência quando a avaliação segue o turno em que a ação foi gerada

E o achado que quebra a intuição: declarar explicitamente que a ação veio do mesmo modelo, por si só, não induz o viés

Não é a assinatura no código que enviesa

É dividir a mesma janela de contexto com quem escreveu

Como prevenir (o que a própria pesquisa aponta)

• Contexto novo: tirar o revisor do turno em que a ação nasceu
• Cadeia de raciocínio longa antes do veredito: o mesmo estudo dos benchmarks verificáveis aponta essa mitigação por escala em tempo de inferência, mais tokens de raciocínio levam o avaliador a reconsiderar criticamente o julgamento inicial e aumentam a acurácia do veredito
• Desconfiar de benchmark de monitor em exemplo fixo: os autores dessa pesquisa sobre viés de auto-atribuição (Dipika Khullar, Jack Hopkins, Rowan Wang e Fabien Roger) alertam que avaliar monitores em exemplos fixos superestima a confiabilidade deles em produção, porque no uso real o monitor julga ações que ele próprio gerou

O risco prático disso é colocar em produção monitores inadequados achando que são confiáveis

Tome cuidado com isso se tu montou um "agente auditor" e testou ele só com casos preparados na mão

Mesma sessão, contexto novo, outro modelo ou humano: o que muda em cada arranjo

A tabela abaixo compara o DESENHO de cada arranjo: quanta independência o revisor tem e o que ele consegue enxergar

Detalhando os arranjos que dependem de configuração:

Subagentes do Claude Code rodam em janela de contexto própria e são definidos como arquivos markdown com frontmatter YAML

Cada um tem system prompt próprio, acesso a ferramentas e permissões independentes, em nível de projeto (.claude/agents/.md) ou de usuário (~/.claude/agents/.md)

O comando /security-review analisa as mudanças pendentes na branch em busca de vulnerabilidades, cobrindo padrões como injeção de SQL, XSS, falhas de autenticação e autorização, tratamento inseguro de dados e vulnerabilidades de dependência

Pro pull request, a Anthropic mantém o repositório claude-code-security-review, com GitHub Action que analisa automaticamente os PRs

E dá pra trocar de fabricante inteiro: a Action do Gemini CLI (repositório google-github-actions/run-gemini-cli), mantida pelo Google, tem workflow de PR review acionado na abertura do PR ou por comentário com @gemini-cli /review, aceitando foco extra no pedido (por exemplo, @gemini-cli /review focus on security)

Quando trocar de contexto basta e quando vale trocar de modelo ou de ferramenta

Agora a parte de decisão

A régua não é "qual IA é melhor revisora", é "quanta independência esse pedaço de código exige"

Mudança pequena que a própria sessão escreveu: contexto novo já resolve

Ajuste de função, refactor localizado, correção de bug que tu acompanhou nascer

Aqui o problema é o turno, não o modelo

A documentação do Claude Code recomenda contexto novo justamente pra isso: assim o Claude não fica enviesado a favor do código que acabou de escrever

Abrir sessão nova (ou mandar pra um subagente revisor) já tira a maior parte do vício, e o passo a passo de revisar o código antes de commitar encaixa direto nesse cenário

Superfície sensível: comando dedicado

Autenticação, autorização, entrada de usuário, dependência nova

Aqui não dá pra depender de "olhada geral"

Usa o /security-review, que já vem mirado nos padrões clássicos (injeção de SQL, XSS, falhas de autenticação e autorização, tratamento inseguro de dados, vulnerabilidade de dependência)

E se a tua stack tem manias próprias, dá pra customizar: copia o arquivo security-review.md do repositório da Anthropic pra pasta .claude/commands/ do teu projeto e edita a análise

Fluxo de PR em equipe: Action no pull request

Quando tem mais gente no repo, revisão que depende de alguém lembrar de rodar um comando não acontece

Plugar a Action no PR resolve por construção, seja a do repositório de security review, seja a do Gemini CLI se tu quiser um segundo par de olhos de outro fabricante

Decisão arquitetural e código que vira base pro futuro: humano no portão

Esse é o caso mais traiçoeiro, e tem estudo bem específico sobre ele

Um trabalho de Xinyuan Song, Zekun Cai e Liang Zhao (Emory University, The University of Tokyo, LocationMind) comparou três regimes de aprovação num ciclo de retreino com código gerado por IA: sem revisão, com portão humano e com portão de auto revisão por IA

Sem revisão é a degradação mais acentuada (previsível, né?)

O portão humano preserva sinais úteis de validade, mas não barra a deriva semântica de longo prazo

E o portão de auto revisão por IA aparenta bom desempenho nas métricas iniciais enquanto o próprio sinal de aceitação deriva

Esse é o ponto que dói: o painel fica verde enquanto o critério de "verde" está se mexendo embaixo do pano

O que vale mais que escolher o revisor

Dois padrões da documentação do Claude Code fecham essa seção

O primeiro separa os papéis entre duas instâncias: um Claude escreve os testes, outro escreve o código que os faz passar

O segundo, e é apontado como a prática de MAIOR impacto: verificação, ou seja, dar ao Claude um jeito de conferir a própria saída

E repara na diferença, porque ela é o post inteiro: verificação aqui é ferramenta (teste que roda, tipo que compila, lint, execução real), não é o modelo dando nota pro próprio trabalho

Autojulgamento de qualidade é opinião, e é justo aí que o viés mora

Com verificação objetiva por trás, vira evidência

Veredito: auto revisão é camada, não substituta

Deixar a IA revisar o próprio código vale a pena em duas condições: o revisor tem contexto próprio e existe verificação objetiva por trás dele

Fora disso, não use como único portão de aceitação

A pesquisa é bem consistente nesse ponto: o viés não some porque tu pediu com educação, ele some quando o arranjo muda

Um desenho maduro que dá pra olhar como referência é o relato de engenharia da Wealthfront

Eles adotaram uma revisão antagonística e mantêm revisão humana e revisão de IA como camadas aditivas, separadas no tempo pra preservar a independência do revisor humano

Repara na sacada: separar no tempo pra que a pessoa não seja ancorada pelo que a IA já disse

O resultado da abordagem antagonística foi leve aumento nos verdadeiros positivos e queda bem grande nos falsos positivos, a ponto de a maioria dos pull requests passar a receber nenhum comentário e poucos receberem mais de um

Revisão que fala pouco e acerta é MUITO melhor que revisão que comenta tudo

E pra quem isso não compensa? Pra quem só quer carimbo rápido no próprio código

Se o objetivo é ouvir "tá ótimo", a mesma sessão entrega isso de graça, só que sem valor nenhum

Conclusão

A regra de bolso cabe numa frase: autor e revisor não podem dividir a mesma janela de contexto

O resto é escolher o nível de esforço que o teu código pede

1. Sessão nova pra revisar o último trabalho: custo zero, resolve o pedaço mais grosseiro do viés
2. Subagente revisor no projeto: arquivo markdown com frontmatter YAML em .claude/agents/, com system prompt, ferramentas e permissões próprias, pra revisão virar rotina e não lembrança
3. Revisão plugada no pull request: GitHub Action, com o comando de segurança dedicado nas superfícies sensíveis e, se tu quiser, um revisor de outro modelo em paralelo

Antes de brigar sobre qual modelo revisa melhor, faz o teste no TEU repositório: pega o último commit gerado com IA, roda a revisão na mesma sessão, depois roda em contexto novo e compara o que cada uma aponta

A diferença entre os dois costuma decidir a discussão sozinha 😀

até o próximo post!