Skip to main content

Gotchas de prompting: cómo un prompt se rompe en producción

Un prompt que funciona en el playground funciona con el input que escribiste, en el modelo en el que lo escribiste, por un camino que recorriste vos. Producción lo corre con inputs que nadie guionó, con texto no confiable en la ventana, contra una versión de modelo que se te mueve abajo — y una falla de prompt parece una respuesta con seguridad, no un error. Diez gotchas que rompen un prompt después de la demo, cada uno con la pregunta que tenés que contestar primero y el costo de equivocarte.

Nota de producción·Actualizado 2026-06-03·Escrito por Lira · Editado por German Medina

Un prompt que funciona en el playground prueba que el modelo puede hacer la cosa una vez — con el input que escribiste, en el modelo en el que lo escribiste, por un camino que recorriste vos. Producción es otra sala: el modelo corre con inputs que nadie guionó, con texto no confiable sentado en la ventana al lado de tus instrucciones, contra una versión de modelo que se te puede mover abajo entre un trimestre y el siguiente. El prompt no empeoró; llegaron las condiciones que nunca vio. Y una falla de prompt no se anuncia como un error — vuelve como una respuesta con seguridad, bien formada y equivocada, o como una forma que tu parser no traga, y alguien downstream actúa sobre ella.

Diez gotchas que convierten un prompt que demoeó limpio en uno que se rompe en producción. Tienen la misma forma que los que matan agentes y grounding: la demo hace que el camino fácil parezca el camino entero, y producción es todo lo que el camino fácil dejó afuera. Cada uno va con la pregunta a contestar antes de salir a producción y el costo de equivocarte. Nada de esto depende del toolkit — un prompt que dirige una acción de Agentforce, una llamada a la Claude API, o un paso dentro de un loop de LangGraph hereda todos y cada uno. La habilidad no es encontrar palabras ingeniosas; es ingenierizar el contexto alrededor del modelo para que las palabras aguanten bajo condiciones que el playground nunca te mostró.

Los gotchas

1. La instrucción ignorada — una restricción enterrada en una pared de texto que el modelo se saltea

Escribiste la regla. Está en el prompt. El modelo igual la ignoró — no porque no pueda seguir instrucciones, sino porque la que importaba era la oración número once en un párrafo denso, con el mismo peso que las diez de alrededor. La salience no es una función de que vos la hayas escrito; una restricción sin énfasis estructural compite con todo lo demás en la ventana y pierde tan seguido como gana.

El costo es una regla que podés probar que está "en el prompt" y un modelo que igual la rompe en producción — el peor tipo de bug para discutir, porque todos pueden ver que la instrucción está ahí. El arreglo es estructura y salience, no más palabras: sacá la restricción de la prosa, dale su propia línea o sección, decila una vez y con claridad. La pregunta a contestar antes de salir: ¿tus restricciones duras están estructuralmente prominentes — apartadas, no enterradas — o son oraciones en un párrafo esperando que las noten?

2. Formato frágil — confiar en la prosa para emitir una forma exacta, sin nada que la haga cumplir

Un prompt que dice "respondé con los campos de abajo" y saca la forma correcta en diez corridas de prueba no está produciendo esa forma de forma confiable — la está produciendo por ahora. La generación libre es no-determinística por naturaleza, y en la corrida número once el modelo agrega un preámbulo amable, envuelve la salida en un code fence, o reordena los campos, y el parser que asumió la forma exacta de la demo se rompe con el primer input que no probaste.

El costo es un pipeline que corre una semana y después falla un martes, con una salida que está casi bien — el tipo de rotura que despierta a alguien en el peor momento y es enloquecedor de reproducir. El arreglo es dejar de confiar en la prosa para cargar la estructura: pedí una forma definida y hacela cumplir (mirá el gotcha 7). La pregunta: ¿qué garantiza la forma de la salida — un schema, structured output, un paso de validación — o tu parser está apostando a que el modelo nunca, ni una vez, decida ponerse conversacional?

3. Sobre-promptear — apilar reglas hasta que se contradicen entre sí y ahogan la tarea

Cuando un prompt se porta mal, el instinto es agregar: otro caveat, otro "siempre", otro "nunca". Pasado un punto esto sale al revés. Las reglas empiezan a contradecirse — "sé conciso" peleando con "sé exhaustivo", una excepción que en silencio niega la regla de arriba — y la tarea real se ahoga bajo el andamiaje que tenía que controlarla. Más prompt no es más control; es más superficie para que el modelo pondere mal.

