Prompt Engineering voor Code: 7 Patronen die We Dagelijks Gebruiken in Claude Code en Cursor (2026)

Prompt engineering voor code is het verschil tussen een agent die een werkende pull request oplevert en een agent die stilletjes iets in productie kapotmaakt. Dat hebben we op de dure manier geleerd: één vage instructie in onze eigen pipeline zorgde ooit voor 54 dubbele live pagina's voordat iemand het merkte. Tegenwoordig schrijft, vertaalt en publiceert een setup van 16 Claude Code agents onze content, en de prompts die daarachter zitten lijken totaal niet op de lijsten met 50 templates die je op de eerste pagina van Google vindt. Dit zijn de 7 patronen die we elke dag typen, elk met een echte voor-en-na.

Kort antwoord: Goede coding prompts delen één vorm. Je benoemt het doel en de definitie van "klaar", noemt de exacte bestanden binnen scope, dwingt een plan af vóór elke wijziging, geeft de tests mee en eist bewijs in plaats van een "ziet er goed uit". Doe dat en een moderne agent (Claude Code, Cursor, GitHub Copilot) schrijft code die veel vaker in één keer door de review komt. Sla het over en je krijgt zelfverzekerde, plausibele onzin.

De 7 patronen, in de volgorde waarin we ze gebruiken:

1. Taakkadering: doel, beperkingen en "klaar" vooraf
2. Contextselectie: benoem de bestanden, sluit de rest af
3. Eerst plannen: laat het voorstellen voordat het bewerkt
4. Eerst tests: zet de acceptatietests in de prompt
5. Debuggen: fout plus reproductie plus verwachting, oorzaak vóór fix
6. Refactoren: verander de structuur, behoud het gedrag, toon de diff
7. Review: een checklist om tegen te greppen, plus bewijs

Prompt Engineering voor Code vs. Configuratiebestanden: Wat Hoort Waar

Configuratiebestanden en per-taak prompts doen ander werk, en ze door elkaar halen is de meest gemaakte fout in dit vakgebied. Een CLAUDE.md of een .cursor/rules bestand is staand beleid dat de agent elke sessie leest: je stack, je naamgevingsconventies, je testcommando. Een prompt is de specifieke taak die je nu meegeeft. Duurzame regels horen in de configuratie, de taak hoort in de prompt.

De meeste overzichten van "coding prompts" halen dit door elkaar en adviseren om een enorme persona-prompt in .cursorrules te plakken. Dat maakt de configuratie die de agent bij elke taak laadt onnodig zwaar en kadert de taak van dit moment nog steeds niet. Houd de twee gescheiden:

Als je de configuratiekant goed wilt aanpakken, behandelen we dat uitgebreid in onze CLAUDE.md best practices en Cursor rules gids. Dit artikel is de andere helft: de prompts die je elke keer opnieuw typt. Beide vallen onder onze bredere prompt engineering gids als je eerst de basis wilt.

Prompt Engineering voor Code: De 7 Patronen die We Dagelijks Gebruiken

Elk patroon hieronder heeft de zwakke versie die mensen in de praktijk typen en de sterke versie die werkende code oplevert. Het gat tussen zwak en sterk is bijna altijd dezelfde beweging: vervang een wens door een specificatie.

1. Taakkadering: Benoem het Doel, de Beperkingen en "Klaar"

Taakkadering betekent dat je het doel, de beperkingen en hoe "klaar" eruitziet opschrijft voordat de agent ook maar één regel aanraakt. Een agent optimaliseert voor wat je letterlijk hebt gevraagd, dus een vaag verzoek levert een vage patch op. Benoem het bestand, het gewenste gedrag, de acceptatiecheck en de dingen die niet mogen veranderen.

Dit is het patroon dat ons 54 pagina's kostte. Onze oude vertaalinstructie was in feite gewoon een wens:

Zwak: Vertaal deze post opnieuw naar het Duits en behoud de merknamen.

Nergens staat wat een slug wel of niet mag doen. Dus bij een herrun "verbeterde" de agent de URL-slug, en omdat een nieuwe slug een nieuw document betekent, hadden we ineens twee live Duitse pagina's voor dezelfde post. Vermenigvuldig dat over talen en oude posts en je hebt 54 duplicaten en een stapel uitsluitingen wegens dubbele content. De oplossing was een specificatie, geen aardigere wens:

Sterk: Vertaal deze post opnieuw naar het Duits.
- Als er al een Duits bestand bestaat, kopieer dan de bestaande slug
  woordelijk. Nooit opnieuw afleiden of "verbeteren".
- Zoek, voordat je een document aanmaakt, het bestaande document op via zijn
  canonieke referentie en hergebruik dat record.
- Als de slug die je zou genereren afwijkt van de live slug, STOP dan en
  meld dit. Een gewijzigde slug creëert een tweede live URL voor dezelfde
  pagina.

De sterke prompt benoemt het faalscenario expliciet. Die ene gewoonte, hardop zeggen wat er niet mag gebeuren en waarom, is de meest waardevolle verandering die de meeste teams kunnen doorvoeren. We sluiten elke taakprompt ook af met een expliciet outputcontract ("je laatste bericht moet het aantal woorden, de validatiescore en de aangeraakte bestanden rapporteren"), zodat de agent weet wat "klaar" oplevert, niet alleen wat er gedaan moet worden.

2. Contextselectie: Benoem de Bestanden, Sluit de Rest Af

Contextselectie betekent dat je de agent precies vertelt welke bestanden hij moet lezen en welke hij met rust moet laten, in plaats van hem zelf te laten zoeken en zijn venster met ruis te laten vollopen. Anthropic is er zelf duidelijk over: het contextvenster raakt snel vol en de kwaliteit daalt naarmate het voller raakt, dus de meeste best practices bestaan om dat venster te beschermen (Claude Code best practices).

Zwak: Fix de bug in de checkout-flow.

Sterk: Lees alleen src/checkout/cart.ts en src/checkout/tax.ts. De
belastingafronding klopt niet bij bestellingen boven €1.000 (elke regel
wordt apart afgerond in plaats van het totaal van de bestelling). Fix de
afronding. Raak niets aan buiten src/checkout/.

Wij sluiten hard af. Een echte regel uit onze agent-prompts luidt: "schrijf niet naar url-mapping.json, pipeline.md of config.json, en raak nooit een bestand buiten je scratchpad-map aan." Die ene zin heeft meer onbedoelde schade voorkomen dan welke opruimactie achteraf dan ook. Als een taak echt live documenten of extra tools nodig heeft, voegen we die bewust toe via MCP-servers in plaats van te hopen dat de agent toevallig het juiste bestand vindt. En als die context van buiten je repo komt, behandel het dan als niet-vertrouwd: lees onze notitie over prompt injection voorkomen voordat je een gescrapete pagina in een coding agent plakt.

3. Eerst Plannen: Laat het Voorstellen Voordat het Bewerkt

Eerst-plannen prompting laat de agent eerst een aanpak voorleggen voordat hij iets bewerkt. In Claude Code is Plan Mode een harde, afgedwongen alleen-lezen status, geen beleefd "denk eerst even na" waar het model omheen kan wandelen, waardoor het letterlijk niets kan schrijven totdat je het plan goedkeurt. Onderzoek en planning scheiden van uitvoering is de praktijk waar Anthropic het meest op leunt om te voorkomen dat het verkeerde probleem wordt opgelost.

Zwak: Voeg rate limiting toe aan de API.

Sterk: Geef me, voordat je code schrijft, een genummerd plan: welke
middleware, waar de tellers leven, hoe je de 429-response en headers
afhandelt, en welke tests je toevoegt. Wacht op mijn goedkeuring voordat
je iets bewerkt.

Waarom het werkt: het plan is goedkoop om te lezen en goedkoop om te corrigeren. Een verkeerd plan repareren kost één zin; verkeerde code repareren kost een hele reviewronde. Dit sluit natuurlijk aan bij het model eerst stap voor stap laten redeneren (zie chain-of-thought prompting), en het is de ruggengraat van de meerstaps Claude Code workflows die we draaien voor alles wat niet-triviaal is.

4. Eerst Tests: Zet de Acceptatietests in de Prompt

Eerst-tests prompting zet de acceptatiecriteria als concrete input en output in de prompt, zodat de agent code schrijft tegen een doel dat jij hebt bepaald in plaats van een doel dat hij zelf raadt. Plak de falende test, of een kleine tabel met verwachte resultaten, en zeg "laat deze slagen zonder de test te wijzigen".

