Agentenbasiertes Engineering mit Claude Code und der Android CLI

Hallo, ich bin Ben, Android Developer Relations.

Ich bin Steven, Produktmanager.

Heute geht es um die agentische Entwicklung von Apps mit Claude Code und der Android-Befehlszeile.

Ich denke, man kann sagen, dass sich unsere Rolle als Entwickler ein wenig verändert und die Dinge sich rasant entwickeln. So schnell, dass der Inhalt dieses Vortrags wahrscheinlich schon veraltet ist, besonders wenn Sie ihn online ansehen.

Wir haben uns also mit dem, was wir geschrieben haben, und den Informationen, die wir präsentieren, weit aus dem Fenster gelehnt. Die Demos, die heute laufen, sind jedoch realistisch und sollten daher zuverlässig sein.

Außerdem haben wir für diesen Vortrag Claude Code verwendet, aber die Informationen sind agentenunabhängig.

Es ist eher eine Denkweise, die für alles gilt, was Sie beim Erstellen Ihrer Apps verwenden möchten.

Wir möchten, dass Sie sich eine Welt vorstellen, in der Sie Teams von autonomen Agenten verwalten, und wie Sie sie auf Erfolg einstellen.

Wenn die KI eine Funktion oder etwas Ähnliches nicht implementieren kann, sollten wir nicht einfach aufgeben und sagen: „Oh, das kann die KI noch nicht.“ Stattdessen müssen wir einen Schritt zurückgehen und überlegen, welche Information gefehlt hat. Wir sollten das Problem wie einen Fehler behandeln, den wir heute beheben müssen.

Wenn Sie sich die Veröffentlichungen der Teams ansehen, die diese Agenten-Frameworks entwickeln – Claude Code, Codex, Antigravity –, werden Sie feststellen, dass sie genau so vorgehen. Und wenn wir diese Frameworks als einen Blick in die Zukunft betrachten, ist das wahrscheinlich die Richtung, in die wir uns alle bewegen.

Es war wahrscheinlich noch nie so spannend, Android-Entwickler zu sein. Aber vielleicht geht es Ihnen wie mir und Sie wissen nicht genau, worauf Sie sich konzentrieren sollen.

Und wir als Entwickler brauchen Tools und Workflows, die mit der Intelligenz skalieren, damit unsere harte Arbeit nicht überflüssig wird, wenn ein neues Modell die Grenzen erweitert.

Wir möchten, dass jede Modellverbesserung zu intelligenteren Workflows für unsere Kundenservicemitarbeiter führt, was letztendlich zu besseren Ergebnissen für unsere Nutzer führt.

Heute geht es um vier Themen.

Zuerst erklären wir, warum es so wichtig ist, Ihre KI-Agenten in Umgebungen einzurichten, in denen sie erfolgreich sein können.

Anschließend geben wir einen Überblick über den Kontext und wie Sie ihn am besten verwalten.

Anschließend stellen wir Ihnen einige der besten Tools vor, die Android-Entwicklern zur Verfügung stehen, die mit KI-Agenten arbeiten. Zum Schluss erläutern wir, warum es sinnvoll ist, Schleifen in Ihre Agentic Workflows einzubinden.

Sehen wir uns das genauer an.

Also, Umgebung.

Aber was bedeutet das eigentlich?

Wie ich schon sagte, versuchen wir, eine Umgebung zu schaffen, in der der KI-Agent erfolgreich sein kann, ohne dass Sie ständig neue Prompts eingeben und ihn auf den richtigen Weg bringen müssen. Denn wenn Sie das tun, können Sie mehrere KI-Agenten parallel ausführen. Und genau hier kommen die echten Produktivitätsgewinne ins Spiel, wenn Sie diese Teams von KI-Agenten haben, die alle Ihre Arbeit für Sie erledigen.

Das geht aber weit über den bloßen Zugriff auf den Code hinaus.

Sie benötigen Zugriff auf eine genaue Dokumentation, einschließlich Projektspezifikationen und Regeln für die Arbeit an diesem Projekt.

Das ist der offensichtliche Grund.

Einige Leute verbinden ihren Agenten jetzt mit ihrem Team-Chatbereich, nicht nur, um Agenten zu starten, sondern um den Kontext bereitzustellen, wie Entscheidungen getroffen wurden, die zu der Funktion geführt haben, mit der sie beauftragt wurden. Als Entwickler verwenden Sie diese Art von unbewussten Informationen, wenn Sie Probleme lösen, und das kann auch für Ihren Agenten hilfreich sein.

Auch der Verlauf früherer Entscheidungen und Pull-Anfragen.

Sie sollten die Kommentare sehen können, die Sie zu Ihren Pull-Anfragen erhalten, die Art von Dingen, für die sie gepingt werden, und so weiter. Dann werden Sie feststellen, dass sie daran arbeiten und das Problem beheben können.

