A los equipos de producto les venden que el prompt engineering es una habilidad secreta. No lo es. Son cinco patrones, aplicados con disciplina, y los equipos que los aplican bien son los que entregan agentes que se quedan en producción.
¿Cuáles son los cinco patrones?
- Role framing. Las primeras líneas del prompt le dicen al modelo qué es y qué no es. "Sos un agente de matching a tres vías. No escribís copy de marketing. No inventás SKUs." Los límites explícitos reducen el drift.
- Output estructurado. Cada llamada del agente devuelve JSON con un schema que vos controlás. Nada de prosa. Si el modelo no puede llenar el schema, lo dice y escala.
- Harness de evaluación. Cada cambio de prompt corre contra un set de ejemplos reales con respuestas correctas conocidas. Baja el pass rate, se revierte el cambio.
- Topes de costo. Cada llamada tiene un máximo de tokens y un máximo de retries. Sin loops infinitos. Sin facturas sorpresa.
- Path de escalación. Cuando el agente no puede responder, pasa a un humano con el contexto exacto, la pregunta y la respuesta intentada.
¿Cómo evalúo prompts en el tiempo?
Un harness de evaluación de producción tiene tres piezas:
- Un set de fixtures. 50 a 200 ejemplos reales con respuestas correctas conocidas, versionados en tu repo.
- Un runner automatizado. Un job de CI que re-corre el set en cada cambio de prompt y en cada release de modelo.
- Un threshold de pass. Un número debajo del cual el cambio no mergea, sin importar quién lo escribió.
Los equipos que se saltean el harness terminan re-plataformando cada seis meses porque no pueden decir qué cambio rompió qué flujo.
¿Cuál es un tope de costo razonable?
Para la mayoría de los llamados de agente en producción vemos tres niveles:
| Nivel | Máx tokens | Máx retries | Uso típico |
|---|---|---|---|
| Rápido | 2.000 | 1 | Lookups de status, respuestas simples |
| Estándar | 8.000 | 2 | Razonamiento sobre un documento |
| Profundo | 32.000 | 3 | Research o planning multi-step |
Elegí el nivel por endpoint, no por equipo. Un endpoint, un tope.
Preguntas frecuentes
¿Necesito un prompt engineer en el equipo?
Necesitás a alguien que trate los prompts como código: control de versiones, tests y proceso de review de diffs. Esa persona generalmente ya está en el equipo.
¿Con qué modelo arranco?
Arrancá con el modelo que tu harness de evaluación puntúe más alto en tus tareas reales. La preferencia de modelo sin evaluación es un vibe.