Ingeniería de prompts: cómo conversar mejor con las LLM sin depender del ensayo y error

Abres ChatGPT, Copilot u otra herramienta con LLM y escribes: “ayúdame con este error”. La respuesta llega rápido, con confianza, bien formateada y… no ayuda tanto. Tal vez sea demasiado genérica. Tal vez asuma un stack que ni siquiera usas. Tal vez proponga una solución que parece buena en teoría, pero no encaja con el problema real ni aunque reces.

Este es un buen punto de partida para hablar de ingeniería de prompts: no como una colección de frases mágicas, sino como la práctica de hacer más explícita tu intención para el modelo. En lugar de lanzar una pregunta aislada y esperar lo mejor, describes el objetivo, el contexto, las restricciones, el formato esperado y los criterios de calidad.

Esto no convierte a la LLM en una fuente infalible. Tampoco elimina la revisión, las pruebas ni el sentido crítico. Pero reduce las ambigüedades y aumenta la probabilidad de recibir una respuesta útil, verificable y más fácil de ajustar.

TL;DR

• La ingeniería de prompts es la práctica de estructurar mejor las instrucciones para las LLM.
• Los buenos prompts dejan claro el objetivo, el contexto, el papel, las restricciones, el formato, los ejemplos y los criterios de calidad.
• Más contexto suele ayudar, pero un contexto excesivo, desordenado o irrelevante puede dificultar la tarea.
• Las LLM pueden equivocarse, inventar información y sonar seguras incluso cuando están equivocadas.
• Usa la respuesta como apoyo para pensar, escribir, planificar o diagnosticar, no como una decisión final sin validación.

La ingeniería de prompts consiste menos en una “frase mágica” y más en explicitar la intención

Un prompt vago deja muchas decisiones en manos del modelo.

Por ejemplo:

Haz un resumen de esto.

Esta petición puede generar respuestas muy diferentes dependiendo de lo que el modelo “entienda” como importante. ¿Es un resumen para estudiar? ¿Para enviarlo al equipo? ¿Para una persona ejecutiva? ¿Debe incluir ejemplos? ¿Debe conservar los términos técnicos? ¿Debe señalar dudas?

Ahora compáralo con una versión más estructurada:

Resume el texto siguiente para una persona desarrolladora junior que está estudiando el tema.
Prioriza los conceptos principales, los ejemplos prácticos y las dudas abiertas.
Usa hasta 8 puntos.
Separa claramente los hechos presentados en el texto de tus propias interpretaciones.

La segunda versión no es perfecta, por supuesto. Pero comunica mejor la intención. Reduce el espacio para interpretaciones no deseadas y facilita revisar la respuesta después.

En este sentido, la ingeniería de prompts puede verse como una especie de especificación ligera. No sustituye los requisitos, la documentación, la conversación con las personas usuarias ni los criterios de aceptación. Aun así, ayuda a organizar lo que ya sabes sobre la tarea antes de pedir ayuda.

Esta idea combina bien con prácticas cuidadosas de desarrollo: claridad, feedback corto, revisión y mejora continua. El valor no está en “obtener una respuesta lista”, sino en mejorar la calidad de la conversación con la herramienta.

¿Por qué varían tanto las respuestas?

Las LLM generan respuestas a partir de patrones de lenguaje y del contexto recibido. No “entienden” una tarea de la misma manera que la entendería una persona de tu equipo después de participar en reuniones, leer el código, conocer las restricciones del negocio y sufrir contigo cuando el pipeline falla un viernes por la tarde.

Cuando la petición está incompleta, el modelo debe llenar los vacíos. Y ahí empiezan las suposiciones. Algunas preguntas quedan sin respuesta:

• ¿Para quién es la respuesta?
• ¿Cuál es el objetivo?
• ¿Qué profundidad se espera?
• ¿Qué debe evitarse?
• ¿Cómo se utilizará la salida?
• ¿Qué tecnologías, reglas y limitaciones son importantes?

Mira un ejemplo en desarrollo.

Petición vaga:

Crea una API de usuarios.

Esta petición puede generar una API REST o GraphQL, con autenticación JWT o sin ella, usando Node.js, Java o Python, con una base de datos relacional, una base en memoria, una arquitectura en capas, una arquitectura minimalista… El menú es amplio.

Una versión más útil sería:

