Claude Code o Codex, ¿al final cuál? La solución real para combinarlos sin accidentes

“Entonces, ¿al final cuál uso?”

Claude Code y Codex de OpenAI. Cuanto más has tocado los dos, más te ronda esta pregunta. A mí, al principio, también me daba por pensar que “tengo que decidirme por uno”.

Pero tras medio año usándolos, la respuesta resultó ser de lo más sosa. No es uno u otro. Uso los dos. Eso sí, repartiendo qué le delego a cada uno. Solo eso.

El problema no es “cuál es más listo”. Es lo mismo que no comparar si es mejor el cuchillo o las tijeras. Para verdura, cuchillo; para papel, tijeras. Cada herramienta tiene su forma fuerte, y si te equivocas, te cortas el dedo. Hoy va de eso: de “a cuál le das qué trabajo” y de cómo colocarlos para correr los dos a la vez sin accidentes.

No vengo a meter caña. Tampoco a sacar una conclusión del tipo “este es superior”. Voy a poner, con honestidad, las minas que pisé de verdad llevando este sitio.

Primero, la diferencia de carácter de los dos

Dejemos la comparación de inteligencia a un lado y hablemos de carácter.

Claude Code es el compañero que se sienta a tu lado y te ayuda a recoger tu cuarto desordenado. Abre tu repositorio, lee las reglas que escribiste en CLAUDE.md y va arreglando de forma conversada, encadenando contexto: “si tocas esto, ya de paso esto otro”. Se le da bien captar las circunstancias del código que ya hay. Por eso es fuerte en refactorizar proyectos existentes y en ajustes finos en local.

Codex se parece más a un proveedor externo que está en otra sala y avanza solo el trabajo que le encargas. Le sueltas la tarea y la ejecuta del lado de la nube, o te lanza un Pull Request para que entre a revisión; ese estilo de delegación le va bien. OpenAI también presenta Codex como un compañero al que puedes encargarle trabajo de código (OpenAI: Introducing Codex). Lo suyo es soltar las manos y delegar.

Dicho a lo bruto: Claude Code es “a tu lado, juntos”; Codex es “se lo dejas y esperas”. Si te quedas con esa diferencia de temperatura, el cuándo usar cada uno te entra solo.

Eso sí, los nombres de modelo, los precios y la frontera de “qué puede hacer cada uno” que escribo aquí cambian bastante rápido. Los dos se actualizan a toda velocidad. Así que los puntos fuertes, los flacos y los precios finales, confírmalos siempre en la fuente oficial (documentación de OpenAI y documentación de Claude Code). Tómate este artículo como “un mapa de cómo pensarlo”.

¿Qué trabajo le das a cuál?

Solo con el mapa cuesta usarlo, así que pongo mi reparto real. Es solo mi sensación a día de hoy, no la verdad absoluta.

Lo que quieres hacer	Encargado principal	Por qué
Refactorizar algo enrevesado en un repo existente	Claude Code	Lee el contexto de alrededor y evita arrastrar daños colaterales
Diseñar y ajustar conversando en local	Claude Code	El ida y vuelta de “mejor hazlo así” es rápido
Delegar una tarea independiente y bien acotable	Codex	La sueltas y te pones con otra cosa
Crear un PR y meterlo a revisión	Codex	Encaja en el flujo de delegar + revisar
Cumplir reglas propias del proyecto	Claude Code	Lee CLAUDE.md y lo aplica fácil
Llevar varias tareas en paralelo	Los dos	A uno le conversas, al otro le delegas, y no te atascas

La clave está en la última fila. No es elegir uno; es repartir papeles. Yo acabé en el estilo de dos espadas: aprieto el diseño delante de la pantalla con Claude Code mientras le suelto a Codex el trabajo soso ya recortado para que avance en la otra sala.

Y aquí viene el meollo. Uses el que uses, la forma de pensar el dispositivo de seguridad es la misma. En vez de elegir la IA más lista, monta primero la colocación en la que, si te caes, no te haces daño. A esto yo lo llamo “harness (arnés) = el andamio y el cabo de vida de la IA”. Si quieres entender el concepto, pásate por la guía completa de harness engineering.

El andamio se ordena fácil si lo piensas en cuatro capas. No tiene misterio.

Tu encargo
  ↓
IA (Claude Code / Codex)
  ↓
[1] Capa de permisos    qué le dejas hacer y qué le frenas
[2] Capa de procedimiento  en qué orden lo hace
[3] Capa de verificación   con qué compruebas el "OK" al terminar
[4] Capa de recuperación   cómo revierte si falla
  ↓
