[🤖] A IA continuava concordando comigo, então decidi pedir que outra IA a contestasse primeiro

✨ Resumo do GPT-5.6 Sol

Ao investigar por que um trabalho de UI de 16 horas havia fracassado, percebi que a IA mudava de conclusão a cada objeção minha. Este é o registro de como troquei críticas entre sessões e transformei o processo em uma Skill com um fresh critic e no máximo duas rodadas de revisão.

Eu não conseguia simplesmente acreditar nem na resposta que explicava um fracasso de 16 horas

Ontem passei muito tempo discutindo e escrevendo especificações página por página para uma reformulação completa de UI/UX, e defini um Codex Goal para desenvolver com base nelas. O Goal rodou por 16 horas. Hoje abri a tela real cheio de expectativa, mas o resultado era simplesmente lixo.

Eu havia planejado até as visualizações de calendário e table, porém parecia que tinham apenas empilhado explicações e cards sobre a tela antiga. Enquanto isso, relatórios de implementação concluída, auditoria aprovada e build aprovado continuavam se acumulando. Exigi saber o que ele havia feito durante 16 horas e mandei analisar primeiro a causa daquela situação.

Nesse processo, descobri também que o problema contra o qual eu lutava começava a receber o nome de Graph Engineering. Dividir um trabalho longo em resultados pequenos e etapas de verificação, separando quem implementa de quem audita para impedir que uma direção errada se espalhe, parecia claramente útil para este incidente.

Mas, antes da metodologia, outro problema chamou minha atenção. Quando eu sugeria uma alternativa, a IA logo dizia que ela estava certa. Quando eu fazia uma objeção, passava a dizer que a objeção estava certa. Cada resposta soava plausível, mas a conclusão oscilava para o lado da minha fala mais recente.

Até a própria resposta que explicava o fracasso era difícil de aceitar sem questionar.

“Por favor, critique”

Então enviei a resposta de uma sessão para outra fazer uma revisão crítica. Levei a crítica de volta à sessão original para que respondesse e depois mostrei a nova resposta a outra sessão.

Isso era ao menos melhor do que deixar uma sessão responder e elogiar a si mesma. Um lado captava pressupostos que o outro havia tratado como óbvios, e surgiam custos operacionais e formas de fracasso ausentes da primeira resposta. Por outro lado, quando a sessão crítica avançava demais, a original também contestava com evidências.

Mesmo assim, eu precisava continuar segurando o processo. Quando colava a crítica de outra sessão, ela aceitava com facilidade demais que “essa crítica está certa”. Por fim, eu disse:

Por favor, critique.

Eu não queria ver duas IAs chegando amigavelmente a um consenso. Queria desconfiar tanto da primeira resposta quanto da crítica posterior e investigar até o fim o que realmente correspondia às evidências. Várias vozes dizendo a mesma coisa não a tornam correta, e chamar um Agent de critic não o torna automaticamente mais preciso.

Eu gostava do método de trocar respostas entre sessões e adotar ao final a conclusão que sobrevivesse. O problema era o trabalho irritante de copiar e colar repetidamente o texto original, a resposta e a réplica entre GPT e Codex.

Eu reduzi novamente o grande sistema de debate

No começo imaginei uma “Skill de debate” que criaria até três critics e executaria várias rodadas. Cheguei a pensar em assinar o Claude Code para fazê-lo trocar argumentos com o Codex pela CLI.

A IA propôs separar Coordinator, Worker e Auditor e manter estado adicional. Não era uma ideia errada, mas, para mim, o trabalho voltava a ficar desnecessariamente complicado. O Goal de 16 horas fracassou justamente por ser uma tarefa longa sem controle. Parecia estranho tentar evitar isso construindo outra orchestration gigantesca.

O que eu imaginava era muito mais simples.

Não bastaria abrir um fresh subagent e trocar revisões com ele?

A sessão principal envia sua conclusão atual a um critic. Sem ser puxado pelo clima da conversa anterior, o critic procura contraexemplos e pressupostos ocultos. A sessão principal classifica cada ponto como aceito, refutado com evidências ou não resolvido. Se corrigir a resposta, mostra-a ao mesmo critic apenas mais uma vez. Eles verificam se o problema foi realmente resolvido e encerram.

