Vom Schreiben von Kotlin bis zur Steuerung von Agenten: Die neue Rolle des Mobile-Entwicklers

Coding-Agenten hören nicht mehr bei der Fertigstellung einer Zeile auf. Sie durchsuchen ein Repository, planen Änderungen, bearbeiten mehrere Dateien, führen den Build aus, lesen Fehlermeldungen und versuchen es erneut. Für Mobile-Entwickler stellt sich damit eine schwierige Frage: Wenn der Agent den größten Teil des Kotlin-Code schreibt, handelt es sich dann immer noch um Android-Entwicklung – oder ist daraus stillschweigend das Schreiben von Prompts innerhalb einer IDE geworden? Dieser Artikel argumentiert, dass keiner dieser Begriffe passt, und erläutert stattdessen, zu welcher Rolle der Entwickler wird: Er erstellt präzise Spezifikationen, gestaltet den Kontext, in dem der Agent arbeitet, kodiert Architekturen als Einschränkungen und überprüft Ergebnisse, die er selbst nicht eingegeben hat.

Die Beispiele beziehen sich auf Android, doch die Argumentation gilt direkt auch für React Native sowie Web- und Backend-Teams, die dieselbe Art von Tools verwenden.

Wie weit sind Coding-Assistenten bereits gekommen

Der klassische Android-Arbeitsablauf ist vertraut: Android Studio öffnen, eine Klasse erstellen, Kotlin schreiben, mit Gradle kämpfen, einen Absturz über Logcat aufspüren, auf einem Gerät testen und einen Pull Request öffnen.

KI-Hilfen sind schrittweise in diesen Arbeitsablauf eingedrungen. Zuerst wurden einzelne Zeilen fertiggestellt, anschließend ganze Funktionen und schließlich ganze Klassen. Aktuelle Tools fungieren als Agenten. Zum Zeitpunkt der Erstellung beschreiben mehrere Produkte diese Funktion explizit:

• Gemini Agent Mode in Android Studio nimmt ein hochrangiges Entwicklungsziel entgegen, erstellt einen Plan, ruft Tools auf, bearbeitet mehrere Dateien, baut das Projekt auf und iteriert, wenn ein Schritt fehlschlägt.
• Cursor's Agent durchforstet eine Codebasis, ändert mehrere Dateien, führt Terminalbefehle aus und behebt Fehler, während er eine Aufgabe bearbeitet, anstatt nur die nächste Zeile vorzuschlagen.

OpenAI Codex wird über die Terminal als Programmieragent ausgeführt, der Code liest, modifiziert und ausführt.

Die Funktionalitäten der Produkte in diesem Bereich ändern sich schnell, daher sollten Sie die aktuelle Dokumentation des Tools prüfen, das Ihr Team verwendet. Die Richtung ist jedoch klar.

Die Arbeit bewegt sich nach oben in der Hierarchie

Ein nützliches Denkmodell ist eine Leiter der Ingenieuraktivitäten, von den am meisten mechanischen Tätigkeiten unten bis zu den am stärksten auf Urteilsvermögen beruhenden Tätigkeiten oben:

Write code
   ↓
Understand code
   ↓
Design architecture
   ↓
Define requirements
   ↓
Make engineering decisions
   ↓
Validate behavior
   ↓
Own the product

Agenten werden in den unteren Ebenen immer besser. Das macht das Tippen und Lesen von Code nicht wertlos, verändert aber den Wert dieser Fähigkeiten. Eine herkömmliche Repository-Implementierung, die manuell eine halbe Stunde dauert, kann in Sekunden erstellt werden. Zehn nahezu identische Compose-Bildschirme sind manuell mühsam zu schreiben; ein Agent kann die relevanten Dateien bearbeiten und die wiederholten Teile erzeugen. Ein einfacher Kompilierfehler kann mehrere Minuten Ihrer Zeit in Anspruch nehmen, während ein Agent die Meldung liest, den fehlerhaften Code findet, ihn repariert, neu kompiliert und fortfährt.

Das Gesamtergebnis ist, dass ein Ingenieur weniger Zeit damit verbringt, Code zu erstellen, und mehr Zeit damit, zu entscheiden, welcher Code überhaupt vorhanden sein sollte.

