Engenharia de agentes com o Claude Code e a CLI do Android

Olá, meu nome é Ben, sou da equipe de relações com desenvolvedores Android.

Sou Steven, gerente de produtos.

Hoje vamos falar sobre como criar apps com o Claude Code e a CLI do Android de forma agêntica.

Então, acho que é justo dizer que nosso papel como desenvolvedores está mudando um pouco, e as coisas estão se movendo muito rápido, tão rápido que, para ser sincero, o conteúdo desta palestra provavelmente já está desatualizado, especialmente se você estiver assistindo on-line.

Por isso, adotamos uma postura proativa com o que escrevemos e com as informações que apresentamos, mas as demonstrações que eles executam hoje são baseadas na realidade, então devem ser confiáveis agora.

Outra coisa é que usamos o Claude Code para esta palestra, mas as informações são independentes de agente.

É mais uma mentalidade, então deve se aplicar ao que você preferir usar ao criar seus apps.

Por isso, queremos que você comece a pensar em um mundo em que gerencia equipes de agentes autônomos e como prepará-los para o sucesso.

Quando eles não conseguem implementar um recurso ou algo parecido, em vez de desistir e dizer "Ah, a IA ainda não consegue fazer isso", precisamos dar um passo atrás e pensar em qual informação estava faltando, tratando isso como tratamos os bugs hoje.

Se você ler qualquer coisa que venha das equipes que criam todas essas estruturas de agentes, Claude Code, Codex, Antigravity, vai ver que é assim que as equipes realmente desenvolvem essas estruturas. Se as considerarmos como um vislumbre do futuro, é provavelmente para lá que todos estamos indo.

Então, provavelmente nunca houve um momento mais empolgante para ser um criador, um desenvolvedor Android, mas se você é como eu, pode achar difícil saber exatamente em que focar.

E nós, como desenvolvedores, precisamos de ferramentas e fluxos de trabalho que realmente escalem com inteligência, para que, à medida que um novo modelo amplie as fronteiras, todo o nosso trabalho árduo não se torne redundante.

Queremos que cada melhoria no modelo leve a fluxos de trabalho mais inteligentes para nossos agentes, o que resulta em melhores resultados para os usuários.

Hoje, vamos abordar quatro temas.

Primeiro, vamos explicar por que é tão importante configurar seus agentes em ambientes para que eles tenham sucesso.

Em seguida, vamos apresentar uma visão geral do contexto e como gerenciá-lo da melhor forma.

Depois, vamos falar sobre algumas das melhores ferramentas disponíveis para desenvolvedores Android que trabalham com agentes e, por fim, vamos defender a adição de loops aos seus Agentic Workflows.

Vamos ao que interessa.

Portanto, o ambiente.

Mas o que isso significa na prática?

Como eu estava dizendo, estamos tentando criar um espaço onde o agente possa ter sucesso sem que você precise ficar constantemente reescrevendo comandos e o colocando de volta no caminho certo. Quando você faz isso, consegue executar agentes paralelos, e é aí que os ganhos reais de produtividade aparecem, quando você tem essas equipes de agentes fazendo todo o trabalho para você.

Mas isso vai muito além de apenas ter acesso ao código.

Eles precisam de acesso a uma documentação precisa, que inclua especificações do projeto e regras de como trabalhar nele.

Essa é a mais óbvia.

Outra coisa que as pessoas estão fazendo é conectar o agente ao espaço de chat da equipe, não apenas para iniciar os agentes, mas para fornecer o contexto de como as decisões foram tomadas e levaram ao recurso que eles precisam criar. Como desenvolvedor, esse é o tipo de informação subconsciente que você usa ao resolver problemas, então pode ser útil para o agente também.

Também como o histórico de decisões anteriores e as solicitações de pull.

Eles precisam ver os comentários que você recebe nas solicitações de pull, o tipo de coisa que eles recebem, coisas assim, e então você vai descobrir que eles podem trabalhar e corrigir isso.

Além disso, você não espera escrever código Android sem acesso a um dispositivo ou emulador, então não espere que seu agente faça isso.

Sei que eles parecem incríveis e capazes de fazer qualquer coisa, mas um emulador ajuda muito.

O mesmo vale para os criadores de perfil.

Se você quiser que eles trabalhem no desempenho, eles precisam ser capazes de criar perfis, o que envolve ter acesso a um dispositivo real.

