El agente de Momentic encontro 269 errores en una hora, tres veces mas que Codex

Las pruebas automatizadas detectan bien aquello que el equipo ya sospecha. Si un desarrollador escribe el escenario «abrir el carrito, pulsar pagar y ver la confirmacion», el sistema repetira fielmente esos mismos pasos. Pero no intentara pulsar dos veces un boton, volver atras en mitad del pago ni abrir un formulario en una pantalla estrecha, a menos que alguien anada expresamente esos pasos.

La startup Momentic propone otro enfoque. Su agente de QA, Mo, obtiene acceso a una aplicacion en funcionamiento y se comporta como un usuario persistente: inspecciona las pantallas, crea un mapa de las acciones disponibles, ejecuta comprobaciones en paralelo y documenta los problemas encontrados. Para ello no necesita el codigo fuente.

En un benchmark publicado por la empresa, Mo encontro 269 errores confirmados en 60 minutos. Codex con Playwright MCP detecto 86, Claude Code encontro 59 y Devin, 27. Suena impresionante, pero la principal conclusion no es que «un agente vencio a los demas». Lo mas interesante es otra cosa: las pruebas se estan separando gradualmente de los escenarios escritos de antemano y se estan convirtiendo en una exploracion autonoma del producto.

Como encuentra el agente lo que no figura en el caso de prueba

Imaginemos un servicio de reparto. Tras una nueva actualizacion, las pruebas convencionales comprueban el inicio de sesion, la busqueda de restaurantes y la realizacion del pedido. Todo aparece en verde. Sin embargo, al regresar de la ventana de pago, la direccion seleccionada se restablece de repente. El equipo no habia previsto esta ruta, por lo que no existe una prueba para ella.

Mo empieza creando un grafo de la aplicacion: que pantallas estan disponibles y que acciones las conectan. Distribuye las secciones grandes entre agentes independientes. Uno explora la autenticacion, otro el carrito y un tercero el pago. Componentes especializados analizan la imagen de la pantalla, localizan los elementos necesarios de la interfaz y siguen los cambios de estado.

Para impedir que las comprobaciones paralelas corrompan los datos de las demas, los agentes reservan los recursos compartidos. Varios procesos pueden leer simultaneamente un mismo objeto, pero solo uno puede modificarlo. Esto es importante en escenarios con una cuenta compartida, pedidos y registros de prueba en la base de datos.

Este enfoque no exige definir de forma rigida un XPath, el texto de un boton o un atributo aria concreto para cada accion. El agente recibe un objetivo en lenguaje natural y busca por si mismo como alcanzarlo. Cuando cambia el diseno de la interfaz, esto puede hacer que las comprobaciones sean menos fragiles, aunque no elimina por completo el problema de las pruebas inestables.

Las cifras parecen solidas, pero es un benchmark del proveedor

El conjunto incluyo 1.396 errores etiquetados en cuatro aplicaciones de codigo abierto: Gitea, Metabase, Twenty y Saleor. En una hora, Mo logro una exhaustividad del 19,3% con una precision del 84%. Codex obtuvo una exhaustividad del 6,2%, aunque su precision fue ligeramente superior: un 86%.

En otras palabras, Mo encontro muchos mas defectos conocidos, pero entre sus avisos hubo algo mas de falsos positivos. Tambien existe una diferencia de costes: cada error confirmado costo $2,67 con Mo, frente a $0,80 con Codex. Segun estos datos, Mo resulta mas eficaz para una exploracion amplia del producto, mientras que Codex parece mas economico cuando el presupuesto es limitado.

Los resultados deben interpretarse con cautela. Momentic preparo el benchmark, el conjunto de condiciones y el sistema de evaluacion. Un modelo de lenguaje realizo la comprobacion inicial y despues una persona reviso los resultados. La empresa publico el conjunto de datos y el entorno de pruebas, por lo que el experimento puede repetirse, pero las cifras presentadas todavia no sustituyen una comparacion independiente en el producto de cada equipo.

Que debe hacer ahora un equipo

No hace falta descartar Playwright ni Selenium. Las pruebas basadas en escenarios siguen siendo utiles para rutas criticas y predecibles: inicio de sesion, pago, asignacion de permisos y persistencia de datos. Lo mas razonable es usar la exploracion mediante agentes como una segunda capa para buscar problemas desconocidos.

Un piloto practico es sencillo: ejecutar el agente en la vista previa de cada pull request importante, limitar su tiempo y presupuesto, y confirmar manualmente los defectos encontrados. Despues se puede comparar cuantos errores unicos detecto, cuantos avisos resultaron falsos y cuantas horas de QA manual se ahorraron.

Si el agente encuentra de manera constante fallos que las pruebas existentes no detectan, puede incorporarse al proceso de lanzamiento. Si solo repite comprobaciones ya conocidas y genera ruido, las cifras llamativas de un benchmark ajeno no aportan nada al equipo.