[🤖] La IA no dejaba de darme la razón, así que decidí hacer que otra IA la refutara primero

✨ Resumen de GPT-5.6 Sol

Mientras investigaba por qué había fracasado un trabajo de UI de 16 horas, descubrí que la IA cambiaba de conclusión con cada objeción mía. Este es el registro de cómo pasé críticas entre sesiones y convertí el proceso en una Skill con un fresh critic y un máximo de dos rondas de revisión.

Ni siquiera podía aceptar sin más la respuesta que explicaba un fracaso de 16 horas

Ayer dediqué mucho tiempo a debatir y redactar especificaciones página por página para una renovación completa de la UI/UX, y configuré un Codex Goal para que desarrollara a partir de ellas. El Goal trabajó durante 16 horas. Hoy abrí la pantalla real con muchas expectativas y el resultado era simplemente basura.

Había planificado incluso las vistas de calendario y table, pero parecía que solo habían apilado explicaciones y cards sobre la pantalla antigua. Mientras tanto, durante el trabajo se habían acumulado informes de implementación terminada, auditoría aprobada y build aprobado. Exigí saber qué demonios había hecho durante 16 horas y le ordené analizar primero la causa de aquel desastre.

En ese proceso también descubrí que el problema contra el que estaba luchando empezaba a llamarse Graph Engineering. Dividir un trabajo largo en resultados pequeños y etapas de verificación, y separar al implementador del auditor para impedir que una dirección equivocada se propagara, parecía claramente útil para este incidente.

Pero antes que la metodología, apareció otro problema. Si yo proponía una alternativa, la IA decía enseguida que esa era la correcta. Si planteaba una objeción, entonces decía que la objeción era correcta. Todo sonaba convincente, pero la conclusión se inclinaba hacia lo último que yo hubiera dicho.

Hasta la propia respuesta que explicaba el fracaso resultaba difícil de creer.

«Por favor, critícalo»

Así que pasé la respuesta de una sesión a otra para que la revisara críticamente. Llevé esa crítica de vuelta a la sesión original para que respondiera y luego mostré la nueva respuesta a otra sesión.

Al menos era mejor que dejar que una sesión respondiera y se felicitara a sí misma. Una parte encontraba supuestos que la otra había dado por obvios, y aparecían costes operativos y formas de fracaso que faltaban en la primera respuesta. A la inversa, cuando la sesión crítica se iba demasiado lejos, la original también rebatía con pruebas.

Pero incluso entonces yo tenía que frenarlas. Cada vez que pegaba la crítica de otra sesión, aceptaban con demasiada facilidad que «esa crítica es correcta». Al final dije:

Por favor, critícalo.

No quería ver a dos IA llegar amistosamente a un acuerdo. Quería desconfiar tanto de la primera respuesta como de la crítica posterior y averiguar hasta el final qué encajaba realmente con las pruebas. Que varias voces digan lo mismo no lo convierte en verdad, y llamar critic a un Agent tampoco lo hace automáticamente más preciso.

Me gustaba el proceso de intercambiar respuestas entre sesiones y adoptar al final la conclusión que resistiera. El problema era lo tedioso que resultaba copiar y pegar cada vez el texto original, la respuesta y la réplica entre GPT y Codex.

Volví a reducir el gran sistema de debate

Al principio imaginé una «Skill para debatir» que creara hasta tres critics y ejecutara varias rondas. Incluso pensé en pagar Claude Code para que intercambiara argumentos con Codex mediante la CLI.

La IA propuso separar Coordinator, Worker y Auditor y mantener estado adicional. No era incorrecto, pero para mí el trabajo volvía a complicarse sin necesidad. El Goal de 16 horas había fallado por ser una tarea larga sin control. Resultaba extraño intentar evitarlo construyendo otra orchestration enorme.

Lo que yo tenía en mente era mucho más sencillo.

¿No bastaría con abrir un fresh subagent y cruzar revisiones con él?

La sesión principal envía su conclusión actual a un critic. Sin dejarse arrastrar por el ambiente de la conversación anterior, el critic busca contraejemplos y supuestos ocultos. La sesión principal clasifica cada observación como aceptada, refutada con pruebas o no resuelta. Si modifica la respuesta, se la muestra al mismo critic una sola vez más. Comprueban si el problema quedó resuelto y terminan.

