ForgeNEX

Google abre Android a agentes de IA de terceros: qué cambia

Google da acceso a Claude Code, Codex y otros agentes a las herramientas de Android: dispositivos, perfiles y fallos en producción. Claves para tu equipo.

5 min de lectura

En este artículo

Google ha movido ficha en el terreno del desarrollo móvil y lo ha hecho, sorprendentemente, abriendo puertas en lugar de cerrarlas. En el Android Dev Summit celebrado esta semana, la compañía ha anunciado que los agentes de programación de terceros —como Claude Code de Anthropic o Codex de OpenAI— podrán acceder de forma profunda a su cadena de herramientas de Android. Hablamos de dispositivos reales, perfiladores de rendimiento y, lo más relevante para cualquier equipo que mantenga una app en producción, informes de fallos en producción.

La noticia tiene miga porque Google no ha aprovechado la ocasión para empujar a los desarrolladores hacia su propio modelo Gemini. Matthew McCullough, vicepresidente de producto para Android, ha subrayado la idea de dar libertad a los desarrolladores para elegir sus propios modelos y agentes. Adarsh Fernando, responsable de herramientas para desarrolladores, lo resume como dar a los equipos y a sus agentes “las herramientas y el conocimiento para construir apps Android de alta calidad más rápido”.

Detalle ilustrativo: Google just handed its rivals the keys to Android

Qué significa 'trae tu propio agente'

La función Bring Your Own Agent, que ahora sale como estable en la versión de Android Studio Rabbit 2, soporta más de 40 agentes de programación que hablan el protocolo abierto Agent Client Protocol. Entre ellos están Claude Agent de Anthropic, Codex de OpenAI y Antigravity, el propio agente de Google. Un desarrollador puede instalar varios y cambiar entre ellos sin salir del IDE.

El detalle técnico que importa: los agentes conectados heredan la lectura que el propio IDE hace del proyecto —su estructura, configuración de compilación, símbolos y herramientas como Compose Preview, el emulador o Logcat—. Es decir, no tienen que reconstruir ese contexto a base de búsquedas en el código y conjeturas en la terminal. Ese ahorro de contexto es, en la práctica, lo que separa un agente útil de uno que da vueltas.

Junto a esto llega Change Review, una función que revisa los cambios pendientes de un agente en busca de problemas habituales y puede guiar al desarrollador por un conjunto amplio de modificaciones antes de aplicar nada. Google también extiende el alcance fuera del IDE con plugins oficiales de Android CLI para Claude Code y Codex, que cubren creación de proyectos, gestión de emuladores, inspección de UI y documentación de Android.

Previews desde la terminal y dispositivos remotos

Otro de los anuncios es el comando android preview, que permite a los agentes renderizar vistas previas de Jetpack Compose directamente en la terminal, sin lanzar el IDE ni el emulador. Google afirma que los agentes que lo usan completaron tareas de UI un 77% más rápido y consumieron hasta tres veces menos tokens, aunque comparte pocos detalles sobre cómo midió esos resultados. La CLI añade además android device remote, que da a los agentes acceso a dispositivos físicos del laboratorio de Google para pruebas.

En el terreno de la depuración, Google pone a disposición de los agentes más vías para investigar problemas una vez construida la app: rendimiento, fallos en producción y fugas de memoria. En una demostración, Claude Code trabajó con LeakCanary, la biblioteca open source de detección de fugas, para revisar rutas críticas de usuario con una sola instrucción del desarrollador. El agente ejecutó las rutas en varios dispositivos en paralelo, analizó volcados de memoria a través de la integración de la CLI y rastreó las fugas hasta el código culpable. Después aplicó las correcciones y repitió las pruebas para confirmar que funcionaban.

Google sostiene que estas herramientas ayudaron a modelos capaces a completar esas investigaciones casi el doble de rápido y con hasta un 25% menos de tokens. Un comando complementario, android signals, canaliza datos de Android vitals y Firebase Crashlytics al mismo flujo de terminal, lo que da a los agentes una línea directa a fallos en producción, ANRs y problemas de memoria.

El matiz que no conviene ignorar

La demostración es vistosa, pero conviene leerla con calma. La propia noticia recuerda un dato que invita a la prudencia: un escáner de Anthropic marcó unos 29.000 posibles vulnerabilidades en código open source y solo unos cientos llegaron a corregirse. Es decir, la detección autónoma de fallos puede ir por delante de la capacidad de arreglarlos. Y nada de esto retira al humano del bucle: hay quien vio a Claude Code cerrar un parche del kernel de Linux y a los revisores pillar después una condición de carrera.

Google también presenta Android Bench 2.0, un banco de pruebas para evaluar cómo se comportan modelos y agentes en tareas Android más complejas, desde construir una app a partir de maquetas hasta migrar una interfaz existente. Algunas tareas están modeladas sobre trabajo que a un ingeniero Android le llevaría varios días, y el benchmark mide además tiempo de finalización y coste.

Qué hacemos con esto en una pyme

Si tu empresa tiene una app Android propia o un equipo interno que la mantiene, este anuncio abre una puerta interesante pero exige cabeza. Nuestra recomendación, en tres pasos:

  • Evalúa antes de adoptar. Probar un agente en un proyecto pequeño y medir tiempo y coste reales es más sensato que lanzarse a integrarlo en el flujo principal. Los porcentajes que publica Google son de su propio laboratorio y con sus propias métricas.
  • Mantén la revisión humana. Change Review y las pruebas automáticas ayudan, pero el criterio de un desarrollador sigue siendo el filtro final. Como vimos con el episodio del kernel, un agente puede acertar el parche y fallar el contexto.
  • Vigila el gasto en tokens. Ya lo comentamos al hablar de cómo Claude Code dispara el gasto enterprise: el ahorro de tokens que promete Google solo se materializa si el agente no se pasa el día explorando sin rumbo.

Y una advertencia de seguridad que enlaza con lo que venimos viendo en el blog: cuanta más autonomía damos a un agente sobre dispositivos, perfiles y datos de producción, más importa controlar qué puede tocar y qué no. Es la misma lógica que aplicamos cuando revisamos el cortafuegos de npm de GitHub: la automatización acelera, pero los límites los pone el equipo.

En resumen: Google ha decidido que Android sea un terreno abierto para los agentes de IA, y eso es una buena noticia para la libertad de elección. La pelota está ahora en el tejado de los equipos de desarrollo, que tendrán que decidir cuánto de su flujo de trabajo dejan en manos de un agente y cuánto reservan para el criterio humano.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.

Sigue leyendo