Агентная разработка с Claude Code и Android CLI

Здравствуйте! Меня зовут Бен, я работаю в отделе по связям с разработчиками Android.

Меня зовут Стивен, я менеджер по продукту.

Сегодня мы поговорим о том, как создавать приложения с помощью Claude Code и Android CLI, используя агентный подход.

Думаю, можно сказать, что наша роль как разработчиков немного меняется, и всё движется безумно быстро, настолько быстро, что, давайте будем честны, содержание этого доклада, вероятно, уже устарело, особенно если вы смотрите его онлайн.

Поэтому мы заняли активную позицию в отношении того, что мы написали, и информации, которую мы представляем, но демонстрации, которые они проводят сегодня, основаны на реальности, поэтому сейчас они должны быть надежными.

Ещё один момент: в этом докладе мы использовали Claude Code, но информация не зависит от агента.

Это скорее образ мышления, поэтому он должен применяться ко всему, что вы предпочитаете использовать при создании своих приложений.

Поэтому мы хотим, чтобы вы начали думать о мире, в котором вы управляете командами автономных агентов, и о том, как вы настраиваете их на успех.

Когда у них не получается реализовать функцию или что-то в этом роде, вместо того чтобы просто сдаться и сказать: "О, ИИ пока не может этого сделать", нам нужно сделать шаг назад и подумать, какой информации не хватало, и относиться к этому так, как мы относимся к ошибкам сегодня.

Если вы читали что-то от команд, которые создают все эти агентные обвязки, Claude Code, Codex, Antigravity, вы увидите, что именно так их команды на самом деле разрабатывают эти обвязки, и если мы воспримем их как своего рода взгляд в будущее, то, вероятно, именно туда мы все и направляемся.

Сейчас, пожалуй, самое интересное время для разработчиков Android, но, возможно, вам, как и мне, трудно понять, на чем именно сосредоточиться.

А нам, разработчикам, нужны инструменты и рабочие процессы, которые действительно масштабируются с помощью ИИ, чтобы по мере расширения границ новой модели вся наша тяжелая работа не становилась излишней.

Мы хотим, чтобы каждое улучшение модели приводило к более интеллектуальным рабочим процессам для наших агентов, что в конечном итоге приводит к лучшим результатам для наших пользователей.

Сегодня мы обсудим четыре темы.

Сначала мы расскажем, почему так важно создать для агентов подходящую среду.

Затем мы расскажем о контексте и о том, как им управлять.

Затем мы рассмотрим некоторые из лучших инструментов, доступных разработчикам Android, работающим с агентами, и, наконец, мы обоснуем необходимость добавления циклов в ваши рабочие процессы с агентами.

Давайте начнем.

Итак, среда.

Но что это значит на самом деле?

Как я уже говорил, мы пытаемся создать пространство, в котором наш агент сможет добиться успеха, и сможет добиться успеха без того, чтобы вы сидели там и постоянно, например, повторно подсказывали ему и возвращали его на правильный путь, потому что, когда вы это делаете, именно тогда вы открываете возможность запускать параллельных агентов, и именно здесь, например, происходит реальный прирост производительности, когда у вас могут быть эти команды агентов, которые делают всю вашу работу за вас.

Но это выходит далеко за рамки простого доступа к коду.

Им нужен доступ к точной документации, которая включает спецификации проекта и правила работы над этим проектом.

Это очевидно.

Некоторые разработчики подключают агента к чату команды, чтобы он не только запускал других агентов, но и понимал контекст принятия решений, которые привели к созданию функции, над которой он работает. Как разработчик, вы используете эту информацию на подсознательном уровне, когда решаете проблемы, и она может быть полезна и вашему агенту.

Также как и предыдущая история решений и pull-запросы.

Они должны видеть комментарии, которые вы получаете к своим pull-запросам, то, на что они обращают внимание, и тому подобное, и тогда вы обнаружите, что они могут работать и исправлять это.

Кроме того, вы не сможете писать код для Android без доступа к устройству или эмулятору, поэтому не стоит ожидать, что ваш агент сможет это сделать.

Я знаю, что они кажутся потрясающими и могут делать все, что угодно, но эмулятор действительно помогает.

То же самое касается профилировщиков.