Archivos / shell / servicios externos / despliegue

Si te faltan estas cuatro, tanto Claude Code como Codex se caen, más o menos, en el mismo sitio.

Dónde se nota de verdad “combinar” (tres casos)

1. El diseño con Claude Code, la producción en serie con Codex

Un trabajo que necesita “ir y volver”, como el diseño de datos de una función nueva, lo aprieto delante de la pantalla con Claude Code. Y la tarea simple de después —“otros 8 archivos con la misma forma”— la recorto y se la suelto a Codex. El tiempo de usar la cabeza y el tiempo de solo esperar quedaron limpiamente separados.

2. El cuerpo con Claude Code, la revisión con Codex

A veces te apetece que otro par de ojos mire el código que escribiste con Claude Code. Ahí le paso la revisión del PR a Codex. Como no es la misma IA la que escribe y la que revisa, el punto de vista se desplaza y salen más observaciones. No está mal como “primer filtro” antes de la revisión humana.

3. Las operaciones peligrosas, las pulsa siempre el humano al final, use el que use

Esto es lo más importante. Despliegue, actualizar la base de datos de producción, enviar correos, git push, npm publish. Solo este tipo de “operaciones sin marcha atrás” las dejo, tanto en Claude Code como en Codex, con el humano pulsando el botón al final. Generar o hacer borradores, automático, vale. Pero las operaciones que salen al exterior, frenadas. Si lo obligas desde el lado del andamio, no hay accidentes de madrugada.

La línea de los permisos, si la tienes en un archivo así, no dudas. En Claude Code lo escribes en .claude/settings.json.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

El truco es no escribir las prohibiciones “por si suena peligroso”. rm -rf, git reset --hard, leer .env, el despliegue a producción. Con el nombre concreto del comando. Cómo armarlo en detalle lo tienes de entrada en Claude Code settings. La parte práctica de Approval / Sandbox la recogí en la guía de configuración de Approval / Sandbox.

Del lado de Codex hay la misma idea. Con sandbox (un espacio de trabajo aislado) y aprobación (approval) separas “hasta aquí puedes a tu aire, a partir de aquí pregúntale al humano”. El nombre de los ajustes cambia, pero lo que quieres conseguir es lo mismo. Una vez que interiorizas la forma de pensar del harness, aunque cambie la herramienta, sabes aplicarlo.

Tres metidas de pata que cometí yo

Lo escribo sin maquillar. Combinarlos, al principio, fue bastante accidentado.

La primera. Le encargué el mismo trabajo a los dos y se montó una guerra de reescrituras. Un archivo que estaba arreglando con Claude Code se lo solté también a Codex con un “arregla esto aquí”. Como era de esperar, el cambio de uno sobrescribía al del otro y ya no sabía qué era lo correcto. Ahora reparto el alcance: “este archivo lo lleva ahora Claude Code”. No usar la misma tabla de cortar dos personas a la vez. Es de cajón, ya lo sé.

La segunda. La tarea que le pasaba a Codex era demasiado ambigua. Si le sueltas al lado de la delegación un encargo dependiente del contexto tipo “arréglalo bonito”, no sale nada decente. La delegación es como un encargo externo, así que la regla de oro era trocearlo en algo que se complete por sí solo antes de pasarlo. Al revés, el trabajo que necesita contexto, no lo fuerces a delegación: avanza conversando con Claude Code. La forma del encargo decide la elección de herramienta.

