Prompt engineering heeft de voorbije jaren een rare reputatie opgebouwd. Eerst was het “spreek in magische spreuken tegen je chatbot”, daarna “dit is een jobtitel”, en vervolgens “het is dood”. Het oude beeld van prompt engineering verdwijnt inderdaad, maar het werk zelf niet. Het verschuift van slimme zinnen schrijven naar betrouwbare AI-systemen bouwen.
Waarom “prompt engineering was tijdelijk” tegelijk juist en fout was
In 2023 ging prompt engineering vooral over herhalen wat je wil, voorbeelden toevoegen, formats afdwingen, of overal “think step by step” bijzetten. Dat soort trucjes wordt minder belangrijk. Moderne modellen begrijpen veel beter de intentie uit gewone taal.
Maar die verbetering maakt prompt engineering niet overbodig. Integendeel. Zodra je van “geef antwoord” naar “voer werk uit” gaat, stijgt de inzet. Een misverstand is niet langer een slechte alinea tekst. Het kan een verkeerd ticket zijn, een bericht naar de verkeerde klant, of een wijziging in een database die je later mag uitzoeken.
casual prompting wordt eenvoudiger, maar production prompting wordt belangrijker.
Prompt engineering vandaag: drie verschuivingen die je moet snappen
Vandaag draait prompt engineering vooral om drie domeinen:
- Context engineering
- Tool- en workflow-instructies
- Beheersing (testen, versiebeheer, monitoring, rollback)
Dat is geen semantische discussie. Het is het verschil tussen een demo en iets dat je durft loslaten op echte processen.
1) Context engineering: de juiste info, in de juiste vorm, op het juiste moment
Een model kan alleen goed antwoorden met het materiaal dat je ervoor zet. Vaak is het moeilijke niet “kan het model redeneren?”, maar “redeneert het over het juiste materiaal?”.
Context engineering is dus het ontwerpen van:
- Welke bronnen je ophaalt (documenten, CRM-data, policies, e-mails, tickets)
- Hoe je selecteert (relevantie, recency, autoriteit)
- Hoe je presenteert (samenvatting, citaten, tabellen, JSON, snippets)
- Wat je weglaat (ruis, irrelevante threads)
Voorbeeld: support-assistent met kennisbank
Stel: je wil een AI-assistent die supporttickets beantwoordt. De oude aanpak is: “schrijf een prompt als ‘beantwoord dit ticket vriendelijk’”. De moderne aanpak is: voer gecontroleerde context aan en maak “geen info” een geldige uitkomst in plaats van een hallucinatierisico.
Slechte context:
Beantwoord dit ticket. Gebruik de kennisbank.Betere context engineering:
Rol: je bent een support agent. Doel: schrijf een antwoord dat correct is volgens onze knowledge base.
Context die je mag gebruiken:
- Ticket: {ticket_tekst}
- Product: {productnaam}
- Relevante KB-artikels (met bron-id):
1) {kb_snippet_1}
2) {kb_snippet_2}
Regels:
- Als de KB geen antwoord bevat: zeg dat expliciet en stel 2 gerichte vragen.
- Citeer altijd het bron-id bij technische claims.
- Geen aannames over accountstatus of contracten.
Output:
- Onderwerp
- Antwoordmail
- Follow-up vragen (indien nodig) Waarom dit werkt: je dwingt af dat het model redeneert op de juiste bronnen en je bouwt guardrails in rond onzekerheid. Dat is context engineering in de praktijk.
2) Tool- en workflow-instructies: als AI acties mag nemen, moet je grenzen ontwerpen
Prompt engineering gaat vandaag ook over tool design. Zodra een model functies kan oproepen, bestanden kan doorzoeken, databases kan queryen of berichten kan sturen, moet je het leren wanneer welke tool mag en wat er eerst geverifieerd moet worden.
Dat lijkt op product- en systems engineering, maar het komt in de praktijk neer op instructies, guardrails en beslissingsregels rond gedrag.
Voorbeeld: AI die tickets kan aanmaken en klanten kan mailen
Je bouwt een agent die een ticket classificeert, info opzoekt, een voorstelmail opstelt en eventueel een proces start. Dan moet je expliciet maken:
- Welke tool heeft voorrang (bijvoorbeeld KB eerst, CRM daarna, pas dan mail)
- Wat is high risk (wijzigingen met externe impact)
- Wanneer bevestiging verplicht is (voor je iets verstuurt of data wijzigt)
- Wat te doen bij tegenstrijdige bronnen (stoppen, samenvatten, vraag stellen)
Praktische prompt-structuur voor tools:
Beslissingsregels:
- Als actie externe impact heeft (mail sturen, status wijzigen, refund starten): vraag expliciete bevestiging.
- Als bronnen conflicteren: stop, vat conflict samen, stel 1 vraag.
- Gebruik CRM-data enkel voor accountvelden, nooit voor technische troubleshooting.
- Gebruik KB enkel als bron voor procedures en technische stappen.
Tool usage:
- search_kb(query): gebruik altijd eerst
- get_crm(customer_id): alleen na gevonden customer_id
- draft_email(content): ok
- send_email(draft_id): verboden zonder “CONFIRM_SEND”
Dit is het punt: je bent niet bezig met “mooie prompts”. Je bent bezig met operationele veiligheid.
3) Versiebeheer en monitoring: PromptOps is niet optioneel
Als prompts deel worden van productiegedrag, moet je ze behandelen zoals code: testcases, inzicht in wijzigingen, en rollback als een update gedrag breekt. Er is nood aan test cases, checks, monitoring, versioning en rollback.
In die richting hoor je ook de term PromptOps: een systematische aanpak voor promptbeheer op schaal, inclusief versiecontrole en monitoring.
prompts zijn geen tekstjes, maar specificaties van gedrag.
Een handige checklist voor productiegebruik:
- Doel: wat is succes, hoe ziet een goede output eruit?
- Context: welke bronnen zijn toegestaan, welke zijn verboden?
- Grenzen: wat mag het systeem nooit doen zonder bevestiging?
- Output contract: format, lengte, taal, structuur.
- Escalatie: wanneer stoppen en vragen stellen?
Een praktisch voorbeeld
Opdracht: “schrijf een tekst” versus “werk in een proces”
Casual prompt (prima voor eenmalig gebruik):
Schrijf een vriendelijke mail om een afspraak te verzetten.Production prompt (voor een agent in je CRM):
Doel: verzet afspraak volgens regels.
Context:
- Afspraak: {datum, klant, type}
- Beschikbaarheid: {slots}
- Policy: {annulatievoorwaarden}
Regels:
- Bied 3 nieuwe opties aan binnen 10 werkdagen.
- Als klant VIP = true: bied ook optie buiten 10 werkdagen.
- Herhaal geen gevoelige info.
- Verstuur geen mail zonder expliciete bevestiging.
Output:
- conceptmail
- korte checklist van policy compliance
- vraag om confirmatie: "CONFIRM_SEND" Je voelt meteen: dit is geen copywriting, dit is systeemgedrag ontwerpen.
Prompt Engineering is niet “dood” maar “volwassen”
Je ziet regelmatig koppen die stellen dat prompt engineering “dood” is, of dat modellen hun prompts zelf gaan optimaliseren. Er is debat en onderzoek in die richting, maar zelfs dan blijft er werk: iemand moet nog altijd bepalen wat het doel is, welke context mag, welke acties veilig zijn, en hoe je afwijkingen detecteert.
Telkens modellen beter worden, geven we ze meer context, meer tools, meer verantwoordelijkheid en vager werk. Het model verbetert, maar het systeem errond wordt ambitieuzer.