Zwak: Schrijf een functie om ISO 8601-datums te parsen.

Sterk: Laat deze falende test slagen zonder de test te wijzigen:

  parseIso("2026-07-20T15:00:00Z")   -> Date op dat exacte UTC-moment
  parseIso("2026-07-20")             -> Date op 2026-07-20T00:00:00Z
  parseIso("not-a-date")             -> gooit RangeError
  parseIso("")                       -> gooit RangeError

Geef alleen de functie en de imports terug.

Concrete voorbeelden verslaan bijvoeglijke naamwoorden altijd. "Handel edge cases af" is een hoop; vier input-naar-output regels zijn een specificatie die het model daadwerkelijk kan halen, en je kunt ze meteen draaien zodra de code binnenkomt.

5. Debuggen: Fout, Reproductie, Verwachting, Oorzaak Vóór Fix

Een debug-prompt geeft de agent de foutmelding, de input die de fout veroorzaakt en wat je had verwacht, en vraagt daarna om de oorzaak vóór welke fix dan ook. Sla dat over en de agent patcht het symptoom, waardoor de bug gewoon ergens anders opduikt, iets stiller.

Zwak: Dit gooit een fout, fix het.

Sterk: Dit gooit een fout bij checkout. Hier is de stack trace: [plakken].
Het gebeurt alleen als de winkelwagen een kortingscode ÉN een cadeaubon
heeft (reproductie: voeg beide toe, ga dan naar checkout). Verwacht: beide
worden toegepast, cadeaubon als laatste. Zoek de oorzaak en leg die in één
zin uit voordat je iets verandert. Verstop het niet in een try/catch die
de fout onderdrukt.

De regel "leg de oorzaak eerst in één zin uit" doet echt werk. Ze dwingt het model om zich vast te leggen op een diagnose die je zelf kunt controleren, in plaats van een fix te leveren waarvan je de logica nooit ziet. De regel "verstop het niet in een try/catch" sluit het meest gebruikte achterdeurtje af.

6. Refactoren: Verander de Structuur, Behoud het Gedrag, Toon de Diff

Een refactor-prompt beperkt de scope hard: verander de structuur, houd het gedrag identiek en toon de diff. Zonder die afbakening gaan agents dingen "opruimen" waar je nooit om hebt gevraagd, en verlies je het overzicht over de wijziging die er echt toe deed.

Zwak: Ruim dit bestand op.

Sterk: Haal de validatielogica uit submitOrder() en zet die in een pure
functie validateOrder(). Houd elke publieke signature en al het gedrag
identiek. Verander verder niets in dit bestand. Laat me een voor/na-diff
zien en één regel over waarom elke wijziging gedrag-behoudend is.

Dit is de andere kant van de configuratie-versus-prompt splitsing van eerder: je staande stijlregels leven in Cursor rules, maar de scope van deze refactor hoort in de prompt. "Verander verder niets" is de zin die refactors reviewbaar houdt.

7. Review: Een Checklist om Tegen te Greppen, Plus Bewijs

Een reviewprompt geeft de agent een checklist om tegen te greppen en eist bewijs, geen oordeel. "Ziet er goed uit" is waardeloos; het commando dat is uitgevoerd en de output die daaruit kwam is dat niet. Anthropic zegt het gewoon rechttoe rechtaan: laat de agent bewijs tonen (de testoutput, het commando en het resultaat) in plaats van succes te beweren, want bewijs lezen gaat sneller dan het zelf opnieuw controleren.

Zwak: Review mijn PR.

Sterk: Controleer deze diff tegen precies deze vijf punten:
1. Geen secrets of API-keys toegevoegd
2. Elke nieuwe functie heeft een test
3. Geen gedragsverandering buiten src/checkout/
4. Foutpaden geven getypeerde errors terug, geen strings
5. Geen console.log achtergelaten
Citeer bij elk punt de regel die eraan voldoet of het schendt. Draai daarna
de testsuite en plak de output. Zeg niet "klaar"; laat het zien.

