Claudeex probado: Claude Code y Codex en un loop de planes

Claudeex probado: Claude Code y Codex en un loop de planes

El plan parecía limpio. Doce pasos numerados. Diagrama de arquitectura en rebajas. Se detalla el orden de migración de la base de datos. Estaba a punto de presionar "implementar" cuando recordé que tenía instalado Claudeex, así que pensé en dejarlo ejecutar antes de enviar algo.

La primera ronda terminó con siete números. Tres de ellos hablaban en serio. Uno de ellos, "el plan llama a un webhook antes de que exista la fila de la base de datos", me habría costado una tarde completa de depuración a las 11 p.m. de un martes. El plan que estaba a punto de lanzar tenía una condición de carrera incorporada en el paso cuatro.

Ese es el momento en que dejé de pensar en Claudeex como una curiosidad y comencé a considerarlo como el tipo de cosa que debería haber estado ejecutando durante los últimos seis meses.

Si aún no lo ha visto, Claudeex es un pequeño bash y un arnés YAML que convierte Claude Code y OpenAI Codex CLI en un bucle de planificación. Claude Code redacta un plan, Codex lo audita, Claude Code lo revisa, Codex audita la revisión, y así sucesivamente hasta alcanzar un límite redondo configurable. El valor predeterminado es tres rondas. Todo se basa en el gancho de parada de Claude Code, que pausa la ejecución entre turnos para que el script bash pueda pagar a codex exec el pase de auditoría.

He pasado las últimas dos semanas ejecutándolo en trabajo de cliente real (una página de análisis de visitantes, una refactorización de webhook de Stripe, un pequeño panel de administración de Laravel) y hay suficiente aquí como para explicar qué funciona, dónde se ven las uniones y por qué los bucles de planificación de dos modelos están a punto de convertirse en los predeterminados para cualquier cosa más compleja que un formulario CRUD.

Qué es realmente Claudeex (más allá de README)

El discurso es sencillo: Claude Code es bueno para redactar planes, Codex es bueno para encontrar agujeros en ellos, y la mayoría de los errores de planificación se pueden detectar si solo tienes un segundo modelo que lee el plan con ojo crítico. Entonces, en lugar de pedirle a usted que sea el segundo modelo, Claudeex automatiza el ida y vuelta.

Mecánicamente son cuatro piezas:

1. Un iniciador de bash que recibe un mensaje, escribe un archivo de estado YAML e inicia Claude Code con la configuración del enlace derecho cargada.
2. Un archivo de estado YAML que rastrea el mensaje, las rondas totales, la iteración actual y cualquier archivo de contexto anclado (como scope.md o architecture.md)
3. Un gancho de parada Claude Code que se activa después de que Claude finaliza un turno de planificación, lee el archivo de estado y decide si invocar Codex o dejar que Claude termine
4. Tres comandos de barra diagonal: /plan, /review y /cancel, además de un /rollback para borrar el estado del plan cuando desee hacer borrón y cuenta nueva

El gancho de tope es la parte inteligente. El gancho de parada se dispara una vez por turno cuando Claude termina de responder de Claude Code, y un gancho de parada que sale con el código 2 obliga a Claude a seguir trabajando. Claudeex usa ese truco de salida 2 para inyectar la transcripción de auditoría de Codex nuevamente en la conversación como si el propio Claude hubiera recibido comentarios de un revisor y luego le pide a Claude que lo revise. Desde dentro del contexto de Claude Code, parece simplemente otro giro, pero resulta que el giro contiene una crítica estructurada desde un modelo de frontera diferente.

Si ha leído mi desglose del flujo de trabajo de dos agentes Claude Code y Codex, el modelo mental es similar. La diferencia es que Claudeex integra el bucle en la propia sesión Claude Code; no es necesario canalizar manualmente transcripciones entre terminales ni copiar y pegar críticas. El gancho lo hace.

Por qué la planificación de dos modelos supera a la planificación de un solo modelo

Quiero tener cuidado aquí porque el encuadre obvio (“dos modelos son mejores que uno”) es el tipo de afirmación vaga que normalmente eliminaría de un borrador. Permítanme ser específico sobre lo que realmente cambia.

