Verhindern, dass UI‑Änderungen die Geschäftslogik in KI‑Apps brechen

Warum UI-Änderungen die Geschäftslogik in KI-erstellten Apps brechen

Eine UI-Änderung wirkt harmlos: einen Button verschieben, ein Label umbenennen, Abstände anpassen. Aber in vielen KI-generierten Prototypen steuert dieselbe Datei sowohl das Aussehen als auch das, was passiert, wenn Sie klicken, welche Daten gespeichert werden und welche Regeln gelten. Deshalb kann ein „visueller Feinschliff“ echtes Verhalten verändern.

Eine häufige Ursache ist vermischte Verantwortung. Eine Komponente kann Layout handhaben, einen Einkaufswagen-Total berechnen, eine Payment-API aufrufen und entscheiden, ob ein Nutzer etwas darf. Wenn Sie am Layout schrauben, kann es passieren, dass Sie versehentlich die Logik beeinflussen — durch Verschieben von Code, Ändern von Props oder verändertes Rerender-Verhalten.

Eine andere Ursache ist versteckte Kopplung: ein CSS-Klassenname wird auch als Selektor in JavaScript verwendet, der Text eines Buttons dient als Key, oder ein „einfaches Aufräumen“ ändert die Reihenfolge von Event-Handlern. KI-Tools neigen zudem dazu, fragile Muster zu erzeugen, wie Inline-Berechnungen in UI-Handlern, duplizierte Validierungsregeln und State, der bei jedem Rerender zurückgesetzt wird.

Symptome zeigen sich meist schnell:

• Buttons reagieren nicht mehr oder lösen die falsche Aktion aus.
• Totale, Steuern oder Rabatte ändern sich nach einem Layout-Tweak.
• Login funktioniert erst, dann bleibt die App in einer Redirect-Schleife hängen.
• Ein Formular wird abgeschickt, aber die gespeicherten Daten fehlen Felder.
• Ein Modal öffnet sich, aber der App-State aktualisiert sich nie.

Eine sichere UI-Änderung bedeutet: Sie können das Aussehen anpassen, ohne das Verhalten zu ändern — gleiche Eingaben, gleiche Ausgaben, gleiche Regeln, gleiche Nebeneffekte.

Beispiel: Sie ersetzen einen „Pay now“-Button durch eine neue Komponente, damit er ins Design-System passt. Der neue Button sieht korrekt aus, leitet aber den onClick-Handler nicht weiter, sodass der Zahlungsaufruf nie stattfindet. Nichts in der UI schreit „Abrechnung kaputt“, aber die Geschäftslogik ist getrennt.

Dies ist eines der häufigsten Muster in KI-generiertem Code: Die App funktioniert, bis ein „visueller“ Tweak die direkt daneben liegende Logik berührt.

Design vs. Verhalten: Ziehen Sie eine klare Linie

Die meisten Fehler entstehen, weil Design und Regeln in derselben Datei gemischt werden.

Design-Änderungen betreffen Layout, Abstände, Farben, Typografie, Icons und Texte. Sie verändern, was Menschen sehen.

Verhaltens-Änderungen betreffen Entscheidungen: Validierungsregeln, Preisberechnung, Berechtigungen, was gespeichert wird, wann ein API-Aufruf läuft und was passiert, wenn etwas fehlschlägt.

Eine einfache Regel macht Sie sicherer: UI soll Zustand anzeigen, nicht Regeln entscheiden. Eine Komponente kann eine Fehlermeldung anzeigen, aber sie sollte nicht die Fehlerbedingung erfinden. Sie kann „$29/month“ rendern, aber die Preisberechnung sollte nicht in einem Click-Handler mit versteckten Bedingungen stattfinden.

Wo UI-Dateien riskant werden

In KI-generierten Prototypen versteckt sich die gefährlichste Logik oft an Stellen, die wie „nur UI“ aussehen, insbesondere:

• Event-Handler (onClick, onSubmit, onChange), die Geschäftsregeln enthalten.
• Geteilter State, der UI-State (Modal offen) mit Domain-State (User-Rolle, Plan) mischt.
• API-Aufrufe, die direkt in UI-Komponenten gemacht werden.
• „Helper“-Funktionen, die in einer UI-Datei definiert und über Bildschirme wiederverwendet werden.

Diese Bereiche lassen sich bei Layout-Änderungen oder Prop-Umbenennungen leicht aus Versehen antasten.

Was in der UI bleiben darf und was ausgelagert werden sollte

UI-Code darf Präsentationsdetails handhaben: Loading-Spinner, einen Button während des Speicherns deaktivieren, Datums- und Währungsformatierung und welche Ansicht für einen gegebenen Zustand gezeigt wird.

