Probando dev-orchestra con Codex

Introducción

La vez anterior usé dev-orchestra en un entorno solo con Claude Code. Esta vez lo instalo en Codex.

Voy al grano: funciona solo con Codex. Pero mi mayor recomendación es instalar tanto Claude Code como Codex. Así obtienes automáticamente una configuración en la que IAs de empresas distintas revisan tu código.

Para saber qué hace dev-orchestra, mira el artículo de presentación.

dev-orchestra está publicado en GitHub (licencia MIT). Si te parece útil, me alegraría mucho que le dieras una estrella.

→ github.com/istb16/dev-orchestra

Requisitos

Elemento	Notas
Codex CLI	Con la sesión ya iniciada
Python 3.11 o superior	Funciona solo con la biblioteca estándar
git	Se usa para obtener el diff que se revisa

No hace falta ninguna clave de API. Usa directamente el inicio de sesión de Codex.

Pasos

1. Instálalo

Dos líneas en la terminal.

codex plugin marketplace add istb16/dev-orchestra
codex plugin add dev-orchestra@dev-orchestra

Puedes comprobar que está instalado con codex plugin list.

2. Elige un preset la primera vez

El comienzo es igual que con Claude Code. La primera vez que haces una petición que usa dev-orchestra, te pregunta por el preset. Si dudas, elige standard. Qué contiene cada preset lo explicaré en detalle en la segunda mitad de esta serie.

3. Mira la configuración solo con Codex

En una máquina sin Claude Code, al elegir standard obtuve esta configuración (extracto de config show en dev-orchestra 1.0.0).

Preset: standard (implicit; fitted to codex)
  note: claude not found on PATH: reviewer seat 2 (general) was not added; it would repeat codex-general
  note: claude not found on PATH: reviewer seat 4 (test) was not added; codex has no cheap model named offline

  Architect
    codex / recommended-coding / latest
  Implementer
    codex / recommended-coding / latest
  Reviews
    1. codex / recommended-coding / latest / general / codex-general
    2. codex / recommended-coding / latest / security / codex-security

El diseño, la implementación y la revisión se asignan todos a Codex.

Hay una diferencia respecto a la configuración solo con Claude Code: hay 2 revisores en lugar de 4.

El segundo puesto general sería exactamente el mismo Codex que el primero, así que no se añade
El puesto test es para un “modelo barato”, y Codex no tiene ningún modelo barato que se pueda indicar por nombre, así que no se añade

Poner la misma IA dos veces en el mismo rol no tiene sentido, así que no crea puestos inútiles desde el principio.

4. Añade Claude Code para obtener la configuración recomendada

Esta es la forma de uso que recomiendo. Si en la misma máquina también está instalado Claude Code, la configuración cambia así.

Preset: standard (implicit; fitted to claude, codex)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. codex / recommended-coding / latest / general / codex-general
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

El segundo revisor ahora es Codex.

Claude implementa, y tanto Claude como Codex revisan
Las IAs de empresas distintas tienen también prejuicios distintos. Donde las opiniones sobre el mismo diff no coinciden es donde están los bugs de verdad

Sin tocar ningún ajuste, adopta esta forma automáticamente según las CLI instaladas.

Si quieres que Codex se encargue del diseño o de la implementación, puedes cambiar la IA de cada rol. Cómo reorganizarlos lo explicaré en la segunda mitad de esta serie.

5. Comprueba que todo está listo

Pídele al agente “Ejecuta el doctor de dev-orchestra”. La parte de Codex salió así (extracto).

Codex CLI (codex)
  Installed: yes
  Model selection: supported
  Read-only runs: enforced by -s read-only (CLI sandbox); filesystem writes are blocked by the sandbox (measured); MCP servers were not examined, so external side effects are not covered

Los roles de diseño y revisión se ejecutan en el sandbox de solo lectura de Codex. El sandbox bloquea la escritura de archivos. Eso sí, indica con honestidad que no se examinaron los servidores MCP (también lo menciono en la tabla de abajo).

Si al final aparece No problems found., ya está todo listo.

6. Haz una petición en una frase

A partir de aquí es igual que con Claude Code: basta con hablarle como siempre.

Implementa este issue con el flujo de trabajo configurado

El flujo, desde que pregunta si apruebas el plan hasta el informe final, es el que describí en el artículo anterior.

Al ejecutar varios revisores se gastan más tokens que con una sola IA. Te recomiendo empezar con peticiones pequeñas.

Funciones y limitaciones solo de Codex

Cosas útiles de saber al usarlo con Codex (a fecha de dev-orchestra 1.0.0; para más detalles, consulta providers.md).

	Detalles
Ventaja: el solo lectura lo impone el sandbox	El diseño y la revisión se ejecutan con `-s read-only`, que también bloquea las escrituras desde el shell
Ventaja: usa tal cual el modelo “recomendado”	El valor por defecto es `recommended-coding`. Otros modelos solo se pueden indicar si aparecen en `dev-orchestra model list`
Ventaja: se puede retomar desde un diseño anterior	Puede continuar la conversación de diseño anterior, siempre en solo lectura (en las versiones de Codex verificadas)
Precaución: no se examinan los servidores MCP ni los hooks	dev-orchestra no garantiza que no haya efectos externos a través de herramientas MCP como Slack
Precaución: puede leer fuera del directorio de trabajo	A diferencia de Claude, la lectura no está confinada. Puede leer archivos secretos como `.env` dentro o fuera del repositorio, y lo que lee se envía a OpenAI
Precaución: solo 2 revisores con Codex solo (en `standard`)	Porque no crea el puesto que duplicaría a Codex ni el puesto del modelo barato. `quality` da 4 y `fast` normalmente 1 (+1 en cambios arriesgados)
Precaución: no se puede retomar el diseño con un `model_provider` propio	Si usas un proveedor propio en `config.toml`, la reanudación falla y se ejecuta de nuevo desde cero
Precaución: los ajustes de sandbox del implementador vienen de la configuración global	Si pones `sandbox` / `approve` en el archivo de configuración del proyecto, se rechazan las ejecuciones de implementación

Para estar tranquilo, deja los archivos secretos donde los revisores no puedan alcanzarlos. Para el código que de ningún modo debe salir de tu máquina, también puedes revisarlo con un LLM local (lo menciono en el artículo de presentación).

Al actualizar el plugin, codex plugin marketplace upgrade por sí solo no instala la nueva versión. Ejecuta después codex plugin add dev-orchestra@dev-orchestra.

Resumen

Instalarlo en Codex también son dos líneas. No hace falta clave de API
Funciona solo con Codex. El diseño, la implementación y la revisión van todos a Codex, con 2 revisores (en standard)
Añade Claude Code para la configuración recomendada. Revisan tanto Claude como Codex, así que IAs de empresas distintas revisan de forma independiente
El diseño y la revisión se ejecutan en el sandbox de solo lectura de Codex. Eso sí, no se examinan MCP ni los hooks
Al actualizar, ejecuta plugin add otra vez después de marketplace upgrade

Para un uso más detallado, consulta el README. La próxima vez lo probaré con Antigravity.

Para saber cómo actualizar cuando sale una versión nueva, mira Actualizar dev-orchestra.

Todos los artículos de esta serie están en la lista de artículos de “dev-orchestra”.

GitHub: istb16/dev-orchestra (una estrella siempre se agradece)