Prompt Engineering en Producción: Lo Que Cambia Cuando Es Código Real

Hay una diferencia fundamental entre escribir prompts para explorar un LLM y escribir prompts que corren en producción 24/7 con usuarios reales.

La primera vez que uno de mis agentes falló en producción — respuesta incoherente, bucle infinito en un edge case — me di cuenta de que mi enfoque seguía siendo el de un explorador, no el de un ingeniero.

La Fiabilidad No Es Negociable

En modo experimentación, una respuesta extraña en 10 llamadas es interesante. En producción, es un bug.

Primer principio integrado: tratar los prompts como código que puede fallar. Lo que implica:

• Definir exactamente las condiciones de fallo (cuándo el LLM debe decir “no sé”)
• Testear con inputs malformados, contradictorios, vacíos
• Tener una salida degradada explícita

Un prompt de producción siempre tiene una instrucción de fallback. “Si no tienes la información necesaria, responde únicamente: INSUFFICIENT_DATA”. Sin interpretación, sin invención.

Estructurar los Outputs para el Código que los Consume

En exploración, lees las respuestas a mano. En producción, es código el que parsea la salida.

Impongo sistemáticamente una estructura JSON para todo lo que debe ser consumido downstream:

Responde ÚNICAMENTE con este JSON, sin markdown, sin texto antes ni después:
{
  "action": "create|update|skip",
  "confidence": 0.0-1.0,
  "reason": "una frase máximo"
}

El campo confidence está subestimado. Permite rutear los casos límite hacia revisión humana en lugar de dejar que el LLM decida solo.

Versionar los Prompts Como Código

Cambiar un prompt de sistema en producción sin versionar es como hacer merge sin diff.

Mi organización:

prompts/
├── v1/
│   ├── system.md
│   └── classify.md
├── v2/
│   └── system.md
└── current -> v2/

Cada versión está etiquetada. Si aparece una regresión, rollback en 30 segundos.

La Longitud del Contexto Es una Variable de Coste

Lo que los tutoriales no dicen: cada token del prompt de sistema se paga en cada llamada. En un agente en bucle, un prompt de 2.000 tokens × 10.000 llamadas/día aparece en la factura.

Optimizo los prompts de producción como optimizo SQL: eliminar lo que no se usa, comprimir instrucciones redundantes. Un prompt de producción es el resultado de varias iteraciones de compresión, no el primer borrador.

Los Modelos No Son Intercambiables

Haiku, Sonnet y Opus no se comportan igual con el mismo prompt. Un prompt finamente ajustado en Sonnet puede producir resultados diferentes en Haiku — no necesariamente peores, pero sí diferentes.

Mantengo configuraciones separadas por modelo objetivo. Cuando sale una nueva versión, revalido con mi suite de tests antes de migrar.

Lo Que Cambia en la Práctica

El prompt engineering en producción se acerca más a la ingeniería de software que a la escritura creativa:

• Tests de regresión sobre un conjunto representativo de ejemplos
• Monitorización de outputs (tasa de respuestas fuera de formato, tasa de fallback)
• Versionado y changelog de prompts
• Revisión antes de cualquier cambio en producción

No es más complejo que mantener una API — simplemente es muy diferente de lo que muestran la mayoría de los tutoriales de introducción.