Waarom vibe coding floreert door onvolmaaktheid en verandering

Wat vibe coding betekent (en wat het niet is)

“Vibe coding” is een manier van software bouwen waarbij je momentum omarmt: begin met een ruw idee, schrijf het eenvoudigste dat werkt en laat echte feedback bepalen wat je daarna bouwt. Het gaat minder om het volgen van een perfect plan en meer om het project lang genoeg in beweging houden om te ontdekken wat echt belangrijk is.

Wat het wel is

Vibe coding is een praktische mindset:

• Begin klein, lever iets dat je kunt testen.
• Leer van wat breekt, gebruikers verward of te veel tijd kost.
• Pas snel aan, ook als dat betekent dat je van richting verandert.

In het begin telt snelheid omdat onzekerheid groot is. Je weet nog niet welke functies waardevol zijn, welke randgevallen echt voorkomen, of het idee überhaupt een “eindversie” verdient. Snelle iteraties kopen je duidelijkheid.

Wat het niet is

Vibe coding is geen loos excuus van “maak je niet druk”. Het is geen vrijbrief om basiszaken zoals dataveiligheid, security of gebruikersvertrouwen te negeren. Het betekent ook niet dat je nooit refactort—alleen dat je afwerking uitstelt totdat je het verdiend hebt.

Snel vs. slordig

“Snel” betekent dat je weloverwogen afwegingen maakt om de time-to-learning te verkleinen:

• Je vereenvoudigt eisen.
• Je schrapt optionele functies.
• Je accepteert een tijdelijke hack met een duidelijk plan om die te reviseren.

“Slordig” betekent dat je helemaal niet nadenkt:

• Geen notities over wat tijdelijk is.
• Geen minimale checks.
• Geen manier om problemen te reproduceren.

Het echte doel: leren

Het doel van vibe coding is geen perfectie maar inzicht. Elke kleine release is een vraag die je aan de echte wereld stelt: wil iemand dit? Welk deel is verwarrend? Wat moet je daarna automatiseren? Je bouwt kennis evenveel als je software bouwt.

Onvolmaaktheid is een kenmerk van echt werk

Perfecte plannen zijn zeldzaam omdat echte projecten niet statisch zijn. Vereisten verschuiven na een klantgesprek, een collega ziet een betere aanpak of je ziet het product pas echt werken. Vibe coding werkt omdat het die rommeligheid als normaal behandelt, niet als falen van discipline.

Waarom perfectie je vertraagt

De angst om fouten te maken creëert vaak een verborgen vertraging: je wacht met beginnen tot je je zeker voelt. Maar zekerheid komt meestal pas nadat je iets gebouwd hebt en het gedrag hebt gezien.

Als je streeft naar “geen ruwe randen”, neig je ertoe om:

• het opleveren uit te stellen totdat je elk geval voorspeld hebt
• beslissingen te vermijden die feedback zouden opleveren (omdat feedback negatief kan zijn)
• te veel beschermingen te bouwen voor problemen die misschien nooit optreden

Het resultaat is geen hogere kwaliteit—het is trager leren.

Bugs en ruwe randen zijn signalen

Onvolmaaktheden zijn informatie. Een verwarrend scherm vertelt je waar mensen vastlopen. Een breekbare functie onthult waar de grenzen van je systeem echt liggen. Een “vreemde” supportmelding toont wat gebruikers daadwerkelijk proberen, niet wat jij bedacht hebt.

Zo gezien zijn bugs niet alleen defecten om te verbergen. Ze zijn een kaart van wat er daarna belangrijk is.

“Goed genoeg voor nu” is een valide beslissing

Imperfecte code uitrollen betekent niet slordige code opleveren. Het betekent inspanning afstemmen op onzekerheid.

“Goed genoeg voor nu” is de juiste keuze wanneer:

• de functie nog gevormd wordt door feedback
• de kosten van ongelijk hebben laag en omkeerbaar zijn
• je echte gebruiksdata nodig hebt om de juiste richting te kiezen

Als je kunt terugdraaien, de schade kunt beperken en snel kunt leren, wordt onvolmaaktheid een instrument. Je verlaagt de lat niet—je ordent hem: bewijs eerst waarde, verstevig daarna wat blijft.

Tijdelijke hacks: het goede, het slechte en het bruikbare