Если вы хотите, чтобы они работали над производительностью, они должны иметь возможность профилировать, что предполагает доступ к реальному устройству.

И в идеале ваш агент должен иметь возможность взаимодействовать со всеми серверными сервисами, которые использует ваше приложение.

Именно здесь на помощь приходит Android CLI.

Если вы не слышали о нем, то он также упоминался в докладе "Что нового в инструментах". Android CLI – это наш новый интерфейс командной строки для взаимодействия с различными инструментами Android.

Это не ИИ-продукт, а просто интерфейс командной строки.

Так, она предоставляет вам доступ к таким вещам, как Android SDK Manager, возможность запускать эмуляторы и многое другое.

Он также подключается к инструментам и серверным частям, таким как Crashlytics.

Он работает с любым агентом, которого вы используете, и просто находится в пространстве оболочки.

Вот так.

Вы можете установить его по этой ссылке, но я думаю, что проще будет просто посмотреть на него в действии.

Теперь

Поэтому вместо того, чтобы просто объяснять, почему так важно настроить агентов на успех, мы хотели применить этот принцип к созданному нами рабочему приложению под названием Sideline.

А Sideline – это приложение для Android, которое предоставляет теннисистам информацию о местоположении мяча, игрока и корта в реальном времени.

Оно позволяет просматривать видеозаписи тренировок и предоставляет данные о физической активности, например о максимальной скорости, пройденном расстоянии и самых длинных розыгрышах.

Все это работает на основе специальных моделей TF Lite, которые запускаются прямо на устройстве Android.

Прежде всего, мы не можем решать проблемы, о которых не знаем.

Поэтому с помощью Android CLI мы добавили Firebase Crashlytics в нашу среду разработки, что позволило нам найти некоторые проблемы, о которых мы даже не подозревали.

Первая проблема – ошибка ANR ("Приложение не отвечает") на устройстве Pixel 11 Pro Fold, которую не удалось воспроизвести в эмуляторе.

К счастью, Android CLI поддерживает стриминг устройств Android.

Когда мы попросили агента исправить проблему, он подключился к устройству, на котором возникала ошибка ANR. Это было особенно полезно, потому что у меня не было Pixel 11 Pro Fold, чтобы проверить исправление.

Предоставив агенту доступ к устройству, необходимому для проверки исправления, мы смогли расширить набор возможностей.

Чтобы сэкономить время, я провел все эксперименты заранее и обобщил их здесь.

Не вдаваясь в подробности, скажу, что проблема была связана с вызовом сходства в Android 17.

Это было быстрое исправление в две строки, которое показалось мне хорошим.

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

Я создал pull-запрос, объединил его и обновил приложение, отправив новую сборку в Google Play.

Если бы мы не настроили среду программирования с возможностями, необходимыми для успешной работы, мы не смогли бы выявить реальную проблему и не смогли бы проверить исправление.

В сборках 1.0 проблема решена.

Однако возникли новые проблемы, о которых мы поговорим позже.

Теперь

Далее: контекст.

Примерно полтора-два года назад, что не так уж и давно, но в сфере ИИ это целая жизнь, была гонка за все большими и большими окнами контекста, и теория заключалась в том, что чем больше мы могли бы дать модели, тем лучшие результаты мы бы получили, и мы делали сумасшедшие вещи, например, пытались включить весь developer.android.com в подсказку, это не очень-то сработало.

Но даже несмотря на то, что окна контекста в основном вышли на плато, возможности моделей продолжают расти.

Это Android Bench 1.0.

Android Bench – это наш тест, который оценивает способность ИИ писать код для Android.

Задачи в нем реалистичны.

Это то, над чем вы работаете, и мы видим, что контекстные окна застыли на отметке в 1 миллион, но возможности модели продолжают расти.

Но контекст – это по-прежнему фиксированный бюджет, и вы хотите сохранить его для того, что важно.

Вам не нужны вещи, которые не помогают решить конкретную проблему, над которой вы работаете.

И многие агентные обвязки на самом деле не предоставляют вам доступ к этому полному контекстному окну в 1 миллион токенов, потому что считают, что это бессмысленно.

Результаты от этого только ухудшаются.

