Claude Code PR-review: diffs vooraf beoordelen sneller en veiliger

Waarom PR-reviewtijden oplopen

PR-reviews duren zelden eeuwig omdat de code "moeilijk" is. Ze duren lang omdat de reviewer intentie, risico en impact uit een diff moet reconstrueren die veranderingen toont, niet het hele verhaal.

Een kleine aanpassing kan verborgen afhankelijkheden raken: hernoem een veld en een rapport breekt, verander een standaardwaarde en het gedrag verschuift, pas een condition aan en foutafhandeling verandert. Reviewtijd groeit wanneer de reviewer rond moet klikken voor context, de app lokaal moet draaien en follow-upvragen moet stellen alleen om te begrijpen wat de PR zou moeten doen.

Er is ook een menselijk patroonprobleem. Mensen scannen diffs op voorspelbare manieren: we focussen op de "hoofd"-verandering en missen de saaie regels waar bugs zich verstoppen (grenscontroles, null-handling, logging, opruimwerk). We hebben ook de neiging te lezen wat we verwachten te zien, dus copy-paste fouten en omgekeerde condities kunnen doorheen glippen.

Een goede pre-review is geen definitief oordeel. Het is een snelle, gestructureerde tweede blik die aangeeft waar een mens moet vertragen. Het beste resultaat is:

• een samenvatting in gewone taal van wat er is veranderd
• specifieke risicopunten (bestanden, functies, aannames)
• leesbaarheidsnotities (naamgeving, verwarrende control flow)
• correctheidszorgen (logica, foutafhandeling, dataconsistentie)
• randgevallen die het waard zijn om te testen (inputs, tijd, permissies, lege toestanden)

Wat het niet moet doen: de PR "goedkeuren", eisen verzinnen, of runtime-gedrag raden zonder bewijs. Als de diff niet genoeg context bevat (verwachte inputs, beperkingen, caller-contracts), moet de pre-review dat aangeven en precies opsommen wat ontbreekt.

AI-hulp is het sterkst bij middelgrote PR's die businesslogica of refactors raken waar betekenis verloren kan gaan. Het is zwakker wanneer het juiste antwoord afhangt van diepe organisatie-specifieke kennis (legacy-gedrag, productie-performance eigenaardigheden, interne beveiligingsregels).

Voorbeeld: een PR die "alleen pagination bijwerkt" verbergt vaak off-by-one pagina's, lege resultaten en niet-overeenkomende sortering tussen API en UI. Een pre-review moet die vragen naar boven halen voordat een mens 30 minuten verspilt om ze opnieuw te ontdekken.

Wat je Claude kunt vragen in een pre-review

Behandel Claude als een snelle, kieskeurige eerste-ronde reviewer, niet als de persoon die beslist of de PR wordt uitgerold. Het doel is problemen vroeg te signaleren: verwarrende code, verborgen gedragsveranderingen, ontbrekende tests en randgevallen die je vergeet als je te dicht bij de wijziging staat.

Geef het wat een redelijke menselijke reviewer zou nodig hebben:

• het doel van de PR (1 tot 3 zinnen)
• wat er absoluut niet mag breken (API-vorm, backwards compatibility, prestatielimiet, veiligheidsregels)
• eventuele speciale beperkingen of afwegingen (deadlines, geleidelijke uitrol)
• de relevante diff-hunks, met voldoende omliggende code om intentie te begrijpen

Als de PR een bekend risicogebied raakt, vermeld dat dan meteen (auth, billing, migrations, concurrency).

Vraag vervolgens om uitvoer waar je concrete acties op kunt ondernemen. Een sterke opdracht ziet er zo uit:

• Vat samen wat er is veranderd in gewone taal.
• Markeer leesbaarheidsproblemen (naamgeving, structuur, verrassingen, inconsistente patronen).
• Identificeer correctheidsrisico's (null-handling, foutpaden, off-by-one, datavorm-mismatch).
• Listeer randgevallen en faalmodi om te testen (timeouts, retries, lege inputs, partiële updates).
• Stel ontbrekende tests voor en wat elke test aantoont.
• Maak een korte checklist voor reviewers en 5 tot 10 "vragen om te stellen" voordat er gemerged wordt.

Houd de mens aan de knoppen door onduidelijkheid te forceren. Vraag Claude bevindingen te labelen als "zeker uit diff" versus "moet bevestigd worden", en laat de exacte regels citeren die elk bezwaar veroorzaakten.

Bereid de diff en context voor voordat je prompt