Tijdelijke hacks horen erbij in vibe coding: je probeert te leren wat het werk echt is voordat je je commit aan “juiste” architectuur. De truc is weten welke shortcuts gezond zijn en welke stilletjes permanent worden.

Het goede: hacks die leren kopen

Veelvoorkomende “getting it working”-hacks zijn:

• Hardgecodeerde waarden (API-keys in een lokaal bestand, vaste ID's, één gebruikersaccount)
• Handmatige stappen (draai een commando, kopieer/plak een CSV, start een deploy handmatig)
• Simpele scripts (eenmalige Python/Bash om bestanden te hernoemen of data te backfillen)
• Dunne integraties (“roep gewoon de endpoint aan,” geen retries of monitoring nog)

Deze kunnen valide prototypes zijn omdat ze snel hoge-waarde vragen beantwoorden: wil iemand dit? Welke inputs doen ertoe? Waar zitten de echte randgevallen? Een hack is nuttig wanneer hij onzekerheid verkleint en scope onder controle houdt.

Het slechte: hacks die onzichtbare afhankelijkheden worden

Hacks worden schadelijk wanneer ze niet meer als hacks aanvoelen.

Het gevaarlijke patroon is “het werkt, dus niemand raakt het meer aan.” Na verloop van tijd gaan teamgenoten (of je toekomstige ik) vertrouwen op verborgen aannames:

• Een hardgecodeerde waarde wordt “de enige waarde” die het systeem aankan
• Een handmatige stap wordt het enige falingspunt in een release
• Een snel script wordt het enige naslagwerk van hoe data getransformeerd wordt

Zo worden tijdelijke shortcuts onzichtbare afhankelijkheden: kritisch gedrag dat niet gedocumenteerd, getest of toegewezen is.

“Tijdelijk” is een belofte die je moet beheren

Iets tijdelijk noemen is geen label—het is een commitment.

Maak de belofte concreet:

• Schrijf op waarom het een hack is en wat “goed gedaan” betekent
• Zet er een vervaldatum of trigger op (“verwijderen na de eerste betalende klant,” “vervangen voor publieke lancering”)
• Volg het in je backlog, niet alleen in je hoofd

Een goed beheerde hack is eerlijk, tijdgebonden en makkelijk te vervangen. Een onbeheerde hack is gewoon technische schuld met betere vibes.

Continue verandering verslaat perfecte voorspelling

Proberen het meteen “goed” te krijgen voelt verantwoordelijk—tot de realiteit zich aandient. Vibe coding leunt op een eenvoudiger waarheid: je kunt niet voorspellen wat gebruikers waarderen totdat ze iets daadwerkelijk kunnen gebruiken.

Snelle releases creëren echte feedback

Een snelle release verandert meningen in bewijs. In plaats van functies in meetings te debatteren, lever je een klein deel en kijk je wat er gebeurt: waar klikken mensen, wat negeren ze, waar vragen ze om en wat verwart ze.

Die feedback is moeilijk na te bootsen. Het is ook de enige soort die prioriteiten betrouwbaar verandert. Een plan is een gok; een uitgebracht feature is een test.

Vroege code is bedoeld om hervormd te worden

De eerste versie is geen fundament—het is een sonde. Vroege code wordt vaak:

• Vervangen omdat je een betere aanpak leerde
• Vereenvoudigd omdat de functie minder belangrijk bleek
• Uitgebreid omdat gebruikers een echte behoefte vonden die je niet voorzag

Dit is geen mislukking. Het is de verwachte kosten van snel leren.

De feedbackloop: bouwen → opleveren → leren → aanpassen

De kracht zit in de lus, niet in de eerste poging:

1. Bouw de kleinst mogelijke nuttige versie
2. Lever die aan echte gebruikers (ook al is het ruw)
3. Leer van gedrag en supportverzoeken
4. Pas aan scope, ontwerp en implementatie

Als de lus kort is, is verandering goedkoop. Als de lus lang is, wordt veranderen eng—en klampen teams zich vast aan voorspellingen.

Eenvoudig voorbeeld: vereisten verschuiven na de eerste demo

Stel dat je een “Saved Searches”-feature demo’t. Je bouwde een UI om filters een naam te geven en op te slaan, in de veronderstelling dat gebruikers een bibliotheek met opgeslagen weergaven zouden beheren.

Na de demo gebeuren drie dingen:

• Gebruikers geven geen namen aan searches—ze willen gewoon “één-tap opnieuw uitvoeren” van de laatste filter.
• De echte pijn is het delen van searches met collega’s.
• Support meldt verwarring over wat opgeslagen wordt (filters vs. resultaten).

Als je alles perfect gepland had, zat je nog steeds fout. Als je snel leverde, heb je nu duidelijke richting: prioriteer “Recente Filters” en “Deelbare Links,” en vereenvoudig het opslagmodel. De code die je schreef is geen verspilling—het was een opstapje dat onthulde wat je daarna moet bouwen.

Het doel is niet om verandering te voorspellen. Het is om je workflow zo te ontwerpen dat verandering normaal, veilig en productief is.

Hoe je imperfectie veilig maakt

Imperfect werk wordt gevaarlijk wanneer niemand kan zien wat “tijdelijk” is en wat “nu het systeem is.” Het doel is niet om shortcuts te vermijden—het is ze zichtbaar, omkeerbaar en begrensd te maken.

Maak de shortcut expliciet

De eenvoudigste veiligheidsstap is benoemen wat je doet terwijl je het doet. Gebruik labels als “hack”, “prototype” of “v1” in commits of tickets zodat je toekomstige ik (of een collega) een snelle patch niet als langetermijnontwerp ziet.

Als je solo werkt, blijft dit belangrijk. Over een maand herinner je je niet meer welke delen intentioneel waren en welke “even voor nu”.

Maak direct het “bewijs” aan

Shortcuts zijn prima; vergeten shortcuts zijn duur. Voeg meteen een opvolgende taak toe zodra je een shortcut introduceert—zolang de context fris is en je nog weet hoe de “juiste” versie eruitziet.

Een nuttige opvolgtaak is specifiek en toetsbaar:

• Vervang hard gecodeerde limiet door config + validatie
• Voeg error handling toe voor timeout en retry-strategie
• Verwijder tijdelijke flag en migreer opgeslagen data

Schrijf aannames op voordat ze je bijten

De meeste hacks rusten op verborgen aannames: kleine dataset, lage traffic, één gebruiker, vriendelijke inputs. Schrijf de aannames op (datagrootte, gebruikspatronen) in de ticketbeschrijving, een kort docje of zelfs een comment vlak bij de workaround.

Dit is geen bureaucratie—het is een trigger voor wanneer de code moet veranderen. Zodra een aanname niet meer klopt (bijv. “slechts 100 records”), heb je al gedocumenteerd waarom de shortcut kan falen.

Houd een lichtgewicht lijst met bekende issues bij

Beheer een kleine, zichtbare lijst van risico’s en ruwe randen zodat iedereen snel kan antwoorden:

• Wat kan breken bij groei?
• Wat is opzettelijk onvolledig?
• Wat heeft aandacht nodig voor we dit “v1” noemen?

Imperfect werk blijft veilig als het gelabeld, gevolgd en omringd is met duidelijke grenzen. Zo beweeg je snel zonder een mysteriueuze machine te bouwen.

Guardrails: waar je niet moet improviseren

Vibe coding werkt omdat je snel beweegt en snel leert. Maar sommige gebieden vergeven geen “we fix it later.” De truc is creatief blijven, maar een paar harde rails te zetten rond de onderdelen die onomkeerbare schade kunnen veroorzaken.

Kies je “non-negotiables”

Kies 1–2 categorieën waarin je niet improviseert:

• Security (auth, toegangscontrole, secrets, rate limits)
• Privacy (PII-verwerking, toestemming, retentie)
• Betalingen (idempotentie, retries, ontvangstbewijzen, basisfraudepreventie)
• Backups (herstel getest, niet alleen aangemaakt)

Je hoeft geen enterprise-compliance te hebben. Je hebt duidelijke lijnen nodig: raak je een non-negotiable aan, dan vertraag je, review je en documenteer je.

Test de pijnpunten, niet alles

Voeg basis-tests toe waar falen het meeste zou schaden. Dat betekent meestal:

• Login/signup en permissiechecks
• Code die geldgerelateerde records schrijft
• Datamigraties of bulkbewerkingen
• De “one-way doors” (deletes, e-mails, onomkeerbare statuswijzigingen)

Een handvol gerichte tests kan de bugs voorkomen die vertrouwen vernietigen.

Veiliger uitrollen: flags, fasen en rollbacks

Gebruik featureflags of gefaseerde uitrol waar mogelijk, vooral voor wijzigingen in billing, datamodellen of kernflows. Zelfs een simpele “alleen-intern” toggle geeft tijd om echt gedrag te observeren voordat iedereen ervan afhankelijk wordt.

Definieer een rollback-plan voor risicovolle veranderingen. Concreet: weet naar welke versie je teruggaat, welke data mogelijk geraakt wordt en hoe je herstel verifieert. Als rollback onmogelijk is, behandel de wijziging als hoog risico en voeg extra review toe.

Als je een lichtgewicht checklist wilt bewaren, link dan naar je eigen /release-notes of /runbook-pagina en houd die bij naarmate je leert.

Technische schuld zonder schuldgevoel

Technische schuld is geen schuldbekentenis dat je “het verkeerd hebt gedaan.” Het is de extra kosten die je accepteert wanneer je nu snelheid of eenvoud kiest, in de wetenschap dat je later opruimt. In vibe coding kan die afweging slim zijn—vooral als je nog leert wat het product moet worden.

Schuld is een hulpmiddel, geen karakterfout

Soms neem je schuld bewust: hardgecodeerde waarden, snel gekopieerde code, tests overslaan, tijdelijk datamodel. Het belangrijkste is eerlijk zijn over wat tijdelijk is en waarom. Schuld wordt een probleem zodra het je tempo gaat bepalen.

Signalen dat het te snel groeit

Let op deze praktische symptomen:

• Kleine veranderingen voelen ongewoon traag omdat je bang bent iets te breken
• Bugs herhalen zich in dezelfde gebieden (de code “lekt” steeds)
• Oplossingen veroorzaken elders nieuwe breuken
• Je mijdt bepaalde bestanden, routes of schermen

Als dat gebeurt, brengt je schuld rente in rekening.

Houd het bij met een kleine lijst

Maak geen megaproject van een herschrijving. Houd een korte “Schuldlijst” (5–15 items) die makkelijk te scannen is. Elk item bevat:

• Wat pijn doet (bijv. “Checkout-validatie is in 3 plaatsen gedupliceerd”)
• De impact (snelheid, betrouwbaarheid, klantpijn)
• Een kleine volgende stap (niet “betalingen herschrijven,” maar “centraliseer validatiefunctie”)

Dit verandert vage schuld in beheersbaar werk.

Stel een aflossingsritme in

Kies een standaardregel en houd je eraan. Een gebruikelijke is 20% van elke cyclus (of één dag per week) voor schuldaflossing: opruimwerk, tests rond risicogebieden, verwijderen van dode code, vereenvoudigen van verwarrende stromen. Als deadlines krap zijn, verklein de scope—maar behoud het ritme. Consistente onderhoud verslaat sporadische “schuldbrandjes” die nooit gebeuren.

Praktische workflow: lever klein, breid daarna uit

Vibe coding werkt wanneer je je eerste versie als een zet ziet, niet als een monument. Het doel is iets afleveren dat al bruikbaar is, en vervolgens echt gebruik laten bepalen wat je daarna bouwt.

1) Definieer de kleinste nuttige versie (je echte MVP)

