Claude Code für Flutter-UI-Iteration: ein praktischer Workflow

Das Problem: schnelle UI-Iterationen, die nicht im Chaos enden

Schnelle Flutter-UI-Arbeit beginnt oft gut. Du passt ein Layout an, fügst einen Button hinzu, verschiebst ein Feld — und der Screen wird schnell besser. Das Problem zeigt sich nach ein paar Durchläufen, wenn Tempo in einen Berg von Änderungen umschlägt, den niemand gerne reviewt.

Teams stolpern üblicherweise über die gleichen Fallen:

• Der Widget-Baum wächst ohne Plan, sodass eine „kleine" Änderung viele Dateien trifft.
• State wird an UI-Code festgeschraubt, was Rebuilds unvorhersehbar und Bugs schwer zu verfolgen macht.
• Navigationslogik verteilt sich (ein push hier, ein pop dort), bis die Flows nicht mehr zum tatsächlichen Nutzerverhalten passen.
• Benennungen drifteten, Komponenten werden dupliziert und niemand ist sicher, welches Widget das „echte" ist.
• Diffs werden riesig; Reviewer überfliegen sie, Probleme rutschen durch und Regressionen tauchen später auf.

Eine große Ursache ist der „one big prompt“-Ansatz: die ganze Funktion beschreiben, um das vollständige Set an Screens bitten und eine große Ausgabe akzeptieren. Der Assistent versucht zu helfen, aber berührt zu viele Teile des Codes auf einmal. Das macht Änderungen unordentlich, schwer zu reviewen und riskant zum Mergen.

Eine wiederholbare Schleife löst das, indem sie Klarheit erzwingt und die Blast-Radius begrenzt. Statt „baue das Feature", mach wiederholt Folgendes: wähle eine User Story, generiere die kleinste UI-Scheibe, die sie beweist, füge nur den für diese Scheibe nötigen State hinzu und verdrahte Navigation für einen Pfad. Jede Iteration bleibt klein genug zum Review, und Fehler sind leicht rückgängig zu machen.

Das Ziel ist ein praktischer Workflow, um User Stories in konkrete Screens, State-Handling und Navigationsflüsse zu verwandeln, ohne die Kontrolle zu verlieren. Gut gemacht endest du mit modularen UI-Stücken, kleineren Diffs und weniger Überraschungen, wenn sich Anforderungen ändern.

Verwandle User Stories in eine klare UI-Spezifikation, die du bauen kannst

User Stories sind für Menschen geschrieben, nicht für Widget-Bäume. Bevor du etwas generierst, verwandle die Story in eine kleine UI-Spezifikation, die sichtbares Verhalten beschreibt. „Fertig" sollte prüfbar sein: was der Nutzer sehen, antippen und bestätigen kann — nicht, ob das Design „modern wirkt".

Eine einfache Methode, den Umfang konkret zu halten, ist die Aufteilung der Story in vier Bereiche:

• Screens: was sich ändert, was bleibt
• Components: welche neuen UI-Teile erscheinen und wo sie leben
• States: loading, success, error, empty und was jeweils gezeigt wird
• Events: taps, swipes, pull-to-refresh, Back-Navigation, Retry

Wenn die Story noch unklar ist, beantworte diese Fragen in einfacher Sprache:

• Welche Screens ändern sich, welche bleiben gleich?
• Welche neuen Komponenten erscheinen und wo gehören sie hin?
• Welche States existieren und was zeigt jeder State?
• Welche Events treiben State-Änderungen an?
• Was ist die Akzeptanzprüfung, die du in 30 Sekunden nach dem Start der App durchführen kannst?

Füge früh Constraints hinzu, denn sie leiten jede Layout-Entscheidung: Theme-Grundlagen (Farben, Abstände, Typografie), Responsivität (zuerst Phone-Portrait, dann Tablet-Breiten) und Mindestanforderungen an Accessibility wie Tippflächen, lesbare Textskalierung und aussagekräftige Labels für Icons.

Entscheide schließlich, was stabil vs. flexibel ist, damit du den Code nicht unnötig churnst. Stabil sind Dinge, von denen andere Features abhängen, z. B. Routennamen, Datenmodelle und vorhandene APIs. Flexibel sind sichere Iterationspunkte wie Layout-Struktur, Microcopy und die genaue Widget-Komposition.

Beispiel: „Als Nutzer kann ich ein Item auf der Detailseite zu Favoriten speichern." Eine buildbare UI-Spezifikation könnte sein:

• Die Detailseite zeigt ein Lesezeichen-Icon.
• Antippen toggelt den gespeicherten Zustand.
• Während des Speicherns zeigt es einen kleinen Progress-Indicator.
• Bei Fehlern wird ein Inline-Fehler mit Retry-Aktion angezeigt.
• Die Navigation bleibt unverändert (keine neuen Routen).

Das reicht, um zu bauen, zu reviewen und iterativ zu verbessern, ohne zu spekulieren.

Die Iterationsschleife so einrichten, dass Diffs klein bleiben

Kleine Diffs bedeuten nicht langsameres Arbeiten. Sie machen jede UI-Änderung leicht zu reviewen, einfach rückgängig zu machen und schwer zu brechen. Die einfachste Regel: eine Seite oder eine Interaktion pro Iteration.

Wähle vor dem Start einen engen Slice. „Füge einen Empty-State zum Orders-Screen hinzu" ist ein guter Slice. „Überarbeite den gesamten Orders-Flow" ist es nicht. Ziel ist ein Diff, das ein Teammitglied in einer Minute verstehen kann.

Eine stabile Ordnerstruktur hilft außerdem, Änderungen eingegrenzt zu halten. Ein einfaches, feature-first Layout verhindert, dass Widgets und Routen überall verstreut werden:

lib/
  features/
    orders/
      screens/
      widgets/
      state/
      routes.dart

Halte Widgets klein und komponierbar. Wenn ein Widget klare Inputs und Outputs hat, kannst du Layout ändern, ohne State-Logik anzufassen, und State ändern, ohne UI neu zu schreiben. Bevorzuge Widgets, die einfache Werte und Callbacks akzeptieren, statt globalen State zu lesen.

Eine reviewbare Schleife:

• Schreibe eine 3–6-zeilige UI-Spez für den Slice (was erscheint, was Taps tun, wie loading/error aussehen).
• Generiere oder editiere nur die minimal nötigen Dateien (oft ein Screen und ein oder zwei Widgets).
• Starte den Screen, dann mache einen Cleanup-Durchgang (Benennung, Abstände, entferne unbenutzte Props).
• Committe mit einer Nachricht, die zum Slice passt.

Setze eine harte Regel: jede Änderung muss leicht revertierbar oder isolierbar sein. Vermeide „Drive-by“-Refactors während du an einem Screen iterierst. Wenn dir nebenbei Probleme auffallen, notiere sie und behandle sie in einem separaten Commit.

Wenn dein Tool Snapshots und Rollback unterstützt, nutze jeden Slice als Snapshot-Punkt. Einige Vibe-Coding-Plattformen wie Koder.ai bieten Snapshots und Rollback, was Experimente sicherer macht, wenn du mutige UI-Änderungen ausprobierst.

Ein weiteres Verhalten, das frühe Iterationen ruhig hält: füge lieber neue Widgets hinzu, statt geteilte zu bearbeiten. Geteilte Komponenten sind der Ort, an dem kleine Änderungen große Diffs auslösen.

Schritt für Schritt: vom User Story zum Widget-Baum

Schnelle UI-Arbeit bleibt sicher, wenn du Denken und Tippen trennst. Beginne mit einem klaren Widget-Tree-Plan, bevor du Code generierst.

1. Bitte zuerst nur um eine Widget-Tree-Outline. Du willst Widget-Namen, Hierarchie und was jeder Teil zeigt. Kein Code. Hier bemerkst du fehlende States, leere Screens und merkwürdige Layout-Entscheidungen, solange alles noch billig änderbar ist.

2. Bitte um eine Komponenten-Aufschlüsselung mit Verantwortlichkeiten. Halte jedes Widget fokussiert: eins rendert den Header, ein anderes die Liste, ein drittes die Empty/Error-UI. Wenn später State nötig wird, notiere es, implementiere ihn aber noch nicht.

3. Generiere das Screen-Scaffold und stateless Widgets separat. Beginne mit einer einzigen Screen-Datei mit Platzhaltern und klaren TODOs. Halte Inputs explizit (Konstruktorparameter), damit du später echten State anschließen kannst, ohne den Baum umzuschreiben.

4. Mach einen separaten Durchgang für Styling und Layout-Details: Abstände, Typografie, Theming und responsives Verhalten. Behandle Styling als eigenen Diff, damit Reviews einfach bleiben.

Ein Prompt-Pattern, das funktioniert

