AI voor programmeren gebruiken: workflows die risico verkleinen

Regels voor veilige AI-hulp bij programmeren

De beste manier om AI voor programmeren te gebruiken is hem trager te maken op precies die momenten waarop gokken gevaarlijk is. AI kan onbekende code uitleggen, foutmeldingen omzetten in hypotheses, tests opstellen, diffs beoordelen en refactors voorstellen. AI kan ook API's verzinnen, verborgen afhankelijkheden missen, te sterk vastklampen aan het geplakte fragment, of een patch produceren die er netjes uitziet terwijl hij gedrag verandert dat je juist wilde behouden.

Hanteer deze regel: AI mag voorstellen doen, maar je repository beslist. De bron van waarheid is de codebase, de falende reproductie, de testsuite, de runtimelogs, de producteisen en menselijke review. Een goede AI-programmeerpartner helpt je redeneren vanuit die artefacten in plaats van ze te vervangen.

Regel	Waarom het uitmaakt	Wat je het model vraagt
Eerst reproduceren	Voorkomt willekeurige patches	"Herhaal het falende gedrag en het bewijs voordat je code voorstelt."
Houd de scope klein	Verkleint het regressierisico	"Stel de kleinste veilige wijziging voor en noem de geraakte bestanden."
Behoud gedrag	Beschermt gebruikers en contracten	"Benoem de invarianten die deze wijziging niet mag breken."
Eis tests	Maakt het antwoord verifieerbaar	"Schrijf tests die falen vóór de fix en slagen erna."
Review vóór de merge	Vangt zelfverzekerde fouten	"Beoordeel deze diff op correctheid, security en gemiste randgevallen."

Dit geldt voor alle modellen. OpenAI, Anthropic en andere aanbieders publiceren modeldocumentatie waarin verschillende mogelijkheden, contextvensters en patronen voor tool use staan beschreven. Die mogelijkheden zijn nuttig, maar ze vervangen geen gedisciplineerde workflow. Beoordeel modellen voor engineeringwerk met dezelfde maatstaf als een collega: vragen ze om ontbrekende context, verkleinen ze onzekerheid, respecteren ze de randvoorwaarden, en laten ze een spoor achter dat jij kunt controleren?

Workflow voor debuggen

Een betrouwbare AI-workflow voor debuggen heeft vijf fasen: reproduceren, isoleren, hypotheses opstellen, patchen en verifiëren. Begin niet met "los dit op". Begin met het bewijs. Geef het model het falende commando, de exacte foutmelding, het verwachte gedrag, het waargenomen gedrag, de relevante code, details over de omgeving en elke recente wijziging die het probleem veroorzaakt kan hebben.

Fase 1: leg de reproductie vast. Voor backendcode geef je het request, de response, de statuscode, de logs en de falende test. Voor frontendcode geef je de route, de handeling van de gebruiker, de fout in de browserconsole, de netwerkrespons, de state van het component en zo nodig een beschrijving van de screenshot. Voor buildproblemen geef je het commando, de packagemanager, de Node-versie en de volledige fout rond het eerste falen.

Fase 2: vraag om hypotheses voordat er code komt. Een zorgvuldig model rangschikt de waarschijnlijke oorzaken en vertelt welk bewijs elke oorzaak ondersteunt. Kan het geen onderscheid maken tussen oorzaken, vraag dan om de kleinste diagnostische stap. Dat kan een log zijn, een gerichte test, een typecheck of nog één bestand lezen.

Fase 3: vraag om de kleinste patch. Zeg het model dat het geen variabelen mag hernoemen, omliggende code mag herschrijven, afhankelijkheden mag toevoegen of publiek gedrag mag veranderen tenzij het kan onderbouwen waarom. Vraag om de grondoorzaak, de opzet van de patch, de geraakte bestanden, de tests en het risico.

Fase 4: draai de tests lokaal. Output van AI is geen verificatiestap. De verificatiestap is het commando of het gebruikerspad dat het gedrag bewijst. Bestaat er geen geautomatiseerde test, vraag het model dan eerst een regressietest te maken en implementeer daarna de fix.

Prompt voor debuggen:

Gedraag je als een zorgvuldige debugpartner. Schrijf nog geen code. Herhaal eerst de reproductie, het verwachte gedrag, het waargenomen gedrag en de drie waarschijnlijkste grondoorzaken. Rangschik elke oorzaak op bewijs. Stel daarna de kleinste diagnostische stap voor. Bug: [beschrijf]. Commando of handeling: [plak]. Fout/logs: [plak]. Relevante code: [plak]. Randvoorwaarden: [stack, bestanden die je niet mag raken, gedrag dat behouden moet blijven].

Prompt voor de fix:

Stel op basis van de bevestigde grondoorzaak de kleinste veilige fix voor. Geef terug: grondoorzaak, bestanden/functies die veranderen, opzet van de patch, tests die falen vóór en slagen na, randgevallen en risico bij terugdraaien. Refactor geen ongerelateerde code. Context: [plak].

Workflow voor code review

AI is vaak beter als reviewer dan als eerste auteur. Vraag je om een diff te beoordelen, dan kan hij gemiste randgevallen, beveiligingsproblemen, verouderde aannames, gaten in de tests en gedragsveranderingen opsporen. De sleutel is de review specifiek maken. Vraag je "ziet dit er goed uit?", dan krijg je beleefde goedkeuring. Vraag je naar het risico op onjuistheden, dan is de kans veel groter dat je bruikbare bezwaren terugkrijgt.

Geef het model de diff, het bedoelde gedrag, de bijbehorende tests en eventuele randvoorwaarden. Vraag het kleine stijlkwesties te negeren tenzij die de onderhoudbaarheid raken. Je wilt dat de review bugs vooropstelt, niet ijdele muggenzifterij.

Reviewgebied	Vragen die AI moet beantwoorden
Correctheid	Voldoet de diff echt aan de eis?
Regressierisico	Welk bestaand gedrag kan per ongeluk veranderen?
Security	Zijn input, auth, secrets, rechten en injectierisico's afgedekt?
Foutafhandeling	Wat gebeurt er bij null, timeouts, retries, foute responses of halve state?
Tests	Welke beweringen over gedrag zijn niet gedekt?
Onderhoudbaarheid	Volgt dit de lokale patronen en blijft de wijziging begrijpelijk?

Prompt voor code review:

Beoordeel deze diff als een strenge maar praktische maintainer. Focus op correctheid, regressierisico, security, randgevallen en ontbrekende tests. Negeer kleine stijlkwesties tenzij ze echt onderhoudsrisico opleveren. Geef een tabel terug met issue, prioriteit, bewijs uit de diff, voorgestelde fix en benodigde test. Bedoeld gedrag: [plak]. Diff: [plak]. Bestaande tests: [plak].

Gebruik bij wijzigingen met een hoog risico een workflow in Whizi waarin je de fixes van modellen vergelijkt. Draai dezelfde reviewprompt bij twee of drie modellen. Vindt één model een mogelijk probleem, neem dat dan niet blind aan; controleer of het probleem in de codebase echt bestaat. Het doel is niet om meer meningen te verzamelen. Het doel is het reviewoppervlak vergroten voordat je merget.

Workflow voor refactoren en tests

Refactoren met AI is riskant, omdat veel refactors juist worden beoordeeld op wat er niet verandert. Het model maakt de code misschien mooier terwijl het subtiel het gedrag, de foutafhandeling, de timing of de publieke contracten verandert. Een veiliger refactorworkflow begint met het vastleggen van invarianten voordat je de implementatie aanraakt.

Stap 1: beschrijf het doel van de refactor. Voorbeelden: duplicatie verminderen, een groot component opsplitsen, datatoegang isoleren, vertakkingen vereenvoudigen, een API-wrapper migreren of de testbaarheid verbeteren. Benoem daarna wat hetzelfde moet blijven: publieke functiesignaturen, gedrag van routes, namen van events, de vorm van responses, analytics, rechten, toegankelijkheidsgedrag en verwachtingen rond performance.

Stap 2: vraag om een gefaseerd plan. Een bruikbaar AI-refactorplan is omkeerbaar. Elke fase raakt een klein gebied, bevat tests en levert een werkende tussentoestand op. Vermijd herschrijvingen in één klap, tenzij de code klein is en goed gedekt.

