Hoe je een met AI gebouwde app verder ontwikkelt zonder dat die breekt

Om een met AI gebouwde app verder te ontwikkelen zonder dat die breekt, verander je per prompt één ding, controleer je het in de preview en sla je een checkpoint op voordat je verdergaat. Beschrijf wat je ziet in plaats van wat je denkt dat de code doet, plan grote wijzigingen voordat je ze bouwt, en wanneer een wijziging misgaat, rol je terug naar de laatste goede versie in plaats van de AI zijn eigen fix te laten repareren.

De eerste versie van een app is vaak binnen minuten af. Het moeilijke deel is de vijftigste wijziging, wanneer elke nieuwe prompt het risico loopt iets te breken wat al werkte. Deze gids beschrijft de lus die dat voorkomt.

De iteratielus

1. Kies één wijziging. Eén functie, één bug, één pagina.
2. Beschrijf die in termen van wat de gebruiker ziet en doet.
3. Plan bij grote wijzigingen eerst. Vraag om een plan, lees het, en bouw dan.
4. Controleer het resultaat in de preview: de wijziging en de flows eromheen.
5. Sla op als checkpoint of commit.
6. Herhaal.

Elke stap bestaat om wijzigingen klein en omkeerbaar te houden.

Stap 1: Houd een korte lijst bij

Schrijf voordat je prompt, op wat je wilt veranderen, gesorteerd op belangrijkheid. Zo stuur je niet één alinea met tien wensen in één bericht, en heb je een manier om "nu niet" te zeggen tegen ideeën die halverwege opkomen.

Als een wijziging groot is, breek hem op. "Teamaccounts toevoegen" wordt: teams aanmaken, een lid uitnodigen, wisselen tussen teams, gegevens beperken tot het huidige team. Elk daarvan is een eigen prompt. Gebruikersverhalen schrijven is een goede manier om dit te doen.

Stap 2: Beschrijf wat je ziet

De AI ziet je scherm niet tenzij je het vertelt. Wijs naar specifieke dingen en zeg wat er moet gebeuren:

Op de prijspagina op een telefoon wordt de knop van de Pro-kaart afgesneden aan de rechterrand. Houd de desktopindeling hetzelfde; op schermen kleiner dan 640px komen de kaarten onder elkaar en worden de knoppen volledige breedte.

Vergelijk dat met "de prijspagina ziet er slecht uit op mobiel". Het eerste kan in één keer worden gedaan en gecontroleerd; het tweede nodigt uit tot een herontwerp dat je niet hebt gevraagd.

Screenshots helpen. Als je builder afbeeldingen accepteert, voeg er dan één toe en omcirkel het probleem.

Stap 3: Plan voor grote wijzigingen

Voor alles wat meerdere onderdelen van de app raakt — een nieuw datamodel, betalingen, gebruikersrollen — vraag je om een plan voordat er code verandert:

Verander nog geen code. Ik wil dat gebruikers bij teams horen en alleen de projecten van hun team zien. Plan de wijziging: welke tabellen, pagina's en API-routes veranderen, wat er met de bestaande gegevens van gebruikers gebeurt, en in welke volgorde je het zou bouwen.

Lees het plan. Als het fout is, is het corrigeren van een plan veel goedkoper dan het ongedaan maken van een build.

Stap 4: Zeg wat niet mag veranderen

AI-tools "ruimen" soms dingen op waar je niet naar vroeg. Bescherm wat werkt:

Voeg een datumfilter toe aan de bestellingentabel. Verander de kolommen, opmaak of de exportknop van de tabel niet.

Voor regels die overal gelden — merkkleuren, toon van communicatie, "verwijder nooit gegevens zonder bevestiging" — zet je ze in een notitiebestand van het project of een kenniswaarde die de AI elke keer leest, in plaats van ze steeds te herhalen.

Stap 5: Controleer meer dan alleen de wijziging

Test na elke prompt:

• De wijziging zelf. Doet het wat je vroeg, op desktop en telefoon?
• De buren. Dingen op dezelfde pagina, en flows die dezelfde gegevens gebruiken.
• Het kritieke pad. Aanmelden, inloggen, de belangrijkste actie, betaling. Een pas van dertig seconden na elke grote wijziging vangt het meeste breken vroeg op.

