Prompt Engineering

Wat is Prompt Engineering?

Prompt engineering is de praktijk van het ontwerpen van de tekst gestuurd naar een AI-model, inclusief instructies, voorbeelden, beperkingen, en outputformaat, zodat het model betrouwbaar het resultaat produceert dat je wilt. Het behandelt de prompt als een geëngineerd artefact, iets doelbewust geschreven, tegen gevallen getest, en geversioneerd in broncode, in plaats van een vraag casual getypt in een chatvak. Het veld is groter dan het van buiten lijkt: The Prompt Report, een survey van Schulhoff et al. uit 2024, catalogiseert 58 onderscheiden tekstgebaseerde promptingtechnieken plus 40 meer voor andere modaliteiten [1].

De belangrijkste punten

• De kernvaardigheid is specificatie: de meeste slechte outputs zijn te herleiden tot instructies die nooit zeiden hoe goed eruitziet, niet tot modelzwakte.
• De werkpaardtechnieken zijn stabiel en weinig: duidelijke instructies, relevante voorbeelden, expliciete outputformaten, en delimiters die instructies scheiden van data.
• In productie gedragen prompts zich als code. Ze leven in versiebeheer, draaien tegen evalsuites, en regresseren wanneer iemand ze onvoorzichtig bewerkt.
• De discipline versmalde in plaats van te sterven. Model-truc-bezweringen verouderden; precieze systeemprompts en toolbeschrijvingen schrijven doet er meer toe dan ooit.

Hoe het werkt

Taalmodellen volgen instructies, en de kwaliteit van het volgen volgt de kwaliteit van het instrueren. Een werkende prompt stelt meestal een handvol delen samen: een rol- of taakframing, de concrete instructies, beperkingen op wat te vermijden, de inputdata duidelijk afgebakend zodat het model het niet kan verwarren met de instructies, en een specificatie van outputvorm. Elk deel verdient zijn plek door een klasse mislukking af te sluiten. Delimiters beschermen tegen verdwaalde tekst die als commando's gelezen wordt, wat de onschuldige neef is van prompt injection. Expliciete formatspecs, of structured outputs afgedwongen op API-niveau, stoppen het model met JSON in vriendelijk proza wikkelen.

Wanneer instructies alleen tekortschieten, dragen voorbeelden de last. Het model twee of drie uitgewerkte input-output-paren tonen, de techniek bekend als few-shot prompting, communiceert formaat en oordeel betrouwbaarder dan ze beschrijven, want het model imiteert patronen beter dan het abstracties gehoorzaamt. Voor taken met redeneerdiepte helpt het model vragen door het probleem te werken voor het antwoordt nog steeds op non-reasoning-modellen, hoewel reasoning-modellen uit het 2026-tijdperk veel van dat overwegen intern behandelen zonder dat het gezegd wordt.

Wat engineering onderscheidt van geknutsel is de lus rond de prompt. Een productieprompt wordt geschreven tegen een doel, gedraaid over een vaste set testinputs, gescoord, en herzien, en wordt dan bevroren in versiebeheer waar wijzigingen gereviewd worden zoals elke diff. Dit doet ertoe omdat prompts broos zijn op onintuïtieve manieren: een zin toegevoegd om één mislukking te fixen kan stilletjes vijf andere gevallen breken, en zonder een eval kom je erachter van gebruikers. De brosheid is ook meetbaar. Een studie van 2023 door Sclar et al. vond dat subtiele wijzigingen in promptformattering alleen al nauwkeurigheidsschommelingen van tot 76 punten veroorzaakten in few-shot-settings, en de gevoeligheid verdween niet met grotere modellen of instruction tuning [2]. In agentic systemen geldt hetzelfde vakmanschap voor de systeemprompt, voor toolbeschrijvingen, en voor instructiebestanden, elk daarvan een prompt met een lange levensduur.

Voorbeeld

Een team extraheert factuurdata uit leveranciers-e-mails naar JSON. De eerste prompt, "extraheer de factuurdetails uit deze e-mail," werkt op nette facturen en valt uiteen op echt verkeer: totalen met EU-decimaalkomma's, doorgestuurde threads met twee facturen, e-mails zonder. De fix is engineering in plaats van magische woorden. Ze specificeren het exacte schema met een null-beleid voor afwezige velden, voegen drie few-shot-voorbeelden toe die het kommaformaat en het geen-factuur-geval dekken, instrueren dat alleen het meest recente bericht in een thread telt, en bakenen de e-mailbody af zodat niets erin als instructie leest. Gedraaid tegen een evalset van 40 e-mails gaat nauwkeurigheid van 61 naar 96 procent, en de eval bewaakt nu de prompt in CI tegen toekomstige bewerkingen.