Sie würden auch nicht erwarten, Android-Code ohne Zugriff auf ein Gerät oder einen Emulator schreiben zu können. Das sollten Sie also auch nicht von Ihrem Agenten erwarten.

Ich weiß, dass sie fantastisch wirken und alles können, aber ein Emulator ist wirklich hilfreich.

Das Gleiche gilt für Profiler.

Wenn sie an der Leistung arbeiten sollen, müssen sie in der Lage sein, ein Profil zu erstellen. Dazu benötigen sie Zugriff auf ein echtes Gerät.

Und alle Backend-Dienste, die Ihre App verwendet, sollten idealerweise auch mit Ihrem Agenten kommunizieren können.

Und hier kommt die Android-Befehlszeile ins Spiel.

Falls Sie noch nichts davon gehört haben: Es wurde auch im Vortrag „What's New in Tools“ erwähnt. Die Android-Befehlszeile ist unsere neue Befehlszeile für die Interaktion mit verschiedenen Android-Tools.

Es ist kein KI-Produkt, sondern nur eine Befehlszeile.

Sie erhalten Zugriff auf den Android SDK-Manager, können Emulatoren starten und vieles mehr.

Außerdem kann er mit Tools und Back-Ends wie Crashlytics verbunden werden.

Sie funktioniert mit jedem KI-Agenten, den Sie verwenden, und befindet sich einfach in Ihrem Shell-Bereich.

Also.

Sie können es über diesen Link installieren, aber ich denke, es ist einfacher, wenn wir es uns einfach in Aktion ansehen.

Okay.

Anstatt nur zu erklären, warum es so wichtig ist, Ihre KI-Agenten auf Erfolg auszurichten, wollten wir dieses Prinzip auf eine von uns entwickelte Produktionsanwendung namens Sideline anwenden.

Und Sideline ist eine Android-App für Tennisspieler, die ihnen Echtzeit-Feedback zu Ballposition, Spielerposition und Platzposition gibt.

Sie bietet Offline-Coaching-Feedback per Videowiederholung und Fitnessdaten wie Höchstgeschwindigkeit, zurückgelegte Strecke und längste Ballwechsel.

All das wird durch benutzerdefinierte TF Lite-Modelle ermöglicht, die direkt auf dem Android-Gerät ausgeführt werden.

Zuerst möchte ich sagen, dass wir natürlich keine Probleme lösen können, von denen wir nichts wissen.

Wir haben Firebase Crashlytics über die Android-Befehlszeile in unsere Entwicklungsumgebung eingebunden und konnten so Probleme finden, von denen wir gar nicht wussten, dass sie auftreten.

Der erste war ein „App antwortet nicht“-Fehler (ANR) auf einem Pixel 11 Pro Fold, der im Emulator nicht reproduziert werden konnte.

Glücklicherweise unterstützt die Android-Befehlszeile Android Device Streaming.

Nachdem wir den Agenten angewiesen hatten, das Problem zu beheben, stellte er eine Verbindung zu dem Gerät her, auf dem der ANR-Fehler aufgetreten war. Das war für mich besonders nützlich, da ich zu dem Zeitpunkt kein Pixel 11 Pro Fold hatte, um die Fehlerbehebung zu überprüfen.

Indem wir dem KI-Agenten die Möglichkeit gaben, auf das Gerät zuzugreifen, das er zur Validierung der Fehlerbehebung benötigte, konnten wir letztendlich die Möglichkeiten erweitern.

Um Zeit zu sparen, habe ich alle Tests im Voraus durchgeführt und hier zusammengefasst.

Ohne zu sehr ins Detail zu gehen, war das Problem, das wir hatten, ein Affinitätsaufruf im Zusammenhang mit Android 17.

Es war eine schnelle Korrektur, die aus zwei Zeilen bestand und für mich gut aussah.

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

Ich habe also die Pull-Anfrage erstellt, zusammengeführt und mit einem neuen Build aktualisiert, der bei Google Play eingereicht wurde.

Hätten wir die Programmierumgebung nicht mit den erforderlichen Funktionen eingerichtet, hätten wir weder ein echtes Problem identifizieren noch eine Lösung validieren können.

Bei den 1.0-Builds ist das Problem also behoben.

Es sind jedoch neue Probleme aufgetreten, auf die wir später eingehen werden.

Okay.

Als Nächstes: Kontext.

Vor etwa eineinhalb bis zwei Jahren – was nicht lange her ist, aber im KI-Bereich eine Ewigkeit – gab es ein Wettrennen um immer größere Kontextfenster. Die Theorie war, dass wir umso bessere Ergebnisse erzielen würden, je mehr wir dem Modell vorwerfen. Wir haben verrückte Dinge getan, wie versucht, die gesamte developer.android.com-Website in den Prompt einzubinden. Das hat nicht wirklich funktioniert.

