‘Prompts Aren’t Real’: medir importa más que escribir prompts

Por qué un ingeniero con 25 años de experiencia dice que los prompts "no son reales"

Dan, ingeniero en Los Ángeles que lleva un cuarto de siglo escribiendo software, subió al escenario de evaluation.club con una tesis incómoda para cualquier equipo que hoy construye agentes con LLMs: "los prompts no son reales". Su argumento central es que el contenido textual de un prompt importa mucho menos de lo que la industria lleva años vendiendo como prompt engineering, y que el verdadero activo son las medidas que permiten evaluarlo y mejorarlo automáticamente.

La charla recorre el ciclo completo: desde la frustración de ver a un modelo ignorar una restricción sencilla (como devolver un título de menos de 80 caracteres) hasta un sistema self-improving donde un optimizador con LLM reescribe prompts hasta converger en una versión que cumple las métricas, aunque el resultado final sea "absolutamente desquiciado", como dice el propio Dan.

La trampa de confiar en un solo intento del LLM

Una de las ideas más prácticas de la charla es el concepto de pass^k (que Dan llama "pass power k"). En lugar de ejecutar un test una sola vez, lo corres k veces y exiges que pase las k. Es una forma barata de detectar lo que él llama comportamientos "encantados":

• Una fracción pequeña de las respuestas falla en cosas simples (romper un esquema JSON, ignorar instrucciones).
• La falla cambia según el resto del prompt: añadir un skill nuevo puede despertar bugs en otro comportamiento.
• Los modelos más avanzados siguen fallando en esto.

Su ejemplo favorito: un campo JSON llamado title que el modelo a veces inunda con notas repetitivas sobre el propio JSON. Renombrarlo a heading lo arregló. "Es una solución completamente desquiciada", dice Dan, "y espero que se rompa otra vez en algún momento".

El pass^k se convierte así en el instrumento de medición que hace el resto del sistema posible: si no puedes decir cuántas de cada cien veces falla tu agente en una tarea concreta, no tienes forma de saber si un cambio lo mejoró o lo empeoró.

Adversarios primero, prompt después

Dan propone invertir el orden tradicional: en lugar de que un experto de dominio escriba un prompt y lo entregue a ingeniería, se usa un LLM para generar escenarios adversariales, formas en que un usuario malicioso podría subvertir el prompt y situaciones benignas que el nuevo prompt podría romper. Cada escenario se convierte en un test pass^k.

Luego se ejecutan los tests con y sin la nueva instrucción. Si el prompt sube al menos un poco la métrica y mantiene el resto, se queda. Si no, el modelo ya era "más resistente a la dirección de lo que esperabas" y hay que probar otra estrategia. En palabras de Dan: "a veces los LLMs ya son buenos en las cosas que nos preocupan".

Esta inversión cambia quién es dueño de qué. Lo que Dan llama "the voice team owns the voice prompts" es, según él, "el patrón equivocado, no solo para escalar, sino conceptualmente". El equipo de voz debería ser dueño de las medidas, no del texto.

Optimizadores automáticos: GEPA y la evidencia pública

Una vez que tienes tests repetibles, ya puedes enchufar el prompt a un optimizador. Dan menciona GEPA (Genetic-Pareto) como ejemplo. No es una herramienta de nicho: el paper "GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning" (arXiv:2507.19457, publicado en julio de 2025, con autores como Matei Zaharia y Omar Khattab de Databricks) reporta que GEPA supera al optimizador líder anterior MIPROv2 por más de 10% en accuracy y al método de RL GRPO por 6% en promedio, hasta 20%, usando hasta 35 veces menos rollouts.

El repositorio público del proyecto, en github.com/gepa-ai/gepa, documenta casos de uso ya en producción: Shopify, Databricks, Dropbox, OpenAI, Pydantic, MLflow y Comet ML lo utilizan. Entre los números concretos reportados por sus usuarios:

