Referencias Oficiales: Review · Automations · Worktrees · How OpenAI uses Codex
Ruta del currículo
- Primeros Pasos con Codex — Instalación, Primera Tarea y Checkpoints — primeros loops seguros
- Instrucciones de Codex — Cómo Hacer que AGENTS.md Sirva de Verdad — reglas del repo y defaults
- Sandboxing en Codex — Permisos, Approvals y Entornos Cloud — permisos y límites
- Diseño de Tareas en Codex — Escribe Prompts Como Issues, No Como Deseos — dar buena forma al trabajo
- Skills de Codex — Convierte Prompts Repetidos en Workflows Reutilizables — convertir trabajo repetido en activos reutilizables
- Subagentes de Codex — Ejecución Paralela y Patrones de Delegación — ejecución paralela y delegación
- MCP en Codex — Conecta Contexto Externo en Vez de Copiarlo y Pegar — conectar sistemas externos
- Reviews y Automatizaciones con Codex — /review, Worktrees e Ingeniería Repetible — ejecutar workflows estables una y otra vez ← Estás aquí
- Codex Worktrees — Ejecución Paralela Aislada Sin Caos de Branches
- Handoffs en Codex — Convertir Lanes Paralelos en Resultados Listos para Merge
- Loops de Verificación en Codex — Demostrar que Funciona Antes del Merge
- Release Readiness en Codex — Gates Finales Antes de Producción
- Codex Loop Seguro del Primer Día — Flujo Inicial para Evitar Errores Tempranos
- Playbook de Entrega de Equipo en Codex — Operación Intermedia por Lanes
- Gobernanza de Cambios de Alto Riesgo en Codex — Controles Avanzados para Releases Críticas
- Manual Operativo de Codex — Ritmo Diario, Semanal y de Release para Equipos
- Playbook de Recuperación de Incidentes en Codex — Respuesta Determinista Bajo Presión
- Bucle de Hardening Post-Incidente en Codex — De la Recuperación a Controles Duraderos
- Simulacros de Resiliencia Caótica en Codex — Ensayar Fallos Antes de Recibirlos
- Métricas de Resiliencia y SLO en Codex — Medir Confiabilidad Antes del Fallo
- Loops de Persistencia Ralph en Codex — Llevar Tareas Largas a Cierre Verificado
Documentación oficial usada en esta guía
- Defaults del review pane y cambio de alcance — Review
- Tareas recurrentes con cadence y execution environment — Automations
- Trabajo paralelo sin choques mediante worktrees — Worktrees
- Best-of-N e ingeniería repetible — How OpenAI uses Codex
La palanca real aparece en el trabajo repetido
Una tarea exitosa con Codex sirve. Un workflow repetible con Codex vale mucho más.
Ahí es donde review loops, mantenimiento, sincronización de docs, refactors seguros y automatización acotada empiezan a multiplicar valor.
El patrón sano no es “darle más permisos”. Es hacer revisable el trabajo antes de convertirlo en costumbre.
Haz de /review un hábito operativo
Los docs oficiales de Review explican que el review pane refleja el estado Git del repo y, por defecto, se centra en uncommitted changes. Eso lo vuelve útil para el loop cotidiano porque muestra el diff local real. Además, puedes cambiar el alcance a:
- All branch changes — diff de la rama contra la base
- Last turn changes — solo el último turno del asistente
- Unstaged / Staged — cuando trabajas localmente y quieres revisar por estado del índice
Qué scope conviene en cada momento
uncommitted changes
Úsalo durante iteración local. Sirve para ver el estado total antes de decidir si sigues editando o limpias el diff.
last turn changes
Úsalo cuando quieres inspeccionar exactamente qué hizo Codex en la última respuesta. Es especialmente útil si estás afinando el prompt o verificando que respetó restricciones.
all branch changes
Úsalo para pensar como reviewer de PR. Es la vista correcta cuando quieres validar el cambio completo antes de stage, squash o merge.
unstaged / staged
Úsalo para separar exploración de decisión. Primero revisas sin comprometer; luego validas lo que ya elegiste stagear.
Un loop corto y fuerte de review
Un loop sano suele verse así:
- tarea con Goal / Context / Constraints / Done when
- implementación o edición
- verificación mecánica (
lint,build, tests relevantes) /reviewcon el scope adecuado- stage, revert o nueva iteración
La review no sustituye la verificación; convierte esa verificación en una decisión humana legible.
Qué cambios requieren la review humana más fuerte
La review humana es especialmente importante para:
- cambios de contrato de API
- schemas o migraciones
- auth, billing o lógica de seguridad
- copy y comportamiento user-facing
- renames o borrados grandes
- cambios que amplían permisos o automatización
Codex puede producir un draft rápido. El juicio irreversible sigue siendo humano.
Worktrees: aislamiento y paralelismo, no solo comodidad
La documentación de Worktrees describe que Codex puede trabajar en paralelo sobre Git worktrees dedicados. Eso importa por dos razones a la vez:
- aislamiento: reduces el blast radius sobre tu working tree principal
- paralelismo: puedes empujar varias tareas independientes sin que se pisen
Pensarlo así ayuda mucho:
- subagentes = pensar o explorar en paralelo
- worktrees = ejecutar cambios en paralelo con aislamiento Git
Cuándo un worktree aporta valor real
Un worktree suele merecer la pena cuando:
- quieres correr una tarea larga sin bloquear tu árbol principal
- estás comparando dos enfoques de implementación
- una automation necesita un entorno Git aislado
- el cambio merece una rama y un diff propios
- necesitas mantener limpio el working tree principal mientras sigues desarrollando otra cosa
Un worktree no es solo una feature de velocidad; también es una forma de control de riesgo.
Patrón práctico: una tarea, un worktree, una review clara
Un flujo robusto puede verse así:
- defines la tarea con forma de issue
- la ejecutas en un worktree dedicado
- corres validaciones en ese worktree
- abres
/reviewsobre el diff aislado - decides si promover, descartar o repetir
Eso te da velocidad sin mezclar experimentos, deuda accidental y trabajo listo para merge.
Automations solo después de estabilizar el workflow manual
La documentación de Automations describe ejecuciones recurrentes en background donde eliges project, prompt, cadence y execution environment. Eso es potente, pero no convierte un workflow borroso en uno confiable.
Regla simple:
Si todavía necesitas reescribir el prompt a mano cada vez, todavía no estás listo para automatizar.
Automatiza solo cuando ya tengas:
- una tarea estrecha y repetida
- entradas previsibles
- salida consistente
- verificación entendible
- una review humana clara al final
Los propios docs recomiendan revisar de cerca las primeras salidas y ajustar prompt o cadence antes de confiar en la rutina.
Buenos y malos candidatos para automation
Buenos candidatos
- resúmenes de commits recientes
- borradores de release notes
- chequeos de docs drift
- escaneos de bugs probables
- checks estáticos de bajo riesgo
- informes periódicos que luego verá un humano
Malos candidatos
- trabajo de producto con decisiones abiertas
- despliegues irreversibles
- cambios de seguridad sin revisión humana
- flujos con alto costo de error y poca señal mecánica
- tareas cuyo prompt todavía cambia radicalmente semana a semana
CI/CD con Codex: automatiza antes del punto de decisión humana
El patrón útil casi nunca es “dejar que Codex mergee solo”. Lo más valioso suele ser automatizar el trabajo repetido antes del punto donde una persona decide.
Ejemplos buenos:
- redactar una primera pasada de review de PR
- convertir un label de issue en un borrador de tarea
- generar un primer draft de updates grandes de docs
- detectar zonas candidatas a falta de tests
- abrir un resumen operativo para triage diario
El valor está menos en autonomía total y más en comprimir trabajo repetible previo a la decisión humana.
Mantén gates humanos donde el coste del error sea alto
En CI/CD, Codex encaja mejor como generador de artefactos revisables que como autoridad final. Mantén gates humanos, como mínimo, en:
- aprobación de PR
- cambios de contrato o esquema
- despliegues a producción
- modificaciones de permisos, secretos o seguridad
- cambios amplios de copy o comportamiento visible
Si una tarea puede dañar datos, seguridad o reputación, el gate humano no es fricción: es parte del diseño.
Skill + automation + worktree + review: el combo maduro
Cuando el workflow ya está estable, esta combinación es especialmente fuerte:
- skill = procedimiento reutilizable
- automation = ejecución recurrente
- worktree = aislamiento Git para la run
/review= inspección final legible
Juntas, estas cuatro piezas convierten a Codex en un sistema de ingeniería repetible, no en una serie de prompts sueltos.
Tres combinaciones concretas que suelen funcionar
1. Docs drift semanal
- una skill define cómo comparar docs y código
- una automation corre cada semana
- la run vive en un worktree aislado
- un humano usa
/reviewantes de aceptar el diff
2. Release notes recurrentes
- una skill fija el formato
- la automation recoge cambios con cadence estable
- el worktree separa el borrador del resto del repo
- la review humana corrige tono y exactitud antes de publicar
3. Triage de bugs probables
- la skill ejecuta el checklist de exploración
- la automation corre en background
- el worktree aísla la investigación
- la review decide si el hallazgo merece issue o fix manual
Escalera de madurez razonable
Etapa 1
Trabajo local + /review
Etapa 2
Workflows repetidos empaquetados como skills
Etapa 3
Flujos paralelos con worktrees
Etapa 4
Automations en background sobre workflows ya probados
Etapa 5
Integración acotada en CI/CD con gates humanos explícitos
Ese enfoque por etapas mantiene entendible la superficie de fallo.
Señales de que estás automatizando demasiado pronto
- cada ejecución requiere editar el prompt a mano
- la salida no es consistente entre runs
- nadie sabe qué validar en review
- la tarea mezcla exploración, implementación y decisión final
- un fallo obliga a tocar demasiadas piezas fuera del scope
Si ves varias de esas señales, vuelve un paso atrás: mejora task design, skill o loop manual antes de programar más cadence.
Fallos comunes en setups de review y automatización
“La automation genera ruido útil, pero sigue siendo ruido”
Suele indicar que el prompt es demasiado amplio o que los criterios de éxito no son suficientemente mecánicos.
“Las runs en background chocan con trabajo activo”
Suele indicar que el workflow debería vivir en un worktree dedicado.
“La review cuesta demasiado porque el diff llega sucio”
Suele indicar que la tarea era demasiado grande o que faltaron constraints claras.
“El equipo no sabe qué puede decidir la automation”
Suele indicar que los human gates no se escribieron de forma explícita.
Checklist operativo antes de productivizar un workflow
Antes de automatizar o meter Codex dentro de CI/CD, pregúntate:
- ¿la tarea tiene shape estrecho y repetible?
- ¿el prompt ya funciona manualmente varias veces seguidas?
- ¿hay una skill que quite ambigüedad operativa?
- ¿el aislamiento por worktree reduce riesgo real?
- ¿la review humana final es clara?
- ¿los checks mecánicos son fiables?
- ¿los permisos y el sandbox coinciden con el riesgo?
- ¿siguen existiendo gates humanos en los puntos caros?
El objetivo no es tocar menos review; es hacerla mejor
Los equipos que usan bien Codex en el tiempo no son los que tienen más automatización ni permisos más amplios. Son los que hacen tres cosas bien:
- diseñan tareas revisables
- aíslan el trabajo repetido en worktrees y automations razonables
- preservan la decisión humana donde el coste del error lo exige
Ese es el uso maduro de Codex en CI/CD: menos trabajo repetitivo, más evidencia útil y mejores puntos de control.
Consejos operativos rápidos
Si solo quieres recordar seis cosas, recuerda estas:
- Usa
/reviewcon el scope que responda a la pregunta correcta. - Piensa en worktrees como herramienta de aislamiento y de paralelismo.
- Automatiza solo cuando el workflow manual ya sea estable y aburrido.
- Mantén gates humanos para merge, deploy, migraciones y decisiones de alto blast radius.
- Combina skill + automation + worktree +
/reviewcuando quieras repetibilidad sin perder confianza. - El mejor uso de Codex en CI/CD acelera el juicio; no lo sustituye.