Wenn die KI deine Flutter-App schreibt: Was funktioniert und was skaliert

Zwei Talks, eine Frage

Auf der FlutterCon 2026 habe ich zwei Vorträge gehört, die auf den ersten Blick nichts miteinander zu tun haben. Der eine kam von einer Agentur, die eine komplett per Vibe-Coding gebaute App retten musste. Der andere vom Flutter-Team bei Google, das erklärt hat, warum Flutter in Zeiten von KI-Agenten gut skaliert.

Beide beantworten dieselbe Frage: Was passiert eigentlich, wenn eine KI einen großen Teil deiner App schreibt?

Ich arbeite selbst täglich so. Deshalb habe ich genau hingehört.

Teil 1: Von der Vibe-Coding-MVP zur Produktion in 90 Tagen

Óscar Martín von Very Good Ventures hat erzählt, wie sein Team die App Divine übernommen hat. Divine ist eine Neuauflage von Vine mit Flutter. Der Gründer kannte Flutter vorher gar nicht und hat den ersten Stand in wenigen Wochen per Vibe-Coding gebaut.

Das Ding ist durch die Decke gegangen. Nach der Präsentation auf dem Web Summit in Lisbon war das TestFlight-Limit von 10.000 Nutzern innerhalb weniger Stunden voll.

Gleichzeitig war die App instabil. Nach ein paar Minuten Scrollen wurde das Handy heiß, die Authentifizierung machte Probleme, der Akku ging in die Knie.

Das Gute am Vibe-Coding

Martín fand das Gute an der Sache ziemlich klar:

• Ein Gründer mit einer Vision hat in kurzer Zeit einen funktionierenden Prototyp gebaut.
• Features, die Nutzer im Discord gewünscht haben, waren am nächsten Morgen drin.
• Am Ende stand fest, dass Leute die App wirklich wollen. Vor ein paar Jahren hast du dafür oft ein Jahr entwickelt und danach gemerkt, dass es niemand braucht.

Das deckt sich mit meiner Erfahrung. Für Validierung ist schnell gebauter Code Gold wert. Mehr dazu in meinem Artikel über schneller shippen statt perfektionieren.

Das Schlechte

Dann hat Martín zum ersten Mal in den Code geschaut. Sein Eindruck war ein deutliches "Ouch".

• Die Architektur war überall verstreut. Der Video-Feed existierte zeitweise in sechs, sieben Varianten, je nachdem ob du Videos im Profil oder auf dem Home-Screen gesehen hast.
• Die CI/CD-Pipeline war unzuverlässig. Pull Requests haben Tests gelöscht, weil man den Tests nicht trauen konnte. Viele waren nur für die Coverage geschrieben.
• Das Repository war Open Source, der Gründer hat teilweise über 10 PRs am Tag erstellt.

Agenten sind laut Martín sehr gut darin, bestehende Muster zu erweitern. Wenn der Feed einmal kopiert wurde, wird er eben wieder kopiert. Es gab keine Regel, die gesagt hat: Nutze die Komponente, die schon da ist.

Architektur ist wichtiger denn je

Das ist für mich die wichtigste Aussage aus dem ersten Talk. Martín sagt, dass Architektur mit KI wichtiger ist als vorher, nicht unwichtiger.

Sein Gedanke: Auch wenn du den Code nicht mehr selbst tippst, schreibt ihn dein Agent. Und der braucht ein Fundament, das er nachbauen kann. Bei Very Good Ventures nennen sie das "boring code". Du öffnest eine Klasse und weißt sofort, was sie tut. Je vorhersehbarer die Struktur, desto besser repliziert ein Agent sie.

Dafür haben sie einen Ansatz namens Feature-First Clean Architecture entwickelt. Er mischt klassische Clean Architecture mit dem, was sie bei Very Good Ventures schon länger machen. Das Ziel: eine Architektur, die für Menschen und für Agenten funktioniert.

Ich glaube, das ist der unterschätzte Teil. Viele denken, KI macht Architektur-Disziplin überflüssig. Bei mir ist es genau andersherum. Je mehr Code ein Agent schreibt, desto wichtiger sind klare Strukturen. Wie ich das in Flutter angehe, habe ich in meinem Artikel zum State Management 2026 beschrieben.

Kein Rewrite, sondern kleine Squads

Eine Frage kam im Talk natürlich auf: Warum nicht einfach neu bauen?