И на самом деле есть золотая середина, и она меняется в зависимости от модели, но если вы можете ограничить свои разговоры примерно 150 000 токенов, то именно здесь вы получите полную мощность модели без какого-либо ухудшения контекста.

Но контекст – это не только то, что вы вводите.

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

На самом деле за кулисами происходит много того, чего вы не видите.

Он состоит из нескольких частей.

Первый – это системные инструкции.

Системные инструкции предоставляются вашим агентом.

Это своего рода подсказка, которая сообщает, как работать с этим агентом, какое поведение он должен демонстрировать.

Но также и информацию о рабочей области, например о текущем рабочем каталоге, о том, какие SDK у вас есть, о любых установленных навыках (мы поговорим об этом через секунду), об инструментах MCP и о любых инструментах, предоставляемых вашим агентом.

Модель должна знать, что может вызывать их, поэтому они занимают контекст.

Но самое главное – полная история сообщений и журнал вызовов инструментов отправляется с каждым запросом, каждым новым сообщением, которое вы отправляете агенту.

И это, это действительно может складываться, особенно с Gradle.

Как мы все знаем, журналы Gradle очень длинные и подробные.

Большинство этих настроек необязательны.

Вот вам совет, как этого избежать.

Вы можете запустить Gradle в тихом режиме.

./gradlew assembleDebug --quiet

или же это делают более крупные агентные обвязки.

Поэтому Claude Code и Android Studio не отправляют полный журнал Gradle.

Но если вы используете одного из минимальных агентов, потому что вся их философия заключается в том, чтобы отправлять все в модель, модель знает лучше, поэтому mini-SWE-agent отправляет этот полный журнал Gradle, и это может стать очень дорогим очень быстро.

Но как удержаться в пределах этого магического окна в 150 000?

Что ж, ключ в том, чтобы использовать рабочий процесс.

И существует множество рабочих процессов.

Мне очень нравится серия Мэтта Покока, в которой он рассказывает о навыках, помогающих управлять такими сеансами.

Итак, начнем с навыка "grill-me".

Вы запускаете этот навык, когда только начинаете работу над проектом или новой функцией в нем, и агент задает вам ряд вопросов.

Вы можете просто сказать: "Проверь меня.

Я хочу создать, не знаю, новый менеджер будильников в своем приложении".

И он начнет задавать вам вопросы о том, как мы должны его реализовать, где он должен находиться.

И это убирает всю двусмысленность из проблемы и из вашей головы в па- в проблему.

Затем мы запускаем следующий навык, который пишет большой документ со спецификацией.

Другой навык разбивает его на задачи, которые мы заносим в выбранный вами менеджер задач.

Идея в том,что каждый из этих выпусков должен укладываться примерно в 150 000 экземпляров.

Затем вы выбираете одну проблему, работаете в терминале или IDE, как вам удобнее, создаете, проверяете цикл, в конце мы очищаем контекст, больше нет истории разговоров, и мы остаемся в окне.

Теперь

Теперь поговорим о AGENTS.md.

AGENTS.md – это место, где вы можете предоставить агенту дополнительную информацию, которая относится к любой проблеме, над которой он работает в этом проекте или во всей рабочей области, если вы решите это сделать.

Но поскольку она предоставляется для каждого запроса, важно, чтобы она содержала только то, что применимо всегда.

Поэтому работают такие вещи, как правила архитектуры и модулей.

Это то, о чем агент не может знать, особенно если вы работаете над приложением с закрытым исходным кодом.

Но их важно понимать, чтобы не тратить время на размышления о том, к какому типу относится функция.

Например, в модуль системы проектирования можно поместить компоненты пользовательского интерфейса. Также очень удобно добавлять туда распространенные ошибки, которые выявляются при проверке кода, или просто часто используемые фрагменты, которые приходится постоянно вводить вручную.

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

Например, в этом проекте мы предпочитаем использовать kotlinx.datetime и так далее.

Я бы хотел дать вам рекомендации, которые будут работать всегда, но на самом деле все меняется с каждым выпуском новой модели.

Разные модели по-разному обрабатывают дополнительный контекст.

Например, в Opus 4.6 часто встречались большие заглавные буквы, которые говорили: "Никогда так не делайте".

