Ingegneria agentica con Claude Code e la CLI Android

Ciao, sono Ben, Android Developer Relations.

Sono Steven, product manager.

Oggi parleremo della creazione di app con Claude Code e la CLI Android, in modo agentico.

Quindi, penso sia giusto dire che il nostro ruolo di sviluppatori sta cambiando un po' e le cose si stanno muovendo a una velocità pazzesca, così velocemente che, siamo onesti, i contenuti di questo intervento sono probabilmente già obsoleti, soprattutto se lo stai guardando online.

Quindi, abbiamo adottato un approccio lungimirante con ciò che abbiamo scritto, con le informazioni che presentiamo, ma le demo che eseguono oggi sono basate sulla realtà, quindi dovrebbero essere affidabili ora.

Un'altra cosa: abbiamo utilizzato Claude Code per questo talk, ma le informazioni sono indipendenti dall'agente.

Si tratta più di una mentalità, quindi dovrebbe applicarsi a qualsiasi strumento tu preferisca utilizzare per creare le tue app.

Quindi, vogliamo che iniziate a pensare a un mondo in cui gestite team di agenti autonomi e a come prepararli al successo.

Quando non riescono a implementare una funzionalità o qualcosa del genere, invece di arrendersi e dire "Oh, l'AI non può ancora farlo", dobbiamo fare un passo indietro e pensare a quale informazione mancava, trattando il problema come trattiamo i bug oggi.

Se avete letto qualcosa sui team che creano tutte queste infrastrutture agentiche, Claude Code, Codex, Antigravity, vedrete che è così che i loro team sviluppano effettivamente queste infrastrutture e, se li consideriamo come una sorta di sguardo al futuro, è probabilmente la direzione in cui stiamo andando tutti.

Quindi, probabilmente non c'è mai stato un momento più entusiasmante per essere un builder, per essere uno sviluppatore Android, ma se sei come me, potresti trovare difficile sapere esattamente su cosa concentrarti.

E noi, in qualità di sviluppatori, abbiamo bisogno di strumenti e flussi di lavoro che scalino davvero con l'intelligence, in modo che, quando un nuovo modello estende la frontiera, tutto il nostro duro lavoro non diventi ridondante.

Vogliamo che ogni miglioramento del modello porti a workflow più intelligenti per i nostri agenti, che alla fine si traducono in risultati migliori per i nostri utenti.

Oggi parleremo di quattro argomenti.

Innanzitutto, spiegheremo perché è così importante configurare gli agenti in ambienti che ne favoriscano il successo.

Poi, forniremo una panoramica sul contesto e su come gestirlo al meglio.

Successivamente, parleremo di alcuni dei migliori strumenti che abbiamo a disposizione per gli sviluppatori Android che lavorano con gli agenti e, infine, spiegheremo perché è importante aggiungere loop agli Agentic Workflows.

Iniziamo.

Quindi, l'ambiente.

Ma cosa significa esattamente?

Beh, è come dicevo, stiamo cercando di creare uno spazio in cui il nostro agente possa avere successo e possa farlo senza che tu debba sederti lì e, tipo, riproporgli costantemente i prompt e rimetterlo in carreggiata, perché quando lo fai, è allora che sblocchi la possibilità di eseguire agenti paralleli, ed è lì che, tipo, arrivano i veri guadagni di produttività, quando puoi avere questi team di agenti che fanno tutto il lavoro per te.

Ma questo va ben oltre il semplice accesso al codice.

Devono avere accesso a una documentazione accurata, che includa le specifiche del progetto e le regole per lavorare su quel progetto.

Questa è la parte più ovvia.

Alcune persone stanno collegando il proprio agente allo spazio di chat del team, non solo per avviare gli agenti, ma per fornire effettivamente il contesto di come sono state prese le decisioni che hanno portato alla funzionalità che è stato chiesto loro di realizzare, perché come sviluppatore, questo è il tipo di informazioni subconsce che utilizzi quando risolvi i problemi, quindi può essere utile anche per il tuo agente.

Inoltre, puoi consultare la cronologia delle decisioni precedenti e le richieste di pull.