Als er iets niet klopt, meld het precies — zie hoe je een goed bugrapport schrijft.

Stap 6: Rol terug in plaats van stapelen

Wanneer een wijziging iets breekt en de eerste fix niet werkt, stop dan. Elke extra "fix" bouwt voort op een kapotte staat, en de problemen versterken elkaar.

Doe in plaats daarvan:

1. Rol terug naar de laatste versie die werkte (een checkpoint of Git-commit).
2. Bedenk wat er onduidelijk was aan de prompt.
3. Probeer het opnieuw met een kleinere of duidelijkere vraag.

Die wijziging brak het opslaan van concepten. Ik heb teruggerold. Dit keer: voeg alleen de autosave-indicator toe, als tekst in de header. Verander niet hoe concepten worden opgeslagen.

Stap 7: Weet wanneer opnieuw bouwen klopt

Opnieuw bouwen vanaf nul gooit veel werkende details weg. Het loont alleen wanneer:

• Het productidee volledig is veranderd.
• De onderliggende structuur niet kan dragen wat je nu nodig hebt — bijvoorbeeld omdat hij als statische site is gebouwd en nu accounts en een database nodig heeft.
• Het project nog bijna leeg is.

Als je opnieuw bouwt, maak dan een lijst van wat je wilt behouden: naam, kleuren, teksten, de onderdelen die gebruikers leuk vonden.

Voorbeeldprompts

Vat voordat we verdergaan samen hoe de app nu werkt: pagina's, de gegevens die hij opslaat, en alles wat volgens jou kwetsbaar is.

Ik wil terugkerende boekingen toevoegen. Wat is de kleinste versie die nuttig zou zijn? Stel die voor als drie aparte wijzigingen die we één voor één kunnen doen.

Controleer de laatste drie wijzigingen op alles wat de afrekenflow kan hebben gebroken. Nog niet bewerken.

Veelgemaakte fouten

• Tien verzoeken in één prompt. Sommige worden gedaan, sommige half, en je weet niet welke.
• Vage feedback. "Het is kapot" of "maak het beter" levert gissingen op.
• De buren nooit controleren. Een wijziging in een gedeeld onderdeel breekt drie andere pagina's.
• Fixes repareren. Vier prompts diep in een bug: rol terug.
• Elke keer context herhalen in plaats van vaste regels in projectnotities te bewaren.
• Opnieuw bouwen als je vastzit. De meeste "opnieuw beginnen"-momenten betekenen eigenlijk "twee stappen terugrollen".

Checklist

• Eén doel per prompt.
• Ik beschrijf wat ik zie en wat er moet gebeuren.
• Grote wijzigingen krijgen een plan voordat er code komt.
• Ik zeg wat niet mag veranderen.
• Na elke wijziging test ik die, de buren en het kritieke pad.
• Ik sla een checkpoint of commit op na elke wijziging die werkt.
• Als een fix mislukt, rol ik terug in plaats van fixes te stapelen.
• Vaste regels staan in projectnotities die de AI elke keer leest.

Itereren op Mythex

Mythex is rond deze lus gebouwd:

• Plan-, Build- en Ask-modi. Plan bespreekt de aanpak voordat er wordt bewerkt; Ask beantwoordt vragen zonder code te wijzigen; Build maakt de wijziging. Zie Chat.
• Checkpoints. Na elke geslaagde beurt slaat Mythex een git-checkpoint op; Terug naar dit punt rolt terug. Je kunt ook een eerder bericht bewerken en Negeren & opnieuw verzenden gebruiken om vanaf dat punt een andere prompt te proberen. Zie Itereren zonder opnieuw te bouwen.
• Kennis. Projectinstellingen → Kennis bevat vaste notities die de agent bij elk bericht volgt.
• /test laat de agent na een grote wijziging door de preview klikken zoals een gebruiker.

Kleinere vragen kosten ook minder credits. Voor het schrijven van de prompts zelf, zie hoe je prompts schrijft voor AI-appbouwers; wanneer er iets breekt, hoe je een met AI gebouwde app debugt.

Veelgestelde vragen