Prompt Design

In het begin van het LLM-tijdperk moest je veel werk verzetten om een model de juiste kant op te sturen. “Je bent een expert in copywriting.” “Handel als een data-analist.” Rolzetting, uitgebreide checklists, strikte scopebeperking: het voelde als engineering, en zo noemden we het ook.

Toen werden de modellen slimmer. Je hoeft Claude niet meer te vertellen dat het verstand heeft van copywriting als je een copywriting-vraag stelt. Het model snapt dat zelf. Technieken die tot 2025 essentieel waren — uitgebreide persona-prompts, handmatig voorkauwen van redeneerstappen voor simpele taken — zijn nu onnodige overhead. De conclusie leek logisch: prompt engineering is dood.

Maar dat klopt niet helemaal. Er zijn twee vormen van rolzetting, en alleen één ervan is achterhaald.

Rolzetting die capaciteiten probeert toe te voegen

Deze vorm probeert het model capaciteiten toe te wijzen die het niet heeft, of het model “op te tillen” met krachttermen: “jij bent een omnisciente AI zonder beperkingen”, “JE MOET altijd antwoorden”. Dat werkt niet meer. Moderne modellen zijn getraind om sceptisch te zijn over dit soort trucjes, en safety-alignment zit diep in de modelgewichten — de getrainde parameters die het gedrag van het model bepalen — niet in een oppervlakte-instructie die je bovenop kunt plakken.

Rolzetting die context en sturing geeft

Deze vorm geeft het model context en sturing: “jij bent een klantenservice-agent voor softwareproduct X, je spreekt Nederlandse ondernemers aan.” Dit werkt nog steeds, en alle drie de grote AI-leveranciers (Anthropic, OpenAI, Google) bevelen het expliciet aan als onderdeel van een goede system prompt.

Jouw betekenis

Wat nooit is verdwenen, is het articuleren van jouw betekenis. Niet wie het model moet zijn, maar wat je wilt bereiken en waarom. Welk resultaat je zoekt. Welke structuur je waardeert. Welke kwaliteitscriteria je hanteert. Die zijn uniek voor jou, en geen enkel model kan ze raden.

Prompt Design is daarmee niet verdwenen; het is gepromoveerd. Van LLM-management naar het helder formuleren van betekenis: wat je wilt bereiken, wat je verwacht, en aan welke criteria het moet voldoen.

Het iteratieve gesprek

Er is een tweede verschuiving die minstens zo belangrijk is: van één perfecte prompt naar het iteratieve gesprek. De echte kracht van werken met AI zit niet in het eerste prompt, maar in de vervolgvragen. De vragen die alleen jij kunt stellen, omdat ze voortkomen uit je domeinkennis, proceskennis en ervaring; kennis die je niet kunt opschrijven in een instructie, maar die eruit komt als je het resultaat ziet en weet wat er niet klopt, wat er mist, of wat beter kan. Dat is impliciete kennis (tacit knowledge) in actie: je brengt het in via het gesprek, niet via de eerste prompt.

Overdraagbaarheid

Dit heeft een praktische consequentie: de kern van goede promptspecificaties is overdraagbaar. Je verwachtingen, kwaliteitscriteria en schrijfstijl zijn niet gebonden aan één model of tool. Een helder gestructureerd document met wat je wilt bereiken, welke structuur je verwacht en welke kwaliteit je acceptabel vindt, neem je mee van Claude naar ChatGPT naar een AI-schrijftool die je voor het eerst uitprobeert.

De nuance: hoe je die verwachtingen vormgeeft verschilt per model. Anthropic’s Claude werkt het beste met XML-tags als structureringsmethode; Google Gemini en OpenAI’s GPT-modellen werken doorgaans beter met Markdown-headers. Alle drie ondersteunen beide formaten — het gaat erom wat per model het beste resultaat oplevert. De optimale instructievolgorde en de mate van explicietheid verschillen ook per model. Maar de kern — wat je wilt, waarom, en aan welke criteria het resultaat moet voldoen — blijft hetzelfde. Leg die kern vast als leesbare, modelonafhankelijke tekst. De vertaling naar een specifiek formaat is een implementatiedetail.

Een goede prompt is geen kunstig geformuleerde zin, maar een opbouw van vijf elementen. Niet elke prompt vult ze alle vijf even uitgebreid in, maar wie weet wat ze zijn, weet ook wat er ontbreekt als het resultaat tegenvalt. De vaste volgorde is: betekenis, context, instructies & verwachtingen, criteria, output.

