Ingeniería con agentes con Claude Code y la CLI de Android

Hola, soy Ben, de Relaciones con Desarrolladores de Android.

Soy Steven, gerente de producto.

Hoy hablaremos sobre cómo crear apps con Claude Code y la CLI de Android de forma agéntica.

Por lo tanto, creo que es justo decir que nuestro rol como desarrolladores está cambiando un poco y que las cosas se están moviendo muy rápido, tanto que, seamos honestos, el contenido de esta charla probablemente ya esté desactualizado, especialmente si la estás viendo en línea.

Por lo tanto, adoptamos una postura proactiva con lo que escribimos y con la información que presentamos, pero las demostraciones que se ejecutan hoy se basan en la realidad, por lo que deberían ser confiables ahora.

Por otro lado, usamos Claude Code para esta charla, pero la información es independiente del agente.

Es más bien una mentalidad, por lo que debería aplicarse a lo que prefieras usar cuando compiles tus apps.

Por lo tanto, queremos que comiences a pensar en un mundo en el que administres equipos de agentes autónomos y cómo los preparas para el éxito.

Cuando no logran implementar una función o algo similar, en lugar de simplemente rendirse y decir: "Oh, la IA aún no puede hacer esto", debemos dar un paso atrás y pensar qué información faltaba, y tratarlo como tratamos los errores hoy en día.

Si leíste algo de los equipos que crean todos estos arneses de agentes, Claude Code, Codex y Antigravity, verás que así es como sus equipos desarrollan esos arneses y, si los tomamos como un vistazo al futuro, probablemente hacia allí nos dirigimos todos.

Por lo tanto, probablemente nunca haya sido un momento más emocionante para ser creador, para ser desarrollador de Android, pero si eres como yo, puede que te resulte difícil saber exactamente en qué enfocarte.

Y nosotros, como desarrolladores, necesitamos herramientas y flujos de trabajo que realmente escalen con inteligencia, para que, a medida que un nuevo modelo amplíe la frontera, todo nuestro arduo trabajo no se vuelva redundante.

Queremos que cada mejora del modelo genere flujos de trabajo más inteligentes para nuestros agentes, lo que, en última instancia, se traduce en mejores resultados para nuestros usuarios.

Hoy, abordaremos cuatro temas.

Primero, explicaremos por qué es tan importante configurar tus agentes en entornos para que tengan éxito.

Luego, proporcionaremos una descripción general sobre el contexto y la mejor manera de administrarlo.

Luego, hablaremos sobre algunas de las mejores herramientas que tenemos disponibles para los desarrolladores de Android que trabajan con agentes y, por último, explicaremos por qué es conveniente agregar bucles a tus flujos de trabajo de agentes.

Muy bien, comencemos.

Por lo tanto, el entorno.

Pero ¿qué significa eso realmente?

Bueno, como decía, intentamos crear un espacio en el que nuestro agente pueda tener éxito, y pueda tenerlo sin que tengas que sentarte allí y, constantemente, volver a darle instrucciones y volver a encarrilarlo, porque cuando haces eso, es cuando desbloqueas la capacidad de ejecutar agentes paralelos, y ahí es donde, por ejemplo, se obtienen las ganancias reales de productividad, cuando puedes tener estos equipos de agentes haciendo todo tu trabajo por ti.

Pero eso va mucho más allá de tener acceso al código.

Necesitan acceder a documentación precisa, que incluye las especificaciones del proyecto y las reglas para trabajar en él.

Esa es la más obvia.

Otras cosas que la gente está haciendo es conectar su agente a su espacio de chat de equipo, no solo para iniciar agentes, sino para proporcionar el contexto de cómo se tomaron las decisiones que llevaron a la función que se les asignó, porque como desarrollador, ese es el tipo de información subconsciente que usas cuando resuelves problemas, por lo que también puede ser útil para tu agente.

También como el historial de decisiones anteriores y las solicitudes de extracción.

Deberían poder ver los comentarios que recibes en tus solicitudes de extracción, el tipo de cosas por las que se les envía un ping, cosas así, y luego verás que pueden trabajar y solucionar eso.

