Un prompt de sistema no es un texto que escribes una vez y olvidas. Es código. Y como todo código que no se mantiene, se pudre.
He visto —y he escrito— prompts de sistema que empezaron con quince líneas claras y acabaron con doscientas, llenas de parches para casos concretos que un día fallaron. El resultado: instrucciones que se contradicen entre sí, el modelo ignorando la mitad porque hay demasiado ruido, y nadie se atreve a tocar nada por miedo a romper lo que ya funciona.
Esto no es un problema exclusivo de prompts largos. Es un problema de cómo se acumulan los cambios, exactamente igual que en cualquier otra base de código sin disciplina.
Por qué se rompen
Un prompt de sistema se rompe casi siempre por tres motivos:
- Acumulación sin poda. Cada vez que algo falla, añades una frase que lo corrige. Nunca quitas nada. Al cabo de meses tienes reglas para casos que ya no existen conviviendo con reglas nuevas que las contradicen.
- Instrucciones en negativo sin alternativa. "No hagas X" sin decir qué hacer en su lugar deja al modelo improvisando, y esa improvisación cambia con cada actualización del modelo.
- Mezclar capas que deberían estar separadas. Personalidad, restricciones, formato de salida y lógica de negocio, todo en el mismo párrafo. Cuando algo falla no sabes qué tocar sin arriesgar el resto.
Ninguno de estos tres es un problema de "prompting avanzado". Son problemas de mantenimiento, y se arreglan con las mismas herramientas de siempre.
Tratarlo como código, en serio
Lo que me ha funcionado no es una técnica mágica, es aplicar higiene de ingeniería normal y corriente:
Versiona el prompt. Un prompt de sistema debería vivir en un archivo de texto bajo control de versiones, no pegado directamente en una plataforma sin historial. Si algo se rompe, quieres poder ver el diff exacto que lo rompió, no adivinar qué cambió entre ayer y hoy.
Sepáralo en secciones con propósito único. Rol, restricciones duras, formato de salida, ejemplos. Cada sección responde a una pregunta distinta. Si necesitas tocar el formato de salida, tocas esa sección y ninguna otra, y sabes exactamente qué no deberías haber afectado.
Prioriza explícitamente cuando haya conflicto. Si dos instrucciones pueden chocar en un caso real, decídelo tú por escrito, no dejes que lo resuelva el modelo caso a caso de forma distinta cada vez. "Si el usuario pide X pero la regla Y lo impide, prevalece Y" es una frase que ahorra comportamiento errático más adelante.
Escribe en positivo. Cambia "no des respuestas largas" por "responde en máximo tres frases salvo que el usuario pida detalle". Es más fácil de seguir para el modelo y más fácil de verificar para ti.
Ten un set de casos de regresión. No hace falta un framework de evaluación sofisticado para empezar. Basta con una lista de diez o veinte entradas reales que el sistema debe manejar bien, y comprobarlas cada vez que tocas el prompt. Sin esto, cada cambio es un salto de fe, y los saltos de fe se acumulan igual que los parches.
El error de optimizar para el modelo del momento
Otro motivo por el que los prompts envejecen mal: se escriben pensando en las rarezas de un modelo concreto. Una frase que compensaba una debilidad puntual de un modelo puede convertirse en ruido innecesario —o directamente en algo contraproducente— con el siguiente.
Cuando cambias de modelo o de proveedor, no asumas que el prompt sigue funcionando igual. Vuelve a pasar el set de regresión completo antes de dar el cambio por bueno. Los parches que compensaban debilidades específicas de un modelo anterior normalmente se pueden quitar, y quitarlos suele mejorar las cosas, no empeorarlas.
Lo que no vale la pena optimizar antes de tiempo
Hay una tentación de pulir el prompt de sistema hasta la perfección antes de lanzar nada. No merece la pena. Un prompt razonable, con secciones claras y un puñado de casos de regresión, es mejor punto de partida que uno "perfecto" que nadie ha probado todavía contra usuarios reales.
Los problemas de verdad aparecen con el uso real: preguntas ambiguas, usuarios que rompen el formato esperado, casos límite que no se te habían ocurrido. Ese es el momento de añadir una regla nueva, no antes, y no por adelantado especulando sobre qué podría pasar.
La regla que más me ha servido
Cada vez que añado una instrucción nueva al prompt, me obligo a preguntarme: ¿esto es una regla general o un parche para un caso muy concreto? Si es un parche, casi siempre hay una regla general debajo que no había identificado bien todavía. Buscarla cuesta más en el momento, pero evita que el prompt se convierta en una lista infinita de excepciones que nadie entiende del todo seis meses después.
Quién revisa el prompt cuando el equipo crece
Hay un problema adicional que aparece en cuanto el prompt deja de ser cosa de una sola persona: distintas personas añaden reglas distintas, cada una resolviendo el problema que tenía delante en ese momento, sin ver el conjunto completo. Esto acelera la acumulación de contradicciones más rápido que trabajando en solitario.
La solución no es burocrática, es simplemente designar quién revisa los cambios al prompt de sistema antes de que entren, igual que se revisa cualquier otro cambio de código con impacto en producción. No hace falta un proceso pesado, basta con que alguien lea el diff completo y pregunte "¿esto contradice algo que ya está ahí?" antes de aprobarlo.
Un prompt de sistema que no se rompe con el tiempo no es el que nunca cambia. Es el que cambia de forma controlada, con versionado, con pruebas de regresión, con revisión antes de entrar y con la disciplina de quitar tanto como se añade.
Relacionado: Qué debe incluir un buen prompt para Cursor IDE