Begin niet met “alle functies die we uiteindelijk willen.” Begin met één concrete taak die je code end-to-end moet uitvoeren.

Een goede MVP-definitie bevat meestal:

• Eén primaire gebruikersactie (bijv. “maak en sla een notitie op”)
• Eén succesmetric (“het slaat betrouwbaar op en laadt snel genoeg”)
• Eén beperking (“nog geen accounts”)

Als de MVP niet in één zin past, is het waarschijnlijk al v2.

2) Timebox experimenten zodat ze experiment blijven

Verkenning is waardevol totdat het stilletjes verandert in een meerweekse omweg. Zet er een klok op: uren of dagen, geen weken.

Voorbeelden:

• “Probeer twee benaderingen gedurende 3 uur, kies er één aan het eind van de dag.”
• “Prototypeer de UI in één middag, valideer met één vriend.”

Timeboxing dwingt beslissingen af. Het maakt het ook makkelijker een doodlopend pad weg te gooien zonder het gevoel te hebben een maand verspild te hebben.

3) Kies eenvoudige oplossingen die je later kunt vervangen

In het begin heeft de versie die het makkelijkst te begrijpen en te verwijderen is de voorkeur. Een basisimplementatie die je kunt vervangen is beter dan een slimme oplossing waar je aan vastzit.