Además, no esperarías poder escribir código de Android sin acceso a un dispositivo o un emulador, por lo que tampoco deberías esperar que tu agente pueda hacerlo.

Sé que parecen increíbles y que pueden hacer cualquier cosa, pero un emulador es de gran ayuda.

Lo mismo ocurre con los generadores de perfiles.

Si quieres que trabajen en el rendimiento, deben poder generar perfiles, lo que implica tener acceso a un dispositivo real.

Y, idealmente, tu agente también debería poder comunicarse con cualquier servicio de backend que use tu app.

Y ahí es donde entra en juego la CLI de Android.

Si no escuchaste hablar de ella, también se mencionó en la charla Novedades de las herramientas, pero la CLI de Android es nuestra nueva CLI para interactuar con varias herramientas de Android.

No es un producto de IA en sí, sino una CLI, una interfaz de línea de comandos.

Por lo tanto, te brinda acceso a elementos como el SDK Manager de Android, la capacidad de iniciar emuladores y muchas otras cosas.

También se conecta a herramientas y backends como Crashlytics.

Funciona con cualquier agente que uses, solo se encuentra en tu espacio de shell.

Entonces, sí.

Puedes instalarlo en este vínculo, pero creo que es más fácil si lo vemos en acción.

Bien.

Por lo tanto, en lugar de simplemente explicar por qué es tan importante preparar a tus agentes para el éxito, queríamos aplicar este principio a una aplicación de producción que creamos llamada Sideline.

Y Sideline es una aplicación para Android para jugadores de tenis que les proporciona comentarios en tiempo real sobre la ubicación de la pelota, del jugador y de la cancha.

Proporciona comentarios de entrenamiento sin conexión a través de la reproducción de video y datos de actividad física, como la velocidad máxima, la distancia recorrida y los intercambios más largos.

Todo esto se logra con modelos personalizados de TF Lite que se ejecutan directamente en el dispositivo Android.

En primer lugar, quiero decir que, obviamente, no podemos resolver problemas que no sabemos que existen.

Por lo tanto, con la CLI de Android, agregamos Firebase Crashlytics a nuestro entorno de desarrollador, lo que nos permitió encontrar algunos problemas que ni siquiera sabíamos que estaban ocurriendo.

El primero fue que se produjo un error de aplicación no responde, o ANR, en un dispositivo Pixel 11 Pro Fold, que no se reprodujo en el emulador.

Por suerte, la CLI de Android admite la transmisión de dispositivos Android.

Y lo que hizo el agente una vez que le dijimos que solucionara este problema fue crear una conexión con el dispositivo en el que se estaba produciendo el ANR, lo que me resultó especialmente útil porque, en ese momento, ni siquiera tenía un Pixel 11 Pro Fold para validar la corrección.

Por lo tanto, al darle al agente la capacidad de acceder al dispositivo que necesitaba para validar la corrección, pudimos, en última instancia, expandir el conjunto de capacidades de lo que es posible.

Para ahorrar tiempo, ejecuté todos los experimentos con anticipación y los resumí aquí.

Y sin entrar en demasiados detalles, el problema que teníamos era una llamada de afinidad relacionada con Android 17.

Fue una corrección rápida de dos líneas, que me pareció bien.

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

Por lo tanto, creé la solicitud de extracción, la combiné y la actualicé con una nueva compilación enviada a Play.

Por lo tanto, si no hubiéramos configurado el entorno de programación con las capacidades necesarias para tener éxito, no habríamos podido identificar un problema real ni validar una solución.

Por lo tanto, con las compilaciones 1.0, puedes ver que se resolvió el problema.

Sin embargo, surgieron problemas nuevos que abordaremos más adelante.

Bien.

A continuación, el contexto.

Hace aproximadamente un año y medio o dos, que no es mucho tiempo, pero en el espacio de la IA es una eternidad, existía esta carrera por tener ventanas de contexto cada vez más grandes, y la teoría era que, cuanto más pudiéramos darle al modelo, mejores resultados obtendríamos, y hacíamos cosas locas, como intentar incluir todo developer.android.com en la instrucción, pero no funcionaba.