Obwohl die Kontextfenster weitgehend stagnieren, steigen die Modellfunktionen weiter.

Das ist Android Bench 1.0.

Android Bench ist unser Benchmark, mit dem wir die Fähigkeit von KI bewerten, Android-Code zu schreiben.

Die darin enthaltenen Aufgaben sind realistisch.

An solchen Dingen arbeiten Sie. Wir sehen, dass die Kontextfenster bei einer Million Tokens stagnieren, aber die Modellfunktionen weiter zunehmen.

Aber der Kontext ist immer noch ein festes Budget, das Sie für das aufsparen möchten, was wichtig ist.

Sie möchten keine Dinge darin haben, die nicht zur Lösung des Problems beitragen, an dem Sie gerade arbeiten.

Und viele Agenten-Frameworks stellen Ihnen dieses Kontextfenster von 1 Million Tokens gar nicht zur Verfügung, weil sie es für sinnlos halten.

Die Ergebnisse werden dadurch nur schlechter.

Es gibt einen optimalen Bereich, der je nach Modell variiert. Wenn Sie Ihre Unterhaltungen auf etwa 150.000 Tokens beschränken, können Sie die volle Leistung des Modells nutzen, ohne dass der Kontext verloren geht.

Kontext ist aber nicht nur das, was Sie eingeben.

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

Hinter den Kulissen passiert tatsächlich eine ganze Menge, die Sie nicht sehen.

Sie besteht aus mehreren Teilen.

Zuerst die Systemanweisung.

Die Systemanweisung wird von Ihrem Agenten bereitgestellt.

Das ist im Grunde ein Prompt, der dem KI-Agenten mitteilt, wie er mit diesem Agenten arbeiten und sich verhalten soll.

Aber auch Arbeitsbereichsinformationen, wie Ihr aktuelles Arbeitsverzeichnis, welche SDKs Sie haben, alle installierten Skills (darüber sprechen wir gleich) und MCP-Tools, also alle Tools, die von Ihrem KI-Agenten bereitgestellt werden.

Das Modell muss wissen, dass es sie aufrufen kann, was Kontext erfordert.

Der wichtigste Punkt ist jedoch, dass der gesamte Nachrichten- und Toolaufrufverlauf mit jedem Prompt und jeder neuen Nachricht, die Sie an Ihren Agenten senden, mitgesendet wird.

Das kann sich wirklich summieren, insbesondere bei Gradle.

Wie wir alle wissen, sind Gradle-Logs sehr lang und sehr ausführlich.

Die meisten davon sind nicht erforderlich.

Hier ist ein kurzer Tipp, worauf Sie achten sollten.

Sie können Gradle im stillen Modus ausführen.

./gradlew assembleDebug --quiet

Oder die größeren Agenten-Frameworks kürzen dies für Sie.

Bei Claude Code und Android Studio wird nicht das gesamte Gradle-Log gesendet.

Wenn Sie jedoch einen der minimalen Agenten verwenden, weil deren Philosophie darin besteht, alles an das Modell zu senden, da das Modell es am besten weiß, sendet der mini-SWE-Agent das vollständige Gradle-Log, was sehr schnell sehr teuer werden kann.

Aber wie bleiben wir innerhalb dieses magischen Fensters von 150.000?

Der Schlüssel liegt in der Verwendung eines Workflows.

Es gibt unzählige Workflows.

Ich mag besonders die von Matt Pocock. Er hat eine Reihe von Skills, die dir helfen, diese Sitzungen zu verwalten.

Es beginnt mit der Fähigkeit „grill-me“.

Sie führen diesen Skill aus, wenn Sie ein ganzes Projekt oder nur eine neue Funktion innerhalb des Projekts starten. Der Agent stellt Ihnen dann eine Reihe von Fragen.

Sie könnten also einfach sagen: „Grill mich.

Ich möchte einen neuen Wecker in meiner App erstellen.“

Und dann stellt es Ihnen Fragen, z. B. in welcher Sprache es implementiert werden soll und wo es hingehört.

So werden alle Unklarheiten aus dem Problem und aus Ihrem Kopf in ein Problem übertragen.

Dann führen wir den nächsten Skill aus, der eine Art großes Spezifikationsdokument schreibt.

Ein anderer Skill zerlegt das dann in Probleme, die wir in dem von Ihnen bevorzugten Issue Manager ablegen.

Und dann sollte jedes dieser Probleme ungefähr in dieses 150.000-Fenster passen.

