Claude Code + Codex como revisor: lo que mostraron 5 PRs

Conclusión clave — En septiembre, una revisión de código que había automatizado dentro de Claude Code se disparó unas 400 veces en tres días, con Opus, y ayudó a agotar mi límite semanal. Dividí la revisión en dos niveles: una ligera con Sonnet dentro de Claude Code y una más profunda por pull request con Codex de OpenAI, en otra suscripción. En una prueba con 5 PRs, Codex tuvo menos falsas alarmas que Opus y encontró un bug que ningún otro modelo vio. La lección más grande fue que modelos distintos se pierden bugs distintos.

Este artículo es la continuación de cómo dejé de chocar con el límite semanal de Claude Max. Ese artículo recibió hoy una actualización de septiembre: volví a llegar al límite, y buena parte de la causa fue una revisión de código.

La revisión que se comió la cuota

Tenía un plugin que le pedía a Opus revisar el diff cada vez que terminaba una sesión o un subagente de Claude Code. Parecía un seguro barato. En cuatro semanas corrió 854 revisiones. 405 fueron en tres días, del 13 al 15 de septiembre. Las sesiones lanzaban decenas de subagentes, una de ellas 120, y cada subagente que terminaba disparaba su propia revisión. Cada revisión era una llamada completa a Opus sobre la misma cuota semanal que necesitaba para el trabajo de verdad.

Ese es el problema de automatizar la revisión dentro de la misma herramienta que escribe el código: crece con la cantidad de subagentes, no con la cantidad de cambios que vale la pena revisar. Cien subagentes que terminan no son cien cambios. La mayoría eran búsquedas y lecturas.

Dos niveles, dos proveedores

La dividí:

• Dentro de Claude Code, una revisión ligera con Sonnet. Ya no se dispara cada vez que termina un subagente. Atrapa lo obvio mientras la sesión sigue abierta.
• Una vez por pull request, una revisión más profunda con otro proveedor. Codex de OpenAI, desde la línea de comandos, con un plan de ChatGPT. Lee una copia de solo lectura del cambio, no edita nada y escribe un reporte. Su medidor de uso es independiente del de Claude.

¿Por qué otro proveedor y no simplemente otra llamada a Claude? Por dos razones. La de la cuota es obvia: la revisión profunda deja de competir con el trabajo. La otra son los puntos ciegos. Un modelo que revisa código escrito por el mismo modelo tiende a compartir sus supuestos. Quería un revisor entrenado de otra forma.

No lo di por hecho. La evidencia publicada sobre revisión entre modelos es escasa: afirmaciones de los proveedores y un estudio controlado donde un revisor más débil ayudó a un escritor más débil pero perjudicó a uno más fuerte. Así que lo probé con mi propio código.

La prueba: 5 pull requests ya integrados

El diseño, tan justo como pude hacerlo:

• Cinco pull requests ya integrados de mi propio producto, no código de clientes. Cambios reales: procesos en segundo plano, un flujo de credenciales, una pantalla de estado, una migración de datos.
• El mismo prompt y el mismo contexto para cada revisor: el diff, un paquete corto de código relacionado e instrucciones para verificar contra el código lo que el PR afirma.
• Tres modelos de Codex (gpt-5.6-terra, gpt-5.6-sol, gpt-6-astra) con esfuerzo alto, más un control: Claude Opus con exactamente el mismo prompt.
• Calificación contra el código, no contra el argumento del revisor. Cada hallazgo se verificó en el commit de integración y se marcó como real, menor o falso. En los cinco PRs aparecieron cinco defectos reales distintos; dos de los PRs no tenían ninguno.

	Terra	Sol	Astra	Opus (sin herramientas)
Defectos reales encontrados (de 5)	3	4	4	3
Hallazgos	12	11	15	23
Falsas alarmas	6	1	3	3
Encontrados solo por este modelo	0	1	0	0

Qué significa en la práctica:

• Terra fue ruidoso. La mitad de sus hallazgos estaban mal. No lo uso como default.
• Sol fue el más preciso. Una falsa alarma en once hallazgos. También fue el único modelo que detectó una pantalla que mostraba una cuenta como “conectada” antes de que la cuenta estuviera verificada. Ese bug llegó a producción y se corrigió el mismo día en el siguiente PR.
• Astra fue el más rápido y el más escueto, pero llenaba sus reportes de puntos que “no se pueden verificar”.
• Opus fue más verboso. Veintitrés hallazgos, quince ciertos pero menores. En un PR citó código que no existe en el repositorio.

