Inżynieria agentowa z Claude Code i interfejsem wiersza poleceń Androida

Cześć, nazywam się Ben i pracuję w zespole ds. relacji z programistami aplikacji na Androida.

Nazywam się Steven i jestem menedżerem produktu.

Dzisiaj porozmawiamy o tworzeniu aplikacji za pomocą Claude Code i interfejsu wiersza poleceń Androida w sposób agentowy.

Można więc powiedzieć, że nasza rola jako deweloperów nieco się zmienia, a zmiany zachodzą bardzo szybko. Tak szybko, że, szczerze mówiąc, treść tej prezentacji jest już prawdopodobnie nieaktualna, zwłaszcza jeśli oglądasz ją online.

Dlatego w naszych tekstach i prezentowanych informacjach przyjęliśmy perspektywę przyszłościową, ale wersje demonstracyjne, które dziś uruchamiają, są oparte na rzeczywistości, więc powinny być teraz niezawodne.

W tej rozmowie użyliśmy Claude Code, ale informacje są niezależne od agenta.

To raczej sposób myślenia, więc powinien mieć zastosowanie do dowolnego narzędzia, którego wolisz używać podczas tworzenia aplikacji.

Dlatego chcemy, abyście zaczęli myśleć o świecie, w którym zarządzacie zespołami autonomicznych agentów, i o tym, jak zapewnić im sukces.

Gdy nie uda się wdrożyć funkcji lub czegoś podobnego, zamiast poddawać się i mówić: „AI jeszcze tego nie potrafi”, musimy się cofnąć i zastanowić, jakich informacji brakowało, i potraktować to tak, jak traktujemy błędy.

Jeśli czytaliście artykuły zespołów, które tworzą te uprzęże agentów, Claude Code, Codex, Antigravity, zobaczycie, że właśnie w ten sposób ich zespoły je rozwijają. Jeśli spojrzymy na nie jak na przebłysk przyszłości, to prawdopodobnie tam właśnie zmierzamy.

To chyba najbardziej ekscytujący czas dla twórców i programistów aplikacji na Androida. Jeśli jednak jesteście tacy jak ja, możecie mieć trudności z określeniem, na czym dokładnie się skupić.

My, deweloperzy, potrzebujemy narzędzi i przepływów pracy, które naprawdę skalują się wraz z AI, aby po wprowadzeniu nowego modelu nasza ciężka praca nie poszła na marne.

Chcemy, aby każde ulepszenie modelu prowadziło do bardziej inteligentnych przepływów pracy dla naszych agentów, co ostatecznie przełoży się na lepsze wyniki dla naszych użytkowników.

Omówimy dziś 4 tematy.

Najpierw wyjaśnimy, dlaczego tak ważne jest skonfigurowanie agentów w środowiskach, które pozwolą im odnieść sukces.

Następnie omówimy kontekst i najlepsze sposoby zarządzania nim.

Następnie omówimy niektóre z najlepszych narzędzi dostępnych dla deweloperów aplikacji na Androida, którzy pracują z agentami, a na koniec przedstawimy argumenty za dodaniem pętli do przepływów pracy agentów.

Zaczynajmy.

Środowisko.

Co to jednak oznacza w praktyce?

Well, it's like I was saying, we're trying to create a space where our agent can succeed, and can succeed without you having to sit there and constantly, like, re-prompt it and put it back on track, because when you do that, that's when you unlock being able to run parallel agents, and that's where, like, the real productivity gains come in, when you can have these teams of agents all doing your work for you.

Ale to nie tylko kwestia dostępu do kodu.

Potrzebują dostępu do dokładnej dokumentacji, która zawiera specyfikacje projektu i zasady pracy nad nim.

To dość oczywiste.

Niektórzy użytkownicy łączą teraz swojego agenta z pokojem czatu zespołu, nie tylko po to, aby uruchamiać agentów, ale też po to, aby zapewnić kontekst dotyczący sposobu podejmowania decyzji, które doprowadziły do powstania funkcji, nad którą mają pracować. Jako deweloper używasz tego rodzaju podświadomych informacji podczas rozwiązywania problemów, więc może to być pomocne również dla Twojego agenta.

Możesz też sprawdzić historię poprzednich decyzji i żądań pull.

Powinni widzieć komentarze, które otrzymujesz do swoich żądań pull, rzeczy, o których są powiadamiani, i inne tego typu informacje. Dzięki temu będą mogli pracować nad tymi kwestiami i je rozwiązywać.

