Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development

El artículo presenta "Vibe Code Bench", un nuevo benchmark que evalúa la capacidad de 16 modelos de IA avanzados para desarrollar aplicaciones web completas de principio a fin mediante agentes autónomos, revelando que la fiabilidad en este proceso sigue siendo un desafío significativo y destacando la importancia de la autoevaluación durante la generación y la alineación de los evaluadores.

Lo esencial

Imagina que hasta ahora, probar si una Inteligencia Artificial (IA) podía programar era como pedirle a un estudiante que resolviera una sola ecuación matemática en un examen. Si la resolvía bien, decíamos: "¡Genial, sabe matemáticas!".

Pero en la vida real, construir software no es resolver una sola ecuación; es como construir una casa entera desde cero, desde los cimientos hasta el techo, con electricidad, fontanería y que la gente pueda vivir dentro.

Este paper, llamado "Vibe Code Bench", presenta un nuevo examen para las IAs que es mucho más difícil y realista. Aquí te lo explico con analogías sencillas:

1. El Nuevo Examen: De "Escribir una frase" a "Construir un restaurante"

Antes, las pruebas de IA pedían: "Escribe una función que sume dos números".
Vibe Code Bench dice: "Aquí tienes una idea: 'Quiero una app para que la gente reserve estacionamientos en la ciudad'. ¡Constrúyela!"

La IA tiene que:

• Escribir todo el código (frente y fondo).
• Configurar la base de datos (donde se guardan los datos).
• Conectar servicios externos (como cobrar con tarjeta o enviar correos).
• Lo más importante: La IA debe probarse a sí misma. Tiene que abrir un navegador virtual, hacer clic en los botones, registrarse como usuario y asegurarse de que todo funcione antes de decir "terminado".

2. ¿Cómo se califica? El "Inspector de Obras" Robot

No hay humanos revisando el código línea por línea. En su lugar, usan un agente autónomo (un robot con "ojos" y "dedos" digitales) que actúa como un cliente real.

• El robot entra a la aplicación creada por la IA.
• Sigue una lista de tareas: "Regístrate", "Sube una foto", "Paga $10".
• Si el robot logra completar el 90% de los pasos, la aplicación aprueba.
• Si la aplicación se cae, no carga o el botón de "Pagar" no funciona, reprueba.

Es como si contrataras a un inspector de construcción que no solo mira los planos, sino que camina por la casa, abre las puertas, prueba el grifo y se sienta en el sofá para ver si está listo para vivir.

3. Los Resultados: ¡Todavía estamos aprendiendo!

Probaron a las 16 IAs más potentes del mundo (como las de OpenAI, Google, Anthropic, etc.).

• El mejor resultado: La IA ganadora (GPT-5.3-Codex) logró construir aplicaciones que funcionaban perfectamente en solo el 61.8% de los intentos.
• La realidad: Esto significa que casi 4 de cada 10 veces, la IA falla en construir la app completa. A veces olvida poner la puerta, a veces la electricidad no funciona, o a veces el grifo gotea.

La lección: Las IAs son muy buenas escribiendo código suelto, pero todavía les cuesta mucho orquestar todo el proceso para crear un producto final que funcione solo.

4. El Secreto de los Éxitos: "El que se prueba, pasa"

El estudio descubrió algo fascinante: las IAs que tienen éxito son las que se ponen a prueba a sí mismas mientras trabajan.

• Analogía: Imagina a un cocinero.
  • El cocinero novato mezcla los ingredientes y sirve el plato sin probarlo. (Resultado: A veces está salado o crudo).
  • El cocinero experto prueba la sopa, ajusta la sal, prueba de nuevo y luego sirve.
• Las IAs que usaban el navegador para "probar" su propia aplicación mientras la construían tuvieron un rendimiento mucho mejor. Las que solo escribían código sin verificar, fallaban más.

5. El Problema del "Juez"

Otro hallazgo interesante es que quién califica importa mucho.

• Si usas un "juez" (otra IA) diferente para calificar el trabajo, la nota puede cambiar drásticamente.
• Es como si un profesor de matemáticas le diera un 10 a un examen y otro profesor le diera un 5 al mismo examen porque tienen criterios distintos. El estudio encontró que elegir el "juez" correcto es vital para saber si la IA realmente aprendió.

En Resumen

Este paper nos dice que la era de "pedirle a la IA que escriba un código" ya pasó. Ahora estamos en la era de "pedirle a la IA que construya un producto".

