AI für Android-Entwicklung: Erfahrung eines Nicht-Entwicklers

Nicht-Entwickler baut und pflegt Android-Apps mit KI: Zwischenauswertung

Ein Business-Analyst ohne jegliche Programmiererfahrung hat zwei Android-Apps ausschließlich mit KI-Chat (Claude) und Android Studio gestartet. Die Rolle des Menschen: Aufgaben definieren, Testen, Änderungen integrieren und deployen. Die KI übernimmt Code-Generierung, Fehlerdiagnose und Architekturvorschläge. Ziel: Prüfen, ob dieser Ansatz ein echtes Produkt mit realen Nutzern halten kann, inklusive Bugfixes und neuer Features.

Die Methode hat sich weiterentwickelt: Von der Generierung neuer Features aus dem Nichts hin zu minimalen Diffs und Fixes. KI-Aufgaben enthalten Kontext wie Symptome, Reproduktionsschritte, Einschränkungen (keine neuen Bibliotheken, Datenpersistenz) und Error-Logs.

Tools und Workflow

Wichtige Komponenten:

• Claude: Code-Generierung, Build-Fehleranalyse, Vorschläge für persistente Speicherung und Activity-Lifecycle.
• Android Studio: Bauen, Emulation, manuelle Integration von Änderungen.
• RuStore: Veröffentlichen, Feedback sammeln, Updates deployen.

Bug-Report-Format für KI:

• Symptom-Beschreibung und erwartetes Verhalten.
• Reproduktionsschritte.
• App-Version und Einschränkungen.
• Vorherige Fix-Versuche mit Logs.

KI antwortet mit: Wahrscheinliche Ursache, zu prüfende Dateien, 2–3 Lösungsoptionen mit Risiken, dann Patches.

Ergebnisse nach dem Launch

Veröffentlichte Apps:

• „168 Stunden“ — Planer basierend auf einem 168-Stunden-Wochenbudget.
• „F1 Tycoon“ — Simulator.

Nach dem ersten Artikel stiegen die Downloads rasant: „168 Stunden“ von 1 auf 71, „F1 Tycoon“ von 13 auf 45. Reale Nutzer meldeten Bugs in ungetesteten Szenarien.

Fall 1: Timer-Reset beim Neustart

Symptom: Timer starten → App verlassen → zurückkehren → auf Null zurückgesetzt. KI-Lösung: Umstellung von gespeicherter verstrichener Zeit auf Start-Zeitstempel mit Neuberechnung. Fix dauerte 2 Stunden (Diagnose + Build + Deploy). Problem lag am Activity-Lifecycle und fehlender persistenter Speicherung.

Fall 2: Manuelle Aktivitätserstellung

Neues Feature: Nutzer erfassen eigene Einträge. KI schlug Integration in Datenmodelle, Screens und Speicher vor, mit Validierung von Edge-Cases (leere Felder, Listen-Updates).

Verständnis der Projektstruktur gewonnen

Ohne tiefes Syntaxwissen entstand ein operatives Modell:

• Klassen: Trennung von Screens, Modellen, Speicher.
• Datenmodelle: Änderungen wirken sich auf UI und Persistenz aus.
• Zustand: Hauptbug-Quelle — Lifecycle, Neustarts, Threads.
• Logik vs. Daten: Screens für UI, Speicher für Daten.

Das ermöglicht präzise KI-Prompts, die auf Systemknoten abzielen.

Grenzen des Ansatzes

Projektintegrität: KI erzeugt lokale Änderungen, übersieht aber Abhängigkeiten. Mensch besitzt die Architektur.

Debugging: Funktioniert bei reproduzierbaren Bugs (Timer, Zustand). Flüchtige Probleme (Konkurrenz, gerätespezifisch) erfordern Logs und Iterationen.

UI/UX: Funktionalität erreicht, aber Ergonomie leidet ohne Nutzerdaten.

Wartung: Feedback als Anforderungen, Updates als separate Prozesse mit Abwärtskompatibilität.

Grenze: Tauglich für Releases und Fixes, erfordert aber Basis-Skills (Lifecycle, State-Management).

Wichtige Erkenntnisse

• Reale Nutzer (71+45 Installationen) brachten Bugs ans Licht, Entwicklung vom Prototyp zum Produkt.
• Fixes (Timer, Features) in 2 Stunden mit KI-Unterstützung.
• Mensch als Integrator: Testet, deploied, versteht Struktur.
• Grenzen: Architektur und komplexes Debugging beim Menschen.
• Ausblick: Apps laufen und werden gepflegt.

Entwicklungspläne

• „168 Stunden“ stabilisieren: Checklisten testen, zuverlässige Timer-Zustände.
• Iterative Features: Nur innerhalb der aktuellen Architektur.
• Basis-Skills: Lifecycle, Diagnostik, Struktur.
• Nächster Bericht zu Metriken (Bugs, Updates, Trends).

— Editorial Team