Um agente de IA pode revisar o código de outro agente de IA?

Resposta curta: pode, e ele acha defeito de verdade, mas a condição que faz aquilo funcionar não é a marca do modelo. São outras três coisas: o agente revisor precisa rodar em uma instância separada, sem nenhum contexto de quem escreveu, precisa ser mandado caçar defeito novo em vez de confirmar que os antigos sumiram, e uma pessoa continua dona do merge. Na nossa própria pipeline de conteúdo, entre 12 e 14 de agosto de 2026, seis artigos técnicos passaram por um agente revisor de contexto zerado e os seis foram reprovados ao menos uma vez antes de passar, ao longo de 14 rodadas de revisão. Esse é o nosso número para revisão de artigo que carrega comando executável, não para pull request contra código de produção, e a diferença importa.

Por que o teste que o agente de IA escreveu passa no comportamento errado?

Porque o mesmo agente que escreveu o código escreveu o teste, e teste escrito depois da implementação tende a afirmar o que a implementação já faz. Ele fica verde no comportamento errado, e só fica vermelho no dia em que você tenta consertar o defeito. Este é o menor exemplo honesto que a gente conseguiu montar, uma allowlist de caminhos do tipo que um agente de IA de programação precisa quando você diz em quais diretórios ele pode mexer:

def is_allowed(path, allowed_root):
    """Return True when path is inside allowed_root."""
    return path.startswith(allowed_root)

E o teste que veio junto, na biblioteca padrão do Python, então não há nada para instalar:

import unittest
from allowlist import is_allowed

ROOT = "/home/dev/project"

class TestAllowlist(unittest.TestCase):
    def test_file_inside_the_project_is_allowed(self):
        self.assertTrue(is_allowed(ROOT + "/src/main.py", ROOT))

    def test_nested_file_is_allowed(self):
        self.assertTrue(is_allowed(ROOT + "/src/deep/util.py", ROOT))

    def test_unrelated_path_is_rejected(self):
        self.assertFalse(is_allowed("/etc/passwd", ROOT))

Rode com python3 -m unittest -v e ele imprime, no Python 3.14.3, com o tempo decorrido dependendo da sua máquina:

Ran 3 tests in 0.000s

OK

Três testes passando, e a função está quebrada. Duas perguntas que o teste nunca faz:

/home/dev/project-secrets/.env   -> True
/home/dev/project/../other/.env  -> True

Um diretório vizinho, cujo nome apenas começa com a mesma string, está dentro da allowlist, e também está tudo que se alcança saindo por ... A suíte verde não é evidência. Ela é a opinião do autor, repetida por uma máquina.

O agente de IA revisor precisa ser de outra empresa?

A gente dizia que sim, e está estreitando essa afirmação. O nosso artigo anterior sobre como revisar código escrito por vários agentes de IA diz que vale um agente revisar outro com uma condição, ser de outra empresa. O que a gente consegue defender de fato é mais fraco e mais útil: o que a gente observou é o efeito de uma instância separada, com contexto limpo e instrução adversarial. A gente nunca rodou a comparação controlada que isolaria a marca, mesmo modelo com contexto limpo contra outro modelo com contexto limpo, então não dá para dizer quanto do benefício pertence à diferença de fornecedor.

O mercado está discutindo exatamente isso. Na thread Reviewing AI code has quietly made me the slowest part of my own team, publicada no r/cursor em 11 de agosto de 2026 (post 1vllfe1, 25 comentários declarados, 20 com corpo na página que lemos), um comentarista descreve a falha com todas as letras, que o mesmo modelo escrevendo código e teste produz um teste que afirma o que o código já faz, e outro responde que o fornecedor é irrelevante porque modelo não tem ego, e o que importa é instância separada, sem contaminação de contexto, rodando sob instrução ajustada para ser adversarial. As duas posições se sustentam, e nenhum dos dois lados daquela thread rodou teste controlado. Trate a questão do fornecedor como aberta.

O que faz um segundo agente de IA discordar de verdade do primeiro?

Três coisas, na ordem que importa. A primeira é o contexto. Um agente que tem a conversa do autor na janela herda as suposições do autor, inclusive a suposição errada que produziu o defeito. Uma instância nova, que recebe só o diff e o requisito, não tem lealdade a nada, e é isso que o exercício inteiro procura.

A segunda é a instrução. Pedir para um agente conferir se o código está certo produz concordância, porque código fluente se lê como certo. Pedir para ele achar uma classe específica de defeito produz achado. A instrução que a gente usa nomeia as classes: algo que a mudança tocou e não deveria, um teste que continuaria passando se a implementação estivesse errada, e uma suposição feita sem ser dita.

A terceira é o que você manda ele fazer na segunda rodada, e é a que mais gente erra. Depois de uma correção, a instrução natural é confirmar que os defeitos relatados sumiram. Essa instrução é quase inútil, porque ela aponta o revisor justamente para a parte do código que acabou de receber toda a atenção. Mandar o revisor procurar um defeito novo foi o que pegou, na nossa própria pipeline, três rodadas seguidas em que a correção é que introduziu o problema seguinte.

O que um agente de IA revisor pega de fato, medido na nossa pipeline?

