Prompt Engineering in 2026: 10 Technieken Die Nog Werken (en 4 Die Sneuvelden bij Reasoning Models)

Prompt Engineering in 2026: 10 Technieken Die Nog Werken (en 4 Die Sneuvelden bij Reasoning Models)

Prompt engineering is niet dood gegaan in 2026. Het is in tweeën gesplitst. OpenAI's eigen reasoning-documentatie zegt je nu om te stoppen met "think step by step" te schrijven, en een arXiv-paper uit 2024 (2410.21333) mat een nauwkeurigheidsdaling tot wel 36,3% wanneer chain-of-thought op de verkeerde taak werd afgedwongen. Dat is het rare gedeelte. De casual helft van prompt engineering werd makkelijker, terwijl de productiehelft, de helft die draait op GPT-5 en Claude, een stuk strenger werd. Deze gids sorteert de 10 technieken die nog steeds je tijd waard zijn van de 4 gewoontes die reasoning models hebben afgeschreven.

Belangrijkste inzichten:

• Prompt engineering splitste in 2026 in casual prompting (makkelijker) en productie-prompting (strenger).
• Bij reasoning models is het afdwingen van "think step by step" overbodig en kan het de nauwkeurigheid verlagen. OpenAI raadt het af.
• Vier gewoontes afgeschreven: CoT forceren, reflexmatig zwaar few-shot gebruiken, response prefilling, en handmatig budget_tokens afstellen.
• Wat nog steeds wint: helderheid, structured outputs, taakdecompositie, en evaluatiegedreven iteratie.

Wat Prompt Engineering in 2026 Eigenlijk Is

Prompt engineering is het vak van het ontwerpen en verfijnen van de instructies die je een large language model geeft om accurate, relevante output te krijgen. Kerntechnieken zijn onder meer zero-shot, few-shot, chain-of-thought en role prompting. In 2026 splitst het zich in twee taken: casual prompting in een chat, en productie-prompting binnen een systeem.

Dit is wat niemand tot dit jaar hardop zei: het zijn twee verschillende vaardigheden. Een goed antwoord krijgen in ChatGPT is inmiddels bijna triviaal, omdat de modellen slordige formuleringen vergeven. Een betrouwbaar antwoord krijgen van een systeem dat duizend keer per dag draait, in tien talen, zonder dat iemand meekijkt, is dat niet. Die tweede taak staat centraal in deze gids.

Wij schrijven voor de productieband: developers en AI engineers die instructies nodig hebben die standhouden op GPT-5, Claude Opus 4.8 en Gemini. De intro, deze definitie en de FAQ blijven leesbaar voor iedereen. Wil je de neutrale taxonomie van elke benoemde techniek, dan is de dair-ai promptingguide.ai-referentie nog altijd de beste encyclopedie op het web. In 2026 is prompt engineering geen vaardigheid. Het zijn er twee.

Prompt Engineering vs Context Engineering: Wat Is Het Verschil?

Prompt engineering draait om het opstellen van de instructie. Context engineering draait om het ontwerpen van alles wat eromheen in het contextvenster terechtkomt: retrieval, geheugen, tools, volgorde. Prompt engineering is een subset van context engineering. Deze gids behandelt de prompt-crafting helft; de gelinkte gids behandelt de rest.

Welke heb je dan nodig? Als je context statisch is en in één bericht past, is prompt engineering ruim voldoende. Zodra je input per verzoek verandert, zit je in context engineering, en wordt prompt engineering slechts één tool daarbinnen. We hebben dat volledige plaatje geschetst in onze complete gids over context engineering; dit artikel blijft aan de prompt-crafting kant van de streep.

Nog één opmerking voor de entiteitenverzamelaars: Google Autocomplete rekt dit inmiddels op tot een vierdeling van engineering-disciplines, en wij behandelen de eerste twee, prompt en context. Simpel gezegd: prompt engineering is het kiezen van de juiste woorden voor de vraag; context engineering is bepalen wat er al op tafel ligt voordat de vraag wordt gesteld.