Martín sagt, es war sein erster Gedanke. Aber die 10.000 Nutzer haben jeden Tag nach neuen Features gefragt. Einen Monat oder zwei zu pausieren, kam nicht in Frage. Also haben sie sich anders organisiert:

• Kleine Squads mit zwei bis drei Leuten, zum Beispiel für Account, Feed oder Video-Player.
• Jede Woche wechselt der Fokus. Wenn gerade die Account-Bugs dran sind, nutzt das Video-Squad die Zeit für kleine Refactorings und führt zwei, drei Feed-Varianten zusammen.
• Nutzer merken davon nichts, aber die Codebasis wird Stück für Stück sauberer.

Ein Greenfield-Projekt wäre ihm in dem Fall lieber gewesen, sagt er offen. Aber manchmal ist der inkrementelle Weg der einzig mögliche.

30 bis 50 PRs am Tag überleben

Bei so vielen Pull Requests funktioniert klassisches Review nicht mehr. Martín hat in der ersten Woche versucht, alles selbst zu prüfen, und hat gemerkt: Dann machst du den ganzen Tag nichts anderes.

Das hat sein Team geändert:

• CI/CD und Lint-Regeln ausbauen. Alles Wiederholbare gehört in deterministische Checks oder Pre-Commit-Hooks. Falls du dafür eine Auffrischung brauchst: Was ist CI/CD?
• Agent-Regeln als zweite Schicht. Sie sind nicht deterministisch und werden manchmal ignoriert, aber besser als nichts.
• Menschliche Reviews auf Architektur fokussieren. Nicht mehr "diese Zeile gefällt mir nicht", sondern: Ist das Feature verständlich geschnitten? Passt es zur Struktur?
• Agenten-Review über ein Skill. Das kostet laut Martín viele Tokens, ist es ihm aber wert. Seine Begründung sinngemäß: Er soll seine Zeit in Urteilsvermögen stecken, nicht in Zeilenkosmetik.

Dazu kamen gute Contributor-Docs, weil im Open-Source-Repo auch Leute mit ihren eigenen Agenten mitgearbeitet haben. Martín schätzt, dass sie zu zehn Menschen eher wie hundert Beteiligte gearbeitet haben, wenn man die Agenten mitzählt. Koordination wird damit wichtiger, nicht unwichtiger.

Das Ergebnis: ein öffentlicher Release ohne Invite-Code im August, eine Kooperation mit Taco Bell und eine stabile, wachsende App. Der komplette Code ist Open Source.

Teil 2: Warum Flutter mit KI gut skaliert

Der zweite Talk kam von Emma Tursky und Carlos Mendoza aus dem Flutter-Team. Natürlich haben die einen Heimvorteil, wenn es um Flutter geht. Ich lese das als Argumentation eines Teams, das sein eigenes Produkt verteidigt. Trotzdem sind ein paar Punkte hängen geblieben.

Migration ist nicht Skalierung

Der Kernsatz des Talks: KI macht es leicht, auf ein neues Framework zu migrieren. Flutter macht es leicht zu skalieren.

Ihr Gedanke dazu: Ein Rewrite mit KI liefert vor allem den Happy Path, also Layouts, Netzwerk-Requests und Boilerplate. Ein Produktivsystem enthält aber über Jahre gesammeltes Wissen, entschiedene Diskussionen und Edge Cases. Wer zweimal schreibt, verdoppelt diese Fläche.

Dazu kommt Drift. Zwei Agenten, einer für Swift, einer für Kotlin, treffen laut Tursky auch mit identischem Prompt leicht unterschiedliche Architekturentscheidungen. Am Ende müssen Menschen das wieder zusammenführen.

Verifikation ist der Engpass

Code erzeugen ist 2026 der einfache Teil. Das Nadelöhr ist das Prüfen. Ein Agent braucht schnelles, deterministisches Feedback.

Tursky hat das so verglichen:

• Nativ: Der Agent ändert Kotlin oder Swift und startet den Build. Zwei bis fünf Minuten pro Durchlauf. Vier Debug-Runden sind etwa 20 Minuten Warten. Ob die UI stimmt, prüft er über Screenshots und ein multimodales Modell, was langsam und teuer ist.
• Flutter: Widget-Tests laufen headless in Millisekunden. Über den Dart VM Service und DevTools kann der Agent den echten Widget-Baum auslesen, statt Pixel zu raten. Hot Reload spielt Änderungen in unter 200 Millisekunden ein und behält den State.

