Prompts de programación y datos

16 plantillas para copiar y adaptar. Sustituye lo que va entre corchetes, revisa siempre el resultado y no incluyas datos personales o confidenciales.

Explicar un fragmento de código ajeno

Programación y datosCuando heredas código sin documentación y necesitas entender qué hace antes de tocarlo.

Actúa como desarrollador/a senior que hace revisión de código. Te paso un fragmento en [LENGUAJE]. Explícalo así: 1) propósito general en dos frases; 2) recorrido paso a paso de lo que hace, en orden de ejecución; 3) entradas y salidas esperadas, con un ejemplo concreto; 4) casos límite que podrían fallar (valores vacíos, nulos, grandes, caracteres especiales); 5) posibles problemas de seguridad o rendimiento. No reescribas el código salvo que lo pida. Si algo depende de código que no veo (funciones o variables externas), no supongas su comportamiento: indícalo como dependencia no verificada. Si hay partes que no puedes interpretar con certeza, di cuáles. Código: [PEGA AQUÍ]

Añade la versión del lenguaje o framework; el comportamiento puede cambiar entre versiones.
Pide después un test unitario para cada caso límite detectado.

Qué esperar: Una explicación en cinco apartados, con dependencias no verificadas y riesgos señalados. No pegues claves, contraseñas ni código propietario de terceros sin permiso.

Diagnosticar un error paso a paso

Programación y datosCuando un programa falla y quieres ordenar las hipótesis en lugar de probar cambios al azar.

Eres un/a ingeniero/a de software experto en depuración. Tengo este problema en [LENGUAJE/ENTORNO]: [DESCRIPCIÓN DEL COMPORTAMIENTO]. Comportamiento esperado: [ESPERADO]. Mensaje de error o traza: [ERROR]. Código relevante: [CÓDIGO]. Haz lo siguiente: 1) enumera las tres causas más probables, ordenadas por probabilidad, con el razonamiento; 2) para cada una, indica una comprobación concreta y barata que confirme o descarte la hipótesis; 3) propón la corrección más probable explicando por qué funciona; 4) indica qué información adicional necesitarías si ninguna encaja. No afirmes que has encontrado la causa si solo es una hipótesis. Si el error puede deberse a la versión de una librería, dilo.

Reduce el ejemplo al mínimo que reproduce el fallo; mejora mucho la calidad del diagnóstico.
Cuenta qué has probado ya para no recibir las mismas sugerencias.

Qué esperar: Una lista priorizada de hipótesis con comprobaciones, una corrección propuesta y los datos adicionales que harían falta. Prueba cualquier cambio en un entorno de desarrollo y con copia de seguridad antes de llevarlo a producción.

Revisión de código con criterios claros

Programación y datosAntes de fusionar una modificación, para detectar fallos, malas prácticas y problemas de mantenimiento.

Actúa como revisor/a de código exigente pero constructivo. Revisa el siguiente código en [LENGUAJE] pensado para [FINALIDAD]. Evalúa por separado: corrección (errores lógicos), seguridad (entradas sin validar, secretos expuestos, inyecciones), manejo de errores, legibilidad, nombres, duplicación y facilidad de prueba. Para cada hallazgo indica gravedad (alta, media, baja), línea o fragmento afectado, por qué es un problema y una propuesta concreta. Lista al final lo que está bien hecho. No inventes problemas para llenar la lista: si un apartado está correcto, dilo. Si no puedes juzgar algo por falta de contexto, indícalo. Limita la respuesta a los diez hallazgos más importantes. Código: [PEGA AQUÍ]

Indica las convenciones de estilo de tu equipo para evitar críticas irrelevantes.
Pide que separe lo imprescindible de las mejoras opcionales.

Qué esperar: Una lista de hasta diez hallazgos con gravedad y propuesta, más un apartado de aspectos positivos. Elimina secretos y datos reales antes de pegar el código y valida las sugerencias con tus propias pruebas.

Construir una consulta SQL y comprobarla

Programación y datosCuando necesitas una consulta a una base de datos y quieres asegurarte de que devuelve lo que pretendes.