Claude is maar zo goed als wat je toont. Als je een gigantische diff plakt zonder doel of beperkingen, krijg je algemene adviezen en mis je de echte risico's.

Begin met een concreet doel en succescriteria. Bijvoorbeeld: "Deze PR voegt rate limiting toe aan de login-endpoint om misbruik te verminderen. Het mag de response-vorm niet veranderen. Het moet gemiddelde latency onder 50 ms houden."

Voeg daarna alleen toe wat ertoe doet. Als 20 bestanden zijn gewijzigd maar slechts 3 de logica bevatten, richt je dan op die 3. Voeg omliggende context toe wanneer een snippet misleidend zou zijn, zoals functiesignatures, belangrijke types of config die het gedrag verandert.

Wees tenslotte expliciet over testverwachtingen. Als je unit-tests voor randgevallen wilt, een integratietest voor een kritisch pad, of een handmatige UI-check, zeg het. Als tests opzettelijk ontbreken, vermeld waarom.

Een eenvoudig "contextpakje" dat goed werkt:

• PR-doel: wat verandert, wat ziet de gebruiker, wat moet verbeteren
• Relevante diff-chunks: alleen sleutelbestanden, met voldoende omliggende code
• Harde beperkingen: prestatielimieten, compatibiliteitseisen, beveiligings/privacyregels
• Testverwachtingen: wat moet gedekt zijn, wat is toegevoegd, hoe draai je het
• "Mag niet veranderen" items: publieke API-contracten, databaseschema, UX-gedrag, logging/auditing-formaat

Stap-voor-stap: een herhaalbare pre-review flow

Een goede Claude Code PR-review werkt als een korte lus: geef net genoeg context, krijg gestructureerde notities terug, en zet die om in acties. Het vervangt geen mensen. Het vangt makkelijke missers voordat een teamgenoot veel tijd besteedt aan lezen.

De 5-pass flow

Gebruik iedere keer dezelfde passes zodat de resultaten voorspelbaar blijven:

1. Leg de wijziging in gewone taal uit. Vraag Claude het PR te samenvatten: wat doet het, welke bestanden zijn gewijzigd en wat is de waarschijnlijke reden. Als het het niet simpel kan uitleggen, heeft de PR waarschijnlijk een duidelijkere omschrijving of een kleinere scope nodig.
2. Controleer eerst op correctheid. Zoek naar logische fouten, gebroken aannames en stille gedragsveranderingen (standaarden, foutafhandeling, permissies, tijdzones, off-by-one).
3. Scan op missende gevallen. Denk als een gebruiker en als productie: lege inputs, nulls, retries, partiële fouten, concurrency, backwards compatibility.
4. Beoordeel leesbaarheid en onderhoud. Identificeer verwarrende namen, lange functies, gedupliceerde logica, onduidelijke comments en kleine refactors die toekomstige reviewtijd verlagen.
5. Maak reviewcomments met verwijzingen. Groepeer opmerkingen per bestand en voeg een functienaam of geciteerde snippet toe zodat een mens de plek snel vindt.

Na ontvangst van de notities, zet ze om in een korte merge-gate:

Merge-checklist (houd het kort):

• Tests dekken het nieuwe gedrag en ten minste één randgeval
• Fouten worden consistent afgehandeld (en gelogd indien nodig)
• Geen breaking change zonder duidelijk migratiepad
• Naamgeving en structuur passen bij nabijgelegen code
• Risicovolle onderdelen hebben een rollback-plan

Sluit af door te vragen om 3 tot 5 vragen die duidelijkheid afdwingen, zoals "Wat gebeurt er als de API een lege lijst teruggeeft?" of "Is dit veilig bij gelijktijdige requests?"

Gebruik een simpele rubric (leesbaarheid, correctheid, randgevallen)

Claude is het meest behulpzaam wanneer je het een vaste lens geeft. Zonder rubric neigt het ernaar te commenten op wat als eerste opvalt (vaak stijl-nits) en kan het het ene risicovolle grensgeval missen.

Een praktische rubric:

• Leesbaarheid: duidelijke namen, eenvoudige flow, kleine functies, comments die verklaren waarom, geen dode code of achtergebleven debug-output.
• Correctheid: belangrijke invarianten worden afgedwongen, fouten consistent afgehandeld, null/lege waarden veilig, grenzen correct (off-by-one, afronding).
• Randgevallen: lege/zeer grote inputs, ontbrekende optionele velden, tijdzones en zomertijd, retries die dubbel-schrijven riskeren, concurrency races.
• Beveiliging en privacy: auth-checks op de juiste plaats, geen secrets in code/logs, logs lekken geen tokens of gevoelige payloads.
• Compatibiliteit en uitrolveiligheid: oudere clients en opgeslagen data blijven werken, migraties zijn veilig, rollback-plan bestaat.