Sin embargo, aunque las ventanas de contexto se han estabilizado en gran medida, las capacidades de los modelos siguen aumentando.

Así es Android Bench 1.0.

Android Bench es nuestro comparador que evalúa la capacidad de la IA para escribir código de Android.

Las tareas que se incluyen son realistas.

Son el tipo de cosas en las que trabajas, y podemos ver que las ventanas de contexto se estabilizaron en esa marca de 1 millón, pero la capacidad del modelo sigue aumentando.

Pero el contexto sigue siendo un presupuesto fijo, y quieres ahorrarlo para lo que es importante.

No querrás incluir elementos que no ayuden a resolver el problema exacto en el que estás trabajando.

Y muchos de los arneses de agentes no te exponen esa ventana de contexto completa de 1 millón porque consideran que no tiene sentido.

Los resultados solo empeoran cuando lo hacen.

De hecho, hay un punto óptimo, que cambia según el modelo, pero si puedes mantener tus conversaciones en alrededor de 150,000 tokens, ahí es donde obtienes todo el poder del modelo sin que se pierda el contexto.

Pero el contexto no es solo lo que escribes.

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

En realidad, hay mucho que sucede tras bambalinas y que no ves.

Se compone de varias partes.

La primera es la instrucción del sistema.

La instrucción del sistema la proporciona tu agente.

Es como una instrucción que le indica cómo trabajar con este agente, el tipo de comportamiento que debe tener.

Pero también información del espacio de trabajo, como tu directorio de trabajo actual, qué SDK tienes, las habilidades instaladas (hablaremos de eso en un segundo) y las herramientas de MCP, así como cualquier herramienta que proporcione tu agente.

El modelo necesita saber que puede llamarlas, por lo que eso ocupa contexto.

Pero el más importante es que el historial completo de mensajes y llamadas a herramientas se envía con cada instrucción, cada mensaje nuevo que envías, con tu agente.

Y eso puede acumularse, especialmente con Gradle.

Como todos sabemos, los registros de Gradle son muy largos, muy detallados.

La mayoría de esos datos no son obligatorios.

Así que aquí tienes un consejo rápido para tener en cuenta.

Puedes ejecutar Gradle en modo silencioso.

./gradlew assembleDebug --quiet

O los arneses de agentes más grandes truncan esto por ti.

Por lo tanto, Claude Code y Android Studio no envían el registro completo de Gradle.

Pero si usas uno de los agentes mínimos, como su filosofía es enviar todo al modelo, el modelo sabe más, por lo que mini-SWE-agent envía ese registro completo de Gradle, y eso puede volverse muy costoso muy rápido.

Pero ¿cómo nos mantenemos dentro de esta ventana mágica de 150,000?

La clave es usar un flujo de trabajo.

Y hay muchísimos flujos de trabajo.

El que más me gusta es de un hombre llamado Matt Pocock, que tiene una serie de habilidades para ayudarte a gestionar estas sesiones.

Por lo tanto, comienza con la habilidad llamada "grill-me".

Lo que haces es ejecutar esta habilidad cuando comienzas un proyecto completo o solo una función nueva dentro del proyecto, y hace que tu agente te haga una serie de preguntas.

Por lo tanto, podrías decir "grill-me.

Quiero compilar, no sé, un nuevo administrador de alarmas de tiempo en mi app".

Y lo que hará es empezar a hacerte preguntas sobre en qué deberíamos implementarlo, a dónde pertenece.

Y elimina toda la ambigüedad del problema y de tu cabeza para convertirlo en un problema.

Luego, ejecutamos la siguiente habilidad, que escribe un documento de especificaciones grande.

Hay otra habilidad que luego lo divide en problemas, y los archivamos en el administrador de problemas que prefieras usar.

Y, luego, la idea es que cada uno de esos problemas debería encajar aproximadamente en esa ventana de 150,000.

Y, luego, eliges un problema, ya sea que estés trabajando en la terminal o en tu IDE, lo que prefieras, compilas, verificas el bucle, borramos el contexto al final, no hay más historial de conversaciones y nos quedamos dentro de la ventana.