Eres un/a analista de datos experto/a en SQL para [MOTOR DE BASE DE DATOS]. Esquema de las tablas (nombres y columnas): [ESQUEMA]. Necesito una consulta que responda a esta pregunta de negocio: [PREGUNTA]. Entrega: 1) la consulta formateada y comentada; 2) explicación de cada parte en lenguaje llano; 3) las suposiciones que has hecho sobre los datos (duplicados, nulos, zonas horarias, claves); 4) tres comprobaciones que puedo hacer para validar que el resultado es correcto, incluida una con un caso cuyo resultado conozco; 5) riesgos de rendimiento y de resultados engañosos, como uniones que multiplican filas. Si el esquema es insuficiente para responder con seguridad, pregúntame antes de escribir la consulta. Nunca uses instrucciones que modifiquen o borren datos.

Incluye unas pocas filas de ejemplo anonimizadas para evitar malinterpretaciones.
Prueba siempre primero con una copia o con LIMIT antes de lanzarla sobre tablas grandes.

Qué esperar: Una consulta comentada con sus supuestos, comprobaciones de validación y advertencias de rendimiento. No incluyas datos reales de personas y ejecuta la consulta en un entorno de pruebas antes de usarla.

Diseñar casos de prueba para una función

Programación y datosCuando has escrito una función y quieres cubrir los casos habituales y los límites antes de darla por buena.

Actúa como ingeniero/a de calidad de software. Para la función que pego abajo, en [LENGUAJE] con el marco de pruebas [MARCO], diseña un conjunto de pruebas unitarias. Primero, describe en una tabla los casos: entrada, resultado esperado, motivo del caso y categoría (normal, límite, inválido, regresión). Incluye como mínimo valores vacíos, nulos, extremos, tipos incorrectos y caracteres especiales cuando apliquen. Después escribe el código de las pruebas. El resultado esperado debe derivarse de la especificación que te doy, no de lo que el código haga hoy: si el código y la especificación discrepan, señálalo como posible error. Especificación: [QUÉ DEBE HACER]. Función: [CÓDIGO]. Si la especificación es ambigua, enumera las ambigüedades antes de escribir pruebas.

Escribe la especificación con ejemplos concretos de entrada y salida.
Ejecuta las pruebas y devuelve los fallos al asistente para analizarlos juntos.

Qué esperar: Una tabla de casos de prueba, el código de los tests y una lista de discrepancias o ambigüedades. Comprueba que las pruebas realmente se ejecutan y fallan cuando deben antes de fiarte de ellas.

Script para automatizar una tarea repetitiva

Programación y datosCuando haces a mano una tarea con ficheros o datos y quieres un script seguro que la sustituya.

Eres un/a desarrollador/a con experiencia en automatización con [LENGUAJE] en [SISTEMA OPERATIVO]. Necesito un script que haga esto: [TAREA]. Entrada: [FORMATO Y EJEMPLO]. Salida deseada: [SALIDA]. Requisitos: que no modifique ni borre los originales (trabajar sobre copias o escribir en una carpeta nueva); que muestre un resumen de lo que va a hacer y pida confirmación antes de escribir; que registre errores sin detenerse; que esté comentado en español. Después del código, explica cómo ejecutarlo, qué dependencias necesita y cómo probarlo primero con un caso pequeño. Enumera las suposiciones que has hecho y los casos en que podría fallar. Si la tarea es ambigua, formula tus preguntas antes de escribir código.

Pide un modo de simulación (dry-run) para ver qué haría sin cambiar nada.
Prueba con una carpeta de ejemplo antes de usarlo con información importante.

Qué esperar: Un script comentado con instrucciones de uso, dependencias, prueba inicial y lista de suposiciones. Haz una copia de seguridad antes de ejecutar cualquier script nuevo sobre tus archivos.

Documentación clara de una función o API

Programación y datosCuando necesitas que otras personas puedan usar tu código sin leerlo entero.

Actúa como redactor/a técnico/a para desarrolladores. Genera documentación en español para el siguiente código en [LENGUAJE]. Para cada función o endpoint incluye: descripción de una frase, parámetros (nombre, tipo, obligatorio u opcional, descripción, valores permitidos), valor devuelto, errores o excepciones posibles, un ejemplo mínimo de uso y notas sobre efectos secundarios. Usa el formato de comentarios habitual de [CONVENCIÓN, p. ej. docstrings o JSDoc] y después una versión resumida para un README. Documenta únicamente lo que se puede deducir del código: si el comportamiento no está claro, escribe [CONFIRMAR: duda] en vez de adivinar. Evita descripciones circulares que repiten el nombre de la función. Código: [PEGA AQUÍ]

