Je kent het gevoel. Het is vrijdagmiddag, je opent GitHub en er staan drie PR’s klaar voor review. Eentje is 40 bestanden. De tweede raakt de registratie-flow die je al maanden niet hebt ingezien. De derde is “een kleine refactor” — 800 regels gewijzigd.

Code review is essentieel. Het vangt bugs, behoudt consistentie en verspreidt kennis over het team. Maar het is ook langzaam, mentaal vermoeiend en het eerste dat sneuvelt als deadlines dichtbij komen.

Wat als Claude Code die eerste pass zou kunnen doen?

Lokaal reviewen voordat je pusht

De simpelste manier om te beginnen is nog voordat je een PR aanmaakt. Je hebt je wijzigingen gemaakt, alles compileert, tests slagen. Voordat je pusht, vraag je aan Claude Code:

Review mijn staged changes. Focus op potentiële bugs, ontbrekende validatie en alles wat afwijkt van onze code-standaarden.

Claude Code leest de diff, volgt referenties door de rest van je codebase en geeft je feedback. Geen generiek advies — feedback gebaseerd op jouw daadwerkelijke code, jouw patronen.

Ik heb zo al gênante fouten gevonden. Een FirstOrDefault() zonder null-check twee regels later. Een nieuw endpoint zonder het [Authorize] attribuut dat elk ander endpoint in de controller wél heeft. Dingen die je niet meer ziet als je urenlang naar je eigen code staart.

Een PR reviewen met de gh CLI

Als iemand anders’ PR gereviewed moet worden, kan Claude Code daar ook bij helpen. Je kunt de PR-diff er direct in voeden:

gh pr diff 42 | claude -p "Review deze .NET PR. Focus op bugs, ontbrekende error handling en afwijkingen van onze patronen."

Dit stuurt de volledige diff naar Claude Code als prompt. Claude leest elke gewijzigde regel, begrijpt de context uit bestandsnamen en omringende code, en geeft je een gestructureerde review.

Voor een diepere review waarbij Claude de volledige codebase moet zien — niet alleen de diff — check je de PR eerst lokaal uit:

gh pr checkout 42
claude

Vraag Claude Code dan om de wijzigingen te reviewen ten opzichte van de main branch. Op die manier kan het referenties volgen, controleren of nieuwe code bij bestaande patronen past, en inconsistenties spotten die je mist als je alleen de diff leest.

Waar Claude Code goed in is

Na maanden Claude Code gebruiken voor reviews op .NET-projecten, zie ik duidelijke sterktes.

Null reference risico’s. Claude is opmerkelijk goed in het traceren van nullable values door je code. Het vangt FirstOrDefault() calls waar het resultaat zonder null-check wordt gebruikt, nullable reference types die niet afgehandeld worden, en string.IsNullOrEmpty() checks die IsNullOrWhiteSpace() zouden moeten zijn.

// Claude vlagt dit direct
var user = await _context.Users.FirstOrDefaultAsync(u => u.Email == email);
var displayName = user.FirstName + " " + user.LastName; // mogelijke NullReferenceException

Ontbrekende validatie. Als je andere endpoints request models valideren met FluentValidation, merkt Claude het op wanneer een nieuw endpoint dat overslaat. Hetzelfde geldt voor ontbrekende [Required] attributen, ongecontroleerde enum-waarden of request models zonder enige validatie.

Inconsistente patronen. Hier blinkt Claude echt uit. Het ziet wanneer één controller NotFound() teruggeeft terwijl alle andere Problem() gebruiken. Het merkt op wanneer een nieuwe service niet hetzelfde DI-registratiepatroon volgt. Het vangt wanneer iemand DateTime.Now gebruikt terwijl de rest van het project IDateTimeProvider gebruikt.

Dependency injection problemen. Scoped services geïnjecteerd in singletons, ontbrekende registraties, circulaire dependencies — Claude leest je Program.cs en vangt mismatches.

Waar het tekortschiet

Laten we eerlijk zijn over de beperkingen.

Correctheid van business logic. Claude kan je vertellen dat de code compileert en nulls afhandelt. Het kan je niet vertellen of de kortingsberekening daadwerkelijk klopt voor je bedrijfsregels. Het weet niet dat klanten in België andere btw-regels hebben dan klanten in Nederland.

Architectuurcontext die het niet heeft. Als je team vorige maand heeft besloten dat alle nieuwe services het mediator-pattern moeten gebruiken, weet Claude dat niet — tenzij je het hebt gedocumenteerd. Het reviewt wat het ziet, niet wat jullie in meetings hebben besproken.

Performance op schaal. Claude vlagt niet dat je nieuwe LINQ-query een full table scan doet op een tabel met 50 miljoen rijen. Het kent je datavolumes niet. Het vangt voor de hand liggende N+1 queries, maar subtiele performance-issues vereisen menselijk oordeel en kennis van je productieomgeving.