Quiero una propuesta de diseño para una API REST de usuarios en Java 21 con Spring Boot.
Contexto: la aplicación ya usa PostgreSQL y autenticación mediante JWT.
La API debe permitir la creación, la consulta por ID, el listado paginado y la desactivación de usuarios.
Restricciones: no incluir eliminación física; no usar bibliotecas distintas de las que ya son habituales en Spring Boot; considerar la validación de que el correo electrónico sea único.
Formato de la respuesta: enumera los endpoints, los payloads de entrada, las respuestas esperadas, las reglas de negocio y los criterios de aceptación.
Si falta información, enumera las preguntas antes de asumir.

La diferencia no está en “convencer” a la IA con una frase secreta. Está en eliminar ambigüedades.

Por otro lado, existe un trade-off: más contexto suele mejorar la adecuación de la respuesta, pero un contexto excesivo, desorganizado o irrelevante puede confundir la tarea. Un prompt de muchos párrafos con historial, opiniones, logs sueltos y requisitos mezclados puede convertirse en un cajón desordenado.

A veces, el mejor prompt es el que proporciona lo necesario: ni menos ni mucho más.

Ingeniería de prompts en la práctica: una estructura sencilla

Una forma práctica de mejorar tus prompts es utilizar un checklist. No como una fórmula rígida, porque una fórmula demasiado rígida se convierte en burocracia con otro nombre, sino como un recordatorio de lo que suele influir en la calidad de la respuesta.

Objetivo

Di claramente qué quieres obtener.

En lugar de:

Ayúdame con esto.

Prefiere:

Explica este error y propone pasos de diagnóstico antes de sugerir correcciones.

O:

Revisa este texto para hacerlo más claro para personas no técnicas, sin cambiar su significado.

El objetivo define el “tipo de ayuda” esperado. Diagnosticar, resumir, revisar, comparar, planificar y explicar son tareas diferentes. Cuando el objetivo no aparece, el modelo tiende a elegir un camino por su cuenta.

Contexto

Incluye la información necesaria para la tarea: escenario, público, tecnología, datos disponibles y decisiones ya tomadas.

Por ejemplo:

Estoy investigando un fallo en una prueba de integración de una aplicación Java con Spring Boot.
La prueba debería devolver HTTP 201 al crear un usuario, pero está devolviendo 400.
La validación de correo electrónico único se añadió recientemente.
Quiero hipótesis priorizadas, no una corrección directa todavía.

Contexto no significa volcarlo todo. Significa proporcionar al modelo las piezas relevantes del rompecabezas.

Una precaución importante: no envíes contraseñas, tokens, datos personales, información de clientes, fragmentos confidenciales ni código propietario sin autorización y sin comprender las políticas de la herramienta utilizada. Un buen prompt no compensa una filtración de información sensible.

Papel o perspectiva

Pedir un papel puede ayudar cuando delimita el tipo de análisis.

Ejemplo:

Analiza como una persona que revisa código Java para identificar riesgos de legibilidad, mantenimiento y comportamiento inesperado.

Esto es mejor que simplemente decir:

Actúa como especialista.

“Actúa como especialista” por sí solo no resuelve la falta de contexto. Es como pedirle a alguien que “sea senior” sin explicar el problema, el sistema, las restricciones y lo que debe decidirse. Puede sonar bien, pero no aporta mucho.

Usa los papeles para indicar una perspectiva, no como una orden de autoridad.

Restricciones

Las restricciones evitan soluciones incompatibles con la realidad.

Ejemplos:

No uses bibliotecas externas.
Considera Java 21.
Mantén la solución en un máximo de dos clases.
No propongas cambios en la API pública.
Prioriza alternativas con menor impacto en el código existente.

Las restricciones son especialmente útiles cuando existen muchas soluciones posibles. Además, ayudan a evitar respuestas que parecen excelentes en un proyecto idealizado, pero son impracticables en tu contexto.

Formato de salida

Pedir un formato ayuda a utilizar y revisar la respuesta.

Ejemplos:

Responde con: hipótesis, evidencia en el código, riesgo, sugerencia de corrección y prueba recomendada.

O:

Organiza la respuesta en una tabla con las columnas: problema, impacto, prioridad y acción sugerida.

O también:

Responde en etapas numeradas, empezando por las comprobaciones que no modifican el código.

El formato no es un detalle cosmético. Guía el razonamiento y hace que la respuesta sea más auditable. Cuando la salida está organizada, es más fácil distinguir qué es una suposición, qué es una recomendación y qué debe validarse.

Ejemplos