Cuando Claude Code redacta un plan solo, opera a partir de una distribución única de "cómo son los buenos planes". Tiene sus propios sesgos de formación. Tiene sus propios puntos ciegos. Cuando le pido que "verifique dos veces el plan", esencialmente le estoy pidiendo que no esté de acuerdo consigo mismo, algo en lo que los modelos lingüísticos son notoriamente malos. Hay investigaciones sobre la adulación y la autoconsistencia que explican por qué: los modelos entrenados con RLHF tienden a comprometerse con su primera respuesta y luego defenderla, incluso cuando se les pide que hagan una crítica.

Codex es un modelo diferente con un canal de formación diferente. El modelo de producción actual en la CLI Codex es GPT-5.5 (con GPT-5.4 como alternativa si su cuenta aún no ha sido cancelada). Cuando Codex audita un plan escrito por Claude, está leyendo prosa escrita en un estilo cognitivo ligeramente diferente y está mucho más dispuesto a señalar cosas que Claude pasó por alto. La asimetría es el valor. Codex detecta cosas que Claude escribió en el pasado; Claude detecta cosas que Codex habría pasado por alto si hubiera redactado el plan.

En la práctica, en los proyectos que he ejecutado a través de Claudeex durante las últimas dos semanas, la tasa de detección de errores en la etapa de planificación ronda el 80% en las primeras dos o tres rondas. Después de la tercera ronda, los rendimientos marginales disminuyen: Codex comienza a señalar preferencias estilísticas en lugar de problemas reales. Por eso el valor predeterminado de tres rondas es correcto. Intenté configurarlo en cinco en un trabajo complejo y en la cuarta ronda Codex discutió sobre si debería usar una enumeración o una cadena para un campo de estado. En la quinta ronda, Codex cambió de opinión sobre la cuarta ronda. Tres rondas es el punto óptimo.

La superficie de slash commands

Hay cuatro comandos de barra diagonal y realmente solo necesitas dos de ellos en el día a día.

/plan <prompt> es el caballo de batalla. Le entrega una descripción de lo que desea crear, opcionalmente fija algunos archivos de contexto como scope.md o architecture.md y se ejecuta el bucle. Borradores de Claude, auditorías de Codex, revisiones de Claude. Al final, obtienes un plan final con las eliminaciones y adiciones de cada ronda que se muestran en rojo y verde para que puedas ver cómo evolucionó el plan. Si alguna vez realizó una revisión seria del código y vio la transformación PR de un ingeniero junior entre v1 y v3, la vista de diferencias se ve exactamente así.

/review es la versión de solo lectura. Se necesita un plan existente (uno que usted escribió, uno que escribió un compañero de equipo, uno que Claude escribió en una sesión anterior) y ejecuta Codex sobre él sin ningún paso de revisión. Obtienes los comentarios de auditoría y eso es todo. Lo uso en planes que estoy a punto de entregar a otro desarrollador; es una segunda opinión barata antes de comenzar el trabajo.

/cancel es una parada de emergencia. Si el bucle se descarrila (Codex comienza a alucinar dependencias, Claude comienza a reescribir la misma sección en círculos), puede interrumpir la ejecución limpiamente sin dejar el archivo de estado YAML en un medio estado roto.

/rollback borra el estado del plan por completo. Útil cuando desea empezar de nuevo desde cero sin reiniciar Claude Code.

La sintaxis importa más de lo que cabría esperar. La primera vez que ejecuté /plan, le pedí una frase: "cree una página de análisis de visitantes que no utilice terceros". Claude escribió un plan razonable pero genérico. Codex lo auditó y el primer comentario fue "el mensaje es demasiado vago para evaluarlo; ¿cuál es el criterio de éxito?" Esa es una característica, no un error. La herramienta de entrada de usuario opcional que se incluye con Claudeex está específicamente ahí para estos momentos: cuando un mensaje es demasiado vago para planificar, detiene el ciclo y le hace preguntas aclaratorias antes de continuar. Aprendí a liderar con /plan más un párrafo de contexto y un scope.md fijado, y la calidad de cada ronda posterior mejoró notablemente.

Cómo se ven realmente Bash y YAML

El lanzador es lo suficientemente pequeño como para leer de un extremo a otro. Aquí está su forma, con el ruido cortado:

#!/usr/bin/env bash
set -euo pipefail

PROMPT="$1"
ROUNDS="${2:-3}"
STATE_FILE=".claudeex/state.yaml"

mkdir -p .claudeex

cat > "$STATE_FILE" <<EOF
prompt: |
  $PROMPT
rounds_total: $ROUNDS
rounds_completed: 0
phase: drafting
context_files:
  - scope.md
  - architecture.md
EOF

