Antes de hacer merge de un PR. Te da una segunda opinión estructurada que cubre bugs, seguridad y rendimiento.
El prompt
Eres un senior developer con experiencia en code review en equipos de 5 a 20 personas. Tu filosofía: un buen review detecta bugs, pero un gran review mejora el diseño.
Revisa el siguiente código y dame:
1. BUGS: Errores que van a romper en producción. Para cada uno:
- Línea(s) afectada(s)
- Qué falla y en qué condiciones
- Fix propuesto
2. SEGURIDAD: ¿Hay inputs sin sanitizar? ¿Secrets hardcodeados? ¿SQL injection? ¿Permisos demasiado amplios?
3. RENDIMIENTO: ¿Hay queries N+1? ¿Loops innecesarios? ¿Operaciones que deberían ser async?
4. MANTENIBILIDAD: ¿Se entiende el código sin comentarios? ¿Los nombres de variables y funciones son descriptivos? ¿Hay duplicación que debería extraerse?
5. TESTS: ¿Los tests cubren los edge cases? ¿Falta algún test que debería existir?
Clasifica cada hallazgo como: BLOCKER (no mergear), WARNING (mergear con plan de fix), o SUGGESTION (mejorable pero OK).
Lenguaje: [indicar]
Contexto: [qué hace este código]
Código: [pegar]
Cómo usarlo
Modelo recomendado: Claude
Ejemplo de input
[PR de 200 líneas en Python: endpoint de API que procesa pagos]
Ejemplo de output
BLOCKER - Línea 45: El amount se parsea como float. Para dinero, usar Decimal. Float causa errores de redondeo (ej: 0.1 + 0.2 != 0.3). Fix: from decimal import Decimal; amount = Decimal(str(raw_amount))
WARNING - Línea 78: No hay rate limiting en el endpoint. Un atacante podría hacer miles de requests por segundo.
SUGGESTION - Línea 12-34: La función process_payment hace 3 cosas. Extraer validación y logging a funciones separadas.
Contexto
Cómo hacer code review con IA y detectar bugs antes de producción
El code review más caro es el que no se hizo. Ese bug que llega a producción un viernes por la tarde y te obliga a hacer rollback mientras los clientes reportan errores.
Este prompt convierte a Claude en un revisor de código que busca cinco tipos de problemas: bugs que van a romper, vulnerabilidades de seguridad, problemas de rendimiento, código difícil de mantener, y tests que faltan.
Cada hallazgo viene clasificado como BLOCKER, WARNING o SUGGESTION, para que sepas qué parar y qué puede esperar. Los BLOCKER incluyen fix propuesto que puedes aplicar directamente.
No sustituye a un review de un senior del equipo (el contexto de negocio solo lo tiene una persona), pero cubre el 80% de los problemas técnicos que un humano cansado a las 6 de la tarde dejaría pasar.