De 10 Belangrijkste Prompt-Crafting Technieken (Gerangschikt op ROI in 2026)

De tien technieken die het waard zijn om in 2026 te kennen, ruwweg gerangschikt op rendement per inspanning: zero-shot, few-shot, role prompting, chain-of-thought, taakdecompositie, prompt chaining, self-consistency, structured outputs, prompt templates en meta-prompting. Sommige zijn dagelijkse werkpaarden; twee gedragen zich anders op reasoning models, wat de volgende sectie uitsplitst.

De namen hieronder volgen de taxonomie uit "The Prompt Report", een systematisch overzicht van meer dan 50 promptingtechnieken. Zie dit als een toolkit waaruit je put, niet als een checklist die je van boven naar beneden afwerkt.

1. Zero-shot prompting

Zero-shot betekent dat je een duidelijke instructie geeft zonder voorbeelden, en het model laat uitzoeken hoe. Bij 2026-modellen is dit je standaard eerste zet, omdat een precieze, specifieke instructie meestal wint van een rommelige. De truc zit niet in magische bewoording, maar in het wegnemen van ambiguïteit: zeg welke output je wilt, in welk format, voor wie.

# Doelmodel: GPT-5 / Claude Opus 4.8
Classificeer dit supportticket als: billing, technical of account.
Geef alleen het enkele label in kleine letters terug.

Ticket: "Mijn kaart is deze maand twee keer belast."

2. Few-shot prompting

Few-shot betekent dat je twee tot vijf voorbeelden meegeeft om het gewenste format of gedrag te sturen. Het is de snelste manier om een outputstijl vast te zetten waar het model steeds van afdwaalt. Eén kanttekening: bij reasoning models zeggen OpenAI's reasoning best practices om eerst zero-shot te proberen en alleen voorbeelden toe te voegen als ze aantoonbaar helpen. Bij 2026-modellen is zero-shot de standaard en few-shot de fallback, niet andersom.

# Doelmodel: GPT-5
Extraheer het product en het sentiment. Volg de voorbeelden.

Input: "De batterij is na een uur leeg." -> product: batterij, sentiment: negatief
Input: "Installatie duurde twee minuten, geweldig." -> product: installatie, sentiment: positief
Input: "Het scherm is prachtig, maar het is zwaar." ->

3. Role-/persona-prompting

Role prompting bepaalt wie het model is voordat het antwoordt, wat toon, woordkeuze en format meer stuurt dan het ruwe redeneren. "Je bent een senior belastingaccountant die een aangifte beoordeelt" trekt andere taal aan dan een lege prompt. Houd het functioneel, niet theatraal. De rol moet echte beperkingen coderen: doelgroep, format, wat je weglaat. Onze aankomende verzameling system prompt examples brengt de patronen samen die we het vaakst hergebruiken.

# Doelmodel: Claude Opus 4.8
Je bent een senior belastingaccountant. Beoordeel onderstaande cijfers voor een
kleine ondernemer die geen accountant is.
Format: 3 bullets, in gewone taal, markeer elk getal dat verkeerd oogt.

4. Chain-of-thought (CoT)

Chain-of-thought vraagt het model om zijn redeneerstappen te tonen voordat het met het eindantwoord komt. Bij klassieke GPT-stijl modellen is het nog steeds een van de meest waardevolle trucs voor wiskunde, logica en meerstaps problemen. Maar bij reasoning models kan het overbodig of zelfs schadelijk zijn, wat de volgende sectie met echte cijfers behandelt. Onze aankomende chain-of-thought prompting deep-dive behandelt de volledige techniek. Onthoud voor nu dat het niet langer een reflex is die je overal op toepast.

5. Taakdecompositie

Decompositie betekent één grote vraag opsplitsen in geordende subtaken die het model één voor één afhandelt. In plaats van "schrijf een launchplan" vraag je eerst om de doelgroep, dan de kanalen, dan de kalender. Kleinere stappen betekenen minder plekken waar het mis kan gaan, en makkelijker debuggen wanneer dat toch gebeurt.

