Tu agente de IA terminó la tarea eso no significa que haya pasado la prueba

Imaginemos que le pedimos a un agente de IA que ejecute un workflow.

El agente empieza, intenta llamar a una acción y falla porque el nombre configurado no existe. Revisa los archivos, encuentra la inconsistencia, corrige el nombre, vuelve a ejecutar y finalmente completa la tarea.

¿La prueba pasó?

Si miramos solamente el resultado final, podríamos decir que sí. El agente recibió un objetivo y lo cumplió.

Pero si lo que queríamos evaluar era la calidad de la configuración original, la respuesta cambia. La prueba falló en el primer intento. El agente no se limitó a usar el sistema: lo reparó mientras lo estaba probando. En el proceso consumió más tokens para arreglar algo que en un principio no tendría que haber pasado. Pero...creo que eso es una conversación para otro momento.

Esta diferencia no parece gran cosa hasta que imaginamos al mismo agente haciendo algo más sensible que corregir un archivo. Podría estar desplegando una aplicación, modificando una base de datos, aprobando una operación financiera o trabajando con información de clientes. En esos casos ya no alcanza con preguntar si llegó al resultado esperado. También necesitamos saber qué hizo para llegar, qué cambió en el camino y si volvería a comportarse de la misma manera.

Durante años, buena parte del testing de software se apoyó en una idea bastante cómoda: ante una entrada conocida, observamos una salida y decidimos si es correcta. Los agentes rompen esa zona de confort porque no se limitan a producir una respuesta. Planifican, eligen herramientas, ejecutan comandos, leen archivos, modifican el entorno y reaccionan ante los errores que encuentran. Ahora mismo tengo a Codex corriendo varios agentes al mismo tiempo creando una API para un dashboard privado con el que guió todo mi negocio online.

El resultado de todo esto es apenas la última foto de una película entera. Osea...yo veo cuando me dice "pip pip, ya lo hice!". Pero antes de eso tuvo mil errores, buscó cómo resolverlos, lo hizo...

Una demo con apariencia de prueba

Un paper reciente llamado AEVAL: From Anecdotal to Deterministic Testing for Agentic Skill Workflows describe un problema que ya empieza a aparecer en los equipos que construyen agentes: muchas evaluaciones siguen siendo anecdóticas.

Alguien modifica una skill (un paquete de instrucciones, código y configuración que le enseña al agente a realizar una tarea), abre una sesión y le pide que la pruebe. Observa una ejecución, ve que el resultado parece razonable y concluye que funciona.

No existe necesariamente un contrato de prueba persistente. Las condiciones pueden cambiar entre intentos y dos personas podrían interpretar el mismo comportamiento de manera distinta. Tampoco queda siempre una evidencia que permita comparar la versión nueva con la anterior.

No es una prueba reproducible. Es una demo con pinta de prueba en realidad.

AEVAL propone convertir cada cambio en una ejecución automatizada contra un contrato que declara el prompt de prueba, el resultado esperado y las credenciales necesarias. El proceso genera artefactos estructurados: el transcript de la ejecución, el resultado de cada assertion, las autocorrecciones realizadas y las sugerencias vinculadas con evidencia.

Los autores describen este pipeline como determinista, pero conviene entender bien qué significa esa palabra en este contexto para no hacernos lío. El agente sigue siendo probabilístico. Puede tomar caminos diferentes entre ejecuciones. Lo que se vuelve persistente y comparable es el contrato, la separación de responsabilidades y la evidencia que queda después de cada prueba.

La idea más interesante del paper, de todos modos, no es integrar agentes en CI. Es detectar una forma nueva de falso positivo.

Cuando un agente competente esconde un defecto

Los agentes están diseñados para recuperarse. Si encuentran un error, prueban otra alternativa. Si falta una configuración, pueden completarla. Si un comando falla, ajustan los parámetros y vuelven a intentarlo.

Como capacidad de producto, esto es valioso. Como mecanismo de evaluación, puede engañarnos.

Los autores llaman self-correction bias al problema que aparece cuando el mismo agente ejecuta una skill, corrige los defectos que encuentra y después evalúa el estado final que él mismo produjo. El reporte puede decir que todo pasó, aunque la versión que recibió el agente no fuera capaz de funcionar sin modificaciones.

El paper muestra este problema con una skill de segmentación cuyos nombres de acciones no coincidían con los del contenedor real. El primer intento terminó con un KeyError. El agente corrigió los nombres en el script generado, volvió a ejecutar y consiguió que las diez assertions pasaran sobre la salida corregida.

Una evaluación ingenua habría mostrado un 100% de éxito. Bazofia.

AEVAL conservó la historia completa: tres errores iniciales y dos cambios necesarios para alcanzar ese resultado. Las assertions relacionadas con la consistencia de la configuración fallaron al evaluar el primer intento. El agente había conseguido completar la tarea, pero la skill, tal como había sido entregada, no había pasado la prueba.

Esto no significa que debamos frenar que un agente se recupere. La recuperación es una capacidad que también merece ser evaluada. Lo que no deberíamos hacer es mezclar dos señales diferentes dentro de un único PASS: que el sistema funcione en el primer intento y que un agente competente sea capaz de repararlo hasta hacerlo funcionar.

Las dos señales contienen información útil, pero responden preguntas distintas.

Quien ejecuta no debería corregir su propio examen

La respuesta de AEVAL es separar estructuralmente al ejecutor del evaluador.

