Prompt engineering para desarrolladores: escribir, probar y versionar prompts de producción

El "prompt engineering" tiene mala fama entre los desarrolladores: suena a adivinar frases mágicas. En producción es algo más corriente: escribir instrucciones claras y comprobables para un componente cuyo comportamiento no puedes especificar del todo en código. Un buen prompt de producción se parece más a una especificación bien escrita que a un truco ingenioso. Esta guía cubre las técnicas que importan de forma consistente, cómo estructurar los prompts como código y cómo cambiarlos sin romper lo que ya funciona.

Qué ha cambiado con los modelos actuales

Los primeros consejos de prompting estaban llenos de trucos: "respira hondo", amenazas, propinas, mayúsculas. Los modelos actuales ajustados para seguir instrucciones siguen bien las indicaciones sencillas y concretas, y las propias guías de los proveedores convergen en los mismos fundamentos (resumen de prompt engineering de Anthropic; guía de prompt engineering de OpenAI). Un amplio estudio de técnicas de prompting catalogó decenas de métodos, pero la mayoría de las mejoras en producción vienen de unos pocos (Schulhoff et al., The Prompt Report, 2024).

El cambio para los desarrolladores: deja de pensar en los prompts como conjuros y empieza a pensar en ellos como interfaces: entradas, comportamiento, salidas, casos de error.

Anatomía de un prompt de producción

Una estructura fiable para los prompts de sistema:

Rol y contexto. A quién representa el modelo, quién es el usuario, qué producto es.
Tarea. Qué hacer, en una o dos frases.
Reglas y restricciones. Qué hacer siempre y qué nunca, con sus motivos.
Descripción de la entrada. Qué datos recibirá el modelo y cómo están delimitados.
Especificación de la salida. Formato, longitud, idioma, esquema.
Ejemplos. Unos pocos pares de entrada/salida que cubran casos típicos y complicados.
Casos límite. Qué hacer cuando la información falta, es ambigua o está fuera de alcance.

You are a support assistant for Acme Contabilidad, a SaaS for small businesses
in Spain. Users are accountants; answer as a knowledgeable colleague.

Task: answer the user's question using only the documentation in <docs>.

Rules:
- If the docs do not contain the answer, say so and suggest contacting
  soporte@acme.es. Do not guess — wrong tax advice causes real harm.
- Answer in the user's language (Spanish or English).
- Keep answers under 150 words unless the user asks for detail.
- Never mention internal ticket numbers or employee names from the docs.

<docs>
{{retrieved_documents}}
</docs>

Output: a direct answer first, then a "Sources:" line listing doc titles.

Fíjate en el motivo después de "Do not guess". Explicar por qué existe una regla ayuda al modelo a generalizarla a casos que no enumeraste; la guía de Anthropic lo señala explícitamente.

Técnicas que ayudan de forma consistente

Sé concreto sobre lo que quieres

Vago: "Resume este documento". Concreto: "Resume este contrato para un director comercial en cinco viñetas: partes, duración, precio, condiciones de rescisión, cláusulas inusuales. Cita los números de cláusula". La versión concreta es más larga y mucho más fiable. La prueba: ¿un compañero nuevo, leyendo solo este prompt, produciría lo que quieres?

Separa las instrucciones de los datos con etiquetas

Cuando un prompt contiene documentos, entrada del usuario o resultados de herramientas, delimítalos con claridad. Las etiquetas de estilo XML funcionan bien con todos los modelos: <docs>, <user_question>, <previous_answer>. Las etiquetas facilitan al modelo distinguir tus instrucciones del contenido, y a ti analizar la salida. También ayudan, aunque poco, contra el prompt injection, pero no son una frontera de seguridad; consulta seguridad de agentes de IA.

Usa los ejemplos de forma deliberada

Los ejemplos few-shot son la forma más potente de mostrar formato y tono (Brown et al., 2020). Reglas para buenos ejemplos:

De 3 a 5 ejemplos, lo bastante variados para que el modelo no copie rasgos superficiales.
Incluye al menos un caso límite (información que falta, rechazo).
Envuélvelos en etiquetas <example> para que no se confundan con la entrada real.
Mantenlos alineados con tus reglas: las contradicciones entre ejemplos e instrucciones confunden a los modelos.

Deja pensar al modelo cuando la tarea lo requiera

En el razonamiento de varios pasos —cálculos, clasificación con muchos criterios, planificación—, pedir al modelo que razone antes de responder mejora la precisión (Wei et al., 2022). Los modelos actuales suelen tener modos de razonamiento extendido integrados que lo hacen sin pedirlo; úsalos para tareas difíciles y omite el razonamiento en extracciones sencillas, donde solo añade latencia y coste. Si necesitas el razonamiento separado de la respuesta, pídelo en un bloque <thinking> y la respuesta en un bloque <answer>, y analiza solo este último.

Especifica la salida con precisión

Di qué formato, longitud y estructura quieres, y qué debe quedar fuera ("sin preámbulo", "sin encabezados markdown"). Para salidas legibles por máquina, usa salidas estructuradas o llamadas a herramientas con un esquema JSON en lugar de pedir JSON amablemente; consulta salidas estructuradas.

Pon primero los documentos largos y al final la pregunta