Bien.

A continuación, hablemos de AGENTS.md.

En AGENTS.md, puedes proporcionar información adicional para tu agente que se aplique a cualquier problema en el que esté trabajando en este proyecto o en todo tu espacio de trabajo, si así lo deseas.

Sin embargo, como se proporciona en cada instrucción, es importante que solo se incluyan cosas que se apliquen idealmente todo el tiempo.

Por lo tanto, el tipo de cosas que funcionan son las reglas de arquitectura y de módulos.

Son el tipo de cosas que tu agente no podría haber sabido, especialmente si trabajas en una app de código cerrado.

Pero es muy importante comprenderlas para ahorrar tiempo al principio y saber a dónde pertenece esta función.

Por lo tanto, puedes colocar elementos como componentes de la IU en el módulo del sistema de diseño, o bien otra cosa que funciona muy bien son los errores comunes de revisión de código o simplemente cosas comunes que estás detectando y que tienes que escribir todo el tiempo.

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

Por ejemplo, en este proyecto, preferimos usar kotlinx.datetime, cosas así.

Y realmente quería proporcionar una especie de prácticas recomendadas que siempre se apliquen, pero la realidad es que esto cambia con cada lanzamiento de modelo.

Los diferentes modelos tienen comportamientos distintos cuando se trata de contexto adicional.

Por ejemplo, en los días de Opus 4.6, era muy común tener letras mayúsculas grandes que decían: "Nunca hagas esto".

Y, luego, cuando salió Opus 5, Anthropic publicó una declaración que decía: "En realidad, las mayúsculas ya no funcionan tan bien.

Solo usa minúsculas".

A esto me refiero: tienes que estar al tanto de todo.

Sin embargo, hay algunas cosas que se mantienen bastante universales, como que sea breve.

Por lo tanto, mantén la cantidad por debajo de las 250 líneas.

Y este, el siguiente, es un poco polarizante, porque sé que a mucha gente le encanta hacer esto, pero en febrero de este año se publicó un estudio que demostró que, si dejas que tu agente modifique su propio AGENTS.md, el rendimiento disminuye entre un 2% y un 3%, lo que, ya sabes, no es tan grave.

Pero lo importante es que aumentó los costos en un 20%.

Por lo tanto, perdimos un poco de rendimiento y aumentamos nuestros costos, todo por permitir que el agente escribiera su propio AGENTS.md.

Una forma de evitar esto que he visto es que puedes hacer que tu agente escriba una retrospectiva al final de cada solicitud de extracción y, luego, como equipo, en sus retrospectivas, pueden leerlas todas juntas y decidir qué modificaciones van a realizar, porque este archivo se está convirtiendo en la pieza clave de la infraestructura crítica del equipo si trabajas en equipos grandes con agentes.

Así que, de forma rápida, aquí está el AGENTS.md para la aplicación Sideline que compilamos.

Hay dos cosas que quiero destacar aquí.

La primera es que tener una arquitectura claramente definida te ahorrará tokens y longitud de contexto.

Básicamente, permite que tu agente evite tener que buscar constantemente en más partes de tu base de código y hacer cada vez más inferencias.

Proporciona un lineamiento muy bien definido para que lo siga.

Y el segundo punto que quería destacar es, en particular, para las aplicaciones de código cerrado.

Obviamente, si tu código es cerrado, ninguno de los agentes ni los LLM se han podido entrenar con tu base de código.

Por lo tanto, en estos casos, es particularmente importante dedicar ese tiempo adicional, dedicar esos ciclos a limpiar, revisar, perfeccionar y mejorar constantemente tu AGENTS.md, porque te beneficiará a largo plazo.

Entonces, si no deberíamos poner todo en AGENTS.md, ¿cómo se supone que cambiemos el comportamiento del agente o del modelo?

Bueno, el primero son los hooks, y los hooks son realmente buenos para el tipo de cosas que la gente pone en AGENTS.md, como, por ejemplo, ejecutar siempre el linter cuando terminas de escribir.

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