Vraag: “Als dit kapot gaat, kan ik het in 10 minuten uitleggen en repareren?” Zo niet, dan is het misschien te ingewikkeld voor deze fase.

4) Maak scope-kortingen expliciet

Schrijf op wat je nog niet bouwt—letterlijk.

“Niet nu” items kunnen zijn: permissies, onboarding, analytics, mobiele afwerking, perfecte foutafhandeling. Scope-kortingen verminderen stress, voorkomen onbedoelde complexiteit en maken de volgende uitbreiding een bewuste keuze in plaats van een sluipende verplichting.

Waar platforms kunnen helpen (zonder de mindset te veranderen)

Als je een vibe-coding platform gebruikt zoals Koder.ai, kan het de build → ship → learn-lus verkorten: je kunt van een chatprompt naar een werkende webapp (React) of backend (Go + PostgreSQL) gaan en daarna itereren als feedback binnenkomt. Het belangrijkste is de snelheid te gebruiken om hypothesen te testen, niet om guardrails over te slaan—houd je non-negotiables (security, privacy, betalingen) expliciet, ook als tooling prototyping moeiteloos maakt.

Een hack omzetten in een onderhoudbare v1

Een hack wordt v1 wanneer je ophoudt het als een persoonlijk experiment te behandelen en het begint te zien als iets waar anderen van afhankelijk worden. Je hebt geen herschrijving nodig. Je hebt een paar doelgerichte verbeteringen nodig die het gedrag begrijpelijk, diagnoseerbaar en onderhoudbaar maken.