А когда вышла Opus 5, Anthropic выпустила заявление, в котором говорилось: "На самом деле, заглавные буквы больше не работают так хорошо.

Используйте только строчные буквы".

Вот что я имею в виду: вы должны быть в курсе всего.

Но некоторые вещи, которые остались довольно универсальными, должны быть короткими.

Поэтому в нем должно быть не более 250 строк.

И ещё один момент, который может вызвать споры, потому что я знаю, что многие любят это делать. В феврале этого года вышло исследование, которое показало, что если вы разрешите своему агенту изменять собственный AGENTS.md, это снизит производительность примерно на 2–3 %. Это не так уж и много.

Но важно то, что это увеличило расходы на 20%.

Таким образом, мы немного потеряли в производительности и сильно увеличили расходы, и все это из-за того, что позволили агенту написать собственный AGENTS.md.

Чтобы обойти это, можно попросить агента писать ретроспективу в конце каждого pull-запроса, а затем вы, как команда, на своих ретроспективах можете читать их все вместе и решать, какие изменения вы собираетесь внести, потому что этот файл становится своего рода ключевым элементом критической инфраструктуры команды, если вы работаете в больших командах с агентами.

Вот AGENTS.md для приложения Sideline, которое мы создали.

Здесь я хочу обратить внимание на две вещи.

Во-первых, четко определенная архитектура сэкономит вам токены и длину контекста.

По сути, это позволяет вашему агенту не заглядывать постоянно в базу кода и не делать все больше и больше выводов.

Оно предоставляет очень чётко определённое руководство, которому нужно следовать.

И второе, о чем я хотел бы упомянуть, касается приложений с закрытым исходным кодом.

Очевидно, что если у вас закрытый исходный код, ни один из агентов не сможет обучить LLM на вашей базе кода.

Поэтому в таких случаях особенно важно тратить дополнительное время на постоянную очистку, проверку, доработку и улучшение AGENTS.md, потому что в долгосрочной перспективе это принесет вам пользу.

Если не стоит помещать все в AGENTS.md, то как изменить поведение агента или модели?

Первый – это хуки. Они отлично подходят для того, что люди добавляют в AGENTS.md, например для запуска линтера после написания кода.

// settings.json

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

Это может быть крючок.

Хук – это событие, на которое можно подписаться. Агент предоставляет доступ ко всем таким событиям. Они охватывают практически все, что только можно придумать, но основные – это начало сеанса, завершение сеанса, чтение и запись файлов.

Поэтому вместо того, чтобы писать внизу AGENTS.md "всегда запускай линтер" или "всегда запускай набор тестов, прежде чем сказать, что все готово", вы просто используете хук остановки, который может запустить детерминированный скрипт, и это помогает обуздать небольшую случайность ИИ.

Ещё один пример: если у вас есть файлы, которые вы не хотите, чтобы агент мог читать или записывать, например, файл с секретами, вы не хотите, чтобы он отправлялся на сервер, или AGENTS.md, вы не хотите, чтобы агент мог в него писать, вы можете использовать для этого хук.

У вас есть хук чтения или записи, вы получаете файл, который он пытается отредактировать, и можете просто вернуть "Нет, вы не можете этого сделать".

Это просто способ добавить детерминизм.

Следующий – навыки.

И есть навыки, которые превращают ваши AGENTS.md в крючки.

Это совсем другое дело.

Но навыки позволяют добавлять контекст только тогда, когда это необходимо.

Поэтому AGENTS.md подходит для того, что актуально всегда.

Навыки нужны для определенных ситуаций, в основном для работы с документами.

Навыки состоят из трех частей: у них есть название, описание (это важная часть, описание ограничено 1024 символами) и тело.

---

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

Тело может быть огромным, оно может даже включать другие скрипты, что довольно распространено.

Навыки позволяют делать многое.

Рассмотрим пример.

Это описание Android CLI.

Вам не нужно читать все это.

Просто знайте, что это краткое описание того, когда Android CLI актуален.

А это тело.

Он огромный, поэтому мы не хотим загружать все это постоянно, верно?

Мы хотим загружать его только тогда, когда пытаемся использовать Android CLI, и именно это позволяет нам делать навык.