Ein guter Prompt ist im Grunde eine Spezifikation

Nehmen wir einen typischen Produktantrag: Hinzufügen einer Download-Warteschlange zur App. Ein erfahrener Android-Entwickler erweitert diesen Satz im Geiste zu einem schichtweisen Design:

Database
    ↓
Repository
    ↓
Use Cases
    ↓
ViewModel
    ↓
UI State
    ↓
UI
    ↓
Background execution
    ↓
Notifications

Ein Agent kann nun einen Großteil dieser Struktur umsetzen, doch die Qualität des Ergebnisses hängt stark davon ab, was genau man angefordert hat. Vergleichen Sie eine dreiwortige Anweisung ("Add Download Queue") mit etwas wie diesem:

Erstellen Sie eine Warteschlange, die mehrere Downloads gleichzeitig ausführen und über verschiedene Startvorgänge hinweg erhalten bleibt, wobei Room in Kombination mit WorkManager die Arbeit übernimmt. Verfolgen Sie den Fortschritt im Speicher, anstatt jede Aktualisierung in der Datenbank zu speichern. Wenn der Prozess beendet wird, werden ausstehende und aktive Downloads wiederhergestellt. Der ViewModel sollte einen nur zum Lesen zugänglichen StateFlow veröffentlichen. In der Domain-Schicht dürfen keine Android-Framework-Typen verwendet werden. Abdecken Sie Änderungen des Warteschlangenzustands sowie die Wiederherstellung nach Fehlern mit Unit-Tests. Ändern Sie keine Room-Entitäten, die nichts mit Downloads zu tun haben.

Die Bezeichnung der zweiten Version als „besseres Prompt“ unterschätzt ihre Bedeutung. Es handelt sich um eine technische Spezifikation: Sie nennt die Persistenztechnologie, das Mechanismus für die Hintergrundausführung, eine Leistungsentscheidung (nicht jede Fortschrittsmeldung auf die Festplatte schreiben), eine Anforderung an Widerstandsfähigkeit (Überleben bei Prozessabsturz), einen API-Vertrag (unveränderlicher StateFlow), eine Schichtungsregel, den Testumfang sowie einen expliziten Einflussbereich. Jeder dieser Punkte spiegelt Android-Kenntnisse wider, die der Agent nicht aus dem Befehl „Download-Warteschlange hinzufügen“ ableiten kann.

Die Schlussfolgerung ist, dass der Ingenieur nicht verschwindet. Der Ingenieur wird zur Person, die eine vage Anfrage vom Produkt in eine genaue Beschreibung eines technischen Systems übersetzen kann.

Prompting versus Ingenieurwesen

Die beiden Rollen stellen unterschiedliche Fragen. Jemand, der sich auf das Anstoßen des Modells konzentriert, fragt, wie man das Modell dazu bringen kann, eine bestimmte Ausgabe zu erzeugen. Ein Ingenieur möchte wissen, was gebaut werden soll, aus welchem Grund, unter welchen Einschränkungen und wie man feststellen kann, dass es funktioniert.

Nehmen wir an, ein Agent übergibt Ihnen dieses ViewModel:

class DownloadViewModel(
    private val repository: DownloadRepository
) : ViewModel() {
    val downloads = repository.downloads
}

Es kompiliert und liest sich einwandfrei. Ein erfahrener Android-Entwickler hat dennoch eine Reihe von Fragen, bevor er es akzeptiert:

• Ist downloads ein normaler Flow oder ein StateFlow, und was löst jeder Collector aus?
• Wo befindet sich die einzige Quelle der Wahrheit für den Download-Zustand?
• Was bleibt nach dem Absturz des Prozesses übrig?
• Löst jede Fortschrittsaktualisierung eine Schreiboperation in Room aus?
• Was passiert, wenn zwei Downloads zur gleichen Zeit abgeschlossen werden?
• Wie wird die Stornierung modelliert?

Kann WorkManager diese Aufgabe neu starten, und spiegelt der Zustand das wider?

Was passiert, wenn die Verbindung abbricht?

Wie verhält es sich, wenn der Benutzer die Anwendung gewaltsam beendet?

Ist das Repository hinsichtlich der Lebenszyklen sicher?

