Cross-check com um segundo modelo achou bug HIGH que o primeiro deixou passar

Um mesmo modelo de IA revisando o próprio código (ou o código de um agente irmão da mesma família) tende a ter pontos cegos correlacionados: os tipos de erro que um modelo comete ao escrever código tendem a ser os mesmos tipos de erro que ele deixa passar ao revisar código — porque nascem da mesma distribuição de treinamento e do mesmo padrão de raciocínio.

Rodando uma revisão de código com dois modelos de fornecedores/arquiteturas diferentes sobre a mesma mudança, o segundo modelo encontrou uma falha de severidade alta (HIGH) que o primeiro modelo — que tinha acabado de revisar a mesma mudança e reportado "sem problemas relevantes" — não sinalizou.

Por que isso não é surpresa, olhando de fora

É o mesmo argumento por trás de revisão de código humana: um segundo par de olhos ajuda mais quando é um par de olhos com um modelo mental diferente do primeiro autor, não um clone do mesmo raciocínio. Com modelos de IA, essa diferença de "modelo mental" existe entre famílias/fornecedores distintos de forma mais garantida do que entre duas chamadas do mesmo modelo — mesmo com temperatura alta, a mesma arquitetura tende a errar do mesmo jeito, nas mesmas classes de problema.

O padrão prático

• Para mudanças de maior risco (segurança, dado destrutivo, lógica financeira), rodar revisão com pelo menos dois modelos de origens diferentes antes de aceitar como "revisado".
• Tratar concordância entre os dois como sinal mais forte de segurança do que a aprovação de um único modelo, mesmo que o único modelo tenha sido minucioso.
• Tratar discordância como sinal para revisão humana — não para "escolher o modelo que discordou menos".

O limite do padrão

Cross-check com dois modelos não substitui revisão humana em mudanças de alto risco real (dado de produção, ação irreversível, segurança de credencial) — ele reduz a taxa de erro correlacionado de uma única revisão automatizada, mas ambos os modelos ainda podem compartilhar um ponto cego não relacionado à arquitetura (por exemplo, um requisito de negócio que nenhum dos dois tem contexto suficiente para avaliar). O ganho é real e barato de obter; não é uma garantia.

← Voltar pra Notes