Но важно тщательно выбирать навыки, которые вы устанавливаете.

Мы не хотим просто слепо устанавливать эти репозитории, которые мы видим в интернете, которые представляют собой сотни агентских инженерных навыков.

Во-первых, это огромный риск для безопасности.

Вы не знаете, что в них содержится. Они могут заставить вашего агента сделать что угодно.

У нас есть набор навыков для Android, и я обещаю, что мы их проверили, они не говорят этого.

Но во-вторых, 100 описаний по 1000 символов – это 100 000 символов,которые вы добавили ещё до того,как начали писать код.

То есть вы уже приближаетесь к этому окну.

Поэтому мы рекомендуем установить базовый навык Android CLI, а затем с его помощью найти и установить навыки, которые подходят для вашего приложения.

> android init

✓ Installed base skill: android-cli

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

Или, если вы все же заглянете, полезно знать, какие навыки доступны. Вы можете вручную добавить те, которые имеют смысл для вашего проекта, например навыки Compose, навыки edge-to-edge, они довольно универсальны.

Конечно, есть навыки для аудита навыков.

В Claude Code есть команда /skill-doctor. Она позволяет посмотреть, какие навыки вы включили, но не активировали, то есть просто потратили место в описании.

Если вы не используете Claude Code, то практически в любой агентной обвязке есть экран со статистикой или аудитом, где можно посмотреть то же самое.

Вот ссылка на Android CLI.

Но у него есть команда списка навыков, и, скажем, у вас в проекте есть Навигация 3.

android skills list
android skills add navigation-3

Navigation 3 – это новая библиотека, поэтому она ещё не очень хорошо обучена. Вы можете добавить навык Navigation 3.

Мы часто Ой, извините.

Следующий – MCP.

Но нас часто спрашивают, почему мы сделали Android CLI интерфейсом командной строки, а не сервером MCP.

Мы создавали интерфейсы командной строки задолго до появления ИИ и даже до появления мыши. Они быстрые, компонуемые и, поскольку они работают локально в сеансе оболочки, их запуск фактически бесплатен.

Кроме того, такие тесты, как Terminal Bench, стали самыми важными в области разработки ПО, поэтому создатели моделей активно работают над использованием терминалов, и сейчас они действительно хорошо справляются с CLI.

Но это не значит, что MCP не нужен.

MCP-серверы отлично подходят для внешних сервисов, которые вы уже используете, особенно если они уже размещают MCP-сервис.

Вы можете подключиться к нему напрямую и получить дополнительный контекст для агента без установки.

Такие сервисы, как GitHub, Figma и Slack, уже предоставляют MCP-серверы.

А то, что мы всегда запускали в оболочке, может там и оставаться. Например, команды Android через Android CLI, а также Perfetto и Gradle. Имеет смысл запускать их локально, где у них есть доступ ко всему, что вы используете при разработке.

И я работал над производительностью.

Раньше я всегда говорил, что Perfetto – это единственный инструмент, который нужен для решения любых проблем с производительностью.

Но кривая обучения была очень крутой, как мы только что видели в последнем докладе Рахула.

Давайте посмотрим, как ИИ может помочь повысить эффективность.

Спасибо, Богдан.

Чтобы наше приложение Sideline работало, оно должно работать со скоростью 30 кадров в секунду и в режиме реального времени.

Как видите, на Pixel 10 Pro Fold мы получаем только 20–22 кадра в секунду.

Эти пропущенные кадры станут проблемой, потому что это означает, что приложение не будет работать так, как рекламируется, поэтому нам действительно нужно это исправить.

В Android CLI есть команды профилировщика Android.

И когда мы добавляем его в наш агент кодирования и поручаем ему выполнить это требование в 30 кадров в секунду, происходят две интересные вещи.

Первый – найти решение с помощью команды профилировщика Android.

Она записала трассировки системы на подключенном устройстве Pixel 10 Pro Fold и обнаружила, что потоки ИИ выполнялись на самых медленных ядрах.

И второе: он использовал поиск по документации Android, что интересно, без нашего явного запроса, и извлек официальное руководство по Performance Hint API.

Агент научился оптимизировать системное расписание и за счёт этого смог выполнить требование в 30 кадров в секунду.