Nie można oczekiwać, że będzie można pisać kod na Androida bez dostępu do urządzenia lub emulatora, więc nie należy oczekiwać, że agent będzie w stanie to zrobić.

Wiem, że wydają się niesamowite i że mogą zrobić wszystko, ale emulator naprawdę pomaga.

To samo dotyczy profilerów.

Jeśli chcesz, aby pracowali nad wydajnością, powinni mieć możliwość profilowania, co wymaga dostępu do prawdziwego urządzenia.

Agent powinien też móc komunikować się z usługami backendu, z których korzysta aplikacja.

I tu właśnie wkracza interfejs wiersza poleceń Androida.

Jeśli jeszcze o nim nie słyszeliście, wspominaliśmy o nim w prelekcji „Co nowego w narzędziach”. Android CLI to nasz nowy interfejs wiersza poleceń Androida do obsługi różnych narzędzi na Androida.

Nie jest to usługa AI, tylko interfejs wiersza poleceń.

Zapewnia dostęp do takich narzędzi jak Android SDK Manager, umożliwia uruchamianie emulatorów i wykonywanie wielu innych czynności.

Łączy się też z narzędziami i backendami, takimi jak Crashlytics.

Działa z każdym agentem, którego używasz, i znajduje się w przestrzeni powłoki.

No więc tak.

Możesz ją zainstalować, klikając ten link, ale myślę, że łatwiej będzie, jeśli po prostu zobaczymy, jak działa.

OK.

Zamiast więc po prostu wyjaśniać, dlaczego tak ważne jest, aby agenci byli skuteczni, chcieliśmy zastosować tę zasadę w praktyce w aplikacji produkcyjnej o nazwie Sideline.

Sideline to aplikacja na Androida dla tenisistów, która dostarcza im informacji w czasie rzeczywistym o lokalizacji piłki, gracza i kortu.

Zapewnia wskazówki treningowe offline za pomocą powtórek wideo oraz dane o aktywności fizycznej, takie jak maksymalna prędkość, przebyty dystans i najdłuższe wymiany.

Wszystko to jest możliwe dzięki niestandardowym modelom TF Lite działającym bezpośrednio na urządzeniu z Androidem.

Przede wszystkim chcę powiedzieć, że nie możemy rozwiązać problemów, o których nie wiemy.

Dlatego za pomocą interfejsu wiersza poleceń Androida dodaliśmy Firebase Crashlytics do naszego środowiska programistycznego, co pozwoliło nam znaleźć problemy, o których nawet nie wiedzieliśmy.

Pierwszy z nich dotyczył błędu „Aplikacja nie odpowiada” (ANR) na urządzeniu Pixel 11 Pro Fold, którego nie udało się odtworzyć w emulatorze.

Na szczęście interfejs wiersza poleceń Androida obsługuje strumieniowe przesyłanie danych z urządzenia z Androidem.

Gdy poprosiliśmy agenta o rozwiązanie tego problemu, utworzył on połączenie z urządzeniem, na którym wystąpił błąd ANR. Było to dla mnie szczególnie przydatne, ponieważ nie miałem wtedy Pixela 11 Pro Fold, na którym mógłbym sprawdzić, czy poprawka działa.

Dzięki temu, że agent mógł uzyskać dostęp do urządzenia, na którym musiał sprawdzić, czy problem został rozwiązany, udało nam się rozszerzyć zakres możliwości.

Aby zaoszczędzić czas, przeprowadziłem wszystkie eksperymenty wcześniej i podsumowałem je tutaj.

Bez wchodzenia w szczegóły – problem, który mieliśmy, dotyczył wywołania podobieństwa związanego z Androidem 17.

Była to szybka poprawka składająca się z 2 wierszy, która wyglądała dobrze.

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

Utworzyłem więc żądanie pull, scaliłem je i zaktualizowałem, przesyłając nową kompilację do Google Play.

Gdybyśmy nie skonfigurowali środowiska kodowania z funkcjami, które były potrzebne do osiągnięcia sukcesu, nie moglibyśmy zidentyfikować rzeczywistego problemu ani zweryfikować poprawki.

W kompilacjach 1.0 problem został rozwiązany.

Pojawiły się jednak nowe problemy, które omówimy później.

OK.

Następny element: kontekst.

