Ingénierie agentique avec Claude Code et Android CLI

Bonjour, je m'appelle Ben et je travaille dans l'équipe Android Developer Relations.

Je m'appelle Steven et je suis responsable produit.

Aujourd'hui, nous allons parler de la création d'applications avec Claude Code et la CLI Android, de manière agentique.

On peut donc dire que notre rôle de développeur évolue un peu, et que les choses évoluent à une vitesse folle. En fait, soyons honnêtes, le contenu de cette présentation est probablement déjà obsolète, surtout si vous la regardez en ligne.

Nous avons donc adopté une approche proactive dans ce que nous avons écrit et dans les informations que nous présentons. Les démos qu'ils exécutent aujourd'hui sont ancrées dans la réalité, elles devraient donc être fiables maintenant.

Autre chose : nous avons utilisé Claude Code pour cette présentation, mais les informations sont indépendantes de l'agent.

Il s'agit plutôt d'un état d'esprit, qui doit donc s'appliquer à tout ce que vous préférez utiliser lorsque vous créez vos applications.

Nous voulons donc que vous commenciez à réfléchir à un monde où vous géreriez des équipes d'agents autonomes et à la manière dont vous les prépareriez à réussir.

Quand ils n'arrivent pas à implémenter une fonctionnalité ou quelque chose du genre, au lieu de simplement abandonner et de se dire "Oh, l'IA ne peut pas encore faire ça", nous devons prendre du recul et réfléchir à l'information manquante, et traiter le problème comme nous traitons les bugs aujourd'hui.

Si vous avez lu les publications des équipes qui créent tous ces harnais d'agent (Claude Code, Codex, Antigravity), vous verrez que c'est ainsi qu'elles les développent. Si nous les considérons comme un aperçu de l'avenir, c'est probablement vers cela que nous nous dirigeons tous.

C'est donc sans doute le moment idéal pour être un créateur, un développeur Android. Mais si vous êtes comme moi, vous avez peut-être du mal à savoir exactement sur quoi vous concentrer.

En tant que développeurs, nous avons besoin d'outils et de workflows qui s'adaptent vraiment à l'intelligence, de sorte que lorsqu'un nouveau modèle repousse les limites, tout notre travail ne devienne pas redondant.

Nous voulons que chaque amélioration du modèle se traduise par des workflows plus intelligents pour nos agents, ce qui se traduit par de meilleurs résultats pour nos utilisateurs.

Nous allons aborder quatre sujets aujourd'hui.

Tout d'abord, nous vous expliquerons pourquoi il est si important de configurer vos agents dans des environnements pour qu'ils réussissent.

Nous vous présenterons ensuite le contexte et la meilleure façon de le gérer.

Nous aborderons ensuite certains des meilleurs outils disponibles pour les développeurs Android travaillant avec des agents. Enfin, nous verrons pourquoi il est intéressant d'ajouter des boucles à vos workflows agentiques.

Entrons dans le vif du sujet.

Parlons de l'environnement.

Mais qu'est-ce que cela signifie concrètement ?

Comme je le disais, nous essayons de créer un espace où notre agent peut réussir, et ce, sans que vous ayez à intervenir constamment pour le réorienter. C'est ainsi que vous pouvez exécuter des agents en parallèle, et c'est là que vous gagnez vraiment en productivité, lorsque vous pouvez avoir des équipes d'agents qui travaillent toutes pour vous.

Mais cela va bien au-delà du simple accès au code.

Ils doivent avoir accès à une documentation précise, qui inclut les spécifications du projet et les règles de travail dans ce projet.

C'est un peu l'évidence.

Certaines personnes connectent désormais leur agent à l'espace de chat de leur équipe, non seulement pour lancer des agents, mais aussi pour fournir le contexte des décisions qui ont conduit à la fonctionnalité qu'ils ont été chargés de créer. En tant que développeur, c'est le genre d'informations subconscientes que vous utilisez lorsque vous résolvez des problèmes, et cela peut donc être utile pour votre agent aussi.

comme l'historique des décisions précédentes et les demandes d'extraction.

Ils devraient pouvoir voir les commentaires que vous recevez sur vos demandes d'extraction, les types de choses pour lesquelles ils sont sollicités, etc. Vous constaterez alors qu'ils peuvent travailler et corriger ces problèmes.

