Prompt Coaching

Categorie: Gidsen

Praktische gidsen per AI-model: Claude, GPT en Gemini, plus de tools eromheen. Elke gids geeft werkende voorbeeldprompts en vertelt eerlijk waar het model wel en niet goed in is.

  • Cursor uitleg: zo werk je met de AI-code-editor

    Deze Cursor uitleg is voor iedereen die wel eens hoort dat je “met AI kunt programmeren”, maar niet weet waar je moet beginnen. Cursor is een code-editor met een ingebouwde AI-assistent. Je beschrijft in gewone taal wat je wilt, en de editor schrijft, wijzigt of legt code voor je uit. Je hoeft geen ervaren developer te zijn om er iets mee te bouwen, maar je moet wel leren hoe je hem aanstuurt.

    Het korte antwoord: Cursor is een werkomgeving waarin jij de regie houdt en de AI het typewerk doet. Hoe duidelijker jouw opdracht, hoe bruikbaarder het resultaat. Daar zit de hele truc.

    Wat is Cursor precies?

    Cursor is een editor om software in te schrijven, vergelijkbaar met de bekende editor VS Code, maar met AI direct ingebouwd. In plaats van dat je elke regel zelf typt, kun je de assistent vragen om een functie te maken, een bug op te sporen of bestaande code aan te passen. De AI ziet je projectbestanden en kan over meerdere bestanden tegelijk meedenken.

    Belangrijk om te snappen: Cursor verzint niet zomaar een hele app uit het niets. Het werkt het best als jij het stap voor stap stuurt. Jij blijft de ontwerper; de AI is je snelle, soms eigenwijze assistent die je voorstellen geeft die je goedkeurt of afwijst.

    De eerste stappen in Cursor

    Je begint met het downloaden en installeren van Cursor, waarna je een nieuw of bestaand project opent. Vanaf daar werk je grofweg met drie manieren om de AI in te zetten:

    • Chat — je stelt een vraag of geeft een opdracht in een gesprek naast je code, handig om iets uit te leggen of een plan te maken.
    • Inline bewerken — je selecteert een stuk code en vraagt om een specifieke wijziging op die plek.
    • Voorstellen accepteren of afwijzen — Cursor laat zien wat het wil veranderen, en jij beslist of het zo blijft.

    Mijn advies: begin klein. Vraag eerst om één duidelijke wijziging, kijk wat eruit komt, test het, en ga pas dan verder. Grote vage opdrachten (“bouw een webshop”) leveren rommel op. Kleine, concrete stappen leveren iets werkends op.

    Waarom je prompt het verschil maakt

    De meeste frustratie met Cursor komt niet door de tool, maar door onduidelijke instructies. De AI raadt wat je bedoelt als je het zelf niet vertelt. Daarom werk ik met de KOMPAS-methode: een goede prompt is je kompas. Voor Cursor betekent dat concreet:

    • Kader — vertel wat voor project het is en welke taal of techniek je gebruikt.
    • Opdracht — zeg exact wat je wilt, in één heldere zin.
    • Materiaal — wijs naar de relevante bestanden of code.
    • Paalwerk — geef de grenzen: wat mag de AI niet aanraken?
    • Afwerking — vertel hoe het resultaat eruit moet zien.
    • Sturing — corrigeer en verfijn na het eerste resultaat.

    Wil je weten of jouw instructie sterk genoeg is? Plak hem in de gratis prompt-tool. Die geeft een score en herschrijft je prompt zodat Cursor minder hoeft te raden. Verder lezen over de aanpak kan via de gidsen.

    Past Cursor bij jou?

    Cursor is sterk als je iets wilt bouwen en al een idee hebt van hoe code werkt, of bereid bent dat al doende te leren. Wil je puur snel een prototype klikken zonder veel code te zien, dan zijn er andere gereedschappen die daar beter op gericht zijn. Een overzicht daarvan vind je in mijn artikel over vibe coding tools.

    Ben je nieuw met deze manier van werken? Begin dan bij de basis van vibe coding leren, zodat je snapt hoe je met AI samenwerkt voordat je in Cursor duikt. Daarna val je in Cursor veel minder vaak terug op trial-and-error.

    Iemand werkt aan een houten bureau in de Cursor AI code-editor op een laptop

    Wat kost Cursor?

    Je kunt gratis beginnen. Het Hobby-plan kost niets en is prima om te proeven: je krijgt een beperkt aantal AI-aanvragen en een korte proefperiode van de betaalde functies. Loop je tegen de limieten aan, dan is er een Pro-abonnement van zo’n 20 dollar per maand met ruimere limieten en sterkere modellen. Prijzen en limieten schuiven regelmatig; check de actuele bedragen op cursor.com voordat je beslist.

    Mijn advies: start gratis en upgrade pas als je de limieten echt raakt. Voor een avondje proberen is betalen zonde; bouw je er wekelijks mee, dan verdient Pro zichzelf snel terug in tijd.

    Waar Cursor tegenvalt

    Cursor heeft ook vervelende kanten. Drie dingen waar je tegenaan loopt:

    • De AI bouwt soms te veel. Vraag je om één knop, dan krijg je er soms een half nieuw menu bij. Daarom werkt Paalwerk uit de KOMPAS-methode zo goed: zeg expliciet wat er niet aangeraakt mag worden.
    • Grote projecten worden traag en duur. Hoe meer bestanden de AI moet meelezen, hoe trager het wordt en hoe sneller je door je limieten heen bent. Wijs dus gericht naar de bestanden die ertoe doen.
    • Je moet kunnen beoordelen wat eruit komt. Cursor levert overtuigend ogende code, ook als die niet klopt. Zonder testen merk je dat pas als iets stukgaat.

    Veelgestelde vragen

    Heb ik programmeerervaring nodig voor Cursor?

    Niet per se, maar het helpt enorm. Je hoeft niet vloeiend te kunnen coderen, maar je moet wel kunnen lezen wat de AI voorstelt en beslissen of het klopt. Hoe meer je begrijpt, hoe beter je stuurt.

    Schrijft Cursor een hele app voor me?

    Niet in één klik. Cursor werkt het best als jij het opdeelt in kleine stappen en elke stap controleert. Vage opdrachten leveren onbruikbare code op; concrete opdrachten leveren iets werkends op.

    Wat is het verschil tussen Cursor en gewoon ChatGPT?

    ChatGPT staat los van je project. Cursor zit in je code-editor, ziet je bestanden en kan wijzigingen direct op de juiste plek voorstellen. Dat scheelt veel knip- en plakwerk en fouten.

    Hoe voorkom ik dat de AI verkeerde dingen aanpast?

    Wees specifiek over wat wel en niet mag veranderen, en wijs naar de juiste bestanden. Test na elke stap. Een scherpe prompt voorkomt de meeste ongelukken.

    Is Cursor gratis?

    Er is een gratis Hobby-plan met beperkte AI-aanvragen, genoeg om te ontdekken of het bij je past. Wil je serieus bouwen, dan zit je al snel op het Pro-abonnement van ongeveer 20 dollar per maand. De actuele prijzen staan op cursor.com.

    Cursor of Claude Code: wat kies ik?

    Cursor is een visuele editor waarin je meekijkt en klikt; Claude Code werkt vanuit de terminal en is sterker in zelfstandig grotere klussen afwerken. Begin je net, dan is Cursor toegankelijker. Werk je liever helemaal zonder code, vergelijk dan Cursor met Lovable en Bolt.

    Wil je dat Cursor doet wat je bedoelt in plaats van wat je toevallig typte? Test je instructie gratis in de prompt-coach, of leer het in één sessie goed aan via mijn coaching — in een groep of privé.

    Verder lezen

    De beste tool hangt minder af van hype en meer van controle: kun je wijzigingen terugvinden, testen en herstellen als de AI te enthousiast bouwt? Lees daarna ook vergelijk Cursor, Lovable en Bolt of check je AI-code voor publicatie.

  • Lovable review: waar je het wel en niet voor gebruikt

    Kort antwoord vooraf: Lovable is sterk als je snel een werkend prototype of een eenvoudige web-app uit een beschrijving wil toveren, en zwak zodra je project complex, eigenzinnig of productierijp moet worden. Deze Lovable review gaat niet over hypes, maar over wat je er praktisch mee kunt — en waar je beter een andere route kiest.

    Belangrijker dan de tool zelf is hoe je hem aanstuurt. Vibe coding voelt als magie tot het misgaat, en dan blijkt: de tool deed precies wat je vroeg, alleen vroeg je het verkeerd. Daar zit de echte winst.

    Wat Lovable is en hoe het werkt

    Lovable is een AI-tool die op basis van een beschrijving in gewone taal een web-app voor je bouwt. Je typt wat je wil, de tool genereert de code en een werkende interface, en je stuurt bij door verder te praten. Geen lege editor, geen boilerplate — je begint meteen met iets dat draait.

    De aanpak is conversationeel: je beschrijft een wijziging, Lovable past de app aan, jij beoordeelt het resultaat. Dat maakt de drempel laag, ook als je weinig of geen programmeerervaring hebt. De keerzijde: hoe vager je vraag, hoe meer de tool zelf invult — en die aannames kloppen lang niet altijd met wat jij in je hoofd had.

    Waar Lovable echt goed in is

    Er zijn situaties waarin Lovable je uren werk bespaart. Een paar die er in de praktijk uitspringen:

    • Prototypes en concepten. Een idee snel zichtbaar maken om te testen of het hout snijdt, voordat je er serieus tijd in steekt.
    • Eenvoudige web-apps. Een formulier, een dashboard, een landingspagina met wat interactie — dat soort werk komt snel van de grond.
    • Leren door te doen. Je ziet meteen wat een instructie oplevert, wat het een prettige manier maakt om te begrijpen hoe apps in elkaar zitten.
    • Iteratief bijschaven. Kleine wijzigingen vragen en direct het effect zien werkt soepel, zolang je scope helder blijft.

    De rode draad: hoe duidelijker en begrensder je vraag, hoe beter het resultaat. Een scherpe omschrijving van wat je wil verslaat tien vage prompts achter elkaar.

    Waar je tegen grenzen aanloopt

    Geen enkele AI-builder is een wondermiddel, en eerlijk zijn hoort bij een goede review. Let op deze punten:

    • Complexe logica. Zodra je app veel onderlinge afhankelijkheden, randgevallen of fijne regels krijgt, gaan er dingen kapot die je daarvoor al werkend had.
    • Eigenzinnige eisen. Wijkt je idee sterk af van standaardpatronen, dan moet je veel sturen — en soms zelf in de code duiken.
    • Onderhoud op termijn. Code die je niet zelf hebt geschreven en niet begrijpt, wordt lastig te onderhouden. Zonder enig overzicht raak je het spoor bijster.
    • Productierijp maken. Beveiliging, schaalbaarheid en betrouwbaarheid vragen kennis die de tool niet voor je invult. Een werkend prototype is niet hetzelfde als iets dat je op duizenden gebruikers loslaat.

    Dit zijn geen redenen om Lovable links te laten liggen. Het zijn redenen om te weten wanneer je overstapt op een andere tool of een ontwikkelaar erbij haalt. Wil je de bredere afweging zien, lees dan de vergelijking in vibe coding tools.

    Eén grens die vaak pas na de lancering opvalt: de SEO-basis van gegenereerde sites. Titles, meta descriptions en interne links staan er zelden goed in. Doe daarom vóór je live gaat een SEO-check voor Lovable-output, dan weet je wat je nog moet rechtzetten.

    Hoe je met betere prompts meer uit Lovable haalt

    Het verschil tussen frustratie en flow zit zelden in de tool — het zit in je instructie. Een paar gewoontes die meteen helpen:

    • Geef context. Vertel voor wie de app is, wat het doel is en wat absoluut niet mag breken. De tool gokt minder als je meer kaders geeft.
    • Werk in stappen. Vraag één duidelijke wijziging per keer, niet vijf tegelijk. Zo zie je precies waar iets misgaat.
    • Beschrijf het gewenste resultaat, niet alleen het probleem. “Maak de knop rechtsboven, blauw, en koppel hem aan opslaan” werkt beter dan “verbeter de knop”.
    • Bewaak wat al werkt. Benoem expliciet wat overeind moet blijven, anders sloopt een nieuwe instructie zomaar iets ouds.

    Met mijn KOMPAS-methode breng je precies die onderdelen op orde: Kader, Opdracht, Materiaal, Paalwerk, Afwerking en Sturing. Een goede prompt is je kompas — zeker bij vibe coding, waar één onhandige zin een hele middag kan kosten. Wil je dit echt onder de knie krijgen, dan helpt vibe coding leren je verder dan trial-and-error. Of test je prompts direct in de gratis prompt-coach: die scoort je prompt en herschrijft hem voor je.

    Veelgestelde vragen

    Is Lovable geschikt voor beginners zonder programmeerkennis?

    Ja, voor eenvoudige projecten en prototypes is de drempel laag — je beschrijft wat je wil in gewone taal. Zodra je app complexer wordt, helpt enig technisch inzicht wel om de tool goed te sturen en problemen te herkennen.

    Kan ik met Lovable een echte, productierijpe app bouwen?

    Voor prototypes en kleine apps prima. Voor iets dat veel gebruikers, beveiliging en betrouwbaarheid aankan, heb je extra kennis nodig — of een ontwikkelaar die het werk afmaakt. Zie het als een sterke start, niet als het volledige eindproduct.

    Waarom doet Lovable niet wat ik vraag?

    Meestal omdat de vraag te vaag is of te veel ineens omvat. De tool vult dan zelf aannames in. Werk in kleine stappen, geef context en benoem wat niet mag veranderen. Daar wint je resultaat het meest mee.

    Hoe weet ik of Lovable de juiste tool is voor mijn project?

    Kijk naar complexiteit en hoe afwijkend je eisen zijn. Standaard en overzichtelijk: Lovable is een goede keuze. Eigenzinnig en complex: overweeg een andere tool of haal hulp erbij. De vergelijking in vibe coding tools helpt je kiezen.

    Wil je dat Lovable doet wat jij bedoelt in plaats van wat je toevallig typt? Test je prompt gratis in de prompt-coach, of boek coaching en leer in één sessie hoe je met de KOMPAS-methode grip krijgt op vibe coding.

    Verder lezen

    De beste tool hangt minder af van hype en meer van controle: kun je wijzigingen terugvinden, testen en herstellen als de AI te enthousiast bouwt? Lees daarna ook vergelijk Cursor, Lovable en Bolt of check je AI-code voor publicatie.

  • De nadelen van vibe coding (en hoe je ze voorkomt)

    De grootste nadelen van vibe coding zijn niet dat het niet werkt — het werkt juist verrassend goed. Het probleem zit in wat je níet ziet: code die je niet snapt, fouten die je niet kunt vinden, en beslissingen die het model voor je neemt zonder dat je het doorhebt. Je bouwt in een uur iets wat vroeger een week kostte, maar als het breekt sta je met lege handen.

    Dat betekent niet dat je het moet laten. Het betekent dat je moet weten waar de valkuilen zitten en hoe je ze omzeilt. Hieronder de echte nadelen, eerlijk en zonder doemdenken, plus wat je eraan doet.

    Je begrijpt je eigen code niet meer

    Dit is het kernprobleem. Bij vibe coding beschrijf je wat je wilt en de AI tovert code tevoorschijn. Werkt het? Top. Maar je hebt het niet zelf bedacht, dus je weet ook niet hoe het in elkaar steekt. Zodra je iets wilt aanpassen of er gaat iets mis, ben je afhankelijk van diezelfde AI om het uit te leggen.

    Het gevaar groeit met de tijd. Kleine onbegrepen stukjes stapelen op tot een project dat alleen het model nog overziet — en zelfs dat wordt onbetrouwbaar naarmate het groter wordt. Wil je eerst weten waar we het precies over hebben? Lees dan wat vibe coding is voordat je verder gaat.

    Wat je eraan doet: bouw in kleine stappen en vraag bij elke stap om uitleg. Niet alleen “maak dit”, maar “maak dit en leg uit hoe het werkt en waarom je deze keuze maakt”. Je houdt de regie als je begrijpt wat er gebeurt.

    Foutopsporing wordt een nachtmerrie

    Zolang alles werkt, voelt vibe coding als vliegen. Maar de eerste echte bug verandert dat. Je weet niet waar je moet zoeken, want je hebt de structuur niet zelf opgebouwd. En als je de fout terugkoppelt aan de AI, krijg je soms een oplossing die drie nieuwe problemen introduceert.

    Dit komt vaak doordat de AI te veel tegelijk doet en jij geen tussenstops inbouwt. Het model raadt, jij plakt, en niemand controleert. Een paar dingen die helpen:

    • Test na elke verandering, niet pas aan het eind.
    • Geef bij een bug de exacte foutmelding mee, niet “het werkt niet”.
    • Vraag de AI om eerst de oorzaak te benoemen voordat ze iets aanpast.
    • Houd één probleem per prompt aan — niet vijf tegelijk.

    Hoe scherper je je opdracht formuleert, hoe minder rommel je terugkrijgt. Daar draait betere prompts schrijven om.

    Beveiliging en kwaliteit glippen erdoorheen

    Een AI bouwt wat je vraagt, niet wat veilig is. Vraag je om een inlogformulier, dan krijg je een inlogformulier — maar of wachtwoorden goed worden opgeslagen, of er gaten in zitten, of gevoelige data lekt, dat checkt het model niet uit zichzelf. Voor een hobbyprojectje maakt dat weinig uit. Zodra echte gebruikers of echte data in het spel komen, wel.

    Hetzelfde geldt voor kwaliteit. Gegenereerde code kan werken en tegelijk slordig, traag of onhoudbaar zijn. Je merkt het niet meteen, want het draait. Tot het project groeit en alles gaat schuren.

    Wat je eraan doet: behandel AI-code als code van een stagiair. Het kan prima zijn, maar je controleert het. Vraag expliciet om beveiligingschecks, vraag of er betere aanpakken zijn, en laat de AI haar eigen werk kritisch nalopen. Wil je dieper in de werkwijze duiken, kijk dan bij de uitleg over vibe coding zelf.

    Je leert er weinig van — als je niet oplet

    Het verleidelijke aan vibe coding is dat je niets hoeft te snappen. Het vervelende is precies hetzelfde. Als je puur kopieert en plakt, word je niet beter. Je blijft afhankelijk van het model en loopt vast zodra het je in de steek laat.

    De oplossing is niet om minder AI te gebruiken, maar om bewuster te prompten. Vraag om uitleg. Vraag om alternatieven. Laat de AI je niet alleen het antwoord geven, maar ook waaróm. Dan bouw je niet alleen een product, maar ook je eigen kennis op. Dat is precies het verschil dat een goede prompt maakt — en waar de gratis prompt-tool je bij helpt: hij scoort je prompt en laat zien wat scherper kan.

    Veelgestelde vragen

    Is vibe coding gevaarlijk?

    Niet in zichzelf. Het wordt riskant als je code naar een echte omgeving brengt zonder te controleren op beveiliging en kwaliteit. Voor experimenteren en prototypes is het prima. Voor iets met echte gebruikers of data: altijd nalopen of laten nalopen.

    Moet ik dan toch leren programmeren?

    Het helpt enorm, maar het hoeft niet meteen diep. Basisbegrip van hoe code is opgebouwd maakt je een stuk minder afhankelijk en helpt je fouten sneller herkennen. Zelfs een beetje kennis maakt het verschil tussen blind plakken en sturen.

    Hoe voorkom ik dat de AI rommel maakt?

    Werk in kleine stappen, test tussendoor en geef heldere, specifieke opdrachten. Vraag om uitleg en alternatieven in plaats van alleen een antwoord. Hoe beter je prompt, hoe beter het resultaat — daar valt het meeste te winnen.

    Voor wie is vibe coding wél geschikt?

    Voor iedereen die snel een idee wil testen, een prototype wil bouwen of iets persoonlijks wil maken. Het wordt pas spannend bij serieuze, schaalbare projecten — dan zijn controle en begrip onmisbaar.

    Wil je vibe coding gebruiken zonder erin te verdrinken? Het begint bij betere prompts. Test je eigen prompt gratis met de prompt-coach, of werk er samen aan tijdens coaching. Meer leren over slim prompten en bouwen? Snuffel rond in de gidsen.

    Verder lezen

    Vibe coding werkt pas goed als de scope klein genoeg is. Een werkende demo is geen eindpunt; de check zit in testen, uitleggen en veilig publiceren. Lees daarna ook start met vibe coding leren of kies daarna je tool.

  • Vibe coding voor beginners: je eerste project in 5 stappen

    Vibe coding voor beginners betekent: je beschrijft in gewone taal wat je wil bouwen, en een AI-tool zet dat om in werkende code. Je hoeft geen programmeertaal te kennen. Je hoeft wél te weten hoe je je idee scherp opschrijft. Dat laatste is waar de meeste mensen vastlopen — niet op de techniek, maar op de prompt.

    In dit artikel bouw je je eerste project in vijf stappen. Geen theorie over compilers of frameworks. Gewoon: van een leeg scherm naar iets dat draait. En vooral: wat je tegen de tool zegt zodat je niet na tien minuten in een berg foutmeldingen zit.

    Wat vibe coding eigenlijk is

    Bij vibe coding praat je tegen een AI-tool zoals je tegen een handige collega zou praten. Je typt “maak een pagina waar mensen zich kunnen inschrijven voor mijn nieuwsbrief” en de tool genereert de code, laat een voorbeeld zien en past het aan als je vraagt om iets anders. Tools als Cursor, Lovable en Bolt zijn gemaakt om dit soort werk te ondersteunen — je beschrijft, zij bouwen.

    Het verschil tussen frustratie en een werkend project zit bijna altijd in hoe je het vraagt. “Maak een app” is te vaag. De tool gokt dan, bouwt iets willekeurigs, en jij bent je richting kwijt. Wil je dieper begrijpen hoe de denkwijze werkt, lees dan ook vibe coding leren. Hier houden we het bij doen.

    De 5 stappen voor je eerste project

    Stap 1 — Kies één klein ding

    Begin niet met “een webshop” of “een planningsapp voor mijn hele team”. Kies iets dat in één zin past: een persoonlijke landingspagina, een eenvoudige to-do-lijst, een rekenmachine die jouw specifieke berekening doet. Eén scherm, één functie. Klein winnen geeft je het gevoel hoe de tool reageert, zonder dat je verdrinkt.

    Stap 2 — Beschrijf het project voordat je iets bouwt

    Schrijf eerst in een paar zinnen op wat je maakt, voor wie, en wat de bezoeker moet kunnen doen. Dit is je kader. Geef je tool die context in je allereerste bericht. Bijvoorbeeld: “Ik bouw een eenvoudige landingspagina voor mijn fotografiebedrijf. Bezoekers moeten mijn werk zien en contact kunnen opnemen. Houd het strak en rustig.” Nu heeft de tool een richting.

    Stap 3 — Bouw in kleine stukjes

    Vraag niet alles in één keer. Eerst de basisstructuur. Dan de tekst. Dan een contactformulier. Dan de kleuren. Per stap controleer je of het klopt voordat je verder gaat. Dit voorkomt dat een fout zich opstapelt en je niet meer weet waar het misging.

    • Eén verzoek per bericht, niet vijf tegelijk
    • Test na elke wijziging of het nog werkt
    • Werkt iets? Zeg dat ook, dan houdt de tool het zo

    Stap 4 — Geef gerichte feedback bij fouten

    Er gaat iets stuk. Dat is normaal. Kopieer de foutmelding letterlijk terug naar de tool en zeg wat je verwachtte. “Ik krijg deze foutmelding wanneer ik op de knop klik: [tekst]. De knop zou een e-mail moeten openen.” Hoe concreter je beschrijft wat er misgaat, hoe sneller de tool het oplost.

    Stap 5 — Bekijk, publiceer, herhaal

    Klopt het en doet het wat je wil? Dan kun je het online zetten — de meeste vibe coding-tools hebben daar een knop voor. Daarna pas je rustig aan en bouw je uit. Je eerste project hoeft niet af te zijn. Het hoeft te wérken.

    Waar beginners op vastlopen

    De grootste valkuil is te grote stappen nemen. Je vraagt om tien dingen tegelijk, er gaat iets mis, en je weet niet meer welk deel. Werk klein. De tweede valkuil is vage prompts: “maak het mooier” geeft de tool niets om mee te werken. Zeg in plaats daarvan “maak de koppen groter en gebruik meer witruimte tussen de blokken”.

    De derde valkuil is opgeven bij de eerste foutmelding. Foutmeldingen horen erbij, ook bij ervaren bouwers. Het verschil is dat zij de fout teruggeven aan de tool met context. Mijn gidsen gaan dieper in op dit soort patronen, en wil je weten welke tool bij jou past, kijk dan bij vibe coding tools.

    Betere prompts, sneller resultaat

    Alles in dit stappenplan komt samen in één vaardigheid: helder formuleren wat je wil. Daar bouwde ik mijn KOMPAS-methode voor — Kader, Opdracht, Materiaal, Paalwerk, Afwerking, Sturing. Geef je tool het kader (wat bouw je, voor wie), een scherpe opdracht (wat moet er nu gebeuren), het materiaal (je tekst, je voorbeelden), en stuur bij waar nodig. Een goede prompt is je kompas: hij geeft richting voordat je begint te lopen.

    Twijfel je of je prompt scherp genoeg is? Plak hem in de gratis prompt-coach. Die scoort je prompt en herschrijft hem, zodat je tool meteen snapt wat je bedoelt.

    Veelgestelde vragen

    Heb ik programmeerkennis nodig voor vibe coding?

    Nee. Je beschrijft in gewone taal wat je wil en de AI-tool schrijft de code. Wel helpt het enorm als je leert je idee helder en stap voor stap te formuleren — dat is de kern van vibe coding voor beginners.

    Welk project kies ik als eerste?

    Iets kleins dat in één zin past: een landingspagina, een to-do-lijst of een simpele rekentool. Eén scherm, één functie. Zo voel je hoe de tool werkt zonder dat het onoverzichtelijk wordt.

    Wat doe ik als ik een foutmelding krijg?

    Kopieer de foutmelding letterlijk terug naar de tool en zeg wat je verwachtte dat er zou gebeuren. Hoe concreter, hoe sneller het wordt opgelost. Foutmeldingen horen erbij, ook bij ervaren bouwers.

    Waarom geeft mijn tool steeds iets anders dan ik bedoel?

    Meestal omdat de prompt te vaag is of te veel tegelijk vraagt. Geef context, vraag één ding per keer en wees specifiek over wat je wil. De prompt-coach helpt je dat aanscherpen.

    Klaar om te beginnen? Test eerst je eerste prompt in de gratis prompt-coach. Wil je sneller leren met directe feedback op je eigen projecten, kijk dan naar de coaching — in groep of privé.

    Verder lezen

    Vibe coding werkt pas goed als de scope klein genoeg is. Een werkende demo is geen eindpunt; de check zit in testen, uitleggen en veilig publiceren. Lees daarna ook start met vibe coding leren of kies daarna je tool.

  • App bouwen zonder code met AI: zo begin je

    Een app bouwen zonder code met AI kan echt — je beschrijft in gewone taal wat je wilt, en een AI-tool zet dat om in een werkende applicatie. Geen jaren leren programmeren, geen dure ontwikkelaar. Maar er zit een addertje onder het gras: het resultaat is precies zo goed als jouw instructies. Wie vaag prompt, krijgt een wankel prototype. Wie scherp prompt, krijgt iets bruikbaars.

    In dit artikel lees je waar je begint, welke soort tools er zijn, en — het belangrijkste — hoe je ze aanstuurt zodat je niet na een uur vastloopt.

    Wat betekent “app bouwen zonder code” eigenlijk?

    Je typt wat je voor ogen hebt, de AI genereert de code, de interface en vaak ook de database eronder. Jij stuurt bij in gewone taal: “maak de knop groen”, “voeg een inlogscherm toe”, “die lijst moet alfabetisch”. Dit heet ook wel vibe coding: je bouwt op gevoel en richting, niet op syntax.

    Belangrijk om te weten: zonder code wil niet zeggen zonder denkwerk. Je hoeft geen programmeertaal te kennen, maar je moet wél helder krijgen wát je wilt, voor wie, en hoe het zich moet gedragen. Dat helder krijgen en goed overbrengen is een vaardigheid op zich. Wil je dieper begrijpen hoe dit werkt, lees dan eerst wat vibe coding is voordat je een tool opent.

    Welke soort tools zijn er?

    Grofweg twee smaken, en het verschil bepaalt waar je begint.

    AI-bouwers die voor je coderen

    Tools als Cursor, Lovable en Bolt nemen je beschrijving en bouwen er een echte applicatie van. Je praat in chat, zij produceren code en een live voorbeeld. Lovable en Bolt zijn gericht op snel een werkende web-app neerzetten in je browser. Cursor is een code-editor met AI ingebouwd: krachtiger en flexibeler, maar je ziet wel echte codebestanden — handig als je een stap verder wilt, even wennen als je dat liever niet ziet.

    Klassieke no-code platforms

    Daarnaast bestaan er visuele bouwers waar je blokken sleept in plaats van prompt. Die geven meer controle over de vormgeving, maar je bent gebonden aan wat het platform aanbiedt. De AI-bouwers zijn vrijer, omdat ze echte code genereren.

    Mijn advies om te starten: kies een AI-bouwer die in je browser draait, zodat je meteen een resultaat ziet zonder iets te installeren. Begin klein. Eén scherm, één functie. Pas uitbreiden als dat werkt.

    Zo begin je: vier stappen

    Niet meteen typen “bouw een app voor mij”. Doe dit:

    • Beschrijf het doel in één zin. Wat moet de gebruiker kunnen na het gebruik? Bijvoorbeeld: een gast kan zich aanmelden voor mijn workshop en krijgt een bevestiging.
    • Som de schermen op. Welke pagina’s of stappen zijn er? Aanmeldformulier, overzichtspagina, bedankscherm. Houd het minimaal.
    • Geef context mee. Voor wie is het, welke stijl, welke data wordt opgeslagen. Hoe meer de AI weet, hoe minder hij gokt.
    • Bouw in kleine rondes. Vraag één ding tegelijk. Test. Pas dan de volgende toevoeging. Een grote prompt vol eisen geeft een grote brij aan fouten.

    Loopt iets niet zoals bedoeld? Zeg precies wat je ziet én wat je verwacht: “de knop doet niets als ik klik — hij moet het formulier verzenden.” Vaag klagen helpt de AI niet; concreet beschrijven wel.

    De prompt is je kompas

    Hier valt of staat alles. Dezelfde tool geeft de één een nette app en de ander een chaos — het verschil zit in de prompts. Daarom werk ik met de KOMPAS-methode: een goede prompt is je kompas. Je geeft Kader (wat bouw je en voor wie), de Opdracht (wat moet de AI nu doen), Materiaal (voorbeelden, data, stijl), Paalwerk (de structuur en grenzen), Afwerking (toon en vorm) en Sturing (bijsturen op wat je terugkrijgt).

    Dat klinkt als veel, maar in de praktijk scheelt het je uren foutzoeken. Wil je zien hoe sterk je huidige prompts zijn? Plak ze in de gratis prompt-tool — die scoort je prompt en herschrijft hem direct. Een goed startpunt voordat je je app gaat bouwen.

    Waar het meestal misgaat

    De drie valkuilen die ik het vaakst zie bij beginners:

    • Te veel in één keer vragen. Tien eisen in één prompt levert tien half-werkende dingen op. Bouw in lagen.
    • Niet testen tussendoor. Als je pas na twintig wijzigingen kijkt, weet je niet meer wélke wijziging iets brak.
    • Aannemen dat de AI je gedachten leest. Hij weet niet dat je bedoelt “voor een Nederlandse bakkerij met online bestellen” als je alleen “een bestel-app” typt.

    Wie deze drie vermijdt, komt al een heel eind. Het echte leren zit in het oefenen met je eigen idee. Verder komen met de techniek zelf? Dan helpt het om vibe coding stap voor stap te leren, zodat je niet bij elke hobbel vastloopt.

    Veelgestelde vragen

    Heb ik echt geen programmeerkennis nodig?

    Voor een eenvoudige app niet. Je beschrijft in gewone taal wat je wilt en de AI bouwt het. Wel helpt het enorm als je leert duidelijk en gestructureerd prompten — dat bepaalt de kwaliteit van het resultaat meer dan technische kennis.

    Welke tool kan ik het beste als beginner gebruiken?

    Begin met een AI-bouwer die in je browser draait, zodat je direct resultaat ziet zonder installatie. Lovable en Bolt zijn toegankelijk voor een snelle web-app; Cursor is krachtiger als je een stap verder wilt. Kies er één en blijf erbij tijdens je eerste project.

    Wordt mijn app meteen professioneel?

    Reken op een werkend prototype, geen kant-en-klaar eindproduct. Voor iets dat je echt aan klanten geeft, is bijschaven nodig: foutafhandeling, beveiliging, vormgeving. AI brengt je snel ver, maar de laatste tien procent vraagt aandacht.

    Hoe voorkom ik dat ik vastloop?

    Bouw in kleine stappen, test na elke wijziging, en beschrijf problemen concreet (“knop doet niets bij klik” in plaats van “het werkt niet”). En zorg dat je prompts scherp zijn — daar begint het.

    Klaar om te starten? Test eerst je prompt in de gratis prompt-coach en bouw daarna je eerste scherm. Wil je het sneller onder de knie krijgen, met iemand die meekijkt? Bekijk de coaching — in groep of privé leer je precies prompten zodat je app in één keer goed staat.

    Verder lezen

    Vibe coding werkt pas goed als de scope klein genoeg is. Een werkende demo is geen eindpunt; de check zit in testen, uitleggen en veilig publiceren. Lees daarna ook start met vibe coding leren of kies daarna je tool.

  • AI-site controleren voor publicatie: 12 checks tegen frontend slop

    Een AI-site is niet klaar omdat de knop werkt. Hij is klaar als een bezoeker op mobiel begrijpt wat hij moet doen, foutmeldingen niet vreemd voelen, lange Nederlandse tekst past en de pagina nog steeds vertrouwen wekt zonder demo-content.

    Gebruik deze checklist voordat je een site uit Cursor, Lovable, Bolt, Claude Code of Codex live zet. Niet als designexamen, maar als publicatiegate: wat moet je zelf gezien hebben voordat Google en echte bezoekers de pagina zien?

    De snelle diagnose: werkt het scherm alleen in de demo?

    AI-gebouwde interfaces falen zelden op één grote fout. Het zit vaker in kleine signalen: een modal die net te hard inspringt, een button met twee regels tekst, een mobile breakpoint waar de hero over de CTA valt, of een formulier dat technisch submit maar geen geruststelling geeft.

    Dat is precies waarom “maak het mooier” geen goede prompt is. Een model vult smaakwoorden met gemiddelde patronen: veel cards, paarse glows, te ronde knoppen, vage hero-copy en componenten die afzonderlijk best oké lijken. Je moet de output niet mooier vragen. Je moet hem langs concrete constraints leggen.

    12 checks voordat je publiceert

    1. Eerste scherm: staat binnen vijf seconden duidelijk wat de bezoeker hier kan doen?
    2. Mobiel: test minimaal 390px breed. Geen overlappende hero, menu, CTA of formulierlabels.
    3. Lange Nederlandse tekst: vervang demo-copy door echte zinnen. Vooral buttons, tabs en cards breken dan snel.
    4. Contrast: check tekst op beeld, disabled buttons, badges en lichte grijze bodytekst.
    5. Formulieren: test leeg, fout ingevuld, geldig ingevuld en na submit. Een formulier zonder goede foutstaat is niet klaar.
    6. Loading states: laat niet alleen een spinner zien. Zeg wat er gebeurt en voorkom dubbele submits.
    7. Error states: schrijf menselijke foutmeldingen. Geen technische stack of lege rode box.
    8. Empty states: een leeg dashboard, lege lijst of geen resultaten-pagina moet nog steeds een volgende stap geven.
    9. Modals en drawers: test openen, sluiten, Escape, scrollen en focus. Janky motion voelt goedkoop.
    10. Consistente spacing: gebruik een vaste spacing- en radius-schaal. AI maakt anders elk blok lokaal “mooi”.
    11. Beeldtaal: geen plastic AI-stock, vage glow-achtergronden of nep-screenshots als de gebruiker iets moet beoordelen.
    12. SEO-copy: haal intro’s weg die alleen het onderwerp aankondigen. De pagina moet direct helpen.

    Wat je beter prompt dan “maak dit professioneel”

    Geef de agent regels die je kunt controleren. Bijvoorbeeld:

    Gebruik een rustige redactionele layout.
Geen cards tenzij items echt naast elkaar vergeleken worden.
Geen gradient-orbs of paarse glow-achtergronden.
Buttontekst mag op mobiel niet afbreken.
Maak states voor loading, empty, error en success.
Test lange Nederlandse labels en 390px mobile viewport.
Leg na afloop uit welke visuele risico's nog handmatig gecontroleerd moeten worden.

    Dit soort instructies werkt beter omdat je niet om smaak vraagt, maar om gedrag. De agent kan nog steeds fouten maken, maar jij hebt daarna een checklist om tegen te verifiëren.

    Wanneer je niet verder moet prompten

    Stop met prompten als de pagina bij elke verbetering elders uit elkaar valt. Dat is meestal geen “nog één prompt”-probleem, maar een systeemprobleem: geen vaste typografie, geen componentregels, geen ontwerpbeslissing over dichtheid, geen mobiele hiërarchie.

    Dan is de snelste route vaak handmatig: eerst één scherm goed maken, daaruit componentregels halen, daarna pas de agent verder laten bouwen. Anders train je jezelf om AI-output te poetsen in plaats van een interface te ontwerpen.

    Publicatiegate voor AI-sites

    Publiceer pas als je deze vier dingen kunt laten zien:

    • desktop- en mobiele screenshots van de belangrijkste flow;
    • minimaal één echte foutstaat en één lege staat;
    • een korte lijst met handmatige correcties die je na AI-output hebt gedaan;
    • een duidelijke canonical: welke pagina ownet deze taak, en welke pagina’s linken ernaartoe?

    De beste AI-site voelt niet alsof de agent zijn best heeft gedaan. Hij voelt alsof iemand met smaak en context de laatste beslissing heeft genomen.

    Bronnen en verdere context

    Wil je eerst beter leren prompten voordat je een AI-site laat bouwen? Begin dan met vibe coding, vergelijk Cursor, Lovable en Bolt, en test je output daarna met de checklist hierboven.

    Verder lezen

    Werk per use-case. Een beeldprompt, tekstprompt en codeprompt vragen elk om andere controlepunten; bundel ze niet in één generieke opdracht. Lees daarna ook bekijk de AI-prompt hub of gebruik de Prompt Coach.

  • Cursor vs Lovable vs Bolt: welke vibe coding tool past bij jou?

    De korte versie: Cursor vs Lovable vs Bolt is geen wedstrijd om de “beste” tool, maar een keuze die afhangt van wat je bouwt en hoeveel je zelf wilt sturen. Wil je code schrijven met AI naast je? Dan kom je bij Cursor uit. Wil je vanaf een prompt een werkende app in de browser zien verschijnen, zonder editor? Dan zitten Lovable en Bolt dichter bij wat je zoekt.

    In dit artikel zet ik de drie naast elkaar op de punten die er echt toe doen voor vibe coding: hoeveel controle je hebt, hoe steil de leercurve is, en voor wie elke tool logisch is. Geen feature-lijstjes die volgende maand verouderd zijn — wel een kader om zelf te kiezen.

    Wat is vibe coding eigenlijk?

    Vibe coding betekent dat je beschrijft wat je wilt, en de AI bouwt het. Je stuurt op gevoel, intentie en resultaat in plaats van regel voor regel code te tikken. Dat klinkt magisch, maar het valt of staat met hoe goed je je wens kunt formuleren. Een vage prompt levert een vage app op. Een scherpe prompt levert iets bruikbaars.

    Daarom is de tool maar de helft van het verhaal. De andere helft ben jij: hoe duidelijk je kunt zeggen wat je wilt, en hoe je bijstuurt als het resultaat afwijkt. Wil je daar beter in worden, lees dan eerst hoe je vibe coding leert — dat scheelt je veel frustratie ongeacht welke tool je kiest.

    Cursor: voor wie de code wil zien

    Cursor is een code-editor met AI ingebouwd. Je werkt in een echte ontwikkelomgeving, met bestanden, een terminal en versiebeheer, maar de AI helpt je schrijven, aanpassen en debuggen. Je kunt hele functies laten genereren of gericht een stuk code laten herschrijven.

    Cursor past bij je als:

    • je al wat programmeert of dat wilt leren, en de code niet als zwarte doos wilt behandelen
    • je een bestaand project hebt waar je in wilt blijven werken
    • je volledige controle wilt over de structuur en niet vastzit aan één manier van bouwen

    De keerzijde: je moet je iets meer thuis voelen in een editor. Voor iemand die nog nooit een regel code heeft gezien, is de drempel hoger dan bij een browser-tool. Maar precies omdat je de code ziet, leer je sneller begrijpen wat er gebeurt.

    Lovable en Bolt: van prompt naar werkende app

    Lovable en Bolt zitten in dezelfde hoek: je typt wat je wilt bouwen, en je krijgt een werkende app of website terug die je meteen in de browser ziet draaien. Je hoeft geen ontwikkelomgeving op te zetten en geen code te begrijpen om te starten. Je beschrijft, je kijkt, je stuurt bij met een volgende prompt.

    Dat maakt ze geschikt voor:

    • een idee snel uittesten of een prototype laten zien
    • een landingspagina of simpele app bouwen zonder developer in te huren
    • leren door te doen, zonder eerst een editor onder de knie te krijgen

    Het verschil tussen de twee zit vooral in nuance en werkstijl, en dat verschuift met elke update — dus laat je niet gek maken door losse feature-vergelijkingen. Probeer ze allebei kort met hetzelfde idee en kijk welke jou prettiger laat sturen. De ene voelt voor de een logischer dan voor de ander.

    De gemene deler: hoe meer je app groeit, hoe meer je tegen de grenzen aanloopt. Voor kleine, scherp afgebakende dingen zijn ze snel en fijn. Voor iets groots en complex wil je vaak alsnog ergens code kunnen aanraken — en dan kom je weer in de buurt van een tool als Cursor.

    Zo kies je: drie vragen

    Vergeet de hype en stel jezelf deze drie vragen:

    • Wil je de code zien of niet? Ja: Cursor. Nee, ik wil het resultaat: Lovable of Bolt.
    • Bouw je iets nieuws of werk je in iets bestaands? Nieuw prototype: een browser-tool is sneller. Bestaand project: Cursor.
    • Hoeveel wil je leren onderweg? Wil je echt begrijpen hoe het werkt, dan helpt code zien. Wil je vooral snel iets werkends, dan niet.

    En het belangrijkste: welke tool je ook pakt, je resultaat hangt af van je prompt. Dezelfde opdracht levert in alle drie iets totaal anders op afhankelijk van hoe scherp je het vraagt. Daar is mijn KOMPAS-aanpak voor — Kader, Opdracht, Materiaal, Paalwerk, Afwerking, Sturing — zodat je een vibe coding tool precies de goede kant op stuurt in plaats van te hopen dat het klopt. Een overzicht van meer opties vind je in mijn gids met vibe coding tools.

    Veelgestelde vragen

    Welke is het makkelijkst om mee te beginnen?

    Voor iemand zonder programmeerervaring zijn Lovable en Bolt het laagdrempeligst: je typt een prompt en ziet meteen een werkende app, zonder editor of installatie. Cursor vraagt iets meer technische gewenning, maar leert je wel sneller begrijpen wat er onder de motorkap gebeurt.

    Kan ik met deze tools een echt product bouwen, of alleen prototypes?

    Prototypes en kleine apps gaan prima. Hoe complexer en groter je project, hoe meer je tegen grenzen aanloopt en hoe handiger het is om ergens zelf de code te kunnen aanpassen. Veel mensen starten in een browser-tool en stappen later over naar Cursor zodra het serieus wordt.

    Moet ik kunnen programmeren om vibe coding te doen?

    Nee, om te starten niet. Maar je hebt wél de vaardigheid nodig om duidelijk te beschrijven wat je wilt en bij te sturen als het afwijkt. Dat is een aparte skill — en eerlijk gezegd belangrijker dan de tool zelf.

    Welke moet ik nou kiezen?

    Wil je de code zien en in bestaande projecten werken: Cursor. Wil je snel van idee naar werkende app zonder editor: Lovable of Bolt, en probeer ze allebei kort uit. Twijfel je nog, dan helpt een sessie waarin we het samen op jouw project toepassen.

    Wil je weten of jouw prompt scherp genoeg is voor welke tool dan ook? Plak hem in de gratis prompt-coach tool — die scoort en herschrijft hem voor je. Wil je liever samen aan de slag met vibe coding op jouw eigen project, kijk dan naar de coaching.

    Verder lezen

    De beste tool hangt minder af van hype en meer van controle: kun je wijzigingen terugvinden, testen en herstellen als de AI te enthousiast bouwt? Lees daarna ook vergelijk Cursor, Lovable en Bolt of check je AI-code voor publicatie.

  • Claude Code naar Codex migreren: wat neem je echt mee?

    Claude Code naar Codex migreren: wat neem je echt mee?

    Als je van Claude Code naar Codex overstapt, migreer je vooral je werkwijze. Niet alleen je prompt. Neem je instructiebestanden, skills, MCP servers, hooks, subagents en recente sessies mee. Controleer daarna per project of de agent nog dezelfde regels volgt, dezelfde tools mag gebruiken en dezelfde stopregels respecteert.

    De grootste fout is denken dat een importknop je teamgeheugen begrijpt. OpenAI’s Codex-migratieflow helpt met het overzetten van veel agent-context, maar jij moet beoordelen welke afspraken nog kloppen. Een oude Claude-regel kan in Codex te breed zijn. Een hook die in je vorige setup nuttig was, kan in een andere agent te veel rechten krijgen. En een sessie uit vorige week is handig als geheugensteun, maar geen bewijs dat de nieuwe agent je codebase kent.

    Wat OpenAI’s migratieflow doet

    OpenAI presenteert de migratiepagina als een manier om “from another coding agent” naar Codex te bewegen. De flow draait om drie stappen:

    1. Importeren van bestaande agent-context.
    2. Aanvullende setup nalopen.
    3. Verder werken in Codex met de meegenomen context.

    De screenshots op de OpenAI-pagina laten precies zien waar dit interessant wordt: Codex kijkt niet alleen naar losse prompts, maar naar de werkafspraken om je project heen. Denk aan instructies, configuratie, skills, MCP servers, hooks, subagents en recente sessies.

    Dat is goed nieuws voor mensen die al serieus met Claude Code werkten. Je hoeft niet vanaf nul te beginnen. Maar importeren is geen kwaliteitscontrole. Zie het als een verhuisdoos: alles zit erin, ook de dingen die je beter niet opnieuw in je werkkamer zet.

    Er staat ook een officiele OpenAI-skill rond migrate-to-codex in de OpenAI skills-repository. Die skill richt zich op ondersteunde instructiebestanden, skills, agents en MCP-configuratie. Dat bevestigt het belangrijkste punt: migreren gaat niet over een losse prompt, maar over de operationele laag om je agent heen.

    Wat je wel en niet blind moet meenemen

    Onderdeel Meenemen? Controle
    AGENTS.md, CLAUDE.md of projectinstructies Ja Haal tool-specifieke commands eruit of maak ze expliciet per agent.
    Skills en workflows Ja, maar selectief Check triggers. Een te brede skill activeert op de verkeerde taak.
    MCP servers Ja, met rechtencheck Controleer toegang tot Gmail, GitHub, database, browser, filesystem en secrets.
    Hooks Alleen als je ze begrijpt Een hook die automatisch test of formatteert is prima. Een hook die live deployt vraagt om harde stopregels.
    Subagents Selectief Zet alleen subagents over die een duidelijke taak, input en output hebben.
    Recente sessies Als referentie Gebruik ze niet als bron van waarheid voor requirements.
    Oude modelvoorkeuren Nee, opnieuw kiezen Modellen veranderen te snel. Kies opnieuw per taaktype.

    Mijn advies: importeer breed, activeer smal. Laat Codex eerst lezen, samenvatten en een migratieplan maken. Geef pas daarna toestemming voor edits, hooks of tools met schrijf- of deployrechten.

    Codex of Claude Code: kies niet religieus

    Veel mensen maken hier een fanboy-vraag van. Dat helpt niet. De praktische vraag is: welke agent maakt in jouw project de minste dure fouten?

    Claude Code blijft sterk als je al een volwassen Claude-setup hebt met goede CLAUDE.md-regels, terminalgewoontes en bestaande reviewflows. Codex is logisch als je dieper in OpenAI tooling zit, veel met OpenAI API’s werkt of je agentwerk vanuit een OpenAI-omgeving wilt standaardiseren.

    Voor serieuze projecten zou ik ze naast elkaar testen:

    Taak Beste test
    Bugfix met bestaande tests Laat beide agents dezelfde failing test oplossen en vergelijk diff, testoutput en uitleg.
    Grote refactor Meet wie het kleinste werkende plan maakt en het minst ongevraagd verandert.
    Nieuwe feature Kijk wie betere vragen stelt over randgevallen, data en UX.
    Content of promptworkflow Check wie minder vulling schrijft en beter vasthoudt aan je tone-of-voice.
    Tooling en MCP Controleer wie rechten, secrets en rollback beter behandelt.

    De winnaar is niet de agent met de mooiste uitleg. De winnaar is de agent die na verificatie de schoonste wijziging achterlaat.

    Laatste modellen: let op de taak, niet alleen op de naam

    Peildatum: 10 juni 2026. OpenAI noemt in de officiele modeldocs gpt-5.5 als flagship voor complex reasoning en coding. Daarnaast staan gpt-5.4, gpt-5.4-mini en gpt-5.4-nano in de actuele modelkeuze voor lagere kosten of lagere latency. Anthropic noemt op dezelfde peildatum claude-fable-5 als meest capabele breed beschikbare model, claude-mythos-5 als limited availability via Project Glasswing, en daarnaast claude-opus-4-8, claude-sonnet-4-6 en claude-haiku-4-5.

    Die namen zijn nuttig, maar ze lossen je migratie niet op. De vraag is per taak welk risico je neemt.

    De vuistregel:

    • Gebruik gpt-5.5, claude-fable-5 of claude-opus-4-8 voor architectuur, complexe refactors, securitygevoelige keuzes en migratieplannen.
    • Gebruik gpt-5.4-mini, gpt-5.4-nano, claude-sonnet-4-6 of claude-haiku-4-5 voor samenvatten, kleine tekstedits, simpele testfixes en bulkcontrole.
    • Gebruik geen goedkoop model voor taken met live systemen, klantdata, betalingen of productiedeploys.
    • Laat een agent nooit modelkeuze gebruiken als excuus om geen bewijs te leveren.

    Een goede migratieprompt noemt daarom niet alleen “gebruik het beste model”, maar ook: wat mag de agent lezen, wat mag hij aanpassen, welke tests gelden als bewijs en waar moet hij stoppen.

    Een migratieprompt die wel werkt

    Gebruik deze prompt nadat je de Codex-import hebt gedaan:

    Lees eerst de geimporteerde agent-instructies, skills, MCP-configuratie, hooks en recente sessies.

Maak daarna een migratierapport met:
1. Welke instructies nog bruikbaar zijn in Codex.
2. Welke instructies tool-specifiek zijn voor Claude Code, Cursor of een andere agent.
3. Welke MCP servers schrijf- of secret-risico hebben.
4. Welke hooks automatisch iets kunnen aanpassen, deployen, mailen, betalen of publiceren.
5. Welke skills te breed triggeren.
6. Welke drie projectregels je zou aanpassen voordat je code wijzigt.

Voer nog geen edits uit. Geen hooks draaien. Geen externe tools gebruiken met schrijfrechten. Eindig met een korte safe-to-start checklist.

    Die prompt is saai op de goede manier. Je laat de agent eerst de verhuizing inspecteren voordat hij de gereedschapskist openklapt.

    De KOMPAS-check voor agentmigratie

    Op Promptcoaching gebruiken we KOMPAS voor prompts en workflows. Voor Codex/Claude-migratie ziet die check er zo uit:

    • Kader: om welk project, welke repo, welke omgeving en welke rechten gaat het?
    • Opdracht: moet de agent analyseren, migreren, testen, documenteren of echt code wijzigen?
    • Maat: wat is klein genoeg voor deze sessie?
    • Paalwerk: welke bestanden, URL’s, tests en bronnen zijn leidend?
    • Afwerking: welk bewijs moet de agent opleveren?
    • Stopregels: wanneer moet de agent stoppen en jou vragen?

    Wie deze zes punten overslaat, krijgt vaak een agent die druk lijkt maar weinig controleerbaar werkt.

    Mijn nuchtere advies

    Zet Codex en Claude Code niet tegenover elkaar alsof je maar een gereedschap mag houden. Maak je agent-setup portabel. Schrijf projectregels in gewone markdown. Bewaar workflows als bestanden. Gebruik MCP bewust. Laat hooks nooit zonder stopregels draaien. En meet agentkwaliteit aan bewijs: tests, screenshots, logs, diff en rollback.

    De migratie naar Codex is dan geen sprong in het diepe. Het is een goede aanleiding om je AI-werkwijze op te ruimen.

    Update 12 juni 2026: wat OpenAI/Ona verandert aan Codex-werk

    OpenAI kondigde op 11 juni 2026 aan dat het Ona wil overnemen. De overname is nog niet definitief afgerond; OpenAI schrijft zelf dat de deal nog afhankelijk is van closing conditions en benodigde goedkeuringen.

    De relevante les voor deze migratiepagina is niet de overname zelf. Het gaat om de richting: Codex moet langer lopende taken kunnen doen in veilige, persistente werkomgevingen. Dat maakt een migratie van Claude Code naar Codex minder een promptverhuizing en meer een operationele keuze.

    Als een agent straks uren of dagen doorwerkt, moet je vóór de taak scherper zijn:

    • Scope: wat mag de agent aanpassen, en wat niet?
    • Context: welke bestanden, issues, rapporten en eerdere beslissingen zijn bron van waarheid?
    • Credentials: welke systemen mag de agent lezen, schrijven of juist niet aanraken?
    • Checkpoints: wanneer moet de agent stoppen voor review?
    • Rollback: hoe draai je een verkeerde wijziging terug zonder ander werk te raken?

    Mijn praktische regel blijft: importeer breed, activeer smal. Laat Codex eerst lezen, samenvatten en een plan maken. Geef pas daarna toestemming voor edits, hooks of tools met schrijf- en deployrechten.

    Bron: OpenAI – OpenAI to acquire Ona.

    Verder lezen

    Claude reageert sterk op duidelijke rol, context en beoordelingscriteria. Geef dus niet alleen de taak, maar ook hoe het antwoord beoordeeld wordt. De instellingen die per model verschillen — en die je bij zo’n overstap opnieuw moet afwegen — staan in de promptgidsen per model.

  • AI verandert werk — waarom prompten leren je beste investering is

    AI verandert werk — waarom prompten leren je beste investering is

    Bijna elke week krijg ik dezelfde vraag van iemand die ik coach: “Sam, gaat AI mijn werk overnemen?” Mijn eerlijke antwoord was lang: niemand weet het precies. Maar onlangs verscheen er een document dat me hielp die vraag scherper te beantwoorden — en het kwam uit onverwachte hoek. Anthropic, de maker van Claude, publiceerde geen nieuwe tool, maar een plan over werk en inkomen. Ik las het, en het bevestigde precies waarom ik doe wat ik doe.

    Wat Anthropic zegt

    Het plan heet het Economic Policy Framework. De kern: AI gaat zo snel dat beleid achterloopt. Die snelheid kan veel welvaart brengen, maar ook de vraag naar menselijk werk verlagen. Anthropic schetst drie scenario’s — van een milde schok tot grote werkloosheid — met per geval maatregelen, en legt er $350 miljoen bij voor onderzoek en beurzen. Eerlijk blijven: een AI-bedrijf dat om beleid vraagt heeft daar ook belang bij. Lees het als serieus voorstel, niet als orakel.

    De rode draad: wie met AI kan werken, staat sterker

    Wat me opviel, is wat in bijna élk scenario terugkomt. Anthropic raadt overheden aan om mensen te helpen omscholen, en raadt bedrijven aan om hun mensen om te scholen en te herplaatsen in plaats van in te krimpen. De onderliggende gedachte: niet de technologie bepaalt of jij relevant blijft, maar of je leert ermee te werken.

    Dat is precies de boodschap die ik in elke coaching herhaal. Het is niet “AI versus jij”. Het is “jij met AI versus iemand zonder”. En dat verschil is leerbaar.

    Waarom prompten meer is dan een trucje

    Veel mensen denken bij prompten aan handige zinnetjes die je ergens kopieert. Zo zie ik het niet. Goed prompten is leren denken samen met een model: helder krijgen wat je wilt, het in stukken knippen, bijsturen op het antwoord. Het is het verschil tussen AI die jóu gebruikt — vage vraag, vaag antwoord — en jij die AI gebruikt.

    Die vaardigheid verdwijnt niet als de modellen beter worden. Sterker: hoe krachtiger AI wordt, hoe waardevoller het is om er goed mee te kunnen sturen. Daarom werk ik met de KOMPAS-methode — een vast houvast om elke prompt beter te maken, ongeacht welk model je gebruikt.

    Wat ik mensen aanraad

    Wacht niet op zekerheid die er toch niet komt. Begin klein en concreet. Pak één taak uit je echte werk waar AI je tijd bespaart, en doe die deze week mét AI. Bouw van daaruit verder. Wil je gestructureerd oefenen? Test je eigen prompts gratis met mijn Prompt Coach, of plan een sessie via coaching als je sneller stappen wilt zetten met begeleiding.

    Eerlijk over de onzekerheid

    Ik ga je niets wijsmaken: niemand weet hoe snel of hoe hard dit gaat. Het plan van Anthropic is bewust voorbereidend, geen voorspelling, en zeker geen loopbaangarantie. Maar van alle reacties die ik zie, is afwachten de enige die gegarandeerd niet werkt. Leren werken met AI is iets wat je vandaag al in eigen hand hebt.

    Veelgestelde vragen

    Maakt AI mijn baan overbodig?

    Dat hangt minder af van de technologie dan van wat je ermee doet. AI neemt vooral routinetaken over, terwijl het waardevoller wordt om er goed mee te kunnen sturen. Wie leert werken met AI, vergroot juist zijn waarde.

    Is leren prompten dan de oplossing?

    Geen wondermiddel, wel een concrete stap die je nu zelf kunt zetten. Goed prompten is leren denken met een model — een vaardigheid die niet verdwijnt naarmate AI beter wordt, maar belangrijker.

    Eerlijk gezegd: dit is een voorstel van één bedrijf, gericht op de Amerikaanse situatie, en geen financieel of loopbaanadvies. Ik deel het omdat het scherp laat zien hoe de makers van AI zelf naar de toekomst van werk kijken — en omdat het bevestigt wat ik dagelijks zie: de mensen die leren werken met AI, staan het sterkst. Bron: Anthropic — Economic Policy Framework.

    Verder lezen

    Prompt engineering wordt pas nuttig als je de fout kunt aanwijzen: ontbrekende context, verkeerde rol, geen voorbeeld of geen controle op het antwoord. Lees daarna ook bekijk de AI-prompt hub of gebruik de Prompt Coach.

  • Fable 5 verandert hoe je prompt: van instrueren naar delegeren

    Fable 5 verandert hoe je prompt: van instrueren naar delegeren

    Met Fable 5 verschuift prompten van stap-voor-stap instrueren naar een hele taak delegeren. Het nieuwe model doet langere, ingewikkelde klussen zelfstandig, met minder tussentijdse controle. Dat vraagt een andere prompt: minder micromanagen, meer heldere doelen, context en succescriteria. De klassieke promptprincipes blijven gewoon gelden — je past ze alleen toe op een groter niveau.

    De grootste fout die je nu kunt maken, is een capabeler model behandelen als het oude. Wie Fable 5 elke stap blijft voorkauwen, verspilt precies datgene waar het goed in is: zelfstandig doorwerken aan een doel. De vaardigheid die telt, verschuift van “een vraag goed formuleren” naar “een taak goed inkaderen”.

    De aanleiding: een “derde tijdperk”

    Bij de lancering schreef Felix Rieseberg — die bij Anthropic aan Claude Cowork werkt — in een bericht op X dat hij het bewust niet over de benchmarks wilde hebben. Volgens hem begint met Fable 5 een “derde tijdperk” van werken met AI. De rode draad: we gaan van chatten en bijsturen naar het uit handen geven van complete taken. Dat klinkt abstract, maar het verandert heel concreet hoe je een goede prompt opbouwt.

    Wat er verandert aan je prompt

    Eerdere modellen werkten het best als je ze in kleine stappen aanstuurde: doe dit, en dan dit, en controleer even. Fable 5 is gemaakt om langer zelfstandig door te werken — in Anthropics eigen woorden met “minder check-ins”. Dus in plaats van een reeks losse opdrachten geef je het één heldere opdracht met alles wat het nodig heeft om hem af te maken.

    Denk aan het verschil tussen een stagiair aansturen en een ervaren collega een klus geven. Bij de eerste dicteer je elke stap. Bij de tweede zeg je wat het eindresultaat moet zijn, geef je de context en de kaders, en laat je het werk aan hem over. Fable 5 verdient die tweede aanpak.

    De principes die gewoon blijven gelden

    Belangrijk: dit is geen breuk met alles wat je weet. De vaste promptprincipes uit Anthropics eigen prompting-richtlijnen werken juist beter naarmate een model capabeler wordt. De belangrijkste:

    • Wees expliciet en direct. Zeg precies wat je wilt, inclusief het waarom — een model dat de bedoeling snapt, kiest betere oplossingen.
    • Geef een rol. “Je bent een ervaren redacteur die…” stuurt de toon en het oordeel.
    • Laat voorbeelden zien. Eén goed voorbeeld van het gewenste resultaat stuurt strakker dan drie alinea’s uitleg.
    • Structureer met labels. Scheid je opdracht van het bronmateriaal, bijvoorbeeld met XML-achtige tags, zodat het model niet door elkaar haalt wat het moet doen en waarmee.
    • Laat het nadenken bij ingewikkelde taken — vraag het eerst te redeneren voordat het een conclusie geeft.

    Je gooit deze technieken dus niet weg. Je past ze toe op een grotere brok werk.

    Een goede delegeer-prompt in de praktijk

    Een bruikbaar skelet voor een taak die je uit handen geeft:

    • Rol: wie moet het model zijn? (“Je bent een onderzoeksredacteur.”)
    • Doel: wat is het eindresultaat? (“Lever een artikel van 800 woorden over X.”)
    • Context en materiaal: alles wat het nodig heeft — bronnen, achtergrond, voorbeelden.
    • Randvoorwaarden: wat mag wel en niet, lengte, toon, verboden aannames.
    • Klaar-criterium: wanneer is het goed? (“Elke claim onderbouwd, geen jargon, met een conclusie.”)

    Geef je dat in één keer mee, dan kan Fable 5 het grootste deel zelfstandig afmaken — en hoef jij alleen het resultaat te beoordelen in plaats van elke tussenstap.

    De valkuilen

    Drie dingen gaan het vaakst mis. Te weinig context: laat je gaten, dan vult het model die met aannames. Geen klaar-criterium: dan stopt het te vroeg of doet het juist te veel. En micromanagen: blijf je elke stap dicteren, dan verlaag je een sterk model tot het niveau van je instructies. Houd er ook rekening mee dat Fable 5 bij gevoelige onderwerpen (zoals beveiliging) kan terugschakelen of weigeren — dat is een ingebouwde rem, geen prompt-fout.

    Voorbeeld: micromanagen versus delegeren

    Het verschil zie je het best naast elkaar. Stel, je wilt een samenvatting van drie klantgesprekken.

    Micromanagen (de oude reflex): “Lees gesprek 1. Vat het samen in drie punten. Wacht. Nu gesprek 2. Vat samen. Nu gesprek 3…” Je stuurt elke stap, en het model kan niet vooruitdenken.

    Delegeren (de Fable 5-manier): “Je bent mijn klantonderzoeker. Hieronder staan drie klantgesprekken. Lever één overzicht met de gedeelde pijnpunten, de opvallende verschillen, en drie concrete verbeterpunten voor ons product. Onderbouw elk punt met een citaat uit de gesprekken. Klaar is: niets verzonnen, alleen wat er echt staat.”

    De tweede prompt is langer, maar je schrijft hem één keer en krijgt in één beurt een bruikbaar resultaat — in plaats van tien keer bijsturen. Dat is de hele winst: je investeert vooraf in een heldere opdracht en wint achteraf tijd op de uitvoering. Hoe capabeler het model, hoe meer die investering oplevert.

    Wat dit voor jou betekent

    Fable 5 is tot 22 juni gratis te proberen op de betaalde abonnementen. Gebruik die weken om een paar delegeer-prompts te bouwen voor je echte werk en draai ze naast je oude aanpak — je voelt meteen waar het verschil zit. In onze promptgidsen staat hoe je zulke prompts opbouwt, en bij de use-cases zie je hoe delegeren er in de praktijk uitziet. Wil je sparren over jouw specifieke taken, dan kan dat via de prompt-coach of dieper in een coachingstraject.

    Mijn oordeel

    De kern van goed prompten verschuift met Fable 5 van formuleren naar inkaderen. Niet de mooiste zin wint, maar de helderste opdracht: een rol, een doel, de juiste context en een duidelijk klaar-criterium. Wie dat onder de knie heeft, geeft straks hele taken uit handen waar hij vroeger een uur zat te chatten. De principes zijn niet nieuw — je gebruikt ze alleen op een hoger niveau, en dat is precies waar de winst zit.

    Update 13 juni 2026: Fable 5 en Mythos 5 zijn tijdelijk offline gehaald

    Anthropic heeft Fable 5 en Mythos 5 uitgeschakeld voor klanten nadat het bedrijf naar eigen zeggen een Amerikaanse export-control directive kreeg. Volgens Anthropic richtte die opdracht zich op toegang door foreign nationals, ook als die persoon in de Verenigde Staten zit. Omdat dat in de praktijk moeilijk zuiver te handhaven is, heeft Anthropic de modellen voor iedereen dichtgezet. Andere Claude-modellen zouden volgens Anthropic niet geraakt zijn.

    Dat verandert het advies in dit artikel. Fable 5 was interessant omdat het lange, rommelige taken beter kon dragen dan eerdere Claude-modellen. Maar een promptstrategie die alleen werkt met één tijdelijk beschikbaar frontiermodel is te kwetsbaar. Voor serieus werk moet je prompt dus niet alleen slim zijn, maar ook overdraagbaar.

    Wat je nu praktisch doet

    • Bewaar je taakdefinitie los van het model. Zet doel, context, grenzen en acceptatiecriteria in je prompt, niet in vage verwijzingen naar “doe dit zoals Fable”.
    • Maak een fallback-versie. Test dezelfde taak in Claude Opus, ChatGPT of Codex en noteer wat je moet aanscherpen als het model minder autonoom is.
    • Splits lange opdrachten in checkpoints. Als een model wisselt, wil je niet opnieuw beginnen. Laat het werk opleveren in tussenstappen die je kunt overnemen.
    • Controleer claims over jailbreaks voorzichtig. Anthropic spreekt over een smalle, niet-universele mogelijke bypass. Dat is iets anders dan “Fable is gekraakt”.
    • Maak je workflow model-onafhankelijk. Een goede prompt is een werkinstructie die ook bruikbaar blijft als de beste modelnaam morgen verandert.

    Mijn oordeel: dit is geen reden om Fable 5 af te schrijven. Het is wel een harde herinnering dat AI-werk niet mag hangen aan één modelknop. Wie prompts schrijft voor echte processen, schrijft ze alsof het model vervangen kan worden.

    Bronnen: Anthropic statement over Fable/Mythos access en de oorspronkelijke Fable 5 / Mythos 5 launchpost.

    Verder lezen

    Claude reageert sterk op duidelijke rol, context en beoordelingscriteria. Geef dus niet alleen de taak, maar ook hoe het antwoord beoordeeld wordt. Wat Fable 5 anders doet dan de rest staat naast de andere modellen in de promptgidsen per model — inclusief waarom je die modellen door een aparte verifier laat nakijken.