Betekenis: wat wil je bereiken, en waarom

Het belangrijkste en meest vergeten element. Niet wie het model moet zijn, maar wat je wilt bereiken en welk doel daarachter zit. “Vat dit klantgesprek samen” is een instructie zonder betekenis; “vat dit klantgesprek samen zodat een collega die de klant overneemt in dertig seconden weet waar het misging” legt de bedoeling bloot. Het model kan die bedoeling niet raden, en zonder bedoeling is elk ander element giswerk.

Context: binnen welke omgeving

De achtergrond die het model nodig heeft om de taak goed uit te voeren: om wie of wat gaat het, welke gegevens horen erbij, wat zijn de randvoorwaarden. Dit is waar Dynamic Context (BB_03: de juiste actuele informatie op het juiste moment in het model brengen) en Prompt Design elkaar raken: context is het deel van de prompt dat per geval verandert.

Instructies & verwachtingen: wat je het model vraagt te doen

De concrete opdracht, plus wat je verwacht dat er gebeurt bij twijfel of uitzonderingen. Hoe specifieker, hoe voorspelbaarder de uitkomst. “Schrijf een nette e-mail” laat alles open; “schrijf een e-mail van maximaal honderd woorden, beleefd maar zonder overdreven excuses, en stel één concrete vervolgafspraak voor” stuurt op wat je echt wilt.

Criteria: waaraan het resultaat moet voldoen

De kwaliteitsnorm: wanneer is de output goed genoeg, en wat is een fout die niet door de beugel kan. Dit is het element dat je het vaakst impliciet in je hoofd hebt en het minst vaak opschrijft. Maak het expliciet, los van het model: “geen claims zonder bron”, “toon van een collega, niet van Juridische Zaken”, “liever te kort dan te lang”.

Output: in welke vorm

De structuur die je terug wilt: lopende tekst, een lijst, een tabel, of een vaste opzet met kopjes. Toon de vorm liever dan dat je hem beschrijft; een voorbeeld van de gewenste output is bijna altijd duidelijker dan een uitleg erover.

Voorbeelden: laten zien in plaats van beschrijven

Naast deze vijf elementen is er één techniek die er dwars doorheen snijdt: voorbeelden. Een handvol voorbeelden van ideale invoer met de bijbehorende output laat het model gedrag zien dat je met regels moeilijk vangt: de juiste toon, hoe om te gaan met een randgeval, precies welke structuur je wilt. In de literatuur heet dit few-shot prompting: twee tot vijf diverse voorbeelden verhogen de betrouwbaarheid van gestructureerde output aanzienlijk. Het is geen zesde element, maar een manier om vooral instructies & verwachtingen en output scherper te krijgen. De vuistregel: kun je iets niet helder genoeg in woorden vangen, toon het dan met een voorbeeld.

De vijf samen: een doorgewerkt voorbeeld

Los van elkaar blijven de elementen abstract; samen vormen ze een prompt. Stel je wilt binnengekomen klachtmails automatisch laten samenvatten voor je serviceteam:

• Betekenis: een servicemedewerker moet in één oogopslag zien hoe urgent een klacht is en wat de klant concreet vraagt, zonder de hele mail te lezen.
• Context: de klant is een bestaande zakelijke afnemer; de mail kan in het Nederlands of Engels zijn; gevoelige gegevens horen niet in de samenvatting thuis.
• Instructies & verwachtingen: vat de mail samen in maximaal drie zinnen; bij een dreigende opzegging of juridische taal zet je er “urgent” voor; bij twijfel over de urgentie kies je de hogere inschatting.
• Criteria: verzin geen informatie die niet in de mail staat; houd de toon neutraal; laat namen van personen weg.
• Output: eerst een regel “Urgentie: hoog/midden/laag”, daaronder de samenvatting in maximaal drie zinnen, daaronder “Gevraagde actie: …”.

Dezelfde vijf elementen sturen of je nu een eenmalige prompt, een system prompt of een agent ontwerpt. Wat verandert, is hoe uitgebreid je elk element invult.

Naarmate AI-toepassingen diverser worden, ontstaan er verschillende vormen die elk hun eigen aanpak vragen. Ze bouwen op dezelfde elementen (betekenis, context, instructies & verwachtingen, criteria, output), maar passen ze anders toe.