claude --hook-config .claudeex/hooks.json \
       --slash-command "/plan $PROMPT"

Ese es todo el punto de entrada. Todo lo demás reside en la configuración del enlace y en el archivo de estado. La configuración del gancho registra un gancho de parada apuntado a un pequeño script de shell:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": ".claudeex/audit.sh"
          }
        ]
      }
    ]
  }
}

Y audit.sh es el puente hacia Codex. El script lee el estado de YAML, verifica la fase actual y el recuento de rondas, y decide si invocar Codex o dejar que Claude finalice:

#!/usr/bin/env bash
set -euo pipefail

STATE_FILE=".claudeex/state.yaml"
ROUNDS_TOTAL=$(yq '.rounds_total' "$STATE_FILE")
ROUNDS_DONE=$(yq '.rounds_completed' "$STATE_FILE")
PHASE=$(yq '.phase' "$STATE_FILE")

if [ "$PHASE" = "drafting" ] && [ "$ROUNDS_DONE" -lt "$ROUNDS_TOTAL" ]; then
  PLAN=$(cat .claudeex/plan-current.md)
  CRITIQUE=$(codex exec "Audit this plan for correctness, missing edge cases, race conditions, and broken dependencies. Be specific. Cite line numbers." --input "$PLAN")

  echo "$CRITIQUE" > .claudeex/critique-round-$((ROUNDS_DONE + 1)).md
  yq -i ".rounds_completed = $((ROUNDS_DONE + 1))" "$STATE_FILE"

  # Exit 2 forces Claude Code to keep working with the critique injected
  cat <<EOF >&2
Round $((ROUNDS_DONE + 1)) audit from Codex:

$CRITIQUE

Please revise the plan addressing each point.
EOF
  exit 2
fi

exit 0

El patrón de salida 2 hace todo el trabajo pesado. Como describe la referencia de ganchos Claude Code, un gancho de parada que sale con estado 2 obliga a Claude a continuar trabajando, con la salida stderr del gancho inyectada nuevamente en la conversación. Claudeex usa eso para transmitir la crítica de Codex a Claude como si fuera un nuevo turno, y Claude responde revisando el plan vigente.

Vale la pena decirlo: esto es cinta adhesiva, pero es buena cinta adhesiva. El sistema de gancho no fue diseñado para bucles adversarios de modelos cruzados. Fue diseñado para cosas como "formato automático al editar" o "bloquear comandos peligrosos". El hecho de que pueda reutilizarse para algo tan elaborado es un pequeño testimonio de lo bien que se eligieron los primitivos.

La demostración que construí para realizar una prueba de estrés

Necesitaba un caso de prueba real, así que elegí algo que realmente tenía intención de ofrecer: una herramienta de análisis de visitantes de una sola página que rastrea las interacciones en mi sitio sin enviar datos a ningún servicio de terceros. Sin Google Analytics, sin Plausible, sin Fathom. Solo mi propio backend que recostack clics, desplazamientos y tiempo en la página de mis propios visitantes.

La razón por la que este es un buen caso de prueba de Claudeex es que se encuentra en una intersección incómoda entre la instrumentación frontend, el almacenamiento backend y la ley de privacidad. Hay al menos cuatro formas de equivocarse, y la mayoría de esas formas son errores de planificación, no errores de codificación. Puede escribir JavaScript correctamente y aun así enviar algo ilegal en GDPR. Puede diseñar el esquema de la base de datos correctamente y aun así crear un sistema que bloquee la página en redes lentas. Los errores se esconden antes del código.

Fijé dos archivos de contexto: scope.md (requisitos funcionales, incluida la regla de "no terceros" y una lista de eventos para rastrear) y architecture.md (un boceto de la stack: backend de Laravel, frontend JS básico, MySQL para almacenamiento, Redis para almacenar en búfer eventos de alta frecuencia). Luego corrí:

/plan Build a visitor interaction tracking page following scope.md and architecture.md. Plan should cover schema, frontend instrumentation, backend ingestion, and the consent flow.

Aproximadamente entre 15 y 20 minutos de iteración después, tenía un plan que realmente enviaría. La primera ronda produjo un primer borrador razonable que ignoró por completo el flujo de consentimiento: Claude trató a GDPR como una nota a pie de página en lugar de un requisito de activación. La crítica de la primera ronda de Codex comenzó con "el flujo de consentimiento falta por completo; sin él, ningún evento debería activarse", que es exactamente el tipo de cosas que me habrían molestado en producción. La segunda ronda agregó la puerta de consentimiento, pero introdujo un problema diferente: tenía los eventos del búfer de interfaz en localStorage antes de que se otorgara el consentimiento, lo que en sí mismo es una violación de GDPR en algunas interpretaciones. Codex captó eso en la segunda ronda. La tercera ronda tuvo una versión limpia en la que el frontend no almacena nada hasta que se da el consentimiento y luego envía una cola de eventos registrados con intención al backend.