Eso puede ser un gancho.

Un hook es un evento que expone tu agente y al que te puedes suscribir. Hay hooks para casi todo lo que se te ocurra, pero los principales son iniciar sesión, detener sesión, leer archivos y escribir archivos.

Por lo tanto, en lugar de escribir en la parte inferior de tu AGENTS.md, "siempre ejecuta el linter" o "siempre ejecuta mi paquete de pruebas antes de decir que terminaste", tienes un hook de detención que puede ejecutar una secuencia de comandos determinista y ayuda a controlar la ligera aleatoriedad de la IA.

Otro caso es si tienes archivos que realmente no quieres que tu agente pueda leer o escribir, como un archivo de secretos que no quieres que se envíe a un servidor, o AGENTS.md, no quieres que tu agente pueda escribir en él, puedes tener un hook para eso.

Por lo tanto, tienes un hook de lectura o escritura, se te pasa el archivo que se intenta editar y puedes devolver un mensaje que diga "No, no puedes hacer eso".

Es solo una forma de agregar determinismo.

El siguiente aspecto son las habilidades.

Y, de hecho, hay habilidades para convertir tus AGENTS.md en ganchos ahora.

Ese es otro tema.

Sin embargo, las habilidades son la forma de agregar contexto solo cuando es pertinente.

Por lo tanto, AGENTS.md es para las cosas que siempre son relevantes.

Las habilidades son para cosas que son relevantes en ciertas situaciones, principalmente la documentación.

Por lo tanto, las habilidades se componen de tres partes: tienen un nombre, una descripción (esta es la parte importante, ya que la descripción está limitada a 1,024 caracteres) y un cuerpo.

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

Y el cuerpo puede ser enorme, incluso puede incluir otras secuencias de comandos, lo que es bastante común.

Puedes hacer muchas cosas con las habilidades.

Veamos un ejemplo.

Esta es la descripción de la CLI de Android.

No tienes que leer todo eso.

Solo debes saber que es como una breve descripción que indica cuándo es relevante la CLI de Android.

Y este es el cuerpo.

Es enorme, por lo que no queremos cargar todo esto todo el tiempo, ¿verdad?

Solo queremos cargar esto cuando intentamos usar la CLI de Android, y eso es lo que nos permite hacer una habilidad.

Sin embargo, es importante que seas selectivo con las habilidades que instalas.

No queremos instalar a ciegas esos repositorios que vemos en línea que son cientos de habilidades de ingeniería de agentes.

En primer lugar, eso representa un riesgo de seguridad enorme.

No tienes idea de lo que hay en esas habilidades, podría estar diciéndole a tu agente que haga cualquier cosa.

Y tenemos un conjunto de habilidades de Android, prometo que las examinamos, no dicen eso.

En segundo lugar, 100 descripciones de 1,000 caracteres son 100,000 caracteres que acabas de agregar antes de comenzar a programar.

Por lo tanto, ya estás cerca de esa ventana.

Por eso, con las habilidades de Android, recomendamos instalar la habilidad base de la CLI de Android para todo, y, desde allí, la CLI de Android puede buscar las habilidades disponibles e instalar las que tengan sentido para tu app.

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

O, si ya tienes una idea, es bueno saber qué habilidades están disponibles. Puedes agregar manualmente las que tengan sentido para tu proyecto, como las habilidades de Compose o las de borde a borde, que son bastante universales.

Por supuesto, hay habilidades para auditar habilidades.

Por lo tanto, existe /skill-doctor en Claude Code, que analizará y te dirá qué habilidades estás incluyendo que nunca se activan, por lo que solo estás desperdiciando esa descripción de mil caracteres.

Y si no estás en Claude Code, casi todos los arneses de agentes tienen algún tipo de pantalla de estadísticas o de auditoría para hacer lo mismo.

Así que, de nuevo, Android CLI, ese es el vínculo.

Pero tiene un comando de lista de habilidades y, luego, supongamos que tienes Navigation 3 en tu proyecto.

android skills list
android skills add navigation-3