По сути, исправление было выполнено в соответствии с рекомендациями.

Итак, с Android CLI ключ, вы знаете, через подключение его к вашему агенту, он помогает вам найти правильный инструмент, даже если вы не знакомы с этим инструментом, для любой работы, которую вам нужно выполнить.

Запустив его, мы видим, что Sideline соответствует требованию пользователей в 30 кадров в секунду и теперь работает на Pixel 10 Pro Fold.

Теперь

Теперь мы объединим всё это с помощью циклов.

Думаю, все мы так делали: просили агента внести какое-то большое изменение, а он возвращался и говорил, что все готово.

Если вы устанавливаете приложение и вручную нажимаете на кнопки, а затем записываете ошибки, то это как раз то, от чего нужно отказаться.

Нам нужно перестать быть тестировщиками контроля качества нашего агента и заранее определить, что мы считаем выполненным.

Вот пример.

Мы хотим перенести весь проект на Nav3. Агент уходит, и через некоторое время возвращается и говорит: "Перенос завершен.

Я лучший".

Но потом, конечно, вы поворачиваете телефон, приложение падает, оно пропустило все переходы между слайдами, оно не очистило свой файл Gradle.

Это похоже на мир, в котором мы сейчас живем.

В идеале этого не должно быть, но такова реальность.

Поэтому нам следовало сначала определить все это, чтобы агент мог работать до тех пор, пока не будут выполнены все эти критерии.

Это и есть цикл проверки.

У нас есть убедительные данные об эффективности такого подхода.

Это Android Bench 2.0 – новая версия нашего теста производительности ИИ, о котором я упоминал в начале выступления.

Сейчас экзамен сдают около 40 % кандидатов.

Эти задачи действительно сложные, масштабные и реалистичные. Одна из них – переход с Nav2 на Nav3. Это как раз то, чем вы сейчас занимаетесь в своих проектах.

Если мы возьмем Fable 5.1, его показатель успешности составляет 22%, это то, что он получает только с естественной настройкой подсказки, например "перенести Nav2 в Nav3".

Но если мы заранее дадим ему набор тестов, который не проходит, то есть не дадим ему ответы, не расскажем, как перейти на Nav3, а просто дадим ему набор тестов, который уже не проходит и пройдет, когда все эти вещи будут завершены, его показатели прохождения по всему бенчмарку подскочат до 90%.

Это показывает, что модели уже способны выполнять практически любые задачи на Android, но не всегда понимают, что значит "готово".

И поэтому вам не нужно заранее писать полный набор тестов, которые не пройдут.

Циклы проверки могут быть такими же простыми, как добавление подсказок.

Например, если вы работаете над интерфейсом, вы можете попросить Gemini отобразить предварительный просмотр Compose, убедиться, что он соответствует спецификации Figma, и показать вам результаты.

Похоже, это действительно работает, когда вы просите его показать вам результаты и доказать, что это было сделано, а не просто принимаете текстовый ответ: "Я закончил".

Если вы работаете над бизнес-логикой, вы можете попросить его запустить модульное тестирование. Или, как мы видели в начале, если вы работаете над исправлением сбоя, вы можете попросить его проверить, исправлен ли сбой на реальном устройстве, на котором он произошел, через удаленную тестовую лабораторию.

В Claude Code есть встроенный навык, который помогает создавать циклы проверки.

Обязательно ознакомьтесь с ними.

А если вы работаете в Android Studio с собственным агентом, Android Studio предоставляет целый ряд инструментов, вокруг которых вы можете создавать циклы в зависимости от того, над чем вы работаете.

Например, вы можете попросить его не останавливаться, пока не будут исправлены все ошибки линтера. Или, что мне нравится больше всего, вы можете попросить его запустить ваши пути и убедиться, что они по-прежнему работают.

Или, если вы написали путь, а это довольно просто, потому что это просто подсказки о функции, над которой вы работаете, вы можете сказать ему запустить этот путь и убедиться, что он проходит, прежде чем объявить себя выполненным.

Но на выполнение путей требуется время.

Вы также можете разделить цикл проверки на уровни.

Поэтому мы можем попросить его сначала убедиться, что модульное тестирование и предварительные просмотры Compose отображаются правильно.