Pega también un ejemplo real de llamada para que la documentación sea más fiel.
Revisa los marcadores CONFIRMAR con quien escribió el código original.

Qué esperar: Comentarios de documentación por función, un resumen para README y marcadores donde falte certeza. Verifica que los ejemplos funcionan ejecutándolos antes de publicar la documentación.

Plan de limpieza de una tabla de datos

Programación y datosAntes de analizar un conjunto de datos desordenado, para decidir qué corregir y qué dejar como está.

Eres un/a analista de datos especializado/a en calidad de datos. Te describo una tabla: columnas [COLUMNAS Y TIPOS], origen [ORIGEN], número de filas aproximado [FILAS] y estos problemas que he visto: [PROBLEMAS]. Elabora un plan de limpieza ordenado en pasos. Para cada paso indica: qué problema trata, cómo detectarlo, qué regla de corrección aplicar, qué riesgo tiene (por ejemplo, eliminar casos válidos) y cómo documentar el cambio para poder revertirlo. Distingue entre correcciones seguras y decisiones que dependen del criterio de negocio, y para estas últimas formula la pregunta que debo responder. No inventes valores para completar vacíos sin avisarme. Termina con una lista de verificación para comparar la tabla antes y después de limpiar.

Conserva siempre el original intacto y trabaja sobre una copia.
Registra cuántas filas afecta cada regla; sirve para detectar limpiezas excesivas.

Qué esperar: Un plan de pasos con reglas, riesgos, decisiones abiertas y una checklist de comparación. No pegues datos personales reales; usa descripciones de las columnas o muestras anonimizadas.

Comprobar que una librería y sus funciones existen

Programación y datosCuando la IA te propone código con librerías o funciones que no reconoces y temes que se las haya inventado.

Actúa como ingeniero/a de software prudente. Te pego un fragmento de código en [LENGUAJE] que usa estas librerías y funciones: [LISTA]. Para cada elemento entrega una tabla con: nombre, para qué se usa, tu nivel de confianza (alto, medio, bajo) en que exista tal como está escrito y en la versión [VERSIÓN], y dónde debo comprobarlo (documentación oficial del proyecto, gestor de paquetes o repositorio). Marca como «sospechoso» cualquier nombre que no puedas confirmar y no lo des por válido. No inventes parámetros, métodos ni números de versión. Añade una lista de verificación de seis pasos para validar el código en un entorno aislado, incluyendo revisar la licencia y el mantenimiento del paquete. Código: [PEGA AQUÍ]

Instala las dependencias en un entorno virtual o contenedor antes de ejecutar nada.
Desconfía de paquetes con nombre parecido a otros muy conocidos.

Qué esperar: Una tabla de elementos con confianza y dónde verificar, los sospechosos marcados y una checklist de seis pasos. Un paquete inexistente o malicioso con nombre creíble puede comprometer tu equipo: confirma siempre en la documentación oficial.

Mensajes de commit claros a partir de un cambio

Programación y datosCuando has hecho varias modificaciones y quieres un historial de versiones legible para el equipo.

Eres un/a desarrollador/a que cuida el historial de control de versiones. A partir de la descripción del cambio y del diff que pego, propón mensajes de commit en español con esta convención: primera línea de máximo 70 caracteres en imperativo, línea en blanco y cuerpo explicando qué cambia y por qué, no cómo. Si el cambio mezcla varias cosas, propón cómo dividirlo en commits separados y redacta un mensaje para cada uno. Menciona de forma explícita cualquier cambio que rompa la compatibilidad. Basa el mensaje solo en lo que ves en el diff: no inventes motivos, números de incidencia ni efectos que no pueda deducir; si necesitas el motivo, pregúntamelo. Contexto del proyecto: [CONTEXTO]. Diff: [PEGA AQUÍ]

Cuenta el motivo del cambio en una frase; el diff muestra qué, no por qué.
Pide una variante más corta si tu equipo prefiere mensajes de una línea.