Setze Constraints voran, damit der Assistent keine nicht-versendbare UI erfindet:

• Zielgeräte (nur Phone, Tablet mit einschließen, Orientierung)
• Design-Constraints (Material 3, vorhandene Theme-Farben, Abstandregeln)
• Navigationserwartungen (Back-Verhalten, Deep Links falls vorhanden)
• Akzeptanzkriterien (was sichtbar und tappbar sein muss)
• Bestehende Code-Grenzen (welche Dateien/Widgets bleiben, Benennungs-Konventionen)

Konkretes Beispiel: Die User Story ist „As a user, I can review my saved items and remove one." Bitte um einen Widget-Tree, der eine AppBar, eine Liste mit Item-Rows und einen Empty-State enthält. Fordere dann eine Aufschlüsselung wie SavedItemsScreen, SavedItemTile, EmptySavedItems. Erst danach das Scaffold mit stateless Widgets und Fake-Daten generieren, und zuletzt Styling (Divider, Padding, klarer Remove-Button) in einem separaten Pass hinzufügen.

State hinzufügen, ohne die UI aufzublähen

UI-Iteration scheitert, wenn jedes Widget Entscheidungen treffen will. Halte den Widget-Baum dumm: er soll State lesen und rendern, nicht Geschäftslogik enthalten.

Beginne damit, die States in Worten zu benennen. Die meisten Features brauchen mehr als nur „loading" und „done":

• Loading (Erstlade- oder Refresh-Zustand)
• Empty (keine Daten)
• Error (fehlgeschlagene Anfrage, fehlende Berechtigung)
• Success (Daten vorhanden)
• Partial input (Form begonnen, aber ungültig)

Liste dann Events auf, die den State ändern: taps, Form-Submit, Pull-to-Refresh, Back, Retry und „Nutzer hat ein Feld verändert". Das verhindert spätere Ratespiele.

State vom Widget trennen

Wähle einen State-Ansatz für das Feature und bleibe dabei. Es geht nicht um das „beste“ Pattern, sondern um konsistente Diffs.

Für einen kleinen Screen reicht oft ein einfacher Controller (z. B. ChangeNotifier oder ValueNotifier). Lege die Logik an einer Stelle ab:

• Inputs: Events aus der UI (submit, refresh, edit)
• Output: ein einzelnes State-Objekt, das die UI rendert
• Seiteneffekte: API-Calls und Navigation-Requests

Bevor du Code schreibst, beschreibe die State-Transitionen in einfachem Englisch. Beispiel für einen Login-Screen:

"Wenn der Nutzer Sign in tappt: setze Loading. Wenn die E-Mail ungültig ist: bleibe in Partial input und zeige eine Inline-Meldung. Wenn das Passwort falsch ist: setze Error mit einer Nachricht und aktiviere Retry. Bei Erfolg: setze Success und navigiere zu Home."

Erzeuge dann minimalen Dart-Code, der diesen Sätzen entspricht. Reviews bleiben einfach, weil du den Diff mit den Regeln vergleichen kannst.

Testbare Regeln für ungültige Eingaben hinzufügen

Mache Validierung explizit. Entscheide, was passiert, wenn Eingaben ungültig sind:

• Blockierst du das Absenden oder erlaubst du es und zeigst dann Fehler?\n- Welche Felder zeigen Fehler und wann?\n- Verwirft Back-Nav ungespeicherte Eingaben oder bleiben sie erhalten?\n Wenn diese Antworten schriftlich vorliegen, bleibt die UI sauber und der State-Code klein.

Navigationsflüsse designen, die dem echten Nutzerverhalten entsprechen

Gute Navigation beginnt als kleine Karte, nicht als Berg von Routen. Für jede User Story notiere vier Momente: wo der Nutzer einsteigt, der wahrscheinlichste nächste Schritt, wie er abbrechen kann und was "Back" bedeutet (zurück zur vorherigen Seite oder zu einem sicheren Home-State).

Zuerst eine Route-Map, dann festlegen, was zwischen Screens reist

Eine einfache Routen-Map sollte die Fragen beantworten, die sonst für Rework sorgen:

• Entry: welcher Screen öffnet zuerst und von wo (Tab, Notification, Deep Link)
• Next: der hauptsächliche Vorwärtspfad nach der Aktion
• Cancel: wohin der Nutzer bei Abbruch gelangt
• Back: ob Back erlaubt ist und was erhalten werden soll
• Fallback: wohin, wenn benötigte Daten fehlen

