Prompting para desarrolladores: técnicas que sí funcionan en producción
Cómo escribir prompts para programar con IA y para funciones con modelos de lenguaje: contexto, ejemplos, salida estructurada, plan antes del código y cómo medir si un prompt mejora.
Publicado el 2026-07-06 · actualizado el 2026-10-02 · 4 min de lectura
En resumen
- Un buen prompt da contexto (qué proyecto, qué stack, qué restricción), un objetivo verificable y un ejemplo del resultado esperado.
- Para programar con IA, pide primero un plan de archivos y aprueba el plan antes de que escriba código.
- Si otro programa va a leer la respuesta, pide salida estructurada con un esquema JSON en lugar de texto libre.
- Un prompt no es bueno porque «suena bien»: lo es si gana a la versión anterior en un conjunto fijo de casos de prueba.
Dos tipos de prompting que conviene separar
Cuando un desarrollador habla de prompting puede referirse a dos cosas distintas. La primera es pedirle a un asistente (Cursor, Claude Code, Copilot, ChatGPT) que te ayude a escribir código. La segunda es escribir el prompt que vive dentro de tu producto: el que clasifica tickets, resume documentos o responde a tus clientes.
Las técnicas se parecen, pero el listón no. En el primer caso tú revisas cada respuesta. En el segundo, el prompt responde miles de veces sin que nadie mire, así que necesitas medirlo como medirías cualquier otra parte del código.
La anatomía de un buen prompt
Casi todos los prompts que funcionan tienen las mismas piezas:
- Rol y contexto: para qué proyecto, con qué stack y para qué usuario.
- Objetivo concreto: qué debe existir al terminar y cómo sabrás que está bien.
- Restricciones: qué no tocar, qué librerías no usar, límites de longitud o de formato.
- Ejemplos: uno o dos casos de entrada y salida esperada (few-shot). Suelen valer más que un párrafo de instrucciones.
- Formato de salida: lista, tabla, diff, JSON con un esquema.
Un ejemplo flojo: «hazme un login». Uno útil: «En este proyecto Next.js con Postgres, añade inicio de sesión con correo y contraseña. Usa la tabla users que ya existe. No instales librerías nuevas de autenticación. Antes de escribir código, dame la lista de archivos que vas a crear o cambiar».
Técnicas para programar con un asistente
- Plan antes que código: pide la lista de archivos y pasos, corrígela y solo entonces deja que escriba. Es más fácil corregir un plan que un diff de 400 líneas.
- Un cambio cada vez: tareas pequeñas que puedas probar. Las tareas grandes producen errores difíciles de localizar.
- Contexto justo: comparte los archivos relevantes, no el repositorio entero. Demasiado contexto también confunde.
- Reglas del proyecto en un archivo (por ejemplo AGENTS.md o las reglas de tu editor): convenciones, comandos y lo que nunca debe hacer.
- Revisión adversaria: cuando termine, pide «busca tres errores probables en este cambio» o «qué pasa si el usuario no ha iniciado sesión».
Prompts dentro de tu producto
Cuando el prompt forma parte de tu aplicación, trátalo como código:
- Versiónalo en el repositorio, con un nombre y una fecha, no pegado en un panel.
- Separa las instrucciones del contenido del usuario y no mezcles en el mismo texto lo que escribe el usuario con tus reglas.
- Usa salida estructurada: los proveedores principales permiten exigir un JSON que cumpla un esquema. Así tu código no depende de interpretar texto libre.
- Define qué hacer cuando el modelo no sabe: una respuesta tipo «sin información suficiente» es mejor que una invención.
Cómo medir si un prompt mejora
El error típico es cambiar el prompt, probar con un caso y darlo por bueno. Para saber si una versión es mejor necesitas un conjunto de evaluación:
- Reúne entre 20 y 50 entradas reales o realistas, incluidas las difíciles.
- Escribe para cada una qué se considera una respuesta correcta.
- Pasa las dos versiones del prompt por el mismo conjunto.
- Compara aciertos, errores graves, longitud y coste.
- Quédate con la que gana y guarda el conjunto para el próximo cambio.
Una hoja de cálculo basta para empezar. Lo importante es que la decisión salga de números y no de la impresión de un par de pruebas.
Errores comunes
- Instrucciones contradictorias («sé breve» y «explica todo en detalle»).
- Pedir que «no invente» sin darle una salida cuando no sabe.
- Prompts larguísimos que nadie mantiene. Si una regla no cambia el resultado en tus pruebas, sobra.
- Confiar en una respuesta sin verificarla cuando hay dinero, datos personales o salud de por medio.
Dónde practicar prompting
La ruta Modelos de IA y prompts de Codelindo cubre cómo funcionan los modelos, anatomía de prompts, salida estructurada, RAG y evaluación, con retos y un laboratorio de prompts donde LINDO revisa lo que escribes.
El proyecto final es una función con IA que puedes medir: prompt versionado, salida estructurada, un conjunto de pruebas y los números que demuestran que la segunda versión es mejor que la primera.
Preguntas frecuentes
¿Qué modelo es mejor para programar?
Cambia cada pocos meses y depende de la tarea. Lo práctico es probar dos o tres con tus propios casos de prueba y quedarte con el que mejor equilibra calidad, velocidad y coste para ti.
¿Sigue haciendo falta el prompt engineering con modelos tan buenos?
Hace falta menos «truco» y más claridad. Contexto, objetivo verificable, ejemplos y formato de salida siguen marcando la diferencia, sobre todo en prompts que corren dentro de un producto.
¿Qué es la salida estructurada?
Pedir al modelo que responda en un formato fijo, normalmente JSON que cumple un esquema. Así otro programa puede leer la respuesta sin errores de interpretación.
¿Dónde practico prompting en español?
En la ruta Modelos de IA y prompts de Codelindo, con retos y un laboratorio de prompts revisado por LINDO.
Siguiente paso: curso de prompting y modelos de IA.