La vista diferente al final fue la parte que más me sorprendió. Claudeex muestra el plan con las eliminaciones tachadas en rojo y las adiciones resaltadas en verde, ronda por ronda. Puede ver exactamente qué detectó la auditoría y dónde se fortaleció el plan. Es lo más parecido que he visto a una experiencia de revisión de código para planes en lugar de código.

Claudeex frente a Claude Code solo

Aquí está la comparación a la que sigo volviendo. Después de dos semanas de ejecutar ambos (a veces el mismo mensaje en ambos, a veces alternando según la complejidad del proyecto), las diferencias se clasifican en un patrón claro.

funciones de iones, trabajos sensibles a la seguridad, cualquier cosa que toque datos |

El costo simbólico es real y vale la pena ser honesto al respecto. Tres rondas de planificación Claude más tres rondas de auditoría Codex no son gratuitas. Para un guión rápido o un prototipo, los gastos generales no valen la pena: simplemente puede ejecutar un plan, escanearlo usted mismo y enviarlo. Para cualquier cosa en la que un error de planificación le cueste más de 30 minutos de depuración, Claudeex se amortiza solo en el primer guardado.

El comportamiento de clarificación es el beneficio subestimado. La herramienta opcional de solicitud de comentarios del usuario convierte indicaciones vagas en conversaciones productivas en lugar de planes equivocados y confiados. En mi experiencia, alrededor de un tercio de las indicaciones que escribo son demasiado vagas para planificarlas, y Claudeex es la primera herramienta que he usado que detecta eso de manera consistente antes de generar un plan que malinterpreta con confianza lo que quería.

Si desea una comparación relacionada, el flujo de trabajo de dúo dinámico del complemento Claude Code y Codex es la versión manual de lo que automatiza Claudeex. La ruta del complemento es más flexible; Claudeex es más obstinado. Utilizo ambos, dependiendo del trabajo.

Donde Claudeex se queda corto

Quiero ser honesto acerca de esto porque de lo contrario el artículo sería inútil.

Es frágil en contextos largos. Cuando el plan y la transcripción de la auditoría son lo suficientemente largos (más de 30.000 tokens combinados), Claude comienza a perder la pista de en qué ronda se encuentra y, a veces, regenera secciones enteras que Codex ya aprobó. Este es un problema de gestión de contexto, no un error Claudeex per se. Pero es la costura donde se ve la cinta adhesiva.

El archivo de estado YAML no es excelente para el trabajo paralelo. Si intenta ejecutar dos sesiones Claudeex en el mismo repositorio al mismo tiempo, pisotearán los archivos de estado de cada uno. No hay aislamiento por sesión de forma predeterminada. Lo solucioné creando subdirectorios por función, pero es un verdadero problema.

Codex a veces alucina dependencias. Esto sucede aproximadamente en una ronda de cada diez. Codex criticará un plan por "faltar la configuración de Redis Streams" cuando el plan en realidad no necesita Redis Streams. Claude, dada esa crítica, agregará de manera útil la configuración de Redis Streams. Termina con un plan que es más complejo de lo necesario, con una infraestructura introducida por una alucinación de auditoría. La solución es leer tú mismo las diferencias de cada ronda y rechazar los cambios que no coincidan con la realidad. Lo que significa que Claudeex en realidad no elimina al humano del circuito, simplemente facilita el trabajo del humano.

No es mágico para trabajos totalmente nuevos. Cuando no tienes un scope.md o un architecture.md para fijar, las primeras rondas del ciclo pasan muchos ciclos discutiendo sobre el alcance. Claudeex funciona mejor cuando ya ha pensado estratégicamente y desea ayuda con la planificación táctica. Si todavía estás averiguando qué construir, el bucle no te ayudará a decidir. Simplemente seguirá perfeccionando un plan para lo incorrecto.