Qué esperar: Uno o varios mensajes de commit con título y cuerpo, y una propuesta de división si el cambio es mixto. Revisa que el mensaje describa fielmente lo que hace el código y que el diff no contenga secretos antes de pegarlo.

Refactorizar sin cambiar el comportamiento

Programación y datosCuando quieres limpiar una función compleja pero te preocupa romper algo que ya funciona.

Actúa como especialista en refactorización con red de seguridad. Tengo esta función en [LENGUAJE] que hace [QUÉ HACE]. Quiero mejorar su legibilidad sin cambiar su comportamiento. Proceso: 1) antes de tocar nada, escribe una lista de pruebas de caracterización que fijen su comportamiento actual, incluidos casos límite y errores; 2) propone una secuencia de pasos pequeños de refactorización, cada uno revisable por separado; 3) muestra el código resultante; 4) indica cualquier punto en que el comportamiento podría cambiar sutilmente (orden de operaciones, redondeos, excepciones, efectos secundarios). Si detectas un posible error en el código original, avísame sin corregirlo en silencio. No asumas el contenido de código externo que no veo. Código: [PEGA AQUÍ]

Ejecuta las pruebas de caracterización contra el código antiguo antes de refactorizar.
Haz un commit por cada paso para poder volver atrás fácilmente.

Qué esperar: Una lista de pruebas, pasos de refactorización, el código final y un listado de posibles cambios sutiles. Solo confía en el resultado si las pruebas pasan antes y después en tu entorno.

Expresión regular explicada y probada con ejemplos

Programación y datosCuando necesitas validar o extraer texto con una expresión regular y no quieres usar una que no entiendes.

Eres un/a desarrollador/a experto/a en expresiones regulares para [LENGUAJE O MOTOR]. Necesito una expresión que [OBJETIVO]. Ejemplos que deben coincidir: [EJEMPLOS VÁLIDOS]. Ejemplos que NO deben coincidir: [EJEMPLOS INVÁLIDOS]. Entrega: 1) la expresión; 2) explicación de cada fragmento; 3) una tabla con al menos diez casos de prueba (incluidos vacíos, espacios, acentos y mayúsculas) y el resultado esperado de cada uno; 4) limitaciones: qué casos reales no cubre; 5) riesgos de rendimiento por retroceso excesivo. Indica si alguna parte puede comportarse distinto según el motor o la configuración regional. Si el objetivo se resuelve mejor sin expresión regular, dilo. Para validar datos como correos o teléfonos, avisa de que una expresión no garantiza que el dato exista.

Prueba la expresión con tus propios datos reales anonimizados, no solo con los ejemplos.
Evita validar con una sola expresión estructuras muy complejas.

Qué esperar: Una expresión con explicación por partes, una tabla de diez casos, limitaciones y advertencias de rendimiento. Ejecuta las pruebas en tu motor concreto; los resultados pueden diferir de lo que el asistente supone.

Revisión de seguridad de un formulario web

Programación y datosCuando has creado un formulario o endpoint que recibe datos de usuarios y quieres detectar fallos comunes.

Actúa como especialista en seguridad de aplicaciones web con enfoque defensivo. Revisa el código de [FORMULARIO O ENDPOINT] en [LENGUAJE Y FRAMEWORK] que pego abajo. Comprueba, uno por uno: validación y saneamiento de entradas, protección frente a inyección, escape de salida, control de acceso, gestión de sesiones, protección contra falsificación de peticiones, límites de tamaño, manejo de errores sin filtrar información interna y almacenamiento de datos sensibles. Para cada punto responde: cumple, no cumple o no puedo juzgar por falta de contexto, con el fragmento afectado y una corrección sugerida. No inventes vulnerabilidades. Al final, añade una checklist de verificación con pruebas manuales que puedo hacer en un entorno de desarrollo. Nada de instrucciones para atacar sistemas ajenos. Código: [PEGA AQUÍ SIN CLAVES NI DATOS REALES]

Indica dónde se ejecuta el código (servidor, navegador) para enfocar la revisión.
Complementa la revisión con una herramienta de análisis estático especializada.

Qué esperar: Un informe punto por punto con estado, fragmento, corrección y una checklist de pruebas en entorno de desarrollo. Una revisión con IA no sustituye a una auditoría de seguridad profesional ni garantiza que el código sea seguro.