Aunque las IAs son increíbles, todavía no son arquitectos perfectos. A veces construyen casas bonitas que se caen al primer viento. Pero con este nuevo examen ("Vibe Code Bench"), sabemos exactamente dónde están fallando y cómo mejorarlas: haciéndolas probar su propio trabajo una y otra vez hasta que funcione.

El futuro no es solo que la IA escriba código, sino que pueda crear software que la gente pueda usar de verdad. Y estamos a medio camino de lograrlo.

Resumen técnico

Resumen Técnico: Vibe Code Bench - Evaluación de Modelos de IA en el Desarrollo de Aplicaciones Web de Extremo a Extremo

1. El Problema: La Brecha en la Evaluación de "Cero a Uno"

Aunque la generación de código se ha convertido en uno de los casos de uso de mayor impacto de la IA, las métricas existentes (como HumanEval, MBPP o SWE-Bench) se centran en tareas aisladas: síntesis de funciones, resolución de errores en bases de código existentes o problemas de programación competitiva.

Existe una brecha crítica: no hay un estándar para evaluar la capacidad de los modelos para construir una aplicación web completa, desplegable y funcional desde cero, basándose únicamente en una especificación en lenguaje natural. Este escenario "de cero a uno" implica la generación de múltiples archivos, configuración, integración de servicios (autenticación, bases de datos, pagos) y flujos de trabajo de usuario, algo que las herramientas actuales de "vibe coding" prometen pero que no se han medido sistemáticamente.

2. Metodología: Vibe Code Bench (VCB)

Los autores presentan Vibe Code Bench, un nuevo benchmark diseñado para llenar esta brecha mediante un enfoque de evaluación basado en el comportamiento del usuario final.

A. Diseño del Dataset

• Especificaciones: 100 especificaciones de aplicaciones web realistas, divididas en un conjunto de validación pública (50 tareas) y un conjunto de prueba oculto (50 tareas).
• Categorías de Dominio:
  • Individual (24): Herramientas personales sin autenticación compleja.
  • Fundador Solitario (45): Aplicaciones para negocios con autenticación básica (email) o compleja.
  • Herramienta Empresarial (31): Sistemas internos con jerarquías de roles y permisos.
• Integraciones: El 28% de las tareas requieren integración con servicios externos (Stripe para pagos y MailHog para correos), simulando entornos de producción reales.
• Flujos de Trabajo: Cada tarea está acompañada de 6 a 23 flujos de trabajo automatizados (totalizando 964 flujos y 10,131 subpasos) que simulan la interacción de un usuario real en el navegador.

B. Entorno de Generación (Harness)

• Infraestructura: Se utiliza una versión modificada de OpenHands, un entorno de desarrollo en contenedores aislados.
• Recursos: Los modelos tienen acceso a un terminal, un navegador web y servicios backend (Supabase para BD/Auth, Stripe, MailHog).
• Restricciones:
  • Stack Tecnológico Fijo: React + Vite (frontend), Tailwind CSS, Supabase (backend). Esto asegura comparabilidad.
  • Tiempo Límite: 5 horas por aplicación.
  • Despliegue Obligatorio: La aplicación debe compilarse y ejecutarse mediante Docker Compose para ser evaluada.

C. Pipeline de Evaluación Automatizada

A diferencia de las pruebas unitarias o de DOM (que son frágiles), VCB utiliza un agente de navegador autónomo (basado en Browser Use) para evaluar la aplicación:

1. Despliegue: Verifica que la aplicación se inicie correctamente.
2. Ejecución: El agente navega, hace clic y llena formularios siguiendo los flujos de trabajo definidos.
3. Puntuación: Un flujo se considera aprobado si el 90% de sus subpasos se completan exitosamente. La precisión final es el porcentaje de flujos aprobados por aplicación.

3. Contribuciones Clave

1. Nuevo Dataset y Pipeline: El primer benchmark de 100 especificaciones de aplicaciones web completas con evaluación basada en agentes de navegador.
2. Evaluación Exhaustiva de Modelos: Análisis de 16 modelos de vanguardia (OpenAI, Anthropic, Google, Alibaba, etc.), incluyendo métricas de costo, latencia y análisis de errores.
3. Protocolo de Alineación de Evaluadores: Un estudio que compara la evaluación automática (modelos) contra la humana, demostrando que la elección del evaluador impacta drásticamente los resultados.
4. Descubrimiento de "Self-Testing": Identificación de que el uso del navegador por parte del modelo durante la generación (auto-prueba) es un predictor fuerte de éxito.

