Cómo montar un flujo de revisión de código con Claude Code y Codex: de cambios locales a PR

Claude Code y Codex pueden escribir código, pero funcionan mejor si no compiten por editar lo mismo. Un flujo más sólido es dejar que Claude Code implemente y que Codex revise el diff desde una perspectiva independiente.

El objetivo es cerrar el ciclo: cambio local, revisión, corrección, verificación, resumen de PR y decisión humana.

Define primero el rol de cada herramienta

Claude Code encaja bien como mesa de trabajo principal: edita, refactoriza y sigue el contexto. Codex sirve como segunda mirada: revisa el patch, busca regresiones, pruebas faltantes, riesgos de seguridad y supuestos débiles.

Evita que ambos agentes editen los mismos archivos al mismo tiempo.

Flujo mínimo viable

1
2
3
4
5
6


Claude Code implementa
  -> pruebas o checks locales
  -> Codex revisa el diff
  -> Claude Code corrige hallazgos confirmados
  -> Codex revisa de nuevo si hace falta
  -> una persona aprueba el PR

La separación ayuda porque el revisor no comparte el sesgo de la conversación de implementación.

Llamar a Codex desde Claude Code

Con plugin o slash command:

1

/codex:review

Para una revisión más exigente:

1

/codex:adversarial-review

Sin plugin, abre Codex en el mismo repositorio y pídele revisar el diff actual.

Revisión de cambios locales

Antes de revisar:

1
2
3


git status --short
git diff --stat
git diff

Prompt útil:

1

Review the current uncommitted diff. Focus on correctness, regressions, missing tests, security risks, and behavior changes. Do not rewrite the code; report findings with file and line references when possible.

Así mantienes a Codex en modo revisión.

Revisión antes del PR

Antes del PR:

1

Review this branch before PR. Check whether the change matches the stated goal, whether tests cover the risky paths, and whether the PR description should mention migration, config, compatibility, or rollout risks.

La salida debería separar hallazgos reales, pruebas faltantes, riesgos, preguntas abiertas y resumen del PR.

Cuándo usar revisión adversarial

Úsala para cambios de alto riesgo:

autenticación y autorización;
pagos o facturación;
migraciones de datos;
código sensible de seguridad;
concurrencia o jobs;
librerías compartidas;
configuración de producción;
comportamiento de API pública.

No hace falta para cada cambio pequeño.

Dejar que Claude Code procese el feedback

Después de revisar los hallazgos:

1

Please address the confirmed Codex review findings. Do not refactor unrelated code. Keep the patch scoped and rerun the relevant checks.

Luego ejecuta pruebas y, si procede, pide una segunda revisión.

Guardar la checklist en el proyecto

Ejemplo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


## High-risk areas

- Authentication and authorization
- Input validation
- Data migration
- Background jobs
- External API calls
- Error handling and retries

## Required verification

- Relevant unit tests
- Integration or smoke tests when behavior changes
- Manual check for UI changes
- Rollback or migration notes when needed

## Code review

- Findings first
- File and line references
- No speculative rewrites
- Mention missing tests separately

Claude Code implementa contra esa lista y Codex revisa contra la misma.

Cuidado con gates automáticos

Un gate automático puede ser útil, pero también crear falsos positivos, bucles y consumo excesivo.

Empieza con reglas estrechas:

secrets comprometidos;
módulo modificado sin pruebas;
comandos shell peligrosos;
migración sin rollback;
archivos sensibles sin revisión.

Para razonamiento amplio, mantén revisión humana.

Flujo de equipo

Claude Code implementa.
El desarrollador ejecuta pruebas locales.
Codex revisa el diff sin commit.
Una persona confirma los hallazgos reales.
Claude Code corrige.
Se ejecutan pruebas de nuevo.
Codex ayuda con el resumen del PR.
Un reviewer humano decide.

Errores comunes

Error 1: dos agentes editan a la vez

Genera conflictos y responsabilidad difusa.

Error 2: prompt de revisión demasiado vago

Indica corrección, regresiones, pruebas, seguridad y referencias de archivo.

Error 3: revisar código pero no pruebas

Muchas fallas son cobertura insuficiente.

Error 4: tomar AI review como decisión final

Codex puede detectar problemas reales, pero también malinterpretar intención.

Error 5: no guardar reglas

Las reglas en chat se olvidan. Déjalas en el repositorio.

FAQ

¿Cuál es mejor para code review?

Claude Code para implementar; Codex para revisión independiente.

¿Codex review modifica código automáticamente?

No debería si pides revisión de solo lectura.

¿Cada PR necesita revisión adversarial?

No. Úsala en cambios de riesgo.

¿Conviene activar review gate por defecto?

Normalmente no. Empieza en modo reporte.

¿Dónde poner la checklist?

En el repositorio: documentación, instrucciones de agente o convención del proyecto.

¿Cómo llevar resultados de AI review al PR?

Resume hallazgos confirmados, arreglos, riesgos restantes y pruebas. No pegues todo el output sin filtrar.

Resumen

El mejor flujo Claude Code + Codex no consiste en dos agentes editando a la vez. Consiste en separar implementación, revisión independiente, corrección confirmada y decisión humana. Así ganas cobertura sin perder control.