Dieciseis pautas de prompting que aguantan en produccion y las que se caen a los diez turnos

Un post en r/PromptEngineering reune dieciseis patrones de prompting que, segun su autor, siguen funcionando cuando el prompt deja de ser una prueba suelta y pasa a vivir dentro de un pipeline. La tesis de fondo: casi todo lo que se ensena sobre prompts se escribio para una sola interaccion, y se descompone en cuanto hay herramientas, sesiones largas de agente o llamadas encadenadas a la API.

Como se escriben las instrucciones

Poner una persona vacia al principio ("eres un arquitecto principal en Google") cambia el tono pero no arregla la logica. Lo que mueve la aguja es sustituirla por reglas operativas concretas: evaluar este algoritmo por complejidad temporal, memoria y condiciones de carrera, por ejemplo. Tambien hay techo: apilar mas de cuatro restricciones de comportamiento en una misma capa hunde el recuerdo de las instrucciones, asi que si hacen falta quince reglas conviene repartirlas en prompts modulares por tarea.

El fichero monolitico es el otro clasico. Cuatrocientas lineas de comandos y guias de estilo en un unico archivo garantizan que el modelo ignorara lo que quede en la mitad. Para delimitadores, el autor prefiere etiquetas XML a encabezados Markdown: si el dato del usuario tambien trae Markdown, los encabezados se mezclan y el limite deja de ser inequivoco.

El JSON que se rompe y los tokens que se pagan

Pedir razonamiento paso a paso dentro de un pipeline con tool calling suele acabar con texto conversacional antes o dentro del bloque JSON, y el parser falla. La salida es forzar ese razonamiento a una clave propia del esquema. Con las prohibiciones pasa algo parecido: escribir "no generes tablas en Markdown" mete los tokens de "tablas en Markdown" en la matriz de atencion. Mejor declarar el invariante en positivo.

Hay un truco que el autor defiende con datos de su propio equipo: obligar al modelo a afirmar el cumplimiento de sus reglas en un bloque pequeno antes de responder. Si tiene que escribir que el directorio es valido, baja la probabilidad de generar una ruta fuera de rango.

El gasto se les escapa a casi todos. Los equipos miran el conteo final de tokens de la llamada y no ven que las definiciones de herramientas y los esquemas MCP se reenvian en cada turno. Para medirlo, su equipo publico cost-xray, que intercepta el trafico de un proxy local y desglosa el coste del system prompt, los esquemas y los bloques de razonamiento.

Lo que el prompt no arregla

Un system prompt que prohibe mostrar claves privadas o numeros de la seguridad social no aguanta contexto adversarial ni salidas raras de una herramienta. Eso se corta con codigo determinista. Y si molestan los saludos y las despedidas del modelo, se atajan con una instruccion exacta:

Begin response immediately with the solution payload. Omit conversational salutations and sign-offs.

El resto de la lista son detalles de operacion que se notan a partir del turno veinte: la atencion se reparte de forma desigual en una conversacion larga y conviene reinyectar las reglas criticas justo antes de una accion de impacto; en clasificacion hay que pasar enums en lugar de cadenas libres; un turno previo pidiendo los errores tipicos de una migracion sirve como lista de restricciones para el siguiente; las instrucciones de formato rinden mas al final del prompt; y cerrar la sesion del agente en cuanto se fusiona el ticket es la forma mas barata de evitar que el contexto de depuracion envenene la siguiente tarea.

Nada de esto es especialmente exotico, y ahi esta el valor: son fallos que aparecen en cualquier aplicacion de LLM que lleve semanas en produccion y que rara vez se documentan fuera de un hilo. Lo que no trae el post es verificacion independiente. Las cifras de ahorro y los patrones salen de la experiencia del autor, que ademas promociona dos herramientas propias, asi que conviene leerlo como una lista de hipotesis a probar contra los propios registros de tokens.