Le pides al mismo modelo que piense el plan, lo critique y después lo ejecute. Es como dejar que tu creativo se revise su propio trabajo y se apruebe el presupuesto. Poner a Codex y Claude Code a discutir tu plan es la forma más directa de detectar agujeros antes de que escribas una sola línea de código. Y no, no hace falta ser ingeniero para montarlo.
TL;DR: El resumen sin rodeos
- Grill Me Codex: una skill que enfrenta a Claude y Codex en rondas de crítica hasta que convergen en un plan sólido.
- Máximo 5 rondas: un modelo propone, el otro demuele, y vuelta. Si no hay acuerdo en cinco iteraciones, se cierra y se trabaja con el plan resultante.
- El principio de fondo: un solo modelo planificando y ejecutando tiene puntos ciegos que él mismo no puede ver. Dos perspectivas distintas los cazan.
- Reproducible sin la skill original: el patrón es simple y puedes montarlo con un prompt estructurado en cualquier agente de código.
Qué es "Grill Me Codex" y por qué combinar dos modelos
Grill Me Codex es una skill creada por chase.h.ai que automatiza un patrón simple: poner a dos modelos a discutir sobre tu plan hasta que ambos estén de acuerdo. La idea viene de la skill "Grill Me" de Matt Pocock, que ya obligaba a Claude a cuestionar su propio plan antes de ejecutar. La versión Codex lleva esto un paso más allá: la crítica viene de un modelo con entrenamiento distinto.
El flujo es directo. Claude monta un plan para tu proyecto. Ese plan se pasa a Codex (el agente de código de OpenAI basado en GPT), que lo destripa: señala debilidades, dependencias ignoradas, casos límite. Claude recibe la crítica, revisa lo que tiene sentido y defiende lo que no. Ida y vuelta, máximo cinco rondas o hasta que ambos converjan.
Una vez hay acuerdo, el plan pasa a ejecución. Por defecto lo ejecuta Claude Code, aunque el flujo es editable: puedes asignar la ejecución a Codex o a otro modelo más pequeño si te encaja mejor.
Por qué un modelo planificando solo es una trampa
Un modelo de lenguaje que planifica, critica su plan y luego lo ejecuta tiene un problema estructural: sus puntos ciegos son consistentes. Si su entrenamiento le hace subestimar la complejidad de una migración de base de datos, la va a subestimar al planificar Y al revisar. No hay contrapeso.
En cualquier agencia seria, un proyecto pasa por al menos dos cabezas antes de ejecutarse. El que lo piensa no es el que lo aprueba. No por desconfianza: porque dos cerebros entrenados de forma distinta ven cosas distintas. Pues con los modelos, igual.
Claude y GPT tienen sesgos diferentes. Por lo que hemos probado, Claude tiende a ser más conservador en arquitectura, más detallista en casos límite. GPT suele ser más agresivo proponiendo soluciones rápidas, a veces saltándose pasos. Cuando los enfrentas, Claude pilla las chapuzas de GPT y GPT pilla el exceso de ingeniería de Claude. El plan que sale de esa fricción es, casi siempre, más realista que el de cualquiera de los dos solos.
Lo llevamos aplicando en nuestros pipelines de automatización con IA desde el día uno: separar generación de validación. Nunca confías en el primer resultado sin un segundo par de ojos, sea humano o sea otro modelo.
Cómo montar tu propia revisión cruzada entre modelos
No necesitas la skill exacta de chase.h.ai para aplicar el patrón. Lo que necesitas es un agente de código (Claude Code, Cursor, Windsurf) y acceso a un segundo modelo vía API o CLI. El flujo es reproducible con un prompt bien estructurado.
El truco está en separar roles con claridad: un modelo propone, el otro SOLO critica. Si mezclas roles ("planifica y dime qué está mal"), vuelves al problema original. La crítica tiene que venir de fuera, sin contexto previo del razonamiento que llevó al plan. Así la revisión es honesta.
Cinco rondas es un buen tope. En nuestra experiencia, las dos primeras rondas son las que de verdad aportan. A partir de la tercera, si no hay convergencia, es que el proyecto está mal definido y toca acotarlo antes de seguir.
Y ojo, esto escala a cualquier decisión compleja, no solo a código. Cada modelo tiene un terreno donde brilla: usarlos como adversarios en vez de como herramientas intercambiables es lo que convierte la IA en un proceso serio y no en un lanzamiento de moneda con pasos de más.
Copia esto y pégalo en Claude Code, Cursor o tu asistente de código favorito:
Actúa como planificador. Genera un plan detallado para [describe tu proyecto]. Después, envía ese plan a Codex (o a GPT-4 vía API) con este prompt: "Critica este plan. Señala puntos débiles, dependencias ocultas y casos límite. No propongas soluciones, solo problemas." Recoge la crítica, revisa tu plan y repite hasta 3 rondas o hasta convergencia.
No necesitas saber programar. El asistente se encarga de la instalación, la configuración y las pruebas.
Lo que nadie te dice de la revisión adversarial
Hay un riesgo real en este enfoque que el vídeo original no menciona: la convergencia prematura. Dos modelos pueden "ponerse de acuerdo" en algo incorrecto simplemente porque ambos comparten un sesgo de entrenamiento (datos de Stack Overflow de la misma época, por ejemplo). El acuerdo no es garantía de calidad. Es una señal, no una prueba.
Apostaría a que lo mejor de este patrón son las objeciones de las primeras rondas. Esas críticas iniciales son las que te fuerzan a pensar en lo que dabas por hecho. Aunque las descartes después, defenderlas ya te obliga a entender mejor el problema.
Por eso el enfoque de aprender rompiendo con IA agéntica encaja tan bien aquí: lo bueno está en la pelea en sí.
Si trabajas con IA para proyectos complejos y todavía le pides a un solo modelo que haga todo el trabajo mental, estás dejando dinero en la mesa. La IA que de verdad vale es la que te obliga a defender tu respuesta antes de ejecutarla.