Een “Done for Now”-checklist

Voordat je het v1 noemt, doorloop een lichte checklist die duidelijkheid afdwingt zonder te vertragen:

• Kan iemand anders het draaien? Eén commando of een korte set stappen.
• Zijn de aannames opgeschreven? Inputs, omgevingen, credentials en “het werkt alleen als…”-beperkingen.
• Wat gebeurt er bij falen? Fouten moeten zichtbaar en actiegericht zijn.
• Is er een rollback of uit-knop? Zelfs een handmatige is beter dan niets.
• Is de scope bevroren voor deze versie? Nieuwe ideeën gaan op een lijst, niet in de release.

Documenteer de ruwe randen (met opzet)

Een onderhoudbare v1 doet niet alsof hij perfect is. Hij vertelt de waarheid.

Maak een korte “Bekende beperkingen”-notitie die antwoord geeft op:

• Wat breekt? Randgevallen, schaalgrenzen, browser-/apparaatproblemen.
• Wat ontbreekt? functies die gebruikers later verwachten.
• Wat is handmatig? Stappen die een mens nog moet doen (goedkeuringen, datafixes, geplande taken).

Houd het dicht bij de code of in een eenvoudig intern document en link het vanaf je README. Zo verander je “tribal knowledge” in iets bruikbaars voor je toekomstige zelf.

Voeg vroege, basale observability toe

Je hebt geen monitoring-programma nodig. Je hebt signalen nodig.

Begin met:

• Gestructureerde logs voor sleutelacties (wie/wat/wanneer), plus foutdetails.
• Fouttracking zodat crashes niet afhankelijk zijn van iemand die het meldt.
• Een paar tellers: aanmeldingen, succesvolle runs, mislukte runs, latency indien relevant.

Het doel is simpel: wanneer iemand meldt “het werkte niet”, vind je de oorzaak binnen minuten, niet uren.

Maak een eenvoudig supportpad

Als gebruikers geen issues kunnen melden, haken ze stilletjes af.

Kies één kanaal en maak het zichtbaar:

• Een kort feedbackformulier
• Een dedicated e-mailalias
• Een “Rapporteer een probleem”-link die een issue-template opent

Bepaal vervolgens wie triaget, hoe snel je reageert en wat “we fixen later” betekent. Dat is wanneer een hack ophoudt fragiel te zijn en een product wordt.

Refactoren onderweg (zonder eindeloze herschrijvingen)

Refactoren is hoe vibe coding snel blijft zonder te verworden tot een stapel fragiele shortcuts. De truc is het te zien als een reeks kleine, doelgerichte upgrades—geen dramatische “begin opnieuw”-actie.