E, idealmente, o agente também deve ser capaz de se comunicar com os serviços de back-end usados pelo app.

É aí que entra a CLI do Android.

Se você não ouviu falar dela, ela também estava na palestra "Novidades em ferramentas", mas a CLI do Android é nossa nova CLI para interface, apenas com várias ferramentas do Android.

Não é um produto de IA em si, é apenas uma CLI, uma interface de linha de comando.

Ele dá acesso a recursos como o Android SDK Manager, a inicialização de emuladores e muito mais.

Ele também se conecta a ferramentas e back-ends como o Crashlytics.

Ele funciona com qualquer agente que você esteja usando, basta ficar no seu espaço de shell.

Então, sim.

Você pode instalá-lo neste link, mas acho mais fácil ver como ele funciona.

Certo.

Por isso, em vez de apenas explicar por que é tão importante preparar seus agentes para o sucesso, queríamos aplicar esse princípio a um aplicativo de produção que criamos, chamado Sideline.

E o Sideline é um app Android para tenistas que fornece feedback em tempo real sobre a localização da bola, do jogador e da quadra.

Ele oferece feedback de treinamento off-line por meio de replay de vídeo e dados de condicionamento físico, como velocidade máxima, distância percorrida e ralis mais longos.

Tudo isso é feito com modelos personalizados do TF Lite que são executados diretamente no dispositivo Android.

Antes de mais nada, quero dizer que não podemos resolver problemas que não sabemos que existem.

Usando a CLI do Android, adicionamos o Firebase Crashlytics ao nosso ambiente de desenvolvimento, o que nos permitiu encontrar alguns problemas que nem sabíamos que estavam ocorrendo.

O primeiro foi um erro "O app não está respondendo" (ANR) em um dispositivo Pixel 11 Pro Fold, que não foi reproduzido no emulador.

Felizmente, a CLI do Android é compatível com o streaming de dispositivos Android.

E o que o agente fez quando pedimos para corrigir esse problema foi criar uma conexão com o dispositivo em que o ANR estava ocorrendo, o que foi particularmente útil para mim porque, na época, eu não tinha um Pixel 11 Pro Fold para validar a correção.

Ao dar ao agente a capacidade de acessar o dispositivo necessário para validar a correção, conseguimos expandir o conjunto de recursos possíveis.

Para economizar tempo, fiz todos os experimentos com antecedência e os resumi aqui.

Sem entrar em muitos detalhes, o problema que estávamos enfrentando era uma chamada de afinidade relacionada ao Android 17.

Foi uma correção rápida de duas linhas, que me pareceu boa.

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

Então, criei a solicitação de pull, fiz a mesclagem e atualizei com um novo build enviado ao Google Play.

Se não tivéssemos configurado o ambiente de programação com os recursos necessários, não teríamos conseguido identificar um problema real nem validar uma correção.

Com as versões 1.0, o problema foi resolvido.

No entanto, novos problemas surgiram, e vamos falar sobre eles mais tarde.

Certo.

A seguir: contexto.

Há cerca de um ano e meio ou dois anos, o que não é muito tempo, mas no espaço da IA é uma vida inteira, houve uma corrida para ter janelas de contexto cada vez maiores. A teoria era que, quanto mais pudéssemos fornecer ao modelo, melhores seriam os resultados. Estávamos fazendo coisas malucas, como tentar incluir todo o developer.android.com no comando, mas não funcionou muito bem.

Mas, embora as janelas de contexto tenham se estabilizado, as capacidades dos modelos continuam aumentando.

Esse é o Android Bench 1.0.

O Android Bench é nosso comparativo de mercado que avalia a capacidade da IA de escrever código Android.

As tarefas são realistas.

São o tipo de coisa em que você trabalha, e podemos ver que as janelas de contexto se estabilizaram na marca de 1 milhão, mas a capacidade do modelo continua aumentando.

Mas o contexto ainda é um orçamento fixo, e você quer economizar para o que é importante.

Não inclua nada que não ajude a resolver o problema em questão.

E muitas das estruturas de agentes não expõem essa janela de contexto completa de 1 milhão para você porque acham que é inútil.

Os resultados só pioram quando eles fazem isso.

