Lernen Sie das ‚Nicht-Ändern‘-Prompt-Muster, um eine kleine Änderung durchzuführen und gleichzeitig kritische UI-Flows, Geschäftsregeln und wichtiges Verhalten einzufrieren, damit sonst nichts abweicht.
Eine „kleine" Änderung bleibt selten klein. Sie bitten darum, ein Button-Label anzupassen, und plötzlich verschiebt sich ein Seitenlayout, ein Formular validiert nicht mehr, oder ein Checkout-Schritt verhält sich anders. Apps sind vernetzte Systeme. UI, Logik, Daten und Integrationen stützen sich gegenseitig.
Eine häufige Ursache sind unklare Grenzen. Wenn eine Anfrage sagt „macht das Signup einfacher", muss der Umsetzer (menschlich oder AI) raten, was „einfacher" bedeutet. Raten führt zu zusätzlichen Änderungen: Felder entfernen, Schritte ändern, Copy anpassen oder Validierung umschreiben. Eine andere Ursache sind versteckte Abhängigkeiten. Eine kleine UI-Änderung kann eine Komponente betreffen, die auf fünf anderen Screens wiederverwendet wird.
Eine sichere Iteration bedeutet, dass Sie genau die eine gewünschte Verbesserung bekommen, während sonst alles effektiv identisch bleibt. Für ein nicht-technisches Team heißt das: der Workflow fühlt sich für Nutzer gleich an, Support-Skripte stimmen noch mit dem Produkt überein, und Reports bleiben sinnvoll. Für ein technisches Team heißt das: keine unerwarteten Änderungen an Routes, Datenschemata, API-Verträgen oder Edge-Case-Verhalten.
Um das zu ermöglichen, müssen Sie festlegen, was sich nicht bewegen darf. In der Praxis umfasst das normalerweise kritische Flows (die exakten Schritte, die Nutzer durchlaufen), UI- und UX-Details (Layout, Abstände, Interaktionsverhalten), Geschäftsregeln (Preisbildung, Berechtigungen, Validierung), Datenverhalten (was wann gespeichert wird) und Integrationen (Analytics-Events, E-Mails, Zahlungen, externe APIs).
Dieses „Nicht-Ändern"-Prompt-Muster reduziert Risiko, indem es das Raten entfernt und die Änderung einschränkt. Es ist keine Garantie. Drift kann immer noch auftreten, wenn das ursprüngliche Verhalten schlecht definiert ist, die Änderung geteilte Komponenten berührt oder Sie das Ergebnis nicht verifizieren. Das Ziel ist weniger Überraschungen und schnellere Freigaben.
Das Nicht-Ändern-Prompt-Muster ist eine einfache Methode, um um eine spezifische Änderung zu bitten und gleichzeitig alles andere klar zu sperren. Sie nennen die eine Änderung, die Sie möchten, und schreiben dann eine kurze Freeze-Liste der Teile, die nach der Änderung identisch bleiben müssen.
Das ist wichtig, weil Modelle oft versuchen, „hilfreich" zu sein, indem sie refaktorisieren, umbenennen, Dateien reorganisieren oder Logik „aufräumen", während sie am Code arbeiten. Selbst wenn das Ergebnis noch funktioniert, können diese zusätzlichen Änderungen Bugs einführen, Verhalten ändern oder Reviews erschweren.
Vergleichen Sie diese beiden Anfragen:
“Make the settings page better.” Das lädt zu Designänderungen, neuer Copy, Layout-Verschiebungen und Logik-Tweaks ein.
“Change only the label text from ‘Phone’ to ‘Mobile phone’. Do not change layout, validation, or the save behavior.” Das ist eng gefasst, testbar und sicherer.
Eine solide Freeze-Liste deckt üblicherweise drei Bereiche ab:
Wenn Sie dieses Muster in einem chat-basierten Build-Tool wie Koder.ai verwenden, laufen Iterationen in der Regel schneller, weil das Modell sich auf die einzelne Änderung konzentriert, statt allgemeine „Verbesserungen" vorzunehmen, die Sie nicht angefordert haben.
Dieses Muster funktioniert am besten, wenn Ihre Anfrage wie ein kleiner Vertrag klingt: ein klares Ziel, eine eingefrorene Liste dessen, was identisch bleiben muss, und ein paar Prüfungen zur Bestätigung des Ergebnisses.
Kopieren Sie diese Vorlage und füllen Sie die Klammern aus. Halten Sie es kurz, aber spezifisch.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Ein konkretes Beispiel: Wenn Sie die Farbe eines Checkout-Buttons ändern wollen, lautet Ihr Ziel „Update the primary checkout button color to #1A73E8." Ihre DO NOT CHANGE-Punkte sollten den gesamten Checkout-Flow, den Button-Text und die Preiskalkulation einfrieren.
Wenn Sie Koder.ai benutzen, macht dieses Format Reviews schneller, weil Sie die Akzeptanzprüfungen mit der Vorschau und der Änderungssummary vergleichen können, bevor Sie etwas freigeben.
Wenn Sie um eine kleine Änderung bitten, sagen Sie nicht einfach „brechen Sie nichts." Nennen Sie die genauen Nutzerpfade, die gleich bleiben müssen, vom ersten Klick bis zum finalen Ergebnis. Sie frieren nicht die ganze App ein, sondern die Bereiche, bei denen Regressionen schaden.
Beginnen Sie damit, die kritischen Flows in klarer Sprache aufzulisten: Login (inklusive Passwort-Reset), Onboarding, Checkout, Einstellungen. Für jeden Flow sagen Sie, wie „done" aussieht. Beispiel: „User can log in with email + password, lands on Dashboard, and stays signed in after refresh."
Dann sperren Sie die Edge-Cases, die oft vergessen werden. Das Verhalten des Zurück-Buttons ist eine klassische Ursache für Drift: „Back from Checkout returns to Cart (not Home), and cart items remain." Nennen Sie Fehlermeldungen („wrong password shows the same message"), leere Zustände („no projects shows the same empty screen copy") und Ladezustände („spinner appears within 200ms, no layout jump").
Wenn Performance- und Sicherheitsanforderungen wichtig sind, frieren Sie diese ebenfalls ein. Wenn Sie sie nicht erwähnen, könnte das Modell „Verbesserungen" hinzufügen, z. B. zusätzliche Requests, neues Logging oder geänderte Auth-Prüfungen.
Eine kompakte Art, das ohne Roman anzugeben:
Formulieren Sie den Datenfluss in einem Satz pro Punkt. Zum Beispiel: „Address is saved only after pressing Save, stored in the user profile record, and must persist after logout/login." Diese Detailtiefe verhindert versehentliches Autosave, neue Felder oder Timing-Änderungen, die echte Nutzer brechen.
UI-Drift entsteht oft, weil das Modell styles, Abstände oder die Komponentenstruktur „aufräumt." Die Lösung ist dieselbe wie bei Geschäftslogik: nennen Sie, was identisch bleiben muss, und nennen Sie die eine Sache, die sich ändern darf.
Fixieren Sie die sichtbare Struktur. Nennen Sie Layout (Spalten/Zeilen, Header- und Footer-Platzierung), Abstandsregeln (Padding, Gaps, Alignment) und Komponentenverhalten (Hover, disabled state, Loading-Spinners, Fehlermeldungen). Wenn eine Komponente ein spezifisches „Gefühl" hat, sagen Sie es offen: „Button size, radius, and color must stay exactly the same."
Responsive-Verhalten braucht explizite Regeln. Wenn Sie Mobile nicht erwähnen, könnten Tools „Verbesserungen" vornehmen. Geben Sie die Breakpoints an, die Ihnen wichtig sind, und was an jedem passieren muss: Stapelreihenfolge, verborgene Elemente, fixe Bars und Tap-Ziele.
Freeze auch die Worte. Sagen Sie dem Modell, dass alle Copy, Labels, Placeholders und Hilfetexte unverändert bleiben, außer dem einen Label, das Sie bearbeiten. Das verhindert stille Umschreibungen, die Bedeutung oder Verhalten ändern.
Eine kompakte Aufforderung, die Sie in eine Änderungsanfrage kopieren können:
Wenn möglich, verlangen Sie Before/After-Screenshots. Falls keine Screenshots verfügbar sind, fordern Sie eine kurze „UI diff"-Beschreibung (was sich bewegt hat, was skaliert wurde, was die Farbe geändert hat), damit Sie mit Zuversicht freigeben können.
Geschäftsregeln sind einer der einfachsten Orte, an denen eine kleine UI-Änderung eine stille Regression erzeugen kann. Ein Label-Update kann versehentlich eine Berechnung, einen Statuswechsel oder wer einen Datensatz sehen kann, verändern. Behandeln Sie Regeln und Datenverhalten als eingefrorene Verträge.
Beginnen Sie damit, die wenigen Regeln zu benennen, die am meisten schaden würden, wenn sie driften. Schreiben Sie sie wie Tests: Eingaben, Ausgaben und wer was darf.
Anstatt „keep pricing the same" festzulegen, konkretisieren Sie:
Fügen Sie ein numerisches Beispiel hinzu, um Interpretationen zu vermeiden. Zum Beispiel: „Order subtotal $120, discount 10% (applies before tax), tax 8.25% on discounted amount. Expected total = (120 - 12) * 1.0825 = $116.91. Rounding to 2 decimals only at the final total."
Nennen Sie rollenbasierte Sichtbarkeit, nicht nur Aktionen. Beispiel: „Support agents can view order status and customer email, but must not see full card details. Only admins can issue refunds."
Wenn Validierungen wichtig sind, frieren Sie sie explizit ein. Erwähnen Sie den genauen Trigger und die nutzerseitige Meldung: „If start date is after end date, block save and show: ‘End date must be after start date.’ Do not change this wording."
Vergessen Sie nicht Seiteneffekte außerhalb der App. Wenn Sie E-Mails, Webhooks oder Dritt-APIs aufrufen, frieren Sie ein, was gleich bleiben muss: Event-Namen, Payload-Felder, Timing (sofort vs verzögert) und Idempotenz-Verhalten (keine doppelten Sends bei Retry).
Behandeln Sie eine winzige Änderung wie einen Mini-Vertrag. Das Muster funktioniert am besten, wenn die Änderung eng gefasst ist und alles andere explizit eingefroren wird.
Formulieren Sie die Änderung als einen testbaren Satz. „On the settings page, add a toggle to enable dark mode" ist testbar. „Improve the settings UI" ist es nicht. Wenn Sie es nicht in 30 Sekunden testen können, ist es noch zu breit.
Schreiben Sie eine Freeze-Liste für die Teile, die bei Drift schaden würden: Nutzerfluss, Schlüssel-UI-Elemente, Geschäftsregeln, Datenverhalten und APIs oder Datenbanktabellen, die gleich bleiben müssen.
Fügen Sie Akzeptanzprüfungen und einen kurzen Testplan hinzu. Hier verhindern Sie „works on my side"-Überraschungen. Einschließen: der neue Toggle erscheint, bestehende Einstellungen speichern weiterhin, und nichts anderes auf der Seite verschiebt sich.
Bevor mit dem Editieren begonnen wird, lassen Sie den Assistenten Ihre Constraints zurückgeben. Lassen Sie ihn bestätigen, was geändert wird und was identisch bleiben muss. Wenn die Zusammenfassung falsch ist, korrigieren Sie das Prompt, bevor Sie Änderungen erlauben.
Fordern Sie die kleinstmögliche Implementierung an: keine Refactors, keine Umbenennungen, keine Formatierungsdurchläufe, keine Dependency-Upgrades. Sie kaufen eine Änderung, kein Makeover.
Eine kurze Review-Checklist:
Das funktioniert besonders gut in Koder.ai: die Freeze-Liste in Planning Mode einfügen, vom Assistenten Echo der Constraints verlangen und dann den kleinsten Patch generieren lassen.
Die meisten „kleinen" Edits laufen aus demselben Grund schief: die Anfrage schützt das Ziel, aber nicht das Verhalten. Ein Modell kann Ihr Ziel auf neue Weise erreichen, die Screens, Logik oder Daten still verändert.
Eine häufige Falle ist, das Ergebnis einzufrieren („make onboarding smoother") statt die exakten Schritte, die Nutzer nehmen. Eine andere ist „keep everything the same" zu schreiben und anzunehmen, das System wüsste, was das bedeutet.
Fehler, die am häufigsten Drift verursachen:
Ein kleines Beispiel: Sie bitten, „den Button sichtbarer zu machen" und frieren die Farbe ein, vergessen aber den disabled-Zustand. Das Update könnte den Button immer aktivieren und so Verhalten verändern, das Sie erst später bemerken.
Hilfreich ist, sehr konkret zu sagen, was sich nicht bewegen darf. Vor der Annahme der Änderung führen Sie einen schnellen Regressions-Check durch:
Wenn eines davon abweicht, fehlte in der Anfrage eine eingefrorene Detailangabe — es war kein „schlechter Code".
Eine häufige sichere Iteration ist ein kleines UI-Polish, bei dem der Workflow unverändert bleiben muss.
Szenario: Eine Gründerin hat einen einfachen Signup-Screen mit einem kurzen Formular (Name, E‑Mail, Firmengröße) und einem primären Button, der das Formular absendet und Nutzer zum Dashboard weiterleitet.
Exakte Änderungsanfrage (ein Satz): „Rename the primary button from 'Create account' to 'Continue' and change the 'Company size' field from a free-text input to a dropdown."
Wenden Sie nun das Muster an, indem Sie einfrieren, was gleich bleiben muss:
Akzeptanzprüfungen, die Sie in Minuten durchführen können:
Ein guter Assistent sollte die eingefrorenen Punkte wiederholen, Unklarheiten (z. B. genaue Dropdown-Optionen und welches Value gespeichert wird) bestätigen und dann nur die minimal nötige Code-/UI-Änderung durchführen. Er sollte auch angeben, was er bewusst nicht angefasst hat (Routing, Validierungslogik, Payload-Shape).
Bevor Sie eine „kleine Änderung" annehmen, machen Sie einen schnellen Durchlauf, der nach stiller Drift sucht. Ziel ist nicht vollständige QA, sondern zu bestätigen, dass die App überall dort, wo Sie „do not change" gesagt haben, gleich bleibt — außer bei der einen beabsichtigten Anpassung.
Führen Sie diese Checks immer in der gleichen Reihenfolge aus. Das beruhigt Reviews und macht Regressionen leichter erkennbar.
Rollback, wenn ein eingefrorener Punkt sich geändert hat, auch wenn die App „noch funktioniert". Ein geändertes Label, ein neues Feld oder eine leicht andere Regel ist ein Zeichen dafür, dass das Modell zu weit gegangen ist.
Stellen Sie die Anfrage schärfer neu: formulieren Sie die einzelne Änderung in einem Satz, listen Sie die eingefrorenen Flows und Screens namentlich und fügen Sie „no schema changes, no endpoint changes, no behavior changes outside X" hinzu. Wenn Sie Koder.ai nutzen, macht ein Snapshot vor dem Testen das Zurücksetzen einfacher, wenn etwas driftet.
Wenn Sie in Koder.ai bauen, funktioniert das Nicht-Ändern-Prompt-Muster am besten als Gewohnheit: eine kleine Änderung, alles andere gesperrt, und ein klarer Weg zurück, falls etwas driftet.
Bevor Sie die Änderung anfragen, wechseln Sie in den Planning Mode und lassen Sie den Assistenten Ihren Umfang in einfachen Worten wiedergeben. Lassen Sie ihn zwei Dinge zurückgeben: (1) die genaue Änderung und (2) eine klare Freeze-Liste (Flows, UI-Details und Geschäftsregeln, die nicht verschoben werden dürfen).
Eine funktionierende Planungsaufforderung: „Restate my request. Then list what must not change. If anything is unclear, ask questions before editing."
Behandeln Sie jede Änderungsanfrage wie einen Checkpoint. Erstellen Sie einen Snapshot vor der Änderung und einen weiteren nach der Verifikation. Wenn etwas bricht, ist ein Rollback schneller als ein Patch über eine fehlerhafte Änderung.
Zum Beispiel passen Sie ein Button-Label in einem React-Screen an. Die Änderung wirkt winzig, kann aber Abstände verschieben, ein Rerender-Problem auslösen oder einen automatischen Test brechen. Ein Snapshot erlaubt einen schnellen Vergleich und ein schnelles Zurücksetzen.
Ein einfacher Workflow:
Koder.ai kann Web (React), Backend (Go + PostgreSQL) und Mobile (Flutter) generieren. Das Muster bleibt gleich, auch wenn der Code unterschiedlich ist. Frieren Sie die Teile ein, die Verhalten definieren, nicht nur die Dateien.
Wenn Sie einen Backend-Endpoint ändern, frieren Sie Request/Response-Shape, Validierungsregeln und Daten-Schreibvorgänge ein. Wenn Sie einen Mobile-Screen ändern, frieren Sie Navigationsreihenfolge, Feld-Defaults und Fehlermeldungen ein. Wenn Sie DB-Logik ändern, frieren Sie die Bedeutung bestehender Zeilen und sichere Migrationen ein.
Kopieren Sie Ihre Vorlage, führen Sie heute eine kleine Änderung durch und verifizieren Sie sie mit der Checkliste, bevor Sie die Änderung annehmen. Bewahren Sie die Vorlagentexte auf und tauschen Sie beim nächsten Mal einfach die Änderung aus — eine nach der anderen.
Verwenden Sie es immer dann, wenn Sie eine spezifische Änderung möchten und darauf bestehen, dass sonst alles unverändert bleibt. Besonders wichtig bei Checkout, Auth, Abrechnung oder anderen Abläufen, bei denen kleine Abweichungen echte Nutzerprobleme verursachen.
Weil App-Teile Komponenten, Daten und Regeln teilen. Eine kleine UI-Änderung kann eine wiederverwendete Komponente betreffen, Layouts verschieben, Validierung ändern oder API-Payloads verändern—oft ohne dass man es sofort merkt.
Formulieren Sie ein klares Ziel und listen Sie dann auf, was nach der Änderung identisch bleiben muss. Entscheidend ist, Verhalten einzufrieren (Flows, Regeln, Daten, Integrationen) und sichtbare UI-Details — nicht nur „zerstör nichts" zu sagen.
Kurz, aber konkret: kritische Flows, UI/UX-Details, Geschäftsregeln, Datenverhalten und Integrationen. Wenn Sie nicht benennen können, was gleich bleiben muss, muss das System raten — und Raten verursacht Drift.
Begrenzen Sie es auf den kleinstmöglichen Bereich, der Sie schützt. Frieren Sie etwa den Checkout-Flow und seine geteilten Komponenten ein, aber nicht die ganze App, wenn Sie nur ein Label auf einem Bildschirm ändern.
Nennen Sie die Journeys Schritt für Schritt und definieren Sie, wann etwas als „fertig" gilt. Fügen Sie typische Randfälle hinzu wie Zurück-Button-Verhalten, Fehlermeldungen, leere Zustände und Refresh-Verhalten, damit die Flow-Abschnitte, die Nutzer bemerken, identisch bleiben.
Explizit: Layoutstruktur, Abstände, Komponenten-Zustände (hover/disabled/loading) und alle Texte außer dem einen String, den Sie ändern. Andernfalls „bereinigen“ Modelle Styles oder formulieren Texte um, was Bedeutung oder Layout verändern kann.
Frieren Sie Verträge ein: Request/Response-Formate, Validierungsregeln, Berechtigungen, Berechnungen und was wann gespeichert wird. Fügen Sie bei sensiblen Regeln ein numerisches Beispiel hinzu (z. B. Preisformel), damit es keine Interpretation gibt.
Lassen Sie sich Akzeptanzprüfungen geben, die Sie schnell laufen können, plus eine kurze diff-artige Zusammenfassung dessen, was sich geändert hat und wo. Prüfen Sie dann die gefrorenen Flows Ende-zu-Ende, lösen Sie mindestens einen Fehlerzustand aus und bestätigen Sie, dass Daten/Integrationen unverändert sind.
Snapshot vor der Änderung, eine Planungsrunde, die Umfang und Freeze-Liste wiederholt, dann den kleinsten Patch anwenden. Nach der Verifizierung erneut snapshotten, sodass ein Rollback schnell geht, falls etwas driftet.