De vier randvoorwaarden die elke prompt hieronder laten werken
Voor de prompts komen de regels die ze allemaal delen. Deze toevoegen aan elke codeerprompt verbetert de output meer dan het wisselen van model.
Geef je versie op. Trainingsdata is vertekend richting de major-versie waarover het meest geschreven is, en dat is vaak niet de versie die jij gebruikt. We gebruiken [framework] [versie], [taal] [versie] voorkomt de meeste verouderde antwoorden.
Beperk de diff. Vraag om een fix en je krijgt vaak een refactor. Verander zo weinig mogelijk, behoud de bestaande structuur en naamgeving, en noem elke regel die je hebt aangepast met een reden van één regel is de meest nuttige zin in dit document.
Vraag om hypotheses voordat je om oplossingen vraagt. Een model dat je vraagt wat er mis is, geeft je een gok die als conclusie wordt gebracht. Een model dat om gerangschikte oorzaken en goedkope checks wordt gevraagd, geeft je een debugplan.
Eis het faalscenario. Wat zou dit kunnen breken, en lost dit de oorzaak op of alleen het symptoom? vangt de duurste categorie AI-hulp op: een wijziging die het symptoom laat verdwijnen terwijl het defect blijft bestaan.
Debuggen
1. Gerangschikte hypotheses
Hier is de fout, de relevante code en wat ik al heb uitgesloten. Geef me nog geen fix. Noem de vier meest waarschijnlijke oorzaken gerangschikt op waarschijnlijkheid, en voor elke de goedkoopste check die het zou bevestigen of uitsluiten. Fout: [plakken]. Code: [plakken]. Al uitgesloten: [lijst]. Stack: [taal, framework, versies].
2. De onregelmatige bug
Dit faalt onregelmatig, ongeveer [frequentie], onder [omstandigheden]. Som alle categorieën van onregelmatig falen op die dit specifieke symptoom kunnen veroorzaken: timing, volgorde, uitputting van resources, een externe dependency, state die lekt tussen runs, klok of tijdzone, caching. Geef voor elke aan wat in de code ervoor pleit of het tegenspreekt, en precies wat ik moet loggen om ze te onderscheiden. Code: [plakken].
3. Het werkt lokaal
Dit werkt lokaal en faalt in [omgeving]. Noem elke categorie omgevingsverschil die dit specifieke symptoom kan veroorzaken: configuratie, omgevingsvariabelen, versies, bestandssysteem en hoofdlettergevoeligheid, tijdzone en locale, netwerk en DNS, rechten, resourcelimieten, en build- of bundelverschillen. Rangschik op waarschijnlijkheid gegeven het symptoom, en geef me voor elke het diagnostische commando.
4. Leg de fix uit voordat ik hem toepas
Leg uit waarom deze fix werkt, wat hij niet oplost, en wat hij zou kunnen breken. Als de echte oorzaak elders ligt en dit een symptoompatch is, zeg dat dan direct.
Code review
5. Review een diff
Beoordeel deze diff als een veeleisende reviewer. Categorieën in prioriteitsvolgorde: correctheidsbugs, security issues, onafgehandelde faalscenario's, race conditions, dan stijl. Geef voor elke bevinding de ernst, de specifieke regel, en waarom het in deze codebase relevant is in plaats van in het algemeen. Geef geen commentaar op opmaak. Als de diff solide is, zeg dat dan in plaats van bevindingen te verzinnen. Conventies: [beschrijven]. Diff: [plakken].
6. De securitycheck
Beoordeel deze code specifiek op security issues: injectie, gaten in authenticatie en autorisatie, onveilige deserialisatie, secrets in code of logs, ongevalideerde input die een gevoelige operatie bereikt, en dependency risico. Geef voor elke het aanvalspad concreet in plaats van alleen de categorie te noemen. Geef duidelijk aan wat je niet kunt beoordelen zonder [deployment, authlaag, datagevoeligheid] te zien.
7. De faalscenario-audit
Geef voor elke externe call in deze code aan wat er gebeurt als hij traag is, als hij faalt, als hij onverwachte data teruggeeft, en als hij gedeeltelijk slaagt. Welke daarvan worden nu niet afgehandeld, en welke zouden stil falen?
Die laatste vindt meer echte productieproblemen dan een algemene review, omdat hij vraagt naar de paden waar niemand een test voor schreef.
Refactoring en architectuur
8. Het refactorplan
Stel een gefaseerd plan voor om [beschrijving] te refactoren. Randvoorwaarden: de publieke API van [x] mag niet veranderen, we deployen continu dus elke stap moet los shipbaar zijn, en tests moeten na elke stap slagen. Geef voor elke stap de wijziging, het risico, hoe je het verifieert, en hoe je het terugdraait. Rangschik op risico, laagste eerst. Schrijf de code nog niet.
9. Verdedig de andere kant
Ik kies [aanpak A] boven [aanpak B] voor [context en randvoorwaarden]. Maak het sterkste argument voor B. Wat zou waar moeten zijn over onze randvoorwaarden om B correct te maken, en is iets daarvan hier waar? Concludeer niet dat beide geldig zijn.
10. Begrijp wat je hebt geërfd
Hier zijn de belangrijkste sourcebestanden. Lever: de entry points, de dataflow van request naar response, de state die gedeeld wordt en waar die gemuteerd wordt, externe dependencies en wat er gebeurt als elk onbeschikbaar is, en de drie gebieden die op basis van complexiteit en koppeling het meest waarschijnlijk bugs bevatten. Geef expliciet aan wat je niet kunt bepalen op basis van wat ik heb aangeleverd.
Die laatste instructie is belangrijk. Modellen beschrijven het gedrag van een bestand dat je niet hebt geplakt, afgeleid uit de naam. Door een expliciete lijst met onbekenden af te dwingen, weet je wat je nog moet lezen.
Tests
11. De tests die je zelf niet had geschreven
Schrijf testcases voor deze functie, gericht op inputs die ik waarschijnlijk niet heb overwogen: grenswaarden, leeg en null, unicode, zeer grote waarden, gelijktijdige calls, en elke impliciete aanname in de implementatie. Geef voor elke test aan welke aanname hij controleert. Functie: [plakken].
12. Test de testsuite
Hier is een functie en de bestaande tests. Welk gedrag wordt niet gedekt? Specifiek: foutpaden, grenswaarden, interacties tussen parameters, en alles wat de implementatie doet dat geen enkele test controleert. Herschrijf de bestaande tests niet.
De tweede is de waardevollere prompt en wordt zelden gebruikt. Coveragepercentages vertellen je welke regels zijn uitgevoerd, niet welk gedrag daadwerkelijk is vastgelegd, en in dat gat tussen die twee leven de regressies.
Het second-opinion patroon
De gewoonte met de meeste impact in dit hele pakket, en de enige die meer dan één model vereist.
Krijg een antwoord van één model. Wissel dan van model en geef het door:
Een andere engineer stelde deze oplossing voor dit probleem voor. Zoek wat eraan schort: correctheid bij edge cases, concurrency, foutafhandeling, prestaties bij [schaal], of een eenvoudigere aanpak die gemist is. Als het écht solide is, zeg dat dan gewoon in plaats van bezwaren te verzinnen. Probleem: [plakken]. Voorgestelde oplossing: [plakken].
Twee uitkomsten en beide zijn nuttig. Ofwel vindt het tweede model een echt gat, en dat weet je nu voordat je merget, ofwel het is het eens ondanks dat het werd aangespoord om het oneens te zijn, wat een betekenisvolle bevestiging is. Itereren met hetzelfde model levert geen van beide op, omdat een model dat zijn eigen output beoordeelt het meestal met zichzelf eens is.
Gebruik het voor beslissingen die duur zouden zijn om verkeerd te doen: een schemawijziging, een concurrencyfix, alles wat auth of geld raakt. Niet voor routinewerk. Zie modellen naast elkaar vergelijken, tussen modellen wisselen tijdens een gesprek, en code schrijven en debuggen met meerdere modellen voor de hele workflow op één plek.
Waar je op moet letten
Verzonnen API's. Zelfverzekerde methodenamen, parameters en configsleutels die niet bestaan, vooral voor libraries die recent zijn veranderd. De signatuur zal er juist uitzien. Controleer de echte documentatie voordat je bouwt op iets onbekends.
Geen zekerheidssignaal. Een correcte fix en een subtiel foute fix komen met identieke zekerheid. De toon vertelt je niets.
Stille scope creep. Daarvoor bestaat randvoorwaarde twee.
Security theater. Kwetsbaarheidsklassen in je code benoemen is een nuttige eerste stap. Het is geen audit, en het model kent je threat model, deployment of datagevoeligheid niet.
Bewaar de prompts die je wekelijks gebruikt ergens waar je ze vandaan kunt plakken, en zet vaste randvoorwaarden in de instructies van een project zodat ze automatisch gelden voor elke chat in dat project.
- Geef je taal, framework en versie op in elke codeerprompt
- Voeg de beperk-de-diff-zin toe aan elke prompt die code produceert
- Vraag om gerangschikte hypotheses en goedkope checks voordat je om een fix vraagt
- Vraag altijd wat een fix zou kunnen breken en of hij het symptoom behandelt
- Gebruik het second-opinion patroon voor alles wat duur is om verkeerd te doen
- Vraag wat de bestaande testsuite niet dekt, niet alleen om meer tests
- Controleer onbekende API's aan de hand van de echte documentatie
- Bewaar de prompts die je wekelijks gebruikt op een plek waar je ze kunt plakken
Veelgestelde vragen
Werken deze prompts alleen met Claude?
Nee. Ze zijn geschreven voor de long-context, zorgvuldig-redenerende stijl waar Claude goed in is, maar ze werken ook direct met GPT en Gemini. Sterker nog, sommige zijn juist beter over modellen heen te gebruiken: de second-opinion prompt vereist er twee, en de "verdedig de andere kant"-prompt is nuttiger wanneer het model dat argumenteert niet de oorspronkelijke keuze heeft gemaakt.
Welk model moet ik voor welke prompt gebruiken?
Als uitgangspunt: Claude voor subtiel redeneren, onbekende architectuur, en uitleggen waarom iets zich gedraagt zoals het doet; GPT voor snelle implementatie op bekend terrein en strikte gestructureerde output; een large-context model wanneer de vraag meer code beslaat dan comfortabel in een normale prompt past. Overschrijf dat vervolgens met een week eigen vergelijkingen, want het juiste antwoord hangt meer af van jouw stack dan van welke benchmark dan ook.
Is dit een vervanging voor een agentic coding tool?
Nee, ze lossen verschillende problemen op. Een agent leeft in je repository en bewerkt bestanden. Deze prompts zijn voor de redeneerlaag: een fout begrijpen, een diff beoordelen, een refactor plannen, over een aanpak discussiëren. De meeste developers gebruiken beide, en modelkeuze is hier belangrijker omdat je de redenering beoordeelt in plaats van de uiteindelijke diff.
Hoe voorkom ik dat het code herschrijft waar ik niet om heb gevraagd?
Voeg dit toe aan de prompt: verander zo weinig mogelijk, behoud de bestaande structuur en naamgeving, en noem elke regel die je hebt aangepast met een reden van één regel. Ongevraagde refactoring is de belangrijkste reden dat AI-suggesties onbeoordeelbaar worden, en het beperken van de diff maakt het verschil tussen een wijziging waarover je kunt redeneren en een die je van voren af aan moet herlezen.
Kan ik eigen, vertrouwelijke code plakken?
Whizi traint niet op je gesprekken en het databeleid van elke provider is te bekijken voordat je dat model inschakelt, maar het beleid van je werkgever is de bindende randvoorwaarde en dat verschilt sterk. Waar restricties gelden, is het reproduceren van het probleem als een minimaal voorbeeld dat de structuur behoudt en de businesslogica weglaat meestal zowel toegestaan als een betere prompt, omdat het de details verwijdert die om aandacht concurreerden.