Dann wählen Sie ein Problem aus, das Sie entweder im Terminal oder in Ihrer IDE bearbeiten, je nachdem, was Sie bevorzugen. Sie erstellen und verifizieren die Schleife, wir löschen am Ende den Kontext, es gibt keinen Unterhaltungsverlauf mehr und wir sind im Fenster geblieben.

Okay.

Als Nächstes sprechen wir über AGENTS.md.

Unter AGENTS.md können Sie zusätzliche Informationen für Ihren KI-Agenten angeben, die für alle Probleme gelten, an denen er in diesem Projekt oder im gesamten Arbeitsbereich arbeitet, je nachdem, was Sie auswählen.

Da sie jedoch für jeden Prompt bereitgestellt werden, sollten sie nur Informationen enthalten, die idealerweise immer gelten.

Es funktionieren also Architektur- und Modulregeln.

Das sind Dinge, die Ihr Agent unmöglich wissen konnte, insbesondere wenn Sie an einer Closed-Source-Anwendung arbeiten.

Es ist jedoch wichtig, sie zu verstehen, um sich zu Beginn nicht den Kopf darüber zerbrechen zu müssen, wo dieses Feature hingehört.

Sie können also Dinge wie UI-Komponenten in das Designsystemmodul einfügen. Eine weitere gute Idee sind häufige Fehler bei der Codeüberprüfung oder einfach häufige Dinge, die Sie immer wieder eingeben müssen.

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

„In diesem Projekt verwenden wir lieber kotlinx.datetime“ oder Ähnliches.

Ich wollte eigentlich Best Practices vorstellen, die immer gelten, aber die Realität ist, dass sich das mit jeder Modellversion ändert.

Verschiedene Modelle verhalten sich unterschiedlich, wenn es um zusätzlichen Kontext geht.

In Opus 4.6 war es beispielsweise üblich, in Großbuchstaben zu schreiben: „Das darfst du auf keinen Fall tun.“

Als Opus 5 herauskam, veröffentlichte Anthropic eine Erklärung: „Eigentlich funktionieren Großbuchstaben nicht mehr so gut.

Verwenden Sie einfach Kleinbuchstaben.“

Das meine ich damit: Sie müssen am Ball bleiben.

Einige Dinge sind jedoch ziemlich universell geblieben, z. B. dass man sich kurz fassen sollte.

Beschränken Sie sich also auf etwa 250 Zeilen.

Und das nächste Thema ist etwas polarisierend, weil ich weiß, dass viele Leute das gerne tun. Aber im Februar dieses Jahres kam eine Studie heraus, die zeigte, dass die Leistung um etwa 2 bis 3 % sinkt, wenn Sie Ihren Agenten seine eigene AGENTS.md ändern lassen. Das ist nicht so schlimm.

Aber der wichtige Teil war, dass die Kosten um 20 % gestiegen sind.

Wir haben also ein wenig Leistung verloren und die Kosten sind explodiert – nur weil wir den KI-Agenten seine eigenen AGENTS.md schreiben lassen haben.

Eine Möglichkeit, dies zu umgehen, besteht darin, dass der Agent am Ende jedes Pull-Anfrage eine Retrospektive schreibt. Diese können Sie dann als Team in Ihren Retrospektiven gemeinsam lesen und entscheiden, welche Änderungen Sie vornehmen möchten. Diese Datei wird nämlich zu einem wichtigen Teil der kritischen Teaminfrastruktur, wenn Sie in großen Teams mit Agenten arbeiten.

Hier ist die AGENTS.md für die Sideline-Anwendung, die wir erstellt haben.

Es gibt zwei Dinge, die ich hier hervorheben möchte.

Erstens sparen Sie mit einer klar definierten Architektur Tokens und Kontextlänge.

So muss der KI-Agent nicht ständig weitere Teile Ihrer Codebasis durchsuchen und immer mehr Schlussfolgerungen ziehen.

Es gibt eine sehr klar definierte Richtlinie vor, an die sich das LLM halten muss.

Der zweite Punkt, den ich hervorheben möchte, betrifft insbesondere Closed-Source-Anwendungen.

Wenn Sie Closed Source verwenden, konnte natürlich keiner der Agenten oder LLMs mit Ihrer Codebasis trainiert werden.

In diesen Fällen ist es besonders wichtig, sich die Zeit zu nehmen, um die AGENTS.md ständig zu bereinigen, zu überprüfen, zu verfeinern und zu verbessern, da Sie langfristig davon profitieren werden.

Wenn wir also nicht einfach alles in AGENTS.md einfügen sollten, wie können wir dann das Verhalten des KI-Agenten oder Modells ändern?

Die erste Möglichkeit sind Hooks. Hooks sind eigentlich sehr gut für die Art von Dingen, die man in AGENTS.md einfügt, z. B. „Führe immer den Linter aus, wenn du mit dem Schreiben fertig bist“.

// settings.json

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