Diseño de una API sencilla y coherente

Programación y datosAntes de programar los puntos de acceso de un servicio, para acordar nombres, errores y formatos.

Eres un/a arquitecto/a de software con experiencia en APIs REST. Diseña la API para [DESCRIPCIÓN DEL SERVICIO], con estas entidades principales: [ENTIDADES] y estos usuarios: [ROLES]. Entrega: 1) tabla de recursos con ruta, método, descripción y quién puede usarla; 2) ejemplos de petición y respuesta en JSON; 3) convención de errores con códigos y mensajes; 4) estrategia de paginación, filtrado y versionado; 5) decisiones que dependen del negocio y sobre las que debo opinar, planteadas como preguntas. Mantén un único criterio de nombres. No añadas funcionalidades que no haya pedido. Menciona las consideraciones de seguridad que debo tomar en cuenta sin dar por resuelto nada. Si hay varias alternativas razonables, explica las ventajas y los inconvenientes de cada una.

Escribe primero tres casos de uso reales; el diseño saldrá más ajustado.
Valida el diseño con quien consumirá la API antes de programar.

Qué esperar: Una especificación inicial con rutas, ejemplos JSON, errores, paginación y una lista de decisiones abiertas. Es un borrador de diseño: revisa autenticación, permisos y protección de datos con criterios propios o de un especialista.

Interpretar registros de errores de una aplicación

Programación y datosCuando tienes un fichero de logs largo y necesitas encontrar el patrón detrás de un fallo.

Actúa como ingeniero/a de fiabilidad (SRE) experto/a en análisis de registros. Te pego un extracto de logs de [APLICACIÓN O SERVICIO] sin datos personales. El problema observado es [SÍNTOMA] y empezó hacia [MOMENTO]. Entrega: 1) cronología de los eventos relevantes; 2) errores agrupados por tipo con frecuencia aproximada; 3) las tres hipótesis más probables del origen, con la evidencia del texto que apoya cada una; 4) qué datos adicionales pediría (otros registros, métricas, cambios recientes); 5) pasos de diagnóstico ordenados del más barato al más costoso. Distingue siempre entre lo que se ve en los registros y lo que es deducción. No afirmes una causa raíz con este solo extracto. Registros: [PEGA AQUÍ]

Incluye marcas de tiempo y la zona horaria para ordenar bien los hechos.
Pega también los cambios o despliegues recientes; suelen ser la clave.

Qué esperar: Una cronología, agrupación de errores, tres hipótesis con evidencia, datos adicionales a solicitar y pasos de diagnóstico. Elimina antes cualquier dato personal, token o dirección interna de los registros.

Plan de migración de código o de versión con control de riesgos

Programación y datosCuando debes pasar un proyecto a otra versión de un lenguaje, librería o framework y quieres hacerlo por etapas y con comprobaciones.

Actúa como ingeniero/a de software con experiencia en migraciones graduales. Mi proyecto usa [TECNOLOGÍA Y VERSIÓN ACTUAL] y quiero pasar a [VERSIÓN OBJETIVO]. Tamaño aproximado: [MÓDULOS O LÍNEAS]. Cobertura de pruebas actual: [COBERTURA]. Entrega: 1) inventario de qué debo revisar (dependencias, APIs obsoletas, configuración, compilación); 2) plan por etapas pequeñas y reversibles, con criterio de salida de cada una; 3) estrategia de pruebas antes, durante y después; 4) riesgos principales con medida de mitigación; 5) plan de vuelta atrás. No afirmes qué cambios concretos trae cada versión ni inventes nombres de funciones obsoletas: indica que debo consultar las notas de versión oficiales y señala [VERIFICAR EN DOCUMENTACIÓN OFICIAL] en cada punto que dependa de ellas. Termina con una checklist de seis puntos previa al despliegue.

Migra primero un módulo pequeño y poco crítico para medir el esfuerzo real.
Congela funcionalidades nuevas durante la migración para aislar los fallos.

Qué esperar: Un plan por etapas con inventario, pruebas, riesgos, vuelta atrás y checklist, con los puntos dependientes de la documentación oficial marcados. Contrasta cada paso con las notas de versión oficiales y prueba todo en un entorno separado antes de tocar producción.