Wanneer je prompt, vraag om één korte alinea per categorie en verzoek "hoogste risico eerst." Die volgorde houdt mensen gefocust.

Prompt-templates die nuttige reviewnotities opleveren

Gebruik een herbruikbare basisprompt zodat resultaten er consistent uitzien over PR's. Plak de PR-omschrijving en daarna de diff. Als gedrag gebruikersgericht is, voeg de verwachte werking in 1 tot 2 zinnen toe.

You are doing a pre-review of a pull request.

Context
- Repo/service: <name>
- Goal of change: <1-2 sentences>
- Constraints: <perf, security, backward compatibility, etc>

Input
- PR description:
<...>
- Diff (unified diff):
<...>

Output format
1) Summary (max 4 bullets)
2) Readability notes (nits + suggested rewrites)
3) Correctness risks (what could break, and why)
4) Edge cases to test (specific scenarios)
5) Reviewer checklist (5-10 checkboxes)
6) Questions to ask the author before merge (3-7)

Rules
- Cite evidence by quoting the relevant diff lines and naming file + function/class.
- If unsure, say what info you need.

Voor high-risk veranderingen (auth, betalingen, permissies, migraties), voeg expliciet falen- en rollback-denken toe:

Extra focus for this review:
- Security/privacy risks, permission bypass, data leaks
- Money/credits/accounting correctness (double-charge, idempotency)
- Migration safety (locks, backfill, down path, runtime compatibility)
- Monitoring/alerts and rollback plan
Return a “stop-ship” section listing issues that should block merge.

Voor refactors maak je "geen gedragsverandering" een harde regel:

This PR is a refactor. Assume behavior must be identical.
- Flag any behavior change, even if minor.
- List invariants that must remain true.
- Point to the exact diff hunks that could change behavior.
- Suggest a minimal test plan to confirm equivalence.

Als je een snelle scan wilt, voeg dan een limiet toe zoals "Antwoord in minder dan 200 woorden." Als je diepgang wilt, vraag om "tot 10 bevindingen met redenering."

Zet de output om in een reviewer-checklist

Claude's notities worden pas nuttig als je ze omzet in een korte checklist die een mens kan afvinken. Herhaal de diff niet. Leg risico's en beslissingen vast.

Splits items in twee bakken zodat de thread geen voorkeur-discussies wordt:

Moet gefixt worden (merge blokkeren)

• Correctheid: verwachte uitkomst is in één zin geschreven en komt overeen met het ticket
• Randgevallen: null/lege inputs en foutpaden worden duidelijk afgehandeld (of afgewezen)
• Datasafety: schrijfacties en migraties zijn veilig voor bestaande data en oude code
• Tests: ten minste één test dekt het hoofdgedrag en één test dekt het risicovolste geval
• Observeerbaarheid: logs/metrics zijn voldoende om snel te debuggen (request id, user id, job id)

Mooi om te hebben (follow-ups)

• Leesbaarheid: hernoem de meest verwarrende identifier of voeg een korte "waarom"-comment toe
• Consistentie: pas bestaande patronen toe voor fouten, naamgeving en bestandsindeling
• Prestaties: noteer hot-path wijzigingen en of ze relevant zijn op huidige schaal
• Docs: werk inline docs bij als er een nieuwe optie/vlag is toegevoegd

Vang ook rollout-readiness: veiligste deploy-volgorde, waar je op moet letten na release en hoe je de wijziging ongedaan maakt.

Vragen om te stellen voordat je merge

Een pre-review helpt alleen als het eindigt met een kleine set vragen die duidelijkheid afdwingen.

Gedrag en correctheid

• Welk gebruikerszichtbaar gedrag verandert, en wat moet gelijk blijven?
• Als dit "geen gedragsverandering" is, welk bewijs toont aan dat outputs identiek zijn?
• Wat is het meest waarschijnlijke productie-falen, en waar zou het zich tonen (UI, API, data)?
• Welke aannames doet de code over inputs, ordering, tijd of netwerkcalls?
• Worden fouten weggeslikt of omgezet naar stille defaults?

Randgevallen, tests en operatie

• Wat zijn de ergste reële inputs (lege, enorme, malformed, duplicaat), en wat zou er moeten gebeuren?
• Welke veelvoorkomende flow kan dit tweemaal triggeren (retries, double-click, background jobs) en is dat veilig?
• Welke test bewijst het hoofdgedrag, en welke test dekt het risicovolste randgeval?
• Als een test ontbreekt, is die moeilijk te schrijven of is de code moeilijk te testen?
• Wat heeft ops nodig: nuttige logs, metrics, alerts, config-standaarden en rollback-stappen?