La asimetría del modelo puede cambiar. Codex es bueno en auditorías la mayor parte del tiempo. Pero cuando el tema se desvía hacia las áreas más fuertes de Claude, cualquier cosa que tenga que ver con herramientas específicas de Anthropic, flujos de trabajo agentes o el propio sistema de enlaces de Claude Code, por ejemplo, el borrador de Claude a veces es mejor que la auditoría de Codex. En esos casos, el bucle añade ruido en lugar de señal. Aprende a reconocer cuándo se encuentra en una de esas zonas y simplemente ejecuta /plan una vez sin el paso de auditoría, o usa /review con un umbral de tercera ronda más largo.

Más allá del código: ¿dónde más funciona este patrón?

Lo que realmente me sorprendió es lo bien que el patrón se extiende más allá del código. He estado probando Claudeex en tareas de planificación sin código durante la última semana y los resultados son lo suficientemente interesantes como para mencionarlos.

Lo ejecuté en un esquema de diapositivas para un taller que impartiré en mayo. El primer borrador de Claude fue sólido: un flujo lógico, desgloses de secciones decentes y estimaciones de tiempo razonables. La auditoría de Codex señaló que el taller no tenía ejercicios en el tercio medio, lo que significaría 40 minutos de conversación directa después del pico de energía alrededor del minuto 25. No me había dado cuenta. Lo habría visto en el ensayo, pero el ensayo habría tenido lugar la noche anterior. Claudeex lo captó antes de que perdiera el tiempo de preparación.

Lo ejecuté en una especificación de función para un cliente independiente, no en el código, solo en el documento de descripción de la función que figuraba en la propuesta. Pasó la primera ronda. En la segunda ronda, Codex señaló que el documento describía el camino feliz pero nunca mencionó lo que sucede cuando el API de terceros no funciona. El cliente aprobó una versión 3 que incluía un elegante párrafo de degradación. Ese párrafo ahora es contractualmente parte de lo que les debo.

Todavía no lo he probado en modelos de Excel o documentos financieros, pero no veo ninguna razón para que no funcione. El patrón es genérico: en cualquier lugar donde pueda escribir un plan en rebajas y pedirle a otro modelo que lo audite, se aplica el bucle. Aquí también es donde veo que converge con el patrón más amplio que cubrí en Modo ultra plan de Claude Code: ambos tratan de formalizar el paso de planificación en lugar de tratarlo como un preámbulo de codificación impulsado por vibraciones.

Configuración, costo real y en qué ejecutarlo

Ponerlo en funcionamiento lleva unos diez minutos si su entorno ya está configurado.

Requisitos previos:

• Claude Code instalado e iniciado sesión
• CLI Codex instalada (npm i -g @openai/codex o brew install --cask codex) e iniciada sesión
• yq instalado (brew install yq en macOS)
• Un repositorio donde quieras ejecutarlo.

Instalar:

