Versionar los prompts como código

'Tocar rápido el prompt' sin probarlo es como un commit a producción sin probar: la diferencia a menudo solo se nota cuando algo ya lleva tiempo roto.

Los prompts son código, no configuración

Un prompt determina el comportamiento igual que una línea de código; por eso merece el mismo cuidado: control de versiones en Git, cambios rastreables y pruebas antes de cada despliegue.

Versionar en Git

Los prompts pertenecen al repositorio, no a un archivo de texto suelto ni a una ventana de chat. Así, cada cambio queda rastreable mediante commits, se puede revisar con precisión en el diff y, si es necesario, deshacer mediante un revert.

Medir antes/después

Una pequeña colección fija de casos de prueba con el comportamiento esperado muestra si un cambio de prompt realmente mejora las cosas o empeora otra cosa de forma encubierta. Sin esta referencia, cualquier valoración se queda en pura intuición.

Detectar regresiones y revertir

Si la colección de pruebas obtiene peores resultados después de un cambio que antes, es una señal clara de una regresión, y gracias al versionado, el estado anterior que funcionaba se puede restaurar en cualquier momento.

Por qué 'tocar algo rápido' es arriesgado

Una sola frase modificada puede tener un efecto inesperado en otro punto del mismo prompt, porque los modelos de lenguaje procesan todo el contexto en conjunto. Sin pruebas, un efecto secundario así a menudo pasa inadvertido durante días, hasta que un usuario lo desencadena por casualidad.

EJEMPLO

Versión anterior (prompts/support-antwort.md, v1.2): 'Responde a la consulta del cliente de forma amable y breve.' → Colección de pruebas: 30/30 casos de prueba cumplen el formato esperado. Versión posterior (v1.3, se añade una frase): 'Responde a la consulta del cliente de forma amable, breve y con una propuesta de solución al problema.' → Se vuelve a ejecutar la colección de pruebas: 27/30 la superan; 3 casos de prueba ahora entregan propuestas de solución indeseadamente largas en lugar de la brevedad exigida. → Resultado: regresión detectada, la v1.3 se afina antes del despliegue en lugar de ponerse en producción directamente.

🛠️ EJERCICIO — PRUÉBALO TÚ

Construye una pequeña colección de pruebas para un prompt propio y comprueba un cambio contra ella antes de adoptarlo.

Guarda un prompt existente como archivo propio en un repositorio Git, si aún no lo has hecho.
Escribe 10 pequeños casos de prueba con entrada y comportamiento esperado (por ejemplo, formato o contenido esperado).
Ejecuta la versión actual del prompt contra los 10 casos de prueba y anota la tasa de éxito.
Modifica el prompt según lo planeado, haz commit del cambio por separado, y vuelve a ejecutar los mismos 10 casos de prueba.
Compara ambas tasas de éxito antes de adoptar el cambio como estándar.

✅ AUTOEVALUACIÓN

☐ ¿Bajó la tasa de éxito tras el cambio, aunque no lo esperabas?
☐ ¿Puedes restaurar la versión antigua del prompt a través del historial de Git en menos de un minuto?

QUIZ RÁPIDO

¿Por qué una simple valoración intuitiva no basta para juzgar si un cambio de prompt es realmente una mejora?