El hallazgo en el que más confío no es el ranking. Es este: ningún modelo encontró los cinco, pero dos modelos distintos juntos sí. Sol más Opus cubrieron los cinco. Sol más Astra también.

Lo que la prueba no puede decir

Son cinco pull requests. Un defecto de diferencia equivale a veinte puntos de recall, así que el 4 de Sol contra el 3 de Opus cae dentro del ruido. La calificación la hizo una sesión de Claude verificando cada hallazgo contra el código, que es el método correcto, pero no fue a ciegas respecto a qué modelo escribió qué. El prompt se ajustó después de uno de los cinco PRs, así que ese quedó dentro de la muestra. Y hay un factor que favorece a Codex: corrió sobre una copia del repositorio y podía leer archivos más allá del prompt, mientras que Opus solo vio el prompt.

Así que no digo que Codex revise mejor que Claude. Digo que un segundo modelo de otro proveedor, una vez por PR, atrapa cosas que el primero no ve, sin costo para la cuota que necesito para el trabajo.

Revisar el plan antes del código

La misma herramienta puede revisar una especificación en lugar de un diff. La corrí sobre cuatro planes del mismo producto, cada uno contra el código como estaba antes de empezar el trabajo, y comparé los hallazgos con lo que pasó después.

Cerca de uno de cada diez hallazgos coincidió con una falla que un commit posterior corrigió. Cerca de uno de cada seis estaba mal. Es útil, pero no es un filtro. Un resultado sí destacó: en una tarea del backlog, señaló que una credencial recién guardada se mostraría como conectada antes de validarse. Es el mismo bug que después llegó a producción y que solo Sol detectó en la prueba de diffs. En la etapa de plan ya era visible antes de escribir ese código.

También revisó esta actualización

Hoy actualicé el artículo original con los números de septiembre. Antes de publicar corrí dos revisiones: un fact-check con Claude Opus contra mi bitácora de telemetría y una revisión del cambio con Codex. Las dos regresaron con notas. Opus encontró redacción que exageraba lo que mostraban los datos. Codex encontró una afirmación que todavía le daba toda la mejora a dos causas cuando esa semana cambiaron cuatro cosas, un porcentaje preciso que ya no puedo volver a verificar y un bug de fechas en el índice de artículos. También marcó una “violación” de nombres que no lo era. Corregí los hallazgos válidos y descarté ese.

Ese es el flujo en miniatura: el modelo que escribe revisa los datos, un segundo proveedor revisa el razonamiento y una persona decide.

Cómo lo uso ahora

• Una vez por pull request, nunca por commit. La revisión por evento fue la que agotó la cuota.
• Sol como default. Sol y Astra juntos solo para el cambio raro de alto riesgo.
• Solo reporte. Lee una copia y escribe un reporte. No puede tocar el repositorio.
• Lee los hallazgos, no el veredicto. Más de una vez un modelo imprimió “PASS” con hallazgos reales listados debajo.
• Verifica antes de actuar. Cada hallazgo se revisa contra el código. Cerca de uno de cada diez está mal, y un hallazgo equivocado dicho con seguridad cuesta más que ninguno.
• Solo código propio. El entrenamiento está apagado en la configuración de datos del proveedor, los repositorios de clientes nunca pasan por ahí y los nombres de clientes se filtran de todo lo que se manda.

Lo que no importó

Los LLMs locales. Corro dos en mis propias GPUs, y en mayo conté la delegación local como una palanca de cuota. En septiembre atendió unos 36K tokens de entrada en una semana, frente a cerca de 2 mil millones en Claude. Los detalles están en la actualización del artículo original. Los modelos locales siguen pagándose con otro trabajo. Simplemente no estiran la cuota de Claude, y no son lo bastante buenos para ser el segundo revisor.

Cierre

La semana después del bloqueo, el uso diario bajó cerca de 70%. Sonnet volvió a ser el default, los subagentes son menos y usan Sonnet por defecto, el contexto se compacta antes y la revisión pesada se fue a otro proveedor, una vez por PR. Una semana parcial no alcanza para repartir ese 70% entre estos cambios, así que lo voy a volver a medir con una semana completa y a darle seguimiento semanal.

Es el mismo patrón que uso en proyectos de datos con clientes: medir el costo real de algo opaco, encontrar los pocos cambios que importan y poner una verificación independiente sobre el resultado antes de que alguien dependa de él. Si tu equipo está resolviendo estas mismas preguntas con ingeniería asistida por IA, platiquemos.