Dovrebbero essere in grado di vedere i commenti che ricevi sulle tue richieste di pull, il tipo di cose per cui vengono contattati e così via, e poi scoprirai che possono lavorare e risolvere il problema.

Inoltre, non ti aspetteresti di poter scrivere codice Android senza accedere a un dispositivo o a un emulatore, quindi non dovresti aspettarti che l'agente sia in grado di farlo.

So che sembrano incredibili e in grado di fare qualsiasi cosa, ma un emulatore è davvero utile.

Lo stesso vale per i profiler.

Se vuoi che lavorino sul rendimento, devono essere in grado di eseguire la profilazione, il che implica l'accesso a un dispositivo reale.

Inoltre, l'agente dovrebbe essere in grado di comunicare anche con i servizi di backend utilizzati dalla tua app.

Ed è qui che entra in gioco la CLI Android.

Se non ne hai sentito parlare, è stato menzionato anche nel talk "Novità degli strumenti", ma la CLI Android è la nostra nuova interfaccia a riga di comando per l'interfacciamento, solo con vari strumenti Android.

Non è un prodotto di AI in sé, è solo una CLI, un'interfaccia a riga di comando.

In questo modo, ti consente di accedere a elementi come SDK Manager di Android, di avviare emulatori e molto altro.

Inoltre, si connette a strumenti e backend come Crashlytics.

Funziona con qualsiasi agente tu stia utilizzando, si trova semplicemente nello spazio della shell.

Quindi, sì.

Puoi installarla tramite questo link, ma penso che sia più facile vederla in azione.

Okay.

Quindi, invece di spiegare semplicemente perché è così importante preparare gli agenti al successo, abbiamo voluto applicare questo principio a un'applicazione di produzione che abbiamo creato, chiamata Sideline.

Sideline è un'app per Android per i tennisti che fornisce loro feedback in tempo reale sulla posizione della pallina, del giocatore e del campo.

Fornisce feedback di coaching offline tramite replay video e dati sul fitness per elementi come velocità massima, distanza percorsa e scambi più lunghi.

Tutto questo è possibile grazie a modelli TF Lite personalizzati eseguiti direttamente sul dispositivo Android.

Innanzitutto, voglio dire che ovviamente non possiamo risolvere problemi di cui non siamo a conoscenza.

Quindi, utilizzando la CLI Android, abbiamo aggiunto Firebase Crashlytics al nostro ambiente di sviluppo, il che ci ha permesso di trovare alcuni problemi di cui non sapevamo nemmeno l'esistenza.

Il primo era un errore "L'applicazione non risponde" (ANR) che si verificava su un dispositivo Pixel 11 Pro Fold, ma non nell'emulatore.

Fortunatamente, l'interfaccia a riga di comando di Android supporta Android Device Streaming.

Una volta ricevuto l'ordine di risolvere il problema, l'agente ha creato una connessione al dispositivo su cui si stava verificando l'ANR, il che è stato particolarmente utile per me perché all'epoca non avevo un Pixel 11 Pro Fold su cui convalidare la correzione.

Quindi, dando all'agente la possibilità di accedere al dispositivo necessario per convalidare la correzione, siamo stati in grado di espandere l'insieme di funzionalità di ciò che è possibile fare.

Per risparmiare tempo, ho eseguito tutti gli esperimenti in anticipo e li ho riassunti qui.

Senza entrare troppo nei dettagli, il problema che abbiamo riscontrato era una chiamata di affinità relativa ad Android 17.

Si trattava di una correzione rapida di due righe, che mi sembrava corretta.

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

Quindi, ho creato la richiesta di pull, l'ho unita e ho aggiornato con una nuova build inviata a Google Play.

Quindi, se non avessimo configurato l'ambiente di programmazione con le funzionalità necessarie per avere successo, non saremmo stati in grado di identificare un problema reale, né di convalidare una correzione.

Quindi, con le build 1.0, puoi vedere che il problema è stato risolto.

Tuttavia, sono emersi nuovi problemi di cui parleremo più avanti.

Okay.

Prossimo argomento: il contesto.

Quindi, circa un anno e mezzo, due anni fa, che non è molto tempo, ma nello spazio dell'AI è una vita, c'era questa corsa ad avere finestre di contesto sempre più grandi e la teoria era che più potevamo lanciare al modello, migliori risultati avremmo ottenuto e stavamo facendo cose folli come cercare di includere l'intero developer.android.com nel prompt, ma non ha funzionato.