Das kann ein Aufhänger sein.

Ein Hook ist ein Ereignis, das Ihr Agent verfügbar macht und das Sie abonnieren können. Es gibt Hooks für so ziemlich alles, was Sie sich vorstellen können. Die wichtigsten sind jedoch „Sitzung starten“, „Sitzung beenden“, „Dateien lesen“ und „Dateien schreiben“.

Anstatt also am Ende Ihres AGENTS.md „Führe immer den Linter aus“ oder „Führe immer meine Test-Suite aus, bevor du sagst, dass du fertig bist“ zu schreiben, haben Sie stattdessen einen Stop-Hook, der ein deterministisches Skript ausführen kann. Das hilft, die leichte Zufälligkeit der KI einzudämmen.

Ein weiteres Beispiel: Wenn Sie Dateien haben, die Ihr Agent auf keinen Fall lesen oder schreiben können soll, z. B. eine Datei mit Geheimnissen, die nicht an einen Server gesendet werden soll, oder AGENTS.md, in die Ihr Agent nicht schreiben können soll, können Sie dafür einen Hook verwenden.

Sie haben also einen Lese- oder Schreib-Hook, erhalten die Datei, die bearbeitet werden soll, und können einfach zurückgeben: „Nein, das geht nicht.“

Es ist nur eine Möglichkeit, Determinismus hinzuzufügen.

Der nächste Punkt sind Fähigkeiten.

Es gibt sogar Skills, mit denen du deine AGENTS.md in Hooks verwandeln kannst.

Das ist eine ganz andere Sache.

Mit Skills können Sie Kontext nur dann hinzufügen, wenn er relevant ist.

AGENTS.md ist also für Dinge, die immer relevant sind.

Skills sind für Dinge gedacht, die in bestimmten Situationen relevant sind, hauptsächlich für die Dokumentation.

Skills bestehen aus drei Teilen: einem Namen, einer Beschreibung (die auf 1.024 Zeichen begrenzt ist) und einem Textkörper.

---

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

Der Text kann sehr umfangreich sein und sogar andere Skripts enthalten, was ziemlich häufig vorkommt.

Mit Skills können Sie eine Menge tun.

Sehen wir uns ein Beispiel an.

Dies ist die Beschreibung der Android-Befehlszeile.

Sie müssen das nicht alles lesen.

Es ist eine kurze Beschreibung, die angibt, wann die Android-Befehlszeile relevant ist.

Und das ist der Text.

Es ist riesig, also wollen wir nicht alles auf einmal laden, oder?

Wir möchten diese nur laden, wenn wir die Android-Befehlszeile verwenden möchten. Genau das ermöglicht uns ein Skill.

Es ist jedoch wichtig, die Skills, die du installierst, sorgfältig auszuwählen.

Wir möchten nicht einfach blind die Repositories installieren, die wir online finden und die Hunderte von agentischen Engineering-Fähigkeiten enthalten.

Erstens ist das ein enormes Sicherheitsrisiko.

Sie wissen nicht, was in diesen Skills enthalten ist. Es könnte sein, dass Ihr Agent angewiesen wird, irgendetwas zu tun.

Wir haben eine Reihe von Android-Skills, die wir geprüft haben, und die sagen das nicht.

Zweitens: 100 Beschreibungen mit jeweils 1.000 Zeichen ergeben 100.000 Zeichen, die Sie hinzugefügt haben, bevor Sie überhaupt mit dem Programmieren begonnen haben.

Sie sind also schon nah dran.

Deshalb empfehlen wir, für alle Android-Skills den Android CLI-Basis-Skill zu installieren. Von dort aus kann die Android CLI die verfügbaren Skills durchsuchen und die für Ihre App sinnvollen Skills installieren.

> android init

✓ Installed base skill: android-cli

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

Wenn Sie sich die Liste ansehen, ist es gut zu wissen, welche Skills verfügbar sind. Sie können die Skills, die für Ihr Projekt sinnvoll sind, manuell hinzufügen, z. B. die Compose-Skills oder die Edge-to-Edge-Skills, die ziemlich universell sind.

Natürlich gibt es auch Kompetenzen, um Kompetenzen zu prüfen.

In Claude Code gibt es /skill-doctor. Damit können Sie sich ansehen, welche Fähigkeiten Sie einbeziehen, die nie aktiviert werden. So verschwenden Sie nicht die Beschreibung mit 1.000 Zeichen.

Und wenn Sie nicht in Claude Code sind, hat so ziemlich jedes Agenten-Framework eine Art Statistik- oder Audit-Bildschirm, der dasselbe tut.

Hier ist noch einmal der Link zur Android-Befehlszeile.

Es gibt aber einen Befehl für die Liste der Fähigkeiten. Nehmen wir an, Sie haben Navigation 3 in Ihrem Projekt.