Navigation 3 es una biblioteca bastante nueva, por lo que aún no se ha realizado mucho entrenamiento con ella. Puedes agregar la habilidad de Navigation 3.

A menudo, oh, lo siento.

El siguiente es MCP.

Sin embargo, a menudo nos preguntan por qué hicimos que la CLI de Android fuera una CLI y no un servidor de MCP.

Bueno, hemos estado creando estas cosas de la CLI mucho antes de que existiera la IA, mucho antes de que existiera el mouse, estábamos creando CLI, por lo que son rápidas, se pueden componer y, como se ejecutan localmente en tu sesión de shell, su ejecución es prácticamente gratuita.

Además, las comparativas como Terminal Bench se han convertido en las más importantes en lo que respecta a la ingeniería de software, por lo que los creadores de modelos han estado escalando de forma agresiva en contra del uso de terminales, por lo que son muy buenos usando las CLI en la actualidad.

Pero eso no significa que el MCP no tenga lugar.

Los servidores de MCP son excelentes para los servicios externos que ya usas, en especial si ya alojan un servicio de MCP.

Puedes conectarte directamente a él, y es una forma sin instalación de obtener contexto adicional para tu agente.

Plataformas como GitHub, Figma y Slack ahora exponen servidores de MCP.

Y, luego, las cosas que siempre ejecutamos en la shell pueden permanecer en la shell, por lo que los comandos de Android a través de la CLI de Android, pero también Perfetto y Gradle, tienen sentido tenerlos de forma local, donde tienen acceso a todo lo que usas en tu desarrollo.

Y solía trabajar en el rendimiento.

Siempre decía que Perfetto es la única herramienta que necesitas para resolver cualquier problema de rendimiento.

Pero la curva de aprendizaje era muy pronunciada, como acabamos de ver en la última charla de Rahul.

Veamos cómo la IA puede ayudar a mejorar el rendimiento.

Gracias, Ben.

Por lo tanto, para que nuestra aplicación, Sideline, funcione, debe ejecutarse a 30 fotogramas por segundo y en tiempo real.

Como puedes ver aquí en este Pixel 10 Pro Fold, solo alcanzamos entre 20 y 22 fotogramas por segundo.

Estos fotogramas descartados van a ser un problema, porque significa que la aplicación no va a funcionar como se anuncia, por lo que realmente vamos a tener que solucionar esto.

Con la Android CLI, tenemos los comandos del generador de perfiles de Android.

Cuando lo agregamos a nuestro agente de programación y le indicamos que cumpla con este requisito de 30 fotogramas por segundo, ocurren dos cosas interesantes.

La primera es que encuentra una solución con el comando del generador de perfiles de Android.

Registró seguimientos del sistema en el dispositivo Pixel 10 Pro Fold conectado y descubrió que sus subprocesos de IA se ejecutaban en los núcleos más lentos del dispositivo.

Y la segunda es que usó la búsqueda de documentos de Android, curiosamente, sin que se lo pidiéramos explícitamente, y extrajo la guía oficial de la API de Performance Hint.

Lo que el agente aprendió a hacer fue optimizar la programación del sistema y, de esa manera, pudo cumplir con los requisitos de 30 fotogramas por segundo.

Básicamente, lo que sucedió es que la corrección siguió la orientación.

Entonces, con Android CLI, la clave es que, ya sabes, al conectarlo con tu agente, te ayuda a encontrar la herramienta adecuada, incluso si no estás familiarizado con esa herramienta, para cualquier trabajo que necesites realizar.

Entonces, una vez que lo ejecutamos, puedes ver que Sideline cumple con el requisito de 30 fotogramas por segundo que tienen los usuarios y que ahora funciona en un Pixel 10 Pro Fold.

Bien.

Ahora, uniremos todo con bucles.

Seguro que todos lo hemos hecho: le pides a tu agente que implemente un gran cambio, y vuelve y dice que ya está hecho.

Y si la instalas y haces clic manualmente en la app y escribes los errores, eso es lo que debemos dejar de hacer.

Debemos dejar de ser los evaluadores de control de calidad de nuestro agente y definir de antemano qué consideramos que está listo.