Tuttavia, anche se le finestre contestuali si sono stabilizzate, le funzionalità dei modelli continuano a migliorare.

Questo è Android Bench 1.0.

Android Bench è il nostro benchmark che valuta la capacità dell'AI di scrivere codice Android.

Le attività sono realistiche.

Sono il tipo di cose su cui si lavora e possiamo vedere che le finestre contestuali si sono stabilizzate su quel milione di token, ma la capacità del modello continua a crescere.

Ma il contesto è comunque un budget fisso e vuoi risparmiarlo per ciò che è importante.

Non vuoi che ci siano elementi che non aiutano a risolvere il problema esatto su cui stai lavorando.

E molte delle infrastrutture agentiche non espongono effettivamente l'intera finestra contestuale da 1 milione di token perché ritengono che sia inutile.

I risultati peggiorano quando lo fanno.

In realtà esiste un punto ottimale, che varia a seconda del modello, ma se riesci a mantenere le tue conversazioni intorno ai 150.000 token, è lì che ottieni la piena potenza del modello senza alcun deterioramento del contesto.

Ma il contesto non è solo ciò che digiti.

[
  {
    "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 }"
  }
]

In realtà, dietro le quinte c'è molto di più di quello che vedi.

È composto da diverse parti.

La prima è l'istruzione di sistema.

L'istruzione di sistema viene fornita dall'agente.

È un po' come un prompt che indica come lavorare con questo agente, il tipo di comportamento che deve adottare.

Ma anche informazioni sullo spazio di lavoro, come la directory di lavoro corrente, gli SDK che hai, le skill installate, di cui parleremo tra un attimo, e gli strumenti MCP, nonché tutti gli strumenti forniti dal tuo agente.

Il modello deve sapere che può chiamarle, quindi questo occupa contesto.

Ma la cosa più importante è che la cronologia completa dei messaggi e delle chiamate agli strumenti viene inviata con ogni prompt, ogni nuovo messaggio che invii, con l'agente.

E questo può davvero fare la differenza, soprattutto con Gradle.

Come tutti sappiamo, i log di Gradle sono molto lunghi, davvero molto lunghi e molto dettagliati.

La maggior parte di queste informazioni non è obbligatoria.

Ecco un breve suggerimento per fare attenzione a questo aspetto.

Puoi eseguire Gradle in modalità silenziosa.

./gradlew assembleDebug --quiet

In alternativa, i framework degli agenti più grandi troncano il testo per te.

Quindi, Claude Code e Android Studio non inviano il log Gradle completo.

Ma se utilizzi uno degli agenti minimali, poiché la loro filosofia è quella di inviare tutto al modello, il modello sa cosa è meglio, quindi mini-SWE-agent invia l'intero log di Gradle e questo può diventare molto costoso molto rapidamente.

Ma come facciamo a rimanere entro questa finestra magica di 150.000?

La chiave è utilizzare un flusso di lavoro.

Esistono tantissimi flussi di lavoro.

Quello che mi piace di più è di un ragazzo di nome Matt Pocock, che ha una serie di competenze per aiutarti a gestire queste sessioni.

Inizia con la skill "grill-me".

Quello che devi fare è eseguire questa skill quando inizi un intero progetto o solo una nuova funzionalità all'interno del progetto, in modo che l'agente ti ponga una serie di domande.

Quindi, potresti dire "grill-me.

Voglio creare, non so, un nuovo gestore di sveglie nella mia app."

Inizierà a farti domande su come implementarlo, dove appartiene.

In questo modo, l'ambiguità viene eliminata dal problema e dalla tua testa e viene inserita in un problema.

Poi eseguiamo la skill successiva, che scrive una sorta di documento di specifiche di grandi dimensioni.

C'è un'altra skill che poi lo suddivide in problemi, che vengono archiviati nel gestore dei problemi che preferisci utilizzare.

L'idea è che ognuno di questi problemi dovrebbe rientrare approssimativamente in quella finestra di 150.000.