Refactor na het leren, niet ervoor

Vroege code is vooral een vraag aan het product: Wordt deze workflow gebruikt? Welke randgevallen doen ertoe? Refactor nadat je geleerd hebt wat echt is. Als je te vroeg opschoont, poets je aannames weg die de werkelijkheid niet overleven.

Een goed signaal dat het tijd is: je hebt een dunne versie live, mensen gebruiken het en je past hetzelfde gebied steeds opnieuw aan.

Vervang de risicovolste hack eerst

Niet alle hacks zijn gelijk. Sommige zijn lelijk maar veilig; andere zijn tijdbommen.

Prioriteer wat zowel grote impact heeft als waarschijnlijk faalt:

• Alles wat data kan verliezen, geld verkeerd kan afhandelen of privégegevens kan lekken
• Een workaround die faalt zodra er een nieuwe optie of klanttype bijkomt
• Een handmatige stap die één persoon “onthoudt” om te doen

Het wegwerken van de risicovolste hack eerst geeft veiligheid en ademruimte.

Vermijd herschrijvingen gestuurd door smaak

Herschrijvingen lokken omdat ze schoon aanvoelen. Maar “ik vind deze code niet mooi” is geen bedrijfsdoel. Richt refactoren op resultaten: minder bugs, snellere changes, duidelijkere ownership, makkelijker testen, eenvoudiger onboarden.

Als je geen uitkomst kunt noemen, refactor je waarschijnlijk op stijl.

Gebruik dunne slices om te verbeteren zonder alles stuk te maken

In plaats van een heel systeem uit te rukken, verbeter één nauwe pad end-to-end.

Voorbeeld: houd de oude flow werkend, maar refactor alleen het “create invoice”-pad—voeg validatie toe, isoleer één dependency, schrijf een paar tests—en ga dan naar het volgende stukje. Na verloop van tijd wordt het verbeterde pad de standaard en zwakt de oude code vanzelf af.

Wanneer vertragen en opruimen

Vibe coding beloont beweging, maar momentum is niet hetzelfde als vooruitgang. Soms is de snelste manier om te leveren even pauzeren, risico verminderen en de volgende paar wijzigingen goedkoper maken.

Signalen dat je moet “pauzeren en repareren”

Als je een van deze ziet, ruil je niet langer afwerking voor snelheid maar betrouwbaarheid voor geluk:

• Herhaalde outages of terugkerende “dezelfde bug, een nieuwe dag” incidenten
• Securityzorgen (blootgestelde keys, slordige auth, niet-gecontroleerde permissies)
• Releases die blokkeren omdat de code te fragiel is om met vertrouwen te wijzigen
• Prestatieverslechteringen die klanten raken en blijven terugkomen
• Een groeiende stapel handmatige stappen die maar één persoon kent

“Stop en fix” vs “blijf bewegen”

Een bruikbare regel: stop en fix wanneer de huidige rommel de volgende verandering onvoorspelbaar maakt.

Stop-en-fix-momenten:

• Een bug kan dataverlies, privacyproblemen of foutieve facturatie veroorzaken
• Je kunt een wijziging niet testen zonder “het in productie proberen en kijken”
• Een snelle tweak vereist het aanpassen van vijf niet-gerelateerde bestanden en breekt elke keer

Blijf-bewegen-momenten:

• Het probleem is cosmetisch of treft een intern hulpmiddel met een duidelijke workaround
• Je hebt een tijdelijke hack die geïsoleerd en makkelijk te verwijderen is
• Het risico is begrepen, gedocumenteerd en tijdgebonden

Hoe je de afweging communiceert

Wees expliciet over kosten, risico en opbrengst. In plaats van “we moeten refactoren”, zeg:

• Wat er nu gebeurt (bv. “deploys falen twee keer per week omdat migraties inconsistent zijn”)
• De impact (verloren tijd, gebruikersschade, inkomstenrisico)
• De kleinste opruiming die de trend verandert (1–3 concrete taken)
• Wat je uitstelt door dit te doen (en waarom het de moeite waard is)

Sluit af met een eenvoudige mindset-samenvatting: leer snel, herstel vaak—lever het experiment en los daarna de onzekerheid op voordat die zich opstapelt.