Definiere dann die Parameter, die zwischen Bildschirmen übergeben werden. Sei explizit: IDs (productId, orderId), Filter (Datumsbereich, Status) und Draft-Daten (teilweise ausgefüllte Formulare). Wenn du das auslässt, endest du damit, Kontext in globalen Singletons zu verstecken oder Screens so umzubauen, dass sie Kontext „finden".

Plane Deep Links und "ein Ergebnis zurückgeben"-Muster

Deep Links sind wichtig, auch wenn du sie nicht am ersten Tag auslieferst. Entscheide, was passiert, wenn ein Nutzer mitten im Flow landet: kannst du fehlende Daten nachladen oder leitest du auf einen sicheren Einstieg um?

Entscheide außerdem, welche Screens Ergebnisse zurückgeben sollten. Beispiel: ein Select Address-Screen gibt eine addressId zurück, und der Checkout aktualisiert sich ohne kompletten Refresh. Halte die Rückgabeform klein und typisiert, damit Änderungen leicht reviewbar bleiben.

Rufe Edge-Cases vor dem Kodieren auf: ungespeicherte Änderungen (Confirm-Dialog), Auth nötig (Pause und Fortsetzen nach Login) und fehlende oder gelöschte Daten (Fehler anzeigen und klaren Ausweg bieten).

UI-Änderungen reviewbar und modular machen

Beim schnellen Iterieren ist das eigentliche Risiko nicht „falsche UI", sondern unüberprüfbare UI. Wenn ein Kollege nicht erkennen kann, was sich geändert hat, warum und was stabil blieb, wird jede weitere Iteration langsamer.

Eine Regel, die hilft: sperre zuerst die Interfaces, dann dürfen die Interna sich bewegen. Stabilisiere öffentliche Widget-Props (Inputs), kleine UI-Modelle und Routengegenstände. Sobald diese benannt und typisiert sind, kannst du den Widget-Baum umbauen, ohne den Rest der App zu brechen.

Bevorzuge kleine, stabile Nähte

Fordere vor dem Generieren einen diff-freundlichen Plan an. Du willst einen Plan, der sagt, welche Dateien sich ändern und welche unangetastet bleiben. Das macht Reviews fokussiert und verhindert unbeabsichtigte Refactors, die Verhalten ändern.

Muster, die Diffs klein halten:

• Halte öffentliche Widgets dünn: akzeptiere nur die Daten und Callbacks, die nötig sind, und vermeide den Zugriff auf Singletons.
• Verschiebe Geschäftsregeln früh aus Widgets: lege Entscheidungen in einen Controller oder ViewModel und lasse die UI State rendern.
• Wenn ein UI-Teil nicht mehr ständig geändert wird, extrahiere ihn in ein wiederverwendbares Widget mit klarer, typisierter API.
• Halte Route-Argumente explizit (ein einzelnes Argument-Objekt ist oft sauberer als viele optionale Felder).
• Füge eine kurze Change-Log-Zeile zur PR-Beschreibung hinzu: was sich geändert hat, warum und was zu testen ist.

Ein konkretes Beispiel, das Reviewer mögen

Angenommen, die Story ist „Als Käufer kann ich meine Lieferadresse im Checkout bearbeiten." Sperre zuerst die Route-Args: CheckoutArgs(cartId, shippingAddressId) bleibt stabil. Iteriere dann innerhalb des Screens. Sobald das Layout steht, splitte in AddressForm, AddressSummary und SaveBar.

Wenn sich das State-Handling ändert (z. B. Validierung wandert vom Widget in einen CheckoutController), bleibt das Review lesbar: UI-Dateien zeigen meist nur Rendering-Änderungen, während der Controller die Logikänderung an einer Stelle zeigt.

Typische Fehler und Fallen beim Iterieren mit einem KI-Assistenten

Der schnellste Weg, langsamer zu werden, ist, den Assistenten alles auf einmal ändern zu lassen. Wenn ein Commit Layout, State und Navigation trifft, können Reviewer nicht erkennen, was gebrochen hat. Ein sicherer Habit ist: eine Intention pro Iteration—erst den Widget-Tree formen, dann State verdrahten, dann Navigation verbinden.

Fehler, die unordentlichen Code erzeugen

Ein häufiges Problem ist, dass generierter Code auf jeder Seite ein neues Pattern erfindet. Seite A nutzt Provider, Seite B setState, Seite C einen Custom-Controller — die App wird schnell inkonsistent. Wähle ein kleines Set an Patterns und halte dich daran.