Poi, scegli un problema, che tu stia lavorando nel terminale o nell'IDE, come preferisci, crei, verifichi il loop, cancelliamo il contesto alla fine, non c'è più cronologia delle conversazioni e rimaniamo nella finestra.

Okay.

Ora passiamo a AGENTS.md.

AGENTS.md è il luogo in cui puoi fornire informazioni aggiuntive per l'agente, che si applicano a qualsiasi problema su cui sta lavorando in questo progetto o nell'intero workspace, se scegli di farlo.

Tuttavia, poiché viene fornito a ogni prompt, è importante limitarlo a cose che si applicano idealmente sempre.

Quindi, gli elementi che funzionano sono le regole di architettura e dei moduli.

Si tratta di informazioni che l'agente non avrebbe potuto conoscere, soprattutto se lavori su un'app closed source.

Tuttavia, è molto importante comprenderli per evitare di dover ragionare all'inizio su dove appartiene questa funzionalità.

Quindi, puoi inserire elementi come i componenti UI nel modulo del sistema di progettazione, oppure un'altra cosa che funziona molto bene sono gli errori comuni di revisione del codice o semplicemente le cose comuni che stai raccogliendo e che devi digitare continuamente.

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

Quindi, sai, in questo progetto preferiamo utilizzare kotlinx.datetime, cose del genere.

E volevo davvero fornire una sorta di best practice che si applicano sempre, ma la realtà è che questo cambia con ogni release del modello.

Modelli diversi hanno comportamenti diversi per quanto riguarda il contesto aggiuntivo.

Ad esempio, ai tempi di Opus 4.6, era molto comune avere grandi lettere maiuscole che dicevano "Non farlo mai".

Poi, quando è uscito Opus 5, Anthropic ha rilasciato una dichiarazione in cui affermava: "In realtà, le lettere maiuscole non funzionano più così bene.

Utilizza solo lettere minuscole."

Ecco cosa intendo: devi tenere tutto sotto controllo.

Tuttavia, alcune cose sono rimaste piuttosto universali, come la brevità.

Quindi, non superare le 250 righe.

E questo, il prossimo è un po' polarizzante, perché so che a molte persone piace farlo, ma uno studio pubblicato a febbraio di quest'anno ha dimostrato che se lasci che il tuo agente modifichi il proprio AGENTS.md, le prestazioni peggiorano di circa il 2-3%, il che, sai, non è un grosso problema.

Ma l'aspetto importante è che i costi sono aumentati del 20%.

Quindi, abbiamo perso un po' di prestazioni e abbiamo fatto esplodere i costi, tutto perché abbiamo lasciato che l'agente scrivesse il proprio AGENTS.md.

Un modo per aggirare questo problema che ho visto è chiedere all'agente di scrivere una retrospettiva alla fine di ogni richiesta di pull, in modo che il team possa leggerle tutte insieme durante le retrospettive e decidere quali modifiche apportare, perché questo file sta diventando il pezzo chiave dell'infrastruttura critica del team se si lavora in team di grandi dimensioni con agenti.

Quindi, molto rapidamente, ecco il AGENTS.md per l'applicazione Sideline che abbiamo creato.

Ci sono due aspetti che voglio sottolineare.

Il primo è che un'architettura chiaramente definita ti farà risparmiare token e finestra contestuale.

In pratica, consente all'agente di evitare di dover esaminare costantemente una parte maggiore del codebase e fare sempre più inferenze.

Fornisce una linea guida molto chiara da seguire.

Il secondo aspetto che volevo sottolineare riguarda in particolare le applicazioni closed source.

Ovviamente, se il tuo codice è closed source, nessuno degli agenti o degli LLM ha potuto addestrarsi sul tuo codebase.

Quindi, in questi casi, è particolarmente importante dedicare più tempo, più cicli, alla pulizia, alla revisione, al perfezionamento e al miglioramento costante del tuo AGENTS.md, perché ne trarrai vantaggio nel lungo periodo.

Quindi, se non dobbiamo inserire tutto in AGENTS.md, come possiamo modificare il comportamento dell'agente o del modello?

Beh, il primo sono gli hook, che sono davvero utili per il tipo di cose che le persone inseriscono in AGENTS.md, ad esempio, eseguire sempre il linter quando hai finito di scrivere.

