Wie viel App-Entwicklung kann KI heute wirklich übernehmen?

KI-generierter Code ist mittlerweile nichts Besonderes mehr. Ein Prompt, wenige Sekunden warten und schon entsteht eine Kotlin-Funktion, ein SwiftUI-Screen oder ein erster API-Client.

Für professionelle App-Entwicklung ist das allerdings nur ein kleiner Teil dessen, was KI leisten kann.

Viel interessanter ist für mich die Frage:

Wie lässt sich KI über den gesamten Entwicklungsprozess einsetzen, ohne dabei die Kontrolle über Architektur, Codequalität und Wartbarkeit zu verlieren?

Daraus hat sich für mich ein Workflow entwickelt, bei dem KI nicht meine Entwicklungsumgebung oder meine Erfahrung als Entwickler ersetzt, sondern an verschiedenen Stellen gezielt unterstützt:

Idee → Design → Design-Review → Architektur → Implementierung → Tests → Code Review → Git

Dabei geht es ausdrücklich nicht darum, möglichst viel Code automatisch erzeugen zu lassen.

Entscheidend ist vielmehr, an welchen Stellen KI tatsächlich Entwicklungszeit spart und wie sie sich kontrolliert in einen professionellen Entwicklungsprozess integrieren lässt.

Als durchgängiges Beispiel verwende ich eine White-Label-Zeiterfassungs-App für Android und iOS.

Das Beispielprojekt: eine White-Label-Zeiterfassung

Als Beispiel dient eine Zeiterfassungs-App, deren Branding später je nach Kunde angepasst werden kann.

Ein Mitarbeiter öffnet die App und sieht direkt:

• seinen aktuellen Arbeitsstatus
• die bisherige Arbeitszeit
• Pausen
• die Buchungen des aktuellen Tages
• eine zentrale Aktion zum Ein- oder Auschecken

Später lassen sich Funktionen wie Urlaubsanträge, Korrekturen, Abwesenheiten, Mitarbeiterverwaltung oder unterschiedliche Unternehmens-Brandings ergänzen.

Der White-Label-Gedanke ist dabei bewusst gewählt: Farben, Logo und Markenauftritt können austauschbar sein, während die technische Basis identisch bleibt.

Als durchgängiges Beispiel dient zunächst der zentrale Check-in-Screen. An ihm lässt sich der komplette Workflow vom ersten Design bis zum reviewten Android- und iOS-Code sehr gut nachvollziehen.

Schritt 1: Claude Code als Entwicklungsagent

Für meinen KI-gestützten Workflow nutze ich Claude Code.

Der entscheidende Unterschied zu einem normalen KI-Chat liegt darin, dass Claude Code direkt im lokalen Projekt arbeitet.

Claude kann unter anderem:

• Projektdateien lesen
• Code verändern
• neue Dateien erzeugen
• Git-Diffs analysieren
• Builds ausführen
• Tests starten
• externe Werkzeuge über MCP anbinden

Meine gewohnten Entwicklungsumgebungen verschwinden dadurch nicht.

Für Android arbeite ich weiterhin mit Android Studio, für iOS weiterhin mit Xcode.

Claude Code verhält sich vielmehr wie ein zusätzlicher Entwickler, der auf demselben Git-Repository arbeitet.

Ich kann zum Beispiel einen Screen von Claude implementieren lassen, anschließend selbst Änderungen in Android Studio vornehmen und danach Claude bitten, genau diese Änderungen zu reviewen.

Das funktioniert deshalb so gut, weil es keinen separaten „KI-Projektstand“ gibt.

Am Ende liegen ganz normale Kotlin-, Compose- und Swift-Dateien im Repository.

Schritt 2: Von der Idee zum editierbaren Design

Ein wichtiger Punkt in meinem Workflow ist die klare Trennung zwischen Design und Implementierung.

Ich möchte nicht einfach sagen:

„Erstelle mir einen Compose-Screen.“

Denn dann entscheidet die KI gleichzeitig über Design und technische Umsetzung.

Sinnvoller ist für mich:

Produktidee → Design → Review → Freigabe → Implementierung

Das Design dient damit als visuelle Source of Truth.

Ich kann es öffnen, prüfen und zum Beispiel sagen:

Der obere Bereich gefällt mir, aber der Button sollte größer sein und eine andere Farbe bekommen.

Erst wenn das Design freigegeben ist, beginnt die Implementierung.