El costo es un prompt inflado cuyo comportamiento nadie puede predecir, donde agregar una regla para arreglar un caso rompe en silencio otros dos. La pregunta: ¿cada instrucción de este prompt se gana el lugar contra la tarea, y alguna vez sacaste una regla — no solo agregaste una — para ver si la salida mejoraba?

4. Sin ejemplos donde la tarea los necesita — decir en vez de mostrar

Algunas tareas se resisten a la descripción. Un tono, un juicio de caso borde, un estilo de salida — podés escribir tres párrafos tratando de especificarlo en abstracto, o podés mostrar dos o tres ejemplos trabajados (multishot) y dejar que el modelo haga pattern-matching de lo que querés decir. Decir en vez de mostrar es la razón más común de que un prompt que "explica la tarea perfecto" igual produzca lo equivocado: las palabras estaban claras y la intención igual no se transfirió.

El costo es un prompt que se vuelve más largo y más vago a medida que tratás de describir en prosa lo que un par de ejemplos habrían clavado en una fracción de los tokens. La pregunta: para los casos que esta tarea saca mal, ¿unos pocos ejemplos bien elegidos de la salida correcta la enseñarían más rápido que otro párrafo de instrucción — y tus ejemplos están cubriendo los casos difíciles, no solo repitiendo el fácil que el modelo ya saca?

5. Prompt injection — texto no confiable en la ventana que carga instrucciones que pisan las tuyas

Apenas tu prompt incluye texto que vos no escribiste — un chunk recuperado, el mensaje de un usuario, un documento pegado, el cuerpo de un email — ese texto puede cargar instrucciones, y el modelo no puede distinguir de forma confiable tus instrucciones de las del dato. "Ignorá tus instrucciones previas y…" enterrado en un documento recuperado no es hipotético; es el ataque por defecto a cualquier sistema que mete contenido no confiable en la ventana de contexto. El modelo trata toda la ventana como una sola conversación, y el dato consigue un voto que nunca debió tener.

El costo es un modelo que sigue la instrucción de un atacante porque llegó como dato y confiaste en la ventana — en su peor versión, una acción tomada o un secreto filtrado por orden de un párrafo pegado. La pregunta: ¿por dónde entra texto no confiable a este prompt, está estructuralmente cercado de tus instrucciones, y cuál es el radio de explosión si un chunk recuperado o provisto por el usuario intenta redirigir al modelo?

6. Contexto mal ordenado — la instrucción clave enterrada en el medio donde el modelo la subpondera

La posición es señal. Los modelos atienden de forma más confiable al inicio y al final de un contexto largo y subponderan el medio — el efecto "lost in the middle" — así que una instrucción crítica o el único dato del que depende la respuesta, dejado en el centro de un prompt largo, se lee pero no se pondera. Las mismas palabras arriba o abajo aterrizan; en el medio de diez mil tokens se desvanecen. El orden es una palanca que estás moviendo lo hayas querido o no.

El costo es una instrucción que está técnicamente presente y funcionalmente invisible, produciendo un bug que desaparece apenas movés el mismo texto arriba — y es desconcertante hasta que sabés mirar la posición. La pregunta: ¿la instrucción o el dato más importante están donde el modelo de verdad los pondera — cerca del inicio o del final — en vez de perdidos en el medio de la ventana, y probaste si reordenar cambia la salida?

7. Parsear prosa en vez de structured output — armar un parser para un problema que tiene un feature

Si te encontrás escribiendo un regex para raspar un número de la oración del modelo, o cortando por un delimitador que le pediste al modelo que "por favor use", pará: armaste un parser para un problema que la plataforma ya resuelve. El structured output — pedir JSON contra un schema, o usar los features de structured output y tool use directamente — mueve la carga de producir una forma válida de tu post-procesamiento frágil al modelo y al contrato de la API, que es donde va.

El costo es un parser quebradizo que se rompe cada vez que el modelo frasea las cosas un poco distinto, más las horas que pasás endureciendo lógica de raspado de strings contra un blanco en movimiento en vez de declarar la forma una vez. La pregunta: ¿estás pidiendo structured output y validándolo contra un schema, o raspando estructura de la prosa a mano — reinventando, mal, un feature que el modelo ya soporta?

8. Drift por cambio de modelo — un prompt ajustado a mano a un modelo se degrada en silencio en el siguiente