Cross-systeem impact. Als je API-wijziging een downstream consumer breekt die in een andere repository leeft, heeft Claude geen manier om dat te weten.

Geautomatiseerde review met /install-github-app

Als je wilt dat Claude Code elke PR automatisch reviewt, kun je de GitHub-app installeren:

/install-github-app

Dit zet Claude Code op als geautomatiseerde reviewer op je repository. Elke nieuwe PR krijgt een review-comment met bevindingen — voordat een mens er ook maar naar heeft gekeken.

De geautomatiseerde reviews volgen dezelfde patronen: null checks, validatie-gaten, inconsistenties. Het verschil is dat het gebeurt zonder dat iemand eraan hoeft te denken.

CLAUDE.md als de stijlgids van je team

Hier wordt het pas echt krachtig. Claude Code leest het CLAUDE.md bestand van je project vóór elke review. Dat betekent dat je het de conventies van je team kunt leren.

## Code Review Standards

- Alle controllers moeten het `[Authorize]` attribuut hebben, tenzij expliciet publiek
- Gebruik FluentValidation voor alle request models, geen data annotations
- Geef ProblemDetails terug voor alle foutresponses (RFC 7807)
- Alle async methoden moeten CancellationToken accepteren
- Gebruik IDateTimeProvider in plaats van DateTime.Now/UtcNow
- Repository methoden geven domeinmodellen terug, nooit EF entities

Nu controleert elke review — handmatig of geautomatiseerd — tegen de specifieke regels van je team. Geen generieke best practices. Jullie regels.

Dit is de vermenigvuldiger. Zonder CLAUDE.md krijg je een degelijke generieke review. Mét CLAUDE.md krijg je een review die klinkt als je meest ervaren teamlid dat de stijlgids uit het hoofd kent.

Voorbeeld: een echte review-sessie

Dit is hoe een typische review eruitziet. Ik vroeg Claude Code om een PR te reviewen die een nieuw endpoint toevoegt voor het exporteren van gebruikersdata:

Review de wijzigingen in deze PR. Controleer op bugs, ontbrekende validatie
en afwijkingen van onze bestaande patronen in dit project.

Claude kwam terug met vijf bevindingen:

  1. Ontbrekende null check — GetUserById geeft null terug als de gebruiker niet bestaat, maar de export-methode controleert daar niet op
  2. Geen autorisatie — Het endpoint mist [Authorize(Policy = "Admin")], terwijl alle andere admin-endpoints dat wél hebben
  3. Inconsistente foutresponse — Geeft BadRequest("User not found") terug in plaats van NotFound() met ProblemDetails
  4. Ontbrekende CancellationToken — De async methode accepteert of forwardt geen CancellationToken, in tegenstelling tot elk ander endpoint in de controller
  5. Geen inputvalidatie — Het ExportUserRequest model heeft geen FluentValidation validator, terwijl alle andere request models dat wél hebben

Vier van de vijf waren legitieme issues die ik zelf ook zou hebben gevlagd in mijn eigen review. De vijfde (CancellationToken) was technisch correct maar lage prioriteit. Nul false positives, nul verzonnen problemen.

Dat is een goede eerste pass.

Tips voor bruikbare reviews

Niet alle review-prompts zijn gelijk. Dit heb ik geleerd:

Wees specifiek over wat je zoekt. “Review deze code” geeft generieke feedback. “Controleer op ontbrekende validatie, null reference risico’s en afwijkingen van onze bestaande patronen” geeft actionable bevindingen.

Vraag Claude om te vergelijken met bestaande code. “Vergelijk deze nieuwe controller met OrdersController.cs en vlag eventuele inconsistenties” dwingt Claude om daadwerkelijk naar je conventies te kijken in plaats van generieke aan te nemen.

Vraag om een severity level. Laat Claude bevindingen categoriseren als “moet gefixt,” “zou gefixt moeten worden” en “overweeg.” Dit helpt je om snel te triagen.

Vraag niet om goedkeuring. Claude vindt altijd iets. Dat is het hele punt. Gebruik het als bugvinder, niet als poortwachter.

Begin bij je volgende PR

Je hoeft geen automatisering op te zetten om hier profijt van te hebben. De volgende keer dat je een PR moet reviewen — die van jou of van iemand anders — probeer dit:

gh pr checkout 42
claude

“Review de wijzigingen in deze PR ten opzichte van main. Focus op bugs, ontbrekende error handling en alles wat niet past bij onze bestaande patronen.”

Je zult merken dat het saaie deel van code review — elke regel lezen, controleren op voor de hand liggende fouten, consistentie verifiëren — seconden duurt in plaats van minuten. Wat overblijft is het deel dat daadwerkelijk je hersens nodig heeft: architectuur beoordelen, business logic en afwegingen maken.

AI-review vervangt geen menselijke review. Het maakt menselijke review de moeite waard.