git clone <claudeex-repo-url> .claudeex
chmod +x .claudeex/*.sh

Primera ejecución:

.claudeex/run.sh "build a visitor analytics page following scope.md"

La primera vez, espere entre 15 y 20 minutos para un plan moderadamente complejo. La CLI Codex utilizará cualquier modelo al que tenga acceso su cuenta: GPT-5.5 si tiene la última versión, GPT-5.4 si no. Ambos funcionan bien para una crítica de estilo auditoría; GPT-5.5 es significativamente más preciso a la hora de detectar problemas sutiles.

En cuanto a costos, un ciclo de tres rondas en un plan moderadamente complejo me cuesta entre tres y cuatro veces el costo de un solo turno de planificación Claude Code. Para el trabajo independiente y para clientes, eso es un error de redondeo. Para experimentos personales, es posible que desee ejecutarlo solo en los problemas más difíciles y dejar que /plan (sin el bucle) se encargue de las cosas pequeñas.

En qué ejecutarlo primero: cualquier función en la que un error de planificación le costaría más de medio día de retrabajo. Flujos de autenticación. Integraciones de pagos. Migraciones de datos. Cualquier cosa con concurrencia. Cualquier cosa que toque GDPR o HIPAA. Estas son las áreas donde 15 minutos de auditoría automatizada se amortizan diez veces. Si está realizando un trabajo adyacente a la seguridad, se aplica la misma lógica, y el patrón de agente de escáner de seguridad en Claude Code se empareja naturalmente con Claudeex en el lado de la planificación.

Sáltelo para: correcciones de errores en los que el error ya está aislado, pequeños ajustes en la interfaz de usuario, cualquier cosa que haya hecho antes y para la que pueda escribir el plan mientras duerme. Los gastos generales no valen la pena en esos.

Preguntas frecuentes

¿Qué es Claudeex y cómo funciona?

Claudeex es un ciclo de planificación iterativo en el que Claude Code redacta un plan, la CLI OpenAI Codex lo audita y Claude Code lo revisa, repitiendo durante un número configurable de rondas (tres de forma predeterminada). Utiliza un gancho de parada Claude Code con código de salida 2 para inyectar la crítica de Codex nuevamente en la conversación como si fuera un nuevo turno. Para obtener un tutorial completo de la implementación de bash y YAML, consulte la sección anterior sobre el iniciador y el script de auditoría.

¿Cuántas rondas necesita Claudeex para detectar la mayoría de los errores de planificación?

Dos o tres rondas detectan aproximadamente el 80% de los errores de planificación en mis pruebas. La cuarta ronda y las posteriores producen rendimientos decrecientes y a menudo sacan a la luz preferencias estilísticas en lugar de problemas reales. El valor predeterminado de tres rondas está bien ajustado. Consulte la tabla comparativa anterior para conocer el contexto completo sobre el tiempo y el costo del token.

¿Claudeex funciona para tareas de planificación sin código?

Sí. El patrón funciona para cualquier plan escrito en rebajas que otro modelo pueda auditar: esquemas de diapositivas, especificaciones de funciones, propuestas de proyectos. Lo probé en plataformas de taller y en especificaciones de clientes independientes con buenos resultados. La sección "Más allá del código" anterior muestra ejemplos específicos.

¿Cuál es la diferencia entre /plan y /review en Claudeex?

/plan ejecuta el ciclo iterativo completo: borrador, auditoría, revisión, repetición. /review es de solo lectura: ejecuta Codex sobre un plan existente una vez y devuelve los comentarios de auditoría sin ningún paso de revisión. Utilice /review cuando desee una segunda opinión sobre un plan que usted o un compañero de equipo ya hayan escrito.

¿Vale la pena el costo adicional del token por Claudeex?

Para funciones de producción, trabajos sensibles a la seguridad o cualquier cosa en la que un error de planificación costaría más de 30 minutos de depuración, sí. El costo del token de 2,5 a 3 se amortiza solo la primera vez que detecta una condición de carrera. Para prototipos, guiones desechables o trabajos que haya realizado muchas veces antes, los gastos generales no se justifican.

Lo que me llevé

La mañana después de mi primera ejecución real de Claudeex, volví y miré tres planes que había enviado el mes anterior, planes con los que estaba contento en ese momento. Pasé cada uno de ellos por /review para ver qué habría captado Codex.

Los tres tenían al menos un problema. Dos tenían condiciones de carrera que me había perdido. A uno le faltaba una ruta de reversión en una migración destructiva que, para ser justos, habría quedado atrapada en la revisión del código, pero solo si el revisor hubiera prestado mucha atención. Ninguno de ellos fue catastrófico. Los tres habrían sido menos vergonzosos si la auditoría se hubiera realizado antes de mi envío en lugar de dos semanas después, en retrospectiva.

Esa es la parte que me atrapó. No la demostración. No la vista diferente. Darme cuenta de que había estado enviando planes de calidad media y que los había dado por terminados porque nada en mi flujo de trabajo los rechazaba. Claude Code no retrocede. No retrocedo, porque escribí el mensaje y estoy a favor de que el plan sea bueno. Lo único en este bucle que no tiene ningún aspecto en el juego es Codex.

El modelo al que no le importa si su plan es bueno es el modelo que usted quiere auditarlo.

El plan que casi envié antes de instalar Claudeex, el que tenía la condición de carrera integrada en el paso cuatro, me habría superado. Habría superado Claude. No habría superado Codex, porque Codex no lo escribió y no tenía motivos para defenderlo. Ésa es la asimetría que el bucle está explotando, y esa es la asimetría que hace que valga la pena ejecutarlo.

Esta noche, antes de enviar el siguiente plan que está a punto de enviar, ejecútelo en un segundo modelo. Si tienes Codex instalado, hazlo manualmente. Si lo desea automatizado, instale Claudeex. De cualquier manera, deje que algo a quien no le importe su plan le diga qué tiene de malo. No te arrepentirás de los diez minutos.

Trabajemos juntos

¿Quiere crear sistemas AI, automatizar flujos de trabajo o ampliar su infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (comstackciones e integraciones personalizadas): fiverr.com/s/EgxYmWD
• Cartera: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y marca): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io