Veelvoorkomende misvattingen

De hardnekkige misvatting is dat prompt engineering een zak geheime zinnen is, dat "adem diep in" of een gedreigde fooi betekenisvol kwaliteit stuurt. Die trucs waren altijd marginaal en werden platgewalst door instruction-getunede en reasoning-modellen. Wat output daadwerkelijk verplaatst is saai en duurzaam: de taak precies formuleren, voorbeelden van het doel tonen, het formaat beperken, en tegen echte gevallen testen. Systematisch gedaan is dat werk krachtig: Microsofts Medprompt-onderzoek van 2023 gebruikte alleen prompt engineering om generalist-GPT-4 voor het eerst boven 90% te duwen op de MedQA-medisch-examen-benchmark, en verlaagde het foutpercentage 27% onder de beste specialistmodellen [3]. Prompt engineering is technisch schrijven met een feedbacklus. Engineers die zoeken naar bezweringen plateauen snel; engineers die de prompt als een spec behandelen, blijven betere resultaten krijgen naarmate modellen verbeteren.

Prompttemplates

In productie worden prompts zelden vers per verzoek geschreven. Een prompttemplate is een geparametriseerde prompt opgeslagen in code: vaste instructiesteiger met sleuven voor de variabele delen, de input van de gebruiker, opgehaalde documenten, de datum van vandaag, gevuld op runtime. Templates zijn wat prompts überhaupt engineerbaar maakt, want een stabiel artefact kan geversioneerd, gediffed, A/B-getest, en door evals gedraaid worden, terwijl een ad-hoc-string samengevoegd op vier plekken alleen in productie te debuggen is. Volwassen codebases houden templates in dedicated bestanden met eigenaren en wijzigingsreview, en de scherpste teams behandelen een templatebewerking als een schemamigratie: klein, doelbewust, en geverifieerd tegen de evalsuite voor het uitgeleverd wordt.

FAQ

Is prompt engineering nog relevant in 2026? Ja, hoewel de vorm veranderde. De standalone "prompt engineer"-functietitel loste grotendeels op in gewoon engineeringwerk, terwijl de vaardigheid zelf zich verspreidde: iedereen die op modellen bouwt schrijft systeemprompts, toolbeschrijvingen, en templates, en het verschil tussen een slordige en een precieze verschijnt nog steeds direct in productkwaliteit.

Wat is het verschil tussen prompt engineering en context engineering? Bereik. Prompt engineering vervaardigt de instructie zelf. Context engineering bestuurt alles wat het model ziet op inferentiemoment, en beslist welke bestanden, geschiedenis, en toolresultaten het contextvenster vullen over een hele taak heen. In agentic systemen is de prompt één zorgvuldig geschreven stuk binnen dat grotere beheerde budget.

Maken reasoning-modellen prompt engineering onnodig? Ze maken het eenvoudiger, niet optioneel. Stap-voor-stap-steigers en uitgebreid rollenspel doen er minder toe omdat het model intern overweegt. Duidelijke taakdefinitie, beperkingen, voorbeelden, en outputcontracten doen er precies zoveel toe als voorheen, want geen hoeveelheid redenering herstelt een vereiste die de prompt nooit formuleerde.

Bronnen

1. Schulhoff et al., arXiv (The Prompt Report). "Taxonomie van 58 tekstgebaseerde LLM-promptingtechnieken en 40 technieken voor andere modaliteiten." https://arxiv.org/abs/2406.06608. Geraadpleegd augustus 2026.
2. Sclar et al., arXiv (FormatSpread). "Promptformatteringswijzigingen veroorzaakten prestatieverschillen tot 76 nauwkeurigheidspunten in few-shot-settings." https://arxiv.org/abs/2310.11324. Geraadpleegd augustus 2026.
3. Microsoft Research, arXiv (Medprompt). "Prompt engineering stuurde GPT-4 voorbij 90% op MedQA, een foutpercentageverlaging van 27% ten opzichte van specialistmodellen." https://arxiv.org/abs/2311.16452. Geraadpleegd augustus 2026.