E, na verdade, há um ponto ideal, que muda dependendo do modelo, mas se você conseguir manter suas conversas em cerca de 150.000 tokens, é aí que você terá todo o poder do modelo sem nenhuma perda de contexto.

Mas o contexto não é apenas o que você está digitando.

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

Na verdade, há muita coisa acontecendo nos bastidores que você não vê.

Ele é composto por várias partes.

A primeira é a instrução do sistema.

A instrução do sistema é fornecida pelo agente.

É como um comando que diz como trabalhar com esse agente, o tipo de comportamento que ele deve ter.

Mas também informações do espaço de trabalho, como o diretório de trabalho atual, os SDKs que você tem, as habilidades instaladas (vamos falar sobre isso em um segundo) e as ferramentas do MCP, além de qualquer ferramenta fornecida pelo seu agente.

O modelo precisa saber que pode chamá-las, o que ocupa contexto.

Mas o principal é que o histórico completo de mensagens e chamadas de ferramentas é enviado com cada comando, cada nova mensagem que você envia, com seu agente.

E isso pode realmente se acumular, especialmente com o Gradle.

Como todos sabemos, os registros do Gradle são muito longos, muito detalhados.

A maioria não é obrigatória.

Então, fica a dica para prestar atenção nisso.

É possível executar o Gradle no modo silencioso.

./gradlew assembleDebug --quiet

Ou as estruturas de agentes maiores fazem isso por você.

Então, o Claude Code e o Android Studio não enviam o registro completo do Gradle.

Mas se você estiver usando um dos agentes mínimos, como a filosofia deles é enviar tudo para o modelo, o modelo sabe o que é melhor. Então, o mini-SWE-agent envia todo o registro do Gradle, e isso pode ficar muito caro muito rápido.

Mas como podemos ficar dentro dessa janela mágica de 150.000?

A chave é usar um fluxo de trabalho.

E há muitos fluxos de trabalho por aí.

O que eu mais gosto é de um cara chamado Matt Pocock, que tem uma série de habilidades para ajudar você a gerenciar essas sessões.

Então, começa com a habilidade chamada "grill-me".

Você executa essa habilidade ao iniciar um projeto inteiro ou apenas um novo recurso dentro do projeto, e ela faz com que o agente faça várias perguntas.

Então, você pode dizer: "Me faça perguntas.

Quero criar, sei lá, um novo gerenciador de alarmes no meu app."

Ele vai começar a fazer perguntas sobre como implementar e onde colocar o código.

E isso elimina toda a ambiguidade do problema e da sua cabeça, transformando-a em um problema.

Em seguida, executamos a próxima habilidade, que é escrever um documento de especificação grande.

Há outra habilidade que divide o conteúdo em problemas, que são registrados no gerenciador de problemas que você preferir.

A ideia é que cada um desses problemas se encaixe nessa janela de 150.000.

Em seguida, você escolhe um problema, seja no terminal ou no ambiente de desenvolvimento integrado, o que preferir, cria, verifica o loop, limpamos o contexto no final, sem mais histórico de conversas, e ficamos dentro da janela.

Certo.

Agora vamos falar sobre AGENTS.md.

Em AGENTS.md, você pode fornecer informações extras para o agente que se aplicam a qualquer problema que ele esteja resolvendo neste projeto ou em todo o espaço de trabalho, se você quiser.

No entanto, como ele é fornecido a cada comando, é importante que ele seja usado apenas para coisas que se aplicam o tempo todo.

Portanto, o que funciona são as regras de arquitetura e de módulo.

São coisas que o agente não poderia saber, especialmente se você trabalha em um app de software proprietário.

Mas é muito importante entender para não precisar pensar no início sobre onde esse recurso pertence.

Por exemplo, você pode colocar componentes de interface no módulo do sistema de design. Outra coisa que funciona muito bem é colocar erros comuns de revisão de código ou coisas que você precisa digitar o tempo todo.

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

Neste projeto, preferimos usar kotlinx.datetime, coisas assim.

Eu queria muito oferecer práticas recomendadas que sempre funcionassem, mas a realidade é que isso muda a cada lançamento de modelo.

Modelos diferentes têm comportamentos distintos quando se trata de contexto extra.

Por exemplo, na época do Opus 4.6, era muito comum ter letras maiúsculas grandes que diziam "Nunca faça isso".