Werden einmalige UI-Ereignisse vom Zustand getrennt aufbewahrt?

Wie verhält es sich auf Geräten mit geringer Leistung?

Die Erstellung der Klasse ist einfach. Das Abfragen des Systems im Zusammenhang damit ist der schwierige Teil, und es ist weitaus schwieriger, dies zu automatisieren.

Der agentebasierte Entwicklungszyklus

Der traditionelle Zyklus hält den Entwickler auf dem kritischen Pfad jedes Schritts:

Requirement
    ↓
Developer writes code
    ↓
Build
    ↓
Error
    ↓
Developer investigates
    ↓
Fix
    ↓
Test
    ↓
PR

Durch einen Agenten dazwischen ändert sich der Zyklus. Der Entwickler legt zu Beginn das Ziel fest und ist am Ende für die Überprüfung und Validierung verantwortlich, während der Agent in der Zwischenzeit die Phasen der Erkundung, Bearbeitung sowie Fehlerbehebung übernimmt:

Developer defines goal
        ↓
AI Agent explores codebase
        ↓
AI creates plan
        ↓
AI modifies files
        ↓
AI runs build/tests
        ↓
AI observes result
        ↓
AI fixes problems
        ↓
Developer reviews
        ↓
Developer validates behavior
        ↓
Ship

In der Dokumentation des Herstellers wird dasselbe Muster beschrieben. Der Agent-Modus von Android Studio wird als Planung, Aufruf von Tools, Änderung von Dateien und Iteration der Ergebnisse dargestellt. Cursor beschreibt seinen Agenten als ein Modell, das logisch denkt, als Tools, die es ermöglichen, Dateien zu durchsuchen und zu bearbeiten oder Terminalbefehle auszuführen, sowie als einen Schleifenprozess, in dem der Agent die Ergebnisse beobachtet und den nächsten Schritt wählt. Das ist nicht mehr Autocomplete; es ähnelt eher der Delegation eines Teils der Ingenieurarbeit.

Die IDE als Orchestrierungsschicht

Diese Veränderung beeinflusst die Funktion einer IDE. Früher war sie eine Arbeitsplattform für einen einzelnen Entwickler. Zum Zeitpunkt der Erstellung bieten die KI-Tools von Android Studio Funktionen wie:

• Agent-Modus
• mehrere parallele Agentenkonversationen
• Verbindungen zu MCP-Servern
• Anweisungen in AGENTS.md auf Projektebene
• Zugang zu kenntnissen speziell für Android

Web-Suche

Spezialisierte Fähigkeiten

Rechtemanagement

Validierung im Emulator

Google stellt Agent Mode als in der Lage dar, mehrstufige Entwicklungsaufgaben zu bewältigen, und bietet MCP-Server sowie AGENTS.md als Möglichkeiten zur Erweiterung und Steuerung. Die IDE ist nicht mehr nur der Ort, an dem man Kotlin schreibt, sondern wird zum Ort, an dem ein von KI unterstütztes Ingenieurumfeld ausgeführt und überwacht wird.

Die Grundlagen sind wichtiger denn je

Es wäre naheliegend anzunehmen, dass Ingenieure weniger wissen müssen, wenn Agenten den Code schreiben. Doch das Gegenteil ist der Fall: Agenten machen es einfach, falsche Implementierungen schnell zu erstellen, weshalb man stärkere Grundkenntnisse benötigt, um diese zu erkennen.

Kotlin

Man benötigt weiterhin ein solides Verständnis der Sprachfunktionen, die am häufigsten subtile Fehler verbergen:

Flow
StateFlow
SharedFlow
coroutines
structured concurrency
inline functions
sealed classes
value classes
delegation
generics
null safety

Ziel ist es nicht, jede Zeile selbst einzutippen. Vielmehr geht es darum, rechtzeitig zu erkennen, wenn der generierte Kotlin-Code subtil fehlerhaft ist – beispielsweise bei einem Hot Flow, wo eigentlich ein Cold Flow erforderlich wäre, oder bei einer Coroutine, die außerhalb der strukturierten Konkurrenz gestartet wird.

Die Android-Plattform

Das Verhalten der Plattform ist der Bereich, in dem generierter Code am häufigsten korrekt erscheint, aber in der Produktion versagt:

Lifecycle
Process death
Configuration changes
Services
WorkManager
Room
Navigation
Permissions
Storage
Background execution
Notifications
Compose
Views
Performance

Ein Agent kann eine Worker-Klasse innerhalb von Sekunden erstellen. Das sagt jedoch nichts darüber aus, ob der Worker die Lebenszyklusregeln, Wiederholungs- und Einschränkungsvorgaben Ihrer App berücksichtigt.

Architektur als Einschränkungen für Agenten

Architekturwissen erhält eine neue Bedeutung. Muster wie MVI und MVVM, Clean Architecture, Modulgrenzen, Repositorien, DI, Zustandsverwaltung und Domänengetrennung sind nicht nur Möglichkeiten zur Codeorganisation; sie werden zu den Vorgaben, die man einem Agenten übermittelt. Anstatt „eine Funktion erstellen“ zu sagen, kann man folgende Anweisung geben:

Erstelle diese Funktion unter Verwendung unserer bestehenden MVI-Architektur. Spiegle die Muster aus Funktion A und Funktion B wider. Füge keine neuen Abhängigkeiten hinzu. Geschäftsregeln gehören in die Domäneschicht.

Die Verwendung bestehender Funktionen ist besonders effektiv, denn sie weist den Agenten auf konkrete, überprüfte Beispiele im Codebase hin, anstatt sich auf seine allgemeine Vorstellung von „MVI“ zu verlassen. Die Architektur wird Teil der Sprache, die man verwendet, um Agenten anzuleiten.

Anweisungen auf Repositorieebene mit AGENTS.md

Viele Teams wiederholen in jeder Sitzung dieselben Erinnerungen: Das Projekt verwendet Kotlin und Hilt, die Geschäftslogik bleibt außerhalb der Composables, der Zustand wird mit StateFlow bereitgestellt, es gelten Namenskonventionen, Tests sind erforderlich, und generierte Dateien dürfen nicht verwendet werden.

Diese Erwartungen können im Repository selbst festgehalten werden. Zum Zeitpunkt der Niederschrift liest das Gemini-Tool von Android Studio AGENTS.md-Dateien, in denen solche Präferenzen aufgezeichnet sind, sodass der Agent sie als Projektkontext wahrnimmt. Andere Agenten lesen ähnliche Dateien; dieselbe Idee wird ausführlich in einem praktischen Leitfaden zur Erstellung einer effektiven CLAUDE.md-Datei behandelt.

Es handelt sich um eine kleine Änderung mit großen Konsequenzen. Ein Repository enthielt traditionell:

source code
configuration
tests
documentation

Nun kann es auch Folgendes enthalten:

AI engineering instructions

Die Codebasis beschreibt sowohl die Software selbst als auch, wie ein Agent mit ihr arbeiten sollte. Behandeln Sie diese Anweisungen wie Code: Überprüfen Sie Änderungen daran, halten Sie sie kurz und präzise und löschen Sie Regeln, die nicht mehr gelten.

MCP verbindet den Agenten mit dem Rest der Toolchain

Das Model Context Protocol ermöglicht es KI-Systemen, sich mit externen Tools und Diensten zu verbinden, was bedeutet, dass der Agent nicht mehr auf ein Chat-Fenster beschränkt ist. Über MCP-Server kann er potenziell auf Folgendes zugreifen:

GitHub
Databases
Design tools
Documentation
Issue trackers
CI systems
Cloud services
Internal APIs

Android Studios KI-Tools unterstützen derzeit die Verbindung zu MCP-Servern, einschließlich solcher im Fernzugriff. Man stelle sich eine einzige Anfrage vor, bei der vom Agenten verlangt wird, ein neues Profilbildschirm basierend auf einer Figma-Datei zu erstellen, die vorhandenen Design-Tokens wiederverzuenden, den Bildschirm mit dem Profil-Endpunkt zu verbinden, Lade- und Fehlerzustände zu handhaben, Tests hinzuzufügen und einen Pull Request vorzubereiten. Die Erfüllung dieser Aufgabe betrifft gleichzeitig viele Systeme:

Developer
    ↓
AI Agent
    ├── Figma
    ├── Codebase
    ├── Documentation
    ├── API
    ├── Tests
    ├── Git
    └── CI