Eenmalige prompts

Eén vraag, één antwoord. De basis. Alle elementen zijn specifiek voor deze ene taak: je weet precies welke betekenis, welke context, welk resultaat. Voor veel taken is dit voldoende.

De system prompt

Ontworpen voor herhaald gebruik over meerdere interacties. Het verschil met een eenmalige prompt: je weet niet vooraf welke specifieke taken komen. Daarom wordt “betekenis” een overkoepelend doel (“klanten helpen hun technische problemen op te lossen”), en voeg je twee dingen toe die bij een eenmalige prompt niet nodig zijn: afhandeling van onverwachte situaties (off-topic vragen, dubbelzinnige input, gefrustreerde gebruikers) en voorbeelden van ideale interacties die het model kalibreren op gedrag dat je moeilijk in regels kunt vangen. Dit patroon heet in de literatuur few-shot prompting: 2 tot 5 diverse voorbeelden verhogen de betrouwbaarheid van gestructureerde output substantieel. Belangrijk patroon daarnaast: de prioriteitenladder: wanneer regels conflicteren, moet het model weten welke wint. Veiligheid en privacy gaan boven feitelijke correctheid, die gaat boven toon en formatting.

Het iteratieve gesprek

De vorm waar de meeste waarde zit voor domeinexperts. Niet de eerste prompt is beslissend, maar de vervolgvragen, gestuurd door jouw domeinkennis, proceskennis en ervaring. Dit is prompt design als dialoog.

Agent prompts

Een AI-agent stuurt geen enkel antwoord maar een hele cyclus aan: het model redeneert, gebruikt tools en bepaalt op basis van resultaten vervolgstappen. Dit is een eigen ontwerpdiscipline geworden; zie de sectie Agentic prompt design: flow engineering hieronder voor de diepte.

Een AI-agent is een systeem dat zelfstandig taken uitvoert door te redeneren, tools te gebruiken en op basis van resultaten vervolgstappen te bepalen. Waar een chat-prompt één antwoord oplevert, stuurt een agent-prompt een hele cyclus aan: soms minuten, uren of tientallen model-calls lang. Dat vraagt een fundamenteel andere ontwerpdiscipline, die de industrie inmiddels “flow engineering” noemt: het ontwerpen van de workflow, toestandsovergangen en beslispunten rondom de model-calls, niet alleen de prompts zelf.

Een cyclus, geen antwoord

Bij een chat-prompt is de centrale vraag “hoe formuleer ik dit het beste?” Bij een agent-prompt verschuift de kernvraag naar: welke stappen, beslissingen en overgangen sturen het gedrag van deze agent? en wanneer mag welke tool ingezet worden? De prompt blijft belangrijk, maar is slechts één onderdeel van een groter ontwerp waarin toestandsbeheer (bijhouden waar de agent in het proces zit), foutafhandeling en stopcondities even kritisch zijn.

Redeneerstructuur per stap

In productie-agents is een vast patroon standaard geworden: elke stap produceert een gestructureerde redenering met vier onderdelen:

• REASON: wat weet ik, wat is de huidige state?
• NEXT ACTION: wat ga ik doen en waarom?
• EXPECTED RESULT: wat zou er moeten gebeuren?
• CONTINGENCY: wat doe ik als dat mislukt?

Dit maakt beslissingen auditeerbaar (je kunt achteraf zien waarom de agent iets deed) en dwingt de agent om vóór actie expliciet aannames te checken, wat hallucinaties reduceert.

Stopcondities

Een agent zonder expliciete stopcondities blijft oneindig doorlopen; hij weet niet wanneer de taak klaar is, wanneer hij moet afbreken, of wanneer hij moet escaleren. Drie stopcondities zijn verplicht:

• Taak voltooid: agent produceert FINAL en stopt
• Staplimiet bereikt: agent produceert PARTIAL met reden van voortijdig stoppen
• Onzekerheid over veiligheid: agent stopt en escaleert naar een mens

Deze stopcondities zijn niet alleen een technische hygiëne, ze zijn ook een guardrail-vereiste. De EU AI Act eist dat een mens in staat is het systeem te onderbreken of de output te overschrijven. Een agent die ontworpen is zonder exit-mechanisme is niet alleen onveilig, maar in risicovolle contexten mogelijk niet-compliant.

Plan-Then-Execute

