Pon a prueba tus prompts como si fueran código

Un prompt es una pieza de lógica que se ejecuta en producción y da forma a lo que ven tus usuarios. Nunca enviaríamos una función que solo hayamos ejecutado una vez, sobre una entrada, mirando la salida de reojo y declarándola buena. Sin embargo, así es exactamente como se desarrolla la mayoría de los prompts: ajustar la redacción, probarla en el ejemplo que tienes delante, ver algo bonito, enviarlo. Esta guía trata de aplicar la disciplina que ya usamos para el código —casos de prueba, líneas base, comprobaciones de regresión— a los prompts, porque los prompts la merecen y se rompen sin ella.

Por qué la demo te está mintiendo

El hábito más peligroso en el trabajo con prompts es juzgar un prompt por una sola salida impresionante. Escribes un prompt, lo ejecutas sobre una entrada escogida a mano, obtienes una gran respuesta y te sientes satisfecho. Pero esa única entrada no representa el abanico de cosas que enviarán los usuarios reales. La siguiente entrada —redactada de otra forma, con un campo ausente, más larga, más rara— puede producir basura, y no lo sabrás hasta que un usuario lo descubra por ti.

La demo engaña por la misma razón que una sola ejecución exitosa engaña en el código: pone a prueba el camino feliz que tenías en mente, no los casos que no contemplaste. Los prompts son especialmente propensos a esto porque la salida es fluida y segura incluso cuando está mal, así que un resultado malo se lee como plausible. La única defensa es dejar de confiar en salidas individuales y empezar a medir el comportamiento a través de un conjunto de entradas que de verdad se parezca a la realidad.

Construye un conjunto de pruebas que se parezca a la realidad

Poner a prueba prompts empieza por reunir una colección de entradas representativas —el equivalente a los casos de prueba—. Extráelas del uso real si lo tienes, y asegúrate de que el conjunto abarque la variedad que de verdad ves: peticiones típicas, pero también las cortas, las mal formadas, los casos límite y los casos del tipo "no hay buena respuesta". Un conjunto de pruebas solo con entradas fáciles te dice que tu prompt maneja entradas fáciles, lo cual ya sabías.

Para cada entrada, decide cómo es una buena salida. A veces hay una única respuesta correcta que puedes comprobar con exactitud. Más a menudo, lo "bueno" es un conjunto de propiedades: el formato correcto, los hechos relevantes incluidos, nada inventado, el caso de fallo manejado correctamente. Anotar qué significa "bueno" antes de ejecutar nada es lo que convierte el "eso se ve bien" en un juicio real de aprobado o suspenso. El conjunto de pruebas más sus criterios de éxito es tu especificación del prompt, hecha concreta.

Decide cómo vas a calificar la salida

Las pruebas de código suelen comprobar igualdad exacta. Las salidas de los prompts rara vez tienen una única respuesta correcta exacta, así que necesitas un enfoque de calificación que encaje. Para salidas estructuradas —un formato específico, un campo obligatorio, un valor de un conjunto fijo— puedes comprobar de forma programática: ¿se analiza?, ¿está presente el campo?, ¿es válido el valor? Estas comprobaciones son baratas y vale la pena automatizarlas porque capturan los fallos mecánicos que más importan en una aplicación.

Para salidas abiertas, la calificación se basa en el juicio: ¿cubre la respuesta los puntos clave?, ¿evita la invención?, ¿da con el tono correcto? Puedes hacerlo leyendo, y para conjuntos pequeños leer está bien y está infravalorado. A mayor escala, un enfoque común es hacer que un modelo califique las salidas frente a una rúbrica que tú escribes —útil, pero solo tan bueno como la rúbrica, y conviene contrastarlo por muestreo con tu propia lectura. La cuestión es elegir un método de calificación de forma deliberada en lugar de caer en el "se ve bien", que no es un método.

Establece una línea base antes de cambiar nada

Antes de empezar a mejorar un prompt, ejecuta tu prompt actual contra el conjunto de pruebas completo y registra cómo lo hace. Esa puntuación es tu línea base —aquello frente a lo que se mide cada cambio—. Sin una línea base, vuelas a ciegas: harás un cambio, verás mejorar una salida y no tendrás ni idea de si el prompt mejoró o empeoró en conjunto. Un cambio que arregla un caso mientras rompe en silencio otros tres parece progreso y es lo contrario.

La línea base es lo que hace que el trabajo con prompts sea acumulativo en lugar de un paseo aleatorio. Cada cambio candidato se ejecuta contra el mismo conjunto y se compara con la línea base. Si lo hace mejor en todo el conjunto, se convierte en la nueva línea base. Si lo hace peor, lo descartas, aunque produjera una salida que te encantó. Este es el bucle central, y es el mismo bucle que hace seguro refactorizar código: una referencia conocida como buena que siempre puedes consultar.

Cambia una sola cosa cada vez

Cuando un prompt rinde poco, la tentación es reescribir la mitad de golpe —nuevas instrucciones, nuevos ejemplos, nuevo formato, todo junto—. Si el resultado es mejor, no sabrás qué cambio ayudó; si es peor, no sabrás qué cambio perjudicó. En ambos casos no has aprendido nada transferible. Cambia una variable, ejecuta el conjunto de pruebas, compara con la línea base y registra el resultado. Luego cambia la siguiente.

Esto es más lento por iteración y mucho más rápido en conjunto, porque construyes conocimiento real sobre a qué responde tu prompt. Aprendes que este ejemplo arregló el problema de formato, que esta instrucción redujo la invención, que esta reestructuración no hizo nada. Ese conocimiento se acumula a lo largo del proyecto y a lo largo de prompts futuros. La reescritura a discreción, en cambio, produce un prompt que funciona por razones que nadie entiende y que nadie puede modificar después con seguridad.

Vuelve a ejecutar el conjunto antes de que cada cambio se publique

La última pieza es tratar tu conjunto de pruebas como una suite de regresión. Los modelos se actualizan, los requisitos cambian, y un prompt que funcionaba puede empezar a fallar en silencio —incluso en casos que solía manejar—. Cada vez que cambies el prompt, e idealmente con regularidad aunque no lo hagas, vuelve a ejecutar el conjunto completo y confirma que nada haya retrocedido. Un cambio que mejora casos nuevos mientras rompe los viejos es una regresión, y la única forma de capturarla es seguir ejecutando los casos viejos.

Esto también te protege cuando cambia el modelo de debajo. Como tu conjunto de pruebas codifica el comportamiento del que realmente dependes, volver a ejecutarlo te dice de inmediato si una nueva versión del modelo aún satisface tus requisitos o rompió algo en silencio. El conjunto de pruebas se convierte en un activo duradero: una definición de "funcionando" que sobrevive a los cambios de modelo, los cambios de equipo y la lenta erosión del recuerdo de por qué el prompt se escribió como se escribió.

En resumen

Trata un prompt como el código de producción que es. Construye un conjunto de pruebas que se parezca al uso real, casos límite incluidos, y anota qué significa una buena salida para cada entrada. Elige un método de calificación a propósito, establece una línea base antes de cambiar nada, y mejora el prompt una variable cada vez mientras mides frente a esa línea base en todo el conjunto. Conserva el conjunto como una suite de regresión y vuelve a ejecutarlo antes de cada cambio y después de cada actualización de modelo. La diferencia entre el folclore de los prompts y la ingeniería de prompts es exactamente esta: uno juzga por una sola demo, el otro mide a través de un conjunto —y solo el segundo sigue funcionando cuando las entradas, el modelo o los requisitos se mueven.