Hoe houden we PR-reviews bij in het AI-tijdperk?

1. Beperk elke PR tot één ding

De snelste manier om reviewmomentum om zeep te helpen is een PR die drie dingen tegelijk doet. Reviewers zouden niet mentaal hoeven uitpluizen welke wijzigingen bij de bugfix horen en welke bij de refactor die je ertussendoor hebt gesmokkeld.

• Eén bugfix, één veld, één feature, niet alle drie in dezelfde PR.

• Een gerichte PR van ongeveer 1.000 regels die één duidelijk probleem oplost is prima. Een PR van 300 regels met drie aandachtspunten niet. Als je ruim boven de 1.000 regels zit, is dat een sterk signaal om op te splitsen.

• Gebruik stacked PR's voor grotere wijzigingen.

• Check je gevoel voordat je hem opent: kan iemand dit in één sessie reviewen? Doet het precies één ding? Zou jij het mergen?

2. Vraag pas om review als het echt klaar is

Drafts bestaan niet voor niets. Een PR uit draft halen is een signaal aan het team dat je je huiswerk hebt gedaan en dat dit iemands tijd waard is. Als dat signaal onbetrouwbaar is, stort het hele reviewsysteem in.

Haal hem alleen uit draft als je op alles ja kunt zeggen:

• Je hebt een self-review gedaan

• Alle tests slagen, inclusief e2e

• Nul onopgeloste comments (die van Devin inbegrepen)

• Je hebt het lokaal getest voor UI/UX-wijzigingen

• Voor wijzigingen die met geautomatiseerde tests kunnen worden afgedekt, heb je geverifieerd dat het voor 100% afgedekt is

• Alle CI-jobs zijn groen (behalve de vervelende Vercel previews)

Als op iets het antwoord nee is, laat hem dan in draft. Drafts die om review vragen vervuilen de wachtrij en vertragen PR's die echt klaar zijn.

3. Houd je open PR's op 5 of minder (drafts tellen mee)

Open PR's zijn voorraad. Ze brengen contextswitch-kosten, risico op mergeconflicten en reviewschuld met zich mee. Als je er meer dan vijf tegelijk open hebt, klopt de rekensom niet. Je produceert sneller dan het team kan verwerken.

Als je 5 PR's open hebt, draft en niet-draft samen, begin dan niets nieuws. Ga in plaats daarvan de PR's van je teamgenoten reviewen of werk je oudere werk af.

4. Zet een menselijke stem in je PR-beschrijving

De beschrijving hoeft niet volledig door jou te zijn geschreven. AI is prima voor de opzet en het samenvatten van het diff. Het probleem met wat we nu zien, zijn de enorme AI-gegenereerde beschrijvingen die lezen als een generieke checklist waar niemand echt mee bezig is geweest. Daar ontbreekt het menselijke element dat een reviewer echt nodig heeft.

• Een notitie van één zin van de auteur over de afweging die je hebt gemaakt, of waarom deze fix nu belangrijk is, doet meer dan een lange sectie "Key Review Points" / "Human Review Checklist".

• Als je code verzendt die nog nergens wordt gebruikt, leg dan uit waarom.

• Als AI de beschrijving heeft opgesteld, bewerk hem dan korter en voeg alleen de context toe die jij hebt.

5. Bewijs dat de fix werkt

Een PR die zegt "fixes bug X" zonder bewijs, vraagt de reviewer om het op goed vertrouwen aan te nemen. Doe dat niet.

• Screenshots, schermopnames, dashboards vóór en na, wat dan ook dat laat zien dat de bug dood is en dat er verder niets is teruggevallen.

• Functionele QA is verplicht voor UX/UI-wijzigingen, niet optioneel.

6. SQL- en prestatie-wijzigingen hebben echte validatie nodig

Code review alleen kan niet bevestigen dat een query-herschrijving onder productielast standhoudt. Een query-diff lezen en zeggen "ziet er goed uit" is geen validatie. Voor PR's die querypaden of herschrijvingen raken:

• EXPLAIN ANALYZE op een dataset die op productie lijkt

• Latentiecijfers vóór en na of dashboardscreenshots

• Uitrol achter een feature flag voor risicovolle wijzigingen

7. AI is een versneller, geen brein

AI kan snel code genereren. Het kan niet beslissen of die code überhaupt zou moeten bestaan. Het denken moet nog steeds van jou komen.

• Eerst ontwerpen. Schets de aanpak, denk de randgevallen door, schrijf een korte notitie en geef dan pas een prompt.

• Lees na het genereren door de agent het echt. Een self-review vangt Prisma-aanroepen op de verkeerde plek, genegeerde richtlijnen voor agents, fragiele structuur, enzovoort.

• Vraag je vóór het openen af: wat raakt dit? Impact op gebruikers? Gevolgen voor performance of beveiliging? Hoe groot is de schade als het fout zit?

8. Valideer security-PR's vóór je ze opent

Controleer of de kwetsbaarheid echt van toepassing is op hoe we de code gebruiken. PR's met "fix vulnerability X" die gevoelige paden raken, kunnen meer risico introduceren dan het oorspronkelijke rapport.

9. Leid PR's naar de juiste reviewer

De verkeerde reviewer kost twee mensen tijd: de reviewer die geen zinvolle feedback kan geven en de auteur die moet wachten op een tweede ronde met de juiste persoon.

• Domeinspecifieke PR's (Salesforce/CRM routing, migraties van teamprofielen, enz.) horen bij de domeineigenaar, niet bij Foundation die een AI-gegenereerde testsuite klakkeloos afstempelt.

• Wijzigingen aan core/foundation-paden (query-infra, hasTeamAccess, enz.) verdienen een snelle afstemming met het verantwoordelijke team voordat de PR wordt geopend.

10. Architectuurgesprekken beginnen vroeg

Drie keer hetzelfde gebied patchen is een signaal, geen toeval. Als je weer om dezelfde beperking heen werkt, is de juiste stap een gesprek en mogelijk een herschrijving, niet nog een patch.

Praat met Foundation/Head of Engineering voordat je implementeert. Zo zijn de infra-modules samengekomen, en consistentie stapelt zich op.

11. Lichtere route voor triviale fixes

Niet alles hoeft door Foundation te worden gereviewd. We moeten reviewcapaciteit inzetten waar het het meest telt.

Toast-aanpassingen, knopformaten, mechanische hernoemingen, tekstwijzigingen, hoofdfeatures - deze kunnen door AI review en/of teamreviews gaan. Reserveer Foundation review voor wijzigingen die het echt nodig hebben.

12. Open geen PR's namens anderen

Als Engineer X het werk doet, opent Engineer X de PR. Anders komen comments bij de verkeerde persoon terecht, blijven vragen onbeantwoord en loopt de PR vast.