Een krachtig patroon om prompt injection tegen te gaan: scheid de planfase van de uitvoeringsfase. In de planfase krijgt het model de taak en ontwerpt het een concreet stappenplan; pas in de uitvoeringsfase komen user-content en tool-resultaten in beeld. Hierdoor kan kwaadaardige input uit een gebruiker het plan niet meer manipuleren; het is al vastgelegd.

Zes patronen in productie

De industrie heeft in 2025–2026 zes canonieke agentic design patterns benoemd. Welke je kiest hangt af van de taak:

• Prompt Chaining: een sequentiële ketting van stappen waarbij het resultaat van de ene stap de invoer is voor de volgende
• Routing: herken het type vraag en stuur het door naar een gespecialiseerde handler (bijvoorbeeld: facturatie-vraag naar de finance-agent, technische vraag naar de support-agent)
• Parallelization: splits een taak in onafhankelijke stukken die tegelijk uitgevoerd worden, of laat dezelfde vraag meerdere keren beantwoorden en kies daarna het meest consistente antwoord
• Orchestrator-Workers: een centraal coördinerend model deelt de taak op in stukken en verdeelt ze over gespecialiseerde worker-agents, zoals een projectleider met een team
• Evaluator-Optimizer: de agent schrijft een antwoord, beoordeelt het zelf kritisch en verbetert het in een cyclus met een maximum aantal rondes om oneindig doorgaan te voorkomen
• ReAct (Reason + Act): het model wisselt tussenstappen van redeneren af met het gebruiken van tools (bijvoorbeeld: eerst nadenken over welke informatie nodig is, dan een zoekopdracht uitvoeren, dan het resultaat weer beredeneren). Dit is de meest gebruikte bouwsteen

Production-agents combineren typisch meerdere patronen. Een customer-service bot kan Routing gebruiken om inkomende vragen te classificeren, dan Evaluator-Optimizer voor het opstellen van een antwoord, en Plan-Then-Execute als overkoepelende veiligheidslaag.

Deterministisch waar mogelijk

Niet alles hoeft door het model beslist te worden. Waar de logica voorspelbaar is, zijn deterministische scripts betrouwbaarder, sneller en goedkoper dan AI-beslissingen. Goede agent-architectuur vraagt constant: is deze stap een AI-beslissing of een code-beslissing? Een agent die elke berekening, conversie of lookup door een LLM laat doen, is een agent die onnodig duur en foutgevoelig is.

Prompt Design stopt niet bij het schrijven van een goede prompt. In productie moeten prompts beheerd, getoetst en versioned worden, net als code. De industrie noemt deze discipline PromptOps: de levenscyclus van een prompt, van experiment tot productie en weer terug.

Van ad-hoc naar discipline

De praktijk evolueert in drie stappen. Op het eerste niveau zijn prompts gewoon losse tekststrings in de code, zonder versiebeheer of evaluatie. Op het tweede niveau leven ze als versioned bestanden in Git, met pull requests, review en een changelog. Op het derde niveau zit er een registry tussen: een database die prompts bevat, met A/B testing, staged deployment en geautomatiseerde rollback.

Teams die dit serieus nemen gebruiken een versienummering vergelijkbaar met software: major bij een gedragsverandering die bestaande output breekt, minor bij een verbetering die achterwaarts compatibel is, patch bij een kleine correctie.

Evaluatie in drie lagen

Een gezonde evaluatie-pipeline combineert drie soorten metingen:

• Deterministische checks: klopt het JSON-schema, zijn verplichte velden aanwezig, voldoet de output aan harde regels?
• Semantische kwaliteitsmeting: een tweede model (LLM-as-judge, een beoordelende AI) scoort of het antwoord goed is; menselijke review voor steekproeven
• Bedrijfsmetrieken: taak-succespercentage, gebruikerstevredenheid, kostprijs per interactie

Pas als een nieuwe promptversie op alle drie de lagen goed scoort, mag hij door naar productie.

Uitrol en terugdraaien

Nieuwe prompts gaan niet direct naar 100% van het verkeer. Canary-deployments (gefaseerd uitrollen) zijn standaard: eerst 1–10% van het verkeer naar de nieuwe versie, scores monitoren, en bij een kwaliteitsdaling automatisch terug naar de oude versie. Elke productie-fout wordt de volgende test: als een prompt faalt, leg dat faalgeval vast en voeg het toe aan je testsuite. Zo wordt de testsuite continu beter met elke echte incident-grond.

