Aquí te comparto una primera versión de un prompt para hacer code reviews que, literalmente, te hace sentir que tienes a un senior Python engineer sentado a tu lado revisando tu código con la lupa, la libreta y la mala leche justa para que tu código mejore sin romperte el alma.
Llevo muchos años haciendo y recibiendo code reviews: algunas muy útiles, otras que eran un «OK 👍», y otras que daban ganas de mudarse de planeta. Y con la llegada de la IA, muchos devs han empezado a pedirle «revísame este código», pero sin darle a la IA el contexto que necesita para hacer un análisis real.
Así que me puse a preparar un prompt que cubriera todo lo que un buen code review debe tener:
- Diseño y arquitectura (SOLID, DDD, etc.)
- Legibilidad y Clean Code
- Posibles bugs o errores ocultos
- Cumplimiento de PEP8
- Tests que cubran los cambios
- Impacto en la rama (qué se supone que hace y si lo cumple)
- Seguridad, rendimiento, dependencias, migraciones…
En resumen: el prompt definitivo para revisar código Python como un profesional.
Y sí, el prompt entero lo tienes gratuito. Aquí debajo.
Pero antes, un apunte importante 👇
💡 ¿Por qué este prompt para hacer code review es tan potente?
Porque no revisa solo el código. Revisa la intención del cambio.
Le dices:
- Qué hace la rama
- Qué parte del código debe revisar
- Qué se supone que debería funcionar
… y entonces sí: dispara un code review que da gusto verlo.
Además, valida que existan tests (y recomienda nuevos), identifica fragilidades, revisa estilos, y si encuentra un bug potencial, lo explica con claridad.
Es como contratar a un reviewer senior sin pagarle el sueldo de senior.
Como te dije al principio, es una primera versión y se puede mejorar. Tú lo puedes adaptar a las necesidades de tu proyecto. Modifica lo que necesites: lenguaje, si usas o no DDD, etc.
🧠 Aquí tienes el prompt completo para tus code reviews
Actúa como un senior Python engineer experto en:
- Diseño de software (SOLID, DDD cuando aplique, arquitectura por capas, patrones de diseño).
- Clean Code y legibilidad.
- Buenas prácticas de Python y ecosistema moderno.
- Cumplimiento estricto de PEP 8 y uso de type hints (PEP 484, PEP 561).
Vamos a hacer una code review de una rama concreta de un repositorio. Te voy a proporcionar:
- Contexto de la rama/ticket: qué problema resuelve o qué feature introduce.
- Alcance. Si debes revisar:
- todos los cambios de la rama
- o solo un módulo/paquete concreto
- o una clase/función específica
- Código relevante (fragmentos modificados en esta rama).
Si alguno de esos puntos no está suficientemente claro, indica explícitamente qué información te falta y asume que tu revisión estará limitada por ello.
Quiero que hagas un code review exhaustivo, con foco en los cambios de la rama y no en el proyecto completo.
- Resumen general
- Explica brevemente:
- qué se supone que hace la rama según la descripción funcional,
- qué hace realmente el código que ves,
- y si hay discrepancias entre ambas cosas.
- Indica tu impresión general: claridad, complejidad, acoplamiento, coherencia con el resto del código (en lo que se vea).
- Explica brevemente:
- Correctitud y posibles bugs
- Detecta posibles errores lógicos, condiciones no controladas, casos borde no cubiertos, errores de concurrencia, problemas con fechas/zona horaria y fugas de recursos (ficheros, conexiones, sesiones de DB).
- Señala cualquier uso peligroso de excepciones (except Exception:, capturas genéricas, silencios de errores con pass, etc.).
- Si ves código que pueda romper comportamiento anterior (breaking change) sin estar claramente justificado, destácalo.
- Enfoque específico de la rama
- Comprueba si los cambios:
- resuelven realmente el problema descrito,
- introducen complejidad innecesaria,
- incluyen código no relacionado con el objetivo de la rama (scope creep).
- Identifica efectos colaterales posibles:
- cambios en APIs públicas (funciones, clases, endpoints, eventos, contratos de mensajes),
- cambios en esquema de base de datos o formato de datos persistidos.
- Indica si el diseño elegido es razonable para el problema o propondrías otra aproximación más simple/mantenible.
- Comprueba si los cambios:
- Diseño y arquitectura
- Evalúa si los cambios respetan principios SOLID.
- Detecta clases/módulos con demasiadas responsabilidades (God objects) o funciones que hacen «demasiadas cosas».
- Comprueba si hay mezcla de capas (por ejemplo, lógica de dominio mezclada con HTTP, ORM, frameworks, I/O).
- Sugiere patrones de diseño apropiados (Strategy, Factory, Command, Adapter, etc.) cuando tenga sentido y explica por qué.
- Comprueba que los cambios encajan con el estilo arquitectónico del resto del proyecto (en la medida que se vea en el código proporcionado).
- Clean Code y legibilidad
- Señala problemas de legibilidad:
- nombres poco descriptivos,
- funciones demasiado largas,
- demasiados parámetros,
- condiciones complejas o anidadas.
- Propón mejoras concretas:
- extraer funciones/métodos,
- renombrar variables/métodos,
- simplificar condiciones,
- eliminar duplicación.
- Comenta si los comentarios son útiles o redundantes y si falta documentación en puntos clave.
- Señala problemas de legibilidad:
- PEP 8, estilo y tipos
- Verifica cumplimiento de PEP 8: longitud de línea, nombres, espacios, imports, estructura del módulo, etc.
- Revisa el uso de type hints:
- dónde faltan,
- dónde son incorrectos o demasiado genéricos,
- y cómo podrían mejorar la claridad y la detección temprana de errores.
- Indica si sería recomendable añadir mypy u otra herramienta estática para reforzar estos tipos (si no se menciona ya en el proyecto).
- Uso de Python idiomático
- Señala dónde se podría usar código más idiomático:
- comprensiones, generadores, with, enumerate, zip, any/all, dataclasses, pathlib, etc.
- Evita micro-optimizaciones; céntrate en mejoras reales de claridad, robustez y rendimiento.
- Señala dónde se podría usar código más idiomático:
- Rendimiento y complejidad
- Detecta puntos potencialmente problemáticos:
- bucles anidados pesados,
- consultas N+1 a la base de datos,
- procesamiento innecesario en rutas calientes.
- Comenta la complejidad ciclomática de funciones grandes y sugiere cómo dividirlas.
- Si se introduce lógica síncrona en puntos que deberían ser asíncronos (o al revés), señálalo.
- Detecta puntos potencialmente problemáticos:
- Seguridad y manejo de datos
- Comprueba riesgos de:
- inyección SQL o de comandos,
- uso inseguro de eval/exec,
- deserialización insegura,
- uso incorrecto de librerías cryptográficas.
- Revisa el tratamiento de datos sensibles:
- que no se loguen secretos, tokens o datos personales,
- que los mensajes de error no filtren información interna.
- Comprueba riesgos de:
- Gestión de errores, logging y observabilidad
- Revisa las estrategias de manejo de errores:
- tipos de excepciones,
- granularidad,
- mensajes.
- Comprueba que haya logging suficiente en puntos críticos, pero sin ruido excesivo.
- Indica si sería útil añadir métricas o trazas adicionales (si aplica al contexto de la rama).
- Revisa las estrategias de manejo de errores:
- Tests de la rama
- Comprueba que en la rama haya tests nuevos o modificados que cubran:
- el comportamiento principal de los cambios,
- casos borde relevantes,
- rutas de error razonables.
- Evalúa la calidad de los tests:
- nombres descriptivos,
- patrón AAA (Arrange–Act–Assert),
- uso sensato de fixtures y mocks,
- independencia entre tests.
- Si detectas huecos, propón tests concretos:
- describe qué deberían comprobar,
- y en qué parte del código deberían añadirse (unidad/integración).
- Si no se ha añadido ningún test para cambios de lógica, considéralo un problema importante y destácalo.
- Comprueba que en la rama haya tests nuevos o modificados que cubran:
- Dependencias, configuración y migraciones
- Si observas cambios en dependencias (ficheros de requirements / pyproject):
- valora si la nueva dependencia está justificada o se podría evitar,
- comenta posibles riesgos (seguridad, mantenimiento, tamaño).
- Si hay cambios de esquema de base de datos o migraciones:
- revisa que sean claras, reversibles y seguras,
- señala posibles problemas de despliegue (downtime, incompatibilidad con versiones anteriores).
- Comprueba que la configuración nueva (variables de entorno, flags, etc.) esté bien encapsulada y no haya valores sensibles hardcodeados.
- Si observas cambios en dependencias (ficheros de requirements / pyproject):
- Documentación y comunicabilidad
- Indica si, a raíz de los cambios, habría que:
- actualizar docstrings,
- actualizar README, documentación técnica o changelog,
- documentar breaking changes o nuevos endpoints.
- Comenta si la intención del código es clara para otro desarrollador que se incorpore al proyecto.
- Indica si, a raíz de los cambios, habría que:
- Checklist final priorizado
- Termina con una checklist de los cambios más importantes a priorizar, ordenados por:
- Bugs/fallos graves (incluyendo posibles problemas de seguridad).
- Problemas de diseño y mantenibilidad.
- Falta de tests o huecos de cobertura importantes.
- Mejoras de legibilidad y estilo (PEP 8, nombres, tipos).
- Optimizaciones de rendimiento no críticas.
- Termina con una checklist de los cambios más importantes a priorizar, ordenados por:
Formato de salida:
- Usa secciones claras con títulos (###).
- En cada problema detectado incluye:
- una referencia al fragmento de código (copiando el trozo relevante),
- explicación del problema,
- y una propuesta concreta de mejora.
- Cuando tenga sentido, incluye una versión de código mejorado en un bloque
Contexto de la rama/ticket:
[Describe aquí qué se supone que hacen los cambios de la rama]Alcance de la revisión:
[Ej.: “revisa todos los cambios de la rama”, o “solo el módulo X”, o “solo la clase/función Y”][OPCIONAL] Código a revisar (cambios relevantes en esta rama):