Cuando el tono, el formato o el estándar de calidad sean difíciles de explicar, proporciona un ejemplo.

Por ejemplo:

Usa este estilo de respuesta: - “Confirmado”: información presente en el texto. - “Hipótesis”: interpretación posible, pero no comprobada. - “Pregunta abierta”: algo que debe validarse.

Los ejemplos orientan bastante la salida. El trade-off es que también pueden limitar alternativas mejores. Si proporcionas un ejemplo demasiado rígido, quizá el modelo copie el patrón incluso cuando otro formato sería más adecuado.

Criterios de calidad

Explica cómo pretendes evaluar la respuesta.

Ejemplos:

Si falta información, enumera las preguntas antes de asumir detalles.

Diferencia hechos, hipótesis y recomendaciones.

Señala los riesgos y las pruebas necesarias antes de sugerir una implementación.

No inventes bibliotecas, APIs ni referencias. Si no lo sabes, di que necesitas comprobarlo.

Los criterios de calidad cambian la conversación. En lugar de pedir solo una respuesta, pides una respuesta que pueda revisarse.

Esto es importante porque una respuesta “bonita” puede estar equivocada. Los criterios explícitos ayudan a reducir ese riesgo, pero no sustituyen la validación.

De la petición vaga al prompt útil: ejemplos prácticos

La mejor forma de entender la ingeniería de prompts es observar la diferencia entre una petición aislada y una instrucción más clara. Los ejemplos siguientes no son “prompts universales listos para usar”. Son modelos de razonamiento que puedes adaptar a tu contexto.

Desarrollo: investigar un error

Petición inicial:

¿Por qué está fallando mi prueba?

Problemas de esta petición:

• no muestra el error;
• no muestra el comportamiento esperado;
• no informa el lenguaje, el framework ni el entorno;
• no solicita un tipo específico de ayuda;
• fomenta las suposiciones.

Versión revisada:

Estoy investigando una prueba de integración que falla en una aplicación Java 21 con Spring Boot.
Comportamiento esperado: al enviar una petición válida para crear un usuario, la API debe devolver HTTP 201.
Comportamiento actual: la prueba devuelve HTTP 400.
Cambio reciente: añadimos la validación de correo electrónico único.
A continuación se incluyen el fragmento de la prueba, el payload y el mensaje de error.
Quiero que propongas hipótesis priorizadas. Para cada hipótesis, indica: evidencia, cómo verificarla y una posible corrección.
No propongas cambios de código antes de enumerar las comprobaciones.

Cómo revisar la salida:

• intenta reproducir el problema;
• valida cada hipótesis;
• comprueba que la sugerencia respeta la arquitectura del proyecto;
• no apliques una corrección sin entender la causa;
• ejecuta las pruebas después.

La LLM puede acelerar la investigación, pero no ejecuta el sistema por ti. Al menos no en este escenario. Y mejor así: alguien tiene que seguir pulsando el botón rojo con responsabilidad.

Escritura: revisar un mensaje técnico

Petición inicial:

Mejora este mensaje.

Versión revisada:

Revisa el mensaje siguiente para comunicar una actualización de un incidente a personas no técnicas.
Contexto: hubo inestabilidad en el inicio de sesión entre las 10:00 y las 10:25. El servicio ya fue restablecido. Todavía no tenemos confirmada la causa raíz.
Restricciones: no inventes la causa; no minimices el impacto; separa el impacto actual de los próximos pasos.
Formato: título, resumen, impacto, estado actual y próxima actualización.
Tono: claro, directo y sin lenguaje defensivo.

Este tipo de prompt es útil porque evita un error común: que el modelo “embellezca” demasiado el mensaje y termine afirmando cosas que aún no se han confirmado.

Cuando se trata de un incidente, la claridad importa más que el adorno. Si la causa raíz aún no está confirmada, el texto debe decirlo. Si el impacto existió, el texto no debe ocultarlo. El prompt ayuda a hacer explícitos esos límites.

Resumen: convertir contenido extenso en material de estudio

Petición inicial:

Resume este texto.

Versión revisada:

Resume el texto siguiente como material de estudio para una persona principiante en el tema.
Incluye: - conceptos principales; - ejemplos citados; - términos que merecen revisión; - dudas abiertas; - una lista de 5 preguntas para autoevaluación.
Limita la respuesta aproximadamente a una página.
No añadas información externa al texto.

Cómo revisar la salida:

• compárala con el material original;
• comprueba si se omitieron matices importantes;
• verifica que el modelo no haya añadido interpretaciones propias como si fueran hechos;
• usa el resumen como apoyo, no como sustituto de la lectura.

Los resúmenes son útiles, pero pueden aplanar ideas complejas. A veces, el detalle que quedó fuera era precisamente el más importante.

Planificación: descomponer una tarea

Petición inicial:

Planifica esta feature.

Versión revisada:

Quiero descomponer una entrega pequeña en etapas de implementación.
Contexto: necesitamos añadir la opción de desactivar usuarios sin eliminar registros de la base de datos.
La aplicación ya tiene un endpoint de creación y otro de consulta.
Genera una propuesta con: - etapas técnicas; - dependencias; - riesgos; - preguntas abiertas; - sugerencias de pruebas.
No estimes plazos. No asumas cambios en las pantallas, porque todavía no sabemos si habrá una interfaz.

Este tipo de respuesta puede ayudar a iniciar mejor una conversación con el equipo. Sin embargo, las prioridades, el esfuerzo y la secuencia real dependen del contexto del equipo, del producto y del sistema existente.

Aquí, la principal ganancia no es delegar la planificación. Es crear una primera estructura para discutir mejor: qué falta decidir, dónde están los riesgos y qué pruebas pueden proteger el cambio.

Análisis: interpretar datos o resultados

Petición inicial:

Analiza estos números.

Versión revisada:

Analiza los datos siguientes basándote únicamente en la información proporcionada.
Quiero que: - describas las tendencias observables; - diferencies una conclusión sólida de una hipótesis; - señales las lagunas de los datos; - menciones posibles sesgos; - indiques qué conclusiones no pueden sostenerse.
No inventes contexto externo.

Esta precaución es esencial porque las LLM tienden a completar narrativas. Si les proporcionas una tabla incompleta, el modelo puede producir una explicación plausible, pero sin base suficiente.

En estos casos, un buen prompt no pide solo “un análisis”. También establece límites: qué puede concluirse, qué es una hipótesis y qué todavía requiere mejores datos.

Un ciclo práctico para escribir, probar y revisar

La ingeniería de prompts es iterativa. Se parece más a refinar una especificación, una búsqueda o una prueba exploratoria que a escribir una contraseña encantada.

Un ciclo sencillo ayuda.

Escribe la primera versión

Empieza con el objetivo y el contexto mínimo.

Por ejemplo:

Quiero revisar este fragmento de documentación para hacerlo más claro para personas desarrolladoras junior.
Mantén un tono didáctico.
Señala las ambigüedades antes de reescribir.

No intentes anticipar todas las posibilidades desde el principio. Una primera versión suficientemente buena ya permite aprender de la respuesta.

Inspecciona la respuesta

Después de recibirla, pregunta:

• ¿Atiende al objetivo?
• ¿Respetó las restricciones?
• ¿Inventó información?
• ¿Explicó sus suposiciones?
• ¿El formato facilita utilizar o validar el resultado?
• ¿Faltó algún dato importante?

Esta es la etapa en la que muchas personas pierden calidad. La respuesta llega bonita, formateada y segura; la tentación es copiarla y continuar. Pero un texto bien escrito no equivale a una respuesta correcta.

Refina la instrucción

Usa lo que salió mal para mejorar el prompt.

Ejemplos de refinamiento:

Prioriza alternativas con menor impacto en el código existente.

No propongas cambios en la API pública.

Antes de responder, enumera la información ausente que podría cambiar la recomendación.

Separa “lo que sabemos” de “lo que debe verificarse”.

Refinar no significa “pelearse” con la herramienta. Significa ajustar la especificación.

Si la respuesta fue genérica, quizá falte contexto. Si fue demasiado larga, quizá falte una restricción. Si inventó detalles, quizá falten criterios de calidad y validación. El prompt mejora cuando observas el tipo de error que apareció.

Valida fuera de la conversación

Esta es la parte menos glamurosa y más importante.

Valida mediante:

• código ejecutable;
• pruebas automatizadas;
• documentación oficial;
• fuentes primarias;
• datos originales;
• revisión humana;
• criterios definidos por el equipo.

Pedirle a la propia LLM que “confirme si es correcto” no es una validación independiente. Puede repetir el error con mayor convicción. Es el equivalente conversacional de preguntarle a tu bug si está seguro de que es un bug.

Las herramientas pueden apoyar el análisis, la generación de escenarios y la investigación, pero siguen exigiendo validación técnica. La decisión final debe considerar el sistema real, las restricciones del equipo y el impacto del cambio.