// settings.json

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

Questo può essere un hook.

Un hook è un agente che espone tutti questi eventi a cui puoi iscriverti. Ce ne sono per quasi tutto ciò che ti viene in mente, ma i principali sono l'avvio della sessione, l'interruzione della sessione, la lettura e la scrittura dei file.

Quindi, invece di scrivere in fondo al tuo AGENTS.md "esegui sempre il linter" o "esegui sempre la mia suite di test prima di dire che hai finito", hai un hook di arresto che può eseguire uno script deterministico e aiuta a tenere sotto controllo la leggera casualità dell'AI.

Un altro esempio: se hai file che non vuoi che l'agente possa leggere o scrivere, ad esempio un file di secret, non vuoi che venga inviato a un server o AGENTS.md, non vuoi che l'agente possa scriverci, puoi avere un hook per questo.

Quindi, se hai un hook di lettura o scrittura, ti viene passato il file che sta tentando di modificare e puoi semplicemente restituire "No, non puoi farlo".

È solo un modo per aggiungere determinismo.

La seconda è "skills" (competenze).

E ora ci sono anche skill per trasformare i tuoi AGENTS.md in hook.

Questa è un'altra cosa.

Le skill, invece, consentono di aggiungere contesto solo quando è pertinente.

Quindi AGENTS.md è per le cose che sono sempre pertinenti.

Le skill sono utili per attività pertinenti in determinate situazioni, principalmente la documentazione.

Le skill sono composte da tre parti: un nome, una descrizione (questa è la parte importante, la descrizione è limitata a 1024 caratteri) e un corpo.

---

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

Il corpo può essere enorme e può anche includere altri script, il che è piuttosto comune.

Puoi fare molte cose con le skill.

Vediamo un esempio.

Questa è la descrizione di CLI Android.

Non devi leggere tutto.

Tieni presente che si tratta di una breve descrizione che spiega quando è pertinente la CLI Android.

Questo è il corpo.

È enorme, quindi non vogliamo caricare tutto questo ogni volta, giusto?

Vogliamo caricarlo solo quando proviamo a utilizzare la CLI Android, ed è proprio questo che ci consente di fare una skill.

Tuttavia, è importante essere selettivi riguardo alle skill che installi.

Non vogliamo limitarci a installare ciecamente i repository che vediamo online e che contengono centinaia di competenze di ingegneria agentica.

Innanzitutto, si tratta di un enorme rischio per la sicurezza.

Non hai idea di cosa contengano queste skill, potrebbero dire al tuo agente di fare qualsiasi cosa.

E abbiamo un insieme di competenze Android, ti assicuro che le abbiamo verificate, non dicono questo.

In secondo luogo, 100 descrizioni per 1000 caratteri equivalgono a 100.000 caratteri che hai appena aggiunto prima ancora di iniziare a programmare.

Quindi ti stai già avvicinando a quella finestra.

Ecco perché, con le skill Android, consigliamo di installare la skill di base della CLI Android per tutto. Da lì, la CLI Android può cercare le skill disponibili e installare quelle più adatte alla tua app.

> android init

✓ Installed base skill: android-cli

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

In alternativa, se dai un'occhiata, è utile sapere quali competenze sono disponibili, puoi aggiungere manualmente quelle che hanno senso per il tuo progetto, ad esempio le competenze di Compose, le competenze edge-to-edge, che sono piuttosto universali.

Naturalmente, esistono competenze per controllare le competenze.

Quindi c'è /skill-doctor in Claude Code, che darà un'occhiata e ti dirà quali skill stai includendo che non vengono mai attivate, quindi stai solo sprecando quella descrizione di mille caratteri.

E se non utilizzi Claude Code, praticamente ogni infrastruttura agentica ha una sorta di schermata di statistiche o di controllo per fare la stessa cosa.

Quindi, ancora una volta, CLI Android, questo è il link.

Tuttavia, ha un comando per l'elenco delle skill e supponiamo che tu abbia Navigation 3 nel tuo progetto.

android skills list
android skills add navigation-3

Navigation 3 è una libreria piuttosto nuova, quindi non è ancora stato eseguito molto addestramento. Puoi aggiungere la competenza Navigation 3.