Sobald ein Tool Designdateien, Code, Dokumentation, APIs, Tests, Git und CI koordiniert, ist „Code-Generator“ eine falsche Beschreibung. Es handelt sich dabei um einen Engineering-Agenten, und gerade sein Umfang erklärt, warum Berechtigungen und Überprüfungen wichtig sind: Jedes verbundene System ist etwas, das der Agent lesen oder ändern kann.

Die Falle: abhängig, aber nicht fähig

Diese neue Konfiguration weist einen typischen Fehlermodus auf. Ein Entwickler kann abhängig von KI werden, ohne wirklich damit umgehen zu können. Es ist durchaus möglich, Code zu erstellen, der all diese Elemente verwendet:

Flow
StateFlow
SharedFlow
CoroutineScope
SupervisorJob
Channel

ohne zu verstehen, was jede dieser Komponenten bewirkt. Alles läuft, die Arbeit erscheint schnell – doch Monate später tritt in der Produktion eine Rennbedingung auf, die mit der Stornierung des Lebenszyklus zusammenhängt und von niemandem im Team erklärt werden kann.

KI beschleunigte das Tippen; sie machte den Entwickler jedoch nicht besser. Deshalb wird es zunehmend wichtiger, das von der KI Erstellte zu überprüfen, anstatt nur in der Lage zu sein, es selbst zu generieren. Eine praktische Regel für Teams: Niemand soll Code zusammenführen, den er in einer Überprüfung nicht Zeile für Zeile erklären kann.

Kontext ist der eigentliche Hebel

Code-Agenten sind stark von dem Kontext abhängig, den sie erhalten. Die Dokumentation von Cursor beschreibt beispielsweise ein Agentensystem in Bezug auf Kontext, Werkzeuge, Anweisungen und Modelle. Das deutet auf eine grobe multiplikative Beziehung hin:

Agent Quality
=
Model
× Context
× Tools
× Instructions
× Verification

Die Multiplikation ist der entscheidende Aspekt. Ein starkes Modell, das mit einem schlechten Kontext arbeitet, erzeugt schlechte Software, da ein nahe nuller Faktor das gesamte Ergebnis nach unten zieht. Ein solides Modell, das in einem gut strukturierten Repository mit klarer Architektur, zuverlässigen Tests, nützlichen Dokumentationen und präzisen Anweisungen arbeitet, kann deutlich bessere Ergebnisse liefern. Die entscheidende Fähigkeit besteht darin, den Kontext zu gestalten – wobei die Formulierung von Prompts nur ein Teil davon ist.

Warum „Prompt Engineering“ zu eng gefasst ist

Der Unterschied lässt sich leicht nebeneinander erkennen. Ein einfacher Prompt sieht so aus:

"Create a login screen."

Eine kontextbasiert gestaltete Anfrage sieht so aus:

Here is our architecture.
Here are our design rules.
Here is the API contract.
Here are existing authentication patterns.
Here are the tests.
Here are the project constraints.
Here is the expected behavior.
Now implement the feature and verify it.

Die zweite Version übermittelt dem Agenten die Architektur, Designregeln, API-Verträge, vorhandene Authentifizierungsmodelle, Tests, Einschränkungen sowie das erwartete Verhalten und bittet ihn anschließend, sowohl um Implementierung als auch um Überprüfung zu kümmern. Das kommt dem Verfahren sehr nahe, wie man einen neuen Kollegen einweist, wobei die Anfrage nur ein Bestandteil davon ist. Wenn sich ein Agent falsch verhält, lohnt es sich, herauszufinden, welche dieser Komponenten fehlte; unser Leitfaden zu der Fehlersuche bei KI-Agenten schichtweise erklärt diese Diagnosemethoden ausführlich.

Der Ingenieur entwirft den gesamten Ablauf

Die größte Veränderung liegt möglicherweise darin, wo die Verantwortlichkeiten liegen. Die alte Struktur war direkt:

Developer → Code

Die neue Struktur umfasst mehrere Phasen, und der Ingenieur ist für alle davon verantwortlich:

Developer
    ↓
Specification
    ↓
Agent
    ↓
Tools
    ↓
Code
    ↓
Tests
    ↓
Verification

