Leer het 'niet wijzigen'-promptpatroon om één kleine update door te voeren terwijl je cruciale UI-flows, bedrijfsregels en gedrag bevroren houdt zodat niets anders verandert.
Een “kleine” wijziging blijft zelden klein. Je vraagt om het label van één knop aan te passen, en plotseling verschuift de paginalay-out, stopt een formulier met valideren of gedraagt een betalingsstap zich anders. Apps zijn verbonden systemen. UI, logica, data en integraties hangen van elkaar af.
Een veelvoorkomende oorzaak is onduidelijke grenzen. Als een verzoek zegt “maak de aanmelding eenvoudiger”, moet degene die bouwt (mens of AI) raden wat “eenvoudiger” betekent. Raden leidt tot extra aanpassingen: velden verwijderen, stappen veranderen, copy aanpassen of validatie herschrijven. Een andere oorzaak is verborgen afhankelijkheden. Een kleine UI-wijziging kan een component hergebruiken die op vijf andere schermen voorkomt.
Een veilige iteratie betekent dat je de ene bedoelde verbetering krijgt terwijl alles anders effectief identiek blijft. Voor een niet-technisch team betekent dat de workflow voor gebruikers hetzelfde aanvoelt, support-scripts nog steeds bij het product passen en rapportage logisch blijft. Voor een technisch team betekent het geen onverwachte veranderingen in routes, datastructuren, API-contracten of randgevalsgedrag.
Om dat mogelijk te maken, moet je vastleggen wat niet mag veranderen. In de praktijk omvat dat meestal kritieke flows (de exacte stappen die gebruikers doorlopen), UI- en UX-details (lay-out, afstand, interactiegedrag), bedrijfsregels (prijzen, permissies, validatie), datagedrag (wat en wanneer opgeslagen wordt) en integraties (analytics-events, e-mails, betalingen, externe API's).
Dit “niet wijzigen”-promptpatroon vermindert risico door het gokken weg te halen en de wijziging af te bakenen. Het is geen garantie. Er kan nog steeds drift optreden als het oorspronkelijke gedrag slecht gedefinieerd is, als de wijziging gedeelde componenten raakt of als je het resultaat niet verifieert. Het doel is minder verrassingen en snellere goedkeuringen.
Het niet wijzigen-patroon is een eenvoudige manier om te vragen om één specifieke update terwijl je duidelijk alles anders vergrendelt. Je noemt de ene wijziging die je wilt en schrijft vervolgens een korte freeze-lijst van de onderdelen die na de update identiek moeten blijven.
Dit is belangrijk omdat modellen vaak behulpzaam willen zijn door te refactoren, hernoemen, bestanden te reorganiseren of logica “op te schonen” terwijl ze de code aanraken. Zelfs als de output nog werkt, kunnen die extra wijzigingen bugs introduceren, gedrag veranderen of reviews moeilijker maken.
Vergelijk deze twee verzoeken:
“Maak de instellingenpagina beter.” Dit nodigt uit tot ontwerpwijzigingen, nieuwe copy, lay-outverschuivingen en logica-aanpassingen.
“Wijzig alleen de labeltekst van 'Telefoon' naar 'Mobiel telefoon'. Verander de lay-out, validatie of het save-gedrag niet.” Dit is nauw, toetsbaar en veiliger.
Een degelijke freeze-lijst dekt meestal drie gebieden:
Wanneer je dit patroon gebruikt in een chat-gebaseerde buildtool zoals Koder.ai, verlopen iteraties meestal sneller omdat het model zich concentreert op de ene wijziging in plaats van brede “verbeteringen” die je niet vroeg.
Dit patroon werkt het beste wanneer je verzoek leest als een klein contract: één duidelijk doel, een bevroren lijst van wat identiek moet blijven en een paar checks om het resultaat te bevestigen.
Kopieer deze template en vul de haakjes in. Houd het kort, maar specifiek.
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
Een concreet voorbeeld: als je de kleur van een checkout-knop wilt wijzigen, is je doel “Werk de primaire checkout-knop bij naar kleur #1A73E8.” Je DO NOT CHANGE-items moeten de volledige checkout-flow bevriezen, de knoptekst en de prijsberekening.
Als je Koder.ai gebruikt, maakt dit formaat reviews ook sneller omdat je de acceptatiechecks kunt vergelijken met de preview en de wijzigingssamenvatting voordat je iets goedkeurt.
Als je om een kleine wijziging vraagt, zeg dan niet alleen “breek niks”. Noem de exacte gebruikersreizen die hetzelfde moeten functioneren, van de eerste klik tot het eindresultaat. Je bevriest niet de hele app; je bevriest de delen waar regressies pijn doen.
Begin met het opsommen van kritieke flows in simpele taal: login (inclusief wachtwoordreset), onboarding, checkout, instellingen. Voor elke flow geef je aan hoe “klaar” eruitziet. Voorbeeld: “Gebruiker kan inloggen met e-mail + wachtwoord, komt op het Dashboard terecht en blijft ingelogd na refresh.”
Vergrendel daarna de edge-cases die mensen vergeten. Terugknopgedrag is een klassieke drift-bron: “Terug van Checkout gaat naar Winkelwagen (niet Home), en winkelwagenitems blijven staan.” Noem foutstaten (“verkeerd wachtwoord toont hetzelfde bericht”), lege staten (“geen projecten toont dezelfde lege-scherm-tekst”) en laadstaten (“spinner verschijnt binnen 200ms, geen layout-sprong”).
Als performance en security belangrijk zijn, bevries die ook. Noem ze expliciet, want als je ze niet vermeldt kan het model “verbeteringen” doen door extra requests toe te voegen, nieuwe logging te introduceren of auth-checks te veranderen.
Een compacte manier om dit te specificeren zonder een lang document:
Wees specifiek over dataflow in één zin per item. Bijvoorbeeld: “Adres wordt alleen opgeslagen na het drukken op Opslaan, wordt bewaard in het gebruikersprofielrecord en moet blijven na uit-/inloggen.” Dit detailniveau voorkomt per ongeluk autosave, nieuwe velden of timingveranderingen die echte gebruikers breken.
UI-drift gebeurt meestal omdat het model “behulpzaam” probeert te zijn door styles, spacing of componentstructuur op te schonen. De oplossing is hetzelfde als bij bedrijfslogica: benoem wat identiek moet blijven en geef expliciet aan wat wél mag veranderen.
Leg de zichtbare structuur vast. Noem lay-out (kolommen/rijen, header- en footerplaatsing), spacing-regels (padding, gaps, uitlijning) en componentgedrag (hover, disabled state, loading spinners, foutmeldingen). Als een component een specifieke feel heeft, zeg dat duidelijk: “Knopgrootte, radius en kleur moeten exact hetzelfde blijven.”
Responsief gedrag heeft expliciete regels nodig. Als je mobiel niet noemt, kan het systeem het “verbeteren”. Geef de breakpoints die je belangrijk vindt en wat er bij elke breakpoint moet gebeuren: stapeling, verborgen elementen, vaste balken en tap-targets.
Bevries ook woorden. Vertel het model dat alle copy, labels, placeholders en helptekst ongewijzigd moeten blijven, behalve de ene label die je bewerkt. Dit voorkomt stille herschrijvingen die betekenis veranderen.
Een compacte prompt die je in een wijzigingsverzoek kunt plakken:
Als het kan, vraag om voor/na-screenshots. Als die niet beschikbaar zijn, vraag om een korte “UI-diff”-beschrijving (wat bewoog, wat resized, wat van kleur veranderde) zodat je met vertrouwen kunt goedkeuren.
Bedrijfsregels zijn één van de makkelijkste plaatsen waar een kleine UI-wijziging een stille regressie kan veroorzaken. Een label-update kan per ongeluk een berekening, een statusovergang of wie een record mag zien veranderen. Behandel regels en datagedrag als bevroren contracten.
Begin met het benoemen van de paar regels die het meest pijn doen als ze wijzigen. Schrijf ze als tests: inputs, outputs en wie wat mag doen.
In plaats van “houd prijzen hetzelfde”, pin het vast:
Voeg één numeriek voorbeeld toe om interpretatie weg te nemen. Bijvoorbeeld: “Order subtotal $120, korting 10% (toepassen vóór belasting), belasting 8.25% op het kortingsbedrag. Verwachte total = (120 - 12) * 1.0825 = $116.91. Afronden op 2 decimalen alleen op het eindtotaal.”
Noem rolgebaseerde zichtbaarheid, niet alleen acties. Voorbeeld: “Supportmedewerkers kunnen orderstatus en klant-e-mail zien, maar mogen geen volledige kaartgegevens zien. Alleen admins kunnen refunds uitvoeren.”
Als validaties van belang zijn, bevries ze expliciet. Noem de exacte trigger en de gebruikersboodschap: “Als startdatum na einddatum is, blokkeer opslaan en toon: ‘Einddatum moet na startdatum liggen.’ Wijzig deze tekst niet.”
Vergeet neveneffecten buiten de app niet. Als je e-mails, webhooks of third-party API-aanroepen doet, bevries wat identiek moet blijven: event-namen, payload-velden, timing (onmiddellijk vs vertraagd) en idempotentiegedrag (geen dubbele verzendingen bij retry).
Behandel een kleine update als een mini-contract. Het patroon werkt het beste wanneer de wijziging smal is en alles anders expliciet bevroren is.
Schrijf de wijziging als één toetsbare zin. “Op de instellingenpagina, voeg een toggle toe om dark mode in te schakelen” is toetsbaar. “Verbeter de instellingen-UI” is dat niet. Als je het niet in 30 seconden kunt testen, is het nog te breed.
Schrijf een freeze-lijst voor de onderdelen die pijn doen als ze veranderen: gebruikersflow, sleutel-UI-elementen, bedrijfsregels, datagedrag en alle API's of database-tabellen die hetzelfde moeten blijven.
Voeg acceptatiechecks en een kort testplan toe. Hier voorkom je “het werkt bij mij” verrassingen. Neem checks op zoals: de nieuwe toggle verschijnt, bestaande instellingen blijven opslaan en niets anders op de pagina verschuift.
Vraag voordat er bewerkt wordt dat de assistant je constraints teruggeeft. Laat het bevestigen wat er zal veranderen en wat identiek moet blijven. Als de samenvatting niet klopt, pas het prompt aan voordat je wijzigingen toestaat.
Vraag de kleinst mogelijke implementatie: geen refactors, geen hernoemingen, geen format-passes en geen dependency-upgrades. Je koopt één wijziging, geen make-over.
Een korte review-checklist:
Dit werkt vooral goed in Koder.ai: plak de freeze-lijst in Planning Mode, laat het echoën en genereer dan de kleinste patch.
De meeste “kleine” edits gaan mis om dezelfde reden: het verzoek beschermt het doel, maar niet het gedrag. Een model kan je doel op een nieuwe manier bereiken die stilletjes schermen, logica of data verandert.
Een veelvoorkomende val is het bevriezen van het resultaat (“maak onboarding soepeler”) in plaats van de exacte stappen die gebruikers nemen. Een andere is “houd alles hetzelfde” schrijven en verwachten dat het systeem weet wat dat betekent.
Fouten die het vaakst drift veroorzaken:
Een klein voorbeeld: je vraagt om “de knop zichtbaarder te maken” en bevriest de kleur, maar vergeet de disabled-state te bevriezen. De update kan de knop altijd inschakelen, wat gedrag verandert dat je pas later merkt.
Wat helpt is specifiek benoemen wat niet mag bewegen. Voordat je de update accepteert, doe een korte regressiepass:
Als iets daarvan afwijkt, ontbrak er een bevroren detail in je verzoek, niet “slecht coderen”.
Een veelvoorkomende veilige iteratie is een kleine UI-polish waarbij de workflow niet mag veranderen.
Scenario: een founder heeft een simpele aanmeldpagina met een kort formulier (Naam, E-mail, Bedrijfsgrootte) en een primaire knop die het formulier verzendt en gebruikers naar het dashboard leidt.
Exact wijzigingsverzoek (één zin): “Hernoem de primaire knop van 'Account aanmaken' naar 'Doorgaan' en verander het veld 'Bedrijfsgrootte' van een open tekstveld naar een dropdown.”
Pas nu het patroon toe door vast te leggen wat identiek moet blijven:
Acceptatiechecks die je binnen enkele minuten kunt uitvoeren:
Een goede assistant-antwoord zou de bevroren items herhalen, eventuele onduidelijkheden benoemen (bijv. exacte dropdown-opties en welk waardeformaat opgeslagen wordt) en dan alleen de minimale code/UI-wijziging voorstellen. Het zou ook noemen wat het bewust niet aanraakte (routing, validatielogica, payload-shape).
Voordat je een “kleine wijziging” accepteert, doe een korte check op stille drift. Het doel is geen volledige QA. Het is bevestigen dat de app zich nog steeds hetzelfde gedraagt op alle plaatsen die je “niet wijzigen” zei, behalve de bedoelde ene aanpassing.
Voer deze checks altijd in dezelfde volgorde uit. Dat houdt reviews rustig en maakt regressies makkelijker zichtbaar.
Draai terug als een bevroren item veranderde, ook als de app “nog werkt”. Een veranderd label, een nieuw veld of een iets andere regel duidt erop dat het model vrijheden nam. Herhaal het verzoek met strak afgebakende constraints: herhaal de ene wijziging in één zin, lijst de bevroren flows en schermen bij naam en voeg toe “geen schema-wijzigingen, geen endpoint-wijzigingen, geen gedrag buiten X.” Als je Koder.ai gebruikt, maakt een snapshot vóór testen terugdraaien een eenvoudige keuze.
Als je in Koder.ai bouwt, werkt het niet-wijzigen-patroon het beste als gewoonte: één kleine wijziging, de rest vergrendeld en een duidelijke manier terug als iets verschuift.
Voordat je om de wijziging vraagt, schakel naar Planning Mode en laat de assistant je scope in gewone woorden herhalen. Vraag het om twee dingen terug te geven: (1) de exacte wijziging en (2) een duidelijke freeze-lijst (flows, UI-details en bedrijfsregels die niet mogen bewegen). Een planningsprompt die goed werkt: “Herhaal mijn verzoek. Noem daarna wat niet mag veranderen. Als iets onduidelijk is, stel vragen voordat je bewerkt.”
Behandel elk wijzigingsverzoek als een checkpoint. Maak een snapshot vóór je de update toepast en nog een nadat je het verifieerde. Als er iets breekt, is terugdraaien sneller dan proberen over een slechte wijziging heen te patchen.
Voorbeeldworkflow:
Koder.ai kan web (React), backend (Go + PostgreSQL) en mobiel (Flutter) genereren. Het patroon blijft hetzelfde, ook al verschilt de code. Bevries de onderdelen die gedrag definiëren, niet alleen de bestanden.
Als je een backend-endpoint verandert, bevries request/response-shape, validatieregels en data-schrijfbewerkingen. Als je een mobiel scherm verandert, bevries navigatievolgorde, velddefaults en foutmeldingen. Als je database-logic verandert, bevries wat bestaande rijen betekenen en houd migraties veilig.
Kopieer je template, voer één kleine wijziging uit vandaag en verifieer hem met de checklist voordat je accepteert. Bewaar de templates en gebruik ze opnieuw voor het volgende wijzigingsverzoek, één per keer.
Gebruik het telkens wanneer je één specifieke wijziging wilt en je erop let dat alles anders precies hetzelfde blijft. Het is vooral handig voor checkout, authenticatie, facturatie of elke flow waar kleine afwijkingen echte problemen voor gebruikers kunnen veroorzaken.
Omdat onderdelen van een app componenten, data en regels delen. Een kleine UI-aanpassing kan een hergebruikt component raken, wat elders lay-outverschuivingen, gewijzigde validatie of gewijzigde API-payloads kan veroorzaken zonder dat je het meteen ziet.
Schrijf één helder doel en lijst daarna op wat identiek moet blijven na de wijziging. Het belangrijkste is gedrag te bevriezen (flows, regels, data, integraties) en zichtbare UI-details, niet alleen zeggen “breek niks”.
Houd het kort maar specifiek: kritieke flows, UI/UX-details die niet mogen veranderen, bedrijfsregels, datagedrag en integraties. Als je niet kunt benoemen wat gelijk moet blijven, moet het model raden, en raden veroorzaakt drift.
Scope het naar het kleinste gebied dat je toch beschermt. Bijvoorbeeld: bevries de checkout-flow en de gedeelde componenten ervan, maar bevries niet de hele app als je alleen een label op één scherm aanpast.
Noem de gebruikersreizen stap voor stap en definieer wat “klaar” betekent. Voeg de veelvoorkomende edge-cases toe zoals terugknopgedrag, foutmeldingen, lege staten en refresh-gedrag zodat de flow op de plekken blijft die gebruikers het meest merken.
Bevries expliciet structuur, spacing, componentstaten (hover/disabled/loading) en alle copy behalve de ene string die je wijzigt. Zonder dat kan het model styles opschonen of tekst herschrijven op manieren die betekenis of layout veranderen.
Bevries contracten: request/response-vormen, validatieregels, permissies, berekeningen en wat wanneer opgeslagen wordt. Voeg één numeriek voorbeeld toe voor gevoelige regels zoals prijsberekeningen zodat er geen interpretatieverschil is bij implementatie.
Vraag om acceptatiecontroles die je snel kunt uitvoeren, plus een korte diff-achtige samenvatting van wat waar veranderde. Controleer vervolgens de bevroren flows end-to-end, trigger minimaal één foutstaat en bevestig dat data/integraties ongewijzigd zijn.
Maak een snapshot vóór de wijziging, voer een planningsstap uit waarin de scope en freeze-lijst herhaald worden, en pas dan de kleinste patch toe. Na verificatie maak je een nieuwe snapshot zodat terugdraaien één stap is als er iets verschuift.
Vooraf: maak een snapshot en laat de assistant je constraints herhalen. Daarna: vraag alleen de kleinste implementatie, geen refactors of hernoemingen. Tenslotte: verifieer met de checklist en maak een post-verificatie snapshot.
Als een bevroren item veranderde, draai terug, ook al “werkt” de app nog. Een gewijzigd label, een nieuw veld of een iets andere regel betekent dat het model te veel vrijheid nam. Herhaal het verzoek met strakkere constraints en maak voor de test een snapshot.