Onze eigen reviewpoort is precies zo gebouwd. Voordat een agent mag melden dat een post gepubliceerd is, grept hij de conceptversie tegen een lijst met verboden woorden (een harde blokkade, zero tolerance) en draait hij een query om te bevestigen dat de documentbody niet leeg is. De agent mag succes niet zomaar beweren; hij moet de check-output produceren. Voor reviewersrollen die je vaak hergebruikt, promoveer je de checklist tot een opgeslagen persona, en daar komen system prompt voorbeelden om de hoek kijken.

Claude Code vs. Cursor vs. Copilot: Waar Elk Patroon Leeft

Alle drie de grote agents van 2026 ondersteunen elk patroon hierboven, maar het oppervlak verschilt. Claude Code leunt op Plan Mode en subagents, Cursor op Agent-modus en zijn Agents-venster, en GitHub Copilot op agent-modus plus instructiebestanden. Kies de tool waar je team al in leeft; de patronen dragen probleemloos over.

Een paar actuele details om te kennen. Plan Mode van Claude Code is een echte alleen-lezen vergrendeling, en de subagents draaien elk in een geïsoleerde context met hun eigen tools (subagents docs). De 2026-lijn van Cursor voegde een Agents-venster toe dat parallelle agents opstart, elk in zijn eigen git worktree (Cursor 2.0). De agent-modus van GitHub Copilot leest aangepaste instructies uit .github/copilot-instructions.md, plus padgebonden .instructions.md bestanden met een applyTo-veld (Copilot custom instructions). Als Cursor je dagelijkse tool is, lees dan onze post over Cursor efficiënter gebruiken.

Hoe Wij Onze Coding Agents bij Techsy Prompten

Wij draaien een contentpipeline als een team van 16 Claude Code agents: een onderzoeker, een briefschrijver, een contentschrijver, negen vertalers, een validator en een publisher, gecoördineerd via taakberichten. Twee conventies uit dat systeem gaan één op één over naar elk codeteam.

Ten eerste eindigt elke taakprompt met een outputcontract. De laatste regel is altijd een variant van "je laatste bericht moet X, Y en Z rapporteren." Een agent die precies weet hoe "klaar" eruitziet, dwaalt veel minder af dan een agent die alleen te horen krijgt waar hij moet beginnen.

Ten tweede laten we een agent nooit zijn eigen huiswerk in proza becijferen. Genereren en verifiëren zijn gescheiden stappen, en de verificatie is een commando met output, geen mening. Die scheiding tussen bouwen en controleren is de kern van hoe Anthropic het bouwen van betrouwbare agents beschrijft, en het is waarom onze reviewpoort greept en query't in plaats van een "ziet er goed uit" te vertrouwen.

Dit is ook onze dagelijkse praktijk. Bij Techsy bouwen we AI-agents en automatisering voor B2B-teams, en promptdiscipline zoals dit is het grootste deel van wat een demo onderscheidt van iets dat je bij een klant kunt neerzetten. Wil je dat een coding- of agent-workflow goed wordt opgezet, dan is onze AI-integratiedienst precies daarvoor, en je kunt een gratis consult boeken om je stack door te nemen.

Een Kopieer-en-Plak Prompttemplate om Aan te Passen

Dit is het skelet waarmee we starten voor elke niet-triviale coding-taak. Verwijder de secties die je niet nodig hebt, maar houd de volgorde aan, want die weerspiegelt de zeven patronen.

DOEL
Eén zin: wat moet waar zijn als je klaar bent.

CONTEXT
Lees alleen: <exacte bestanden>. Negeer al de rest.
Relevante feiten: <beperkingen, versies, wat de bug veroorzaakt>.

EERST PLANNEN
Geef me, voordat je bewerkt, een genummerd plan en wacht op goedkeuring.

TESTS / KLAAR
Klaar betekent: <plak falende test of input->output regels>.
Verander de tests niet.

BEPERKINGEN
Houd alle publieke signatures en gedrag identiek tenzij anders vermeld.
Raak <bestanden/gebieden> niet aan. Benoem elke aanname die je maakt.

OUTPUT
Toon een voor/na-diff, draai de tests en plak de output.
Zeg niet "klaar"; laat het bewijs zien.