# Doelmodel: elk 2026-model
Taak: schrijf een e-mail voor een productlancering.
Werk in volgorde en label elke stap:
1) Bepaal de doelgroep en hun belangrijkste bezwaar.
2) Schrijf één onderwerpregel die dat bezwaar wegneemt.
3) Schrijf een body van 90 woorden.
4) Sluit af met één CTA.

6. Prompt chaining

Chaining voedt de output van de ene prompt als input aan de volgende. Het is decompositie werkelijkheid gemaakt in code: prompt A haalt de kernfeiten eruit, prompt B schrijft een concept op basis van die feiten, prompt C toetst het concept aan een regel. Elke schakel is simpel, testbaar en verwisselbaar. Als één stap achteruitgaat, fix je die schakel in plaats van een gigantische monoliet-prompt te moeten ontwarren.

7. Self-consistency

Self-consistency samplet dezelfde vraag meerdere keren en neemt daarna het meerderheidsantwoord. Het ruilt tokens in voor betrouwbaarheid bij lastig redeneerwerk waarbij één enkele poging wisselvallig is, maar je betaalt voor drie tot vijf completions om er één te krijgen. Bij sterke reasoning models krimpt de winst vaak, dus bewaar het voor taken die echt ambigu zijn, waarbij het juiste antwoord zwaarder weegt dan de rekening.

8. Outputformattering / structured outputs

Structured outputs betekent dat je de response aan een schema bindt in plaats van te hopen dat het model schone JSON teruggeeft. Dit verdient hieronder een eigen sectie. De versie in één zin: bedel niet om JSON in de prompt, dwing het model in een schema en stop met gokken.

9. Prompt templates & variabelen

Templates maken van een goede eenmalige prompt een geparametriseerd, herbruikbaar asset: vaste instructies plus slots voor de variabele delen. Zo stoppen prompts ad-hoc tekst te zijn en worden ze versiebeheerde artefacten die je kunt testen, wat verderop het pipeline-verhaal is. Herbruikbare projectregelbestanden, zoals de cursor rules die developers in hun repo's bewaren, zijn levende prompt templates onder een andere naam.

10. Meta-prompting

Meta-prompting is een model gebruiken om je prompt te schrijven of te verbeteren. Het is het snelste pad geworden van een leeg vak naar een solide concept, en er staan echte data achter, hieronder behandeld. Korte versie: begin met een door het model verbeterd concept, en werk dat daarna handmatig bij.

Welke Prompt-Technieken Hebben Reasoning Models Overbodig Gemaakt (of Gebroken)?

Vier gewoontes die ooit goed advies waren, werken nu averechts bij reasoning models zoals OpenAI's o-serie, GPT-5 en Claude's thinking modes: het afdwingen van expliciete chain-of-thought, standaard zwaar leunen op few-shot, response prefilling, en handmatig budget_tokens afstellen. Reasoning models denken al intern na, dus het scripten van de stappen is overbodig, en soms erger dan overbodig.

Elk ervan is om een andere reden gesneuveld.

Chain-of-thought afdwingen. OpenAI's reasoning best practices zijn glashelder: "Vermijd chain-of-thought-prompts," omdat deze modellen intern redeneren, waardoor ze vertellen "think step by step" te doen "onnodig" is en "de prestaties mogelijk niet verbetert (en ze soms zelfs kan schaden)." De arXiv-paper 2410.21333 zette er een getal op: tot 36,3% lagere absolute nauwkeurigheid voor o1-preview versus GPT-4o op een taak waarbij bewust stap-voor-stap denken juist averechts werkt. Een tweede studie, 2412.21187, laat zien dat reasoning models te veel rekenkracht verspillen aan triviale problemen. Wij zijn maanden geleden gestopt met "think step by step" toe te voegen aan prompts voor reasoning models, en er werd niets slechter.