android skills list
android skills add navigation-3

Navigation 3 ist eine recht neue Bibliothek, daher wurde sie noch nicht viel trainiert. Sie können den Navigation 3-Skill hinzufügen.

Wir oft… Oh, Entschuldigung.

Der nächste ist MCP.

Wir werden jedoch oft gefragt, warum wir die Android-Befehlszeile als Befehlszeile und nicht als MCP-Server entwickelt haben.

Wir haben diese CLI-Tools schon lange vor der KI und sogar vor der Maus entwickelt. Sie sind schnell, modular und da sie lokal in Ihrer Shell-Sitzung ausgeführt werden, sind sie praktisch kostenlos.

Benchmarks wie Terminal Bench sind zu den wichtigsten Benchmarks im Software Engineering geworden. Die Modellentwickler haben sich intensiv mit der Terminalnutzung auseinandergesetzt, sodass die Modelle heute sehr gut mit Befehlszeilen umgehen können.

Das bedeutet aber nicht, dass MCP keine Rolle spielt.

MCP-Server sind besonders nützlich für externe Dienste, die Sie bereits verwenden, insbesondere wenn diese bereits einen MCP-Dienst hosten.

Sie können direkt darauf zugreifen und Ihrem Agenten ohne Installation zusätzlichen Kontext hinzufügen.

Dienste wie GitHub, Figma und Slack stellen jetzt MCP-Server bereit.

Und Dinge, die wir schon immer in der Shell ausgeführt haben, können in der Shell bleiben, also Android-Befehle über die Android-CLI, aber auch Perfetto und Gradle sind lokal sinnvoll, wo sie Zugriff auf alles haben, was Sie bei der Entwicklung verwenden.

Ich habe früher im Bereich Leistung gearbeitet.

Ich habe immer gesagt, dass Perfetto das einzige Tool ist, das man braucht, um jedes Leistungsproblem zu lösen.

Aber die Lernkurve war so steil, wie wir gerade im letzten Vortrag von Rahul gesehen haben.

Sehen wir uns an, wie KI die Leistung verbessern kann.

Danke, Ben.

Damit unsere Anwendung Sideline funktioniert, muss sie mit 30 Bildern pro Sekunde und in Echtzeit ausgeführt werden.

Und wie Sie hier auf diesem Pixel 10 Pro Fold sehen können, erreichen wir nur etwa 20 bis 22 Bilder pro Sekunde.

Diese ausgelassenen Frames sind ein Problem, weil die Anwendung dann nicht wie angegeben funktioniert. Wir müssen das also unbedingt beheben.

In der Android-Befehlszeile gibt es die Android Profiler-Befehle.

Wenn wir es unserem KI-Agenten für die Programmierung hinzufügen und ihn anweisen, die Anforderung von 30 Bildern pro Sekunde zu erfüllen, passieren zwei interessante Dinge.

Erstens: Es findet eine Lösung mit dem Android-Profiler-Befehl.

Es hat System-Traces auf dem verbundenen Pixel 10 Pro Fold aufgezeichnet und festgestellt, dass die KI-Threads auf den langsamsten Kernen des Geräts ausgeführt wurden.

Und zweitens hat es die Android-Dokumentationssuche verwendet, ohne dass wir es explizit dazu aufgefordert haben, und die offizielle Anleitung für die Performance Hint API abgerufen.

Der KI-Agent hat gelernt, den Systemzeitplan zu optimieren, und konnte so die Anforderung von 30 Bildern pro Sekunde erfüllen.

Im Grunde wurde die Korrektur also gemäß der Anleitung vorgenommen.

Mit der Android-Befehlszeile können Sie also den KI-Agenten einbinden, um das richtige Tool zu finden, auch wenn Sie es nicht kennen, für jede Aufgabe, die Sie erledigen müssen.

Wenn wir die App jetzt ausführen, sehen wir, dass Sideline die Anforderung von 30 Bildern pro Sekunde erfüllt und jetzt auf einem Pixel 10 Pro Fold funktioniert.

Okay.

Jetzt fügen wir alles mit Schleifen zusammen.

Das haben wir sicher alle schon erlebt: Sie bitten Ihren KI-Agenten, eine große Änderung vorzunehmen, und er meldet, dass er fertig ist.

Wenn Sie die App installieren und manuell darin herumklicken und die Fehler zurückmelden, ist das genau das, was wir nicht mehr tun sollten.

Wir müssen aufhören, die QA-Tester unseres KI-Agenten zu sein, und im Voraus definieren, was wir als „erledigt“ betrachten.

Hier ein Beispiel:

Wir möchten das gesamte Projekt zu Nav3 migrieren. Der Agent verschwindet dann für eine Weile, kommt aber mit der Meldung „Migration abgeschlossen“ zurück.