Sla het op als snippet, of splits het beter: de staande beperkingen gaan naar je configuratiebestand, en het doel, de context en de tests gaan naar de prompt. Die splitsing is precies het hele punt.

Veelgestelde Vragen

Wat is prompt engineering voor code?

Prompt engineering voor code is het schrijven van instructies die een AI-agent aanzetten tot correcte, reviewbare code. In de praktijk betekent dit: het doel en de definitie van "klaar" benoemen, de bestanden binnen scope noemen, een plan afdwingen vóór elke wijziging, tests meegeven en bewijs eisen. Het lijkt meer op het schrijven van een specificatie dan op het bedenken van een slimme zin.

Hoe verschilt dit van een CLAUDE.md of .cursor/rules bestand schrijven?

Configuratiebestanden bevatten staand beleid dat de agent elke sessie leest: je stack, je conventies, je testcommando. Een prompt per taak is de specifieke opdracht die je nu meegeeft. Zet duurzame regels in de configuratie en de taak in de prompt. Hele taakprompts in een configuratiebestand plakken maakt elke sessie zwaarder en kadert de afzonderlijke taak nog steeds niet.

Wat is de beste promptstructuur voor AI coding agents?

Gebruik gelabelde secties in plaats van één alinea: DOEL, CONTEXT, PLAN, TESTS, BEPERKINGEN en OUTPUT. Agents verwerken gestructureerde prompts betrouwbaarder dan lopende tekst. Benoem de succescriteria vooraf, geef één tot drie concrete voorbeelden in plaats van bijvoeglijke naamwoorden, en specificeer het exacte outputformaat dat je terug wilt.

Hoe schrijf ik een goede debug-prompt?

Geef de agent vier dingen: de exacte foutmelding of stack trace, de input die de fout reproduceert, wat je had verwacht, en een verzoek om de oorzaak vóór welke fix dan ook. Voeg "leg de oorzaak eerst in één zin uit voordat je iets verandert" toe zodat je de diagnose kunt controleren, en "verstop het niet in een try/catch" zodat de agent fixt in plaats van maskeert.

Moet ik tests opnemen in mijn coding prompts?

Ja, waar mogelijk. De falende test plakken, of een kleine tabel met input-naar-output regels, verandert een vaag verzoek in een doel dat het model daadwerkelijk kan raken, en je kunt het resultaat meteen draaien. Zeg tegen de agent dat hij de tests moet laten slagen zonder ze te wijzigen, zodat hij de doelpalen niet kan verzetten om zijn eigen code goed te laten lijken.

Werken deze prompts ook in Cursor en GitHub Copilot?

Ja. De patronen zijn tool-onafhankelijk. Claude Code toont ze via Plan Mode en subagents, Cursor via Agent-modus en zijn Agents-venster met een worktree per agent, en GitHub Copilot via agent-modus plus .github/copilot-instructions.md. Het oppervlak verandert; taakkadering, contextselectie, eerst plannen en bewijsgedreven review niet.

Hoe lang moet een coding prompt zijn?

Lang genoeg om een specificatie te zijn, kort genoeg om gefocust te blijven. De redeneerkwaliteit daalt naarmate de context voller raakt, dus kies voor structuur boven volume: een gelabelde prompt van 150 tot 300 woorden met de juiste bestanden en tests verslaat een uitweidende prompt. Verplaats alles wat voor elke taak geldt naar je configuratiebestand in plaats van het steeds te herhalen.

Hoe voorkom ik dat een AI-agent code verandert waar ik niet om heb gevraagd?

Bepaal de scope in de prompt. Zeg precies welke bestanden hij mag bewerken, voeg "verander verder niets" toe, en eis "houd alle publieke signatures en gedrag identiek tenzij ik anders zeg". Vraag bij refactors om een voor/na-diff met één regel over waarom elke wijziging gedrag-behoudend is, zodat elke onverwachte wijziging meteen opvalt in de review.

Zijn kant-en-klare promptbibliotheken de moeite waard?

Als startpunt, soms. Als afgewerkte tool, zelden. Een bibliotheek met 50 prompts geeft je bewoordingen, maar kan je bestanden, je tests of je beperkingen niet kennen, en daar zit de correctheid nu juist. Leer de patronen, houd één aanpasbaar template achter de hand, en vul de specifieke details van de taak voor je in.