Alles, was Ergebnisse entscheidet, gehört an einen zentralen Ort außerhalb der UI: Validierung, Preis- und Abrechnungsregeln, Berechtigungsprüfungen, Mapping von API-Fehlern auf nutzerfreundliche Meldungen und jede „wenn dies, dann das“-Entscheidung, die echte Daten beeinflusst.

Ein schneller Test: Wenn das Ändern einer Farbe, eines Labels oder des Layouts das Ergebnis verändern könnte, gehört der Code nicht in die UI.

Ein sicherer Workflow, bevor Sie die UI anfassen

Behandeln Sie jeden visuellen Tweak wie ein kleines Release. In fragilen Prototypen ist das Risiko nicht das CSS — es sind die unbeabsichtigten Nebeneffekte.

Starten Sie mit einer kleinen Änderung. Bevor Sie den Editor öffnen, schreiben Sie eine kurze "muss gleich bleiben"-Liste: die Ergebnisse, die nach dem UI-Update unverändert bleiben müssen. Halten Sie sie konkret und menschenlesbar.

Wenn Sie eine Checkout-Seite anpassen, könnte Ihre Liste so aussehen:

• Der Totalbetrag bleibt gleich.
• Der Gutschein greift weiterhin.
• Der Bezahl-Button belastet genau einmal.

Erstellen Sie dann einen Snapshot, den Sie schnell zurücksetzen können. Nutzen Sie Version Control und machen Sie einen Branch. Falls nicht vorhanden, duplizieren Sie den Projektordner und benennen ihn mit Datum und Änderungsname.

Arbeiten Sie in kleinen Schritten: editieren, ausführen, prüfen, Checkpoint speichern, wiederholen. Vermeiden Sie „während ich schon hier bin“-Extras.

Entscheiden Sie außerdem, wie Sie den Erfolg verifizieren, bevor Sie starten. Wählen Sie einen kurzen Flow, den Sie jedes Mal wiederholen können, z. B.: „einloggen, Einstellungen öffnen, E-Mail ändern, speichern, neu laden, bestätigen, dass die Änderung gespeichert blieb.“ Wenn Sie den Flow nicht in einem Satz beschreiben können, ist die Änderung wahrscheinlich zu groß.

Schritt für Schritt: eine rein visuelle Änderung ohne Verhaltensänderung

Wenn Sie eine nur-UI-Änderung vornehmen wollen, halten Sie die Verkabelung stabil.

1. Benennen Sie den genauen Screen und die einzelne Aktion, die Sie beeinflussen (z. B. „Settings-Screen, Save-Button“).
2. Finden Sie die dahinterliegende Logik (Validierung, Berechnungen, Request-Payload). Markieren Sie sie als Tabu für diese UI-Änderung.
3. Wenden Sie nur die visuelle Änderung an (Abstände, Layout, Texte). Lassen Sie Handler, Props und Datenpfade unverändert.
4. Führen Sie denselben Nutzerflow mit denselben Eingaben erneut aus und vergleichen Sie die Ergebnisse.
5. Wenn Sie aufräumen (Umbenennen, Refactor), machen Sie das als separaten Change, nachdem die UI-Änderung als sicher bestätigt ist.

Ein typischer Fehler sieht so aus: Sie verschieben einen „Save“-Button in eine Sticky-Footer. Das Layout ist unproblematisch. Riskant wird es, wenn Sie onClick neu verdrahten zu einer anderen Funktion „weil es sauberer aussieht“. Dann sendet „Save“ plötzlich nicht mehr ein erforderliches Feld.

Regeln aus der UI in einen gemeinsamen Ort verschieben

Viele „UI-Bugs“ in KI-erstellten Apps sind nicht visuell. Der Screen macht heimlich Rechnungen, entscheidet über Berechtigung oder formt, was an den Server gesendet wird. Dann ändert ein Design-Tweak einen Prop-Namen oder die Komponentenstruktur und die Regeln ändern sich aus Versehen.

Ein sichereres Muster ist einfach: Regeln gehören in einen gemeinsamen Ort, die UI zeigt nur an und nimmt Eingaben entgegen.

Regeln dort ablegen, wo man sie findet

Wenn Preisberechnung, Rabatte, Berechtigungen oder Validierung in drei verschiedenen Screens existieren, erhalten Sie drei verschiedene Antworten. Erstellen Sie stattdessen ein Modul, das die Regeln besitzt, und rufen Sie es überall auf.

Zum Beispiel:

• PricingRules entscheidet über Totale und Eligibility.
• PricingCard zeigt nur Ergebnisse an.

Halten Sie es lesbar:

• Ein Modul pro Domain (pricing, billing, auth).
• Bevorzugen Sie pure Funktionen, wenn möglich (gleiche Eingabe, gleiche Ausgabe).
• UI-Komponenten erhalten finale Werte als Inputs.
• Serveraufrufe passieren an einem vorhersehbaren Ort, nicht in zufälligen Buttons.

UI-Komponenten bewusst „dumm“ halten

Eine Komponente, die Daten holt, Totale berechnet und die Seite rendert, ist schwer sicher zu ändern. Wenn alles gemischt ist, kann ein Layout-Change ein Refetch auslösen, einen Default ändern oder eine Prüfung überspringen.

Streben Sie nach diesem Ablauf: fetch data -> compute rules -> render UI.

Ein häufiges Szenario: Eine Pricing-Seite berechnet Steuer innerhalb einer Card-Komponente basierend auf lokalem UI-Status. Später ersetzt jemand eine Checkbox durch ein Toggle und ändert den Default auf „on“, weil es in Demos schöner wirkt. Jetzt werden reale Nutzer fälschlich besteuert. Wenn die Steuerberechnung in PricingRules gelebt hätte und die UI nur isTaxable übergibt, hätte die visuelle Änderung die Abrechnung nicht stillschweigend geändert.

Kritische Flows mit schnellen, wiederholbaren Checks schützen

Wenn Sie nur prüfen „sieht die Seite richtig aus?“, verpassen Sie Fehler, die Kunden treffen: Silent-Login-Fehler, Formulare, die nicht mehr speichern, oder falsche Preisberechnungen. Sie brauchen keine aufwändige Automation, um die meisten Fehler zu finden. Sie brauchen eine kurze Anzahl von Prüfungen, die Sie tatsächlich durchführen.

Wählen Sie ein paar Flows, die wirklich wichtig sind, und halten Sie die Liste kurz:

• Login und Session (anmelden, abmelden, eingeloggt bleiben).
• Checkout oder Zahlung (Totale, Rabatte, Bestätigung).
• Speichern und Laden (erstellen, bearbeiten, neu laden, Daten sind noch da).
• Berechtigungen (wer kann sehen, bearbeiten, löschen).

Für jeden Flow schreiben Sie Erwartungen in Klartext und verwenden dieselben Beispiel-Eingaben (ein Testnutzer, ein falsches Passwort, ein Warenkorb mit bekannten Artikeln, ein Gutschein). Stabile Eingaben machen Verhaltensänderungen offensichtlich.

Ein realistisches Beispiel: Sie räumen ein Login-Formular auf, indem Sie ein Input umbenennen oder in eine neue Komponente verschieben. Die UI sieht besser aus, aber die App sendet das Email-Feld nicht korrekt oder das Submit feuert zweimal. Wenn Ihre Prüfung sagt: „Mit [email protected] und Passwort WrongPass zeige 'Invalid credentials' und logge nicht ein“, fangen Sie den Fehler sofort.

Übliche Fallen, die „kleine“ UI-Änderungen riskant machen

Falle 1: Einen Button verschieben und dabei versehentlich den Handler ändern

Beim Umpositionieren eines Buttons ist es leicht, den falschen Handler anzuhängen, Argumente zu ändern oder Logik zwischen Parent und Child zu verschieben.

Achten Sie auf Warnsignale:

• Der Klick ruft jetzt eine andere Funktionsbezeichnung auf.
• Der Handler wurde verschoben und läuft dadurch zu einer anderen Zeit.
• Eine neue Inline-Funktion ändert die Argumente.
• Ein disabled-Zustand wurde entfernt, nur damit es optisch passt.

Falle 2: Felder, IDs oder Keys umbenennen, von denen andere Logik abhängt

UI-Code verlässt sich oft auf magische Strings, auf die andere Teile der App stillschweigend angewiesen sind: email, planId, billingAddress, user_id. Das Umbenennen zur besseren Lesbarkeit kann Form-Submission oder API-Mapping brechen.

Beispiel: Sie nennen billingEmail zu email um, damit es zum Design passt. Die UI sieht richtig aus, aber die API erwartet billingEmail, sodass die Anfrage ohne Daten abgesendet wird und die Abrechnung fehlschlägt.

Falle 3: Während eines Layout-Refactors API-Aufrufe in die UI ziehen

Beim Umstrukturieren ist es verlockend, „nur einen Fetch“ in eine UI-Datei zu verschieben. Bald hält die Komponente Layout-Code, State-Regeln und Netzwerkaufrufe. Dann ändert eine rein visuelle Änderung, wann Requests ausgeführt werden oder wie mit Fehlern umgegangen wird.

Ein rotes Warnsignal: Ihre Layout-Änderung berührt fetch, Token-Logik oder das Bauen von Request-Payloads.

Falle 4: UI von einem anderen Screen kopieren und damit Regeln überschreiben

