Un desarrollador que sabe usar bien la IA puede aplicarla a las partes tediosas de su trabajo — boilerplate, documentación, scaffolding de tests, checklists de revisión de código — sin sacrificar el control sobre las decisiones de arquitectura que realmente importan. El error no es usar demasiado la IA; es usarla con prompts demasiado vagos y terminar dedicando más tiempo a corregir sus resultados que a escribir el código tú mismo.
Cómo están organizadas estas plantillas
Las 18 plantillas están agrupadas en cinco categorías: revisión de código, refactorización, depuración, generación de tests y documentación. Cada una sigue una estructura de Rol/Tarea/Contexto/Formato que puedes pegar en ChatGPT, Claude o — donde se indica — adaptar para la interfaz de prompting inline de Cursor o GitHub Copilot Chat.
Convenciones clave:
[LENGUAJE]= lenguaje de programación o framework (Python, TypeScript, Go, etc.)[CONTEXTO]= información relevante del código base que necesita el modelo (no pegues archivos completos — resume la arquitectura y pega la función/clase relevante)[RESTRICCIÓN]= restricciones de rendimiento, estilo o compatibilidad
El generador de prompts de IA funciona bien para crear plantillas personalizadas para tu stack específico — puedes codificar tu lenguaje, framework y convenciones de código en el campo Contexto una sola vez y reutilizarlo en diferentes tipos de prompts.
Plantillas de revisión de código (1–4)
1. Revisión de código general
Rol: Eres un ingeniero senior de [LENGUAJE] con opiniones sólidas sobre mantenibilidad y rendimiento.
Tarea: Revisa el siguiente código e identifica problemas.
Contexto: Este código es parte de [DESCRIBE EL SISTEMA/MÓDULO]. Se ejecuta en [PRODUCCIÓN/STAGING/PROTOTIPO]. Restricciones relevantes: [REQUISITOS DE RENDIMIENTO, GUÍA DE ESTILO, CONSIDERACIONES DE SEGURIDAD].
Código:
[PEGA EL CÓDIGO]
Formato: Categoriza los problemas como: Crítico (debe corregirse antes del merge), Sugerido (mejoraría la calidad), Nitpick (estilo/preferencia personal — puede ignorarse). Para cada problema crítico, incluye una explicación de 1–2 oraciones y un fragmento de código corregido.2. Revisión enfocada en seguridad
Rol: Eres un ingeniero de seguridad de aplicaciones senior que realiza una revisión de seguridad del código.
Tarea: Revisa el siguiente código en busca de vulnerabilidades de seguridad.
Contexto: Lenguaje: [LENGUAJE]. Este código maneja: [ENTRADA DE USUARIO / AUTH / CONSULTAS DE BASE DE DATOS / OPERACIONES DE ARCHIVO — describe qué hace]. Áreas de riesgo conocidas: [CATEGORÍAS OWASP TOP 10 relevantes para este código].
Código:
[PEGA EL CÓDIGO]
Formato: Para cada vulnerabilidad encontrada: Severidad (Crítica/Alta/Media/Baja) | Tipo de vulnerabilidad | Referencia de línea | Explicación | Corrección recomendada con código. Ordena por severidad.3. Revisión de rendimiento
Rol: Eres un ingeniero de [LENGUAJE] enfocado en el rendimiento.
Tarea: Identifica cuellos de botella de rendimiento en el siguiente código.
Contexto: Esta función se llama aproximadamente [FRECUENCIA] por [PERÍODO DE TIEMPO]. Latencia actual: [LATENCIA OBSERVADA si se conoce]. Hipótesis sobre el cuello de botella: [TU HIPÓTESIS si la hay].
Código:
[PEGA EL CÓDIGO]
Formato: Para cada cuello de botella: Descripción | Impacto estimado (Alto/Medio/Bajo) | Causa raíz (1 oración) | Versión optimizada (fragmento de código) | Compensaciones introducidas por la optimización.4. Generador de descripción de Pull Request
Rol: Eres un desarrollador que escribe una descripción de PR para tu equipo.
Tarea: Escribe una descripción de pull request para los siguientes cambios/diff.
Contexto: Rama: [NOMBRE DE LA RAMA]. Ticket relacionado: [ID/DESCRIPCIÓN DEL TICKET]. Tipo de cambio: [CORRECCIÓN DE BUG / FUNCIÓN / REFACTORIZACIÓN / DOCS / TEST].
Cambios:
[PEGA EL DIFF O RESUME LOS CAMBIOS PRINCIPALES]
Formato: Título del PR (menos de 72 caracteres, modo imperativo), luego secciones: Resumen (2–3 oraciones), Cambios realizados (lista de viñetas), Testing realizado (lista de viñetas), Capturas de pantalla si aplica (dejar como marcador), Lista de verificación (ítems estándar: tests pasan, docs actualizadas, sin código de depuración).Plantillas de refactorización (5–8)
5. Refactorizar para legibilidad
Rol: Eres un ingeniero de [LENGUAJE] enfocado en código limpio y mantenibilidad a largo plazo.
Tarea: Refactoriza el siguiente código para mejorar la legibilidad sin cambiar el comportamiento.
Contexto: El código está en [LENGUAJE]. Convenciones del equipo: [CONVENCIONES DE NOMBRES, ESTILO DE COMENTARIOS si los hay]. El próximo desarrollador que lo lea probablemente no estará familiarizado con este módulo.
Código:
[PEGA EL CÓDIGO]
Formato: Código refactorizado con comentarios inline que expliquen las decisiones no obvias. Un resumen breve (3–5 viñetas) de qué cambió y por qué.6. Extraer funciones / Reducir complejidad
Rol: Eres un ingeniero senior que aplica principios SOLID y prácticas de código limpio.
Tarea: Identifica funciones o clases que hacen demasiado y refactorízalas.
Contexto: Lenguaje: [LENGUAJE]. La función/clase a continuación tiene una puntuación de complejidad ciclomática de [NÚMERO si se conoce] o tiene [X] líneas de largo.
Código:
[PEGA EL CÓDIGO]
Formato: Versión refactorizada con funciones/métodos extraídos. Para cada extracción: nombre de la nueva función, su responsabilidad en una oración y por qué fue extraída.7. Migrar a un nuevo patrón o librería
Rol: Eres un desarrollador de [LENGUAJE] que realiza una migración de librería o patrón.
Tarea: Reescribe el siguiente código para usar [NUEVA LIBRERÍA/PATRÓN] en lugar de [ANTIGUA LIBRERÍA/PATRÓN].
Contexto: Contexto del código base: [INFORMACIÓN DE ARQUITECTURA RELEVANTE]. El objetivo de la migración: [POR QUÉ ESTÁS MIGRANDO — deprecación, rendimiento, estandarización]. Cambios incompatibles a tener en cuenta: [CUALQUIER CAMBIO INCOMPATIBLE CONOCIDO].
Código:
[PEGA EL CÓDIGO]
Formato: Código migrado con comentarios sobre cualquier diferencia de comportamiento o pasos manuales necesarios. Lista cualquier suposición realizada.8. Mejoras de seguridad de tipos
Rol: Eres un desarrollador de [TYPESCRIPT/PYTHON/RUST] que toma en serio la seguridad de tipos.
Tarea: Añade o mejora las anotaciones de tipo en el siguiente código.
Contexto: Cobertura de tipos actual: [ESTIMACIÓN APROXIMADA]. Objetivo: [TIPOS ESTRICTOS / VALIDACIÓN EN TIEMPO DE EJECUCIÓN / VALIDACIÓN DE ESQUEMA]. Entorno de ejecución: [NODE.JS / PYTHON 3.11+ / etc.].
Código:
[PEGA EL CÓDIGO]
Formato: Versión tipada del código. Señala cualquier lugar donde la tipificación completa requirió una decisión de diseño — describe la decisión y por qué la tomaste.
Plantillas de depuración (9–11)
9. Diagnóstico de errores
Rol: Eres un depurador experimentado de [LENGUAJE].
Tarea: Diagnostica el siguiente error y sugiere correcciones.
Contexto: Mensaje de error: [PEGA EL ERROR COMPLETO + STACK TRACE]. Qué debería hacer el código: [DESCRIPCIÓN]. Lo que ya he intentado: [PASOS DE RESOLUCIÓN].
Código:
[PEGA EL CÓDIGO RELEVANTE]
Formato: Causa raíz (1–2 oraciones), explicación de por qué ocurre el error, lista ordenada de posibles correcciones comenzando por la más probable, fragmento de código para la corrección principal.10. Prompt de depuración rubber duck
Rol: Eres un desarrollador experimentado que me ayuda a pensar en un bug.
Tarea: Hazme preguntas para ayudarme a identificar la causa raíz de este bug. No sugieras correcciones aún.
Contexto: Lo que debería hacer el código: [COMPORTAMIENTO ESPERADO]. Lo que hace realmente: [COMPORTAMIENTO REAL]. Cuándo empezó: [CUÁNDO SE ROMPIÓ — cambio reciente / siempre estuvo roto].
Código:
[PEGA EL CÓDIGO]
Formato: Haz 3–5 preguntas de aclaración que ayuden a delimitar la causa. Después de que responda, procede al diagnóstico.11. Investigación de test inestable
Rol: Eres un ingeniero senior que investiga un test inestable en un pipeline de CI/CD.
Tarea: Analiza el siguiente test e identifica por qué podría fallar de forma intermitente.
Contexto: Lenguaje y framework de testing: [LENGUAJE / JEST / PYTEST / RSpec, etc.]. Con qué frecuencia falla: [PORCENTAJE APROXIMADO]. Entorno donde falla: [CI / LOCAL / STAGING]. Causa sospechada: [TU HIPÓTESIS si la hay].
Código del test:
[PEGA EL TEST]
Formato: Causas probables ordenadas por probabilidad, con explicación para cada una. Para la causa más probable, proporciona una versión corregida del test. Señala cualquier dependencia en estado externo, tiempos o variables globales.Plantillas de generación de tests (12–15)
12. Generación de tests unitarios
Rol: Eres un desarrollador de [LENGUAJE] que escribe tests unitarios exhaustivos.
Tarea: Escribe tests unitarios para la siguiente función/clase.
Contexto: Framework de testing: [JEST / PYTEST / etc.]. Objetivo de cobertura: [SOLO CAMINO FELIZ / CASOS LÍMITE / COBERTURA COMPLETA DE RAMAS]. Mocking disponible para: [DEPENDENCIAS EXTERNAS a mockear].
Código a probar:
[PEGA EL CÓDIGO]
Formato: Archivo de test completo con: test para el camino feliz, tests para casos límite (entradas vacías, valores límite, null/undefined), tests para casos de error. Cada test tiene un nombre descriptivo que funciona como documentación.13. Scaffold de test de integración
Rol: Eres un ingeniero senior que escribe tests de integración para un endpoint de API.
Tarea: Escribe tests de integración para el endpoint [ENDPOINT].
Contexto: Framework: [EXPRESS/FASTAPI/RAILS, etc.]. Test runner: [JEST/PYTEST/RSpec]. Base de datos: [TIPO DE BASE DE DATOS]. Auth: [MÉTODO DE AUTH]. El endpoint hace: [DESCRIPCIÓN].
Formato: Archivo de test con setup/teardown, test de camino feliz, tests de fallo de autenticación, tests de error de validación y un caso límite específico de la lógica de negocio de este endpoint. Usa datos de test de apariencia realista, no "foo" y "bar".14. Prompt de generador de datos de test
Rol: Eres un desarrollador que crea fixtures de test realistas.
Tarea: Genera datos de test para el siguiente esquema/tipo.
Contexto: Esquema: [PEGA EL ESQUEMA O DEFINICIÓN DE TIPO]. Caso de uso: [PARA QUÉ SON ESTOS FIXTURES]. Los datos realistas importan porque: [POR QUÉ — p. ej., testing de búsqueda, testing de formato, testing de validación].
Formato: 5 objetos fixture como [JSON/YAML/LITERALES DEL LENGUAJE]. Cada uno debe representar un caso significativamente diferente: registro típico, caso límite (valores máximos, caracteres especiales), solo campos requeridos mínimos, y al menos uno que debería fallar la validación (etiquétalo).15. Limpieza de test de snapshot
Rol: Eres un desarrollador frontend que audita tests de snapshot.
Tarea: Revisa el siguiente test de snapshot y determina si está probando comportamiento significativo o simplemente bloqueando detalles de implementación.
Contexto: Componente: [NOMBRE DEL COMPONENTE]. Framework: [REACT / VUE / etc.]. Test runner: [JEST / VITEST].
Snapshot:
[PEGA EL SNAPSHOT]
Formato: Evaluación (¿es este snapshot significativo o frágil?), elementos específicos que vale la pena probar vs. elementos que causarán fallos falsos en refactorizaciones, y una aserción alternativa recomendada si el snapshot debe ser reemplazado.Plantillas de documentación (16–18)
16. Documentación de función/método
Rol: Eres un desarrollador que escribe documentación que realmente ayuda al siguiente lector.
Tarea: Escribe documentación para la siguiente función/método.
Contexto: Lenguaje: [LENGUAJE]. Formato de doc: [JSDoc / Python docstring / Go godoc / etc.]. Audiencia: desarrolladores no familiarizados con este módulo.
Código:
[PEGA LA FUNCIÓN]
Formato: Bloque de docstring/comentario completo con: descripción (qué hace, no cómo), parámetros (nombre, tipo, descripción), valor de retorno, excepciones/errores que lanza y un ejemplo de uso.17. Generador de README
Rol: Eres un desarrollador que escribe un README de proyecto para un repositorio público o interno.
Tarea: Escribe un README para el siguiente proyecto.
Contexto: Nombre del proyecto: [NOMBRE]. Qué hace en una oración: [PROPÓSITO]. Stack tecnológico: [STACK]. Audiencia: [DEVS INTERNOS / CONTRIBUIDORES DE CÓDIGO ABIERTO / AMBOS].
Secciones clave a incluir: [INSTALACIÓN / USO / CONFIG / CONTRIBUIR — lista lo que aplica].
Formato: README en Markdown con: nombre del proyecto + descripción en una línea, badges (dejar como marcadores), tabla de contenidos, instalación, uso con ejemplo de código, referencia de configuración (si aplica), guía de contribución (breve), licencia.18. Registro de Decisión de Arquitectura (ADR)
Rol: Eres un ingeniero senior que documenta una decisión técnica.
Tarea: Escribe un Registro de Decisión de Arquitectura para la siguiente decisión.
Contexto: Decisión: [QUÉ SE DECIDIÓ]. Opciones consideradas: [LISTA DE OPCIONES]. Fecha: [FECHA]. Estado: [PROPUESTO / ACEPTADO / OBSOLETO].
Formato: Formato ADR estándar — Título, Estado, Contexto (por qué se necesitaba una decisión), Decisión (qué se decidió y por qué), Consecuencias (resultados positivos, compensaciones negativas, riesgos). Menos de 500 palabras.Consejos para Cursor y GitHub Copilot
La mayoría de estas plantillas funcionan en ChatGPT o Claude a través del chat. Para Cursor y GitHub Copilot Chat, algunos ajustes mejoran los resultados:
Cursor: Usa el disparador de comentario inline (// [PROMPT] encima de una función) para refactorización específica. Para prompts más largos de revisión y documentación, Cursor Chat (Cmd+L) es mejor — pega tu plantilla allí. El flag de contexto @codebase incorpora automáticamente archivos relevantes, lo que puede reducir el Contexto que necesitas proporcionar manualmente.
GitHub Copilot Chat: Usa los comandos slash /explain, /fix y /tests como puntos de partida, luego añade tus requisitos de Formato. Por ejemplo: /tests Escribe tests siguiendo este formato: [tus requisitos de formato]. El resultado de Copilot Chat es más corto que el de Claude o GPT-4o — úsalo para prompts pequeños y contenidos y recurre a un modelo de chat completo para revisiones complejas.
Si estás construyendo una plantilla de prompt personalizada para el stack específico de tu equipo, el generador de prompts de IA te permite codificar el contexto de arquitectura, el lenguaje y las convenciones de tu equipo en los campos Rol y Contexto una sola vez, facilitando la generación de prompts consistentes para todo el equipo sin tener que re-especificar el mismo contexto del código base cada vez.
Preguntas frecuentes
¿Funcionan estas plantillas con Claude Sonnet en Cursor? Sí. Cursor soporta Claude Sonnet como modelo subyacente y estas plantillas funcionan tal como están en Cursor Chat. Para las completaciones inline (autocompletado por tab), los prompts no aplican — esas están impulsadas por el contexto del código circundante, no por prompts explícitos.
¿Cuánto contexto debo incluir al pegar código? Pega solo la función, clase o archivo directamente relevante. Añadir bases de código enteras hace que el modelo pierda el foco en la tarea real. Para el contexto arquitectónico, escribe 2–3 oraciones describiendo el sistema circundante — eso suele ser suficiente para obtener asesoramiento preciso.
¿Pueden los tests generados por IA reemplazar una estrategia de testing real? No. La IA es buena generando estructura de tests y cubriendo casos obvios rápidamente. No conoce tus reglas de negocio, tus modos de fallo de incidentes en producción ni los casos límite que realmente te afectan. Usa la IA para generar el scaffold (camino feliz, verificaciones de null, valores límite) y luego añade manualmente los tests específicos de lógica de negocio.
¿Debo usar ChatGPT o Claude para revisión de código? Claude 3.5 Sonnet y Claude 3.7 Sonnet tienden a dar feedback de código más preciso y menos verboso, y son mejores identificando errores lógicos sutiles. GPT-4o maneja bases de código multilingüe y frameworks poco comunes con más fiabilidad. Para la mayoría de los equipos, prueba ambos en 5 tareas reales de revisión de código y estandariza en el que produce feedback más accionable con menos falsos positivos.
¿Cómo mantengo las revisiones de código con IA consistentes en todo mi equipo? Estandariza en una plantilla de prompt y guárdala en un lugar compartido (Notion, README, instrucciones personalizadas de Cursor). La mayor fuente de inconsistencia no es el comportamiento del modelo — es que diferentes miembros del equipo hacen preguntas diferentes. Una plantilla compartida asegura que todos reciben las mismas categorías de feedback.