Ein anderer Fehler ist, asynchrone Arbeit direkt in build() zu legen. Das mag in einer schnellen Demo funktionieren, führt aber zu wiederholten Calls bei Rebuilds, Flicker und schwer nachverfolgbaren Bugs. Verschiebe den Aufruf in initState(), ein ViewModel oder einen dedizierten Controller und halte build() auf Rendering fokussiert.

Benennungen sind eine stille Falle. Code, der kompiliert, aber Namen wie Widget1, data2 oder temp verwendet, macht spätere Refactors zur Qual. Klare Namen helfen dem Assistenten außerdem, bessere Folgeänderungen zu erzeugen, weil die Absicht offensichtlich ist.

Schutzvorrichtungen, die das Schlimmste verhindern:

• Ändere pro Iteration nur eines: Layout, State oder Navigation
• Verwende dasselbe State-Pattern über ein Feature hinweg
• Keine Netzwerk- oder DB-Aufrufe in build()\n- Benenne Platzhalter um, bevor du weitere Funktionalität hinzufügst\n- Extrahiere Widgets, statt die Verschachtelung weiter zu erhöhen

Die Verschachtelungsfalle

Eine klassische visuelle Bugfix-Strategie ist, einen weiteren Container, Padding, Align und SizedBox hinzuzufügen, bis es richtig aussieht. Nach ein paar Durchläufen wird der Baum unlesbar.

Wenn ein Button nicht ausgerichtet ist, versuche zuerst, Wrapper zu entfernen, ein einzelnes Parent-Layout-Widget zu verwenden oder ein kleines Widget mit eigenen Constraints zu extrahieren.

Beispiel: ein Checkout-Screen, bei dem der Gesamtpreis beim Laden springt. Ein Assistent könnte die Preiszeile in mehr Widgets wrappen, um sie zu „stabilisieren“. Eine sauberere Lösung ist, Platz mit einem einfachen Loading-Placeholder zu reservieren und die Zeilenstruktur unverändert zu lassen.

Kurze Checkliste vor dem Commit der nächsten UI-Iteration

Bevor du committest, mache einen Zwei-Minuten-Check, der den Nutzerwert prüft und dich vor Überraschungsregressionen schützt. Ziel ist nicht Perfektion, sondern sicherzustellen, dass diese Iteration leicht zu reviewen, zu testen und zurückzunehmen ist.

Commit-ready Checkliste

Lese die User Story einmal und prüfe dann diese Punkte gegen die laufende App (oder wenigstens gegen einen einfachen Widget-Test):

• Widget-Tree stimmt mit der Story überein: Schlüsselteile der Akzeptanzkriterien sind sichtbar. Text, Buttons und Abstände wirken beabsichtigt.
• Alle States sind erreichbar: Loading, Error und Empty sind nicht nur skizziert. Du kannst jeden Zustand (auch mit temporärem Debug-Flag) auslösen und er sieht akzeptabel aus.
• Navigation und Back-Verhalten sind sinnvoll: Back geht auf den erwarteten Screen, Dialoge schließen korrekt und Deep Links (falls genutzt) landen an einem sinnvollen Ort.
• Diffs bleiben klein und verantwortbar: Änderungen beschränken sich auf eine kleine Menge Dateien mit klarer Verantwortung. Keine Drive-by-Refactors.
• Rollback ist sauber: Wenn du diesen Commit revertierst, bauen und laufen andere Screens weiterhin. Entferne temporäre Flags oder Platzhalter, die später Probleme machen könnten.

Eine schnelle Realität-Prüfung: Wenn du einen neuen Order-Details-Screen hinzugefügt hast, solltest du (1) ihn aus der Liste öffnen können, (2) einen Loading-Spinner sehen, (3) einen Fehler simulieren können, (4) einen leeren Auftrag sehen und (5) Back drücken, um ohne merkwürdige Sprünge zur Liste zurückzukehren.

Wenn dein Workflow Snapshots/Rollback unterstützt, erstelle vor größeren UI-Änderungen einen Snapshot. Plattformen wie Koder.ai bieten das an und es hilft, schneller zu iterieren, ohne den Main-Branch zu gefährden.

Ein realistisches Beispiel: von User Story zu Screens in drei Iterationen

