Context vs prompt engineering
Waar prompt engineering als discipline voldeed, zijn er nu zoveel aspecten bijgekomen, dat de term tegenwoordig tekort schiet. Tijd voor een bredere term, zoals context engineering? Of misschien zelfs agent engineering?
Als Andrej Karpathy, prominent computerwetenschapper en AI-denker, spreekt, dan luistert de wereld. Recent brak hij een lans voor de term context engineering als belangrijker dan prompt engineering. Karpathy heeft als gebruikelijk een punt. Laten we eerst eens kijken wat prompt engineering en context engineering precies zijn, daarna de verschillen bekijken en tenslotte evalueren waarom het onderscheid relevant is.
+1 for "context engineering" over "prompt engineering".
— Andrej Karpathy (@karpathy) June 25, 2025
People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window… https://t.co/Ne65F6vFcf
Prompt engineering
Prompt engineering is de set van vaardigheden waarmee je het taalmodel kan masseren om de gewenste uitkomst te geven. Een prima verzameling van prompting best practices is het werk Prompt Engineering van Lee Boonstra. Het bevat zowel principes (lever voorbeelden, houd het eenvoudig, wees specifiek, instructies boven beperkingen) als technieken (zero & few shot prompting, chain of thought en self-consistency).
Als je de parallel trekt met programmeren, dan zou je kunnen zeggen dat prompt engineering te vergelijken is met Design Patterns. Het biedt vooral bouwstenen om goede prompts te construeren en een manier van denken hoe je die bouwstenen effectief kunt inzetten.
Context engineering
Context engineering overstijgt prompt engineering, wat slechts een onderdeel is – weliswaar een belangrijk onderdeel – binnen context engineering. Het idee van context engineering is dat je ook kijkt naar andere onderdelen die om de hoek komen kijken als je AI in een bedrijfsproces probeert in te zetten. Je kunt dan denken aan:
- juiste context informatie, juiste hoeveelheid
- beschrijvingen van de taak
- voorbeelden (zero, few, many shots)
- tool calling / MCP
- etc
In de tweet van Karpathy beklaagt hij zich eigenlijk al gelijk dat de scope nog veel groter zou moeten zijn en dat ook andere aspecten van het integreren van AI agents in bedrijfsprocessen een plekje verdienen, zoals bijvoorbeeld:
- het opdelen van problemen in kleinere stappen die door de AI afgehandeld kunnen worden
- het inzetten van het juiste type LLM, met de juiste vaardigheden
- het verificatie-proces van de uitvoer van de LLM
- diverse guardrails, security, parallel verwerking
- etc
Zijn tweet overwegend, zou het me niet verbazen dat hij later met een andere term komt die ook deze cruciale activiteiten vatten. Ik zat zelf te denken in de richting van Agent engineering, een superset van Context engineering, wat op zich weer een superset is van Prompt engineering.
Waarom onderscheid maken?
Door de discipline breder te trekken, maak je expliciet dat de aspecten die vallen onder de nieuwe term belangrijk zijn in het inzetten van agents in je bedrijfsproces. Door een taak expliciet te maken, wordt het iets om op te letten bij de implementatie, te testen, te reviewen, fijn te slijpen, te documenteren, een vaardigheid om op te selecteren, trainen en toetsen, een aspect waar je beter in kunt worden, waar je jezelf en je collega's scherp in kunt houden.
Het benoemen van de term Context engineering – wellicht later om te dopen tot Agent engineering – in plaats van Prompt engineering is een teken dat het implementeren van agents in bedrijfsprocessen een serieuze, technische discipline aan het worden is. Voor mij professioneel gezien een prettige gewaarwording en dat zal ongetwijfeld ook gelden voor anderen die dagelijks met deze technologie bezighouden en zich herkennen in de behoefte om de discipline breder te trekken.