E quando o Opus 5 foi lançado, a Anthropic divulgou um comunicado dizendo: "Na verdade, as letras maiúsculas não funcionam mais tão bem.

Use apenas letras minúsculas."

É isso que quero dizer: você precisa ficar por dentro de tudo.

Mas algumas coisas que continuam sendo universais são: manter o conteúdo curto.

Portanto, mantenha-o com menos de 250 linhas.

E este próximo é um pouco polarizador, porque sei que muita gente adora fazer isso, mas um estudo publicado em fevereiro deste ano mostrou que, se você permitir que seu agente modifique o próprio AGENTS.md, o desempenho será reduzido em cerca de 2% a 3%, o que, você sabe, não é grande coisa.

Mas o importante é que os custos aumentaram em 20%.

Ou seja, perdemos um pouco de desempenho e estouramos os custos, tudo porque deixamos o agente escrever o próprio AGENTS.md.

Uma solução que já vi é pedir para o agente escrever uma retrospectiva ao final de cada solicitação de pull. Depois, a equipe pode ler todas juntas nas retrospectivas e decidir quais modificações fazer. Esse arquivo está se tornando uma peça-chave da infraestrutura crítica da equipe, especialmente se você trabalha em equipes grandes com agentes.

Então, de forma rápida, aqui está o AGENTS.md do aplicativo Sideline que criamos.

Quero destacar duas coisas aqui.

A primeira é que ter uma arquitetura claramente definida vai economizar tokens e tamanho do contexto.

Basicamente, ele evita que o agente precise analisar constantemente sua base de código e fazer cada vez mais inferências.

Ele fornece uma diretriz muito bem definida para o modelo seguir.

E o segundo ponto que eu queria destacar é específico para os aplicativos de software proprietário.

Obviamente, se você usa software proprietário, nenhum dos agentes ou LLMs foi treinado na sua base de código.

Portanto, nesses casos, é importante dedicar um tempo extra para limpar, revisar, refinar e melhorar constantemente seu AGENTS.md, porque isso vai beneficiar você a longo prazo.

Se não devemos colocar tudo em AGENTS.md, como podemos mudar o comportamento do agente ou do modelo?

O primeiro são os hooks, que são muito bons para o tipo de coisa que as pessoas colocam em AGENTS.md, como "sempre execute o linter quando terminar de escrever".

// settings.json

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

Isso pode ser um gancho.

Um hook é o agente expondo todos esses eventos que você pode assinar, e há hooks para praticamente tudo o que você imaginar, mas os principais são iniciar sessão, interromper sessão, ler e gravar arquivos.

Então, em vez de escrever na parte de baixo do AGENTS.md "sempre execute o linter" ou "sempre execute meu pacote de testes antes de dizer que terminou", você tem um gancho de parada que pode executar um script determinístico, o que ajuda a controlar a leve aleatoriedade da IA.

Outro exemplo: se você tiver arquivos que não quer que o agente leia ou grave, como um arquivo de secrets, e não quer que ele seja enviado para um servidor ou AGENTS.md que o agente possa gravar nele, use um hook para isso.

Então, você tem um hook de leitura ou gravação, recebe o arquivo que está tentando editar e pode simplesmente retornar "Não, você não pode fazer isso".

É apenas uma maneira de adicionar determinismo.

O próximo é "skills".

E agora existem habilidades para transformar seus AGENTS.md em ganchos.

Isso é outra coisa.

Mas as habilidades são uma forma de adicionar contexto apenas quando ele é relevante.

Portanto, AGENTS.md é para coisas que são sempre relevantes.

As habilidades são para coisas relevantes em determinadas situações, principalmente documentação.

As habilidades são compostas por três partes: um nome, uma descrição (que é a parte importante, limitada a 1.024 caracteres) e um corpo.

---

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

O corpo pode ser enorme e até incluir outros scripts, o que é bem comum.

Você pode fazer muita coisa com as habilidades.

Vamos analisar um exemplo.

Esta é a descrição da CLI do Android.

Você não precisa ler tudo isso.

É como uma breve descrição que explica quando a CLI do Android é relevante.

E este é o corpo.

Ele é enorme, então não queremos carregar tudo isso o tempo todo, certo?

Só queremos carregar isso quando estamos tentando usar a CLI do Android, e é isso que uma habilidade nos permite fazer.

Mas é importante ser seletivo sobre as habilidades que você instala.

