Cómo comparar prompts con mutation testing y datos

Comparar prompts con métricas objetivas es la forma de dejar de decidir por intuición y empezar a decidir por evidencia. Si trabajas generando tests con IA y quieres saber cuál versión de tu prompt rinde mejor, aquí aprendes a montar un experimento controlado que convierte una opinión en un porcentaje medible.

Cuando comparas dos prompts mirando solo un par de salidas, tu cerebro te traiciona. Recuerdas el ejemplo bonito, olvidas el feo y el último que viste pesa más que los demás. Así no se decide nada. La disciplina que le venimos exigiendo a la IA desde el inicio (fijar pruebas, elegir métrica y medir bajo las mismas condiciones) ahora la aplicamos a nuestro propio trabajo.

Por qué comparar salidas sueltas te engaña

Mirar dos o tres resultados y sacar una conclusión es una trampa de percepción. Tendemos a quedarnos con el caso más vistoso y a darle más peso a lo último que vimos [00:07].

La alternativa es un experimento controlado: mismas condiciones, mismo modelo, misma métrica. Solo así la diferencia entre versiones deja de ser "se ve mejor" y pasa a ser un valor de X% contra Y% [00:40].

¿Cómo comparo dos prompts de forma objetiva? Fija un dataset de prueba, elige una métrica medible y corre ambos prompts sobre exactamente los mismos módulos con el mismo modelo. Gana el que tenga mejor número, no el que "se sienta" mejor.

Cómo montar un experimento controlado entre prompts

El proceso tiene tres pasos claros, y cada uno elimina una fuente de sesgo.

• Fijar el dataset de prueba: elige un conjunto de módulos del payments SVC, por ejemplo amounts.py o refunds.py, y congélalos. Ambos prompts se evalúan sobre los mismos módulos [01:00].
• Elegir una métrica objetiva: nada de "se ve mejor". Usa algo medible, como el porcentaje de mutantes matados del oráculo o el número de modos de falla del catálogo que sí se cubrieron [01:26].
• Correr A contra B y tabular: cada prompt genera su suite por módulo, mides la métrica y llenas una tabla A contra B. Gana el mejor número [01:53].

Con esa tabla ya tienes evidencia real de cuál prompt rinde mejor, sin depender de tu memoria.

Qué papel juega el mutation testing en la medición

El mutation testing es la métrica objetiva que sostiene toda la comparación. La idea es someter cada suite a mutantes y contar cuántos sobreviven: mientras menos sobrevivan, más robusta es la cobertura.

En el ejercicio se compararon tres iteraciones de tests generadas para refunds:

• La suite del prompt ingenuo del inicio.
• La suite generada con el failure mode, pero antes del mutation testing.
• La suite iterada después del mutation testing [02:25].

Primero se verificó con tres comandos de unit test que las tres suites pasaran correctamente, y las tres pasaron [03:30]. Después vino la parte reveladora.

¿Qué significa que un mutante sobreviva? Que tus tests no detectaron un cambio introducido a propósito en el código. Menos mutantes sobrevivientes significa una suite más efectiva. No es obligatorio matarlos todos.

Qué resultados arrojó la comparación de las tres suites

Al correr el mutation testing con los mismos tres comandos de la clase anterior (generar la suite en la base de datos, ejecutarla y sacar el reporte), los números mostraron la evolución con claridad.

• La suite ingenua: 10 mutantes sobrevivientes, la que más tenía, como se esperaba [04:15].
• La suite con failure mode: 8 mutantes sobrevivientes [04:28].
• La suite iterada tras mutation testing: 4 mutantes sobrevivientes, un número aceptado porque no todos los mutantes deben morir [04:35].

Para no quedarse con la revisión "por encima", se usó un prompt que pedía a la IA analizar los tres reportes de Cosmic Ray y generar una tabla comparativa con suite, mutantes totales, mutantes sobrevivientes y la relación entre ellos [05:07].

El resultado confirmó lo esperado: la suite con matamutantes tiene la menor tasa de supervivencia, lo que indica una cobertura significativamente más robusta [05:40]. La diferencia entre versiones ya no es una opinión, es un porcentaje.

Por qué el prompt es código y debe versionarse

Aquí está el cambio de mentalidad más importante: el prompt no es texto descartable que se pierde en el historial de un chat. El prompt es código, y como todo código de producción se tiene que versionar, auditar y aprobar [06:00].

Esto implica una forma concreta de trabajar:

• Guardar los prompts en un directorio dedicado dentro del repo.
• Pasar cualquier cambio por un pull request.
• Dejar registro en Git de qué se modificó y quién lo aprobó [02:05].

Esa carpeta de prompts es parte del repositorio, no de tu memoria. Y aquí viene lo interesante para lo que sigue: antes de meter cualquier cosa de IA en continuous integration, primero se mide [06:40].

El siguiente desafío invierte los roles. Si ya logramos que la IA escriba pruebas rigurosas, ahora toca sentarla en la silla del revisor y ver qué pasa cuando le exigimos que juzgue código ya escrito.

¿Ya versionas tus prompts como código o siguen perdidos en el historial del chat? Cuéntame en los comentarios cómo lo estás haciendo.