Claude + Codex: Revisión de Código Cruzada con IA
TL;DR: Este artículo presenta un flujo de trabajo práctico donde un LLM (ej. Claude Code) genera código y otro (ej. Codex 5.3) lo revisa. Este enfoque de revisión cruzada detecta errores que un solo modelo pasaría por alto, mejorando la calidad y robustez del código antes de la revisión humana. Aprenderás a configurar este proceso, los prompts efectivos y sus implicaciones en un entorno de producción.
El Problema: Los LLMs También Tienen Puntos Ciegos
¿Cuántas veces has revisado tu propio Pull Request y has pensado que estaba perfecto, solo para que un compañero detectara un error obvio en dos minutos? Nos pasa a todos. Leemos lo que *queríamos* escribir, no lo que realmente está escrito. Con los LLMs de código ocurre exactamente lo mismo. Cuando le pides a un modelo que revise su propio trabajo, tiende a confirmar sus decisiones iniciales. Ya está "comprometido" con su enfoque y es menos propenso a cuestionarlo.
En mi experiencia migrando lógica de negocio compleja de Java a Python, este enfoque de doble revisión me ha salvado de introducir bugs sutiles que un solo modelo (y a veces, incluso yo) pasaba por alto. La clave es que cada modelo tiene diferentes "sesgos" de entrenamiento y patrones de fallo. Usar uno para auditar al otro introduce una diversidad de pensamiento artificial que resulta muy eficaz.
Conceptos Clave
¿Qué es la Revisión de Código Cruzada con IA?
La revisión de código cruzada con IA es un proceso donde se utilizan dos o más modelos de lenguaje grandes (LLMs) de forma colaborativa. Un modelo asume el rol de "desarrollador" y genera el código, mientras que el segundo actúa como "revisor", analizando el código en busca de errores, vulnerabilidades y mejoras.
Fortalezas de Cada Modelo (a febrero de 2026)
Aunque los modelos evolucionan rápidamente, actualmente se observan ciertas tendencias:
- Claude Opus 4.6: Sobresale en tareas que requieren un razonamiento profundo y comprensión del contexto a gran escala. Es ideal para diseñar la arquitectura inicial, refactorizaciones complejas y asegurar que el código se alinee con la lógica de negocio.
- Codex 5.3: Es extremadamente rápido y eficiente en tareas de terminal y flujos de trabajo iterativos. Destaca encontrando casos extremos, optimizaciones de rendimiento y bugs sutiles en la implementación.
La combinación de la visión arquitectónica de Claude con la precisión táctica de Codex crea un filtro de calidad muy potente.
Implementación Paso a Paso: Un Ejemplo con FastAPI
Vamos a simular un flujo de trabajo real. La tarea es crear un endpoint en FastAPI que reciba datos de un usuario y los guarde, pero con una validación específica.
Paso 1: Generar el Código con Claude Code
Primero, le pedimos a Claude que genere el endpoint. El prompt debe ser claro y definir los requisitos.
# Prompt para Claude Code
"""
Actúa como un ingeniero de software senior especializado en Python y FastAPI.
Tarea: Crea un endpoint POST en FastAPI en `/users/`.
Requisitos:
1. Debe aceptar un body JSON con `username` (string) y `email` (string).
2. Usa Pydantic para la validación del modelo de entrada.
3. El `username` no puede contener espacios.
4. El `email` debe ser un formato de email válido.
5. Si la validación falla, FastAPI debe devolver automáticamente un error 422.
6. Si es válido, devuelve un JSON `{"status": "ok", "user_id": 123}` con un status code 201.
Genera el código completo en un solo fichero `main.py`.
"""Output esperado de Claude:
# main.py
from fastapi import FastAPI, HTTPException, status
from pydantic import BaseModel, field_validator, EmailStr
app = FastAPI()
class User(BaseModel):
username: str
email: EmailStr
@field_validator('username')
def username_must_not_contain_spaces(cls, v):
if ' ' in v:
raise ValueError('El username no puede contener espacios')
return v
@app.post("/users/", status_code=status.HTTP_201_CREATED)
def create_user(user: User):
# Lógica para guardar el usuario en la base de datos (simulada)
user_id = 123
return {"status": "ok", "user_id": user_id}
Paso 2: Revisar el Código con Codex 5.3
Ahora, tomamos el código generado y se lo pasamos a Codex con un prompt de revisión. Un buen prompt de revisión es específico y asigna un rol claro al LLM.
# Prompt para Codex 5.3
"""
Actúa como un revisor de código experto en seguridad y robustez para aplicaciones Python/FastAPI.
Revisa el siguiente código y busca posibles problemas en estas categorías:
1. **Errores sutiles o bugs**: ¿Hay algún caso que el código no maneje correctamente?
2. **Vulnerabilidades de seguridad**: ¿Existe algún riesgo de seguridad, incluso si es pequeño?
3. **Malas prácticas o anti-patrones**: ¿Se podría escribir de una forma más idiomática o eficiente?
Proporciona tu feedback en formato de lista, explicando el problema y sugiriendo una solución concreta.
---
Código a revisar:
```python
# [Pegar aquí el código generado por Claude]
```
"""Output esperado de Codex:
Codex, siendo más agresivo en la detección de casos extremos, podría encontrar algo que Claude pasó por alto:
- Problema Detectado: El validador de Pydantic actual previene espacios, pero no valida la longitud del `username`. Un `username` vacío (
"") o extremadamente largo podría pasar la validación y causar problemas en la base de datos. - Sugerencia de Mejora: Añadir restricciones de longitud mínima y máxima al campo `username` en el modelo Pydantic para mejorar la robustez.
# Sugerencia de Codex implementada
from fastapi import FastAPI, HTTPException, status
from pydantic import BaseModel, field_validator, EmailStr, Field
app = FastAPI()
class User(BaseModel):
# Field permite añadir más validaciones como min/max longitud
username: str = Field(..., min_length=3, max_length=50)
email: EmailStr
@field_validator('username')
def username_must_not_contain_spaces(cls, v):
if ' ' in v:
raise ValueError('El username no puede contener espacios')
return v
# ... resto del código sin cambios
Este simple hallazgo mejora la robustez del endpoint y es un ejemplo perfecto de un error que un solo modelo (o un desarrollador con prisa) podría no ver.
En Producción
Implementar este flujo en un entorno real requiere considerar varios factores:
- Coste: Este proceso duplica las llamadas a las APIs de los LLMs para cada pieza de código. Para un fichero como el del ejemplo, el coste total (generación + revisión) podría rondar los 0,02€ - 0,05€. Es un coste marginal a cambio de una mayor calidad, pero debe tenerse en cuenta a escala.
- Velocidad: Añade un paso extra al ciclo de desarrollo. Sin embargo, el tiempo invertido (generalmente 1-2 minutos por fichero) es casi siempre menor que el tiempo que llevaría depurar un bug en producción.
- Automatización: Este flujo se puede automatizar. Se puede integrar en un pipeline de CI/CD (ej. GitHub Actions, GitLab CI) como un paso de "linting con IA" que se ejecuta en cada Pull Request. Un script puede orquestar la llamada al primer LLM, capturar el output y enviarlo al segundo para la revisión.
- Revisión Humana: Es fundamental entender que esto no reemplaza la revisión humana. Su objetivo es actuar como un filtro de alta calidad, permitiendo que los revisores humanos se centren en la lógica de negocio y la arquitectura, en lugar de buscar errores sintácticos o casos extremos obvios.
Errores Comunes y Depuración
- Error: El LLM revisor da feedback genérico o poco útil.
Causa: El prompt de revisión es demasiado vago (ej. "revisa este código").
Solución: Utiliza prompts específicos que definan un rol y unas categorías de revisión claras (seguridad, rendimiento, bugs, etc.). - Error: Los modelos entran en un bucle de desacuerdo.
Causa: Cada modelo tiene una "opinión" diferente sobre un patrón de diseño y ninguno cede.
Solución: Establecer un límite de iteraciones (normalmente una o dos es suficiente). Si no hay consenso, es una señal clara de que se requiere intervención humana para tomar la decisión final.
Preguntas Frecuentes (FAQ)
¿Qué combinación de modelos funciona mejor?
Claude para generar la estructura y la lógica principal, y Codex para revisar y optimizar, suele ser una combinación muy efectiva. Sin embargo, la mejor combinación depende de la tarea. Experimentar invirtiendo los roles también puede dar buenos resultados.
¿Se puede aplicar este método a código ya existente?
Sí, es una técnica excelente para auditar código legacy. Puedes pasar un fichero existente a un LLM con un prompt de revisión para obtener un análisis rápido de posibles mejoras o vulnerabilidades ocultas.
¿Cómo se gestionan las API keys de forma segura en un flujo automatizado?
Nunca incluyas las claves directamente en el código. Utiliza siempre variables de entorno o un gestor de secretos (como GCP Secret Manager o HashiCorp Vault) para inyectar las claves de forma segura en tu pipeline de CI/CD.
Conclusión
Hemos visto cómo la revisión de código cruzada con IA, usando las fortalezas complementarias de modelos como Claude Code y Codex 5.3, eleva significativamente la calidad del software. Este enfoque no reemplaza al desarrollador, sino que actúa como un potente asistente que detecta errores sutiles y asegura la robustez del código. La clave está en el "prompt engineering" preciso y en integrar este flujo de manera inteligente en nuestros procesos de desarrollo.
La próxima vez que generes una pieza de código crítica, prueba a que un segundo par de ojos de IA la revise. Te sorprenderá lo que puede encontrar.
¿Has implementado algún flujo de trabajo multi-agente o de revisión cruzada? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_.