Stap 3: schrijf characterization tests. Vraag AI, voordat je code verandert, om het huidige gedrag vast te stellen en tests op te stellen die de belangrijke gevallen vastzetten. Die tests zijn extra nuttig bij legacycode waarvan de bedoeling onduidelijk is. Ze horen normale input, grensgevallen, faalpaden en één regressiegeval te bevatten dat aansluit op de reden voor de refactor.

Stap 4: implementeer één fase tegelijk. Draai na elke fase de tests en vraag om een gerichte review. Stelt het model een brede abstractie voor, laat het dan bewijzen dat die abstractie echte duplicatie of echt risico wegneemt. Houd de code anders saai en lokaal.

Prompt voor het refactorplan:

Maak een gefaseerd refactorplan. Doel: [doel]. Huidige code: [plak]. Randvoorwaarden: behoud publiek gedrag, minimaliseer churn, volg bestaande patronen, vermijd nieuwe afhankelijkheden, houd elke fase testbaar. Geef terug: invarianten, afhankelijkheidsoverzicht, fasen, geraakte bestanden, tests per fase, risico bij terugdraaien en reviewchecklist.

Prompt voor unittests:

Schrijf tests vóór de wijzigingen in de implementatie. Gebruik de bestaande teststijl die hier staat: [plak]. Gedrag dat behouden moet blijven: [plak]. Code die getest wordt: [plak]. Geef testnamen, setup, input, verwacht resultaat en waarom elke test ertoe doet. Neem het happy path, een grensgeval, een foutgeval en een regressiegeval op.

Promptsjablonen

Sterke prompts voor programmeren zijn niet lang omdat ze chic zijn. Ze zijn lang genoeg om dubbelzinnigheid weg te nemen. Het model heeft rol, taak, context, randvoorwaarden, uitvoerformaat en verificatiecriteria nodig. Bewaar de prompts die werken, zodat AI een herhaalbare engineeringworkflow wordt in plaats van een eenmalig gesprek.

Prompt om code uit te leggen:

Leg deze code uit voor een ontwikkelaar die nieuw is in het project. Behandel doel, input, output, dataflow, afhankelijkheden, faalmodi en tests die het vertrouwen zouden vergroten. Scheid feiten die zichtbaar zijn in de code van aannames. Code: [plak].

Prompt voor veilige code:

Beoordeel deze code op beveiligingsrisico's. Focus op auth, rechten, injectie, secrets, validatie, onveilige redirects, bestandsverwerking, risico in afhankelijkheden en blootstelling van gevoelige data. Geef alleen issues terug, met bewijs, impact, voorgestelde fix en test of handmatige controle. Code/diff: [plak].

Prompt om modelfixes te vergelijken:

Ik vergelijk AI-modellen voor een programmeertaak. Gebruik alleen de gegeven context. Geef terug: grondoorzaak, kleinste veilige fix, tests, risico's, aannames en vragen. Geef je vertrouwen een cijfer van 1 tot 5 en noem welk bewijs je antwoord zou veranderen. Taak: [plak]. Context: [plak].

QA-checklist voordat je door AI gegenereerde code accepteert:

• Het model heeft de taak correct herhaald.
• De patch is kleiner dan het probleem, niet groter.
• Publiek gedrag en contracten zijn benoemd.
• De tests dekken de bug of het refactordoel rechtstreeks.
• Randgevallen en faalpaden staan opgesomd.
• Beveiligingsgevoelige input is beoordeeld.
• De diff volgt de bestaande patronen van het project.
• Je hebt de relevante test, lint, build of handmatige reproductie gedraaid.
• Een mens heeft de definitieve diff beoordeeld.

Whizi is handig als je fixes wilt vergelijken zonder de taak te veranderen. Plak dezelfde prompt voor debuggen of review in meerdere modellen en beoordeel de uitkomsten op bewijs, scope, tests en risico. Begin met ChatGPT-alternatieven voor programmeren als je een gids voor modelkeuze wilt, vergelijk de pakketten op de prijzenpagina, of maak een account aan om de workflow op je eigen code te draaien.