Los prompts merecen migraciones, no improvisación
Versionas el código alrededor del modelo con disciplina. Y al prompt lo editas en vivo en un dashboard. Esto es lo que cambió cuando dejé de hacerlo — y dónde se rompió primero.
Jamás abrirías una base de datos en producción para correr un ALTER TABLE a mano, de memoria, sin migración y sin vuelta atrás. Esa lección la aprendimos a las malas hace años. Por eso existen las migraciones: cada cambio de schema es un archivo versionado, revisable y reversible, con fecha y autor.
Y aun así, editamos el prompt que mueve una feature de LLM directo en un dashboard. En vivo. En producción. Sin diff, sin historial, sin test, sin saber si el último ajuste ayudó o rompió algo.
Versionamos el código alrededor del modelo con disciplina. El prompt — lo que de verdad decide qué hace el modelo — lo tratamos como un post-it.
El modelo casi nunca es lo que se rompe
Este es el patrón que veo desde hace dos años construyendo con LLMs. El demo funciona. Producción se rompe. Rastreas el incidente y el modelo estaba bien. Lo que se movió fue el contexto a su alrededor, y casi siempre eso significa el prompt.
Rara vez falla de golpe. Falla como deriva. Un cambio acá para resolver un caso borde. Una línea allá para contentar a un stakeholder. Una instrucción "rápida" agregada la noche antes de un launch. Ninguno revisado contra los demás. Seis semanas después la salida es peor y nadie puede señalar el commit que lo causó, porque no hubo commit.
Un prompt que no puedes diff-ear es un prompt que no puedes debuggear.
Los reportes de incidentes caen siempre en el mismo lugar. No es la capacidad del modelo. Es la acumulación lenta de ediciones de prompt sin revisar, y la deriva que viene detrás. Tu modelo es lo más estable del stack. Tu prompt es lo que cambias cada semana con menos rigor.
Qué cambió cuando traté los prompts como código
No una herramienta. No un framework. Una decisión: un prompt es un artefacto de software y merece el mismo trato que todo lo demás en el repo. En la práctica, cuatro cosas.
1. Versionado — cada prompt vive en el repo
Los prompts salen del dashboard y entran a control de versiones, al lado del código que los llama. Cada cambio es un commit con un mensaje que dice por qué. Puedes hacer diff entre dos versiones. Puedes hacer blame de una línea. Y cuando una "pequeña mejora" resulta no serlo, vuelves al martes pasado con un solo comando.
prompts/
extract_fields.v4.md # era v3 — endurecí la regla de formato de fecha
classify_intent.v8.md # era v7 — rollback, v7 puntuaba mejor
summarize_doc.v2.mdSuena demasiado simple para importar. Es lo que más palanca me ha dado en la confiabilidad de un sistema LLM.
2. Retry progresivo — no pagues el prompt completo para arreglar un campo
Cuando el modelo devuelve algo que falla validación, el arreglo perezoso es reintentar el prompt entero y rezar. Eso sale caro, y con tráfico real se multiplica.
Así que los reintentos se achicaron. Ante una falla, el sistema reintenta con una corrección dirigida al campo que de verdad se rompió, y solo escala si hace falta. Dejas de reenviar todo el contexto para reparar un solo valor malo.
~90% menos tokens gastados en reintentos de validación.
Ese número no es un truco de benchmark. Es lo que pasa cuando "retry" deja de significar "hazlo todo de nuevo".
3. Sanitización por campo — repara la entrada, no el universo
Primo del anterior. Cuando un campo vuelve mal, sanitizas y reejecutas ese campo, no toda la respuesta. La mayoría de las quejas de "el LLM no es confiable" son en realidad "tiramos toda la petición porque una esquina venía torcida". Acota la reparación al problema real y se vuelve más barato, más rápido y más fácil de razonar.
4. Evals sobre intuición
Una vez versionados los prompts, por fin puedes responder la pregunta que la intuición no puede: ¿este cambio de verdad ayudó? Cada versión corre contra un set de casos de evaluación antes de salir. Un ajuste que arregla un ejemplo y rompe en silencio otros cinco nunca llega a producción. Iterar deja de ser "esto se siente mejor" y pasa a ser "esto puntúa mejor en los casos que nos importan".
Dónde se rompió primero
No llegué acá por teoría. Llegué por quemarme.
La primera versión de uno de mis pipelines no tenía nada de esto. Los prompts vivían mitad en código, mitad en un config que cualquiera podía editar. Un día la calidad cayó en cierto tipo de entrada. No de forma catastrófica — apenas lo suficiente para tardar días en notarlo, y para entonces no podía decir cuál de una docena de cambios recientes era el culpable. Sin historial para bisectar. Sin evals para decir qué variante era mejor. Leía salidas y adivinaba.
Esa es exactamente la sensación que las migraciones se inventaron para matar. Así que copié el playbook completo: versiónalo, haz los cambios revisables, deja una vuelta atrás, testea antes de shippear. Si empezara de nuevo mañana, lo primero que construiría no es un modelo más inteligente. Es la aburrida capa de versionado, el día uno, antes de que un solo prompt se acerque a un usuario.
Los prompts son software
Nada de esto es exótico. Es la disciplina que el resto de tu stack ya da por sentada, por fin apuntada a la capa que seguimos fingiendo que es "solo texto". Observable. Versionado. Costeado. Borrable.
Si un prompt es lo bastante importante como para decidir lo que tu producto le dice a un usuario, es lo bastante importante como para merecer una migración, no una improvisación.
Entonces: ¿cómo versiona tu equipo sus prompts hoy? Y si la respuesta honesta es "no lo hacemos", ¿por cuál de las cuatro empezarías?
Lo que sigue: el versionado paga dos veces. Una vez que tus prompts están bajo control de versiones y evals, tienes el andamiaje para endurecerlos — para atajar jailbreaks, fictional-framing y las otras formas en que alguien intenta convencer a un modelo de abandonar su trabajo. De eso va la próxima nota.