Este Prompt Te Obtiene Revisiones de Código de Ingeniero Senior Desde Cualquier IA
Why this prompt matters
Generic 'review my code' prompts produce generic responses: vague suggestions, no line references, no prioritisation. This prompt enforces a specific output structure that separates critical bugs from architecture concerns from style improvements — the same mental model a senior engineer uses when reviewing a PR. The 'What's Done Well' section is intentional: it keeps the feedback calibrated and makes it easier to act on criticism when you also know what to preserve.
What we use it for
Developers who want high-quality code review feedback without blocking on a colleague's availability. Works for any language or framework — paste the function, class, or diff and get structured, specific feedback in seconds.
Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows: **Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code. **Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode. **Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant. **What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note. Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why. [PASTE YOUR CODE HERE]
Pedirle a una IA que "revise mi código" produce siempre el mismo resultado genérico: una lista de cosas a considerar, sin priorización, sin referencias de línea, y consejos que podrían aplicarse a cualquier base de código. El prompt a continuación resuelve esto imponiendo la estructura exacta que un ingeniero senior utiliza cuando realiza una revisión real de Pull Request.
El prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows:
**Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions):
For each: state the line number, explain precisely why it's a problem, and show the corrected code.
**Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain):
1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode.
**Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better):
Practical, specific suggestions. Reference line numbers. Show before/after where relevant.
**What's Done Well**:
2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note.
Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why.
[PASTE YOUR CODE HERE]Cómo usarlo
Reemplaza [PASTE YOUR CODE HERE] con la función, clase, módulo o diff que quieras revisar. Funciona mejor con Claude Sonnet, GPT-4o y Gemini 2.5 Pro — todos tienen suficiente ventana de contexto para manejar archivos de hasta unos cientos de líneas sin necesidad de dividirlos.
Para archivos más grandes, pega la sección más crítica (la función con el bug, la nueva clase, el método modificado) en lugar del archivo completo. Si el contexto es importante, añade una breve descripción antes del código: "Este es un middleware de Express.js en Node.js que maneja la autenticación. El esquema de base de datos relevante es users(id, email, password_hash, role)."
Por qué importa la estructura
La estructura de cuatro secciones refleja cómo los ingenieros experimentados priorizan la retroalimentación. Critical Issues son bloqueantes — deben corregirse antes del merge. Architecture Concerns no son bloqueantes hoy pero se vuelven bloqueantes a escala. Improvements son para el pase opcional. Separarlos previene el modo de fallo común de la revisión de código con IA donde una crítica de estilo recibe el mismo peso que una vulnerabilidad de SQL injection.
La instrucción de mostrar el código corregido (no solo describir la corrección) es la restricción más importante. Sin ella, los revisores de IA tienden a señalar el problema — "el manejo de errores aquí podría mejorarse" — sin decirte qué escribir. El requisito de código corregido fuerza la especificidad.
Adaptación para contextos específicos
Añade contexto al inicio del prompt para mejores resultados: especifica el lenguaje y framework, el entorno de despliegue (serverless, contenedores, embebido), restricciones de rendimiento o convenciones del equipo. Para código sensible a la seguridad, añade "Presta especial atención a la validación de entrada, SQL injection, XSS y casos límite de autenticación" en la sección Critical Issues. Para rutas críticas de rendimiento, añade "la función se llama 10.000 veces por segundo en producción."
El prompt funciona en cualquier lenguaje de programación. Se ha probado en Python, TypeScript, Go, Rust, Java y SQL con resultados consistentes en los tres modelos frontera.