Límites y cuidados al usar LLM en el trabajo y los estudios

Las LLM son útiles, pero tienen límites importantes. El problema es que pueden equivocarse con una redacción muy convincente.

Alucinaciones y verificabilidad

La LLM puede inventar:

• APIs que no existen;
• parámetros incorrectos;
• comportamientos de bibliotecas;
• referencias;
• justificaciones;
• detalles sobre código que no ha visto.

Por eso, pide respuestas verificables.

Ejemplo:

Si mencionas una API, indica cómo puedo verificarla en la documentación oficial.
Si no estás seguro, señala la incertidumbre en lugar de afirmarlo.

Aun así, no delegues la verificación. Ejecuta el código. Consulta la documentación. Comprueba el repositorio. Pon a prueba la hipótesis.

Ambigüedad

Si la petición permite interpretaciones diferentes, la respuesta puede seguir una dirección inesperada.

Una buena práctica es pedir preguntas de aclaración:

Si la información es insuficiente para una recomendación segura, haz hasta 5 preguntas antes de responder.

Esto es especialmente útil en arquitectura, requisitos, análisis de datos y decisiones de producto.

Cuando el modelo pregunta antes de responder, la conversación puede volverse un poco más lenta. A cambio, la respuesta tiende a alinearse mejor con el problema real. Es un buen trade-off cuando una suposición equivocada puede salir cara.

Datos sensibles

Evita introducir:

• contraseñas;
• tokens;
• claves de API;
• datos personales;
• información de clientes;
• secretos comerciales;
• código confidencial;
• logs con datos sensibles;
• documentos internos sin autorización.

Antes de utilizar una herramienta en el trabajo, comprende las políticas de la organización y de la propia herramienta. Si no sabes si puedes enviar algo, trátalo como si no pudieras.

Un prompt bien estructurado no justifica exponer información sensible. Cuando sea necesario, elimina o anonimiza los datos antes de pedir ayuda, siguiendo las reglas de tu organización.

Responsabilidad por la decisión

Usa las LLM para:

• explorar opciones;
• organizar ideas;
• generar borradores;
• revisar la claridad;
• plantear hipótesis;
• crear checklists;
• comparar alternativas.

Pero ten cuidado al utilizar sus respuestas en decisiones críticas, especialmente en seguridad, datos, salud, finanzas, asuntos legales o software en producción. La responsabilidad sigue siendo humana y organizacional.

La herramienta puede ayudar a pensar. No debe ser el piloto automático de decisiones que requieren contexto, responsabilidad y validación.

Checklist final para tu próximo prompt

Antes de enviar tu próximo prompt, revisa:

• ¿Qué resultado quiero?
• ¿Qué contexto es indispensable?
• ¿Para quién y para qué uso se producirá esta respuesta?
• ¿Qué límites o restricciones deben respetarse?
• ¿En qué formato debe venir la respuesta?
• ¿Ayudaría un ejemplo a reducir la ambigüedad?
• ¿Cómo verificaré la respuesta antes de utilizarla?

Una versión compacta de un prompt podría seguir este modelo:

Quiero [objetivo].
Contexto: [información relevante].
Público/uso: [quién lo utilizará y para qué].
Restricciones: [límites, tecnologías, tono, alcance].
Formato: [estructura esperada].
Criterios de calidad: [cómo evaluar].
Si falta información, [pregunta antes de asumir / explicita las suposiciones].

Los mejores prompts no dependen de palabras secretas. Dependen de una intención, un contexto y unos criterios claros.

Para empezar, elige una tarea habitual: revisar un mensaje, resumir un texto, investigar un error o planificar una pequeña entrega. Primero, haz una petición vaga. Después, reescríbela utilizando la estructura de este artículo. Compara las respuestas. Este contraste suele enseñar más que memorizar cualquier lista de “prompts perfectos”.

Próximos pasos

• Elige una tarea real que ya harías hoy con apoyo de una LLM.
• Escribe una primera versión del prompt utilizando objetivo, contexto, restricciones y formato.
• Revisa la respuesta en busca de suposiciones, lagunas y puntos no verificables.
• Refina el prompt una vez y compara el resultado.
• Valida fuera de la conversación antes de utilizar la respuesta.

Si te gusta conversar sobre prácticas de desarrollo, calidad y uso responsable de la IA en el día a día, participa en la comunidad SCCB.