A nossa pipeline de conteúdo publica artigos técnicos que contêm comandos, e todo artigo passa por um agente revisor que não escreveu o texto, roda com contexto vazio e é instruído a rodar os comandos publicados em vez de acreditar neles. Contando as últimas 100 entradas do nosso diário de automação, uma janela que cobre os dois dias até 14 de agosto de 2026, seis artigos chegaram naquele portão. Eles consumiram 14 rodadas de revisão: 8 reprovações e 6 aprovações. Cada um dos seis foi reprovado pelo menos uma vez, e um deles precisou de quatro rodadas.

Os defeitos não eram de estilo, e estes três foram achados pelo agente revisor, não por nós mesmos. Uma contagem de comentários lida do elemento errado de uma página HTML, que reportou uma thread com 68 comentários quando a thread tem 15, porque o número pertencia a outro post da mesma página. Uma citação que perdeu uma única palavra, transformando nenhuma regra de bloqueio branda em nenhuma regra de bloqueio, o que apagou em silêncio uma classe inteira de regra de uma fonte citada. E um comando publicado que não fazia o que o parágrafo em volta dele dizia, sem filtrar nada enquanto o texto afirmava que ele excluía arquivo binário. É o tipo de coisa que uma leitura fluente nunca pega e uma máquina instruída a verificar pega.

Diga os limites desse número com honestidade, porque eles são reais. É uma pipeline, uma janela de dois dias, e o artefato revisado é um artigo técnico carregando comandos executáveis, não um pull request contra código de produção. Isso mostra que um agente revisor de contexto zerado acha, numa taxa alta, defeito que o autor não viu. Não mostra que a mesma taxa vale para código de aplicação, e isso a gente não mediu.

O que um revisor de IA não consegue pegar?

Intenção, e ausência. Um agente de IA revisor lê o que o diff contém, então ele julga se o código faz o que o código diz. Ele não sabe dizer que a funcionalidade resolve o problema errado, que o requisito foi lido torto, ou que um caso que deveria existir simplesmente não está lá. Ausência não tem número de linha, e agente revisor está ancorado em linha.

Ele também é mau juiz de consequência. Um agente revisor aponta um teste de nulo que faltou e um arredondamento errado de moeda com o mesmo tom, e só uma pessoa que conhece o produto sabe que um dos dois é cosmético e o outro é dinheiro. É por isso que o merge continua humano mesmo quando a leitura é delegada: aprovar é ato de responsabilidade, e responsabilidade não se transfere para um processo que dá para rodar de novo.

A divisão realista de trabalho é a máquina ler primeiro e a pessoa decidir. Ela estreita o diff que você precisa ler com cuidado, o que vale muito num dia em que os agentes entregaram mais do que uma pessoa lê. Ela não encurta a parte em que alguém tem de entender o que foi integrado.

Como montar uma revisão adversarial para código de agente de IA?

Quatro regras, cada uma o conserto de uma falha que a gente levou. Comece uma sessão nova, sem nada da conversa de escrita dentro dela. Entregue o diff e o requisito, não a história de como o código chegou ali, porque a história é onde a suposição errada é mais convincente. Nomeie as classes de defeito a caçar: o que mudou e não deveria, um teste que passaria com a implementação vazia, uma suposição nunca dita, e um número ou citação que não bate com a fonte. Exija que ele rode o que dá para rodar, já que comando que ninguém executou é alegação, e alegação é o que você estava tentando verificar.

Na rodada seguinte a uma correção, mude a instrução em vez de repetir: diga ao revisor que os defeitos relatados já foram corrigidos, que ele não gaste tempo neles, e que o trabalho dele é achar um defeito que não estava lá antes. Na nossa pipeline, essa mudança sozinha é o que transformou a segunda e a terceira rodada de formalidade nas rodadas que acharam os problemas mais perigosos.

Um revisor de IA basta para você aprovar sem ler?

Não, e o argumento a favor é mais fraco do que parece. O que dizem é que geração é barata, teste é barato, e o que se mede é resultado, então uma suíte verde mais uma revisão de agente deveriam bastar. A allowlist lá em cima é o contraexemplo: três testes verdes e uma função explorável. Coloque um agente revisor com o contexto do autor e ele concorda com o autor. Coloque um com contexto limpo e instrução adversarial e ele tem chance real de perguntar por que a verificação é startswith, que é a pergunta que conserta o defeito.

O que muda com uma boa revisão por agente é a ordem da sua atenção, não a necessidade dela. Você lê um diff que já foi sondado, então gasta a sua leitura onde a máquina não conseguiu ir: em se aquilo era a coisa certa de construir. É a parte que ninguém automatizou, e também é a parte que sempre foi a cara.

Em que isto se baseia, e o que isto não prova

Os números de rodadas de revisão são nossos, tirados do nosso diário de automação em 14 de agosto de 2026, cobrindo uma janela de dois dias e seis entregas, em artigos técnicos com comandos executáveis e não em pull requests de produção. O exemplo da allowlist foi escrito para este artigo e rodado no Python 3.14.3 no macOS; a saída mostrada é transcrição daquela execução. As posições de mercado vêm de uma thread pública do r/cursor datada de 11 de agosto de 2026, que lemos pela página e não pela API, e que dois comentaristas dela mesma chamam de escrita por IA, um deles acrescentando que é caça a engajamento, ressalva que a gente repassa em vez de esconder.

O que nada disso resolve é a questão do fornecedor. Se um agente revisor de outra empresa ganha do mesmo modelo rodando com contexto limpo é uma comparação que a gente não rodou, e enquanto ninguém rodar, resposta em qualquer direção é preferência vestida de achado.