Prompts schrijven voor AI app builders (met voor- en na-voorbeelden)

Een goede prompt voor een AI app builder beschrijft het product, niet de code: wie het gebruikt, wat die stap voor stap doet, welke data het bewaart en wie wat mag zien. Nadat de eerste versie er is, vraag je om één specifieke wijziging per bericht, zeg je wat hetzelfde moet blijven, en beschrijf je problemen als „ik deed X, ik verwachtte Y, ik kreeg Z”. Met die drie gewoontes los je de meeste teleurstellende resultaten op.

De rest van deze gids laat de patronen in detail zien, met voor- en na-voorbeelden die je kunt aanpassen.

Waarom een app builder prompten anders is dan chatten met een AI

Als je een chatassistent een vraag stelt, krijg je bij een vage prompt een vaag antwoord en ga je door. Als je een AI app builder prompt, is het antwoord een werkend programma. Elk gat in je beschrijving wordt opgevuld met een gok, en die gokken worden code, databasetabellen en schermen waarmee je moet leven of die je moet terugdraaien.

Het doel van een prompt is dus niet slim klinken. Het is zorgen dat er minder belangrijke beslissingen aan het toeval worden overgelaten. Je hebt geen technische woordenschat nodig. Je moet specifiek zijn over de dingen die alleen jij weet: je gebruikers, je werkwijze en je regels.

Wat je in een eerste prompt zet

Beantwoord deze vragen voordat je iets schrijft. Elke vraag sluit een gat waar de AI anders op zou gokken.

Die laatste rij wordt onderschat. Zeggen wat je niet wilt, voorkomt dat de AI een blog, een prijzenpagina en een nieuwsbriefaanmelding toevoegt die je nooit hebt gevraagd.

Voor en na: de eerste prompt

Voor:

Maak een app voor mijn sportschool.

De builder moet alles raden: leden of personeel? Groepslessen of persoonlijke training? Betalingen? Je krijgt iets dat op een sportschoolwebsite lijkt en niets doet wat je nodig hebt.

Na:

Bouw een lesboekingsapp voor een kleine yogastudio. Leden zien de lessen van deze week (naam, docent, tijd, vrije plekken), boeken een plek en annuleren tot twee uur voor de les. Leden melden zich aan met e-mail en wachtwoord. De eigenaar van de studio logt in om lessen toe te voegen, te zien wie is geboekt en aanwezigheid te registreren. Bewaar lessen, leden en boekingen in een database. Rustig, licht ontwerp dat goed werkt op telefoons. Nog geen betalingen.

De tweede versie is nog steeds kort. Hij beantwoordt alleen de vragen uit de tabel hierboven.

Beschrijf gedrag, niet implementatie

Vaak krijg je betere resultaten als je beschrijft wat er moet gebeuren, in plaats van hoe je het moet bouwen.

Voor:

Voeg een useEffect toe die boekingen ophaalt en een modalcomponent voor het bewerken.

Na:

Wanneer de eigenaar op een boeking klikt, open dan een paneel waarin hij de tijd kan wijzigen of de boeking kan annuleren. Wijzigingen moeten meteen in de lijst zichtbaar zijn.

De eerste prompt legt de AI vast op een specifieke techniek die misschien niet past bij hoe de app is gebouwd. De tweede vertelt het resultaat en laat de AI de juiste aanpak kiezen voor de code die er al staat. Als je ontwikkelaar bent en je wel een sterke voorkeur hebt, zeg het dan, maar combineer het met het resultaat.

Wees concreet over de regels

Bedrijfsregels zijn waar door AI gebouwde apps het vaakst misgaan, omdat ze voor jou vanzelfsprekend zijn en voor de AI onzichtbaar. Schrijf ze uit.

• Limieten: „Een lid kan maximaal drie toekomstige boekingen hebben.”
• Timing: „Annuleringen sluiten twee uur voordat de les begint.”
• Randgevallen: „Als een les vol is, toon dan een wachtlijstknop in plaats van Boeken.”
• Rechten: „Docenten zien de aanwezigheid van hun eigen lessen, niet die van andere docenten.”

Elk hiervan is één zin. Als je er één weglaat, zal de app die regel niet afdwingen of zijn eigen versie ervan verzinnen.

Na de eerste versie: één wijziging per bericht

Zodra er iets in de preview draait, schakel je over van het beschrijven van het hele product naar het vragen om kleine, controleerbare wijzigingen.

Voor:

Het ontwerp klopt niet, het boeken werkt niet goed en ik wil een agendaweergave en e-mails.

Na (als vier aparte berichten):

1. Als ik de laatste plek in een les boek, staat er nog „1 plek vrij”. Dat moet „Vol” zijn en de Boeken-knop verbergen.
2. Voeg op de rooster-pagina een weekagenda toe, met één kolom per dag. Houd de huidige lijstweergave als optie.
3. Maak de leskaarten compacter op telefoons: kleinere marges, de naam van de docent op dezelfde regel als de tijd.
4. Stuur het lid een bevestigingsmail als het boekt.

Waarom dit werkt:

• Elke wijziging is klein genoeg om in één keer goed te gaan.
• Je kunt elke wijziging testen voordat je verdergaat.
• Als er één misgaat, kun je alleen die stap terugdraaien zonder de andere te verliezen.

Zeg wat je wilt behouden

Als je om een wijziging vraagt aan iets dat al werkt, zeg dan wat niet mag veranderen. Dit is de makkelijkste manier om regressies te voorkomen (dingen die eerder werkten en breken na een aanpassing).

Herontwerp de hero van de startpagina met een grotere kop en een foto rechts. Houd de navigatie, de kleuren en alles onder de hero precies zoals het is.

Hetzelfde geldt voor data: „Voeg een telefoonveld toe aan leden. Verwijder of hernoem geen bestaande velden.”

Gebruik schermafbeeldingen en exacte tekst

Woorden als „het ding bovenaan” zijn dubbelzinnig. De meeste AI app builders accepteren afbeeldingen, en een schermafbeelding met een korte notitie gaat sneller dan een alinea beschrijving.

• Voeg een schermafbeelding toe en zeg „de knop die rood omcirkeld is, overlapt het menu op telefoons”.
• Plak de exacte tekst van een foutmelding in plaats van hem te parafraseren.
• Citeer labels op het scherm letterlijk: „de knop Wijzigingen opslaan op de instellingenpagina”.

Gebruik voor bugs specifiek deze vorm:

Op de boekingenpagina klikte ik op Annuleren bij een boeking voor morgen. Ik verwachtte dat die uit mijn lijst zou verdwijnen. In plaats daarvan gebeurde er niets en staat de boeking er na verversen nog steeds. Repareer het en controleer of annuleren werkt.

Onze gids over hoe je een door AI gebouwde app debugt gaat hier dieper op in.

Eerst plannen bij grote wijzigingen

Voor alles wat veel delen van de app raakt — gebruikersaccounts toevoegen aan een app zonder accounts, betalingen toevoegen, veranderen hoe data is gestructureerd — vraag je om een plan voordat er code verandert.

Leg voordat je iets verandert uit hoe je teamaccounts zou toevoegen: welke nieuwe tabellen, welke pagina’s veranderen en wat er gebeurt met bestaande gebruikers. Wijzig nog geen code.

Lees het plan. Als het iets verkeerd begrijpt, is het corrigeren van een alinea veel goedkoper dan het corrigeren van een afgeronde functie. Veel builders hebben daarvoor een aparte modus; op Mythex is dat de modus Plan, naast Bouwen en Vragen.

Wat je moet vermijden

Over API-sleutels: als je een betaal- of e-mailservice nodig hebt, zet de sleutels dan in de geheimen van het project en niet in de prompt. Zie wat omgevingsvariabelen en geheimen zijn als dat nieuw voor je is.

Herbruikbare prompttemplates

Pas deze aan door de tussen haakjes staande delen te vervangen.

Nieuwe app:

Bouw een [type app] voor [wie]. Zij [belangrijkste flow, stap voor stap]. [Tweede type gebruiker] logt in om [wat ze doen]. Bewaar [data] in een database. [Uitstraling]. Laat [dingen voor later] weg.

Nieuwe functie:

Voeg [functie] toe aan de [pagina]. Wanneer [gebruiker] [actie] doet, moet [wat er moet gebeuren]. Alleen [wie] kan [dit doen]. Houd [bestaande dingen] zoals ze zijn.

Ontwerpwijziging:

Verander op de [pagina] [specifiek element] naar [specifieke wijziging]. Houd [wat je wilt behouden]. Controleer of het er goed uitziet op een schermbreedte van een telefoon.

Bug:

Op [pagina] heb ik [stappen] gedaan. Ik verwachtte [verwacht]. In plaats daarvan [werkelijk, plus de exacte foutmelding]. Repareer het en controleer of de flow werkt.

Vraag zonder wijzigingen:

Wijzig geen code. Leg uit hoe [deel van de app] werkt en waar [data] wordt opgeslagen.

Een langere specificatie schrijven

Voor grotere projecten kan het helpen eerst een briefing van één pagina te schrijven en die als openingsprompt te plakken: de gebruikers, de kernflows, de data, de regels en wat buiten scope valt. Je kunt zelfs een AI helpen die te concipiëren; onze gids over een productvereistendocument schrijven met AI laat zien hoe. Houd het eerste bouwverzoek wel bij de kernflow, en voeg de rest stap voor stap toe.

Prompten in Mythex

Alles hierboven werkt in Mythex. Een paar specifieke tips die helpen:

• Modi Bouwen, Plan en Vragen. Gebruik Plan voor grote of riskante wijzigingen en Vragen als je een uitleg wilt zonder bewerkingen.
• Checkpoints. Na elke geslaagde wijziging slaat Mythex een checkpoint op, en Terug naar dit punt bij een antwoord zet het project terug. Je kunt ook een eerder bericht bewerken en opnieuw versturen om vanaf dat punt een andere prompt te proberen.
• Geheimenkaart. Als de agent een API-sleutel nodig heeft, vraagt hij die via een kaart in de chat, zodat de waarde als projectgeheim wordt opgeslagen en niet in je bericht wordt geschreven.
• Afbeeldingen. Voeg schermafbeeldingen of mockups toe en de agent kijkt ernaar.

De documentatie heeft een korte pagina over effectieve prompts en een over itereren zonder opnieuw te bouwen. Begin je helemaal opnieuw, dan loopt hoe bouw je een app met AI een volledig project door, en laat hoe ontwerp je een goed ogende app met AI zien hoe je prompts voor visuele afwerking schrijft.

Veelgestelde vragen