Playbook de ingeniería de prompts para programadores
(addyo.substack.com)- Los asistentes de codificación con IA aumentan la productividad de los desarrolladores, pero la calidad de sus resultados depende en gran medida de la ingeniería de prompts
- Para obtener resultados efectivos, hay que seguir reglas como dar contexto abundante, definir objetivos concretos, incluir ejemplos, asignar un rol y mejorar de forma iterativa
- Se ofrecen patrones de diseño de prompts y ejemplos para tareas clave de desarrollo como depuración, refactorización e implementación de nuevas funciones
- Un buen prompt debe incluir información específica como objetivo, lenguaje, entorno, mensajes de error y ejemplos de entrada/salida
- Es un método de diseño de prompts que incluso un ingeniero nuevo puede seguir, e incluye comparaciones de respuestas reales de IA y comentarios
Resumen general: la importancia de una ingeniería de prompts exitosa
- En los últimos tiempos, los desarrolladores usan asistentes de codificación con IA para acelerar su flujo de trabajo, desde el autocompletado de funciones y la corrección de bugs hasta la escritura de módulos completos
- Sin embargo, la calidad de las respuestas de la IA depende de forma decisiva de la calidad del prompt
- Un buen prompt guía hacia soluciones de código claras y creativas, mientras que un prompt ambiguo o pobre conduce a respuestas limitadas y poco útiles
- Este playbook organiza de forma práctica métodos efectivos de diseño de prompts aplicables a tareas cotidianas de desarrollo
Principios básicos de un prompt de código efectivo
- Proporcionar contexto abundante: la IA no conoce de antemano el proyecto ni la intención, así que hay que especificar toda la información relevante, como lenguaje, framework, librerías, mensajes de error y objetivo del código
- Plantear un objetivo o pregunta claros: en lugar de una consulta ambigua como “¿por qué no funciona el código?”, hay que describir claramente el resultado esperado y la situación actual
- Dividir las tareas complejas: en trabajos como el desarrollo de funcionalidades grandes, conviene no pedir todo de una sola vez, sino dividirlo en pasos pequeños y avanzar gradualmente
- Incluir ejemplos de entrada/salida o comportamiento esperado: si se proporcionan ejemplos reales de entrada, salida o comportamiento, la comprensión de la IA mejora mucho ("few-shot prompting")
- Usar roles (personas): asignar funciones responsables como “revisa el código como un desarrollador senior de React” o “optimiza esto como especialista en rendimiento” eleva el nivel de la respuesta de la IA
- Mejora iterativa conversacional: a partir de la primera respuesta de la IA, se puede llegar gradualmente al resultado deseado mediante solicitudes adicionales o pedidos de corrección
- Mantener consistencia en el código: como la IA toma como referencia el estilo, los nombres y los comentarios del código, hay que mantener siempre consistencia y claridad
Patrones de prompts para depuración
Cómo diseñar un prompt de depuración sistemático
- Describir claramente el problema y los síntomas: proporcionar información abundante como lenguaje, propósito de la función, comportamiento esperado, mensaje de error real y fragmentos de código
- Pedir análisis paso a paso o línea por línea: en errores lógicos o bugs sutiles, se puede hacer que identifique la causa con instrucciones como “rastrea las variables línea por línea” o explicando partes del código
- Usar código mínimo reproducible: en vez de usar código grande y complejo, extraer la unidad mínima donde ocurre el error permite diagnosticar el problema de forma más focalizada
- Hacer preguntas directas y solicitudes de seguimiento: pedir retroalimentación clara y repetible como “¿dónde ocurre el bug?” o “proporciona el código corregido”
Ejemplo: prompt deficiente vs. prompt mejorado
Ejemplo de código con problema
function mapUsersById(users) {
const userMap = {};
for (let i = 0; i <= users.length; i++) {
const user = users[i];
userMap[user.id] = user;
}
return userMap;
}
const result = mapUsersById([{ id: 1, name: "Alice" }]);
Prompt deficiente:
“¿Por qué no funciona la función mapUsersById?”
- Respuesta de la IA: presenta suposiciones vagas como “puede que el arreglo esté vacío” o “tal vez user no tenga id”
- Solo salen consejos generales por la falta de contexto y la ambigüedad
Prompt mejorado:
“La función mapUsersById debe mapear un arreglo de usuarios por id, pero con la entrada [ {id: 1, name: "Alice"} ] aparece el error TypeError: Cannot read property 'id' of undefined. El código es el siguiente: [incluir código]. El resultado esperado es algo como { "1": ... }. ¿Cuál es la causa de este comportamiento y cómo se resuelve?”
- Respuesta de la IA: señala que la condición del bucle (i <= users.length) excede el rango y produce
undefineden la última iteración, y propone cambiarlo por i < users.length - Al proporcionar contexto concreto, mensaje de error y comportamiento esperado, se obtiene una solución precisa
Estrategias adicionales de prompts para depuración
- Pedir una lista de posibles causas del bug (“¿cuáles son las posibles causas del TypeError?”)
- Explicar directamente la lógica del código y luego pedir revisión (“dime si mi explicación es correcta y encuentra el problema”)
- Pedir casos de prueba para situaciones inesperadas (“solo sugiere 2 entradas con las que esta función podría fallar”)
- Asignar el rol de revisor minucioso de código (“revisa este código y explica sus problemas y mejoras”)
Patrones de prompts para refactorización/optimización
Presentar objetivos de mejora claros
- “Refactoriza esto” es ambiguo, así que hay que especificar objetivos concretos como legibilidad, rendimiento, mantenibilidad o eliminación de código duplicado
- Proporcionar suficiente contexto: el código completo (o el necesario), el entorno, el lenguaje y la versión del framework
- Pedir también una explicación de los cambios (“muéstrame el código junto con los puntos de mejora”)
- Asignar un rol como “como experto en TypeScript, ajústalo a las prácticas más modernas” para elevar la calidad esperada
Ejemplo: comparación de prompts de refactorización
Código original
(incluye problemas como fetch duplicado y estructuras de datos poco eficientes)
async function getCombinedData(apiClient) {
// Fetch list of users
const usersResponse = await apiClient.fetch('/users');
if (!usersResponse.ok) {
throw new Error('Failed to fetch users');
}
// ... (se omite el resto)
}
Prompt ambiguo
“Refactoriza la función getCombinedData”
- La IA puede cambiar cosas arbitrariamente, como paralelizar
fetcho unificar mensajes de error (como no hay requisitos, su comportamiento es impredecible)
Prompt con objetivos concretos
“Elimina duplicación, mejora el rendimiento, paraleliza los dos fetch, separa los mensajes de error y mejora la combinación de datos con un método eficiente. Incluye también comentarios y explicación de los puntos de mejora”
- Respuesta de la IA: ofrece una refactorización alineada claramente con los objetivos, incluyendo
fetchen paralelo, separación de errores y uso de una estructuramapeficiente, además de una explicación detallada
Consejos adicionales de refactorización
- Hacer solicitudes por etapas (“mejora la legibilidad → optimiza el algoritmo”)
- Pedir enfoques alternativos (“implémentalo también en estilo funcional”)
- Solicitar código + explicación para facilitar el aprendizaje y convertirlo en un tutorial
- Pedir que se agreguen pruebas al código resultante
Patrones de prompts para implementar nuevas funciones
Guiar la generación de código paso a paso
- Presentar primero una descripción de alto nivel (qué funcionalidad se quiere crear) y luego ir desglosándola por etapas
- Compartir el contexto del entorno de trabajo, como código similar existente, patrones del proyecto y librerías utilizadas
- Aprovechar comentarios o TODOs como prompt para guiar directamente el flujo de codificación de la IA dentro del IDE
- Dar ejemplos de entrada/salida o casos de prueba para fijar expectativas claras sobre el resultado
- Si el primer resultado es insuficiente, hacer de inmediato una nueva solicitud con mejoras concretas o estilo de código deseado
Ejemplo: crear un componente React ProductList
“Crea un componente funcional de React llamado ProductList. Debe obtener un arreglo de productos desde /api/products y mostrarlo en una lista, y al escribir el nombre del producto en un campo de entrada debe filtrarlo sin distinguir mayúsculas y minúsculas. También se necesita manejo de carga y errores durante la obtención.”
- Respuesta de la IA: incluye
useState,useEffect, obtención de datos, manejo de entrada, filtrado e implementación de UI para error y carga - Si el proyecto usa hooks personalizados, se pueden dar instrucciones adicionales de forma iterativa, como “refactorízalo para usar el hook useProducts()”
Casos prácticos para elevar el nivel del prompt
- Se puede pedir ampliación gradual de funciones, por ejemplo: “agrega una función de ordenamiento: debe haber un dropdown A-Z y Z-A”
- Dividir el flujo de implementación en etapas y usar un prompt distinto en cada una ayuda a mantener la calidad y la consistencia del código
Conclusión
- Para aprovechar al máximo el potencial de los asistentes de codificación con IA, el diseño de prompts es una habilidad clave
- Para escribir prompts exitosos, siempre hay que tener presentes el contexto específico, el objetivo, los ejemplos, la retroalimentación iterativa y la asignación de roles para obtener resultados efectivos
- La clave del éxito es tratar a la IA como si fuera un desarrollador junior o un revisor de código dentro del proyecto, guiándola en detalle hacia la dirección deseada y elevando gradualmente la calidad
1 comentarios
Comentarios en Hacker News
Por mi experiencia, creo que en realidad solo hay tres técnicas de prompt engineering
In Context Learning (dar ejemplos dentro del contexto, es decir, enfoque one-shot o few-shot frente a zero-shot)
Chain of Thought (indicar que piense paso a paso)
Structured output (por ejemplo, especificar claramente el formato de salida, como JSON)
A esto quizá se podría sumar también el Role Prompting que menciona este artículo
RAG lo clasificaría aparte, porque es una forma en que el modelo resume el contexto proporcionado
Al final, lo demás se resume en cómo pedir lo que quieres con un lenguaje claro y simple
En los prompts, el contexto es el factor más importante
Por ejemplo, si empiezas con TypeScript y luego haces una pregunta de ciencia de datos, he visto que no responde bien
Si haces exactamente la misma pregunta en Python, sale mucho mejor
Como a los LLM todavía les cuesta transferir conocimiento entre dominios, es clave establecer un contexto adecuado al objetivo
Personalmente también creo que el role prompting no tiene mucho sentido
Tal vez en GPT-3 sí, pero la mayoría de los LLM ya entienden el papel de "experto"
Creo que obsesionarse con el "prompt engineering" es una forma de engañarse a uno mismo
Lo importante es transmitir claramente los requisitos, añadir ejemplos si hace falta, revisar el resultado o el reasoning trace, y si no sale lo que quieres, ajustarlo e intentarlo otra vez
Si después de varios intentos no sale la respuesta, también está la opción de razonar yo mismo en vez de usar IA
Muchos opinan que el problema es intentar "meter todo en un solo prompt"
Más bien proponen no lanzar una solicitud enorme de una vez, sino dividirla en varios prompts con contextos pequeños y conectar entre sí salidas estructuradas y claras
Enfocarse en el objetivo y en ejemplos para cada prompt, evitando la sobrecarga de contexto
Así se aplican de forma natural las tres técnicas clave mencionadas arriba
Sobre el tercer enfoque (structured output), mis colegas y yo hicimos un estudio de caso aplicado al ámbito científico
Enlace al paper
Por cierto, nuestro equipo depende más del fine-tuning que del prompt engineering
El enfoque de prompts few-shot no nos funcionó en nuestro caso
Yo también siento seguido que cuando un prompt se vuelve demasiado largo o complejo, el rendimiento cognitivo del modelo empeora
Un prompt complejo puede dar la sensación de control, pero en la práctica puede que no sea una ventaja
Por eso mi patrón de uso ha ido convergiendo naturalmente a prompts muy simples y mínimos, con varias iteraciones de ajuste
Yo también empecé a trabajar exactamente así
Este enfoque también es bueno en costo-beneficio
He usado agents y he terminado quemando $30 mientras enredaban el codebase o volvían al código original demasiadas veces
También quiero advertir que si dejas que la IA escriba demasiado código en tu proyecto, luego ese código no se te queda bien en la cabeza y se vuelve más difícil de mantener
También hay evidencia de que usar terminología experta en el prompt mejora el rendimiento
En general, cuando la gente habla en lenguaje cotidiano la precisión baja, pero el vocabulario de un dominio especializado lleva a respuestas más confiables
Los datos de entrenamiento también reflejan esa distribución
A mí me ha pasado algo parecido
Pero cuando veo los system prompts de los agents, muchas veces son larguísimos y complejos, así que me genera dudas
Me da curiosidad cómo funcionan realmente esos prompts
Enlace con ejemplos de system prompts
En cierta tarea, un colega mío usó un prompt muy verboso
Durante la integración añadí operaciones CRUD y, como experimento, lo cambié por algo realmente corto como "analiza esto desde la perspectiva de <rol profesional>"
Al final ambos resultados fueron casi iguales, y el prompt largo incluso hacía que algunas frases se reciclaran tal cual en la salida
El resultado en sí estuvo bien, pero al final el modelo (gemini 2.5) solo extrajo la información importante y además mezcló partes innecesarias en el resultado
O sea, al menos en esta tarea, la verbosidad no pareció tener un efecto interesante en la "forma de pensar" del modelo
Yo llegué a la misma conclusión, pero me pregunto cómo interpretar los ejemplos de prompts largos que muestran los laboratorios de IA
Ejemplo de system prompt de Anthropic
Creo que el "prompt engineering" como tal no existe
Me pregunto desde cuándo escribir frases con sentido ya cuenta como ingeniería
Me parece incluso peor que lo de "software engineering"
Aun así, me da pena pensar que esto también podría consolidarse como profesión (prompt engineer) y como una supuesta habilidad especial para redactar frases
En realidad, "escribir frases con sentido" depende de muchísimas variables
Si incluyes pruebas, gestión, logging y control de versiones, deja de ser solo intuición y sí se vuelve ingeniería
La estructura, como el orden, el estilo o la reformulación del problema, importa muchísimo
Cuando trabajas con familias de modelos llenas de parámetros, en modelos vía API hace falta verificar compatibilidad con los prompts existentes cada vez que hay una nueva versión
Esas revisiones y pruebas también son parte del prompt engineering
Creo que muchas veces, por rechazo a la moda o al hype, se termina perdiendo de vista lo esencial
Si el barista de mi barrio se pusiera "ingeniero de café" en el nombre, hasta me daría más confianza
El efecto de la adicción a los algoritmos ha hecho que hoy muchos consumidores ya ni siquiera tengan la capacidad de leer frases completas
No creo que haya que preocuparse por vacantes de "prompt engineer"
Los AI sloperators se esfuerzan mucho por hacer que su trabajo se vea más impresionante de lo que es
Por mi experiencia, cuando un LLM no puede resolver un problema, muchas veces no sirve de nada hacer más "ingeniería" de prompts
Más bien no queda otra que dividirlo en subproblemas y dejar que avance poco a poco
Si alguien ha tenido la experiencia contraria, me gustaría escuchar casos
Una parte importante de usar LLM es desarrollar intuición para dividir bien el problema
Hace falta criterio para saber cuándo y cómo dividirlo, y cuándo simplemente dejar que lo resuelva
Como también menciona el artículo, ese know-how es importante
En adelante seguramente también crecerán mucho las formas de organizar y comentar mejor el código para mejorar la interacción con los LLM
Los propios LLM también van evolucionando en esa dirección, y espero que incluso puedan sugerir cómo descomponer problemas
El objetivo del prompt engineering es obtener buenas respuestas más rápido y en el formato deseado
En última instancia quisiéramos que el modelo lo resolviera solo, pero en la práctica también hace falta optimizar la pregunta misma
Al escribir prompts, por costumbre todavía se me hace raro dar instrucciones en lenguaje natural
Siento como si tuviera que escribir algo más parecido a argumentos precisos o a una consulta SQL
Incluso me parece curioso dar instrucciones como si estuviera hablándole a una herramienta en una conversación
Aun así, que se haya vuelto una herramienta que entiende instrucciones en lenguaje natural ha elevado muchísimo la accesibilidad
Pero aun así me sigo sintiendo un poco ridículo al verme escribiendo prompts como si hablara con una persona
Últimamente hay muchísimas guías de prompts
Pero en realidad pienso que no hacen tanta falta
Si usas la herramienta directamente, te familiarizas y aprendes a usarla, terminas entendiendo de forma natural qué prompts son buenos
Se parece a la época en que Google estaba de moda y había toda una ola de FOMO
Decían que si no comprabas libros sobre eso te ibas a quedar atrás como un cavernícola, pero en realidad es un campo tan simple que se puede aprender en un día y no hace falta complicarse tanto
Sin duda hay gente a la que las guías o videos de consejos sí le ayudan mucho
Mucha gente no tiene iniciativa para mejorar por su cuenta, pero con solo ver una guía o un video de alguien experto una vez ya sube de nivel
Yo también suelo aprender tips cada vez que veo cómo lo usan otros o lo que comparte la comunidad
Solo practicando por tu cuenta hay un límite para el tipo de consejos que puedes descubrir
Antes, como en las “guías para escribir user stories”, existía la fórmula “As a [role], I want to [task] so I can [objective]”
Tanto expertos como principiantes necesitan ayuda para comunicar requisitos de forma clara
Incluso un gran desarrollador puede equivocarse o malinterpretar requisitos poco estructurados
También sirve bastante ver cómo otros están sacando productividad con esta herramienta
Ahí descubro ideas que yo había pasado por alto
Es más eficiente aprender aunque sea un poco de experiencias que otros ya hicieron antes de intentar descubrir todo por prueba y error
Personalmente, como no tengo tiempo para probar todo por mí mismo, ese tipo de intercambio de experiencias me parece información realmente valiosa
Definitivamente hay trucos poco evidentes
Por ejemplo, la experiencia me dice que puedes quitar por completo expresiones de cortesía como “please” en un prompt
Hace bastante tiempo, cuando estaba en la maestría de ciencias de la computación, apliqué muy bien al diseño de prompts para data engineering el proceso de verificación que aprendí en la materia Science of programming
Por ejemplo, pedir "dado input(...) y premisas(...), escribe código Spark que satisfaga la post-condition(...)"
Si especificas claramente las entradas, las premisas y las condiciones de resultado, se puede obtener buen código
Material de referencia
Siento que se exagera demasiado con el prompt engineering
Hoy en día, si solo copias y pegas código o errores y haces una pregunta simple en lenguaje llano, la mayoría de los modelos lo resuelven bastante bien por sí solos
No veo necesidad de escribirlo de forma rebuscada
Hace unos días Sergey Brin dijo que un hecho del que no se habla mucho en la comunidad de IA es que “si haces amenazas físicas, el rendimiento del modelo mejora”
Artículo relacionado
Eso me recordó el chiste del vibe coder pro en YouTube “Programmers are also human”, que siempre termina sus instrucciones al LLM con “.. o te vas a la cárcel”
Entonces dan ganas de pensar que por eso Google dejó discretamente atrás el "Don't Be Evil"
Llamar "engineering" al acto de escribir prompts me parece muy poco serio
Cuando se puso de moda eso de prompt "engineering", escuché una comparación divertida
Al final esta discusión se repite cada vez que sale el tema de software engineering
Tal vez pasa porque la imaginación de algunos se queda en pedir fotos de gatos desde una interfaz de chat
En realidad también hay prompts usados en APIs y flujos de automatización, así que va más allá de eso
En Estados Unidos también existe el cargo de "sales engineer", y por mi experiencia muchas veces esas personas no tienen ni idea de cómo funciona el producto que venden
IT es el lugar donde las palabras y sus significados desaparecen
Hasta dan ganas de preguntarse si hace falta que las palabras conserven su significado original