Około 1,5–2 lata temu, czyli nie tak dawno, ale w przestrzeni AI to cała wieczność, trwał wyścig o coraz większe okna kontekstu. Teoria była taka, że im więcej informacji przekażemy modelowi, tym lepsze wyniki uzyskamy. Robiliśmy szalone rzeczy, np. próbowaliśmy umieścić w prompcie całą witrynę developer.android.com, ale to nie zadziałało.

Jednak mimo że okna kontekstu w dużej mierze się ustabilizowały, możliwości modeli nadal rosną.

To jest Android Bench 1.0.

Android Bench to nasz test porównawczy, który ocenia zdolność AI do pisania kodu na Androida.

Zadania są realistyczne.

To są rzeczy, nad którymi pracujesz. Widzimy, że okna kontekstu zatrzymały się na poziomie 1 miliona, ale możliwości modelu nadal rosną.

Ale kontekst jest taki, że budżet jest stały i chcesz go przeznaczyć na to, co ważne.

Nie chcesz, aby znajdowały się tam rzeczy, które nie pomagają w rozwiązaniu problemu, nad którym pracujesz.

Wiele uprzęży agentów nie udostępnia pełnego okna kontekstu o rozmiarze 1 miliona, ponieważ uznają, że nie ma to sensu.

Wyniki są wtedy tylko gorsze.

Istnieje optymalny zakres, który różni się w zależności od modelu, ale jeśli uda się utrzymać rozmowy na poziomie około 150 000 tokenów, można wykorzystać pełną moc modelu bez utraty kontekstu.

Kontekst to jednak nie tylko to, co wpisujesz.

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

W rzeczywistości za kulisami dzieje się o wiele więcej, niż widać na pierwszy rzut oka.

Składa się z kilku części.

Pierwsza to instrukcja systemowa.

Instrukcje systemowe są dostarczane przez agenta.

To coś w rodzaju prompta, który mówi, jak pracować z tym agentem i jakie zachowania powinien on wykazywać.

ale też informacje o obszarze roboczym, np. bieżący katalog roboczy, pakiety SDK, zainstalowane umiejętności (o których za chwilę opowiem), narzędzia MCP i narzędzia udostępniane przez agenta.

Model musi wiedzieć, że może je wywołać, co zajmuje kontekst.

Najważniejsze jest jednak to, że cała historia wiadomości i wywołań narzędzi jest wysyłana z każdym promptem i każdą nową wiadomością, którą wysyłasz do agenta.

Może to być bardzo uciążliwe, zwłaszcza w przypadku Gradle.

Jak wszyscy wiemy, logi Gradle są bardzo długie i szczegółowe.

Większość z nich nie jest wymagana.

Warto o tym pamiętać.

Możesz uruchomić Gradle w trybie cichym.

./gradlew assembleDebug --quiet

Możesz też użyć większych uprzęży agenta, które przytną te dane za Ciebie.

Dlatego w przypadku Claude Code i Android Studio nie wysyłamy pełnego dziennika Gradle.

Jeśli jednak używasz jednego z minimalnych agentów, których cała filozofia polega na wysyłaniu wszystkiego do modelu, ponieważ model wie najlepiej, mini-SWE-agent wysyła cały log Gradle, co może szybko stać się bardzo kosztowne.

Ale jak utrzymać się w tym magicznym przedziale 150 tysięcy?

Kluczem jest użycie przepływu pracy.

Istnieje wiele różnych przepływów pracy.

Bardzo podoba mi się seria Matta Pococka, który przedstawia szereg umiejętności pomagających zarządzać tymi sesjami.

Zaczyna się od umiejętności „grill-me”.

Uruchom tę umiejętność, gdy zaczynasz cały projekt lub tylko nową funkcję w projekcie, a agent zada Ci kilka pytań.

Możesz więc powiedzieć „Zadaj mi pytania”.

Chcę utworzyć w aplikacji na przykład nowego menedżera alarmów”.

Zacznie zadawać Ci pytania, np. w czym powinniśmy to zaimplementować, gdzie to pasuje.

Dzięki temu nie ma już żadnych niejasności, a problem jest jasno sformułowany.

Następnie uruchamiamy kolejną umiejętność, która polega na napisaniu obszernego dokumentu ze specyfikacją.

Inna umiejętność dzieli je na problemy, które następnie zapisujemy w wybranym przez Ciebie menedżerze problemów.

Każdy z tych problemów powinien mieścić się w oknie 150 tys.

Następnie wybierasz jeden problem, nad którym pracujesz w terminalu lub IDE, zależnie od preferencji, tworzysz, weryfikujesz pętlę, na koniec czyścimy kontekst, nie ma już historii rozmów i pozostajemy w oknie.