De plus, vous ne vous attendriez pas à pouvoir écrire du code Android sans accès à un appareil ou à un émulateur. Vous ne devez donc pas vous attendre à ce que votre agent puisse le faire non plus.

Je sais qu'ils ont l'air incroyables et qu'ils peuvent tout faire, mais un émulateur est vraiment utile.

Il en va de même pour les profileurs.

Si vous souhaitez qu'ils travaillent sur les performances, ils doivent pouvoir effectuer un profilage, ce qui implique d'avoir accès à un appareil réel.

Idéalement, votre agent devrait également pouvoir communiquer avec tous les services de backend utilisés par votre application.

C'est là que la CLI Android entre en jeu.

Si vous n'en avez pas entendu parler, il a également été présenté dans la conférence "Nouveautés des outils". Android CLI est notre nouvelle CLI permettant d'interagir avec différents outils Android.

Il ne s'agit pas d'un produit d'IA en soi, mais d'une CLI, une interface de ligne de commande.

Il vous donne accès à des éléments tels que le SDK Manager Android, la possibilité de démarrer des émulateurs et bien d'autres choses encore.

Il se connecte également à des outils et des backends comme Crashlytics.

Il fonctionne avec n'importe quel agent que vous utilisez, il se trouve simplement dans votre espace shell.

Voilà.

Vous pouvez l'installer en cliquant sur ce lien, mais je pense qu'il est plus facile de le voir en action.

Très bien.

Plutôt que de simplement expliquer pourquoi il est si important de préparer vos agents à réussir, nous voulions vraiment appliquer ce principe à une application de production que nous avons créée, appelée Sideline.

Sideline est une application Android pour les joueurs de tennis qui leur fournit des commentaires en temps réel sur la position de la balle, du joueur et du court.

Il fournit des commentaires de coaching hors connexion via la lecture vidéo, ainsi que des données de fitness telles que la vitesse maximale, la distance parcourue et les échanges les plus longs.

Tout cela est possible grâce à des modèles TF Lite personnalisés qui s'exécutent directement sur l'appareil Android.

Tout d'abord, je tiens à préciser que nous ne pouvons évidemment pas résoudre des problèmes dont nous ignorons l'existence.

Nous avons donc ajouté Firebase Crashlytics à notre environnement de développement à l'aide de la CLI Android, ce qui nous a permis de détecter des problèmes dont nous n'avions même pas connaissance.

La première était une erreur "L'application ne répond pas" (ANR) sur un appareil Pixel 11 Pro Fold, qui ne se reproduisait pas dans l'émulateur.

Heureusement, la CLI Android est compatible avec Android Device Streaming.

Une fois que nous lui avons demandé de résoudre le problème, l'agent a créé une connexion à l'appareil sur lequel l'ANR se produisait. Cela m'a été particulièrement utile, car à l'époque, je n'avais pas de Pixel 11 Pro Fold pour valider le correctif.

En donnant à l'agent la possibilité d'accéder à l'appareil dont il avait besoin pour valider le correctif, nous avons pu élargir l'ensemble des possibilités.

Pour gagner du temps, j'ai effectué tous les tests à l'avance et je les ai résumés ici.

Sans entrer dans les détails, le problème que nous rencontrions était un appel d'affinité lié à Android 17.

Il s'agissait d'une correction rapide de deux lignes, qui me semblait correcte.

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

J'ai donc créé la demande d'extraction, je l'ai fusionnée et j'ai mis à jour l'application avec une nouvelle version envoyée à Play.

Si nous n'avions pas configuré l'environnement de codage avec les fonctionnalités nécessaires, nous n'aurions pas pu identifier un problème réel ni valider un correctif.

Comme vous pouvez le voir, le problème a été résolu dans les builds 1.0.

Cependant, de nouveaux problèmes sont apparus, et nous les aborderons plus tard.

Très bien.

Prochain sujet : le contexte.

Il y a environ un an et demi ou deux ans, ce qui n'est pas si long, mais dans le domaine de l'IA, c'est une éternité, il y avait cette course pour avoir des fenêtres de contexte de plus en plus grandes. La théorie était que plus on pouvait en donner au modèle, meilleurs seraient les résultats. On faisait des choses folles, comme essayer d'inclure l'intégralité de developer.android.com dans la requête, mais ça ne fonctionnait pas vraiment.

