VJOURNAL

IA • Mesa global • 01 de octubre de 2026

Android Bench 2.0 revela la distancia entre código convincente y una aplicación funcional

Los resultados Android Bench separan progreso parcial y éxito completo. Las nuevas pruebas de Google exigen leer el agente utilizado, los intervalos y el coste del conjunto antes de decidir.

Portada de VJOURNAL para «Android Bench 2.0 revela la distancia entre código convincente y una aplicación funcional»

Respuesta breve

Los resultados Android Bench separan progreso parcial y éxito completo. Las nuevas pruebas de Google exigen leer el agente utilizado, los intervalos y el coste del conjunto antes de decidir.

Corte de verificación: 4 fuentes
Google anunció la segunda versión el 17 de septiembre con tareas largas y agentes de los proveedores.
Éxito completo y porcentaje de finalización representan preguntas distintas.
Los gastos pertenecen a una ejecución completa y los intervalos solapados limitan conclusiones precisas.

Septiembre cambia la pregunta para los equipos

El anuncio de Google del 17 de septiembre lleva los resultados Android Bench hacia trabajos que afectan a una aplicación completa. Para los equipos móviles, la noticia práctica es una pregunta más exigente: ¿puede un agente terminar una migración o una función hasta obtener una aplicación utilizable? La actualización incorpora tareas prolongadas y agentes de los propios proveedores.

La diferencia aparece cuando un encargo ocupa varias sesiones. Un primer cambio convincente puede dejar una dependencia pendiente o una pantalla inutilizable. Elegir una herramienta requiere pruebas del proceso completo. Este conjunto ayuda a seleccionar candidatos para ingeniería Android; los requisitos de aceptación de cada equipo deciden después si el producto puede publicarse.

Las cifras necesitan conservar sus unidades

La metodología oficial describe treinta tareas con cinco intentos independientes por tarea. La tabla conserva las parejas de modelo y agente, los intervalos y la finalización parcial. El tablero de Google define dólares y horas como medias por ejecución completa. Son mediciones publicadas consultadas el 1 de octubre; VJOURNAL no realizó estos ensayos.

Al copiar los datos a una hoja de compra, hay que conservar esa unidad. Dividir el gasto total entre un número supuesto de tareas puede generar una estimación presupuestaria, pero no revela el precio de una migración específica. El resumen no identifica fechas exactas de ejecución ni esfuerzo de razonamiento; aquí permanecen desconocidos.

Google Android Bench 2.0, tareas prolongadas con agentes del proveedor; consulta 01-10-2026, publicación 17-09-2026. Treinta tareas, cinco ejecuciones por tarea. Coste y horas corresponden al conjunto completo. Fechas exactas y esfuerzo de razonamiento: desconocidos en el resumen.
Modelo / agenteÉxito %Intervalo de confianza %Finalización %Horas / ejecución completaUSD / ejecución completa
GPT-6 Astra / Codex28.013.3–42.082.27.9375.7
Claude Fable 5.1 / Claude Code22.710.7–36.082.422.2492.6
GPT-5.6 Sol / Codex19.37.3–32.074.38.6235.8
Claude Opus 5 / Claude Code16.75.3–29.377.827.0861.4
Gemini 3.8 Flash / Antigravity SDK8.03.3–13.347.412.134.5

El entorno del agente forma parte de la prueba

Codex, Claude Code y Antigravity SDK organizan archivos, herramientas y contexto alrededor del modelo. Sus decisiones pueden influir en lo que consigue terminar. Por tanto, el cuadro evalúa combinaciones operativas completas. No aísla la calidad de una red manteniendo constantes todos los componentes externos.

Esto resulta útil al adquirir un agente existente, pero menos concluyente al construir uno propio. Cambiar permisos, herramientas o gestión del contexto crea otro sistema. La documentación oficial de SWE-bench ofrece una referencia distinta para resolver incidencias de repositorios. Introducir sus porcentajes en esta tabla eliminaría diferencias relevantes de tareas y verificación.

Mucho progreso puede ocultar un bloqueo

Finalización y éxito deben leerse juntos. La primera reconoce trabajo útil incluso cuando falla el resultado final; el segundo informa de requisitos satisfechos. Una aplicación casi completa puede necesitar reparación especializada antes de publicarse. Conviene identificar el requisito pendiente y comprobar si su arreglo es previsible.

Google incorpora verificación durante la ejecución y comprobación visual, lo que permite evaluar interfaces además de estructura de código. Los intervalos de varias combinaciones se solapan. Ese solapamiento desaconseja interpretar el orden visible como una medida exacta de lo que ocurrirá en cualquier repositorio empresarial nuevo.

La compra debe terminar en una aceptación

Un piloto razonable utilizaría migraciones representativas, el mismo punto de partida y comprobaciones explícitas de compilación, funcionamiento y accesibilidad. Registraría gasto completo, tiempo transcurrido y reparación humana juntos. Es un plan de evaluación sugerido, no una prueba realizada por esta redacción ni una promesa de resultados.

La actualización de septiembre mejora la manera de examinar encargos ambiciosos. Ofrece a los responsables una razón concreta para revisar finalización, incertidumbre y categorías de fallo antes de elegir. La siguiente pregunta útil es qué combinación reduce trabajo de ingeniería revisado en sus tareas, con una aplicación funcional como condición de aceptación.

Preguntas frecuentes

¿Un 82,2% significa que la aplicación aprobó?

No. La finalización reconoce requisitos parcialmente satisfechos. Google publica aparte un 28,0% de tareas plenamente superadas para Astra con Codex en este conjunto prolongado.

¿Se cobra esa cantidad por una sola tarea?

No. El tablero identifica los dólares como coste medio de una ejecución completa del conjunto. Presentar 375,7 dólares como precio de una migración individual alteraría la unidad.

¿Son comparables directamente con SWE-bench?

Los conjuntos difieren en tareas, entornos y verificación. Cada porcentaje debe conservar su versión y agente; una cifra igual no demuestra la misma capacidad en ambos.