OK.

Przejdźmy do AGENTS.md.

AGENTS.md to miejsce, w którym możesz podać dodatkowe informacje dla agenta, które dotyczą problemu, nad którym pracuje w tym projekcie lub w całym obszarze roboczym, jeśli tak zdecydujesz.

Ponieważ jednak jest on podawany w każdym prompcie, ważne jest, aby zawierał tylko te informacje, które mają zastosowanie w każdej sytuacji.

Dlatego sprawdzają się takie rzeczy jak reguły dotyczące architektury i modułów.

Są to rzeczy, których agent nie mógłby wiedzieć, zwłaszcza jeśli pracujesz nad aplikacją z oprogramowaniem zamkniętym.

ale warto je poznać, aby na początku nie zastanawiać się, gdzie znajduje się dana funkcja.

Możesz więc umieścić w module systemu projektowania takie elementy jak komponenty interfejsu. Innym rozwiązaniem, które sprawdza się bardzo dobrze, są typowe błędy w inspekcji kodu lub po prostu typowe rzeczy, które musisz cały czas wpisywać.

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

W tym projekcie wolimy używać kotlinx.datetime i tak dalej.

Chciałem podać sprawdzone metody, które zawsze się sprawdzają, ale w rzeczywistości zmieniają się one z każdą nową wersją modelu.

Różne modele zachowują się inaczej, jeśli chodzi o dodatkowy kontekst.

Na przykład w czasach Opus 4.6 bardzo często używano wielkich liter, aby napisać „Nigdy tego nie rób”.

Gdy pojawił się Opus 5, Anthropic wydał oświadczenie: „Właściwie wielkie litery już nie działają tak dobrze.

Używaj tylko małych liter”.

Oto co mam na myśli: musisz być na bieżąco.

Jednak niektóre rzeczy, które są dość uniwersalne, to krótka forma.

Dlatego nie przekraczaj 250 wierszy.

Kolejna kwestia jest nieco kontrowersyjna, bo wiem, że wiele osób lubi to robić, ale w lutym tego roku opublikowano badanie, które wykazało, że jeśli pozwolisz agentowi modyfikować własne AGENTS.md, wydajność spada o około 2–3%, co nie jest aż tak istotne.

ale najważniejsze jest to, że koszty wzrosły o 20%.

W rezultacie odnotowaliśmy niewielki spadek wydajności i znaczny wzrost kosztów, a wszystko to przez pozwolenie agentowi na samodzielne pisanie AGENTS.md.

Można to obejść, prosząc agenta o napisanie podsumowania na końcu każdego żądania pull. Następnie zespół może je wspólnie przeczytać i zdecydować, jakie zmiany wprowadzić. Ten plik staje się kluczowym elementem infrastruktury zespołu, jeśli pracujesz w dużych zespołach z agentami.

Oto AGENTS.md aplikacji Sideline, którą stworzyliśmy.

Chcę zwrócić uwagę na 2 kwestie.

Po pierwsze, jasno zdefiniowana architektura pozwoli Ci zaoszczędzić tokeny i skrócić długość kontekstu.

Zasadniczo pozwala to agentowi uniknąć konieczności ciągłego sprawdzania bazy kodu i wyciągania coraz większej liczby wniosków.

Zapewnia bardzo jasno określone wytyczne, których należy przestrzegać.

Druga kwestia, którą chcę poruszyć, dotyczy aplikacji z zamkniętym kodem źródłowym.

Oczywiście, jeśli masz oprogramowanie zamknięte, żaden z agentów nie był w stanie wytrenować LLM na Twojej bazie kodu.

W takich przypadkach szczególnie ważne jest, aby poświęcić dodatkowy czas i regularnie czyścić, sprawdzać, dopracowywać i ulepszać AGENTS.md, ponieważ na dłuższą metę przyniesie to korzyści.

Jeśli nie powinniśmy umieszczać wszystkiego w polu AGENTS.md, jak możemy zmienić zachowanie agenta lub modelu?

Pierwszy z nich to hooki, które świetnie nadają się do rzeczy, które ludzie umieszczają w AGENTS.md, np. „zawsze uruchamiaj linter po zakończeniu pisania”.

// settings.json

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

To może być haczyk.

Twój agent udostępnia wszystkie te zdarzenia, które możesz subskrybować. Są one związane z praktycznie wszystkim, co przyjdzie Ci do głowy, ale najważniejsze z nich to rozpoczęcie sesji, zatrzymanie sesji oraz odczyt i zapis plików.