Não queremos apenas instalar cegamente os repositórios que vemos on-line com centenas de habilidades de engenharia de agentes.

Primeiro, isso é um risco enorme para a segurança.

Você não sabe o que está nessas habilidades, elas podem estar dizendo ao seu agente para fazer qualquer coisa.

E temos um conjunto de habilidades do Android, que foram verificadas, e elas não dizem isso.

Mas, em segundo lugar, 100 descrições vezes 1.000 caracteres são 100.000 caracteres que você acabou de adicionar antes mesmo de começar a programar.

Então você já está se aproximando dessa janela.

Por isso, recomendamos instalar a habilidade básica da CLI do Android para tudo. Assim, ela pode pesquisar as habilidades disponíveis e instalar as que fazem sentido para seu app.

> android init

✓ Installed base skill: android-cli

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

Ou, se você der uma olhada, é bom saber quais habilidades estão disponíveis. Você pode adicionar manualmente as que fazem sentido para seu projeto, como as habilidades do Compose e de ponta a ponta, que são bastante universais.

É claro que existem habilidades para auditar habilidades.

Então, há o /skill-doctor no Claude Code, que vai analisar e informar quais habilidades você está incluindo que nunca são ativadas, para que você não desperdice essa descrição de mil caracteres.

E se você não estiver no Claude Code, praticamente todas as estruturas de agentes têm algum tipo de tela de estatísticas ou de auditoria para fazer a mesma coisa.

Este é o link da CLI do Android.

Mas ele tem um comando de lista de habilidades. Digamos que você tenha o Navigation 3 no seu projeto.

android skills list
android skills add navigation-3

A Navigation 3 é uma biblioteca bem nova, então ainda não há muito treinamento sobre ela. Você pode adicionar a habilidade Navigation 3.

Muitas vezes, ah, desculpe.

O próximo é o MCP.

Mas muitas vezes nos perguntam por que criamos a CLI do Android como uma CLI e não como um servidor MCP.

Bem, nós criamos essas coisas de CLI muito antes da IA existir, muito antes do mouse existir, estávamos criando CLIs, então elas são rápidas, são combináveis e, como são executadas localmente na sua sessão de shell, são efetivamente sem custo financeiro para executar.

Além disso, benchmarks como o Terminal Bench se tornaram os maiores benchmarks quando se trata de engenharia de software. Por isso, os criadores de modelos têm se esforçado para melhorar o uso do terminal, e hoje em dia eles são muito bons em usar CLIs.

Mas isso não significa que o MCP não tenha utilidade.

Os servidores MCP são ótimos para os serviços externos que você já usa, especialmente se eles já hospedam um serviço MCP.

Você pode se conectar diretamente a ele, e é uma maneira sem instalação de adicionar mais contexto ao seu agente.

Plataformas como GitHub, Figma e Slack já estão expondo servidores MCP.

E as coisas que sempre executamos no shell podem continuar lá, como os comandos do Android pela CLI do Android, mas o Perfetto e o Gradle também fazem sentido no local, onde têm acesso a tudo o que você usa no desenvolvimento.

Eu trabalhava com performance.

Eu sempre dizia que o Perfetto é a única ferramenta necessária para resolver qualquer problema de desempenho.

Mas a curva de aprendizado era muito íngreme, como vimos na última palestra do Rahul.

Vamos ver como a IA pode ajudar a melhorar a performance.

Obrigado, Ben.

Para que o aplicativo Sideline funcione, ele precisa ser executado a 30 quadros por segundo e em tempo real.

Como você pode ver aqui no Pixel 10 Pro Fold, estamos alcançando apenas cerca de 20 a 22 quadros por segundo.

Esses frames descartados serão um problema, porque isso significa que o aplicativo não vai funcionar como anunciado. Por isso, precisamos corrigir isso.

Com a CLI do Android, temos os comandos do Android Profiler.

E quando adicionamos isso ao nosso agente de programação e o instruímos a atender a esse requisito de 30 quadros por segundo, duas coisas interessantes acontecem.

A primeira é que ele encontra uma correção usando o comando do Android Profiler.

Ele registrou rastreamentos do sistema no dispositivo Pixel 10 Pro Fold conectado e descobriu que as linhas de execução de IA estavam sendo executadas nos núcleos mais lentos do dispositivo.