Die Kontrolle über die Schleife bedeutet, zu wissen, welche Anweisung eine Situation erfordert:

• "Mach es einfach“, wenn die Aufgabe klar definiert ist und ein geringes Risiko besteht.
• ">Planen Sie zuerst“, wenn sich die Änderung auf mehrere Module erstreckt.
• ">Lassen Sie den Code vorerst in Ruhe und studieren Sie zunächst die Architektur“, wenn Sie ein Verständnis vor den Änderungen benötigen.
• ">Reproduzieren Sie den Fehler“, bevor Sie eine Lösung annehmen.
• ">Stopp; Ihre Annahme ist falsch“, wenn der Agent zuversichtlich in die falsche Richtung geht.

Diese letzte Maßnahme kann sich als eine der wertvollsten Fähigkeiten überhaupt erweisen – und hängt vollständig davon ab, die Plattform gut genug zu kennen, um fehlerhafte Annahmen zu erkennen.

Niemand, der Android-Entwickler noch Prompt-Engineer ist

Auch eine der beiden Bezeichnungen beschreibt die Rolle allein nicht vollständig. Ein Android-Entwickler, der ausschließlich manuell in Kotlin programmiert, wird in Bezug auf Effizienz zurückbleiben. Jemand, der eine KI um Hilfe bei Kotlin bitten kann, aber kein Verständnis für die Android-Architektur hat, wird früher oder später in Schwierigkeiten geraten. Die ideale Kombination sieht so aus:

Android Engineering
        +
AI Agent Skills
        +
System Design
        +
Context Engineering
        +
Verification
        =
AI-Augmented Android Engineer

In der Praxis bedeutet das, sein Wissen über Android zu vertiefen, das Verständnis für die Architektur auszubauen, zu lernen, Anforderungen präzise an Maschinen weiterzugeben, sowie sich mit Agenten, deren Werkzeugen, MCP, Repository-Anweisungen und automatisierten Überprüfungen vertraut zu machen. Vor allem bedeutet es, erkennen zu können, wann die KI falsch liegt. Ein Agent kann problemlos zweitausend Zeilen generieren; ein Ingenieur muss jedoch beurteilen, ob diese Zeilen überhaupt notwendig sind.

Die realistischere Zukunft besteht nicht darin, dass KI Entwickler ersetzt, sondern darin, dass Entwickler, die gut mit Agenten zusammenarbeiten, Workflows ersetzen, die dies nicht tun. Ein Ingenieur mit soliden Grundkenntnissen und einer gut konfigurierten Agenteninfrastruktur kann potenziell das erreichen, was früher viel mehr manuelle Arbeit erforderte. Das Ingenieurwesen verschwindet nicht; es entwickelt sich auf ein höheres Niveau, bei dem logisches Denken, die Definition von Einschränkungen und die Überprüfung der Ergebnisse wichtiger sind als reine Tastatureingaben, und bei dem die Architektur als Karte dient, um zu verhindern, dass die Agenten vom Weg abkommen.

Kernpunkte

• Betrachten Sie Anweisungen an einen Agenten als Spezifikationen: Nennen Sie die verwendeten Technologien, Leistungsentscheidungen, Anforderungen an Widerstandsfähigkeit, Verträge, den Testumfang sowie das, was unverändert bleiben muss.
• Überprüfen Sie den generierten Code, indem Sie das umgebende System analysieren (Zustandsverwaltung, Lebenszyklus, Prozessbeendigung, Konkurrenz, Stornierung), anstatt nur zu prüfen, ob er kompiliert.

Investieren Sie in die Grundlagen – sie ermöglichen es Ihnen, schnelle, plausibel erscheinende, aber falsche Implementierungen aufzudecken.

Übertragen Sie die Teamkonventionen in instruktive Dateien auf Repository-Ebene wie AGENTS.md und pflegen Sie diese wie Code.

Verbessern Sie die Ergebnisse, indem Sie den Kontext (Architektur, Tests, Dokumentation, Beispiele) verbessern – schließlich begrenzt ein schwacher Faktor das gesamte Ergebnis.

Bleiben Sie der Verantwortliche für den Ablauf: Entscheiden Sie, wann der Agent handeln, planen, untersuchen, nachbilden oder aufhören soll.