Spesso Oh, scusa.

Il prossimo è MCP.

Ma spesso ci viene chiesto perché abbiamo reso la CLI Android una CLI e non un server MCP.

Beh, abbiamo creato queste CLI molto prima che esistesse l'AI, molto prima che esistesse il mouse, quindi sono veloci, componibili e, poiché vengono eseguite localmente nella sessione della shell, sono effettivamente senza costi.

Inoltre, benchmark come Terminal Bench sono diventati i più importanti per l'ingegneria del software, quindi i creatori di modelli hanno scalato aggressivamente l'utilizzo dei terminali, quindi oggi sono davvero bravi a utilizzare le CLI.

Ma questo non significa che l'MCP non abbia un ruolo.

I server MCP sono davvero ottimi per i servizi esterni che utilizzi già, soprattutto se ospitano già un servizio MCP.

Puoi collegarti direttamente e ottenere un contesto aggiuntivo per il tuo agente senza installazione.

Piattaforme come GitHub, Figma e Slack stanno esponendo i server MCP.

E poi le cose che abbiamo sempre eseguito nella shell possono rimanere nella shell, quindi i comandi Android tramite l'interfaccia a riga di comando di Android, ma anche Perfetto e Gradle hanno senso solo se sono locali, dove hanno accesso a tutto ciò che usi nel tuo sviluppo.

In passato mi occupavo di rendimento.

Dicevo sempre che Perfetto è l'unico strumento necessario per risolvere qualsiasi problema di prestazioni.

Ma la curva di apprendimento era molto ripida, come abbiamo appena visto nell'ultimo intervento di Rahul.

Vediamo come l'AI può contribuire a migliorare il rendimento.

Grazie, Ben.

Quindi, per funzionare, la nostra applicazione, Sideline, deve essere eseguita a 30 frame al secondo e in tempo reale.

E come puoi vedere qui su questo Pixel 10 Pro Fold, raggiungiamo solo circa 20-22 frame al secondo.

Questi frame ignorati saranno un problema, perché significa che l'applicazione non funzionerà come pubblicizzato, quindi dovremo assolutamente risolvere il problema.

Con la CLI Android, abbiamo i comandi del profiler Android.

E quando lo aggiungiamo al nostro agente di programmazione e lo istruiamo a soddisfare questo requisito di 30 frame al secondo, accadono due cose interessanti.

La prima è che trova una correzione utilizzando il comando del profiler Android.

Ha registrato i tracciamenti del sistema sul Pixel 10 Pro Fold collegato e ha scoperto che i thread AI venivano eseguiti sui core più lenti del dispositivo.

La seconda è che ha utilizzato la ricerca nella documentazione di Android, curiosamente senza che noi glielo chiedessimo esplicitamente, e ha recuperato le indicazioni ufficiali per l'API Performance Hint.

L'agente ha imparato a ottimizzare la pianificazione del sistema e, in questo modo, è stato in grado di soddisfare i requisiti di 30 frame al secondo.

In sostanza, la correzione ha seguito le indicazioni.

Quindi, con la CLI Android, la chiave è, sai, collegandola al tuo agente, ti aiuta a trovare lo strumento giusto, anche se non hai familiarità con quello strumento, per qualsiasi lavoro tu debba essere in grado di svolgere.

Quindi, una volta eseguita, puoi vedere che Sideline soddisfa il requisito di 30 frame al secondo richiesto dagli utenti e ora funziona su un Pixel 10 Pro Fold.

Okay.

Ora metteremo tutto insieme con i loop.

Sono sicuro che è capitato a tutti: chiedi all'agente di implementare una modifica importante e l'agente ti risponde che è stata eseguita.

Se la installi e fai clic manualmente sull'app e digiti i bug, è proprio questo che dobbiamo smettere di fare.

Dobbiamo smettere di essere i tester QA del nostro agente e definire in anticipo cosa consideriamo "completato".

Ecco un esempio.

Vogliamo eseguire la migrazione dell'intero progetto a Nav3, quindi l'agente si allontana, impiega un po' di tempo, ma torna con sicurezza e dice: "Migrazione completata.

Sono il migliore."