4. Resultados Principales

Rendimiento General

• Precisión Limitada: Incluso el mejor modelo (GPT-5.3-Codex) alcanzó solo un 61.8% de precisión en el conjunto de prueba. Esto indica que el desarrollo de aplicaciones de extremo a extremo sigue siendo un desafío no resuelto.
• Brecha de Rendimiento: La diferencia entre el modelo mejor y el peor es masiva (de 61.8% a 1.2%). A diferencia de SWE-Bench, donde las diferencias son pequeñas (2.8%), en VCB la diferencia entre el segundo y el último lugar es de más del 40%.
• Modelos Dominantes: Los modelos de OpenAI y Anthropic dominan la parte superior. Los modelos de peso abierto (Open-weight) como GLM-5, Qwen y Kimi rinden significativamente peor (15-24%).

Análisis de Factores

• Auto-Prueba (Self-Testing): Existe una fuerte correlación positiva (Pearson r = 0.72) entre el uso del navegador por parte del modelo para probar su propia aplicación durante la generación y la precisión final. Los modelos que iteran y prueban más tienden a tener más éxito.
• Volumen de Edición vs. Calidad: El número de ediciones de archivos no predice el éxito (r = 0.09); la calidad del uso de las herramientas es lo que importa.
• Dificultad e Integraciones:
  • La precisión cae drásticamente de tareas "Fáciles" a "Difíciles".
  • Las integraciones con Stripe reducen significativamente el rendimiento (caída del 71% al 29% en el mejor modelo cuando se requiere Stripe + Email).
• Costo y Latencia: Existe una relación de rendimientos decrecientes. Modelos más caros y lentos (como GPT-5.3-Codex) son más precisos, pero modelos como Claude Opus 4.6 ofrecen un rendimiento casi óptimo con menor costo y latencia.

Análisis de Errores

• Fallas de Implementación: El 46.7% de los fallos se deben a características faltantes (el modelo no implementó lo solicitado).
• Problemas de Autenticación: El 20.4% de los fallos son por problemas de registro/inicio de sesión.
• Distribución Bimodal: Los modelos tienden a fallar completamente (0% de éxito en flujos) o a tener un éxito muy alto, con pocos casos de éxito parcial. La mejora de los modelos se logra principalmente reduciendo las fallas totales, no mejorando ligeramente los casos parciales.

5. Estudio de Alineación Humana

El estudio reveló que la elección del evaluador es crítica:

• Alineación Humano-Humano: Alta (88.6% - 93.6%).
• Alineación Modelo-Humano: Variable.
  • Claude Sonnet 4.5 y Claude Sonnet 4.6 muestran una alta alineación con los evaluadores humanos (~86%).
  • GPT-5.2 muestra una alineación muy baja (~36%), lo que sugiere que sus criterios de evaluación difieren sustancialmente de los humanos.
• Conclusión: La selección del modelo evaluador no es trivial y puede alterar los resultados reportados en más de 30 puntos porcentuales en ciertos casos.

6. Significado e Impacto

Vibe Code Bench cambia el paradigma de evaluación de la IA en ingeniería de software:

1. De "Escribir Código" a "Construir Software": Demuestra que la capacidad de generar snippets de código no equivale a la capacidad de construir sistemas complejos y funcionales.
2. Validación de la Realidad: Pone de manifiesto que, aunque los modelos son potentes, la fiabilidad para el desarrollo "cero a uno" sigue siendo baja, especialmente en escenarios con integraciones externas.
3. Importancia del Comportamiento Agente: Sugiere que la capacidad de un modelo para auto-corregirse y probar su trabajo (comportamiento agencial) es tan importante como su capacidad de generación de texto.
4. Estándar Futuro: Establece un nuevo estándar para medir el progreso real de los agentes de codificación, alejándose de los ejercicios académicos aislados hacia la evaluación de productos finales.

En resumen, el trabajo concluye que, si bien hemos avanzado, la promesa de que la IA pueda construir aplicaciones completas y fiables por sí sola aún no se ha cumplido, y el camino hacia esa meta requiere mejoras significativas en la robustez, la integración de servicios y la capacidad de auto-evaluación de los modelos.