E a segunda é que ele usou a pesquisa de documentos do Android, sem que pedíssemos explicitamente, e extraiu as orientações oficiais para a API Performance Hint.

O agente aprendeu a otimizar a programação do sistema e, assim, conseguiu atender aos requisitos de 30 quadros por segundo.

Então, basicamente, o que aconteceu é que a correção seguiu as orientações.

Então, com a CLI do Android, o segredo é que, ao conectá-la ao agente, ela ajuda você a encontrar a ferramenta certa, mesmo que você não a conheça, para qualquer tarefa que precise realizar.

Depois de executar, você pode ver que o Sideline atende ao requisito de 30 quadros por segundo que os usuários têm e agora funciona em um Pixel 10 Pro Fold.

Certo.

Agora, vamos juntar tudo isso com loops.

Tenho certeza de que todos nós já fizemos isso: você pede ao agente para implementar uma grande mudança, e ele volta dizendo que está pronto.

Se você instalar o app e clicar manualmente nele, digitando os bugs, é isso que precisamos parar de fazer.

Precisamos parar de ser os testadores de controle de qualidade do nosso agente e definir de antemão o que consideramos como "concluído".

Veja um exemplo.

Queremos migrar todo o projeto para o Nav3. O agente sai, leva um tempo, mas volta com confiança e diz: "Migração concluída.

Eu sou o melhor."

Mas, se você girar o smartphone, o app vai falhar, perder todas as transições de slide e não vai limpar o arquivo do Gradle.

É mais ou menos como o mundo em que vivemos hoje.

O ideal seria não precisar fazer isso, mas essa é a realidade atual.

Portanto, deveríamos ter definido tudo isso de antemão, o que permitiria que o agente fizesse um loop até atender a todos esses critérios.

Isso é um loop de verificação.

E temos dados muito consistentes sobre a eficácia disso.

Este é o Android Bench 2.0, a nova versão do nosso comparativo de IA que mencionei no início da palestra.

As taxas de aprovação estão em cerca de 40%.

Essas tarefas são muito difíceis, grandes e realistas, mas uma delas é a Nav2 para Nav3, que é o tipo de coisa que você está fazendo nos seus projetos agora.

E se pegarmos o Fable 5.1, a taxa de aprovação é de 22%, que é o que ele consegue apenas com a configuração de comando natural, como "migrar Nav2 para Nav3".

Mas se fornecermos um pacote de testes com falha com antecedência, sem dar as respostas ou dizer como migrar para o Nav3, apenas um pacote de testes que já está falhando e que será aprovado quando tudo estiver concluído, as taxas de aprovação em todo o comparativo de mercado vão saltar para 90%.

Isso mostra que esses modelos são capazes de implementar praticamente qualquer tarefa do Android que possamos imaginar, mas nem sempre sabem o que significa "concluído".

Assim, você não precisa escrever um pacote de testes com falha completo com antecedência.

Os loops de verificação podem ser tão simples quanto adições de comandos.

Por exemplo, se você estiver trabalhando na interface, pode pedir para ele renderizar a prévia do Compose, garantir que ela corresponda à especificação do Figma e mostrar os resultados.

Parece que funciona mesmo quando você pede para mostrar os resultados e provar que foi feito, em vez de apenas aceitar a resposta de texto "Terminei".

Se você estiver trabalhando na lógica de negócios, peça para ele executar seus testes de unidade. Ou, como vimos no início, se estiver trabalhando em uma correção de falha, peça para ele validar se a falha foi corrigida no dispositivo real em que ocorreu usando o laboratório de teste remoto.

Na verdade, o Claude Code tem uma habilidade integrada para ajudar você a criar loops de verificação.

Não deixe de conferir.

E se você estiver trabalhando no Android Studio com o recurso de trazer seu próprio agente, o Android Studio vai expor várias ferramentas que podem ser usadas para criar loops, dependendo do que você estiver fazendo.

Assim como o linter, você pode pedir para ele não parar até que todos os erros de lint sejam corrigidos. Ou, o que eu mais gosto, as jornadas. Você pode pedir para ele executar suas jornadas e garantir que elas ainda estejam funcionando.

Ou, se você escreveu uma jornada, porque as jornadas são bem fáceis de escrever, elas são apenas comandos sobre o recurso em que você está trabalhando, você pode pedir para executar essa jornada e garantir que ela seja aprovada antes de se declarar concluída.