• Nubank documentó que GEPA dentro de DSPy optimizó prompts de LLM-as-a-Judge y elevó la accuracy de evaluación de 68,88% a 88,89% en su sistema de soporte al cliente a escala de 100 millones de usuarios, según el README del proyecto.
• Databricks afirma haber construido agentes enterprise "90 veces más baratos" con GEPA frente a su baseline anterior.

El patrón es siempre el mismo: un optimizador con un LLM dentro reflexiona en lenguaje natural sobre por qué un prompt falló, propone una modificación y vuelve a probar. Tras varios ciclos, el prompt converge en algo que no se parece en nada al original, y eso, paradójicamente, es buena señal.

Holdout tests: la cura contra el sobreajuste

El riesgo evidente es que el optimizador haga trampa: que codifique literalmente los ejemplos de los tests en el prompt. Funcionaría perfecto contra los tests, pero fallaría contra cualquier input nuevo. Dan llama a esto el problema del sobreajuste.

La solución es separar el set de evaluación: el optimizador solo ve una parte de los casos (entrenamiento), y otra parte, el holdout, queda reservada para validar. Si el holdout pasa, el prompt generaliza. Si el holdout retrocede, se vuelve al paso anterior y se prueba otra mutación.

Es exactamente la disciplina de validación que se usa en machine learning clásico, aplicada por primera vez de forma sistemática a la optimización de prompts.

El flywheel: el dominio construye medidas, no prompts

El cierre de la charla resume la filosofía: "Los prompts no son la cosa. Los prompts son vectores cuyo contenido textual no importa en absoluto. El loop de feedback que mejora solo es la cosa".

En la práctica, eso significa que un equipo de producto o legal no debería invertir tiempo puliendo la prosa de un prompt. Su trabajo debería ser producir:

• Datasets golden de respuestas buenas y malas etiquetadas por humanos.
• Tests pass^k que reflejen los escenarios críticos del negocio.
• Jueces LLM para criterios subjetivos como brand voice, y aquí Dan añade un matiz importante: el propio prompt del juez se convierte en otro problema de optimización dentro del problema original.

Una vez montados, los tests se ejecutan en cada despliegue y los jueces se corren sobre muestras de conversaciones reales en producción. Los casos donde el agente falló se convierten en nuevos tests duros, y el optimizador vuelve a iterar. Es un flywheel que se sostiene solo.

Qué significa esto para tu startup

Si estás construyendo un agente que personas reales van a usar, ya sea atención al cliente, ventas u operaciones internas, la charla de Dan propone una reorganización concreta del trabajo:

• Empieza por el test, no por el prompt. Antes de escribir una sola instrucción, define qué quieres medir (tasa de éxito al llamar la herramienta correcta, respeto de la voz de marca, no revelar el sistema interno). Sin medida, todo cambio es a ciegas.
• Monta un set pass^k desde el día uno. Cada caso crítico se ejecuta N veces; lo que no pasa N veces de N no es fiable en producción. Si tu base de código no tiene esa infraestructura, es lo primero que hay que construir.
• Pon a tu experto de dominio a etiquetar, no a escribir prompts. Su valor está en producir datasets golden de ejemplos buenos y malos. El optimizador (GEPA, DSPy, MLflow optimize_prompts, o lo que elijas) hace el resto.
• Asume que el prompt final será ilegible. Si tu equipo tiene que releer el prompt generado para "entenderlo", estás optimizando mal. Lo que importa es la métrica sobre el holdout.
• Reserva un set holdout desde el inicio. Sin él, tu optimizador hará trampa y tu agente fallará silenciosamente en producción.

La conclusión de Dan es dura pero útil: "Entregarle a alguien un prompt sin medida es una forma de psicosis de IA". Para un founder que está metiendo su primer agente en producción con presupuesto limitado, la traducción práctica es simple: mide o muere.

Fuentes

• Prompts Aren't Real — evaluation.club (fuente original)
• GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning (arXiv:2507.19457)
• GitHub — gepa-ai/gepa