Если все в порядке, запустите подключенные тесты и Android Journeys. И только если они пройдут успешно, запустите полный набор тестов в лаборатории удаленных устройств, который займет несколько часов.

Если вы предоставите эту дополнительную информацию, мы обнаружим, что она зацикливается на каждом уровне, а не пытается выполнить каждый шаг при каждом запуске.

Потому что модели очень уверены в себе.

Поэтому они всегда думают, что они завершены, и они всегда думают, что они пройдут все тесты с первого раза.

Давайте посмотрим, как это выглядит в Sideline.

Давайте применим эту идею к нашему приложению Sideline и добавим новую функцию, специально для XR-очков, которые скоро появятся.

Поскольку у нас пока нет оборудования, мы будем использовать эмулятор XR и поручим нашему агенту кодирования расширить Sideline для нового форм-фактора.

В этом случае мы попросим агентов выполнить тесты JVM, Compose Preview и эмулятора именно в таком порядке.

И каждый цикл должен основываться на предыдущем.

И когда мы это делаем, первое, что мы замечаем, это то, что между первым и вторым циклами для определения шести состояний предварительного просмотра Compose используются тесты JVM.

Конечно, эмулятор не вызывался, поэтому он работает очень быстро.

Аналогично, между вторым и третьим циклами выявляются и устраняются такие проблемы, как длинные строки, ещё до запуска эмулятора.

Наконец, когда цикл эмулятора запускается, он находит дополнительные ошибки, которые не удалось исправить с помощью теста JVM и предварительного просмотра Compose.

Но по сути, с каждым циклом мы дополнительно укрепляем наше приложение, и мы хотим сначала запустить самые быстрые, но наименее мощные циклы, а затем самые медленные, но самые мощные.

Вот что получилось.

На нем показано, что очки теперь показывают тип замаха и скорость мяча, отлетающего от ракетки, так что вы можете играть в теннис и получать обратную связь о своем игровом процессе в режиме реального времени, не отрывая глаз от мяча.

Ранее я упоминал, что мы вернемся к двум проблемам Crashlytics, которые возникли ранее.

Поскольку мы уже убедились, что этот подход работает, мы можем использовать команду /schedule в Claude Code, чтобы зациклить его, и мы можем установить любую периодичность, какую захотим, так что теперь у нас есть самовосстанавливающееся приложение, которое исправляет все ошибки и проверяет, что они исправлены, отправляет их в виде pull-запросов нашим инженерам для ознакомления и слияния.

то идем дальше.

На сегодня это все.

Если вы хотите вынести из этого доклада одну ключевую мысль, то вот она: начните думать о мире, в котором мы создаем среду для успешной работы агентов, и относитесь к этому так же, как мы сегодня относимся к разработке программного обеспечения и исправлению ошибок.

Так мы разблокируем параллельных агентов.

В интернете вы найдете множество советов на эту тему, и многие из них будут противоречить друг другу.

Такова реальность этой быстро меняющейся среды.

Поэтому лучше всего написать собственные оценки для своего проекта.

И когда появляются новые рекомендации или новая модель, вы можете измерить ее эффективность и понять, помогает ли она вам.

И, конечно, для всего нужен навык.

В Claude Code есть навык, который помогает создавать оценки.

/claude-api build-eval

Рекомендую ознакомиться с ними.

Сегодня я рассказал об Android Bench.

Android Bench – это наша оценка.

Это позволяет нам оценивать, насколько хорошо мы справляемся с задачей.

Если вы хотите узнать, какие уроки мы извлекли из этого процесса, чтобы не повторять наших ошибок, посмотрите доклад об Android Bench.

Также есть две панели.

Один в США, другой в Лондоне.

Оба видео будут опубликованы в интернете и будут рассказывать о том, как эта концепция применяется на практике в сообществе.

Поэтому мы пригласили участников сообщества Android Dev, чтобы они рассказали, как применяют эти принципы на практике.

Нам также очень важно ваше мнение.

Нам важно знать, действительно ли наши продукты помогают вам.

Пожалуйста, заполните опрос.

Я оставлю это на экране.

И да,

Благодарю за внимание.

Спасибо!