Zamiast więc pisać na dole pliku AGENTS.md „zawsze uruchamiaj linter” lub „zawsze uruchamiaj zestaw testów, zanim powiesz, że skończyłeś”, masz punkt zatrzymania, który może uruchomić deterministyczny skrypt, co pomaga ograniczyć niewielką losowość AI.

Inny przykład: jeśli masz pliki, których agent nie powinien odczytywać ani zapisywać, np. pliki z tajnymi informacjami, których nie chcesz wysyłać na serwer, lub AGENTS.md, do których agent nie powinien mieć możliwości zapisu, możesz użyć do tego punktu zaczepienia.

Jeśli masz hook odczytu lub zapisu, otrzymujesz plik, który próbuje edytować, i możesz po prostu zwrócić komunikat „Nie, nie możesz tego zrobić”.

To tylko sposób na dodanie determinizmu.

Kolejny element to umiejętności.

Są też umiejętności, które pozwalają przekształcić AGENTS.md w haki.

To zupełnie inna sprawa.

Jednak umiejętności pozwalają dodawać kontekst tylko wtedy, gdy jest to istotne.

AGENTS.md jest więc przeznaczony do rzeczy, które są zawsze aktualne.

Umiejętności dotyczą rzeczy, które są istotne w określonych sytuacjach, głównie w dokumentacji.

Umiejętności składają się z 3 części: nazwy, opisu (to ważna część, która może mieć maksymalnie 1024 znaki) i treści.

---

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

Treść może być bardzo długa i może nawet zawierać inne skrypty, co jest dość powszechne.

Umiejętności dają wiele możliwości.

Przeanalizujmy to na przykładzie.

To jest opis interfejsu wiersza poleceń Androida.

Nie musisz tego wszystkiego czytać.

To krótki opis, który wyjaśnia, kiedy interfejs wiersza poleceń Androida jest przydatny.

A to jest treść.

Jest ogromny, więc nie chcemy go wczytywać za każdym razem, prawda?

Chcemy go wczytywać tylko wtedy, gdy próbujemy użyć interfejsu wiersza poleceń Androida, i to właśnie umożliwia nam umiejętność.

Ważne jest jednak, aby ostrożnie dobierać instalowane umiejętności.

Nie chcemy po prostu instalować repozytoriów, które widzimy online i które zawierają setki umiejętności inżynieryjnych agentów.

Po pierwsze, stanowi to ogromne zagrożenie dla bezpieczeństwa.

Nie masz pojęcia, co zawierają te umiejętności. Mogą one nakazywać agentowi wykonanie dowolnego działania.

Mamy zestaw umiejętności Androida, które sprawdziliśmy i które nie mówią takich rzeczy.

Po drugie, 100 opisów po 1000 znaków to 100 000 znaków,które zostały dodane,zanim jeszcze zaczęliśmy kodować.

Więc już zbliżasz się do tego okna.

Dlatego w przypadku umiejętności Androida zalecamy zainstalowanie podstawowej umiejętności interfejsu wiersza poleceń Androida, która może wyszukiwać dostępne umiejętności i instalować te, które są odpowiednie dla Twojej aplikacji.

> android init

✓ Installed base skill: android-cli

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

Jeśli jednak chcesz, możesz sprawdzić, jakie umiejętności są dostępne, i ręcznie dodać te, które przydadzą się w Twoim projekcie, np. umiejętności związane z Compose czy wyświetlaniem od krawędzi do krawędzi, które są dość uniwersalne.

Oczywiście istnieją umiejętności, które można sprawdzić.

W Claude Code jest /skill-doctor, który sprawdzi i poda Ci, jakie umiejętności uwzględniasz, które nigdy nie są aktywowane, więc marnujesz ten opis o długości 1000 znaków.

Jeśli nie korzystasz z Claude Code, prawie każda uprząż agenta ma jakiś ekran statystyk lub audytu, który działa podobnie.

Link do interfejsu wiersza poleceń Androida znajdziesz tutaj.

Ma jednak polecenie listy umiejętności, a w projekcie masz Navigation 3.

android skills list
android skills add navigation-3

Navigation 3 to dość nowa biblioteka, więc nie ma jeszcze wielu materiałów szkoleniowych na jej temat. Możesz dodać umiejętność Navigation 3.

We often Oh, sorry.

Kolejny to MCP.