Um novo assunto recebe um fresh critic; a revisão de uma correção do mesmo assunto volta ao mesmo critic. Se a primeira crítica não encontrar um problema importante, não se força uma segunda rodada. Mesmo com vários critics, a conclusão não é decidida por maioria.

Isso automatizava quase exatamente o que eu fazia à mão, sem permitir que o próprio debate virasse outro projeto enorme.

Eu pedi uma Skill que não escondesse as contestações

Depois de definir a direção, dei instruções concretas ao Codex para criar uma Skill global. O padrão seria um critic e no máximo duas rodadas de revisão. O critic seria um fresh subagent que não herdaria toda a conversa. Uma revisão do mesmo assunto voltaria ao critic que o analisou primeiro. O workflow seria somente de leitura, sem tocar em arquivos, Git, Runtime ou estado externo.

Minha exigência mais importante era não adotar automaticamente a resposta do critic.

A sessão principal precisa tratar cada crítica importante de uma destas três maneiras.

• Aceitar e corrigir a conclusão.
• Refutar com evidências.
• Manter como divergência não resolvida.

A resposta final deve revelar não apenas o que mudou com a crítica, mas também quais pontos foram rejeitados e que incertezas permanecem. Eu queria impedir que objeções inconvenientes fossem omitidas em silêncio ou que uma conclusão fosse enfeitada com “três Agents concordaram”.

No início usei o nome visível Custom - Debate, mas depois mandei alterá-lo para Custom - Deliberate, seguindo as regras comuns de nomes de Skill. O directory e o nome de chamada já eram custom-deliberate desde o começo. O novo nome também combinava melhor: não se trata de escolher o vencedor de um debate, mas de deliberar e tentar refutar uma conclusão antes de fixá-la.

Usei imediatamente a Skill para revisar a si mesma

Não parei só porque a Skill havia sido criada. Usei imediatamente $custom-deliberate para revisar se o próprio processo era adequado. Depois perguntei novamente se aplicar aquelas críticas realmente melhoraria o desempenho.

Esse processo deixou a Skill mais sóbria. Ela agora declara que deixar de passar a conversa anterior não cria um critic totalmente independente. O critic ainda compartilha o mesmo modelo e as mesmas regras superiores e pode errar da mesma forma, dependendo das evidências que a sessão principal incluir no packet. Ela também diferencia possibilidades meramente imagináveis de material objections capazes de mudar de fato a conclusão. Se não houver objeção importante, termina cedo; se faltarem evidências, admite a insuficiência em vez de forçar consenso.

O que eu fazia copiando respostas entre sessões entrou na Skill. Não confio na primeira resposta, mas também não aceito a crítica automaticamente. Eu adoto somente a conclusão que continua de pé depois da refutação e da nova revisão.

Agora tento quebrar uma resposta antes de aceitá-la

Esta Skill não garante a verdade. Se eu realmente quiser romper vieses compartilhados pela mesma família de modelos, talvez seja melhor conectar outro modelo, como Claude Code. Se eu der material errado ao critic, ele pode apenas produzir uma resposta errada mais sofisticada. Preferências e juízos de valor reais continuam sendo responsabilidade minha.

Mesmo assim, antes de adicionar outra assinatura de 150 mil wones, quero testar primeiro este método pequeno.

Não confirmo a conclusão imediatamente. Peço a um fresh critic que tente quebrá-la. Registro quais objeções aceitei, por que rejeitei outras e o que permanece sem solução. Mostro a resposta corrigida ao mesmo critic apenas uma vez mais.

Eu já havia escrito que tanto Claude Code quanto Codex precisam, no fim, de um harness. Desta vez apliquei essa ideia ao processo de julgamento. Fazer a IA terminar o trabalho é importante, mas impedir que ela concorde cegamente comigo e fixe uma conclusão rápido demais também é.

Daqui em diante, ao tomar com a IA uma decisão não trivial, em vez de pedir mais uma resposta, perguntarei primeiro o que pode estar errado na resposta atual. Se eu acabar repetindo a mesma rotina de copiar e colar, então será hora de conectar Claude Code ou outro modelo. Por enquanto, este é o mecanismo crítico mínimo que eu queria.