Ich bin der Beste.“

Aber dann dreht ihr das Smartphone, die App stürzt ab, alle Folienübergänge werden übersprungen und die Gradle-Datei wird nicht bereinigt.

Das ist so ähnlich wie die Welt, in der wir gerade leben.

Idealerweise müsste es das nicht tun, aber das ist die aktuelle Realität.

Wir hätten also zuerst alles definieren müssen, was wir erwarten. Dann hätte der Agent so lange iterieren können, bis alle Kriterien erfüllt sind.

Das ist eine Verifizierungsschleife.

Wir haben tatsächlich sehr aussagekräftige Daten zur Wirksamkeit dieser Maßnahme.

Das ist Android Bench 2.0, die neue Version unseres KI-Benchmarks, den ich zu Beginn des Vortrags erwähnt habe.

Die Erfolgsquote liegt derzeit bei etwa 40 %.

Diese Aufgaben sind wirklich schwierig, sehr umfangreich und realistisch. Eine davon ist Nav2 zu Nav3. Das sind die Arten von Aufgaben, die Sie gerade in Ihren Projekten erledigen.

Fable 5.1 erreicht mit einem natürlichen Prompt wie „Migriere Nav2 zu Nav3“ eine Erfolgsquote von 22 %.

Wenn wir ihm aber im Voraus eine fehlerhafte Test-Suite geben, also nicht die Antworten, nicht die Anleitung zur Migration zu Nav3, sondern nur eine Test-Suite, die bereits fehlerhaft ist und erst dann erfolgreich ist, wenn alle diese Dinge abgeschlossen sind, steigt die Erfolgsquote im gesamten Benchmark auf 90 %.

Das zeigt uns, dass diese Modelle jetzt wirklich in der Lage sind, so ziemlich jede Android-Aufgabe zu implementieren, die wir uns vorstellen können. Sie wissen nur nicht immer, was „fertig“ bedeutet.

Sie müssen also nicht im Voraus eine vollständige fehlerhafte Test-Suite schreiben.

Überprüfungsschleifen können so einfach sein wie das Hinzufügen von Prompts.

Wenn Sie also an der Benutzeroberfläche arbeiten, können Sie Gemini bitten, die Compose-Vorschau zu rendern und zu prüfen, ob sie der Figma-Spezifikation entspricht, und Ihnen die Ergebnisse anzuzeigen.

Es scheint wirklich zu funktionieren, wenn Sie es bitten, Ihnen die Ergebnisse zu zeigen und zu beweisen, dass die Aufgabe erledigt wurde, anstatt nur die Textantwort „Ich bin fertig“ zu akzeptieren.

Wenn Sie an der Geschäftslogik arbeiten, können Sie Gemini bitten, Ihre Unit-Tests auszuführen. Wenn Sie an der Behebung eines Absturzes arbeiten, können Sie Gemini bitten, über das Remote Test Lab zu prüfen, ob der Absturz auf dem echten Gerät, auf dem er aufgetreten ist, behoben wurde.

Claude Code hat eine integrierte Funktion, mit der Sie Verifizierungsschleifen erstellen können.

Sehen Sie sich das also unbedingt an.

Wenn Sie in Android Studio mit einem eigenen KI-Agenten arbeiten, bietet Android Studio eine Vielzahl von Tools, mit denen Sie je nach Projekt Schleifen erstellen können.

Wie beim Linter können Sie ihm sagen, dass er erst aufhören soll, wenn alle Lint-Fehler behoben sind. Oder Sie können ihn bitten, Ihre Journeys auszuführen und zu prüfen, ob sie noch funktionieren.

Oder wenn Sie eine Journey geschrieben haben – Journeys sind ziemlich einfach zu schreiben, sie sind nur Prompts zu dem Feature, an dem Sie arbeiten –, können Sie es anweisen, diese Journey auszuführen und sicherzustellen, dass sie erfolgreich ist, bevor es sich als fertig erklärt.

Die Ausführung von Journeys dauert jedoch eine Weile.

Sie können die Ebenen Ihrer Verifizierungsschleife auch staffeln.

Wir können Gemini also bitten, zuerst zu prüfen, ob die Unit-Tests und Compose-Vorschauen alle korrekt gerendert werden.

Wenn diese Tests erfolgreich sind, führen Sie bitte unsere verbundenen Tests und Android Journeys aus. Erst wenn diese erfolgreich sind, führen Sie die vollständige Test-Suite im Remote-Geräte-Test-Lab aus, was mehrere Stunden dauern kann.

Wenn Sie diese zusätzlichen Informationen angeben, wird die Schleife pro Ebene ausgeführt, anstatt jeden Schritt bei jedem Durchlauf auszuführen.

Modelle sind nämlich sehr selbstbewusst.