La tercera. Tiré de “ya lo reviso yo luego” y se rompió el día de prisas. Hubo veces en que la URL pública seguía en 404, o la etiqueta de anuncios había desaparecido, y avancé sin darme cuenta. La revisión a ojo, cuando vas con prisa, te la saltas seguro. Por eso, lo que una máquina puede comprobar, que lo compruebe la máquina. Por ejemplo, me puse a golpear con un script pequeño así si la página publicada seguía viva.

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Uso: node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`La página devolvió ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["main content", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`Falta ${name} en ${url}`);
  }
}

console.log(`OK: ${url}`);

No es una verificación perfecta. Pero los accidentes tontos del tipo “creía que estaba publicado y daba 404” o “había desaparecido una etiqueta importante”, esos los frena. La IA tiende a mirar solo la última línea del log de error y a arreglar algo que no era, así que decidir de antemano en código qué cuenta como OK funciona de maravilla.

Si vas a empezar, empieza por aquí

No montes de entrada el doble espada totalmente automático. Hay un orden.

Primero, reparte un trabajo de hoy entre el lado que usa la cabeza y el lado que puede esperar. La parte que exige criterio, conversando con Claude Code. La tarea simple ya recortada, delegada a Codex. Solo con esto cambia la velocidad que percibes.

Después, vuelca todas las operaciones peligrosas a “pregúntale al humano (ask)”. Despliegue, push, envío, base de datos de producción: al principio, sin discusión, a esperar aprobación. Solo lo que confirmes que es seguro, lo asciendes después a automático. Ampliar puedes después. Al principio, estrecho.

Y ten a mano una plantilla de encargo que puedas pasar tal cual y no te despistas cada vez. Esta es mi plantilla para delegar a Codex. Copias, pegas y rellenas el contenido.

# Tarea (en una unidad que se complete por sí sola)
<ej.: añadir tests unitarios a las funciones de formato de fecha bajo src/utils/>

# Alcance que puedes tocar
- Tocar: <ej.: solo src/utils/date.ts y tests/date.test.ts>
- No tocar: <ej.: el resto de archivos. No leas configuraciones ni .env>

# Condición de finalización (esto es lo que cuenta como OK)
- npm run test pasa entero
- No cambies la firma de las funciones existentes
- Mantén el diff al mínimo salvo los archivos nuevos

# Lo que no puedes hacer
- No hacer git push (hasta presentar PR/diff)
- No añadir paquetes de dependencias por tu cuenta
- Ninguna operación de producción, despliegue ni envío

El truco es dejar por escrito el “alcance que no tocar” y el “lo que no puedes hacer”. La IA del lado de la delegación a veces se pasa de lista y toca sitios de más, así que la cercas desde el principio. Esto además sirve de defensa contra el accidente de confundir las instrucciones de un documento externo con órdenes de trabajo (Prompt Injection). Cómo evitar este tipo de encargos peligrosos lo escribí en detalle en comprobación práctica para evitar prompts peligrosos.

Lo que pasó cuando lo probé de verdad

Esta es mi conclusión tras medio año combinando los dos en este sitio.

Donde el efecto fue mayor, sorprendentemente, no fue en las “reglas de prohibición”, sino en “la frontera que dejas en ask”. Borradores de artículos, traducciones, propuestas de refactor: tanto con Claude Code como con Codex se pueden automatizar sin que pase gran cosa. Pero el despliegue, el git push, el envío de correos y la actualización de la URL de producción, esos sí dejan la confirmación humana. Con solo defender a muerte ese punto, las veces que me daba el vuelco en el estómago cayeron en picado.

Y al revés, lo que fue un fracaso clarísimo: el método de meter todos los pasos en un prompt larguísimo. Por avaricioso, de querer que lo hiciera todo de una tacada, la sesión se ponía pesada y tendía a pararse a medias. Mejor instrucciones cortas, y las reglas de ejecución muévelas al lado del andamio (settings o línea de aprobación). Este camino es muchísimo más reproducible.

Y la sensación de usar cada uno para lo suyo. Soltar el “me decido por uno” fue lo que más me sirvió. Como llevar a la vez el cuchillo y las tijeras, muevo a Claude Code a mi lado y a Codex en la otra sala al mismo tiempo. La sensación de que, con un solo cerebro, el trabajo avanza al doble, una vez la pruebas, ya no hay vuelta atrás. Pero, insisto, los puntos fuertes, los precios y los modelos de ambos se actualizan rápido, así que antes de invertir en serio, confirma lo último en la fuente oficial.

En resumen

Mi respuesta a “Claude Code o Codex, ¿cuál?” es: “los dos. Eso sí, repartiendo el trabajo que delegas y la operación que frenas”.

• Si arreglas a su lado, Claude Code; si lo dejas y esperas, Codex
• El trabajo que necesita contexto, conversando; el que se puede recortar, delegado
• Uses el que uses, la forma de pensar el dispositivo de seguridad (permisos, procedimiento, verificación, recuperación) es la misma
• Las operaciones peligrosas (despliegue, envío, base de datos de producción), al final las pulsa el humano

Cambia el tiempo que pierdes dudando qué herramienta elegir por el tiempo de montar un andamio. La calidad del trabajo la decide, más que cuál IA es más lista, la colocación que tiene por fuera.

Si quieres dejar afinados también el diseño de permisos, la CI y las reglas de operación del equipo, en el listado de materiales tengo plantillas listas para usar. Y cuando quieras acompañamiento adaptado al repositorio de tu empresa, escríbeme desde formación y consultas.