El prompt es código: versión, revisión y prueba

Hay una pregunta que separa al equipo que juega con IA del equipo que la pone en producción: ¿dónde vive el prompt? Si la respuesta es "en un campo de texto que alguien edita desde el panel", la función de IA no tiene ingeniería, tiene improvisación con buena intención.

El prompt es la configuración que más cambia el comportamiento

En un sistema tradicional, la configuración ajusta parámetros alrededor de una lógica fija. En una aplicación de LLM, el prompt es la lógica.

Cambiar una frase de instrucción puede alterar el formato de salida, el tono, la tasa de rechazo y el uso de herramientas de una sola vez. Es lo más poderoso y lo más frágil del sistema, y aun así suele ser lo único que nadie versiona.

El principio de configuración de The Twelve-Factor App resuelve la mitad del problema: separa configuración de código y nunca la pongas en un lugar que no sea auditable. La otra mitad es aceptar que el prompt no es solo configuración, es comportamiento, y por eso también necesita pruebas.

Por qué importan el orden y la estructura

La arquitectura Transformer, presentada en el artículo que puso la atención como mecanismo central, procesa la secuencia entera con pesos de atención entre posiciones. No existe una separación rígida entre instrucción y dato: todo es contexto.

Eso explica tres comportamientos que parecen misteriosos cuando solo miras la salida:

• Una instrucción colocada después de un bloque largo de datos suele tener más efecto que la misma instrucción colocada antes.
• Los delimitadores explícitos entre instrucción y contenido reducen la probabilidad de que el modelo trate el contenido como un comando.
• Un ejemplo concreto vale más que un adjetivo. "Responde de forma concisa" es vago; dos ejemplos de buena respuesta definen el objetivo.

No es superstición, es consecuencia de cómo se consume el contexto.

Técnicas que sobreviven al hype

La literatura sobre prompts creció rápido y buena parte envejeció mal. Tres cosas siguen valiendo.

Estructura explícita. Rol, tarea, restricciones, formato de salida y criterio de éxito, separados. La documentación de ingeniería de prompts de Anthropic organiza el trabajo en esa dirección, y la ganancia viene menos de la magia de las palabras que de la claridad que la estructura obliga.

Razonamiento paso a paso. El artículo sobre cadena de pensamiento mostró que pedirle al modelo que exponga los pasos intermedios mejora las tareas de múltiples pasos. El detalle práctico que se olvida: el razonamiento cuesta tokens y latencia, así que conviene activarlo donde la tarea es compuesta y desactivarlo donde es clasificación simple.

Ejemplos en el contexto. Pocos ejemplos bien elegidos, incluyendo el caso difícil y el caso que debe rechazarse, mueven la salida más que cualquier reescritura de instrucción.

Prompt como código, en la práctica

Tratar el prompt con disciplina de código significa cuatro cosas concretas:

1. Vive en el repositorio, en su propio archivo, con historial.
2. Pasa por revisión, y la descripción del PR dice qué cambió y por qué.
3. Tiene pruebas, es decir, un conjunto de casos con salida esperada que corre en CI.
4. Tiene versión registrada en ejecución, para que el log de producción diga qué prompt generó esa respuesta.

El punto 4 es el que salva la investigación. Sin él, miras una mala respuesta de ayer sin saber qué texto la produjo.

El antipatrón del prompt que solo crece

La evolución típica de un prompt en producción es por acumulación. Cada problema encontrado se convierte en una línea más de instrucción, y en seis meses hay un texto de dos mil palabras que nadie se atreve a tocar.

El problema no es solo el costo por llamada. Es que las instrucciones acumuladas entran en conflicto, y el modelo pasa a atender a la más reciente, la más enfática o la más cercana al final del contexto, de forma difícil de prever.

El antídoto es el mismo de la refactorización de código: cuando llega la corrección número quince, deja de sumar líneas y pregunta si eso debía ser prompt. Muchas veces debe ser validación en código, enrutamiento hacia otro flujo o un segundo paso más barato y determinista.

No todo debe ser prompt

Vale repetirlo aparte, porque es el error más caro: usar una instrucción en lenguaje natural para garantizar algo que el código garantiza mejor.

El formato de salida se garantiza con un esquema y validación, no con un pedido educado. El límite de un valor se garantiza verificando después de la respuesta. El acceso a datos se garantiza con permisos, nunca con la frase "no muestres datos de otros clientes".

Una instrucción es orientación probabilística. El código es una garantía.

Qué significa esto para tu equipo

Si hoy el prompt de tu aplicación no está en Git, esa es la tarea de la semana. Es barata y cambia todo lo que viene después.

Luego arma un conjunto pequeño de casos, diez a veinte, con salida esperada, y hazlo correr en CI en cada cambio de prompt. Eso convierte "creemos que mejoró" en evidencia.

Por último, revisa el prompt más antiguo del sistema buscando instrucciones en conflicto. Casi siempre hay dos, y casi siempre la respuesta extraña que nadie explicó venía de ahí.