Los mejores agentes de IA superan hasta el 98% de las pruebas, pero entregan un producto funcional en un máximo del 65% de las compilaciones

Imagine que le pide a un agente de IA una aplicación de taxis. Primero crea el pedido de viajes; después usted le pide penalizaciones por cancelación, conductores con varios coches, ganancias por viaje y pago dividido. Cada nueva función se apoya en el código que el agente escribió antes.

Si rompe una anterior (por ejemplo, si las ganancias dejan de tener en cuenta las penalizaciones), el producto es inutilizable, aunque casi todo lo demás funcione. Así se hace hoy «vibe coding» en la plataforma Replit, mientras que los benchmarks habituales comprueban una sola tarea bien definida y muchos ya están casi agotados. Por eso Replit ha lanzado ViBench 2.

0. El resultado: los tres modelos más potentes superan hasta el 98% de los escenarios de prueba, pero entregan un producto completo y funcional en un máximo del 65% de las compilaciones. La proporción de compilaciones totalmente funcionales a la primera se llama pass@1.

Si construye un producto con un agente, es la métrica que debe mirar.

Cómo funciona la prueba

El agente parte de un proyecto vacío y recibe los requisitos función a función, en un único diálogo largo. Cada producto lleva entre 9 y 18 peticiones, el diálogo puede superar los 200 mil tokens y cada etapa tiene un límite de 300 pasos del agente y dos horas. En total, el benchmark incluye 17 productos web completos inspirados en Amazon, Asana, Discord, Figma, GitHub, Google Docs, Jira y Uber. Suman 241 peticiones de nuevas funciones y 544 escenarios de prueba, y el 85% de esos escenarios comprueba varias funciones a la vez.

Nadie revisa el resultado entre una petición y otra. La nota se pone una sola vez, cuando el producto está listo, y la asigna un agente de navegador: abre la aplicación en un Chromium real y actúa como un usuario. Una compilación solo se da por buena si pasan todos los escenarios del producto, que van de 26 a 41 según el caso. La arquitectura la elige el propio agente, así que las pruebas evalúan el resultado y no un diseño concreto. Que aparezca la etiqueta «Waiting at stop» en lugar de «At Stop» no cuenta como error.

Los autores también auditaron al propio verificador. Cuando un escenario falla, lo revisa hasta cuatro veces, hasta que tres valoraciones coinciden. Detectó los 34 bugs introducidos a propósito y solo da un 0,8% de falsos «aprobados». El verificador y la preparación de los datos de prueba funcionan con Opus 5.5.

La brecha entre «casi» y «listo»

Los autores probaron nueve modelos. Los líderes, GPT-6.1 Sol, GPT-6 Astra y Opus 5.5, superan hasta el 98% de los escenarios. Pero entregan un producto totalmente funcional en no más del 65% de las compilaciones. En la mayoría de las compilaciones fallidas de este trío no pasaron solo uno o dos escenarios. El margen de mejora está en la fiabilidad, no en la capacidad de hacer algo. Ningún modelo abierto entregó nunca un producto totalmente funcional.

La evolución, sin embargo, es rápida. En tres lanzamientos de una misma familia de modelos, el pass@1 en los productos públicos subió del 3% al 53%, y el coste de cada compilación se redujo a menos de la mitad. Esto importa también para otros benchmarks: en Vibe Code Bench, el mejor resultado pasó del 61,8% en marzo de 2026 a más del 90% en seis modelos a finales de octubre. Las pruebas en las que el agente resuelve una sola tarea chocan pronto con el techo. La compilación larga con verificación del producto terminado aún no lo alcanza.

Qué hacer con esto

El porcentaje medio de pruebas superadas oculta lo esencial: una sola función antigua rota deja la compilación inservible. Evalúe los modelos por la proporción de compilaciones impecables. Revise el producto en su conjunto, como lo haría un usuario, y no solo pasos aislados. La propia Replit usa ViBench 2.0 para elegir los modelos de su plataforma y para valorar los cambios en su agente de producción.

Hay también salvedades. Replit es autora del test y, a la vez, quien lo utiliza. Pero el lanzamiento lo verificó un equipo externo, Fireworks: montó el benchmark publicado y ejecutó cada modelo con un solo comando, sin retoques. Ocho productos están publicados en GitHub junto con el lanzador y el verificador. Otros nueve permanecen ocultos para que los modelos no se entrenen con el test. Los archivos públicos llevan una cadena especial que permite filtrarlos de los datos de entrenamiento.