Un asunto nuevo recibe un fresh critic; la revisión de una corrección del mismo asunto vuelve al mismo critic. Si la primera crítica no encuentra un problema importante, no se fuerza una segunda ronda. Aunque haya varios critics, la conclusión no se decide por mayoría.

Con eso podía automatizar casi exactamente lo que hacía a mano sin permitir que el propio debate se convirtiera en otro proyecto gigante.

Pedí una Skill que no ocultara las refutaciones

Una vez fijada la dirección, di a Codex instrucciones concretas para crear una Skill global. El valor predeterminado sería un critic y un máximo de dos rondas. El critic sería un fresh subagent que no heredara toda la conversación. La revisión del mismo asunto volvería al critic que lo hubiera evaluado primero. El workflow sería de solo lectura, sin tocar archivos, Git, Runtime ni estado externo.

Mi requisito más importante fue que no adoptara automáticamente la respuesta del critic.

La sesión principal debe tratar cada crítica importante de una de estas tres formas.

• Aceptarla y modificar la conclusión.
• Refutarla con pruebas.
• Mantenerla como desacuerdo no resuelto.

La respuesta final debe revelar no solo qué cambió debido a la crítica, sino también qué observaciones fueron rechazadas y qué incertidumbre permanece. Quería impedir que omitiera en silencio las objeciones incómodas o adornara una conclusión diciendo que «tres Agents estuvieron de acuerdo».

Al principio usé el nombre visible Custom - Debate, pero después hice que lo cambiara a Custom - Deliberate para ajustarlo a las reglas comunes de nombres de Skill. El directory y el nombre de invocación habían sido custom-deliberate desde el principio. También encajaba mejor con su finalidad: no elegir al ganador de un debate, sino deliberar e intentar refutar una conclusión antes de fijarla.

Usé inmediatamente la Skill para revisarse a sí misma

No terminé solo porque la Skill estuviera creada. Usé de inmediato $custom-deliberate para revisar si el proceso era adecuado. Después volví a preguntar si aplicar esas críticas mejoraría realmente el rendimiento.

El proceso volvió la Skill un poco más sobria. Ahora declara que no transmitir la conversación anterior no crea por sí solo un critic totalmente independiente. El critic sigue compartiendo el mismo modelo y las mismas reglas superiores, y puede equivocarse del mismo modo según las pruebas que la sesión principal incluya en el packet. También distingue posibilidades puramente imaginarias de material objections capaces de cambiar de verdad la conclusión. Si no hay una objeción importante, termina pronto; si faltan pruebas, lo reconoce en lugar de forzar un acuerdo.

Lo que yo había estado haciendo al copiar respuestas entre sesiones quedó dentro de la Skill. No confío en la primera respuesta, pero tampoco acepto automáticamente la crítica. Solo adopto la conclusión que siga en pie después de la refutación y la revisión.

Ahora intento romper una respuesta antes de aceptarla

Esta Skill no garantiza la verdad. Si realmente quiero romper sesgos compartidos por una misma familia de modelos, quizá sea mejor conectar otro modelo como Claude Code. Si doy al critic material equivocado, puede limitarse a producir una respuesta errónea más sofisticada. Las preferencias y los juicios de valor reales siguen siendo responsabilidad mía.

Aun así, antes de añadir otra suscripción de 150.000 wones, quiero probar primero este método pequeño.

No fijo una conclusión de inmediato. Pido a un fresh critic que intente romperla. Registro qué objeciones acepté, por qué rechacé otras y qué sigue sin resolverse. Muestro la respuesta corregida al mismo critic una única vez más.

Ya había escrito que tanto Claude Code como Codex necesitan al final un harness. Esta vez apliqué esa idea al proceso de juicio. Conseguir que la IA termine el trabajo es importante, pero también lo es impedir que me dé la razón a ciegas y cierre demasiado rápido una conclusión.

A partir de ahora, cuando tome con la IA una decisión no trivial, en vez de pedir otra respuesta preguntaré primero qué podría estar mal en la respuesta actual. Si vuelvo a repetir el mismo copiar y pegar, entonces será el momento de conectar Claude Code u otro modelo. Por ahora, este es el mínimo mecanismo crítico que quería.