Vou te contar o resultado mais útil que eu tirei de rodar vários modelos de IA ao mesmo tempo, e não é velocidade. É isto: o melhor reviewer do código que um modelo escreve quase nunca é ELE MESMO. É um modelo de OUTRA família. Eu medi. Não é achismo. Num período, quase todo defeito real que a gente pegou ANTES de mergear -- os que iam pra produção e machucavam -- veio da mesma jogada: um modelo entregava um PR marcado como "pronto", e um modelo de família diferente, revisando, achava o buraco. Dez de doze achados vieram desse cruzamento. Não de mim relendo. Não do mesmo modelo se auto-revisando. De um cérebro treinado diferente olhando o trabalho do primeiro. POR QUE ISSO ACONTECE: Modelo tem ponto cego, igual pessoa. E o ponto cego é CORRELACIONADO dentro da mesma família. Se um modelo escreveu um bug porque "pensou" de um certo jeito, ele mesmo relendo tende a "pensar" do mesmo jeito e passar batido no mesmo lugar. Ele te dá uma revisão educada e confiante do código dele próprio, e não vê o que não consegue ver. Já um modelo treinado diferente chega com outro viés -- e onde os vieses NÃO batem, o defeito aparece. Tem uma ironia boa aqui. Em maio a Anthropic soltou o Opus 4.8 e um dos números de destaque foi que ele deixa passar umas 4x menos falha no próprio código que a versão anterior. Ou seja: os modelos estão ficando melhores em se auto-revisar. E MESMO ASSIM, na minha frota, quem pega o defeito continua sendo o OUTRO modelo. Semana passada ainda subiram uma família nova, a Fable/Mythos, vendida como "focada por milhões de tokens". Modelo melhor, contexto maior, e a conclusão não muda: auto-revisão do mesmo cérebro tem teto. Família diferente não tem esse teto. O QUE O GATE REALMENTE PEGOU: E não foi typo. Foram bugs que iam sangrar: Uma sessão já revogada sendo aceita como válida. Dado sensível -- telefone de gente -- vazando num endpoint de lista que não devia expor. Uma flag "desligada" que dizia estar off e não estava, o que no meu livro é desonestidade de sistema. Um campo de frete editável quando não podia ser. Uma checagem de auth que falhava ABERTA -- quando quebrava, liberava geral em vez de barrar. Colisão em rotina de dinheiro que ia duplicar lançamento. Cada um desses passou pelo modelo que escreveu, marcado como "pronto". Cada um foi pego pelo modelo que revisou. Se fosse só o autor se auto-revisando, tavam todos em produção agora. COMO EU USO ISSO NA PRÁTICA: Um modelo virou a perna primária de review -- ele acha mais. Eu adjudico, porque alguém tem que decidir e a decisão é minha. Pra coisa de risco alto -- auth, dinheiro, dado pessoal -- é review DUPLO, dois modelos diferentes obrigatório. Pra ajuste de UX de baixo risco, um passe cruzado resolve. Tierado por risco, não por dogma. A parte contra-intuitiva é que isso me deixou MENOS apegado a "qual é o melhor modelo". A pergunta certa não é essa. É: quais dois modelos erram de um jeito diferente o bastante pra um cobrir o outro? Código bom, no fim, não nasceu de um modelo genial. Nasceu do ATRITO entre dois modelos que discordam.