Figma oder Penpot?

Figma ist für einen solchen Workflow grundsätzlich sehr interessant und lässt sich über einen offiziellen MCP-Server mit Claude Code verbinden.

In der Praxis ist allerdings das Lizenzmodell zu beachten.

Im kostenlosen Figma-Starter-Plan stehen für bestimmte MCP-Zugriffe nur sehr wenige Aufrufe pro Monat zur Verfügung. Für einen agentischen Workflow kann dieses Kontingent extrem schnell aufgebraucht sein.

Diese Erfahrung war für mich ein wichtiger Hinweis:

Eine vorhandene KI-Integration ist nicht automatisch auch in jedem Tarif produktiv nutzbar.

Für meinen aktuellen Workflow nutze ich deshalb Penpot als editierbare Designquelle.

Entscheidend ist dabei weniger das konkrete Tool als das Prinzip:

Das freigegebene Design existiert unabhängig vom App-Code und dient Android und iOS als gemeinsame visuelle Referenz.

---

Ein schneller HTML-Prototyp kann trotzdem sinnvoll sein

Ein überraschend praktischer Zwischenschritt ist ein durch die KI erzeugter HTML/CSS-Prototyp.

Innerhalb weniger Minuten lässt sich so eine Produktidee direkt im Browser sichtbar machen.

Für eine finale Designfreigabe ist HTML allerdings weniger komfortabel als ein visuelles Design-Tool.

Deshalb nutze ich einen solchen Prototyp vor allem als schnelle Ideenskizze – nicht als endgültige Source of Truth.

Schritt 3: Kotlin Multiplatform als gemeinsame technische Basis

Für das Beispielprojekt nutze ich Kotlin Multiplatform.

Dabei teile ich bewusst nicht die komplette Benutzeroberfläche.

Gemeinsam genutzt werden vor allem:

• Domain Models
• Repositories
• Networking
• Ktor
• Businesslogik
• Mapper
• Validierung

Die Benutzeroberflächen bleiben nativ:

• Android: Jetpack Compose
• iOS: SwiftUI

Auch die Presentation Layer bleiben bewusst plattformspezifisch.

Android arbeitet mit eigenen ViewModels, iOS mit einem eigenen SwiftUI-orientierten Presentation Layer.

---

Das Design bleibt für beide Plattformen identisch, die Implementierung darf aber plattformgerecht sein.

Genau das ist für mich ein entscheidender Unterschied zwischen Code teilen und Architektur sinnvoll teilen.

Schritt 4: Vom freigegebenen Design zu Compose und SwiftUI

Nach der Designfreigabe kann Claude den Screen direkt im bestehenden Projekt implementieren.

Dabei schreibe ich Claude nicht jede einzelne Datei vor.

Ein Auftrag kann deshalb relativ knapp ausfallen:

„Das Design ist freigegeben. Implementiere den Screen entsprechend dem Penpot-Design und unserem Engineering Contract für Android und iOS.“

Claude analysiert daraufhin die bestehende Struktur und setzt die beiden nativen Varianten um.

Das Ergebnis sind zwei voneinander unabhängige, aber auf derselben visuellen Grundlage basierende Implementierungen:

Jetpack Compose für Android und SwiftUI für iOS.

Wichtig ist für mich dabei:

Claude soll SwiftUI nicht einfach als Übersetzung des Compose-Codes betrachten.

Beide Plattformen sollen idiomatisch bleiben.

Ein guter Coding-Agent sollte verstehen, was ein Screen tut und wie er aussehen soll – und nicht nur Syntax von Kotlin nach Swift übertragen.

Schritt 5: Der KI den eigenen Coding Style beibringen

Genau hier beginnt für mich der eigentlich interessante Teil von KI-gestützter Entwicklung.

Funktionierenden Code zu erzeugen ist mittlerweile relativ einfach.

Schwieriger ist es, dafür zu sorgen, dass sich ein Coding-Agent dauerhaft an die Architektur und den Entwicklungsstil eines Projekts hält.

Deshalb liegen die Regeln direkt im Repository.

Zum Beispiel:

CLAUDE.md

docs/
├── philosophy.md
├── architecture.md
├── android-style.md
├── ios-style.md
└── review-guidelines.md

Darin stehen nicht nur Technologien, sondern auch Entwicklungsphilosophie.

Zum Beispiel:

• Reactive State
• ViewModels
• Koin für Dependency Injection
• Ktor für Networking
• möglichst stateless Compose Components
• klare Verantwortlichkeiten
• keine unnötigen Abstraktionen
• kein Overengineering
• Accessibility als Teil der Implementierung
• bestehende Projektkonventionen vor generischen Best Practices

Der entscheidende Gedanke lautet:

Die KI soll sich an das Projekt anpassen – nicht das Projekt an die KI.

---

---

Das Regelwerk kann dabei entweder aus bestehendem, guten Code abgeleitet werden oder bewusst neu definiert werden.

Gerade wenn ältere Projekte historisch gewachsen und inkonsistent sind, kann es sogar sinnvoller sein, den gewünschten heutigen Entwicklungsstil explizit festzuhalten.

---

Schritt 6: Vom Jira-Ticket zur fertigen Funktion

Nachdem Architektur, Coding Style und Projektregeln definiert sind, stellt sich die nächste Frage:

Wie bekommt Claude eigentlich den konkreten Arbeitsauftrag?

In meinem aktuellen Workflow übernimmt Jira diese Rolle. Dort liegen die Anforderungen, Akzeptanzkriterien und der aktuelle Status einer Story. Claude Code kann das Ticket über MCP lesen und daraus ableiten, was als Nächstes zu tun ist.

Besonders interessant wird das bei UI-Features. Ist für eine Story noch kein freigegebenes Design vorhanden, soll Claude nicht einfach mit der Implementierung beginnen. Stattdessen wird zunächst ein Design in Penpot erstellt oder angepasst und mit dem Jira-Ticket verknüpft.

Erst nach der menschlichen Freigabe beginnt die eigentliche Umsetzung.

Dadurch entsteht ein klar definierter Ablauf:

Das Spannende daran ist für mich:

Der Prompt selbst wird immer kleiner, weil der Prozess drumherum immer klarer wird.

Ein Auftrag kann am Ende tatsächlich nur noch lauten:

„Bearbeite das Ticket.“

Anforderungen und Akzeptanzkriterien kommen aus Jira, das freigegebene Design aus Penpot und Architektur-, Coding- und Review-Regeln aus dem Repository.

Claude muss diese Informationen also nicht bei jeder Aufgabe erneut über einen riesigen Prompt bekommen. Stattdessen kennt der Agent den definierten Entwicklungsprozess und arbeitet innerhalb der vorgegebenen Regeln.

Genau hier wird für mich aus einem reinen Coding-Assistenten langsam etwas anderes: ein Entwicklungs-Agent, der sich innerhalb eines bestehenden Prozesses selbstständig bewegen kann – ohne dass ich die Kontrolle über die entscheidenden Schritte abgebe.

Schritt 7: Ich programmiere weiterhin selbst

KI-gestützte Entwicklung bedeutet für mich ausdrücklich nicht, die Kontrolle über den Code abzugeben.

Ich möchte weiterhin jederzeit selbst in Android Studio oder Xcode arbeiten können.

Der Workflow sieht eher so aus:

Claude implementiert → ich prüfe → ich ändere selbst → Claude arbeitet mit dem aktuellen Stand weiter

Da Claude direkt auf demselben lokalen Git-Repository arbeitet, braucht es dafür keinen besonderen Synchronisationsprozess.

Eine Änderung, die ich in Android Studio speichere, ist beim nächsten Auftrag einfach Bestandteil des Projektstands.

---

Wenn morgen ein anderer Coding-Agent eingesetzt wird oder gar keine KI mehr genutzt wird, bleibt das Projekt trotzdem eine normale, wartbare Android- und iOS-Anwendung.

Das ist aus meiner Sicht besonders für langfristige Kundenprojekte wichtig.

Schritt 8: Claude Code als zusätzlicher Reviewer

Einer der praktischsten Anwendungsfälle ist für mich inzwischen das Code Review.

Ein Coding-Agent sollte nicht nur Code erzeugen.

Er kann anschließend bewusst die Rolle wechseln und den aktuellen Git-Diff gegen die Projektregeln prüfen.

In einem Test habe ich dazu absichtlich problematischen Code eingebaut und Claude ausschließlich mit dem Review beauftragt.

Wichtig dabei:

Claude durfte zunächst nichts verändern.

Er sollte Findings auflisten und priorisieren:

• Critical
• Important
• Suggestion