Este es un ejemplo.

Queremos migrar todo el proyecto a Nav3 y, luego, el agente se va, tarda un poco, pero vuelve con confianza y dice: "Migración completada.

Soy el mejor".

Pero, por supuesto, rotas el teléfono, la app falla, se pierde todas las transiciones de diapositivas y no limpia su archivo de Gradle.

Esto es similar al mundo en el que nos encontramos ahora.

Lo ideal sería que no tuviéramos que hacer esto, pero esta es la realidad actual.

Por lo tanto, deberíamos haber definido todo eso de antemano primero sobre lo que esperamos, y eso habría permitido que el agente se repitiera hasta que cumpliera con todos esos criterios.

En eso consiste un bucle de verificación.

De hecho, tenemos datos muy sólidos sobre la eficacia de este enfoque.

Este es Android Bench 2.0, la nueva versión de nuestro benchmark de IA que mencioné al principio de la charla.

Actualmente, las tasas de aprobación son de alrededor del 40%.

Estas tareas son muy difíciles, grandes y realistas, pero una de ellas es Nav2 a Nav3, el tipo de cosas que estás haciendo en tus proyectos en este momento.

Y si tomamos Fable 5.1, su tasa de aprobación es del 22%, que es lo que obtiene solo con la configuración de instrucciones naturales, como "migrar Nav2 a Nav3".

Pero si le damos un paquete de pruebas con errores por adelantado, es decir, no le damos las respuestas ni le decimos cómo migrar a Nav3, sino que solo le damos un paquete de pruebas que ya está fallando y que se aprobará cuando se completen todas esas cosas, sus tasas de aprobación en toda la comparativa aumentan al 90%.

Esto nos demuestra que estos modelos ahora son capaces de implementar casi cualquier tarea de Android que se nos ocurra, solo que no siempre saben qué significa "completado".

Por lo tanto, no tienes que escribir un paquete de pruebas fallidas completo por adelantado.

Los bucles de verificación pueden ser tan simples como agregar instrucciones.

Por ejemplo, si estás trabajando en la IU, puedes pedirle que renderice la vista previa de Compose y se asegure de que coincida con la especificación de Figma, y que te muestre los resultados.

Parece que funciona muy bien cuando le pides que te muestre los resultados y que demuestre que se completó la tarea, en lugar de simplemente aceptar la respuesta de texto "Ya terminé".

Si estás trabajando en la lógica empresarial, puedes pedirle que ejecute tus pruebas de unidades o, como vimos al principio, si estás trabajando en la corrección de una falla, puedes pedirle que valide que la falla se haya corregido en el dispositivo real en el que ocurrió a través del laboratorio de pruebas remoto.

De hecho, Claude Code tiene una habilidad integrada para ayudarte a crear bucles de verificación ahora.

Así que, definitivamente, échale un vistazo.

Y si trabajas en Android Studio con tu propio agente, Android Studio expone un montón de herramientas con las que puedes crear bucles según lo que estés haciendo.

Por lo tanto, al igual que con el linter, puedes indicarle que no se detenga hasta que se corrijan todos los errores de lint, o bien, lo que realmente me gusta, puedes pedirle que ejecute tus recorridos y se asegure de que sigan funcionando.

O si escribiste un recorrido, porque los recorridos son bastante fáciles de escribir, solo son instrucciones sobre la función en la que estás trabajando, puedes decirle que ejecute ese recorrido y se asegure de que se apruebe antes de declararse listo.

Sin embargo, los recorridos tardan un tiempo en ejecutarse.

Por lo tanto, lo que también puedes hacer es clasificar los niveles de tu bucle de verificación.

Por lo tanto, podemos pedirle que primero se asegure de que las pruebas de unidades y las vistas previas de Compose se rendericen correctamente.

Y, luego, cuando se apruebe, ejecuta nuestras pruebas conectadas y Android Journeys, y solo cuando se apruebe, ejecuta el lab de pruebas de dispositivos remotos completo, el paquete de pruebas completo que tardará horas.

Si proporcionas esa información adicional, descubrimos que se repite por nivel en lugar de intentar realizar cada paso en cada ejecución.