En prompts con contexto largo, colocar los documentos arriba y la pregunta y las instrucciones al final suele mejorar las respuestas. Los modelos también prestan una atención desigual a lo largo de contextos muy largos, un fenómeno documentado en Lost in the Middle. Menos contexto y más relevante suele ganar a más contexto: es el tema del context engineering.

Los prompts son código: estructúralos como código

En producción, los prompts deberían vivir en el repositorio, no en un panel que alguien edita un viernes por la tarde.

prompts/
  support_answer/
    system.md          # system prompt template
    examples.yaml      # few-shot examples
    schema.json        # output schema
    CHANGELOG.md       # what changed and why
  ticket_classifier/
    ...

from pathlib import Path
from string import Template

PROMPT_DIR = Path(__file__).parent / "prompts"

def render(name: str, **vars) -> str:
    text = (PROMPT_DIR / name / "system.md").read_text()
    return Template(text).substitute(**vars)  # fails loudly on missing vars

system = render("support_answer", product="Acme Contabilidad")

Prácticas que ahorran disgustos:

Versiona los prompts junto con el código que los llama. Un cambio de prompt es un cambio de código y pasa por revisión.
Registra la versión del prompt con cada petición, para poder correlacionar los cambios de calidad con los cambios de prompt; consulta observabilidad de LLM.
Falla si faltan variables de la plantilla en lugar de enviar en silencio {{customer_name}} al modelo.
Mantén el contenido dinámico al final y las instrucciones estables al principio; así también maximizas los aciertos de prompt caching.

Cambiar prompts con seguridad

Cada cambio de prompt puede arreglar un caso y romper otros tres. La única forma fiable de saberlo es ejecutar evaluaciones:

Mantén un conjunto de referencia de 50–200 entradas reales con las propiedades esperadas.
Ejecuta el prompt actual y el nuevo sobre todo el conjunto.
Compara las puntuaciones por categoría, no solo la global.
Lee una muestra de las salidas que han cambiado antes de lanzar.

El método completo está en cómo evaluar aplicaciones LLM. Sin evals, el prompt engineering sí que es adivinar.

Actualizar de modelo también es cambiar el prompt

Cuando pases a un modelo más nuevo, vuelve a ejecutar tus evals. Los modelos nuevos suelen seguir las instrucciones de forma más literal: un prompt que dependía de que el modelo antiguo "rellenara los huecos" puede producir ahora una salida más estrecha. Arreglos típicos: indica explícitamente el nivel de detalle deseado, elimina el lenguaje enfático ("CRÍTICO", "DEBES") que los modelos nuevos aplican en exceso y revisa los ejemplos. Los proveedores publican notas de migración por esta razón; léelas.

Antipatrones

Sopa de prompts. Un prompt de sistema de 3.000 palabras acumulado durante meses, con reglas contradictorias que nadie se atreve a borrar. Refactoriza los prompts como el código; elimina las reglas que los evals demuestran innecesarias.
Instrucciones solo en negativo. "No uses markdown" funciona peor que "Escribe en párrafos de prosa sencilla".
Requisitos ocultos. Reglas de negocio que solo existen en el prompt y en ningún otro sitio del código o la documentación. Pon también las restricciones importantes en el código de validación.
Probar con cinco ejemplos. Parece productivo y no demuestra nada.
Pedir al modelo aritmética o búsquedas exactas que podría hacer el código. Calcula en código y pásale los resultados.

Lista de comprobación antes de lanzar un prompt

Rol, tarea, reglas, entrada, salida y casos límite están explícitos
Los datos están delimitados con etiquetas; la entrada del usuario no se puede confundir con instrucciones
De 3 a 5 ejemplos cubren casos típicos y límite y coinciden con las reglas
El formato de salida se impone con salidas estructuradas cuando debe ser legible por máquina
El prompt vive en el repositorio, versionado y revisado
Los evals pasan sobre el conjunto de referencia, con puntuaciones por categoría
La versión del prompt se registra con cada petición

Preguntas frecuentes

¿Los prompts deberían estar en inglés si los usuarios escriben en español? Las instrucciones en inglés funcionan bien con los grandes modelos, y puedes indicar al modelo que responda en el idioma del usuario. Para los términos propios del dominio, incluye ejemplos en el idioma de destino.

¿Qué longitud debería tener un prompt de sistema? La necesaria y ni una palabra más. Muchos prompts de producción tienen entre 300 y 1.500 palabras. La longitud está bien; las contradicciones y el relleno, no.

¿Sigue haciendo falta el prompt engineering con agentes? Más que nunca, pero su alcance se amplía a las descripciones de herramientas, la selección del contexto y la memoria; consulta context engineering y diseño de herramientas para agentes.

¿Puede un LLM mejorar nuestros prompts? Sí: los modelos son buenos criticando y reescribiendo prompts. Trata sus sugerencias como candidatas y acéptalas solo si mejoran los evals.

Fuentes

Anthropic. Prompt engineering overview.
OpenAI. Prompt engineering guide.
Schulhoff et al. (2024). The Prompt Report: A Systematic Survey of Prompting Techniques.
Brown et al. (2020). Language Models are Few-Shot Learners.
Wei et al. (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.
Liu et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.