Prompt de revisor sénior — encuentra bugs, perf, edge cases

Las revisiones de código por LLM, por defecto, te ahogan en notas de estilo y entierran el bug real. Este prompt fuerza triaje por severidad, solo reporta lo que sobreviviría a un tech lead estricto, y exige citar línea exacta para verificar cada hallazgo en segundos.

Categoría: codingRecomendado para: claude / chatgpt / cursor

prompt

Eres un Staff Engineer sénior revisando el diff abajo. El objetivo es capturar lo que sobreviviría a la revisión de un tech lead estricto — no ruido de lint.

Reglas de revisión:
1. Clasifica cada hallazgo en BLOCKER / MAJOR / MINOR / NIT.
2. Por defecto, emite solo BLOCKER y MAJOR. Suprime MINOR y NIT salvo que pida explícitamente.
3. Para cada hallazgo, cita la ruta de archivo + rango de líneas. Luego explica (a) qué está mal, (b) modo de fallo en producción, (c) corrección sugerida.
4. Si tu confianza está bajo el 80%, marca [low-confidence] y di qué contexto adicional permitiría verificarlo.
5. Termina con un párrafo de resumen: ship-it / ship-with-followups / do-not-ship.

NO comentes:
- Preferencias de naming salvo que confundan activamente.
- Formato/whitespace si hay un formateador.
- Optimizaciones hipotéticas que no puedas ligar a un hot path medido.
- Patrones que el codebase ya usa en otros lados (es consistencia, no bug).

Diff a revisar:

[pega tu diff unificado o el contenido del archivo aquí]

Cuándo usarlo

Antes de mergear un PR no trivial — pasa el diff por este prompt para sacar a la luz lo que querrías que un segundo par de ojos viera.
Self-review de tu propio trabajo — útil antes de pedir review humano, captura las cosas vergonzosas.
Onboarding a un codebase desconocido — pega una función + el prompt para entender riesgos antes de tocarla.

Consejos por modelo

claude: Claude (Sonnet 4.6 u Opus 4.7) suele dar el triaje más cuidadoso. Pega el diff en un bloque de código; los contextos largos manejan revisiones de PR completas.
chatgpt: GPT-5 / GPT-4o tienden a ser más agresivos marcando estilo. La regla 'suprime MINOR y NIT' lo mantiene en cauce.
cursor: En Cursor, guárdalo como entrada de .cursorrules o pégalo en el composer. Combina bien con referencias @file.

Ejemplo de salida

BLOCKER: src/auth/session.ts:42-58
  - what: Comparación de session token usa ===, no constant-time compare.
  - failure mode: Filtrable por timing attack en login remoto.
  - fix: Cambiar a crypto.timingSafeEqual() sobre el par de buffers.

MAJOR: src/auth/session.ts:73 [low-confidence]
  - what: Refresh token escrito en localStorage.
  - failure mode: Riesgo de exfiltración por XSS si contenido de usuario no sanitizado llega a la página.
  - fix: Mover a httpOnly cookie si el cliente no necesita leerlo. (low-confidence: no veo cómo el front-end consume este token.)

Summary: ship-with-followups. La fix de constant-time es obligatoria pre-merge; el storage es un follow-up issue digno fuera de este PR.

Cómo funciona

Por qué la mayoría de revisiones AI son inútiles

Por defecto, los modelos caen en la persona de 'junior servicial' en tareas de revisión: comentan demasiado naming, sugieren reescrituras 'clean code' a código que está bien, y entierran el único bug real bajo un muro de sugerencias que tienes que ignorar. La relación señal/ruido mata el flujo — la mayoría de equipos abandona la AI para revisar dentro de una semana.

El prompt arriba voltea tres cosas: pide triaje por severidad para suprimir explícitamente lo trivial, exige números de línea para que cada hallazgo sea verificable en segundos, y fuerza un flag de confianza para saber qué hallazgos creer sin leer el archivo entero.

Combinándolo con tu CI

Úsalo como paso de 'segunda opinión' en tu workflow de PR — no como check de bloqueo. Los modelos siguen alucinando, especialmente con invariantes cruzados de archivo y código que depende de convenciones de framework que no pegaste. Trata la salida como lista de cosas a verificar, no como lista de issues a corregir mecánicamente.

Si lo quieres en CI, cambia a salida JSON (modifica el prompt: 'devuelve un array JSON con campos severity, path, lineStart, lineEnd, what, fix, confidence'). Luego postea solo BLOCKER/MAJOR como un comentario único en el PR con cabecera clara 'AI assist — verifica antes de actuar'.

Adaptándolo a tu equipo

Añade una sección 'Codebase context' arriba del diff — pega 5-10 líneas describiendo tu stack, convenciones de tests e invariantes no obvios (e.g., 'todas las escrituras DB pasan por src/db/withTx, nunca client crudo'). Sin esto, el modelo se pierde convenciones específicas del codebase.

Si tu equipo tiene puntos débiles conocidos (race conditions en un job runner, N+1 en un servicio específico), añade una línea 'Watch especially for: …'. El modelo dará más peso a esas clases de bugs y los marcará con más probabilidad cuando estén presentes.

Preguntas frecuentes

›¿Puedo usarlo en código cerrado?

Sí, pero verifica primero la política de tu empresa. El prompt en sí es inofensivo; lo que importa es si tienes permitido pegar tu código en el modelo que uses. Los planes enterprise de Claude y ChatGPT suelen no entrenar con tus inputs; consumer puede variar.

›¿Por qué suprimir MINOR y NIT?

Porque en la práctica generan fatiga de revisión. Después de la tercera nota 'considera extraer esto a una función', dejas de leer. Suprimirlas mantiene afilada la señal BLOCKER/MAJOR. Vuélvelas a activar con 'show all findings including MINOR and NIT' cuando quieras revisión profunda.

›¿Qué tan largo puede ser el diff?

Claude Sonnet/Opus y GPT-5 manejan 50K+ tokens de diff cómodamente. Para PRs muy grandes, divide la revisión por directorio (revisa src/auth primero, luego src/billing) para que el modelo piense cada subsistema aislado.

›¿Y revisiones de seguridad específicas?

Este prompt captura issues obvios de cripto/storage/SSRF pero no sustituye una revisión de seguridad sobre código de auth o pagos. Para esos paths, corre este prompt + un prompt dedicado de revisión de seguridad (publicaremos uno aparte).

›¿Puede revisar a través de múltiples archivos?

Sí — pega el diff que incluya todos los archivos. Maneja invariantes cross-file razonablemente bien dentro de un solo paste; para issues que cruzan múltiples PRs (e.g., '¿es consistente con cómo se gatean feature flags en otros lados?'), incluye extractos representativos de esos otros archivos.

›¿Debería confiar en hallazgos [low-confidence]?

Trátalos como 'investiga antes de actuar'. Aproximadamente la mitad de los low-confidence son reales pero el modelo no pudo verificar; la otra mitad son malas lecturas. El flag es señal honesta, no razón para ignorar el hallazgo.

›¿Por qué pedir el modo de fallo?

Porque 'esto está mal' es inútil sin 'esto crashearía con input unicode'. La línea de modo de fallo te dice la prioridad: una fix que previene un edge case 1-en-millón es distinta a una que previene un incidente diario en prod.

›¿Cómo lo uso en Cursor específicamente?

Guarda el cuerpo del prompt en .cursorrules en la raíz del repo, o pégalo en el composer con referencias @file a los archivos en revisión. Cursor mantendrá las reglas activas para ese proyecto.

Calculadoras relacionadas

Prompts relacionados

Última actualización: 2026-05-08