De meeste mensen die AI gebruiken doen niet veel meer dan een zoekmachine met extra stappen. Vraag intypen, hopen dat er iets bruikbaars uitkomt, teleurgesteld zijn.
Het verschil tussen een AI die bruikbare output geeft en eentje die onzin produceert zit vrijwel nooit in welk model je kiest. Het zit in hoe je dat model aanstuurt. De instructies, de structuur, de context eromheen.
Het vakgebied heet officieel "prompt engineering", maar die term dekt de lading niet meer. In 2026 gaat het niet meer alleen om hoe je een vraag formuleert. Het gaat om context engineering: het complete systeem van informatie dat een model ontvangt. De prompt is daar nog maar een onderdeel van.
Hieronder: de technieken die er in de praktijk toe doen, met voorbeelden.
De basis die bijna iedereen verkeerd doet
Klinkt simpel, maar hier gaat het al mis bij 90% van de mensen: je moet specifiek zijn. Echt specifiek. Niet "schrijf iets over klanttevredenheid" maar exact vertellen wat je wilt, voor wie, in welk formaat, en hoe lang.
Er is een goede test hiervoor. Anthropic noemt het de "nieuwe medewerker"-test: geef je prompt aan iemand die net bij je bedrijf begint en nul context heeft. Zou die persoon precies weten wat ie moet doen? Nee? Dan weet het model het ook niet.
Schrijf iets over klanttevredenheid.
Schrijf een e-mail van max 150 woorden aan een klant die vorige week klaagde over een late levering. Bedank voor de feedback, bied excuses aan, en geef een eenmalige korting van 10% op de volgende bestelling mee. Toon: warm maar zakelijk. Onderteken met "Team [bedrijfsnaam]".
De eerste prompt is een open vraag. Het model kan alle kanten op. De tweede is een opdracht met formaat, lengte, doelgroep, toon en inhoud erin. Het model hoeft niet te gokken.
Mensen besteden uren aan het kiezen van het juiste AI-model, maar precies nul minuten aan het formuleren van een goede instructie. Terwijl dat tweede veel meer uitmaakt.
Paar vuistregels die we altijd meegeven: noem altijd het gewenste formaat. Geef beperkingen mee (lengte, toon, wat er niet in mag). Als de taak meerdere stappen heeft, nummer ze. En test je prompt door hem hardop voor te lezen -- als het raar klinkt, is ie te vaag.
Geef je prompts structuur
Zodra je iets complexers wilt dan een simpele vraag, moet je structuur aanbrengen. Gewoon alles in een lange alinea proppen werkt niet. Het model raakt in de war over wat de instructie is, wat de data is, en wat het gewenste resultaat is.
Wat wel werkt: behandel je prompt als een contract. Met duidelijke secties. Anthropic raadt aan om XML-tags te gebruiken om instructies, context en data te scheiden. Maar het basisprincipe werkt overal: maak expliciet waar elk onderdeel begint en eindigt.
Rol: Je bent een senior financieel analist
met 10 jaar ervaring in SaaS-bedrijven.
Instructie: Analyseer de onderstaande kwartaalcijfers.
Focus op drie dingen: omzetgroei, marges, en risico's.
Wees kritisch -- noem ook wat er niet goed gaat.
Context:
- Bedrijf: TechCorp B.V.
- Periode: Q4 2025
- Sector: B2B SaaS, 50-200 medewerkers
- Vorig kwartaal: 12% omzetgroei, 68% brutomarge
Data:
[Plak hier de kwartaalcijfers]
Gewenst formaat:
1. Samenvatting (max 200 woorden, geen bullet points)
2. Top 3 risico's (genummerd, elk max 2 zinnen)
3. Een concrete aanbeveling (1 zin)Vier blokken: wie het model is (rol), wat het moet doen (instructie), waarmee het werkt (context + data), en hoe het resultaat eruit moet zien (formaat).
Die roltoewijzing maakt overigens meer uit dan je zou verwachten. "Senior financieel analist met 10 jaar ervaring in SaaS" levert een ander antwoord op dan "financieel adviseur" of helemaal niks. Het model past woordkeuze, detailniveau en aannames aan op de rol.
En voor de techneuten: als je met API's werkt, zet de rol en vaste instructies in het system prompt. De variabele data (het document, de vraag, de klantgegevens) gaat in het user prompt. Zo scheid je configuratie van input en kun je dezelfde prompt hergebruiken voor verschillende inputs. Scheelt je een hoop copy-paste.
Laat zien wat je wilt (few-shot) en laat het model denken (chain-of-thought)
Er zijn taken waarbij je uitleg kunt geven tot je een ons weegt, maar het model het pas snapt als je het voordoet. Dat is few-shot prompting: je geeft een paar voorbeelden van wat je wilt, en het model leert het patroon.
We gebruiken dit veel bij classificatietaken. Stel je hebt inkomende support-tickets en je wilt ze automatisch routeren:
Classificeer elk support-ticket in een van deze
categorieen: Technisch, Factuur, Algemeen.
Ticket: "Ik kan niet inloggen sinds de update van
gisteren, ook niet na wachtwoord resetten."
Categorie: Technisch
Reden: Inlogprobleem gerelateerd aan software-update.
Ticket: "Ik heb twee keer betaald voor dezelfde maand,
graag een terugbetaling."
Categorie: Factuur
Reden: Dubbele betaling, terugbetaling nodig.
Ticket: "Kunnen jullie een demo inplannen voor ons team
van 15 personen?"
Categorie: Algemeen
Reden: Verkoopgerelateerde vraag, geen support-issue.
Ticket: "De export-functie geeft een leeg bestand als ik
meer dan 1000 rijen selecteer."
Categorie:Let op wat hier gebeurt: we geven niet alleen de categorie, maar ook de reden. Dat dwingt het model om te redeneren voordat het classificeert. En we dekken bewust drie verschillende typen af -- technisch, financieel en een edge case (sales-vraag in het support-kanaal). Die diversiteit in je voorbeelden is cruciaal. Als al je voorbeelden technisch zijn, gaat het model alles als technisch classificeren.
Dan chain-of-thought: het model expliciet laten redeneren voordat het een antwoord geeft. Bij complexe taken -- berekeningen, data-analyse, logische puzzels -- maakt dit een enorm verschil. In plaats van direct een antwoord te vragen, vraag je het model om eerst zijn redenering uit te schrijven.
Modellen zoals OpenAI o3 en Claude Opus met adaptive thinking doen chain-of-thought al intern. Ze redeneren achter de schermen zonder dat je dat hoeft te vragen. Als je bij deze modellen expliciet "denk stap voor stap" toevoegt, kan dat de performance juist verslechteren -- je dwingt het model in een rigide denkvolgorde terwijl het zelf een betere route had gevonden. OpenAI zegt het zelf: gebruik bij reasoning models simpelere prompts. Handmatige chain-of-thought is alleen voor standaard modellen (GPT-4o, Claude Sonnet) die niet zelf redeneren.
Van losse prompt naar pipeline
Tot nu toe hadden we het over individuele prompts. Maar in de praktijk wil je vaak iets dat uit meerdere stappen bestaat. Een document binnenkrijgen, analyseren, classificeren, en op basis daarvan iets doen. Dat kun je niet in een prompt proppen. Althans, dat kun je wel, maar het resultaat is bagger.
De oplossing heet prompt chaining. Simpel idee: je breekt een complexe taak op in stappen. De output van stap 1 is de input voor stap 2. Elke stap heeft z'n eigen prompt, z'n eigen validatie, en z'n eigen foutafhandeling.
Het meest gebruikte patroon is self-correction: genereren, reviewen, verfijnen. Stap 1 maakt een eerste versie. Stap 2 evalueert die tegen je criteria ("is het onder 200 woorden? klopt de toon? missen er punten?"). Stap 3 verbetert op basis van die evaluatie.
Een echt voorbeeld uit onze projecten: automatische factuurverwerking. De pipeline ziet er zo uit:
- Trigger: PDF komt binnen via e-mail
- Extractie: AI-model haalt leverancier, bedrag, datum, btw-bedrag en regels eruit (structured output als JSON)
- Validatie: Check tegen leverancierslijst -- kennen we deze leverancier? Klopt het btw-nummer? Past het bedrag bij het contract?
- Actie bij match: Concept-boeking aanmaken in het boekhoudsysteem
- Actie bij afwijking: Slack-notificatie naar de financiële afdeling met de factuur en de reden van afwijking
Als stap 2 een veld niet kan extraheren -- gebeurt regelmatig bij handgeschreven facturen of slechte scans -- gaat de factuur naar een handmatige wachtrij. Niet door naar stap 3. Geen halve boekingen, geen foute data in je systeem.
Belangrijk voor dit soort pipelines: structured output. Je wilt geen vrije tekst terug van het model -- je wilt JSON volgens een vast schema. Zowel OpenAI als Anthropic hebben inmiddels API's die het schema afdwingen. Het model kan dan niet anders dan valide JSON teruggeven. Dat scheelt je een berg aan foutafhandeling en maakt je pipeline een stuk betrouwbaarder.
Context engineering
Alles hierboven gaat over de prompt zelf. Maar de prompt is in 2026 nog maar een fractie van wat bepaalt hoe goed je AI-systeem werkt.
Context engineering gaat over alles wat het model ziet op het moment dat het een antwoord genereert. Het system prompt, de tools die het model kan gebruiken, de documenten die je hebt opgehaald, het geheugen uit eerdere gesprekken, de volledige gespreksgeschiedenis.
LangChain ondervroeg eind 2025 meer dan 1.300 professionals over hun AI-agents. 57% heeft agents in productie. Maar 32% noemt kwaliteit als het grootste obstakel -- en die problemen komen bijna nooit door het model. Ze komen doordat het model de verkeerde informatie krijgt, of informatie mist.
Wat context engineering in de praktijk betekent:
- RAG (Retrieval-Augmented Generation): In plaats van alles in je prompt te proppen, haal je op het moment van de vraag de relevante documenten op uit je kennisbank. Het model krijgt alleen te zien wat relevant is. Dat is niet alleen nauwkeuriger, het is ook goedkoper -- minder tokens, lagere kosten.
- Tool definitions: Je vertelt het model welke tools het tot z'n beschikking heeft. Zoeken in een database, een berekening uitvoeren, een API aanroepen. Het model beslist zelf wanneer het een tool inzet. Maar alleen als je het vertelt dat die tools bestaan.
- Geheugen: Informatie uit eerdere gesprekken bewaren. Zodat een klant niet elke keer opnieuw moet uitleggen wat z'n probleem is. Of zodat een assistent onthoudt dat deze klant vorige maand al drie keer heeft gebeld over hetzelfde.
- System prompts: De vaste instructies die bij elke interactie meegaan. Hier definieer je de persoonlijkheid, de regels, de domeinkennis. Dit is het fundament waar alles op draait.
Voorbeeld: een bedrijf bouwt een chatbot met GPT-4o. Aardige prompt, maar de bot zegt "sorry, dat weet ik niet" op productvragen. Logisch -- hij heeft geen toegang tot de productdocumentatie, geen link naar het CRM, en geen idee wie de klant is.
Voeg RAG toe met de kennisbank, tool access tot het CRM, en geheugen van het lopende gesprek, en je hebt een assistent die de klant bij naam kent, de bestelhistorie erbij pakt, en een retour kan inplannen. Zelfde model. Andere context.
Wat je er morgen mee kunt
- Doe de nieuwe-medewerker-test. Pak je meest gebruikte prompt en geef hem aan een collega zonder context. Snapt die niet wat ie moet doen? Herschrijven.
- Structureer je volgende complexe prompt. Vier blokken: rol, instructie, context/data, gewenst formaat. Gebruik het template hierboven als startpunt.
- Stel de context-vraag. Welke informatie mist dit model? Welke documenten zou het moeten kunnen inzien? Welke tools zou het moeten hebben?
Meer lezen:
- Anthropic -- Prompting Best Practices
- OpenAI -- Prompt Engineering Guide
- Lakera -- Prompt Engineering Guide (2026)
- Elastic -- Context Engineering vs. Prompt Engineering
- LangChain -- State of Agent Engineering 2025
Wil je dat je team daadwerkelijk iets met AI kan, in plaats van er af en toe mee te spelen? Wij trainen teams zodat ze zelf betere resultaten halen, sneller werken, en weten wat ze doen. Zonder dat je daarvoor je halve IT-afdeling nodig hebt. Plan een kennismaking in en we kijken waar de meeste winst zit.