Często jednak otrzymujemy pytania, dlaczego interfejs wiersza poleceń Androida jest interfejsem wiersza poleceń, a nie serwerem MCP.

Interfejsy wiersza poleceń tworzyliśmy na długo przed pojawieniem się AI, a nawet myszy komputerowej. Są szybkie, można je łączyć, a ponieważ działają lokalnie w sesji powłoki, ich uruchamianie jest bezpłatne.

Ponadto testy porównawcze takie jak Terminal Bench stały się najważniejszymi testami porównawczymi w inżynierii oprogramowania, więc twórcy modeli intensywnie pracują nad korzystaniem z terminala, dzięki czemu modele są obecnie bardzo dobre w używaniu interfejsów wiersza poleceń.

Nie oznacza to jednak, że MCP nie ma zastosowania.

Serwery MCP świetnie sprawdzają się w przypadku usług zewnętrznych, z których już korzystasz, zwłaszcza jeśli hostują już usługę MCP.

Możesz połączyć się z nim bezpośrednio i bez instalowania uzyskać dodatkowy kontekst dla agenta.

Serwery MCP są teraz udostępniane przez takie usługi jak GitHub, Figma czy Slack.

Z kolei rzeczy, które zawsze uruchamialiśmy w powłoce, mogą w niej pozostać, więc polecenia Androida przez interfejs wiersza poleceń Androida, ale też Perfetto i Gradle, warto mieć lokalnie, gdzie mają dostęp do wszystkiego, czego używasz podczas programowania.

Kiedyś zajmowałem się wydajnością.

Zawsze powtarzam, że Perfetto to jedyne narzędzie, którego potrzebujesz, aby rozwiązać każdy problem z wydajnością.

Jednak krzywa uczenia się była bardzo stroma, co widzieliśmy w ostatniej prezentacji Rahula.

Zobaczmy, jak AI może pomóc zwiększyć skuteczność.

Dzięki, Ben.

Aby nasza aplikacja Sideline działała, musi działać z szybkością 30 klatek na sekundę i w czasie rzeczywistym.

Jak widać na tym Pixelu 10 Pro Fold, uzyskujemy tylko około 20–22 klatek na sekundę.

Te pominięte klatki będą stanowić problem, ponieważ oznacza to, że aplikacja nie będzie działać zgodnie z reklamą, więc naprawdę musimy to naprawić.

W interfejsie wiersza poleceń Androida dostępne są polecenia profilera Androida.

Gdy dodamy go do naszego agenta kodującego i poinstruujemy go, aby spełnił wymaganie 30 klatek na sekundę, dzieją się 2 ciekawe rzeczy.

Pierwszy z nich polega na znalezieniu rozwiązania za pomocą polecenia Android Profiler.

Zarejestrowała śledzenie systemu na podłączonym urządzeniu Pixel 10 Pro Fold i odkryła, że wątki AI były uruchamiane na najwolniejszych rdzeniach urządzenia.

Po drugie, co ciekawe, bez naszej wyraźnej prośby użył wyszukiwarki dokumentacji Androida i pobrał oficjalne wytyczne dotyczące interfejsu Performance Hint API.

Agent nauczył się optymalizować harmonogram systemu, dzięki czemu był w stanie spełnić wymagania dotyczące 30 klatek na sekundę.

Zasadniczo rozwiązanie problemu było zgodne z wytycznymi.

Dzięki interfejsowi wiersza poleceń Androida i połączeniu z agentem możesz znaleźć odpowiednie narzędzie do wykonania danego zadania, nawet jeśli go nie znasz.

Po uruchomieniu aplikacji widać, że Sideline spełnia wymagania użytkowników dotyczące 30 klatek na sekundę i działa teraz na Pixelu 10 Pro Fold.

OK.

Teraz połączymy to wszystko za pomocą pętli.

Pewnie każdemu z nas zdarzyło się poprosić agenta o wprowadzenie dużej zmiany, a on po chwili poinformował, że zadanie zostało wykonane.

Jeśli instalujesz aplikację i ręcznie klikasz w niej różne elementy, a potem wpisujesz błędy, to właśnie tego musimy przestać robić.

Musimy przestać być testerami kontroli jakości naszych agentów i z góry określić, co uważamy za wykonane.

Oto przykład.

Chcemy przenieść cały projekt do Nav3, a potem agent znika. Trwa to chwilę, ale wraca i mówi: „Migracja zakończona.

Jestem najlepszy”.