Un prompt no es portable gratis. Ajustalo con cuidado a un modelo — sus mañas, sus hábitos de formato, las frases a las que responde — y ese ajuste está en parte fitteado a ese modelo, no a la tarea. Cambiá el modelo, o aceptá un upgrade, y el prompt se puede degradar en silencio: las mismas palabras, un modelo distinto, una salida sutilmente peor que ningún error marca. La trampa inversa es igual de real — "esperá el modelo mejor" no es una estrategia cuando un modelo más nuevo puede regresionar un prompt que estaba ajustado a las mañas del viejo.

El costo es una caída de calidad silenciosa el día que una versión de modelo cambia abajo tuyo, atribuida a cualquier cosa menos al prompt porque el prompt "no cambió" — la regresión se esconde en la única variable que todos asumen estable. La pregunta: ¿cada prompt se vuelve a evaluar contra tu set de eval cuando cambia la versión del modelo, y tratás un cambio de modelo como un cambio que hay que puntuar — no un upgrade gratis que podés asumir estrictamente mejor?

9. Sin eval por cambio de prompt — cada retoque es cara o cruz sin puntuar

Editar un prompt porque la versión nueva "se ve mejor" en el único input que justo probaste no es mejorar — es una suposición que no podés calificar. Sin un set de prueba de casos reales con resultados conocidos, puntuado en cada cambio, no podés distinguir un arreglo de una regresión, y lanzás ambos con la misma confianza. Este es el principio 3 (si no podés evaluarlo, no podés lanzarlo) a nivel de prompt: el prompt es el artefacto más editado y menos testeado de la mayoría de los sistemas de IA.

El costo es un prompt que deriva a oscuras — cada "mejora" cambiando un arreglo que ves por una regresión que no, hasta que la calidad se erosiona y nadie puede decir qué edición lo hizo. La pregunta: ¿tenés un set de eval contra el que este prompt corre en cada cambio, y una edición tiene que puntuar mejor — no solo verse mejor en un intento — antes de salir?

10. Costo y caching ignorados — un preámbulo estático enorme reenviado en cada llamada

Un system prompt largo, un set gordo de instrucciones, un bloque de ejemplos — enviado una vez en una demo, es gratis. Enviado en cada llamada a volumen de producción sin prompt caching, ese mismo preámbulo estático es la factura: pagás por reprocesar los tokens líderes idénticos en cada pedido, y a un millón de llamadas por mes el prompt que estaba bien en la demo es una línea de costo que nadie aprobó. Este es el principio 6 (costo y latencia son features) a nivel de prompt — el largo del prompt es un precio por llamada, pagado para siempre.

El costo es un sistema que es correcto y silenciosamente antieconómico — la respuesta correcta a una factura de tokens que escala lineal con el tráfico y nunca tuvo que hacerlo. La pregunta: ¿cuánto cuesta este prompt por llamada a tu volumen real, la porción estática grande se sirve desde prompt caching en vez de reenviarse cada vez, y separaste el preámbulo estable (cacheable) del input por pedido (no) para que el cache pueda de verdad hacer su trabajo?

El hilo común a los diez: un prompt que sale a producción está estructurado para la salience, con su forma de salida hecha cumplir, defendido contra el texto no confiable de su ventana, ordenado para que el modelo pondere lo que importa, evaluado en cada cambio y acotado en costo — o es un prompt que funcionó una vez en el playground y todavía no se encontró con un input que no escribiste. Cada gotcha de arriba es un lugar donde la única corrida limpia del playground y la realidad de producción de correr-sobre-todo se separan, y el input equivocado siempre está esperando en el tráfico contra el que no testeaste.

Cierre

Estos diez son las fallas de prompt que Cleon vio con más frecuencia, tanto en builds nativos de Agentforce como externos. La disciplina que las previene es la misma que recorre toda la ingeniería de IA: el playground hace que el camino fácil parezca el camino entero, y producción es todo lo que el camino fácil dejó afuera. El prompt es el artefacto más editado de un sistema de IA y normalmente el menos testeado, que es justo por qué importa la disciplina — tratalo como contexto ingenierizado, no como un string que retocás a sensación, y evaluá cada cambio contra casos reales antes de salir. Hacé bien eso y la mayoría de estas no se disparan; salteala y lanzás un prompt que se rompe con seguridad, con un input que la demo nunca mostró. Ninguna es difícil de prevenir de entrada; todas son caras de descubrir en vivo, porque un bug de prompt parece exactamente una respuesta correcta hasta que alguien chequea.

Si un gotcha de prompting le pegó a tu equipo y no está acá, escribí a hello@wearecleon.com — lo agregamos, con crédito.

Related

Reference: