Prompt-Leitfaden
Mit KI arbeiten, gründlich
- Kostenlos, ohne Konto
- 12 Kapitel
- 76 Prinzipien
- 19 Beispiele schwach und stark
Die Lerninhalte auf dieser Seite gibt es vorerst nur auf Niederländisch.
Kapitel 1
Hoe een taalmodel denkt
Een taalmodel is geen zoekmachine en geen collega met een geheugen. Het voorspelt, woord voor woord, wat een goed vervolg is op alles wat het op dat moment voor zich heeft. Wie dat snapt, snapt meteen waarom context het belangrijkste is wat je meegeeft.
Het voorspelt, het weet niet
Een model leest je tekst in kleine stukjes (tokens) en berekent wat er het meest waarschijnlijk op volgt. Dat levert verrassend goed redeneren op, maar het blijft voorspellen: een vlot, zelfzeker antwoord is niet hetzelfde als een juist antwoord. Behandel de output als een sterk voorstel dat je nog controleert.
Het contextvenster is zijn hele wereld
Alles wat het model ‘ziet’ zit in het contextvenster: je instructies, de bestanden die je deelt, het gesprek tot nu toe en zijn eigen antwoorden. Dat venster is groot maar eindig, en hoe voller het zit, hoe meer details naar de achtergrond verdwijnen. Wat er niet in staat, bestaat voor het model niet.
Geen geheugen tussen gesprekken, tenzij je het meegeeft
Een nieuwe chat begint blanco. Wat je gisteren uitlegde over de bakkerij van Marleen, is vandaag weg, tenzij je tool een geheugenfunctie heeft of jij het opnieuw aanlevert. Daarom werken vaste projectbestanden (zoals een CLAUDE.md of een briefing) zo goed: ze geven elke sessie dezelfde vertrekbasis.
Schwach Doe verder met die website van gisteren.Stark We werken verder aan de site van Bakkerij Marleen (Astro, Tailwind, NL/FR). Gisteren hebben we de productpagina gebouwd. Vandaag: het bestelformulier voor taarten. Hieronder de briefing en de huidige mappenstructuur.
Hallucinaties zijn normaal gedrag, geen defect
Als het model iets niet weet, vult het vaak in met iets dat plausibel klinkt: een npm-pakket dat niet bestaat, een DNS-instelling die nergens staat, een wetsartikel met het verkeerde nummer. Vraag het om bronnen of onzekerheid te benoemen, en controleer namen, versies, cijfers en citaten altijd zelf.
Schwach Welke npm-library gebruik ik voor Belgische btw-nummers?Stark Welke npm-libraries bestaan er om Belgische btw-nummers te valideren? Geef alleen pakketten waarvan je vrij zeker bent dat ze bestaan, zeg erbij hoe zeker je bent, en vermeld hoe ik dat zelf op npmjs.com nakijk.
Er is een kennisgrens
Een model is getraind tot een bepaalde datum en weet niets van wat daarna gebeurde: nieuwe frameworkversies, gewijzigde prijzen, recente wetgeving. Geef actuele documentatie mee of laat het (als je tool dat kan) de officiële bron opzoeken. Bij versies en API’s: vertrouw de docs, niet het geheugen van het model.
Duidelijke taal levert duidelijke output
Omdat het model verderbouwt op jouw tekst, kleurt jouw tekst het resultaat. Een slordige, vage vraag krijgt vaak een algemeen antwoord; een precieze vraag met vakwoorden trekt het naar een precies antwoord. Schrijf zoals je zou schrijven aan een slimme nieuwe collega die je project nog niet kent.
Kapitel 2
De basis van een goede prompt
Een goede prompt is vooral een goede briefing. Doel, context, grenzen, publiek, vorm en een duidelijk ‘klaar wanneer’: als die erin staan, is de helft van het werk gedaan. Het helpt om te denken aan een slimme freelancer die je niet kent en die maar één keer je briefing leest.
Begin met het doel
Zeg eerst wat je wilt bereiken, niet alleen welke handeling je wilt. ‘Schrijf een tekst’ is een handeling; ‘zorg dat mensen uit Ternat weten dat we op zondag open zijn’ is een doel. Met het doel kan het model zelf betere keuzes maken in alles wat je niet uitspelde.
Schwach Schrijf een tekst over onze openingsuren.Stark Doel: klanten weten dat Café De Posi vanaf november ook op zondag open is (10u–18u). Schrijf een korte melding voor de homepage, 2 zinnen, warm en dorps van toon.
Geef de context die jij in je hoofd hebt
Jij weet wie de klant is, wat al gebouwd is en wat er vorige keer misliep. Het model niet. Noem de stack, de doelgroep, de huidige toestand en wat er al geprobeerd is. Een paar zinnen context besparen je vaak drie rondes bijsturen.
Zeg wat niet mag
Grenzen zijn even belangrijk als opdrachten: geen nieuwe dependencies, niets aan de database veranderen, max. 150 woorden, geen Engelse woorden in de klanttekst. Een model vult lege ruimte graag zelf in; grenzen vertellen het waar die ruimte stopt.
Schwach Maak het contactformulier beter.Stark Verbeter de validatie van het contactformulier in src/components/Contact.astro. Voorwaarden: geen nieuwe npm-pakketten, de bestaande foutmeldingen in vier talen behouden, de server-side controle in api/contact.ts niet aanraken.
Leg uit waarom
Een regel met een reden wordt slimmer toegepast dan een kale regel. ‘Gebruik geen afkortingen’ werkt; ‘gebruik geen afkortingen, want de tekst wordt voorgelezen door een schermlezer’ werkt beter, omdat het model dan ook aan andere dingen denkt die voor schermlezers tellen.
Benoem publiek en vorm
Voor wie is het, en hoe moet het eruitzien? Een uitleg voor een cafébaas is anders dan een uitleg voor een developer, en een tabel is anders dan een mail. Zeg het gewoon: lengte, toon, taal, opbouw, opmaak.
Spreek af wanneer het klaar is
Een duidelijk eindpunt voorkomt dat het model te vroeg stopt of te ver doorgaat. Formuleer het als een controleerbare lijst: de build slaagt, de pagina werkt in vier talen, de tests zijn groen, je geeft een samenvatting van wat je wijzigde.
Schwach Voeg een nieuwsbriefinschrijving toe.Stark Voeg een nieuwsbriefinschrijving toe in de footer. Klaar wanneer: (1) het veld werkt op mobiel en desktop, (2) een ongeldig e-mailadres een duidelijke foutmelding geeft in NL/FR/DE/EN, (3) npm run build slaagt, (4) je me een lijst geeft van de gewijzigde bestanden.
Wees expliciet, ook als het vanzelfsprekend lijkt
Wat voor jou evident is (‘natuurlijk in het Nederlands’, ‘natuurlijk responsive’), is voor het model een gok. Recente modellen volgen instructies bovendien vrij letterlijk: vraag je ‘enkele suggesties’, dan krijg je suggesties en geen uitvoering. Wil je dat het meteen bouwt, zeg dat dan.
Kapitel 3
Context geven
Context is de brandstof van een goed antwoord, maar meer is niet altijd beter. Het gaat om de juiste stukken, duidelijk gescheiden van je instructies. Zo weet het model wat het moet doen en waarmee.
Geef de echte stukken, geen samenvatting
Plak de foutmelding volledig, deel het bestand zelf, toon de huidige DNS-records. Je eigen samenvatting laat net het detail weg dat ertoe doet. In een agent-tool als Claude Code kan je bestanden ook rechtstreeks aanwijzen in plaats van ze te kopiëren.
Schwach Mijn site geeft een error na de verhuis naar de nieuwe hosting.Stark Na de verhuis van pagliacci.be naar Vercel krijg ik deze fout in de browser: ERR_SSL_VERSION_OR_CIPHER_MISMATCH Huidige DNS-records bij de registrar (export hieronder). Wat is de meest waarschijnlijke oorzaak en wat controleer ik eerst?
Kies de juiste hoeveelheid
Een heel project in één keer plakken verdunt de aandacht; te weinig laat het model gokken. Geef wat nodig is voor deze taak: het betrokken bestand, de types die het gebruikt, een voorbeeld van hoe het elders gedaan wordt. Een agent die zelf kan zoeken, laat je beter zelf de rest vinden.
Scheid instructies van materiaal
Zet referentiemateriaal tussen duidelijke markeringen, bijvoorbeeld XML-achtige tags zoals <briefing>, <mail_klant> of <huidige_code>. Zo weet het model wat opdracht is en wat alleen gelezen moet worden. Dat helpt ook als het materiaal zelf zinnen bevat die op instructies lijken.
Lange documenten bovenaan, de vraag onderaan
Werk je met lange stukken (een offerte, een handleiding, een export), zet ze dan eerst en stel je vraag op het einde. Modellen presteren daar doorgaans beter mee. Vraag bij lange bronnen ook eerst de relevante passages te citeren voor het antwoordt.
Geef een rol als die iets toevoegt
‘Je bent een ervaren webdeveloper die voor Belgische kmo’s werkt’ zet de juiste toon en het juiste niveau. Een rol is geen toverwoord, maar het richt de aandacht: welk jargon, welke valkuilen, welke wetgeving. Combineer het altijd met echte context.
Wijs naar bestaande patronen
Vraag het model om zich te spiegelen aan wat er al is: ‘bouw de agendapagina op zoals de nieuwspagina in src/pages/nieuws’. Zo krijg je code die past in het project in plaats van een nieuwe stijl naast de oude.
Schwach Maak een admin-pagina voor de openingsuren.Stark Maak een admin-pagina voor de openingsuren van Café GG. Volg exact het patroon van src/pages/admin/agenda.astro (zelfde layout, zelfde formuliercomponenten, zelfde opslag via api/admin). Toon me eerst welke bestanden je wilt aanmaken.
Kapitel 4
Voorbeelden en formaat
Eén goed voorbeeld zegt vaak meer dan een alinea uitleg. En wie de output verder wil gebruiken, in code, een spreadsheet of een site, moet het formaat even precies vastleggen als de inhoud.
Toon wat je bedoelt (few-shot)
Geef twee of drie voorbeelden van de gewenste output en het model pikt toon, lengte en structuur op. Kies voorbeelden die verschillen van elkaar, anders kopieert het één patroon te letterlijk. Zet ze apart, bijvoorbeeld tussen <voorbeeld> tags.
Schwach Schrijf productbeschrijvingen voor de broodjes.Stark Schrijf productbeschrijvingen voor de broodjes, in deze stijl: <voorbeeld>Desembrood: twee dagen gerezen, krokante korst, zachte kruim. Lekker bij soep.</voorbeeld> <voorbeeld>Spelt-noten: volkoren spelt met walnoten. Stevig, licht zoet.</voorbeeld> Maak er zo één voor: meergranen, rozijnenbrood, baguette.
Beschrijf het formaat, niet alleen de inhoud
Zeg hoe het eruit moet zien: een tabel met deze kolommen, een Markdown-lijst, platte tekst zonder opmaak voor een sms. Zeg ook wat er niet in mag: geen inleiding, geen afsluitende samenvatting. Zeg liever wat je wel wilt dan alleen wat je niet wilt.
Gestructureerde output voor code
Moet de output door code verwerkt worden, vraag dan JSON met een exact schema en zeg dat er niets anders bij mag. Via de API bestaan er ook functies die een schema afdwingen; gebruik die waar het kan. Valideer het resultaat altijd in je code, ook als het er perfect uitziet.
Laat het formaat aansluiten bij je gebruik
Een vertaling voor een i18n-bestand vraag je als JSON-sleutels, niet als lopende tekst. Een lijst DNS-records vraag je in het formaat dat je registrar verwacht. Hoe dichter de output bij de eindbestemming ligt, hoe minder kopieer- en plakfouten.
Schwach Vertaal de knoppen naar het Frans en Duits.Stark Vul src/i18n/fr.json en src/i18n/de.json aan met dezelfde sleutels als nl.json. Behoud de sleutelnamen exact, vertaal alleen de waarden, gebruik ‘vous’ in het Frans en ‘Sie’ in het Duits.
Gebruik je eigen stijl als voorbeeld
Wil je dat een mail klinkt zoals jij, geef dan een paar echte mails van jezelf mee (zonder persoonsgegevens van klanten). Het model neemt woordkeuze, lengte en aanspreekvorm verrassend goed over. Dat werkt beter dan ‘schrijf informeel maar professioneel’.
Kapitel 5
Laten denken en plannen
Bij moeilijke taken wordt het resultaat beter als het model eerst nadenkt en een plan maakt voor het begint. Jij krijgt zo bovendien een moment om bij te sturen voor er iets gebouwd is. Plannen kost een paar minuten; een verkeerde richting kost een namiddag.
Vraag eerst een plan
Laat het model bij alles wat groter is dan een kleine wijziging eerst een plan voorstellen: welke bestanden, welke stappen, welke risico’s. Lees het, stuur bij, en geef dan pas groen licht. In Claude Code bestaat daar een aparte plan-modus voor (zie hoofdstuk 7).
Schwach Bouw een webshop voor de boerderij.Stark We gaan een eenvoudige webshop toevoegen aan de site van de boerderij (afhaling, geen verzending). Maak eerst een plan: datamodel, pagina’s, betaalflow, admin, en wat je niet zou bouwen in versie 1. Schrijf nog geen code.
Laat het stap voor stap redeneren
Bij analyse, rekenwerk of debugging helpt het om te vragen dat het model eerst zijn redenering uitschrijft en pas daarna concludeert. Veel modellen hebben ook een ingebouwde ‘denk’-modus; gebruik die voor moeilijke problemen. Lees de redenering: daar zie je waar het misgaat.
Laat het vragen stellen
Zeg expliciet dat het mag (of moet) terugvragen als iets onduidelijk is. Anders vult het de gaten zelf in met aannames. Een goede formulering: ‘stel eerst je vragen, maximaal vijf, en begin pas daarna’.
Laat aannames benoemen en uitdagen
Vraag het model om de aannames achter zijn voorstel op te sommen, en vraag dan welke het zwakst is. Of vraag het om zijn eigen plan te bekritiseren als een kritische collega. Dat haalt verborgen risico’s naar boven voor ze code worden.
Splits grote taken in een keten
Eén reuzenprompt voor ‘analyseer, ontwerp, bouw en test’ geeft middelmatig werk op elk punt. Knip het op: eerst analyse, dan ontwerp, dan bouw, dan controle, en geef telkens de output van de vorige stap mee. Elke stap krijgt zo de volle aandacht, en jij kan tussendoor ingrijpen.
Vergelijk opties voor je kiest
Voor keuzes met gevolgen (hosting, database, betaalprovider) vraag je beter twee of drie opties met voor- en nadelen dan meteen ‘de beste’. Geef je criteria mee: budget van de klant, onderhoud, GDPR, wie het later beheert.
Schwach Welke hosting moet ik nemen voor de site van de garage?Stark Vergelijk drie hostingopties voor een statische site met een klein admin-gedeelte voor Garage Wauters. Criteria: max. 20 euro/maand, data in de EU, eenvoudig te beheren door mij alleen, automatische deploys vanaf GitHub. Tabel met voor- en nadelen, dan je advies.
Kapitel 6
Itereren en bijsturen
De eerste versie is zelden de laatste. Goed werken met AI betekent goed bijsturen: gerichte feedback, één ding tegelijk, en weten wanneer je beter opnieuw begint. Het gesprek is je werkbank, geen orakel.
Geef specifieke feedback
‘Niet goed’ helpt niemand. Zeg wat er mis is, waar, en hoe het wel moet. Wijs naar de regel, de knop of de zin. Hoe concreter je feedback, hoe minder het model de goede delen ook gaat ‘verbeteren’.
Schwach Dit ziet er niet uit, doe opnieuw.Stark De hero is te druk op mobiel. Hou de titel, maar zet de twee knoppen onder elkaar onder 640px, haal de achtergrondanimatie weg op mobiel en laat de rest van de pagina ongemoeid.
Eén wijziging tegelijk
Vraag je vijf aanpassingen tegelijk, dan weet je bij een probleem niet welke de boosdoener is. Werk in kleine stappen die je telkens controleert. Dat lijkt trager, maar het is de snelste weg naar iets dat werkt.
Zeg wat goed is, zodat het blijft
Benoem ook wat je wilt houden: ‘de kleuren en de tekst zijn goed, pas alleen de spacing aan’. Anders kan een herschrijving dingen wijzigen die je net goedgekeurd had.
Weet wanneer je opnieuw begint
Draait een gesprek in rondjes, of zit de context vol met mislukte pogingen, dan begin je beter fris. Neem mee wat je geleerd hebt: een korte samenvatting van de aanpak die werkte en de valkuilen die je wilt vermijden. Een propere nieuwe start verslaat vaak de twintigste correctie.
Laat het zichzelf controleren
Vraag na een antwoord: ‘controleer je antwoord tegen de oorspronkelijke vereisten en zeg wat ontbreekt’. Of geef het een concrete check: de build, een test, een linter. Een model dat zijn eigen werk kan toetsen, vangt veel van zijn eigen fouten op.
Bewaar wat werkt
Kreeg je met een bepaalde prompt een goed resultaat, bewaar hem dan. Een eigen map met beproefde prompts (voor offertes, DNS-verhuizen, vertalingen, reviews) is na een paar maanden goud waard. Daarover meer in hoofdstuk 12.
Kapitel 7
Werken met Claude Code: de sessie
Claude Code is een agent: hij leest je project, voert commando’s uit, bewerkt bestanden en controleert zijn werk. Dat vraagt een andere manier van werken dan chatten. Jij bent de projectleider die richting geeft, grenzen zet en nakijkt.
Leg je project vast in CLAUDE.md
Een CLAUDE.md in de root van je project wordt aan het begin van elke sessie ingeladen. Zet er de dingen in die altijd gelden: build- en testcommando’s, mappenstructuur, conventies, ‘doe nooit X’. Hou het kort en concreet (richtlijn: onder de 200 regels); met /init laat je een eerste versie genereren, en met @pad/naar/bestand importeer je andere bestanden.
Schwach Schrijf mooie code en let op kwaliteit.Stark # Bakkerij Marleen - Stack: Astro 5, Tailwind, TypeScript strict - Build: npm run build · Check: npx astro check - Talen: nl, fr, de, en. Nieuwe tekst altijd in alle vier (src/i18n) - Geen nieuwe dependencies zonder te vragen - Klantdata nooit in de repo; .env staat in .gitignore - Zie @docs/briefing.md voor de klantbriefing
Ken de lagen van je geheugen
Naast de project-CLAUDE.md (gedeeld via git) is er een persoonlijke ~/.claude/CLAUDE.md voor al je projecten, en een CLAUDE.local.md voor persoonlijke projectnotities die niet in git horen. Claude Code kan ook zelf notities bijhouden (auto memory). Het blijft context, geen afgedwongen regel: wat echt nooit mag, zet je in permissies of hooks.
Plan-modus voor alles wat groter is
In plan-modus leest Claude Code je project en stelt het een plan voor, maar bewerkt het niets tot jij goedkeurt. Je schakelt er in de terminal naartoe met Shift+Tab. Gebruik het voor nieuwe features, refactors en alles waar je eerst de aanpak wilt zien.
Kies bewust je permissiemodus
Claude Code heeft modi die bepalen wat zonder vragen mag: van alles laten bevestigen (handmatig), over bewerkingen automatisch toestaan, tot een automatische modus waarin een tweede model de acties nakijkt. Vrijer werken is sneller, maar je ziet minder. Op een klantproject met productiedata hou je het strak; de modus die alle controles overslaat, hoort alleen in een afgeschermde container.
Beheer je context actief
Een lange sessie vult het contextvenster en de kwaliteit zakt. Met /clear begin je met een leeg gesprek voor een nieuwe taak; met /compact vat je het gesprek samen om plaats te maken, eventueel met een instructie over wat belangrijk is. Met /context zie je hoe vol het zit. Vuistregel: nieuwe taak, nieuwe context.
Checkpoints en terugspoelen
Claude Code bewaart automatisch een checkpoint bij elke prompt. Met /rewind (of twee keer Esc bij een lege invoer) spoel je code, gesprek of beide terug. Let op: wijzigingen via shellcommando’s en edits van subagents worden niet altijd teruggezet. Het is een vangnet, geen vervanging voor git.
Geef het een manier om zichzelf te controleren
Het krachtigste wat je kan meegeven is een check: een test, een build, een linter, een screenshot om mee te vergelijken. Dan kan de agent zelf zien of het werkt en itereren tot het groen is. Zonder check moet jij elke fout zelf vinden.
Schwach Fix de bug in het reservatieformulier.Stark Het reservatieformulier aanvaardt een datum in het verleden. Schrijf eerst een test die dat aantoont (hij moet falen), fix dan de validatie, en draai npm test tot alles groen is. Pas geen andere tests aan om ze te laten slagen.
Kleine stappen, kleine commits
Laat Claude Code werken in stappen die je kan overzien, en commit na elke stap die werkt. Zo heb je altijd een veilig punt om naar terug te keren en blijft elke diff leesbaar. Vraag gerust om een commitboodschap, maar lees de diff zelf voor je commit.
Kapitel 8
Claude Code gevorderd
Als de basis zit, kan je Claude Code uitbreiden: gespecialiseerde subagents, herbruikbare skills, automatische hooks, externe tools via MCP en meerdere sessies naast elkaar. Krachtig, maar elk extra onderdeel is iets wat je moet begrijpen en onderhouden. Voeg toe wat een echt probleem oplost.
Subagents voor afgebakend zijwerk
Een subagent werkt in een eigen contextvenster en geeft alleen een samenvatting terug. Ideaal voor zoekwerk, logs doorspitten of een review, zodat je hoofdgesprek proper blijft. Je definieert ze als Markdown-bestand in .claude/agents/ (per project) of ~/.claude/agents/ (persoonlijk), met een beschrijving en eventueel beperkte tools.
Skills voor wat je steeds opnieuw uitlegt
Plak je telkens dezelfde checklist of werkwijze in het gesprek, maak er dan een skill van: een map in .claude/skills/ met een SKILL.md. Claude ziet alleen de beschrijving tot de skill nodig is, en roept hem zelf aan of jij doet het met /naam. Eigen slash-commando’s zijn intussen samengevoegd met skills; oude bestanden in .claude/commands/ blijven werken.
Hooks voor wat altijd moet gebeuren
Instructies in CLAUDE.md zijn advies; hooks zijn zeker. Een hook is een commando dat automatisch draait op een vast moment, bijvoorbeeld voor een tool gebruikt wordt (en het kan blokkeren) of na een bewerking (om te formatteren). Je stelt ze in via de settings-bestanden of /hooks. Gebruik ze voor formatteren, linten en het afschermen van gevoelige bestanden zoals .env.
MCP om je agent aan andere tools te koppelen
Via het Model Context Protocol (MCP) koppel je Claude Code aan externe systemen: een issue tracker, een database, documentatie, een browser. Elke koppeling geeft de agent meer bereik, dus ook meer risico. Koppel alleen servers die je vertrouwt, geef ze zo weinig rechten als nodig, en weet welke data erdoor gaat.
Headless en de Agent SDK voor automatisering
Claude Code kan ook zonder interactieve sessie draaien, bijvoorbeeld met claude -p in een script of een CI-pipeline, en via de Agent SDK bouw je eigen agents op dezelfde motor. Een automatische taak kan niets terugvragen, dus je prompt moet extra duidelijk zijn over wat succes is en wat er met het resultaat moet gebeuren.
Schwach Kijk de code na.Stark Controleer de wijzigingen van deze pull request op: hardgecodeerde sleutels, ontbrekende vertalingen in nl/fr/de/en, en console.log in productiecode. Antwoord met een lijst per bestand en regel. Geen bevindingen: antwoord alleen ‘OK’.
Worktrees voor parallel werk
Wil je twee taken tegelijk laten lopen in hetzelfde project, gebruik dan git worktrees: aparte werkkopieën op een eigen branch, zodat sessies elkaars bestanden niet overschrijven. Claude Code kan zo’n sessie zelf in een worktree starten. Je repo heeft daarvoor wel minstens één commit nodig.
Parallel helpt bij onafhankelijk werk, niet bij verweven werk
Meerdere agents tegelijk loont als taken los van elkaar staan: drie klantsites dezelfde footerfix geven, onderzoek in verschillende hoeken van een codebase. Bij verweven werk (dezelfde bestanden, beslissingen die op elkaar bouwen) krijg je conflicten en tegenstrijdige keuzes. Elke extra agent is ook een extra diff om na te kijken en verbruikt extra tokens.
Kapitel 9
Sessies plannen en overzicht houden
Een echt project bouw je niet in één sessie. Je bouwt het in een reeks sessies, en dan wordt overzicht het eigenlijke werk: wat is af, wat is beslist, wat komt nu. Wie dat op papier zet, kan elke sessie (en elke agent) zonder verlies laten verderwerken.
Eén bouwdocument per project
Schrijf per project een plan- of bouwdocument met doel, scope, stack, fases en per fase een duidelijk ‘klaar wanneer’. Dat document is de bron van waarheid voor jou én voor elke sessie. Verwijs ernaar vanuit CLAUDE.md, zodat het altijd bij de hand is.
Een statusregel bovenaan
Zet bovenaan je plan één regel die zegt waar je nu staat. Elke nieuwe sessie leest die eerst en weet meteen waar ze moet beginnen. Update hem op het einde van elke sessie; het kost tien seconden en bespaart je het hele ‘waar waren we?’-gesprek.
Sluit elke sessie af met een overdracht
Laat de agent op het einde een korte overdracht schrijven: wat is gedaan, wat staat open, welke beslissingen zijn genomen, wat de volgende stap is. Bewaar die in een sessielog in het project. De volgende sessie, of een collega, start dan vanaf die notitie in plaats van vanaf nul.
Schwach Ok bedankt, tot morgen.Stark Voor we stoppen: schrijf een overdracht onderaan docs/sessielog.md met (1) wat vandaag af is, (2) wat nog openstaat, (3) beslissingen en waarom, (4) de eerste stap voor de volgende sessie. Update ook de statusregel in docs/bouwplan.md.
Bouw bevestigingspunten in
Spreek af waar de agent moet stoppen en jouw akkoord vragen: na het plan, na elke fase, voor iets wat geld kost of extern zichtbaar is (deployen, mails versturen, DNS wijzigen). Zet dat expliciet in je bouwdocument. Autonomie binnen een fase, controle tussen de fases.
Lees de diff voor je commit
Elke sessie eindigt met een diff, en die lees jij. Niet vluchtig scrollen, maar kijken of elke wijziging bij de taak hoort. Vreemde bestanden, gewiste tests of ‘even opgeruimde’ code buiten de scope zijn signalen om te vragen waarom.
Eén sessie, één duidelijk doel
Begin elke sessie met één doel dat je in een zin kan zeggen. Komen er onderweg andere dingen bovendrijven, noteer ze in het plan voor later in plaats van ze er meteen bij te nemen. Zo blijft elke sessie afgerond en elke commit begrijpelijk.
Houd beslissingen bij, niet alleen taken
Over drie maanden weet je niet meer waarom je voor die betaalprovider of die mappenstructuur koos. Een kort lijstje beslissingen met de reden erbij voorkomt dat een volgende sessie (of jijzelf) het allemaal opnieuw in vraag stelt of per ongeluk terugdraait.
Kapitel 10
AI-code nakijken
Code die een AI schreef, is code die jij oplevert. De klant maakt geen onderscheid, en terecht. Kijk ze na zoals je de code van een snelle maar soms overmoedige collega nakijkt.
Begrijp het voor je het oplevert
Lever nooit code op die je niet kan uitleggen. Snap je een stuk niet, vraag dan uitleg, regel per regel als het moet. Als er morgen iets misloopt bij de klant, ben jij degene die het moet oplossen.
Tests zijn je beste reviewer
Laat tests schrijven voor het gedrag dat ertoe doet en draai ze zelf. Kijk ook de tests zelf na: een AI schrijft soms tests die alleen bevestigen wat de code al doet, of past een test aan tot hij slaagt. Een test die nooit kan falen, test niets.
Kijk extra goed naar veiligheid
Let op invoer van gebruikers (validatie, SQL- of HTML-injectie), authenticatie op admin-routes, rechten op bestanden en API-sleutels in de code. Vraag gerust een aparte security-review van de wijzigingen, maar neem het resultaat als startpunt, niet als garantie.
Schwach Is deze code veilig?Stark Review de admin-routes van deze site op beveiliging. Controleer specifiek: is elke route achter login, wordt invoer server-side gevalideerd, kan iemand via de upload andere bestanden overschrijven, lekken foutmeldingen interne info? Geef per bevinding het bestand, de ernst en een fix.
Plak nooit geheimen in een prompt
Wachtwoorden, API-sleutels, tokens en .env-bestanden horen niet in een chat. Gebruik placeholders en zet echte waarden in omgevingsvariabelen. Ben je toch per ongeluk een sleutel kwijtgeraakt in een gesprek of een commit: beschouw hem als gelekt en vervang hem.
Controleer dependencies en licenties
Een AI stelt soms pakketten voor die verouderd, onveilig of zelfs onbestaand zijn, en kwaadwillige partijen registreren soms net die verzonnen namen. Kijk elk nieuw pakket na: bestaat het, wordt het onderhouden, welke licentie heeft het? Ook voor gegenereerde teksten en afbeeldingen geldt: weet wat je mag gebruiken.
Wantrouw te veel ijver
Agents ‘verbeteren’ graag dingen waar je niet om vroeg, of lossen een probleem op door het te omzeilen (een check uitschakelen, een fout wegvangen zonder ze te behandelen). Vraag bij elke onverwachte wijziging waarom. Zet in je prompt dat het buiten de scope niets mag aanpassen.
Kapitel 11
Veiligheid en ethiek
Werken met AI raakt aan veiligheid, privacy en vertrouwen. Je werkt met data van klanten, je laat een agent dingen uitvoeren, en je klanten verdienen eerlijkheid over hoe hun project gemaakt wordt. Dit is geen rem, het is vakmanschap.
Ken prompt injection
Tekst die een model leest, kan instructies bevatten: een webpagina, een mail, een PDF, een issue op GitHub. Een agent die zulke inhoud verwerkt, kan erdoor misleid worden om iets te doen wat jij niet vroeg. Behandel alles wat van buiten komt als data, niet als opdracht, en zeg dat ook in je prompt.
Beperk wat een agent kan bij onbetrouwbare inhoud
Laat een agent die vreemde websites of mails leest niet tegelijk vrij commando’s uitvoeren, bestanden versturen of aan productie zitten. Gebruik strikte permissies, een afgeschermde omgeving en bevestiging voor alles met gevolgen. Hoe meer de agent kan, hoe voorzichtiger je moet zijn met wat hij leest.
Persoonsgegevens: eerst een grond, dan pas plakken
Klantenlijsten, reservaties, ledenbestanden en mails bevatten persoonsgegevens, en de GDPR geldt ook als je ze in een AI-tool plakt. Vraag je af of je een rechtsgrond hebt, of het zakelijke account en de voorwaarden van je tool dat toelaten, en of je het niet kan vermijden. Meestal kan het: anonimiseer, gebruik testdata of laat de structuur zien zonder de inhoud.
Schwach Hier is de ledenlijst van de voetbalclub (export.csv), zoek dubbele inschrijvingen.Stark Hier zijn de kolomnamen en drie verzonnen voorbeeldrijen van een ledenexport. Schrijf een script dat dubbele inschrijvingen vindt op basis van naam + geboortedatum. Ik draai het zelf lokaal op de echte data.
Wees transparant over AI
De Europese AI Act legt transparantieplichten op, bijvoorbeeld dat mensen moeten weten wanneer ze met een chatbot praten en dat bepaalde AI-gegenereerde inhoud herkenbaar moet zijn. Bouw je een chatbot of genereer je beelden voor een klant, hou daar rekening mee en kijk de actuele regels na. Twijfel je, vraag juridisch advies.
Wees eerlijk tegen je klanten
Zeg gewoon dat je met AI-tools werkt en hoe je de kwaliteit bewaakt. Klanten betalen voor jouw oordeel, jouw verantwoordelijkheid en het resultaat, niet voor het aantal uren dat je typte. Eerlijkheid daarover bouwt meer vertrouwen dan het verstoppen.
Jij blijft verantwoordelijk
Een AI kan geen verantwoordelijkheid dragen, jij wel. Wat je oplevert, verstuurt of publiceert, is van jou. Beslissingen die mensen raken (een prijs, een weigering, een juridische tekst) neem je zelf, met de AI als hulp en niet als beslisser.
Kapitel 12
Prompten voor klanten en teams
Wie goed leert prompten, kan dat ook doorgeven: aan collega’s in de gilde, aan klanten die zelf met AI willen werken, aan een team dat dezelfde kwaliteit wil halen. Dan wordt een losse prompt een gedeeld werkmiddel.
Bouw een promptbibliotheek
Verzamel prompts die bewezen werken in een gedeelde plek, met per prompt het doel, wanneer je hem gebruikt, en een voorbeeld van goede output. Versioneer ze zoals code. Zo hoeft niet iedereen het wiel opnieuw uit te vinden, en verbeteren prompts met elk gebruik.
Maak templates met duidelijke invulvelden
Een goede template laat zien wat de gebruiker moet invullen en wat vast blijft. Gebruik herkenbare placeholders, en zet bij elk veld een korte uitleg. Voor een klant die zelf nieuwsberichten schrijft, is een template veel veiliger dan een lege chat.
Leer niet-technische mensen de basis, niet de trucs
Een cafébaas of een boekhouder heeft niets aan ingewikkelde technieken. Leer hen drie dingen: zeg wat je wilt en voor wie, geef een voorbeeld, en controleer het resultaat. Laat hen oefenen met hun eigen echte taken, dan blijft het hangen.
Evalueer output systematisch
Werkt een prompt ‘goed’? Leg vast wat goed betekent (juist, volledig, juiste toon, juiste lengte) en test hem op een vaste set voorbeeldinvoer, ook moeilijke gevallen. Zo zie je of een aanpassing echt beter is, of alleen anders. Voor belangrijke toepassingen is zo’n kleine testset (eval) onmisbaar.
Schwach Ik heb de nieuwe prompt eens geprobeerd en het leek beter.Stark Testset: 15 echte klantvragen (geanonimiseerd), waarvan 5 moeilijke (klacht, dubbelzinnig, Frans). Criteria: juist antwoord, juiste toon, max. 100 woorden, verwijst door bij twijfel. Oude en nieuwe prompt allebei draaien, per vraag scoren, dan pas kiezen.
Spreek teamafspraken af
Zet in een team op papier wat wel en niet mag: welke tools, welke data nooit in een prompt, wie AI-code reviewt, hoe je AI-gebruik vermeldt naar klanten. Een gedeelde CLAUDE.md en gedeelde skills in de repo zorgen ervoor dat elke agent in het team dezelfde regels volgt.
Blijf leren, want de tools veranderen
Modellen en tools evolueren snel: wat vandaag een omweg vraagt, is morgen een ingebouwde functie. De principes in deze gids (duidelijk zijn, context geven, laten plannen, controleren) blijven. Lees de officiële documentatie bij elke grote update en deel wat je leert met de rest van de gilde.