Copy-Paste zieht oft Validierungs-Defaults und Edge-Case-Handling mit, die Sie nicht ändern wollten. Bevor Sie einfügen, prüfen Sie, ob Sie auch Submit-Logik, Validierungsschemas oder versteckte Defaults importieren.

Falle 5: Einen visuellen Bug durch Entfernen von Fehlerzuständen verstecken

Fehlermeldungen, rote Ränder oder Loading-Zustände zu entfernen, kann einen Screen „sauberer“ erscheinen lassen, aber auch echte Fehler verbergen und schlechten Datenfluss ermöglichen. Wenn eine Fehlermeldung stört, behandeln Sie sie als Hinweis und beheben die Ursache, statt die Warnung auszuschalten.

Beispiel: Ein Pricing-Page-Tweak, der die Abrechnung bricht

Ein typischer Bug: Sie redesignen Pricing-Cards und plötzlich stimmen die Checkout-Totale nicht mehr. Nichts wirkt „kaputt“, aber Kunden sehen falsche Beträge oder werden falsch belastet.

Typisches Szenario: Die alte Pricing-Card zeigte „$29/mo“ und „3 seats included“. Beim Redesign fügt die Card einen Monthly/Annual-Toggle hinzu. Die UI aktualisiert dann „hilfreich“ Variablen, um den Jahresrabatt zu berechnen.

Visuell ist das klein: neuer Toggle, neuer Abstand. Was sich ändert, ist die Mathematik. Die Card berechnet price * 12 * 0.8 und gibt diesen Wert weiter als Plan-Preis. Der Checkout hat bereits eigene Pricing-Regeln, erhält jetzt aber eine bereits rabattierte Zahl und multipliziert erneut. Totale stimmen nicht mehr, Steuern können falsch sein und Belege entsprechen nicht dem, was der Nutzer sah.

So verhindern Sie das: Trennen Sie Preis-Anzeige und Preisregelwerk:

• Machen Sie die UI für Preisangaben read-only: Werte anzeigen, nicht berechnen.
• Halten Sie eine einzige Quelle der Wahrheit für Preis-Inputs (plan id, interval, seats).
• Geben Sie Plan-IDs an den Checkout weiter, nicht rohe Zahlen.
• Wenn die UI etwas berechnen muss, beschränken Sie das auf Formatierung (Währung und Anzeige-Text).

Wenn es schon kaputt ist, stellen Sie schnell wieder her: Revertieren Sie die Änderung, die Berechnungen berührt (auch wenn die UI vorübergehend schlechter aussieht), isolieren Sie Preislogik in ein gemeinsames Modul, das sowohl Checkout als auch Schätz-Anzeigen verwenden, und wenden Sie dann das Redesign erneut mit sicheren Inputs und formatierten Outputs an.

Nächste Schritte, wenn Ihr KI-generierter Prototyp ständig bricht

Wenn jede „kleine“ UI-Änderung einen neuen Bug bringt, sind UI und Geschäftslogik wahrscheinlich miteinander verwoben. Weitere Anzeichen sind, dass Button-Style-Tweaks beeinflussen, was gespeichert wird, Auth nach Layout-Edits öfter bricht oder Fixes nur auf einer Maschine funktionieren.

Anzeichen, dass eine tiefere Bereinigung nötig ist:

• UI-Komponenten enthalten Regeln (Pricing, Berechtigungen, Validierung) statt geteilte Logik aufzurufen.
• Text- oder Layoutänderungen brechen API-Aufrufe, State oder das Speichern.
• Secrets oder Keys tauchen im Frontend auf, oder Auth bricht häufig.
• Niemand kann erklären, wo Totale, Rollen oder Abrechnungsregeln definiert sind.
• Jeder Fix erzeugt neue Bugs an anderer Stelle.

Eine fokussierte Sanierung muss nicht eine komplette Neuentwicklung bedeuten. Häufig ist eine kontrollierte Basisbehandlung ausreichend: Diagnose des Codebestands, Schlüssellogiken aus UI-Komponenten ziehen, die chaotischen Teile in klare Module refactoren, offensichtliche Sicherheitsprobleme härten (exponierte Secrets, typische Injection-Risiken) und die App so vorbereiten, dass Deployments konsistent laufen.

Wenn Sie eine KI-generierte App von Tools wie Lovable, Bolt, v0, Cursor oder Replit übernommen haben und sie in Produktion wiederholt ausfällt, spezialisiert sich FixMyMess (fixmymess.ai) darauf, fragile Prototypen in produktionsbereite Software zu verwandeln. Ein kostenloser Code-Audit kann zeigen, welche UI-Dateien verstecktes Billing-, Auth- oder Datenverhalten enthalten, bevor Sie die nächste "einfache" Design-Änderung anfassen.