Waarom breekt mijn Lovable-app bij elke wijziging?

In het begin voelt het alsof je alles kunt. Je typt wat je wilt, het verschijnt, en het werkt. Ergens rond de twintigste of dertigste wijziging kantelt dat: je vraagt om een knop op het ene scherm en er gaat iets stuk op een scherm dat je die dag niet hebt geopend. Je vraagt om herstel, dat lukt, en dan is het eerste ding weer weg.

Dat patroon heet geen pech. Het is het voorspelbare gevolg van drie dingen die in vrijwel elk vibecode-project ontbreken.

1. Het model ziet je project niet in één keer

Een taalmodel heeft een beperkt venster waarin het je code kan bekijken. Zolang je app klein is, past alles erin en klopt elk antwoord. Groeit je project, dan past het niet meer, en dan kiest de tool een selectie bestanden die waarschijnlijk relevant zijn. Wat buiten die selectie valt, bestaat op dat moment niet. Een wijziging die logisch is binnen de vijf zichtbare bestanden kan de drie onzichtbare bestanden breken.

Dat is ook waarom het erger wordt naarmate je verder komt: hoe meer je bouwt, hoe kleiner het deel dat het model tegelijk kan overzien.

2. Dezelfde logica staat op vijf plekken

Vraag je om een prijsberekening op het offertescherm, dan komt die daar te staan. Vraag je er later één op het overzichtsscherm, dan komt er een tweede kopie. Niemand haalt de eerste weg, want niemand kijkt. Pas als je de btw wijzigt merk je dat er drie plekken zijn en dat je er twee hebt aangepast.

• Zoek in je project eens naar een bedrag of een percentage dat maar één keer zou moeten voorkomen.
• Vind je het meer dan één keer, dan weet je nu waarom cijfers soms niet met elkaar kloppen.
• Dit is ook de reden dat kleine wijzigingen steeds langer duren: elke wijziging is stiekem drie wijzigingen.

3. Er is niets dat je waarschuwt

In een normaal project draait er bij elke wijziging een setje tests dat controleert of de dingen die gisteren werkten vandaag nog werken. Dat is geen luxe voor grote teams; het is precies het vangnet dat jij mist. Zonder die tests is jouw enige controle handmatig klikken, en niemand klikt na elke prompt alle schermen na.

Je hoeft niet alles te testen. Tien tests op de plekken waar geld, gegevens of rechten omgaan vangen negentig procent van wat er stukgaat.

Wat je vandaag kunt doen

Zet je project in versiebeheer, als dat er nog niet is. De meeste tools kunnen naar GitHub exporteren of synchroniseren. Vanaf dat moment kun je zien wát er veranderde bij een prompt, in plaats van alleen dat er iets veranderde. Alleen dat al verandert de discussie met jezelf van 'waarom is het stuk' naar 'deze regel is stuk'.

Werk daarna in kleinere prompts en beschrijf per prompt welke bestanden hij mag aanraken. Het klinkt omslachtig en het is precies wat het aantal ongelukken omlaag brengt: je verkleint het gebied waarbinnen het model mag improviseren.

En als dat niet genoeg is

Er komt een punt waarop het opruimen zelf het werk is: de dubbele logica samenvoegen, de berekeningen naar één plek halen, en tests neerzetten op de plekken die pijn doen. Dat is de klus die ik vaak overneem, en het is meestal minder werk dan mensen vrezen, omdat de moeilijke vraag — wat moet het doen — al beantwoord is door het prototype dat je hebt gebouwd.