Geprüft wurden unter anderem:

• Architekturverstöße
• falsches State Management
• ViewModel-Probleme
• Lifecycle und Coroutines
• Fehlerbehandlung
• Accessibility
• fehlende Tests
• unnötige Komplexität
• mögliche Regressionen

Erst nachdem ich die Findings bewertet hatte, durfte Claude die akzeptierten Punkte beheben.

Danach folgte ein erneuter Self-Review.

---

---

Für mich ist das ein wichtiger Unterschied zu blindem AI Coding.

Die KI entscheidet nicht selbst, welche Kritik umgesetzt wird.

Der Entwickler bleibt die Kontrollinstanz.

Schritt 9: Tests und Qualitätssicherung

Auch bei Tests kann KI sinnvoll unterstützen.

Gerade interessant finde ich dabei, Testfälle nicht nur aus bestehendem Code abzuleiten, sondern aus Anforderungen und erwartetem Verhalten.

Dazu gehören beispielsweise:

• Kotlin Unit Tests
• ViewModel Tests
• Compose UI Tests
• Swift Unit Tests
• iOS UI Tests
• Snapshot- oder Screenshot-Tests

Langfristig lässt sich sogar noch ein Schritt weiterdenken:

Design → gerenderter Screen → visueller Vergleich

Damit könnte die Schleife vom vereinbarten Design bis zum tatsächlich gerenderten UI zusätzlich automatisiert abgesichert werden.

Wichtig bleibt allerdings auch hier:

KI-generierte Tests sind nur dann sinnvoll, wenn sie Verhalten prüfen – und nicht einfach die bestehende Implementierung nachbauen.

Git bleibt die Wahrheit

Egal wie viel Arbeit ein KI-Agent übernimmt:

Jede Änderung landet weiterhin ganz normal in Git.

Das ermöglicht:

• nachvollziehbare Diffs
• Branches
• Pull Requests
• Rollbacks
• menschliche Reviews
• CI
• eine saubere Historie technischer Entscheidungen

Die KI bekommt keine Sonderrolle.

Sie arbeitet innerhalb derselben Regeln wie ein menschlicher Entwickler.

Das ist für mich eine der wichtigsten Voraussetzungen dafür, KI auch in professionellen Projekten sinnvoll einzusetzen.

Was bringt KI-gestützte Entwicklung dem Kunden?

Für Kunden ist am Ende nicht entscheidend, welches KI-Modell oder welches MCP-Protokoll verwendet wird.

Entscheidend ist der konkrete Nutzen.

---

Dabei bedeutet KI-Unterstützung nicht automatisch, dass jede App plötzlich nur noch einen Bruchteil der bisherigen Entwicklungskosten verursacht.

Architektur, Produktverständnis, UX, Plattformwissen, Testing und technische Entscheidungen verschwinden nicht.

Der Vorteil entsteht dort, wo ein erfahrener Entwickler entscheiden kann, welche Aufgaben sinnvoll an die KI delegiert werden können – und welche nicht.

Genau dadurch bleibt mehr Zeit für die Bereiche, bei denen Erfahrung tatsächlich den Unterschied macht.

Fazit: Von AI Coding zu KI-gestütztem Engineering

KI kann heute weit mehr als einzelne Code-Snippets erzeugen.

Richtig interessant wird sie für mich aber erst, wenn sie Teil eines kontrollierten Entwicklungsprozesses wird.

Das Design bleibt überprüfbar.

Die Architektur wird vom Entwickler vorgegeben.

Coding Standards liegen versioniert im Repository.

Android Studio und Xcode bleiben Bestandteil des normalen Workflows.

Änderungen landen in Git.

Und KI-generierter Code wird genauso reviewed und getestet wie selbst geschriebener Code.

Genau darin liegt für mich der Unterschied zwischen einfachem „Vibe Coding“ und professioneller KI-gestützter App-Entwicklung.

Die Frage ist nicht mehr, ob KI Code schreiben kann.

Die entscheidende Frage ist, wie wir sie einsetzen, ohne die Kontrolle über Qualität, Architektur und Produkt zu verlieren.

Richtig eingesetzt kann KI Entwicklungszyklen verkürzen, POCs und MVPs schneller realisierbar machen und erfahrene Entwickler von repetitiver Arbeit entlasten.

Sie ersetzt dabei nicht die Erfahrung des Entwicklers.

Sie verstärkt sie.