Mais même si les fenêtres de contexte ont largement stagné, les capacités des modèles continuent de s'améliorer.

Voici donc Android Bench 1.0.

Android Bench est notre benchmark qui évalue la capacité de l'IA à écrire du code Android.

Les tâches qu'il contient sont réalistes.

C'est le genre de choses sur lesquelles vous travaillez. On voit que les fenêtres de contexte ont atteint un plateau à un million, mais les capacités des modèles continuent de s'améliorer.

Mais le contexte reste un budget fixe, et vous voulez le réserver à ce qui est important.

Vous ne voulez pas d'éléments qui ne vous aident pas à résoudre le problème exact sur lequel vous travaillez.

De nombreux harnais d'agent ne vous exposent pas l'intégralité de cette fenêtre de contexte d'un million de jetons, car ils estiment que cela ne sert à rien.

Les résultats ne font qu'empirer lorsqu'ils font cela.

Il existe un juste milieu, qui varie selon le modèle, mais si vous parvenez à limiter vos conversations à environ 150 000 jetons, vous bénéficierez de toute la puissance du modèle sans dégradation du contexte.

Mais le contexte ne se limite pas à ce que vous saisissez.

[
  {
    "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 réalité, il se passe beaucoup de choses en coulisses que vous ne voyez pas.

Il est composé de plusieurs parties.

Le premier est l'instruction système.

L'instruction système est fournie par votre agent.

C'est un peu comme un prompt qui lui indique comment travailler avec cet agent, le type de comportement qu'il doit adopter.

Mais aussi des informations sur l'espace de travail, comme votre répertoire de travail actuel, les SDK dont vous disposez, les compétences installées (nous en reparlerons dans un instant), les outils MCP et tous les outils fournis par votre agent.

Le modèle doit savoir qu'il peut les appeler, ce qui prend de la place dans le contexte.

Mais le plus important, c'est que l'historique complet des messages et des appels d'outils est envoyé avec chaque prompt, chaque nouveau message que vous envoyez, avec votre agent.

Et cela peut vraiment s'accumuler, en particulier avec Gradle.

Comme vous le savez, les journaux Gradle sont très longs, voire très, très longs et très détaillés.

La plupart de ces informations ne sont pas obligatoires.

Voici une astuce rapide pour éviter cela.

Vous pouvez exécuter Gradle en mode silencieux.

./gradlew assembleDebug --quiet

Les harnais d'agent plus grands tronquent ces informations pour vous.

Donc, Claude Code et Android Studio, nous n'envoyons pas le journal Gradle complet.

Mais si vous utilisez l'un des agents minimaux, car leur philosophie est d'envoyer tout au modèle, le modèle sait mieux, donc mini-SWE-agent, il envoie ce journal Gradle complet, et cela peut devenir très coûteux très rapidement.

Mais comment rester dans cette limite magique de 150 000 ?

La clé est d'utiliser un workflow.

Il existe de nombreux workflows.

Celui que j'aime beaucoup est celui d'un certain Matt Pocock, qui propose une série de compétences pour vous aider à gérer ces sessions.

Il commence par la compétence "grill-me".

Vous exécutez cette compétence lorsque vous commencez un projet entier ou une nouvelle fonctionnalité dans le projet, et l'agent vous pose une série de questions.

Vous pourriez donc simplement dire "grill-me".

Je veux créer, je ne sais pas, un nouveau gestionnaire d'alarmes dans mon application."

Il vous posera alors des questions sur la façon dont vous souhaitez l'implémenter et l'endroit où vous souhaitez l'intégrer.

Cela permet d'éliminer toute ambiguïté du problème et de votre esprit, et de la consigner dans un problème.

Nous exécutons ensuite la compétence suivante, qui consiste à rédiger un document de spécifications volumineux.

Une autre compétence les découpe ensuite en problèmes, que nous classons dans le gestionnaire de problèmes de votre choix.

L'idée est que chacun de ces problèmes doit correspondre à peu près à cette fenêtre de 150 000.

Ensuite, vous choisissez un problème, que vous travailliez dans le terminal ou dans votre IDE, selon vos préférences. Vous créez, vous vérifiez la boucle, nous effaçons le contexte à la fin, il n'y a plus d'historique de conversation et nous sommes restés dans la fenêtre.

Très bien.

Parlons maintenant de AGENTS.md.

AGENTS.md vous permet de fournir des informations supplémentaires à votre agent, qui s'appliquent à n'importe quel problème sur lequel il travaille dans ce projet ou dans l'ensemble de votre espace de travail, si vous le souhaitez.

Toutefois, comme il est fourni à chaque requête, il est important de ne l'utiliser que pour des éléments qui s'appliquent idéalement en permanence.

Les règles d'architecture et de module sont donc des éléments qui fonctionnent.

Il s'agit d'informations que votre agent ne peut pas connaître, en particulier si vous travaillez sur une application à source fermée.

Mais il est très important de les comprendre pour éviter de se demander au début où placer cette fonctionnalité.

Vous pouvez donc placer des éléments tels que des composants d'UI dans le module du système de conception. Vous pouvez aussi y mettre les erreurs courantes de revue de code ou simplement les éléments courants que vous devez saisir tout le temps.

# 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.

Par exemple, "Dans ce projet, nous préférons utiliser kotlinx.datetime", etc.

J'aurais vraiment aimé vous donner des bonnes pratiques qui s'appliquent toujours, mais la réalité est que cela change à chaque sortie de modèle.

Les différents modèles se comportent différemment lorsqu'il s'agit de contexte supplémentaire.

Par exemple, à l'époque d'Opus 4.6, il était très courant d'avoir de grandes lettres majuscules indiquant "Ne faites jamais cela".

Puis, quand Opus 5 est sorti, Anthropic a publié un communiqué disant : "En fait, les majuscules ne fonctionnent plus très bien.

Utilisez simplement des minuscules."

C'est ce que je veux dire : vous devez rester au courant.

Mais certaines choses sont restées assez universelles, comme le fait de rester concis.

Veillez donc à ne pas dépasser environ 250 lignes.

Le point suivant est un peu plus controversé, car je sais que beaucoup de gens aiment faire cela, mais une étude publiée en février de cette année a montré que si vous laissez votre agent modifier son propre AGENTS.md, les performances diminuent d'environ 2 à 3 %, ce qui n'est pas si grave.

Mais le plus important, c'est que les coûts ont augmenté de 20 %.

Nous avons donc perdu un peu de performances et nos coûts ont explosé, tout cela parce que nous avons laissé l'agent écrire son propre AGENTS.md.

Pour contourner ce problème, vous pouvez demander à votre agent de rédiger une rétrospective à la fin de chaque demande d'extraction. Ensuite, lors de vos rétrospectives, vous pouvez les lire tous ensemble et décider des modifications à apporter, car ce fichier devient en quelque sorte l'élément clé de l'infrastructure d'équipe critique si vous travaillez dans de grandes équipes avec des agents.

Voici rapidement le AGENTS.md de l'application Sideline que nous avons créée.

Je voudrais attirer votre attention sur deux points.

Tout d'abord, une architecture clairement définie vous permettra d'économiser des jetons et de réduire la longueur de contexte.

En gros, cela permet à votre agent d'éviter d'avoir à examiner constamment une plus grande partie de votre codebase et à faire de plus en plus d'inférences.

Il fournit une consigne très clairement définie à suivre.

Le deuxième point que je voulais souligner concerne en particulier les applications à source fermée.

Évidemment, si vous utilisez une source fermée, aucun des agents n'a pu entraîner les LLM sur votre codebase.

Dans ce cas, il est particulièrement important de consacrer du temps à nettoyer, examiner, affiner et améliorer constamment votre AGENTS.md, car cela vous sera bénéfique à long terme.

Si nous ne devons pas tout mettre dans AGENTS.md, comment pouvons-nous modifier le comportement de l'agent ou du modèle ?

La première, ce sont les hooks, qui sont très utiles pour les éléments que les utilisateurs placent dans AGENTS.md, comme l'exécution systématique du linter une fois l'écriture terminée.

// settings.json

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

Cela peut être une accroche.

Un hook est un événement exposé par votre agent auquel vous pouvez vous abonner. Il en existe pour à peu près tout ce que vous pouvez imaginer, mais les principaux sont le démarrage d'une session, l'arrêt d'une session, ainsi que la lecture et l'écriture de fichiers.

Ainsi, au lieu d'écrire en bas de votre AGENTS.md "toujours exécuter le linter" ou "toujours exécuter ma suite de tests avant de dire que vous avez terminé", vous disposez d'un hook d'arrêt qui peut exécuter un script déterministe, ce qui permet de limiter le léger caractère aléatoire de l'IA.

Autre exemple : si vous avez des fichiers que vous ne voulez vraiment pas que votre agent puisse lire ou écrire (par exemple, un fichier de secrets que vous ne voulez pas envoyer à un serveur ou AGENTS.md, un fichier dans lequel vous ne voulez pas que votre agent puisse écrire), vous pouvez utiliser un hook pour cela.

Vous disposez donc d'un hook de lecture ou d'écriture, vous recevez le fichier qu'il tente de modifier et vous pouvez simplement renvoyer "Non, vous ne pouvez pas faire cela".

C'est juste un moyen d'ajouter du déterminisme.

Le suivant est "skills" (compétences).

Et il existe désormais des compétences pour transformer vos AGENTS.md en hooks.

C'est une autre histoire.

Mais les compétences permettent d'ajouter du contexte uniquement lorsqu'il est pertinent.

AGENTS.md est donc destiné aux éléments qui sont toujours pertinents.

Les compétences sont utiles dans certaines situations, principalement pour la documentation.

Les compétences sont donc composées de trois parties : un nom, une description (c'est la partie importante, limitée à 1 024 caractères) et un corps.

---

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

Le corps peut être volumineux et même inclure d'autres scripts, ce qui est assez courant.

Vous pouvez faire beaucoup de choses avec les compétences.

Prenons un exemple.

Il s'agit de la description de la CLI Android.

Vous n'avez pas besoin de lire tout ça.

Sachez simplement qu'il s'agit d'une brève description qui explique quand la CLI Android est pertinente.

Et voici le corps de texte.

Il est énorme, donc nous ne voulons pas le charger en permanence, n'est-ce pas ?

Nous ne voulons charger ce module que lorsque nous essayons d'utiliser la CLI Android, et c'est ce qu'une compétence nous permet de faire.

Mais il est important de sélectionner soigneusement les skills que vous installez.

Nous ne voulons pas installer aveuglément les dépôts que nous voyons en ligne et qui contiennent des centaines de compétences d'ingénierie agentique.

Premièrement, cela représente un risque de sécurité majeur.

Vous n'avez aucune idée de ce que contiennent ces compétences. Elles pourraient demander à votre agent de faire n'importe quoi.

Nous avons un ensemble de compétences Android, et je vous promets que nous les avons vérifiées. Elles ne disent pas cela.

Ensuite, 100 descriptions de 1 000 caractères représentent 100 000 caractères que vous venez d'ajouter avant même d'avoir commencé à coder.

Vous vous rapprochez donc déjà de cette fenêtre.

C'est pourquoi, pour les compétences Android, nous vous recommandons d'installer la compétence de base de la CLI Android pour tout. À partir de là, la CLI Android peut rechercher les compétences disponibles et installer celles qui sont pertinentes pour votre application.

> android init

✓ Installed base skill: android-cli

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

Si vous y jetez un œil, il est utile de savoir quelles compétences sont disponibles. Vous pouvez ajouter manuellement celles qui sont pertinentes pour votre projet, comme les compétences Compose ou bord à bord, qui sont assez universelles.

Il existe bien sûr des compétences pour auditer les compétences.

Il existe donc /skill-doctor dans Claude Code, qui va examiner et vous indiquer les compétences que vous incluez et qui ne sont jamais activées, ce qui vous évite de gaspiller cette description de 1 000 caractères.

Et si vous n'utilisez pas Claude Code, sachez que presque tous les harnais d'agent disposent d'un écran de statistiques ou d'audit pour faire la même chose.

Voici le lien vers la CLI Android.

Mais elle dispose d'une commande de liste de compétences, et supposons que vous ayez Navigation 3 dans votre projet.

android skills list
android skills add navigation-3

Navigation 3 est une bibliothèque assez récente, donc peu de formations ont été dispensées à son sujet. Vous pouvez ajouter la compétence Navigation 3.

Nous avons souvent… Oh, désolé.

Le suivant est MCP.

On nous demande souvent pourquoi nous avons fait d'Android CLI une CLI et non un serveur MCP.

Nous avons commencé à créer ces CLI bien avant l'existence de l'IA, et même avant l'existence de la souris. Elles sont donc rapides, composables et, comme elles s'exécutent localement dans votre session shell, elles sont en fait sans frais.

De plus, les benchmarks comme Terminal Bench sont devenus les plus importants en matière d'ingénierie logicielle. Les créateurs de modèles ont donc beaucoup progressé sur l'utilisation des terminaux, et ils sont aujourd'hui très doués pour utiliser les CLI.

Mais cela ne signifie pas que le MCP n'a pas sa place.

Les serveurs MCP sont très utiles pour les services externes que vous utilisez déjà, en particulier s'ils hébergent déjà un service MCP.

Vous pouvez vous y connecter directement, et c'est un moyen sans installation d'obtenir du contexte supplémentaire dans votre agent.

Des services comme GitHub, Figma et Slack exposent désormais des serveurs MCP.

Et les éléments que nous avons toujours exécutés dans le shell peuvent y rester, comme les commandes Android via la CLI Android, mais aussi Perfetto et Gradle. Il est logique de les avoir en local, où ils ont accès à tout ce que vous utilisez dans votre développement.

Je travaillais sur les performances.

J'avais l'habitude de dire que Perfetto était le seul outil dont vous aviez besoin pour résoudre n'importe quel problème de performances.

Mais la courbe d'apprentissage était très raide, comme nous l'avons vu dans la dernière présentation de Rahul.

Voyons comment l'IA peut vous aider à améliorer vos performances.

Merci, Ben.

Pour que notre application, Sideline, fonctionne, elle doit s'exécuter à 30 images par seconde et en temps réel.

Comme vous pouvez le voir sur ce Pixel 10 Pro Fold, nous n'atteignons qu'environ 20 à 22 images par seconde.

Ces images perdues vont poser problème, car cela signifie que l'application ne fonctionnera pas comme prévu. Nous allons donc devoir résoudre ce problème.

Avec la CLI Android, nous disposons des commandes du profileur Android.

Lorsque nous l'ajoutons à notre agent de codage et que nous lui demandons de respecter cette exigence de 30 images par seconde, deux choses intéressantes se produisent.

La première consiste à trouver un correctif à l'aide de la commande du profileur Android.

Il a enregistré des traces système sur l'appareil Pixel 10 Pro Fold connecté et a constaté que ses threads d'IA s'exécutaient sur les cœurs les plus lents de l'appareil.

Deuxièmement, il a utilisé la recherche dans la documentation Android, sans que nous lui ayons explicitement demandé de le faire, et a extrait les conseils officiels pour l'API Performance Hint.

L'agent a appris à optimiser la planification du système, ce qui lui a permis de répondre aux exigences de 30 images par seconde.

En gros, ce qui s'est passé, c'est que le correctif a suivi les instructions.

Avec Android CLI, l'intérêt est que, en le connectant à l'agent, il vous aide à trouver le bon outil, même si vous ne le connaissez pas, pour n'importe quelle tâche que vous devez accomplir.

Une fois l'application exécutée, vous pouvez voir que Sideline répond à l'exigence des utilisateurs de 30 images par seconde et qu'elle fonctionne désormais sur un Pixel 10 Pro Fold.

Très bien.

Nous allons maintenant combiner tout cela avec des boucles.

Je suis sûr que nous l'avons tous déjà fait : vous demandez à votre agent d'implémenter un changement important, et il revient en disant que c'est fait.

Si vous l'installez et que vous cliquez manuellement sur l'application, puis que vous saisissez les bugs, c'est ce que nous devons arrêter de faire.

Nous devons cesser d'être le testeur de contrôle qualité de notre agent et définir dès le départ ce que nous considérons comme terminé.

Voici un exemple.

Nous voulons migrer l'ensemble du projet vers Nav3, puis l'agent disparaît. Cela prend un certain temps, mais il revient en toute confiance et dit : "Migration terminée.

Je suis le meilleur."

Mais ensuite, bien sûr, vous faites pivoter le téléphone, l'application plante, elle a manqué toutes les transitions de diapositives, elle n'a pas nettoyé son fichier Gradle.

C'est un peu comme le monde dans lequel nous vivons actuellement.

Idéalement, nous n'aurions pas à le faire, mais c'est la réalité actuelle.

Nous aurions donc dû définir tout cela au préalable, ce qui aurait permis à l'agent de boucler jusqu'à ce qu'il ait rempli tous ces critères.

C'est ce qu'on appelle une boucle de validation.

Nous disposons de données très solides sur l'efficacité de cette approche.

Voici Android Bench 2.0, la nouvelle version de notre benchmark d'IA que j'ai mentionné au début de la présentation.

Le taux de réussite est actuellement d'environ 40 %.

Ces tâches sont très difficiles, très importantes et réalistes. L'une d'elles consiste à passer de Nav2 à Nav3, ce qui correspond au type de tâches que vous effectuez actuellement dans vos projets.

Si nous prenons Fable 5.1, son taux de réussite est de 22 % avec la configuration de prompt naturelle, comme "migrer Nav2 vers Nav3".

Mais si nous lui fournissons à l'avance une suite de tests qui échoue (sans lui donner les réponses ni lui expliquer comment migrer vers Nav3, mais simplement en lui fournissant une suite de tests qui échoue déjà et qui réussira lorsque toutes ces opérations seront terminées), son taux de réussite sur l'ensemble du benchmark passe à 90 %.

Cela nous montre que ces modèles sont désormais capables d'implémenter à peu près n'importe quelle tâche Android, mais qu'ils ne savent pas toujours ce que signifie "terminé".

Vous n'avez donc pas besoin d'écrire une suite complète de tests qui échouent à l'avance.

Les boucles de vérification peuvent être aussi simples que des ajouts de requêtes.

Par exemple, si vous travaillez dans l'UI, vous pouvez lui demander d'afficher l'aperçu Compose et de s'assurer qu'il correspond aux spécifications Figma, puis de vous montrer les résultats.

Cela semble vraiment fonctionner lorsque vous lui demandez de vous montrer les résultats et de prouver que la tâche a été effectuée, plutôt que d'accepter simplement la réponse textuelle "J'ai terminé".

Si vous travaillez sur la logique métier, vous pouvez lui demander d'exécuter vos tests unitaires. Comme nous l'avons vu au début, si vous travaillez sur un correctif de plantage, vous pouvez lui demander de vérifier que le plantage est corrigé sur l'appareil réel sur lequel il s'est produit via le laboratoire de test à distance.

Claude Code intègre désormais une compétence qui vous aide à créer des boucles de vérification.

N'hésitez donc pas à les consulter.

Et si vous travaillez dans Android Studio avec votre propre agent, Android Studio propose de nombreux outils autour desquels vous pouvez créer des boucles en fonction de ce sur quoi vous travaillez.

Comme pour le linter, vous pouvez lui demander de ne pas s'arrêter tant que toutes les erreurs de lint ne sont pas corrigées. Vous pouvez aussi lui demander d'exécuter vos parcours et de s'assurer qu'ils sont toujours fonctionnels.

Si vous avez écrit un parcours (ce qui est assez facile, car il s'agit simplement de prompts sur la fonctionnalité sur laquelle vous travaillez), vous pouvez lui demander de l'exécuter et de s'assurer qu'il réussit avant de déclarer qu'il a terminé.

Cependant, l'exécution des parcours prend un certain temps.

Vous pouvez également hiérarchiser les niveaux de votre boucle de validation.

Nous pouvons donc lui demander de s'assurer d'abord que les tests unitaires et les aperçus Compose s'affichent tous correctement.

Une fois que ce test est réussi, exécutez nos tests connectés et Android Journeys. Ce n'est que lorsque ces tests sont réussis que vous devez exécuter l'intégralité de la suite de tests, comme le laboratoire de test d'appareils distants, qui prendra des heures.

Si vous fournissez ces informations supplémentaires, nous constatons que l'IA effectue une boucle par niveau plutôt que d'essayer d'effectuer chaque étape à chaque exécution.

Parce que les modèles sont vraiment confiants.

Ils pensent donc toujours qu'ils sont complets et qu'ils vont réussir tous les tests du premier coup.

Voyons cela dans Sideline.

Appliquons cette idée à notre application Sideline en ajoutant une nouvelle fonctionnalité, spécifiquement pour les lunettes XR, qui seront bientôt disponibles.

Comme nous n'avons pas encore de matériel, nous allons utiliser l'émulateur XR et demander à notre agent de codage d'étendre Sideline au nouveau facteur de forme.

Pour ce faire, nous allons demander spécifiquement à nos agents de parcourir les tests JVM, les tests d'aperçu Compose et les tests d'émulateur, dans cet ordre.

Et chaque boucle est configurée pour s'appuyer sur la boucle précédente.

La première chose que nous remarquons, c'est qu'entre les boucles 1 et 2, ce sont les tests JVM qui sont utilisés pour définir les six états de l'aperçu Compose.

Bien sûr, aucun émulateur n'a été appelé, donc l'exécution est très rapide.

De même, entre les boucles 2 et 3, les problèmes tels que les chaînes longues sont détectés et corrigés avant même que l'émulateur ne s'exécute.

Enfin, une fois que la boucle de l'émulateur s'exécute, elle détecte des bugs supplémentaires que le test JVM et les aperçus Compose n'ont pas pu corriger.

Mais en gros, à chaque boucle, nous renforçons davantage notre application, et nous voulons d'abord exécuter les boucles les plus rapides, mais les moins puissantes, suivies des plus lentes, mais des plus puissantes.

Voici le résultat.

On voit que les lunettes affichent désormais le type de coup et la vitesse de la balle qui quitte la raquette. Vous pouvez ainsi jouer au tennis et obtenir des commentaires sur votre jeu en temps réel sans quitter la balle des yeux.

Oh, et j'ai mentionné plus tôt que nous reviendrions sur les deux problèmes Crashlytics qui étaient survenus précédemment.

Comme nous avons déjà pu valider que cette approche fonctionnait, nous pouvons utiliser la commande /schedule dans Claude Code pour l'exécuter en boucle. Nous pouvons définir la cadence de notre choix, de sorte que nous disposons désormais d'une application d'autoréparation qui corrige tous les bugs et valide qu'ils sont corrigés, puis les envoie sous forme de demandes d'extraction à nos ingénieurs pour qu'ils les examinent et les fusionnent.

Parfait.

Voilà, c'est tout pour aujourd'hui.

S'il y a une chose à retenir, c'est qu'il faut commencer à réfléchir à ce monde où nous créons un environnement pour que nos agents réussissent, et traiter cela un peu comme nous traitons le développement logiciel et les bugs aujourd'hui.

C'est ainsi que nous débloquons les agents parallèles.

Vous trouverez de nombreux conseils sur ce sujet en ligne, et beaucoup d'entre eux se contrediront.

C'est la réalité de cet environnement en évolution rapide.

La meilleure chose à faire est donc d'écrire vos propres évaluations pour votre projet.

Et lorsque de nouveaux conseils ou un nouveau modèle sont publiés, vous pouvez les mesurer et voir s'ils vous aident.

Et bien sûr, il existe une skill pour tout.

Il existe une compétence pour vous aider à créer des évaluations dans Claude Code.

/claude-api build-eval

Je vous recommande vivement de le consulter.

Aujourd'hui, j'ai parlé d'Android Bench.

Android Bench est notre outil d'évaluation.

C'est ainsi que nous mesurons l'amélioration des choses.

Si vous souhaitez découvrir les leçons que nous avons tirées de cette expérience pour ne pas commettre les mêmes erreurs, regardez la conférence sur Android Bench.

Il y a également deux panneaux.

Il y en a un aux États-Unis et un à Londres.

Ils seront tous les deux mis en ligne et aborderont ce type de concept en pratique dans la communauté.

Nous avons donc invité des membres de la communauté des développeurs Android à venir nous parler de la façon dont ils mettent cela en pratique dans leur travail.

Nous aimerions également beaucoup avoir vos commentaires.

Nous voulons vraiment savoir si nous développons des fonctionnalités qui vous sont réellement utiles.

Veuillez donc répondre à l'enquête.

Je vais laisser ça à l'écran.

Et voilà.

Merci de votre attention.

Merci.