Ale potem, oczywiście, obracasz telefon, aplikacja się zawiesza, nie ma wszystkich przejść slajdów, nie wyczyściła pliku Gradle.

To trochę jak świat, w którym obecnie żyjemy.

Idealnie byłoby, gdyby nie było to konieczne, ale taka jest obecna rzeczywistość.

Powinniśmy byli najpierw zdefiniować wszystkie nasze oczekiwania, co pozwoliłoby agentowi działać w pętli, dopóki nie spełniłby wszystkich kryteriów.

To jest właśnie pętla weryfikacji.

Mamy bardzo mocne dane na temat skuteczności tego rozwiązania.

To jest Android Bench 2.0, czyli nowa wersja naszego testu porównawczego AI, o którym wspomniałem na początku.

Współczynnik zdania wynosi obecnie około 40%.

Te zadania są naprawdę trudne, duże i realistyczne, ale jedno z nich, Nav2 do Nav3, to rodzaj zadań, które wykonujesz obecnie w swoich projektach.

Jeśli weźmiemy Fable 5.1, jego wskaźnik powodzenia wynosi 22% – tyle uzyskuje przy użyciu naturalnego prompta, takiego jak „przenieś Nav2 do Nav3”.

Jeśli jednak wcześniej dostarczymy mu zestaw testów, który nie działa, nie podając mu odpowiedzi ani nie mówiąc, jak przejść na Nav3, tylko dając mu zestaw testów, który już nie działa i będzie działać, gdy wszystkie te rzeczy zostaną ukończone, jego wskaźnik powodzenia w całym teście porównawczym wzrośnie do 90%.

To pokazuje, że te modele są teraz w stanie wykonać praktycznie każde zadanie na Androidzie, o jakim pomyślimy, ale nie zawsze wiedzą, co oznacza „gotowe”.

Nie musisz więc pisać z wyprzedzeniem całego zestawu testów, które zakończą się niepowodzeniem.

Pętle weryfikacji mogą być tak proste jak dodawanie promptów.

Jeśli na przykład pracujesz nad interfejsem, możesz poprosić o wyrenderowanie podglądu Compose i sprawdzenie, czy jest on zgodny ze specyfikacją Figmy, a następnie o wyświetlenie wyników.

Wydaje się, że to naprawdę działa, gdy poprosisz o pokazanie wyników i udowodnienie, że zadanie zostało wykonane, zamiast po prostu zaakceptować odpowiedź tekstową „Zrobione”.

Jeśli pracujesz nad logiką biznesową, możesz poprosić o uruchomienie testów jednostkowych. Jeśli natomiast pracujesz nad rozwiązaniem problemu z awarią, możesz poprosić o sprawdzenie, czy awaria została naprawiona na rzeczywistym urządzeniu, na którym wystąpiła, za pomocą zdalnego laboratorium testowego.

W Claude Code jest wbudowana umiejętność, która pomaga tworzyć pętle weryfikacji.

Warto więc się z nią zapoznać.

Jeśli pracujesz w Android Studio z własnym agentem, Android Studio udostępnia wiele narzędzi, wokół których możesz tworzyć pętle w zależności od tego, nad czym pracujesz.

Możesz na przykład poprosić o niezatrzymywanie się, dopóki nie zostaną naprawione wszystkie błędy lintera. Możesz też poprosić o uruchomienie ścieżek i upewnienie się, że nadal działają.

Jeśli masz już napisaną ścieżkę – a ścieżki są dość łatwe do napisania, bo to tylko prompty dotyczące funkcji, nad którą pracujesz – możesz poprosić o jej uruchomienie i upewnić się, że przejdzie ona pomyślnie, zanim uzna, że zadanie zostało wykonane.

Jednak wykonanie ścieżek zajmuje trochę czasu.

Możesz też podzielić pętlę weryfikacji na poziomy.

Możemy więc poprosić go, aby najpierw upewnił się, że testy jednostkowe i podglądy Compose renderują się prawidłowo.

Gdy ten test zakończy się powodzeniem, uruchom testy połączenia i Android Journeys. Dopiero gdy te testy zakończą się powodzeniem, uruchom pełny zestaw testów, np. w laboratorium testowym urządzeń zdalnych, który może potrwać kilka godzin.

Jeśli podasz te dodatkowe informacje, zauważymy, że pętla jest wykonywana na poziomie, a nie na każdym kroku przy każdym uruchomieniu.

Modele są bardzo pewne siebie.

