Vibe Code Bench: ¿la IA construye una app web desde cero?

Vibe Code Bench no prueba fragmentos de código aislados. Entrega una descripción de aplicación web y pide que el modelo construya la app desde cero, con interfaz, lógica y pruebas. Es una prueba de ingeniería de software de punta a punta, no de autocompletado.

En este artículo vas a ver:

• Lo que Vibe Code Bench pide que el modelo haga.
• Cómo funciona la evaluación (pasos, límites, criterio de aprobación).
• El ranking oficial del 5 de noviembre de 2026 y lo que muestran los números.
• Por qué este benchmark importa para quien usa agentes de código.

Qué es Vibe Code Bench

Vibe Code Bench es un benchmark que evalúa si un modelo logra construir una aplicación web a partir de una descripción en lenguaje natural. Cada tarea pide una app funcional, con interfaz, lógica de negocio y pruebas. El modelo trabaja solo, sin acceso a internet, y entrega el código fuente completo.

La idea es medir capacidad de construcción, no de corrección. El modelo necesita tomar decisiones de arquitectura, implementar la interfaz, escribir la lógica y asegurar que las pruebas pasen. Esto está más cerca del trabajo real de un desarrollador que corregir un bug en un repositorio existente.

Esto diferencia a Vibe Code Bench de benchmarks como el CursorBench, que mide la capacidad de editar código en un editor. Aquí el modelo construye desde cero. También se diferencia del SWE-bench Pro, que parte de un repositorio existente y pide un parche.

Cómo funciona la evaluación

Vals AI evalúa los modelos en 125 tareas públicas de Vibe Code Bench. Cada tarea proporciona una descripción de aplicación web. El agente recibe un terminal bash, un sandbox offline y el prompt estándar del benchmark. Puede inspeccionar los archivos entregados, pero no puede usar internet, consultar registros de paquetes ni usar herramientas de análisis binario.

La submisión contiene archivos de código fuente y un script de compilación. Vals compila y ejecuta las pruebas en un contenedor nuevo. El agente tiene hasta 1.000 pasos, límite de 6 horas de reloj y 180 segundos de timeout por acción. La salida de las herramientas se trunca en 10.000 caracteres en los extremos.

Una app pasa si la interfaz se renderiza, la lógica funciona y las pruebas ocultas pasan. No hay crédito parcial por explicación: o la app funciona, o no.

El ranking oficial del 5 de noviembre de 2026

Vals probó 125 modelos en Vibe Code Bench. Claude Sonnet 5.5, ejecutándose en OpenHands, lidera con 92,39%, seguido por Claude Sonnet 5 con 89,50% y Claude Sonnet 4.6 con 85,20%. La mayoría de los modelos queda por debajo de 70%.

La diferencia entre el primero y el segundo es de casi 3 puntos porcentuales. Esto muestra que construir apps web desde cero es una tarea que los modelos de frontera ya dominan razonablemente bien, pero aún con margen de error.

Vals también compara modelos en costo y latencia por tarea. Claude Sonnet 5.5 en OpenHands es más caro por intento, pero es el único que pasa de 92%.

Cómo probar hoy

Para quien quiere probar, Vals pone a disposición la metodología y los resultados en la leaderboard oficial. Puedes ejecutar los mismos modelos en tu propio proyecto y comparar el resultado con el ranking publicado.

Vals también publica el código de evaluación y los prompts usados, lo que permite reproducir las pruebas en otros modelos y entornos. Esto es útil para equipos que quieren validar si un modelo nuevo cumple con sus necesidades antes de adoptarlo en producción.

Por qué importa este benchmark

El Vibe Code Bench mide una capacidad que los benchmarks de patch no capturan: la habilidad de construir software desde cero a partir de una descripción. Esto es útil en tres escenarios reales.

Primero, prototipado rápido: cuando necesitas una app funcional en horas, no en días. Segundo, validación de agentes de código que necesitan entregar funcionalidades completas, no solo correcciones. Tercero, comparación entre modelos para elegir cuál usar en proyectos de construcción.

El resultado de 92,39% también es un recordatorio de límite. Incluso el mejor modelo se equivoca en casi el 8% de los casos. Para quien usa agentes de código en el día a día, esto refuerza la necesidad de revisión humana y pruebas, como se discutió en el análisis del FeatureLoop en repositorios reales.