Prompt engineering 101: een beginnersgids voor betere AI-uitvoer
22 september 2026
"Prompt engineering" klinkt als een gespecialiseerde technische vaardigheid, maar het meeste wat AI-uitvoer werkelijk verbetert, komt neer op een handjevol gewoonten die iedereen in een middag kan leren. Geen ervan is een truc of een toverformule — ze werken vanwege de manier waarop taalmodellen instructies werkelijk verwerken, en het waarom begrijpen maakt ze veel makkelijker consequent toe te passen.
Waarom is specifiek zijn belangrijker dan slim zijn?
Een model heeft geen toegang tot de context in je hoofd — het heeft alleen de woorden die je daadwerkelijk hebt getypt. "Schrijf iets over ons product" laat het model raden naar je toon, doelgroep, lengte en doel, en het zal iets plausibels maar generieks raden. "Schrijf een LinkedIn-post van 100 woorden waarin we ons product aankondigen aan eigenaren van kleine bedrijven, in een zelfverzekerde maar niet verkoperige toon, eindigend met een vraag" neemt bijna al dat giswerk weg. Specificiteit is geen stilistische voorkeur; je levert rechtstreeks de informatie die het model nodig heeft en anders niet heeft.
Waarom verbeteren voorbeelden de uitvoer meer dan langere instructies?
Een gewenste stijl abstract beschrijven ("maak het pittig en professioneel") is inherent dubbelzinnig — pittig en professioneel betekenen voor verschillende mensen verschillende dingen, en het model moet raden welke versie je bedoelt. Een of twee voorbeelden geven van precies de stijl, het formaat of de toon die je wilt, verankert het model aan iets concreets in plaats van aan een abstracte beschrijving, wat consequent betrouwbaarder is dan proberen de doelstijl te beschrijven met steeds meer bijvoeglijke naamwoorden.
Wat bereik je werkelijk door een model een rol of persona te geven?
Een verzoek inkleden als "je bent een ervaren belastingadviseur die dit uitlegt aan iemand die voor het eerst aangifte doet" doet twee echte dingen: het vernauwt de ruimte van plausibele antwoorden richting de conventies en het vocabulaire van dat vakgebied, en het bepaalt impliciet een passende toon en een niveau van veronderstelde voorkennis zonder dat je die apart hoeft uit te schrijven. Het is een compacte manier om informatie over doelgroep en expertiseniveau te coderen die anders meerdere zinnen zou vergen om expliciet te specificeren.
Waarom levert een complex verzoek opsplitsen in stappen betere resultaten op dan één grote prompt?
Eén dichte prompt die tegelijk om onderzoek, analyse en opgemaakte uitvoer vraagt, dwingt het model om meerdere doelen tegelijk te jongleren, en de kwaliteit van elk afzonderlijk doel kan daaronder lijden. Hetzelfde verzoek opsplitsen in opeenvolgende stappen — eerst de structuur schetsen, dan elke sectie uitschrijven, dan nakijken en aanscherpen — laat het model zich volledig op één doel tegelijk concentreren, en laat jou tussentijdse uitvoer beoordelen en corrigeren voordat fouten zich opstapelen in het eindresultaat. Dit is vooral belangrijk bij werkelijk complexe taken met meerdere onderdelen; eenvoudige verzoeken hebben het niet nodig.
Is het zinvol om een model te vertellen wat het NIET moet doen, of raakt het daar alleen van in de war?
Negatieve instructies ("gebruik geen bedrijfsjargon", "voeg geen slotalinea toe") werken, maar zijn doorgaans minder betrouwbaar dan positieve instructies die beschrijven wat je wél wilt, omdat het model nog steeds iets moet genereren en een afwezigheid moeilijker te richten is dan een aanwezigheid. "Wees niet te formeel" is zwakkere sturing dan "schrijf in een losse, conversationele toon, alsof je het aan een vriend uitlegt" — de tweede geeft het model iets concreets om op te mikken in plaats van alleen een grens om te vermijden.
Waarom voelt de eerste versie van een model zelden als de definitieve versie?
Het eerste antwoord van een model op een niet-triviale prompt is zijn beste gok om alles in je instructies tegelijk te vervullen — het heeft je reactie nog niet gezien. De eerste uitvoer behandelen als een concept om op door te bouwen, in plaats van als een definitief antwoord om in zijn geheel te accepteren of af te wijzen, is consequent productiever: specifiek aangeven wat er mis is ("korter", "concretere voorbeelden", "schrap de tweede alinea") en om een herziening vragen brengt je meestal sneller dichter bij wat je werkelijk wilde dan proberen in één keer de perfecte prompt te schrijven.