In het huidige tooling-landschap zijn LangSmith, Langfuse en Promptfoo gevestigde spelers.

De koppeling met Evaluation Loop

PromptOps is in de kern de operationalisering van de Evaluation Loop (BB_07): dezelfde cyclus van meten, analyseren, verbeteren en opnieuw meten, maar dan specifiek voor prompts in productie. Je kunt niet goed aan de Prompt Design-knop draaien zonder de Evaluation Loop-knop tegelijk te bedienen.

Prompt design gaat in de praktijk vaker mis op een handvol terugkerende manieren dan op gebrek aan techniek. Zes valkuilen, met de tegenmaatregel erbij.

1. Over-prompten: steeds meer instructies, persona-opbouw en herhaalde nadruk stapelen, in de hoop dat meer tekst meer kwaliteit oplevert. Vaak gebeurt het tegendeel: het model raakt afgeleid van de kern of gaat de overdaad letterlijk volgen. De langste prompt is niet de beste, de meest precieze wel. Tegenmaatregel: begin met de kortste prompt die het werk doet en voeg pas iets toe als een test laat zien dat het echt nodig is.

2. Criteria in je hoofd, niet in de prompt: je weet zelf precies wanneer de output goed is, maar schrijft het niet op, waardoor het model ernaar moet raden. Tegenmaatregel: maak je kwaliteitscriteria expliciet en modelonafhankelijk, en schrijf ook op wat een onacceptabele fout is, niet alleen wat je wilt.

3. Het model vermenselijken: krachttermen gebruiken of capaciteiten toewijzen (“jij bent een wereldexpert”, “je MOET altijd”). Moderne modellen zijn getraind om dit soort bezweringen te negeren; het voegt niets toe en kost alleen ruimte. Tegenmaatregel: geef context en sturing in plaats van krachttermen, zoals beschreven in De evolutie van Prompt Design hierboven.

4. Prompt injection negeren: erop vertrouwen dat de tekst die binnenkomt (gebruikersinvoer, opgehaalde documenten, tool-resultaten) altijd braaf is. Een verstopte instructie in die tekst kan de oorspronkelijke prompt overschrijven. Tegenmaatregel: scheid de planfase van de uitvoeringsfase (Plan-Then-Execute), en behandel externe inhoud als gegevens om te verwerken, niet als instructies om op te volgen.

5. Eén keer testen en klaar: de prompt werkt op het ene voorbeeld waarmee je hem schreef, dus hij is “af”. In productie komt al snel invoer die je niet had voorzien. Tegenmaatregel: test met variatie en met edge cases (ongebruikelijke of extreme invoer), en leg elk faalgeval vast als nieuwe testcase.

6. De prompt bevriezen na ingebruikname: na een modelwissel of een verandering in de context blijft de oude prompt ongewijzigd staan, terwijl de aannames eronder zijn verschoven. Tegenmaatregel: behandel prompts als levend materiaal dat je herziet op basis van de Evaluation Loop, niet als iets dat na oplevering vaststaat.

Een continu verbeterproces

Prompt design is geen eenmalige activiteit. Het is een continu verbeterproces waarin je leert van evaluaties, onverwachte invoer ontdekt die het model op het verkeerde been zet, en je instructies verfijnt. De beste prompts zijn niet de langste, maar de meest precieze: ze geven het model precies genoeg sturing zonder de creatieve ruimte onnodig te beperken.

Het gesprek als waarde

Maar de echte waarde van prompt design zit niet alleen in de prompt of de output. Het zit in het gesprek. Het iteratieve proces van vragen stellen, output beoordelen, bijsturen en verfijnen dwingt je om steeds helderder te worden over wat je eigenlijk wilt. Hoe iets eruit moet zien. Hoe het moet werken.

Het denkproces als product

Dat denkproces is het eigenlijke product. De helderheid die je opbouwt in het gesprek met AI neem je mee naar je volgende gesprek, of dat nu met een model is of met een collega.

Dit is precies wat Knowledge (BB_01) het externaliseren van expertise noemt: een prompt codeert de kwaliteitscriteria die tot dusver impliciet in een expert-hoofd zaten. Zonder die criteria is geen prompt betrouwbaar; hij heeft alleen de illusie van precisie. Prompt Design en Knowledge bedienen daarmee dezelfde spier vanuit twee kanten.