Reflexmatig zwaar few-shot gebruiken. OpenAI's richtlijn is: "houd prompts simpel en direct" en "probeer eerst zero-shot, dan few-shot als het nodig is." Standaard voorbeelden opstapelen kost nu tokens en kan een capabel model juist beperken. Voeg voorbeelden toe wanneer ze aantoonbaar helpen, niet als opwarmritueel.

Response prefilling. Woorden in de mond van het model leggen om een format af te dwingen was vroeger een standaardtruc. Op Claude 4.6+, Fable 5 en Mythos 5 worden vooraf ingevulde assistant-turns niet meer ondersteund en leveren ze een 400-fout op, volgens Anthropics prompting best practices. Gebruik in plaats daarvan structured outputs, wat de volgende sectie behandelt.

Handmatig budget_tokens micromanagen. Zelf een thinking-tokenbudget instellen is ook deprecated (een 400 op Opus 4.7+ en nieuwer). Anthropics modellen gebruiken nu adaptive thinking, en je stuurt de inspanning met de effort-parameter in plaats van een getal te scripten. OpenAI maakte dezelfde beweging: developer messages zijn de nieuwe system messages, en reasoning effort is een instelling. De klassieke truc, "let's think step by step," is nu, bij reasoning models, soms juist wat ze slechter maakt.

Hoe Krijg Je in 2026 Betrouwbare JSON Uit een LLM?

Schema-constrained structured outputs, niet prompt-bedelen. In 2026 is het betrouwbare pad om het model een JSON-schema te geven en de API geldige output daartegen te laten garanderen. "Geef alsjeblieft JSON terug" in de prompt schrijven is broos; de deprecated prefill-hack is verdwenen. Zowel OpenAI als Anthropic leveren precies hiervoor een structured outputs-feature.

Waarom is "geef alsjeblieft geldige JSON terug" zo broos? Omdat je een probabilistisch systeem vraagt om op erewoord perfect syntactisch te zijn. Eén verdwaald commentaar of trailing comma en je parser crasht. Structured Outputs lost dit op API-niveau op: je geeft een schema mee, en het model wordt gedwongen daaraan te voldoen. Anthropic merkt op dat nieuwere modellen "complexe schema's betrouwbaar kunnen matchen als ze dat wordt opgedragen."

Hier is een klein, realistisch responseschema voor een support-ticketclassifier:

{
  "name": "ticket_classification",
  "schema": {
    "type": "object",
    "properties": {
      "category": { "type": "string", "enum": ["billing", "technical", "account"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "summary": { "type": "string", "maxLength": 120 }
    },
    "required": ["category", "priority", "summary"],
    "additionalProperties": false
  }
}

Geef dat mee aan OpenAI's of Anthropics structured outputs en je krijgt elke keer parseerbare JSON terug, zonder retry-loop. Voor het volledige cross-provider patroon, inclusief Pydantic- en Zod-validatie, zie onze gids over betrouwbare JSON krijgen uit elke LLM. In 2026 vraag je een model niet om JSON. Je dwingt het in een schema en stopt met hopen.

Meta-Prompting: Laat het Model Je Prompt Schrijven

Meta-prompting betekent dat je een LLM gebruikt om de prompt die je uiteindelijk draait op te stellen of te verfijnen. Het is de snelste weg van een ruw idee naar een werkende prompt, en de tooling zit er al in: Anthropics prompt improver en OpenAI's prompt optimizer herschrijven allebei je concept aan de hand van best practices. Begin met de versie van de machine, en werk die daarna handmatig bij.

Helpt het echt, of is het een kunstje? Anthropic heeft het zelf doorgerekend: hun prompt improver leverde een nauwkeurigheidswinst van 30% op een multilabel-classificatietest en 100% naleving van de woordlimiet op een samenvattingstaak, volgens hun eigen verslag. OpenAI's prompt optimizer doet hetzelfde werk.

De workflow die wij het fijnst vinden: beschrijf de taak, laat de tool een gestructureerd eerste concept produceren, en verfijn dat vervolgens handmatig voor jouw data. Die laatste handmatige stap is precies waarom prompts nog steeds een mens en een test nodig hebben. De snelste weg naar een betere prompt in 2026 is het model jouw versie laten herschrijven, en dan bijwerken. Niet naar een leeg vak staren.

Model-Specifieke Prompting Cheat Sheet (OpenAI vs Anthropic vs Google)

Zelfde werk, drie dialecten. OpenAI wil developer messages en geen afgedwongen chain-of-thought. Anthropic wil XML-tags, adaptive thinking en de effort-parameter. Google's Gemini wil een thinking budget. Reasoning models zijn je planners; klassieke GPT-stijl modellen zijn je werkpaarden. Match de techniek met het niveau.

De verschillen zijn klein, maar bijten wel. Bij OpenAI hebben developer messages het oude system message vervangen voor de o-serie en hoger, en de documentatie stuurt je weg van expliciete CoT. Bij Anthropic zijn XML-tags nog steeds de aanbevolen manier om een complexe prompt te structureren, en is thinking standaard adaptive. Project-niveau promptbestanden, zoals de CLAUDE.md-bestanden die codingteams in hun repo's bewaren, bevatten veel van deze provider-specifieke bekabeling. Bij Gemini geef je het model een thinking budget mee.

Van Prompt naar Pipeline: Templates, Versiebeheer & Evaluatie

In productie stopt prompt engineering met alleen bewoording te zijn en wordt het een empirische discipline. Je versiebeheert prompts zoals code, gate ze met evals, en voegt regressietests toe zodat een wijziging die stilletjes de output breekt wordt opgevangen voordat gebruikers hem zien. Hier ontmoet prompt engineering evaluatie, en dit is het deel dat daadwerkelijk bepaalt of je app werkt.

Zo ziet dat eruit op een echt systeem. Deze blog draait op een door Claude aangedreven contentpipeline van 17 gespecialiseerde sub-agents, elk een apart geprompte rol: een researcher, een brief-creator, een content-writer, een validator, een language-translator, een sanity-publisher, een image-handler, en meer. Bij drie van die fases, brief, writer en validator, handhaven we 8 anti-detectie guardrail-regels. De validator grept elk concept tegen een verboden-woordenlijst van 52 termen, en één treffer blokkeert publicatie, ondersteund door een apart lexicaal controlescript. Die pipeline heeft zo'n 194 Engelse posts over 4 sites uitgebracht, elk vertaald naar tot 10 talen door parallelle taal-specifieke agents.

Niets daarvan kwam van slimme bewoording. Het kwam van prompts behandelen als versiebeheerde, eval-gated artefacten, en twee incidenten leerden ons waarom.

De eerste was een diacritics-bug. Onze vertaalprompt gaf soms ASCII terug in plaats van Unicode, waardoor het Turkse woord "karşılaştırma" terugkwam als "karsilastirma." Stil, lelijk, en makkelijk over het hoofd te zien op schaal. De fix was geen betere zin, maar een aangescherpte instructie plus een grep-gate die native karakters telt en de vertaling automatisch opnieuw draait als de telling op nul uitkomt. Een regressietest, op een prompt.

De tweede was erger. Een her-vertaalprompt begon net iets andere gelokaliseerde slugs te bedenken, waardoor de publisher een gloednieuw document aanmaakte terwijl het oude live bleef staan. Dat leverde 54 dubbele live documenten op, wat Google Search Console-uitsluitingen voor duplicaten triggerde. De fix was een prompt-guardrail die hergebruik van de bestaande slug afdwingt, plus een resolve-before-create regel in de publisher.

De les kwam hard aan: de prompt die 194 posts in tien talen uitbracht, won niet op bewoording. Hij won omdat een grep-gate hem opnieuw draaide op het moment dat hij afdreef. Dat is LLM-evaluatie in actie, en daarom koppelen we elke belangrijke prompt aan prompt management tools om ze te versiebeheren en terug te draaien. Voor een stabiel voorvoegsel dat duizenden keren terugkomt, cachen we het om kosten te besparen. Dit is precies het soort prompt-en-eval pipeline dat we voor klanten bouwen.

Veelgemaakte Prompt Engineering Fouten (en de Oplossingen voor 2026)

De dure fouten in 2026 zijn geen typefouten. Ze zijn structureel: vage instructies, reasoning models overscripten, uitleveren zonder eval-loop, model-specifiek gedrag negeren, de prompt volstoppen terwijl het echte probleem context is, en onbetrouwbare input vertrouwen. Elke fout heeft een nette fix, en de meeste kosten niets behalve aandacht.

Loop de lijst na en wees eerlijk over welke fouten jij maakt:

• Vage instructies. "Maak het beter" geeft het model niets om op te mikken. Zeg wat "beter" betekent: korter, vriendelijker, geldige JSON, onder de 120 woorden.
• Reasoning models overscripten. "Think step by step" afdwingen bij een o-serie- of thinking-model is de fout die hierboven al aan bod kwam. Laat het redeneren; verhoog in plaats daarvan het effort.
• Geen eval-loop. Als je niet kunt zien of een promptwijziging hielp of schaadde, ben je aan het gokken. Voeg testcases en een pass/fail-check toe.
• Model-specifiek gedrag negeren. De prompt die schittert op GPT-5 heeft op Claude misschien XML-tags nodig. Lees de cheat sheet hierboven.
• Prompt-stuffing. Meer in één instructie proppen terwijl het echte gat retrieval of geheugen is, betekent dat je context engineering nodig had, geen langere prompt.
• Onbetrouwbare input vertrouwen. Gebruikersinput en opgehaalde documenten kunnen verborgen instructies bevatten. Voeg er guardrails omheen toe; onze aankomende prompt-injection-prevention deep-dive behandelt de beveiligingskant volledig.

De duurste promptfout in 2026 is geen typefout. Het is uitleveren zonder een eval die de regressie had opgevangen.

Is Prompt Engineering Dood? Een Eerlijk Antwoord voor 2026

Nee. Prompt engineering is niet dood, het is uiteengevallen. Casual prompting werd makkelijker omdat de modellen slimmer en meer vergevingsgezind werden. Productie-prompting werd moeilijker, omdat betrouwbaarheid, structured outputs en evaluatie nu belangrijker zijn dan slimme bewoording. Het woord "engineering" betekent eindelijk wat het zegt.

Waarom blijft iedereen het dan doodverklaren? Omdat de zichtbare helft, een verzoek intypen in ChatGPT, oprecht triviaal is geworden. De helft die niet makkelijker werd, een prompt uitleveren die standhoudt over duizenden calls en tien talen, haalt geen krantenkoppen. De echte 2026-vaardigheid is geen magische zin. Het is evaluatie, de keuze van modelniveau (planner versus werkpaard), en weten wanneer een probleem de prompt is ontgroeid en context engineering is geworden. De makkelijke helft werd makkelijker en de moeilijke helft werd moeilijker, en maar één daarvan haalt de krantenkoppen.

Als er één inzicht is: 10 technieken verdienen nog steeds hun plek, 4 oude gewoontes kosten je nu geld bij reasoning models, en evaluatie is de vaardigheid die een demo van een product onderscheidt. Bouw je iets waarbij de prompts in productie moeten standhouden? Vraag een gratis consult aan en wij helpen je eerst de eval-loop op te zetten.

Veelgestelde Vragen

Wat is prompt engineering in de context van generatieve AI?

Prompt engineering is het vak van het ontwerpen en verfijnen van de instructies die je een large language model geeft om accurate, relevante output te krijgen. Het omvat technieken zoals zero-shot, few-shot, chain-of-thought en role prompting. In 2026 splitst het zich in casual chat-prompting en strenge productie-prompting binnen een systeem.

Is prompt engineering dood in 2026?

Nee, prompt engineering is niet dood in 2026, het is uiteengevallen. Casual prompting werd makkelijker naarmate modellen meer vergevingsgezind werden. Productie-prompting werd strenger, omdat structured outputs, evaluatie en betrouwbaarheid nu belangrijker zijn dan slimme bewoording. De vaardigheid verdween niet; de makkelijke helft had jou simpelweg niet meer nodig.

Wat is het verschil tussen prompt engineering en context engineering?

Prompt engineering stelt de instructie op; context engineering ontwerpt al het andere in het contextvenster: retrieval, geheugen, tools en volgorde. Prompt engineering is een subset van context engineering. Je hebt context engineering nodig zodra je input per verzoek verandert, zoals bij agents en RAG-systemen.

Heb je chain-of-thought prompting nog nodig bij reasoning models?

Meestal niet. Bij reasoning models zoals OpenAI's o-serie, GPT-5 en Claude's thinking modes is "think step by step" afdwingen overbodig omdat ze intern redeneren, en OpenAI zegt dat het de prestaties kan schaden. Chain-of-thought helpt nog steeds bij klassieke GPT-stijl modellen, dus match de techniek met het niveau.

Vereist prompt engineering programmeerkennis?

Niet om te beginnen. Iedereen kan duidelijke instructies schrijven en betere antwoorden krijgen van ChatGPT of Claude. Maar productie-prompt engineering, prompts versiebeheren, structured outputs bekabelen en eval-loops bouwen, is een developersdiscipline. De casual helft heeft geen code nodig; de professionele helft wel.

Wat is het verschil tussen zero-shot en few-shot prompting?

Zero-shot prompting geeft een duidelijke instructie zonder voorbeelden; few-shot bevat twee tot vijf voorbeelden om het outputformat of -gedrag te sturen. Begin bij 2026-modellen met zero-shot, omdat ze instructies goed opvolgen, en voeg few-shot alleen toe wanneer voorbeelden de resultaten aantoonbaar verbeteren. Few-shot is de fallback, niet de standaard.

Hoe zorg je dat een LLM betrouwbaar JSON teruggeeft?

Gebruik schema-constrained structured outputs, niet prompt-bedelen. In plaats van "geef alsjeblieft JSON terug" te schrijven, geef je een JSON-schema mee via OpenAI's of Anthropics Structured Outputs-feature, die het model dwingt tot geldige, parseerbare output. De oude prefill-truc geeft nu een 400-fout op nieuwere Claude-modellen.

Wat is meta-prompting?

Meta-prompting is het gebruiken van een model om de prompt die je gaat draaien op te stellen of te verbeteren. Tools zoals Anthropics prompt improver en OpenAI's prompt optimizer herschrijven je concept aan de hand van best practices; Anthropic mat een nauwkeurigheidswinst van 30% op één test. Genereer een eerste concept, en werk dat daarna handmatig bij voor jouw data.

Is prompt engineering een echt vak of baan?

Ja, het is een echte vaardigheid, al vervaagt de losstaande titel "prompt engineer" naar bredere AI-engineeringrollen. Werkgevers willen mensen die prompts kunnen opstellen én evals, structured outputs en contextpipelines kunnen ontwerpen. Als carrière staat het het sterkst als onderdeel van de toolkit van een AI engineer.

Hoe verschilt prompting tussen ChatGPT, Claude en Gemini?

Het werk is hetzelfde; het dialect verschilt. OpenAI gebruikt developer messages en stuurt je weg van expliciete chain-of-thought bij reasoning models. Anthropics Claude geeft de voorkeur aan XML-tags, adaptive thinking en de effort-parameter. Google's Gemini gebruikt een thinking budget. Reasoning models zijn planners; klassieke GPT-stijl modellen zijn werkpaarden.

Sources

• OpenAI: Reasoning best practices
• OpenAI: Structured Outputs
• OpenAI: Prompt optimizer
• Anthropic: Claude prompting best practices
• Anthropic: Structured Outputs
• Anthropic: Prompt improver (docs)
• Anthropic: Prompt improver announcement
• arXiv 2410.21333: Mind Your Step (by Step)
• arXiv 2412.21187: Do NOT Think That Much for 2+3?
• arXiv 2406.06608: The Prompt Report
• Prompt Engineering Guide (dair-ai)