User Story: „Als Käufer kann ich Artikel durchstöbern, eine Detailseite öffnen, ein Item zu Favoriten speichern und später meine Favoriten ansehen." Ziel ist, in drei kleinen, überprüfbaren Schritten von Worten zu Screens zu kommen.

Iteration 1: Fokus nur auf die Browse-List. Erstelle einen Widget-Tree, der genug rendert, aber noch nicht an echte Daten gebunden ist: ein Scaffold mit AppBar, ein ListView mit Platzhalter-Rows und klare UIs für Loading und Empty. Halte den State einfach: loading (zeigt CircularProgressIndicator), empty (kurze Nachricht + Try again Button) und ready (zeigt die Liste).

Iteration 2: Füge die Detailseite und Navigation hinzu. Halte es explizit: onTap pusht eine Route und übergibt ein kleines Parameter-Objekt (z. B. item id, title). Starte die Details-Seite read-only mit Titel, Beschreibung-Platzhalter und einem Favorite-Action-Button. Ziel ist: list -> details -> back, ohne extra Flows.

Iteration 3: Führe Favorite-Status-Updates und UI-Feedback ein. Füge eine einzige Quelle der Wahrheit für Favoriten hinzu (auch wenn sie im Speicher bleibt) und verbinde sie mit beiden Screens. Tippen auf Favorite aktualisiert sofort das Icon und zeigt eine kleine Bestätigung (z. B. SnackBar). Dann füge einen Favorites-Screen hinzu, der denselben State liest und den Empty-State behandelt.

Ein reviewbares Diff sieht typischerweise so aus:

• browse_list_screen.dart: Widget-Tree plus Loading/Empty/Ready UI
• item_details_screen.dart: UI-Layout und akzeptiert Navigation-Parameter
• favorites_store.dart: minimaler State-Holder und Update-Methoden
• app_routes.dart: Routen und typisierte Navigation-Helper
• favorites_screen.dart: liest State und zeigt Empty/List UI

Wenn eine Datei „der Ort, an dem alles passiert" wird, splitte sie, bevor du weitermachst. Kleine Dateien mit klaren Namen machen die nächste Iteration schnell und sicher.

Nächste Schritte: die Schleife über Features wiederholbar machen

Wenn der Workflow nur funktioniert, wenn du „im Flow" bist, bricht er zusammen, sobald du den Context wechselst oder ein Kollege am Feature arbeitet. Mache die Schleife zur Gewohnheit, indem du sie dokumentierst und Guardrails für die Änderungsgröße setzt.

Eine wiederverwendbare Prompt-Vorlage erstellen

Verwende eine Team-Vorlage, damit jede Iteration mit denselben Eingaben beginnt und dieselbe Art von Ausgabe liefert. Halte sie kurz, aber spezifisch:

• User Story + Akzeptanzkriterien (was "done" bedeutet)
• UI-Constraints (Designsystem, Abstandregeln, zu wiederverwendende Komponenten)
• State-Regeln (wo State lebt, was lokal vs. shared sein darf)
• Navigationsregeln (Routen, Deep Links, Back-Verhalten)
• Output-Regeln (Dateien, die anzupassen sind, Tests, die zu aktualisieren sind, was im Diff erklärt werden soll)

Das reduziert die Wahrscheinlichkeit, dass der Assistent mitten im Feature neue Patterns erfindet.

Definiere "klein", damit Diffs vorhersehbar bleiben

Wähle eine Definition von klein, die im Code-Review leicht durchsetzbar ist. Zum Beispiel begrenze jede Iteration auf eine bestimmte Anzahl Dateien und trenne UI-Refactors von Verhalten.

Einfache Regeln:

• Nicht mehr als 3–5 Dateien pro Iteration ändern
• Eine neue Widget-Änderung oder ein Navigation-Step pro Iteration
• Kein neues State-Management-Pattern mitten im Loop
• Jede Änderung muss vor der nächsten Compilation und Ausführung bestanden haben

Füge Checkpoints hinzu, damit du einen schlechten Schritt schnell rückgängig machen kannst. Mindestens tagge Commits oder halte lokale Checkpoints vor größeren Refactors. Wenn dein Workflow Snapshots/Rollback unterstützt, nutze sie großzügig.

Wenn du einen chatbasierten Workflow willst, der Flutter-Apps end-to-end generieren und verfeinern kann, bietet Koder.ai einen Planungsmodus, der dir hilft, einen Plan und die erwarteten Dateiveränderungen vor dem Anwenden zu prüfen.