Porque los modelos son muy seguros.

Por lo tanto, siempre piensan que están completos y que van a pasar todas las pruebas en el primer intento.

Veamos cómo se hace en Sideline.

Apliquemos esta idea a nuestra aplicación Sideline y agreguemos una nueva función, específicamente para los lentes de RE, que estarán disponibles próximamente.

Y, como aún no tenemos hardware, por supuesto, usaremos el emulador de XR y le indicaremos a nuestro agente de programación que extienda Sideline para el nuevo factor de forma.

Cuando lo hagamos, les pediremos específicamente a nuestros agentes que recorran las pruebas de JVM, las pruebas de vista previa de Compose y las pruebas de emulador en ese orden.

Y cada bucle se basa en el anterior.

Cuando hacemos esto, lo primero que notamos es que, entre el bucle uno y el dos, se usan las pruebas de JVM para definir los seis estados de la vista previa de Compose.

Por supuesto, no se llamó a ningún emulador, por lo que se ejecuta muy rápido.

De manera similar, entre el bucle dos y el tres, se detectan y corrigen problemas como las cadenas largas incluso antes de que se ejecute el emulador.

Por último, una vez que se ejecuta el bucle del emulador, este encuentra errores adicionales que la prueba de JVM y las vistas previas de Compose no pudieron corregir.

Pero, en esencia, con cada bucle, reforzamos aún más nuestra aplicación, y queremos ejecutar primero los bucles más rápidos, pero menos potentes, seguidos de los más lentos, pero más potentes.

Y este es el resultado.

Muestra que los lentes ahora indican el tipo de golpe y la velocidad de la pelota que sale de la raqueta, para que puedas jugar al tenis y obtener comentarios sobre tu juego en tiempo real sin perder de vista la pelota.

Ah, y antes mencioné que volveríamos a los dos problemas de Crashlytics que habían surgido.

Como ya pudimos validar que ese enfoque funcionó, podemos usar el comando /schedule en Claude Code para que se ejecute en bucle, y podemos establecer la cadencia que queramos, de modo que ahora tenemos una aplicación que se corrige automáticamente, soluciona todos los errores y valida que se hayan corregido, y los envía como solicitudes de extracción a nuestros ingenieros para que los revisen y los combinen.

Genial.

Eso es todo por hoy.

Si hay algo que debes recordar, es que debes empezar a pensar en este mundo en el que estamos creando un entorno para que nuestros agentes tengan éxito y tratarlo como tratamos el desarrollo de software y los errores en la actualidad.

Así es como desbloqueamos los agentes paralelos.

Encontrarás muchos consejos sobre este tema en línea, y muchos de ellos se contradicen entre sí.

Y es solo la realidad de este entorno que cambia rápidamente.

Por lo tanto, lo mejor que puedes hacer es escribir tus propias evaluaciones para tu proyecto.

Y, luego, cuando surja un nuevo consejo o un nuevo modelo, podrás medirlo y ver si te ayuda.

Y, por supuesto, hay una habilidad para todo.

Hay una habilidad para ayudarte a crear evaluaciones en Claude Code.

/claude-api build-eval

Te recomiendo que lo revises.

Hoy hablé de Android Bench.

Android Bench es nuestra evaluación.

Es la forma en que medimos para asegurarnos de que las cosas mejoren.

Si quieres conocer las lecciones que aprendimos durante el proceso para no cometer los mismos errores, consulta la charla sobre Android Bench.

También hay dos paneles.

Hay uno en EE.UU. y otro en Londres.

Ambos se publicarán en línea y hablarán sobre este tipo de concepto en la práctica en la comunidad.

Por lo tanto, tenemos miembros de la comunidad de desarrolladores de Android que se unen al panel para hablar sobre cómo están poniendo esto en práctica en sus trabajos.

También queremos recibir tus comentarios.

Queremos saber si lo que estamos creando realmente te ayuda.

Por lo tanto, completa la encuesta.

Dejaré eso en pantalla.

Y, sí.

Gracias por escuchar.

Gracias.