Sie denken also immer, dass sie vollständig sind und alle Tests beim ersten Versuch bestehen werden.

Sehen wir uns das in Sideline an.

Wenden wir diese Idee also auf unsere Sideline-Anwendung an und fügen wir eine neue Funktion hinzu, die speziell für die demnächst verfügbaren XR-Brillen gedacht ist.

Da wir noch keine Hardware haben, verwenden wir den XR-Emulator und weisen unseren KI-Agenten an, Sideline für den neuen Formfaktor zu erweitern.

Dabei weisen wir unsere KI-Agenten ausdrücklich an, JVM-Tests, Compose Preview-Tests und Emulator-Tests in dieser Reihenfolge durchzuführen.

Und jede Schleife baut auf der vorherigen Schleife auf.

Dabei fällt als Erstes auf, dass zwischen Schleife 1 und 2 die JVM-Tests verwendet werden, um die sechs Compose Preview-Zustände zu definieren.

Natürlich wurde kein Emulator aufgerufen, sodass die Ausführung sehr schnell ist.

Ähnlich verhält es sich zwischen Schleife 2 und Schleife 3: Probleme wie lange Strings werden erkannt und behoben, noch bevor der Emulator ausgeführt werden muss.

Wenn die Emulator-Schleife ausgeführt wird, findet sie schließlich zusätzliche Fehler, die der JVM-Test und die Compose-Vorschauen nicht beheben konnten.

Im Grunde härten wir unsere Anwendung mit jeder Schleife weiter ab. Wir möchten die schnellsten, aber am wenigsten leistungsstarken Schleifen zuerst ausführen, gefolgt von den langsamsten, aber leistungsstärksten.

Und hier ist das Ergebnis.

Die Brille zeigt jetzt die Art des Schlags und die Geschwindigkeit des Balls an, der vom Schläger abprallt. So können Sie Tennis spielen und in Echtzeit Feedback zu Ihrem Spiel erhalten, ohne den Ball aus den Augen zu lassen.

Ich hatte ja erwähnt, dass wir uns noch einmal die beiden Crashlytics-Probleme ansehen, die zuvor aufgetreten sind.

Da wir bereits überprüft haben, dass dieser Ansatz funktioniert, können wir den Befehl „/schedule“ in Claude Code verwenden, um ihn in einer Schleife auszuführen. Wir können eine beliebige Häufigkeit festlegen, sodass wir jetzt eine selbstheilende Anwendung haben, die alle Fehler behebt und überprüft, ob sie behoben sind. Sie sendet sie als Pull-Anfragen an unsere Entwickler, damit sie sie sich ansehen und zusammenführen können.

Cool.

Das wars dann auch schon für heute.

Wenn Sie eine wichtige Erkenntnis mitnehmen, dann die, dass Sie sich Gedanken über diese Welt machen sollten, in der wir eine Umgebung für unsere Agenten schaffen, in der sie erfolgreich sein können, und dass wir das so behandeln sollten, wie wir heute Softwareentwicklung und Fehler behandeln.

So werden parallele KI-Agenten freigeschaltet.

Im Internet finden Sie viele Ratschläge zu diesem Thema, die sich oft widersprechen.

Das ist einfach die Realität in diesem schnelllebigen Umfeld.

Am besten schreiben Sie also Ihre eigenen Bewertungen für Ihr Projekt.

Und wenn dann neue Ratschläge oder ein neues Modell herauskommen, können Sie tatsächlich messen und sehen, ob es Ihnen hilft.

Und natürlich gibt es für alles einen Skill.

Es gibt einen Skill, mit dem Sie Bewertungen in Claude Code erstellen können.

/claude-api build-eval

Ich empfehle Ihnen, sich das anzusehen.

Heute habe ich über Android Bench gesprochen.

Android Bench ist unser Bewertungstool.

So können wir messen, ob sich die Dinge verbessern.

Wenn Sie mehr über die Erkenntnisse erfahren möchten, die wir bei der Entwicklung gewonnen haben, und die gleichen Fehler vermeiden wollen, sehen Sie sich den Vortrag zu Android Bench an.

Außerdem gibt es zwei Panels.

Es gibt einen in den USA und einen in London.

Beide werden online veröffentlicht und behandeln dieses Konzept in der Praxis in der Community.

Wir haben Mitglieder der Android-Entwickler-Community eingeladen, die uns erzählen, wie sie diese Funktionen in ihrer Arbeit einsetzen.

Wir freuen uns auch über Ihr Feedback.

Wir möchten wissen, ob wir die Dinge entwickeln, die Ihnen tatsächlich helfen.

Bitte füllen Sie die Umfrage aus.

Ich lasse das auf dem Bildschirm.

Und ja.

Vielen Dank fürs Zuhören.

Vielen Dank.