Dlatego zawsze uważają, że są kompletne i że przejdą wszystkie testy za pierwszym razem.

Zobaczmy, jak to wygląda w Sideline.

Zastosujmy ten pomysł w naszej aplikacji Sideline, dodając nową funkcję, która będzie przeznaczona specjalnie dla okularów XR, które pojawią się już wkrótce.

Ponieważ nie mamy jeszcze sprzętu, użyjemy emulatora XR i poinstruujemy naszego agenta kodowania, aby rozszerzył Sideline na nowy format.

Gdy to zrobimy, poprosimy naszych agentów o wykonanie testów JVM, testów podglądu Compose i testów emulatora w tej kolejności.

Każda pętla jest tworzona na podstawie poprzedniej.

Gdy to zrobimy, pierwszą rzeczą, którą zauważymy, jest to, że między pętlą 1 a 2 do zdefiniowania 6 stanów podglądu Compose używane są testy JVM.

Oczywiście nie wywołano emulatora, więc działa to bardzo szybko.

Podobnie między pętlą 2 a 3 problemy takie jak długie ciągi znaków są wykrywane i rozwiązywane, zanim emulator zostanie uruchomiony.

Gdy pętla emulatora zostanie uruchomiona, znajdzie dodatkowe błędy, których nie udało się naprawić za pomocą testu JVM i podglądów Compose.

Zasadniczo jednak z każdą pętlą coraz bardziej zabezpieczamy aplikację. Chcemy najpierw uruchamiać najszybsze, ale najmniej wydajne pętle, a następnie najwolniejsze, ale najbardziej wydajne.

Oto wynik.

Okulary pokazują teraz rodzaj uderzenia i prędkość piłki odbijanej od rakiety, dzięki czemu możesz grać w tenisa i otrzymywać informacje zwrotne o rozgrywce w czasie rzeczywistym, nie spuszczając piłki z oczu.

Wspomniałem wcześniej, że wrócimy do tych 2 problemów z Crashlytics, które pojawiły się wcześniej.

Skoro już udało nam się potwierdzić, że to podejście działa, możemy użyć polecenia /schedule w Claude Code, aby zapętlić ten proces. Możemy ustawić dowolną częstotliwość, dzięki czemu mamy teraz samonaprawiającą się aplikację, która naprawia wszystkie błędy i potwierdza, że zostały naprawione, a następnie wysyła je jako żądania pull do naszych inżynierów, aby mogli je sprawdzić i scalić.

Świetnie.

To wszystko na dziś.

Jeśli masz zapamiętać jedną rzecz, niech to będzie to, że musimy zacząć myśleć o świecie, w którym tworzymy środowisko, w którym nasi agenci mogą odnieść sukces, i traktować to tak, jak obecnie traktujemy tworzenie oprogramowania i błędy.

W ten sposób odblokowujemy agentów równoległych.

W internecie znajdziesz wiele porad na ten temat, które często będą ze sobą sprzeczne.

And it's just the reality of this fast-moving environment.

Najlepsze, co możesz zrobić, to napisać własne oceny dla swojego projektu.

Gdy pojawiają się nowe porady lub nowy model, możesz je przetestować i sprawdzić, czy Ci pomagają.

Oczywiście do wszystkiego potrzebne są umiejętności.

Dostępna jest umiejętność, która pomoże Ci tworzyć oceny w Claude Code.

/claude-api build-eval

Zdecydowanie polecam się z nią zapoznać.

Dzisiaj omówiliśmy Android Bench.

Android Bench to nasz test porównawczy.

Dzięki temu możemy mierzyć, czy sytuacja się poprawia.

Jeśli chcesz dowiedzieć się, czego nauczyliśmy się podczas tworzenia tego narzędzia, aby nie popełniać tych samych błędów, obejrzyj prezentację na temat Android Bench.

Są też 2 panele.

Jedna jest w Stanach Zjednoczonych, a druga w Londynie.

Oba zostaną opublikowane online i będą dotyczyć tego rodzaju koncepcji w praktyce w społeczności.

W panelu wezmą udział członkowie społeczności deweloperów aplikacji na Androida, którzy opowiedzą o tym, jak wykorzystują te rozwiązania w swojej pracy.

Chętnie poznamy też Twoją opinię.

Chcemy wiedzieć, czy tworzymy rzeczy, które naprawdę Ci pomagają.

Wypełnij ankietę.

Zostawię to na ekranie.

I tak.

Dziękuję za uwagę.

Dziękujemy.