Mas as jornadas levam um tempo para serem executadas.

Você também pode criar níveis para o loop de verificação.

Então, podemos pedir que ele verifique se os testes de unidade e as prévias do Compose estão sendo renderizados corretamente.

E, quando isso for aprovado, execute nossos testes conectados e as jornadas do Android. Somente quando isso for aprovado, execute o laboratório de teste de dispositivo remoto completo, o pacote de testes completo que vai levar horas.

Se você fornecer essas informações extras, o modelo vai fazer um loop por nível em vez de tentar realizar cada etapa em cada execução.

Porque os modelos são muito confiantes.

Por isso, eles sempre acham que estão completos e que vão passar em todos os testes de primeira.

Vamos dar uma olhada nisso no Sideline.

Vamos aplicar essa ideia ao nosso aplicativo Sideline adicionando um novo recurso, especificamente para os óculos de XR, que serão lançados em breve.

Como ainda não temos o hardware, vamos usar o emulador de XR e instruir nosso agente de programação a estender o Sideline para o novo formato.

Ao fazer isso, vamos pedir especificamente aos nossos agentes que percorram os testes da JVM, do Compose Preview e do emulador, nessa ordem.

Cada loop é instruído a se basear no anterior.

Ao fazer isso, a primeira coisa que notamos é que, entre os loops um e dois, são os testes da JVM que são usados para definir os seis estados de visualização do Compose.

Como nenhum emulador foi chamado, a execução é muito rápida.

Da mesma forma, entre os loops dois e três, problemas como strings longas são identificados e corrigidos antes mesmo de o emulador ser executado.

Por fim, quando o loop do emulador é executado, ele encontra outros bugs que o teste da JVM e as prévias do Compose não conseguiram corrigir.

Mas, basicamente, a cada loop, estamos fortalecendo ainda mais nosso aplicativo. Queremos executar primeiro os loops mais rápidos, mas menos potentes, seguidos pelos mais lentos, mas mais potentes.

E aqui está o resultado.

Ele mostra que os óculos agora mostram o tipo de rebatida e a velocidade da bola saindo da raquete, para que você possa jogar tênis e receber feedback sobre sua jogabilidade em tempo real sem tirar os olhos da bola.

Ah, e eu mencionei antes que voltaríamos aos dois problemas do Crashlytics que surgiram antes.

Como já validamos que essa abordagem funcionou, podemos usar o comando /schedule no Claude Code para repetir o processo e definir a cadência que quisermos. Assim, temos um aplicativo de autorrecuperação que corrige todos os bugs, valida as correções e as envia como solicitações de pull para que nossos engenheiros as analisem e mesclem.

Legal.

Por hoje é só.

Se você puder levar uma lição, é começar a pensar em um mundo onde criamos um ambiente para que nossos agentes tenham sucesso e tratar isso como tratamos o desenvolvimento de software e os bugs hoje.

É assim que desbloqueamos os agentes paralelos.

Você vai encontrar muitos conselhos sobre esse assunto on-line, e muitos deles vão ser conflitantes.

E essa é a realidade desse ambiente em rápida evolução.

Portanto, o melhor a fazer é escrever suas próprias avaliações para o projeto.

E quando um novo conselho ou modelo é lançado, você pode medir e ver se ele ajuda.

E, claro, há uma habilidade para tudo.

Há uma habilidade para ajudar você a criar avaliações no Claude Code.

/claude-api build-eval

Recomendo que você confira.

Hoje, falamos sobre o Android Bench.

O Android Bench é nossa avaliação.

É assim que medimos para garantir que as coisas estão melhorando.

Se quiser saber o que aprendemos ao criar esse recurso para não cometer os mesmos erros, confira a palestra sobre o Android Bench.

Há também dois painéis.

Há um nos EUA e outro em Londres.

Ambos serão publicados on-line e falam sobre esse tipo de conceito na prática na comunidade.

Por isso, convidamos membros da comunidade de desenvolvedores Android para falar sobre como estão colocando isso em prática no trabalho.

Também queremos muito seu feedback.

Queremos saber se estamos criando recursos que realmente ajudam você.

Por isso, responda à pesquisa.

Vou deixar isso na tela.

E, sim.

Agradeço pela sua atenção.

Nossa equipe agradece.