Als je dit niet in duidelijke woorden kunt beantwoorden, pauzeer de merge en versmald de scope of voeg bewijs toe.

Veelvoorkomende valkuilen (en hoe ze te vermijden)

De meeste fouten zijn procesproblemen, geen modelproblemen.

• Gigantische diffs plakken zonder focus. Vraag review voor 1 tot 3 risicogebieden en plak alleen de gerelateerde hunks plus de signatures waarop ze vertrouwen.
• Intent en verwacht gedrag overslaan. Zonder doel dwaalt de review af. Voeg twee regels toe: wat verandert en wat mag niet veranderen.
• Vertrouwen op zelfverzekerde aannames. Vereis quotes terug uit de diff. Als het geen bewijs kan citeren, behandel het als een hypothese om te testen.
• Laat het bikesheden over stijl. Vraag om "Moet-gefixte" vs "Mooi-om-te-hebben" en beperk stijl-opmerkingen.
• Teamstandaarden negeren. Als je team conventies heeft (early returns, fouttypes, logging-format), neem die mee.

Als een PR een nieuwe checkout-endpoint toevoegt, plak dan niet de hele service. Plak de handler, validatie, DB-write en eventuele schema-wijzigingen. Zeg dan: "Doel: dubbele charges voorkomen. Niet-doel: naamgeving refactor." Je krijgt minder opmerkingen, en de opmerkingen die je krijgt zijn makkelijker te verifiëren.

Een realistisch voorbeeld: pre-review van een kleine PR

Een klein, realistisch PR: voeg een "display name" veld toe aan een instellingen-scherm. Het raakt validatie (server) en UI-tekst (client). Het is klein genoeg om te overzien, maar bevat toch plekken waar bugs zich verstoppen.

Hier zijn de soort diff-snippets die je zou plakken (plus 2 tot 3 zinnen context zoals verwacht gedrag en gerelateerde tickets):

- if len(name) == 0 { return error("name required") }
+ if len(displayName) < 3 { return error("display name too short") }
+ if len(displayName) > 30 { return error("display name too long") }

- <TextInput label="Name" value={name} />
+ <TextInput label="Display name" value={displayName} helperText="Shown on your profile" />

Voorbeeldbevindingen die je terug wilt krijgen:

• Leesbaarheid: "displayName" vs "name" wordt door elkaar gebruikt in bestanden. Kies één term zodat toekomstige wijzigingen geen mentale vertaling vereisen.
• Correctheid: de server valideert lengte, maar de client niet. Gebruikers kunnen 1 tot 2 tekens invoeren en pas bij submit een fout zien.
• Randgeval: strings met alleen spaties slagen len(displayName) maar lijken leeg. Trim vóór validatie.

Zet dat om in een checklist:

• Naamgeving is consistent tussen API, databasevelden en UI-labels.
• Client-side checks komen overeen met serverregels (min/max, verplicht).
• Input wordt getrimd (en Unicode/emoji-gedrag is acceptabel).
• Foutmeldingen zijn duidelijk en afgestemd tussen server en UI.

Snelle checks, metingen en vervolgstappen

Een Claude Code PR-review werkt het best als het eindigt met een paar snelle checks:

• Gedrag: wat verandert voor een gebruiker en wat mag niet veranderen
• Tests: wat is gedekt, wat mist, wat kan flakey zijn
• Logs en fouten: failures zijn duidelijk en foutmeldingen bruikbaar
• Prestaties: nieuwe loops, N+1 queries, grote payloads, extra netwerkcalls
• Beveiliging: validatie, auth-checks, secrets, riskante defaults

Om te zien of het werkt, track twee simpele metrics gedurende 2 tot 4 weken: reviewtijd (open tot eerste betekenisvolle review, en open tot merge) en rework (follow-up commits na review, of hoeveel comments veranderingen vereisten).

Standaardisatie verslaat perfecte prompts. Kies één template, eis een kort contextblok (wat veranderde, waarom, hoe te testen) en stem af wat "done" betekent.

Als je team features bouwt via chat-gestuurde ontwikkeling, kun je dezelfde workflow toepassen binnen Koder.ai: genereer wijzigingen, exporteer de source code en voeg vervolgens de pre-review checklist toe aan de PR zodat de menselijke review gefocust blijft op de risicovolle delen.