El agente ejecutor puede usar herramientas y producir cambios. Todo queda registrado en un transcript que distingue el primer intento de las correcciones posteriores. El evaluador, en cambio, recibe acceso de sólo lectura a ese transcript, a los archivos producidos y a assertions definidas antes de observar la salida. No puede intervenir en la ejecución ni modificar aquello que está calificando.

La separación importa por dos razones.

Primero, evita que la misma entidad que produjo y reparó el resultado decida qué tan buena fue su propia actuación. Segundo, impide adaptar los criterios después de ver la respuesta. Si escribimos las assertions al final, es muy fácil terminar midiendo aquello que casualmente salió bien.

No es un problema exclusivo de la IA. En testing siempre intentamos evitar que el oráculo se contamine con el resultado observado. La diferencia es que ahora el sistema bajo prueba también puede interpretar, negociar y hasta modificar las condiciones de su examen.

Separar ejecutor y evaluador tampoco resuelve todo. Un evaluador basado en IA puede interpretar de manera diferente qué debería bloquear una entrega, pasar por alto una autocorrección o apartarse del formato exigido. El propio estudio encontró diferencias consistentes entre familias de agentes al clasificar la severidad de los mismos problemas.

El evaluador también es parte del sistema y, por lo tanto, también necesita calibración y testing.

Qué deberíamos observar al testear un agente

Evaluar la respuesta final sigue siendo necesario, pero deja de ser suficiente. Una estrategia más completa debería observar al menos cinco dimensiones.

• El resultado. ¿La tarea terminó en el estado esperado? ¿Las afirmaciones del agente están respaldadas por los artefactos reales?

• La trayectoria. ¿Qué decisiones tomó? ¿Qué herramientas llamó, en qué orden y con qué parámetros? ¿Hubo pasos innecesarios o que aumentaron el riesgo?

• Los límites. ¿Usó únicamente los permisos y recursos permitidos? Un agente puede llegar a una respuesta correcta y aun así violar una restricción importante.

• La recuperación. ¿Qué hizo cuando algo falló? Recuperarse puede ser una fortaleza, pero una corrección no debería borrar el fallo que la hizo necesaria.

• La repetibilidad. ¿El comportamiento se mantiene entre ejecuciones, versiones y runtimes? No alcanza con repetir el caso hasta conseguir una ejecución convincente. También necesitamos observar cuánto cambia el camino y qué riesgos aparecen en esas variaciones.

Estas dimensiones cambian la pregunta central. Ya no estamos evaluando solamente si la respuesta es correcta. Estamos evaluando si existe evidencia suficiente para confiar en la forma en que el sistema la produjo.

De una demo convincente a evidencia reproducible

No hace falta construir una plataforma completa para empezar. Si hoy tuviera que armar una estrategia mínima para evaluar un agente, elegiría un caso de alto valor y convertiría su expectativa en un contrato persistente:

1. Definiría el objetivo y las assertions antes de ejecutar.

2. Prepararía un entorno aislado y un estado inicial conocido.

3. Registraría prompts, herramientas, argumentos, respuestas, cambios y tiempos.

4. Separaría la ejecución de la evaluación, con un evaluador sin permisos de escritura.

5. Reportaría por separado el resultado del primer intento y el resultado posterior a cualquier recuperación.

6. Repetiría el caso varias veces y compararía no sólo la salida, sino también la trayectoria, los permisos utilizados y las autocorrecciones.

La acción más pequeña que produce evidencia real ya es una mejora. Guardar el transcript es mejor que confiar en el resumen del agente. Definir las assertions antes de la ejecución es mejor que decidir qué importa después de ver lo que salió bien. Conservar el primer fallo es mejor que permitir que desaparezca detrás de una recuperación exitosa.

También conviene mantener cierto escepticismo respecto de AEVAL. El trabajo se concentra en skills de agentes orientados a código y presenta resultados cualitativos sobre un entorno de producción; el estudio cuantitativo completo todavía queda para una versión extendida. La prohibición de simular resultados se impone mediante instrucciones, no mediante una barrera técnica infalible, y atribuir qué corrección causó qué éxito puede volverse difícil en workflows largos.

No es una receta universal. Es un marco útil para pensar con más precisión.

El testing no desaparece cuando el agente parece inteligente

Cuanto más autónomo es un sistema, menos razonable resulta evaluarlo únicamente por su última respuesta.

Un chatbot puede equivocarse en una frase. Un agente puede equivocarse en una secuencia de decisiones, utilizar una herramienta incorrecta, modificar algo que no debía y aun así terminar mostrando una pantalla verde. La fluidez con la que explica el resultado tampoco es evidencia de que el proceso haya sido seguro.

Ahí aparece una oportunidad enorme para quienes trabajamos en calidad. No se trata sólo de aprender a escribir prompts ni de usar IA para producir más casos de prueba. Se trata de diseñar evaluaciones, construir oráculos, observar trayectorias, separar señales y decidir qué evidencia alcanza para confiar.

El problema de fondo —dejar de confundir una salida convincente con evidencia de calidad— es parte de lo que trabajo en IA y Testing: El curso definitivo. Allí vemos cómo cambia el testing cuando los resultados dejan de ser completamente deterministas y cómo llevar ideas como evaluación semántica, robustez, seguridad y repetibilidad a pruebas concretas.

Durante años preguntamos si el software hacía lo que debía.

Con los agentes vamos a tener que sumar una pregunta más incómoda: ¿podemos demostrar que llegó hasta ahí de una forma aceptable?