Ma poi, ovviamente, ruoti lo smartphone, l'app si arresta in modo anomalo, perde tutte le transizioni delle slide e non pulisce il file Gradle.

Questo è un po' come il mondo in cui ci troviamo ora.

Idealmente, non dovremmo farlo, ma questa è la realtà attuale.

Quindi, avremmo dovuto definire tutto in anticipo su ciò che ci aspettiamo, e questo avrebbe consentito all'agente di eseguire il loop fino a quando non avesse soddisfatto tutti questi criteri.

Questo è un percorso di verifica circolare.

In effetti, abbiamo dati molto solidi sull'efficacia di questo approccio.

Questo è Android Bench 2.0, la nuova versione del nostro benchmark AI di cui ho parlato all'inizio del discorso.

Al momento, i tassi di superamento sono di circa il 40%.

Queste attività sono davvero difficili, molto ampie e realistiche, ma una di queste è Nav2-Nav3, il tipo di cose che stai facendo nei tuoi progetti in questo momento.

Se prendiamo Fable 5.1, la percentuale di successo è del 22%, ovvero quella che si ottiene con la configurazione del prompt naturale, come "esegui la migrazione di Nav2 a Nav3".

Ma se gli forniamo in anticipo una suite di test non riuscita, senza dargli le risposte, senza dirgli come eseguire la migrazione a Nav3, ma solo una suite di test che non è già riuscita e che riuscirà quando tutte queste cose saranno completate, le sue percentuali di successo sull'intero benchmark salgono al 90%.

Questo ci dimostra che questi modelli sono ora in grado di implementare praticamente qualsiasi attività Android che ci venga in mente, solo che non sempre sanno cosa significa "completato".

Quindi, non devi scrivere in anticipo una suite di test completa che non va a buon fine.

I loop di verifica possono essere semplici come le aggiunte di prompt.

Ad esempio, se stai lavorando nell'interfaccia utente, puoi chiedere di eseguire il rendering dell'anteprima di Compose, assicurarti che corrisponda alla specifica di Figma e mostrare i risultati.

Sembra funzionare davvero quando gli chiedi di mostrarti i risultati e di dimostrare che l'attività è stata completata, anziché accettare semplicemente la risposta testuale "Ho finito".

Se stai lavorando alla logica di business, puoi chiedere di eseguire i test delle unità o, come abbiamo visto all'inizio, se stai lavorando alla correzione di un arresto anomalo, puoi chiedere di convalidare la correzione dell'arresto anomalo sul dispositivo reale su cui si è verificato tramite il lab di test remoto.

In realtà, Claude Code include una skill che ti aiuta a creare loop di verifica.

Quindi, dai un'occhiata.

E se lavori in Android Studio con un agente personalizzato, Android Studio espone una serie di strumenti che puoi utilizzare per creare loop a seconda di ciò su cui stai lavorando.

Quindi, come il linter, potresti dirgli di non fermarsi finché non vengono corretti tutti gli errori di lint, oppure, quello che mi piace molto, sono i percorsi, puoi chiedergli di eseguire i tuoi percorsi e assicurarti che siano ancora funzionanti.

Oppure, se hai scritto un percorso, dato che i percorsi sono piuttosto facili da scrivere, sono solo prompt sulla funzionalità su cui stai lavorando, puoi dirgli di eseguire quel percorso e assicurarti che lo superi prima di dichiararsi completato.

Tuttavia, l'esecuzione dei percorsi richiede un po' di tempo.

Quindi, puoi anche suddividere in livelli il ciclo di verifica.

Quindi, possiamo chiedergli di assicurarsi innanzitutto che i test delle unità e le anteprime di Compose vengano visualizzati correttamente.

E poi, quando questo test viene superato, esegui i nostri test connessi e i percorsi Android e, solo quando anche questi vengono superati, esegui il test lab completo dei dispositivi remoti, la suite di test completa che richiederà ore.

Se fornisci queste informazioni aggiuntive, scopriamo che il loop viene eseguito per livello anziché tentare di eseguire ogni passaggio a ogni esecuzione.

Perché i modelli sono molto sicuri.

Quindi, pensano sempre di essere completi e di superare tutti i test al primo tentativo.

