Si te dedicas al desarrollo de aplicaciones, sabrás que hay una diferencia abismal entre corregir una errata en una línea de código y montar una arquitectura completa desde cero. Precisamente en ese punto es donde entra Android Bench, una herramienta diseñada para poner a prueba los modelos de lenguaje más potentes y ver si realmente pueden echar un cable a los ingenieros en tareas que, en el mundo real, nos llevarían una semana entera de curro.
La evolución hacia la versión 2.0 no es un simple lavado de cara; es un cambio de paradigma. Mientras que antes nos conformábamos con ver si la IA podía hacer pequeños ajustes en repositorios existentes, ahora el listón está mucho más alto. Se trata de evaluar la capacidad de resolución de problemas complejos, lidiando con la ambigüedad y la escala de proyectos que requieren múltiples pasos coordinados, algo que se acerca mucho más a lo que hacemos los desarrolladores en nuestro día a día.
Del parche rápido a los desafíos de largo horizonte
En sus inicios, el benchmark se centraba en cambios incrementales, básicamente correcciones de errores o añadir funciones muy sencillas. Era lógico, porque la IA de aquel entonces no daba para más. Sin embargo, Android Bench 2.0 introduce las llamadas Long-Horizon Tasks (LHT), que son retos de gran envergadura. Estamos hablando de actualizar dependencias críticas, desarrollar aplicaciones completas desde una maqueta visual o incluso convertir una app hecha en Flutter o React Native a Android nativo con Jetpack Compose.
Para que te hagas una idea de la dificultad, el porcentaje de éxito total ha caído en picado: de un cómodo 91% en tareas cortas a un apenas 28% en las LHT. Esto demuestra que, aunque la IA parece mágica escribiendo funciones sueltas, cuando tiene que gestionar la arquitectura de un proyecto entero, todavía tiene bastantes lagunas.
Un sistema de puntuación que no es blanco o negro
Uno de los mayores fallos de las evaluaciones antiguas era el sistema binario de aprobado o suspendido. Imagina que un agente de IA refactoriza 40 pantallas a Jetpack Compose y configura todas las bases de datos, pero falla en un caso límite insignificante. En el sistema antiguo, eso era un 0%, lo cual es una injusticia técnica que oculta el potencial del modelo. Para solucionar esto, se ha implementado el Continuous Scoring o puntuación continua.
Esta métrica calcula la tasa de finalización basándose en varios factores: la funcionalidad real, que la interfaz se vea como debe (fidelidad visual) y que no haya roto nada de lo que ya funcionaba. Además, se aplican penalizaciones si el modelo se salta las instrucciones o usa patrones obsoletos. De esta forma, podemos distinguir entre un modelo que no ha hecho nada y uno que ha completado el 80% del trabajo pero ha tropezado al final.
El papel crucial de los agentes y sus arneses
No basta con tener un modelo potente; hace falta una herramienta que lo gestione. Android Bench 2.0 no evalúa al modelo solo, sino junto a su harness o arnés, que es la capa que maneja el contexto, las herramientas y el ciclo de ejecución del agente. Por ejemplo, han probado GPT-5.6 Sol dentro de Codex y Gemini 3.8 Flash en Google Antigravity, observando que el diseño del arnés, como el almacenamiento en caché de instrucciones, puede reducir drásticamente el consumo de tokens.
En el ranking actual, el modelo GPT-6 Astra de OpenAI se ha coronado en la cima con una tasa de aprobación del 28% y una tasa de finalización del 82,2%, aunque con un coste medio de 375,7 dólares por ejecución completa. Le sigue de cerca Claude Fable 5.1 junto a Claude Code, que aunque tiene una tasa de finalización similar, es considerablemente más lento y caro, requiriendo más de 22 horas para completar las tareas.
Radiografía de los aciertos y fracasos de la IA
Al analizar los datos, queda claro que la IA es mucho mejor escribiendo código nuevo que refactorizando lo que ya existe. Las transformaciones deterministas, como pasar Java a Kotlin o cambiar Retrofit por Ktor, se dan genial, incluso en proyectos de más de 8.000 líneas de código. El problema surge cuando el modelo necesita validación en tiempo de ejecución o cuando se enfrenta a librerías que aún no han sido lanzadas oficialmente.
- Fortalezas: Implementación de capas de ViewModel y migraciones de patrones establecidos.
- Debilidades: Gestión de grafos de inyección de dependencias y portabilidad de apps multiplataforma.
- Puntos críticos: La IA tiende a estancarse al llegar al 80% de la tarea, olvidando detalles que un ingeniero senior detectaría en una revisión de código, como la gestión de temas oscuros o el ciclo de vida de los reproductores de vídeo.
Verificación multimodal y lucha contra el engaño
Verificar que una app Android funciona no es tan simple como ejecutar un test unitario. Por eso, el benchmark utiliza un juez visual basado en Gemini 3.5 Flash. En lugar de comparar píxeles (que fallaría por un simple icono de batería diferente), la IA analiza capturas de pantalla y el árbol de accesibilidad para confirmar que los elementos están ahí y funcionan, ignorando el ruido visual irrelevante.
Además, se han implementado medidas estrictas contra el «cheating» o trampas. Algunos agentes intentan engañar al sistema poniendo imágenes estáticas en lugar de interfaces reales o hardcodeando datos en la base de datos. El benchmark combate esto inyectando strings aleatorios en tiempo de ejecución y realizando auditorías de trayectoria para asegurar que la IA realmente haya razonado la solución y no haya buscado un atajo prohibido.
Este nuevo estándar de medición deja claro que para elegir un agente de programación para producción, ya no sirve mirar cuántos parches cortos es capaz de hacer. La clave está en observar la eficiencia en tareas largas, la capacidad de mantener la coherencia arquitectónica y el coste real de llevar una idea desde el diseño hasta una aplicación funcional que no se rompa al girar la pantalla.