Google lanza Android Bench 2.0 y agentes apenas resuelven 28 % de tareas semanales

Google publica Android Bench 2.0 con tareas de varios días: el mejor modelo (GPT-6 Astra + Codex) logra 28 % de éxito. METR mide horizonte de 110 minutos. Para LatAm, la brecha entre pilotaje y despliegue sigue siendo el riesgo real.

Google lanza Android Bench 2.0 y agentes apenas resuelven 28 % de tareas semanales

Foto: John Doe

Google acaba de publicar Android Bench 2.0 y el dato duele: la mejor combinación modelo-agente —GPT-6 Astra ejecutado sobre Codex— resuelve apenas el 28 % de las tareas que a un ingeniero humano le llevan de unos días a una semana. El benchmark anterior, centrado en parches yfeatures pequeñas, mostraba un 91 % de acierto. El salto a "long-horizon tasks" (LHT) —migraciones de dependencias, refactorizaciones de 40 pantallas a Jetpack Compose, puertos multiplataforma— expone el abismo real entre lo que venden las demos y lo que aguanta producción.

La cifra no es un caso aislado. Un estudio independiente de METR, presentado en NeurIPS 2025, mide el "horizonte temporal al 50 %": el tiempo que tarda un humano en completar tareas que los agentes resuelven con la mitad de éxito. Resultado: 110 minutos para los modelos frontera actuales (o3, Claude 3.7 Sonnet). La métrica se ha duplicado cada siete meses desde 2019, pero el techo sigue en el orden de la hora y media. Extrapolando la tendencia, METR estima que dentro de cinco años los agentes automatizarían tareas de un mes humano; sin embargo, los autores advierten que en tareas "menos estructuradas y más sucias" el progreso es notablemente más lento.

El problema no es el modelo, es el arnés

Patrocinado Advertisement

Android Bench 2.0 introduce evaluación de agentes, no solo de modelos puros. Google probó GPT-5.6 Sol sobre Codex y Gemini 3.8 Flash sobre su entorno Antigravity. La diferencia de rendimiento la marca el harness: caché de prompts, ventana de herramientas compacta, gestión de contexto. Esas decisiones de ingeniería recortan tokens y coste —crítico cuando una tarea de una semana puede consumir millones de tokens—. Para un CTO en México, Colombia o Chile, la lección es operativa: no compren "modelo", compren "modelo + arnés + gobernanza de coste".

Refactorizar duele; escribir de cero, menos

Todas las familias de modelos —desde ligeras hasta frontera— comparten el mismo perfil: destacan creando código nuevo y en transformaciones deterministas (Java→Kotlin, Retrofit→Ktor, ViewModel) incluso sobre bases de 125 archivos y 8 000 líneas. Donde colapsan: refactorizaciones donde la complejidad arquitectónica supera el volumen de código, validación en tiempo de ejecución (gráficos de inyección de dependencias), cambios breaking de framework y bibliotecas no públicas. El puerto de apps multiplataforma a Android sigue sin alcanzar el 100 % en ningún modelo; el tope observado es 80 % de completion rate.

Métrica continua: el fin del binario

Google abandona el aprobado/suspenso. Ahora calcula completion rate combinando funcionalidad, fidelidad visual y ausencia de regresiones, con penalizaciones objetivas por saltarse instrucciones o romper restricciones estructurales. Un agente que refactoriza 40 pantallas y cumple el 90 % de requisitos ya no vale cero por fallar un edge case. Eso permite a los equipos de ingeniería comparar proveedores con una regla que se parece más a una pull request real.

Qué significa para un equipo latinoamericano hoy

1. Pilotos ≠ despliegue. Un 28 % de éxito en tareas semanales implica supervisión senior constante. El "vibe coding" genera deuda de comprensión: código que compila pero nadie —ni el autor humano— entiende la arquitectura resultante. 2. Coste invisible. El consumo de tokens en LHT escala de forma no lineal. La optimización del arnés (caché, tool windowing) puede recortar la factura en doble dígito; sin telemetría de coste por tarea, el experimento se vuelve incontrolable. 3. Talento júnior en riesgo. Las tareas que los modelos resuelven bien (traducción sintáctica, boilerplate) son exactamente las que antes servían de escalera de aprendizaje. Si las externalizan al agente, ¿quién aprende a leer arquitectura legacy dentro de tres años? 4. Regulación latente. Fintech y salud en Brasil, México o Colombia exigen trazabilidad y responsabilidad. Un agente con 28 % de autonomía en tareas críticas no cumple compliance sin humano en el bucle documentando cada decisión.

Hacia dónde apunta la aguja

La curva de METR sugiere que el horizonte temporal seguirá creciendo, pero Android Bench 2.0 demuestra que la fiabilidad en tareas sucias, largas y con contexto real es el nuevo cuello de botella. Google promete ampliar la matriz modelo-agente y añadir evaluación multimodal. Mientras tanto, la regla para el ejecutivo de la región es sencilla: exija completion rate en su propio código base, mida coste por ticket cerrado y no suelte el merge sin revisión de arquitectura. La automatización de una semana de trabajo humano sigue siendo, hoy, una apuesta —no una commodity.

Fuentes

  1. Google publica «Android Bench 2.0» para evaluar los límites de la IA mediante «tareas de desarrollo de una semana»
  2. Blog de desarrolladores de Android: Android Bench 2.0: Llevando la frontera más allá con ...
  3. Android Bench - Desarrolladores de Android
  4. Medición de la capacidad de la IA para completar tareas de software de larga duración
Ariel Acosta

Escrito por

Ariel Acosta

Experto en seguridad de información

Ingeniero en sistemas y gestor de servicios de TI con más de 10 años de experiencia en diseño, implementación y administración de infraestructura de red, seguridad y procesos tecnológicos. Ha desarrollado una carrera orientada a sostener operaciones críticas, optimizar entornos corporativos y traducir necesidades técnicas en soluciones funcionales para organizaciones que dependen de plataformas estables, seguras y alineadas con el negocio, con foco en eficiencia y control.