Van prompt- naar context-engineering
Artificial Intelligence · 
5 minuten leestijd - 18 mei 2026
Toen ik begon met de eerste AI-tools dacht ik dat betere prompts de oplossing waren. Scherpere formuleringen, meer detail in de instructie, een duidelijkere rol voor de AI. Maar bij elk nieuw gesprek moest ik opnieuw beginnen: zelfde uitleg, zelfde regels, zelfde achtergrond. Voor losse taken werkt dat prima. Voor een groter project werkt dat minder goed.
Prompt engineering: de valkuil van een perfecte zin
Prompt engineering draait om het optimaliseren van wat je de AI stuurt. Betere vragen stellen, de juiste rol toekennen, chain-of-thought toepassen. Het is echt tijdrovend en ik heb er de afgelopen maanden flink van geleerd.
Het probleem is dat je elke keer opnieuw begint. Geen geheugen, geen projectcontext, geen kennis van je werkwijze of eerdere beslissingen. Je bouwt de brug bij elke sessie opnieuw op. Dat werkt prima voor losse taken. Zodra je met een AI samenwerkt aan een echt project, met regels, patronen en een eigen tone of voice, schiet zelfs de meest geslepen prompt tekort.
Context engineering: de omgeving is het werk
Context engineering gaat een laag dieper. Het gaat niet over de boodschap die je stuurt, maar over de omgeving die je bouwt rondom de AI. Wie is de gebruiker? Wat zijn de regels? Welke tools heeft de AI beschikbaar? Wat weet hij al over het project?
In de praktijk betekent dat: system prompts met duidelijke afspraken, geheugenbestanden die projectkennis vasthouden, en tools die de AI in staat stellen écht iets te doen, niet alleen te antwoorden. Denk aan een CLAUDE.md: een contextbestand dat een AI-agent vertelt hoe jouw codebase in elkaar zit, welke naamgevingsconventies er gelden en welke tone of voice je hanteert.
De kwaliteit van je output verschuift daarmee van hoe je iets vraagt naar hoe goed je de context hebt ingericht.
| Kenmerk | Prompt engineering | Context engineering |
|---|---|---|
| Focus | Input formulering | Systeemniveau design |
| Scope | Eenmalige interactie | Doorlopend, meerdere sessies |
| Flexibiliteit | Statisch | Dynamisch & adaptief |
| Technieken | Tekst-prompts, few-shot voorbeelden | Tool-integratie, geheugen, orkestratie |
| Use cases | Tekstgeneratie, Q&A | Projectgebaseerde samenwerking, agents |
| ROI | Hoge initiële inspanning | Hogere schaalbaarheid op termijn |
Hoe ik dit zelf ben gaan toepassen
Voor mij was mijn portfolio de perfecte testomgeving. Ik ken het project door en door, de stack is overzichtelijk en ik weet precies wat ik wil. Een bekende context dus, waarmee ik goed kon beoordelen of de AI-output ook echt naar wens was. Als tool koos ik voor Claude, omdat ik daar toch al mee werkte en het een goede ondersteuning biedt voor dit soort projectgebaseerde samenwerking.
De omschakeling werd concreet toen ik begon te werken met MCP (Model Context Protocol). In plaats van elke sessie opnieuw uit te leggen wat mijn Figma-project bevat, geef ik de AI structurele toegang tot mijn designtool. De context is er al. Ik hoef hem niet opnieuw op te bouwen.
Datzelfde principe heb ik toegepast op mijn portfolio. Ik heb Claude gevraagd om op basis van de bestaande codebase een CLAUDE.md op te stellen: een contextbestand dat mijn technische stack, componentstructuur, visuele stijl én schrijfstijl beschrijft. Een AI-agent die dit leest, begrijpt direct hoe het project werkt, zonder dat ik het elke keer opnieuw hoef uit te leggen. Eén keer goed inrichten, elke keer voordeel.
Het voelt minder direct dan een scherpe prompt. Maar het werkt structureel beter. En dat verschil merk je pas echt als je het naast elkaar legt. Een concreet resultaat van die aanpak: de Design System documentatie van mijn portfolio, gegenereerd op basis van diezelfde context ter inspiratie.
Tip van Tai: zo maak je een context markdown
Mijn aanpak voor het opzetten van een CLAUDE.md voor mijn portfolio:
- Laat een AI-agent eerst je projectstructuur scannen: mappenstructuur, configuratiebestanden, bestaande componenten en content
- Beschrijf de technische stack en conventies: naamgeving, componentpatronen, CSS-tokens en wat de AI absoluut niet mag aanpassen
- Voeg een tone of voice sectie toe met concrete voorbeelden uit bestaande content, zodat gegenereerde tekst aansluit op jouw schrijfstijl
- Sluit af met een checklist die de AI doorloopt voordat een taak als klaar wordt beschouwd
Een fragment uit mijn eigen CLAUDE.md als voorbeeld:
## Tone of Voice
- Schrijf in het Nederlands, informeel ("je"/"jij"), nooit "u"
- Geen em-dashes (—), gebruik een komma of dubbele punt
- Geen passieve zinnen, altijd actief en persoonlijk
- Sluit secties af met een korte, zelfstandige conclusiezin
## Wat de AI niet mag doen
- Geen React of andere UI-frameworks installeren
- Geen content in het Engels — alle tekst is Nederlands
- Nooit npm run build overslaan voor een taak als klaar wordt gemeld
## Checklist voor elke taak
- [ ] npm run build slaagt zonder fouten
- [ ] Alle tekst is in het Nederlands
- [ ] Afbeeldingen staan in /publicBegin niet met een lege pagina. Laat de AI het bestand opstellen op basis van wat er al is, en verfijn daarna. Dat scheelt een hoop werk en levert meteen een bruikbaar resultaat.
Designers zijn hier eigenlijk al goed voor uitgerust
Als designer ben je gewend om systemen te ontwerpen: design systems, gebruikersstromen, informatiestructuren. Context engineering is eigenlijk hetzelfde, maar dan voor AI. Je ontwerpt de omgeving waarin een AI effectief kan werken.
Dat vraagt een andere mindset dan “hoe formuleer ik dit slim?”. De vraag wordt: wat moet een AI weten om consistent goed werk te leveren? Welke regels gelden er? Wat is de toon? Wat zijn de grenzen? Designers zijn, misschien meer dan wie dan ook, al gewend om dat soort vragen te beantwoorden. We doen het alleen nog te weinig voor onze AI-tools.
Tip van Tai:
Begin klein. Maak één contextbestand voor een project waar je regelmatig mee werkt. Beschrijf daarin:
- Wat het project is en voor wie
- Welke tone of voice en schrijfstijl je hanteert
- Welke tools, stack en conventies er gelden
- Wat de AI absoluut niet mag doen of veronderstellen
Geen perfecte structuur nodig om te beginnen. Je merkt al na één sessie dat je minder hoeft te herhalen en dat de output dichter bij wat je bedoelt zit.
De prompt is het startpunt, niet het fundament
Prompt engineering blijft waardevol. Een goede vertrekpunt, maar niet het fundament. Wie alleen leert beter te prompten, bouwt een sterker startblok. Wie de context goed inricht, bouwt een betere baan.
De verschuiving van prompt naar context is subtiel, maar de impact is groot. En het mooie is: designers denken al in systemen. We hoeven alleen te leren dat AI-tools ook systemen zijn die je kunt, en eigenlijk moet, inrichten.