Diamo un'occhiata a questa funzionalità in Sideline.

Applichiamo questa idea alla nostra applicazione Sideline e facciamolo aggiungendo una nuova funzionalità, in particolare per gli occhiali XR, che saranno disponibili a breve.

E poiché non abbiamo ancora l'hardware, ovviamente utilizzeremo l'emulatore XR e istruiremo il nostro agente di programmazione per estendere Sideline al nuovo fattore di forma.

In questo modo, chiederemo specificamente ai nostri agenti di eseguire in loop i test JVM, i test di anteprima di Compose e i test dell'emulatore, in quest'ordine.

Inoltre, ogni loop è progettato per basarsi su quello precedente.

In questo modo, la prima cosa che notiamo è che tra il loop uno e il loop due, sono i test JVM che vengono utilizzati per definire i sei stati di Anteprima di Compose.

Ovviamente non è stato chiamato alcun emulatore, quindi l'esecuzione è molto rapida.

Allo stesso modo, tra il ciclo due e il ciclo tre, vengono rilevati e risolti problemi come le stringhe lunghe, prima ancora che l'emulatore debba essere eseguito.

Infine, una volta eseguito il loop dell'emulatore, vengono rilevati altri bug che il test JVM e le anteprime di Compose non sono riusciti a correggere.

In sostanza, con ogni ciclo rafforziamo ulteriormente la nostra applicazione e vogliamo eseguire prima i cicli più veloci, ma meno potenti, seguiti da quelli più lenti, ma più potenti.

Ecco il risultato.

Mostra che gli occhiali ora mostrano il tipo di swing e la velocità della pallina che esce dalla racchetta, in modo che tu possa giocare a tennis e ricevere feedback sul tuo gameplay in tempo reale senza distogliere lo sguardo dalla pallina.

Oh, e prima ho detto che saremmo tornati ai due problemi di Crashlytics che si erano verificati in precedenza.

Quindi, dato che abbiamo già potuto verificare che questo approccio funziona, possiamo usare il comando /schedule in Claude Code per eseguirlo in loop e possiamo impostare qualsiasi cadenza vogliamo, in modo da avere un'applicazione con correzione automatica che corregge tutti i bug e verifica che siano stati corretti, li invia come richieste di pull ai nostri ingegneri per esaminarli e unirli.

Perfetto.

Per oggi è tutto.

Se c'è un aspetto fondamentale da ricordare, è iniziare a pensare a questo mondo in cui stiamo creando un ambiente in cui i nostri agenti possano avere successo e trattarlo un po' come trattiamo oggi lo sviluppo di software e i bug.

È così che sblocchiamo gli agenti paralleli.

Online troverai molti consigli su questo argomento, molti dei quali saranno in conflitto tra loro.

È la realtà di questo ambiente in rapida evoluzione.

Quindi, la cosa migliore che puoi fare è scrivere le tue valutazioni per il tuo progetto.

Quando vengono pubblicati nuovi consigli o un nuovo modello, puoi misurarli e vedere se ti aiutano.

E, naturalmente, c'è una skill per tutto.

Esiste una skill che ti aiuta a creare valutazioni in Claude Code.

/claude-api build-eval

Ti consiglio vivamente di dare un'occhiata.

Oggi ho parlato di Android Bench.

Android Bench è la nostra valutazione.

È il modo in cui misuriamo per assicurarci che le cose stiano migliorando.

Se vuoi ascoltare le lezioni che abbiamo imparato durante la creazione, in modo da non commettere gli stessi errori, dai un'occhiata al talk su Android Bench.

Ci sono anche due panel.

Uno negli Stati Uniti e uno a Londra.

Entrambi i video verranno pubblicati online e parleranno di questo tipo di concetto in pratica nella community.

Quindi, abbiamo invitato alcuni membri della community di sviluppatori Android a parlare di come stanno mettendo in pratica tutto questo nel loro lavoro.

Inoltre, ci piacerebbe molto ricevere il tuo feedback.

Vogliamo davvero sapere se stiamo creando cose che ti aiutano effettivamente.

Quindi, compila il sondaggio.

Lascerò questa schermata.

E, sì.

Grazie per l'attenzione.

Grazie.