Das kenne ich aus der Praxis. Hot Reload war schon für mich als Mensch der Grund, Flutter zu lieben. Dass genau das auch für Agenten der Vorteil ist, überrascht mich nicht.

Harness statt besserer Prompt

Carlos Mendoza hat betont, dass ein besserer Prompt das Problem nicht löst. Allgemeine Coding-Agenten kennen Flutter nur so gut wie ihre Trainingsdaten. Sie greifen zu veralteten APIs oder raten, wie ein Package funktioniert.

Die Antwort des Teams sind offizielle Dart- und Flutter-Agent-Plugins mit MCP-Server und Skills, die Zugriff auf den Analyzer und den Widget Inspector geben. Ergänzt wird das durch das Skills CLI, das ursprünglich von Serverpod kommt. Damit können Package-Autoren Skills direkt im Package mitliefern.

Das passt zu dem, was auch Martín beschrieben hat. Martíns Team geht denselben Weg mit einem eigenen Flutter-Plugin: Best Practices als Skills, damit der Agent nicht raten muss.

Das Flutter-Team misst übrigens, ob das etwas bringt. Bei einer Wishlist-Aufgabe lag Gemini 3.5 Flash mit den Tools 1.4 Prozentpunkte vorn, Gemini 3.1 Pro drei Punkte. Das ist kein Quantensprung, aber ehrlich gemessen.

Project One Shot

Zwei Flutter-Core-Entwickler haben getestet, wie weit Agenten bei einem komplexen Package wie Android CameraX kommen. Ihre Lehren:

• Prompting reicht nicht. "Pass auf Memory Leaks auf" verhindert keine.
• MCP-Tools geben dem Modell Augen und Hände, etwa um den Analyzer zu fragen, ob eine Klasse existiert.
• Domain-Skills der Package-Autoren verhindern Fehlinterpretationen.
• Deterministische Leitplanken zählen: erst ein fehlschlagender Test, dann die minimale Änderung, dann Tests und Linter.

Das letzte Prinzip ist bei beiden Talks identisch. Ob Divine oder CameraX: Die Qualität kommt aus dem Regelwerk drumherum, nicht aus dem Modell.

Was ich daraus mitnehme

Aus beiden Talks ziehe ich vier Dinge, und hier ist es meine Meinung, nicht die der Redner:

1. Vibe-Coding ist ein guter Start und ein schlechtes Fundament. Zum Validieren super, aber plane früh ein, wann du aufräumst. Wann NoCode oder echte Entwicklung besser passt, steht in NoCode vs. echte Entwicklung.
2. Gib dem Agenten Leitplanken. Lint-Regeln, Tests, Hooks, eine klare Ordnerstruktur. Das sind keine Bremsen, das ist der Grund, warum es schnell bleibt.
3. Dein Job verschiebt sich zum Urteil. Nicht mehr "wie schreibe ich das", sondern "sollten wir das überhaupt bauen". Das sehe ich auch in meinen eigenen Projekten, auch als Solo-Entwickler.
4. Eine Codebasis ist ein Vorteil. Gerade wenn Agenten mitschreiben, hilft eine einzige Quelle der Wahrheit. Ob das für jedes Projekt Flutter bedeuten muss, ist eine andere Frage. Wie ich das abwäge, steht in Native App vs. Cross-Platform.

Fazit

KI schreibt heute große Teile von Flutter-Apps, und das funktioniert besser, als viele denken. Aber nur, wenn du ihr ein Umfeld baust: saubere Architektur, strenge Checks, schnelles Feedback.

Die Divine-Geschichte zeigt, dass auch ein chaotischer Start rettbar ist. Der Flutter-Talk zeigt, warum die Toolchain dafür eine gute Basis ist. Beides sagt dasselbe: Das Modell ist selten das Problem. Der Prozess drumherum ist es.

Und falls du überlegst, was KI in deiner eigenen App sinnvoll leisten kann, schau in meinen Artikel KI in der App-Entwicklung.

Häufig gestellte Fragen (FAQ)

Dieser Artikel wurde inspiriert von den Talks "Transforming a Flutter App with AI-Generated Code" von Óscar Martín (Very Good Ventures) und "Flutter for Scaling Applications in the AI Era" von Emma Tursky und Carlos Mendoza (Google) auf der FlutterCon 2026.