Claude Code review: zo doe je het, stap voor stap

Wat heb je nodig

Wat heb je nodig voor een Claude Code review?

Voor een review op je eigen computer heb je weinig nodig. Het lokale /code-review werkt op elk plan waarmee je Claude Code gebruikt en telt mee in je gewone verbruik, net als de rest van je sessie. Pas voor de diepe cloud-review en de automatische review op GitHub komen er voorwaarden bij. Heb je Claude Code nog niet draaien, begin dan bij Claude Code installeren.

Welke review

Welke Claude Code review past bij jou?

Er zijn vijf manieren om Claude je code te laten reviewen. Ze lijken op elkaar, maar verschillen in waar ze draaien, wie ze mag gebruiken en wat ze kosten. Voor een beginner is de volgorde simpel: begin lokaal met /code-review, en kijk pas naar de rest als je weet wat je aan de bevindingen hebt.

/review en /code-review zijn nu hetzelfde

Lees je een oudere tutorial, let dan op. Vóór versie 2.1.223 was /review een apart command dat een pull request in één snelle doorgang las. Nu is het een alias van /code-review, met dezelfde niveaus en vlaggen. De oude /ultrareview is op zijn beurt een alias van /code-review ultra. Het overzicht van alle review-commands staat op Claude Code commands.

De Claude Code review skill

/code-review is een meegeleverde skill: een vaste instructie die in Claude Code zit. Er staat dus geen SKILL.md-bestand op je schijf dat je kunt openen. Wil je eigen regels meegeven, zet ze dan in je CLAUDE.md; de review leest dat bestand. Maak je een eigen skill met de naam code-review, dan draait die in plaats van de ingebouwde, en blijft /review de ingebouwde versie starten. Hoe skills werken lees je in Claude Skills.

Stap voor stap

Je eerste Claude Code review op een lokale wijziging

Je oefent op een wijziging die je toch al gemaakt hebt. Zonder doel achter de review staat ook de rest van het project niet in de diff, en dan kan Claude er niets over zeggen. Volg de stappen in deze volgorde; elke stap zegt waarom.

Niveaus en vlaggen

Hoe diep moet de review? Effortniveaus en vlaggen

Achter /code-review typ je een niveau, eventuele vlaggen en een doel. Het niveau bepaalt hoe breed de review zoekt. Breder betekent meer bevindingen, maar ook meer twijfelgevallen die jij moet nalopen. Afhankelijk van je model en niveau neemt de review ook opruimkansen mee, zoals dubbele code.

De doelen die je kunt meegeven

Zonder doel reviewt Claude je huidige branch. Met een doel kies je zelf wat:
/code-review 1234 reviewt pull request 1234
/code-review main...mijn-feature vergelijkt twee branches
/code-review HEAD~3..HEAD reviewt je laatste drie commits
/code-review src/betalingen reviewt één map

De vlaggen

--fix laat Claude de bevindingen na de review toepassen; elke wijziging gaat via je permissiemodus. --comment zet de bevindingen als opmerkingen op een GitHub-pull request of een GitLab-merge request. --max-findings 10 of --max-findings all verandert hoeveel bevindingen je maximaal krijgt; dat vraagt versie 2.1.288 of nieuwer en blijft staan tot je --max-findings default typt.

Pull request

Claude Code review op een pull request (GitHub)

Werkt je lokale review, dan is een pull request de volgende stap. Een pull request is het voorstel om jouw branch samen te voegen met de hoofdbranch, waar collega's eerst naar kijken. Stap 1 tot en met 3 werken op elk plan. Stap 4 tot en met 6 zijn de automatische review voor Team en Enterprise.

Wat de beheerde review op je pull request zet

Elke bevinding krijgt een markering. Important (rood) is een bug die je voor de merge moet oplossen. Nit (geel) is een kleinigheid die niet blokkeert. Pre-existing (paars) is een fout die al in de code zat en niet door deze pull request komt. Een bevinding wegzetten doe je door de discussie op GitHub te sluiten; alleen reageren is niet genoeg. Kies uit drie niveaus voor de grondigheid: Quick, Standard (standaard) en Deep.

Geen Team-plan? GitHub Actions is het alternatief

Met /install-github-app in Claude Code installeer je de GitHub-app en een workflow die bij elke pull request een review draait op je eigen GitHub-runners, betaald met een API-key of een abonnements-token. Die route werkt alleen voor repositories op github.com en vraagt beheerrechten op de repository. De volledige installatie staat in de tutorial Claude Code met GitHub.

Werkt het?

Werkt het? Zo test je je eerste review

Je weet pas of een review iets waard is als je weet wat hij had moeten vinden. Test daarom eerst met een fout die je zelf hebt gemaakt. Daarna laat je Claude bij een echte bevinding eerst bewijs leveren, voordat er iets verandert.

De controle: verstop zelf een fout

Maak een testbranch met git switch -c review-test. Verander in één functie bewust iets kleins, bijvoorbeeld <= in < in een lus, of haal een controle op een lege waarde weg. Draai /code-review low. Je ziet het goed werken als de review dat bestand en die regel noemt en uitlegt wat er misgaat. Vindt hij niets, controleer dan of je wijziging echt in de diff zit met git diff. Gooi de branch daarna weg met git switch - en git branch -D review-test.

De eerste prompt om te plakken, na een echte review

Neem bevinding 1 uit de review.
1. Leg in twee zinnen uit wat er misgaat.
2. Geef een concreet voorbeeld: welke invoer, wat verwacht je, wat gebeurt er nu.
3. Schrijf een test die nu faalt door deze fout. Pas de code zelf nog niet aan.
4. Kun je geen voorbeeld bedenken dat echt fout gaat? Zeg dat dan eerlijk, dan laat ik de bevinding vallen.

Waarom deze prompt werkt

Stap 3 en 4 maken het verschil. Een bevinding zonder concreet voorbeeld is een vermoeden, en een AI-model kan een vermoeden net zo stellig opschrijven als een feit (zie hallucinatie). Door eerst een falende test te vragen, bewijst Claude de fout. Lukt dat niet, dan heb je een reden om de bevinding te laten liggen. Dat is dezelfde regel die Anthropic adviseert voor de beheerde review: een claim over gedrag hoort een verwijzing naar bestand en regel te hebben, geen gok op basis van een naam.

Bevindingen beoordelen

Claude Code review-bevindingen beoordelen: niet blind toepassen

Een review levert een lijst op, geen besluit. Anthropic zegt het zelf in de documentatie: een review zonder bevindingen betekent niet dat je code foutloos of veilig is. Andersom is niet elke bevinding een echte fout. Loop de lijst daarom per bevinding af met deze beslistabel.

CLAUDE.md of REVIEW.md: welke leest wat?

Het lokale /code-review leest je CLAUDE.md, maar niet REVIEW.md. De beheerde Code Review op GitHub leest allebei. Zet regels die overal moeten gelden dus in CLAUDE.md, bijvoorbeeld Meld geen opmaakfouten, daar draait Prettier al voor. REVIEW.md gebruik je alleen voor de beheerde review, bijvoorbeeld om het aantal Nits per review te beperken of gegenereerde bestanden over te slaan. De beheerde review leest REVIEW.md van je standaardbranch, nooit uit de pull request zelf.

Wat een review niet vervangt

Een review leest code; hij draait je code niet. Dat staat zo in de documentatie van de beheerde review. Tests blijven dus nodig, en /verify in Claude Code bouwt en start je app om te zien of een wijziging echt werkt. Een menselijke reviewer blijft nodig voor de vraag of de wijziging het juiste doet: klopt de kortingsregel met wat sales heeft beloofd, mag deze rol dit scherm zien. Gebruik Claude als eerste lezer die de slordige fouten wegvangt, zodat je collega zijn tijd aan die vragen kan besteden. Dat principe heet human in the loop.

Problemen

Claude Code review werkt niet? Meldingen en oplossingen

Dit zijn de meldingen en situaties waar beginners op vastlopen. Zoek je symptoom in de eerste kolom. De exacte foutteksten komen uit de officiële foutenlijst van Claude Code.

Ons oordeel

Ons oordeel: wanneer een Claude Code review loont

In onze trainingen zien we dat teams het meeste halen uit een review als vaste stap vóór elke commit of pull request, op een laag niveau, met iemand die de bevindingen weegt. Het minste halen ze eruit als de review de enige controle wordt.

Wanneer wel

Je werkt alleen of met een klein team en niemand heeft tijd om elke wijziging grondig te lezen. Je bouwt met Claude Code en wilt dat een tweede lezer de code van de eerste nakijkt. Je pakt een onbekende codebase op en wilt weten waar de risico's zitten. In die gevallen is /code-review low of medium een goedkope eerste filter: het draait in je eigen sessie en kost geen extra abonnement.

Wanneer niet, of nog niet

Je hebt geen tests. Dan kun je een bevinding niet bewijzen en ook niet controleren of de oplossing iets anders kapot maakt; zorg eerst voor een paar tests rond je belangrijkste functies. Je code bevat echte klantgegevens in testbestanden of configuratie. Een cloud-review uploadt je repository naar Anthropic, en ook een lokale review stuurt de code die hij leest naar het model. Haal persoonsgegevens eerst uit je repository en lees Claude Code en privacy voor de AVG-kant. Voor organisaties met Zero Data Retention zijn de cloud-review en de beheerde review niet beschikbaar.

De grootste valkuil: --fix zonder te lezen

De fout die we beginners het vaakst zien maken: /code-review --fix draaien, alles laten toepassen en committen. Twee dingen gaan dan mis. Een onterechte bevinding wordt een echte wijziging, vaak een extra controle of een andere afhandeling die nergens voor nodig was. En je leert niets over waar je eigen code zwak is. Lees eerst, bewijs met een test, en laat dan pas herstellen. Een lege lijst betekent ook niet "veilig": dat zegt Anthropic zelf in de documentatie.

Een voorbeeld uit het MKB

Neem een klein bureau met drie ontwikkelaars dat een klantportaal onderhoudt met een koppeling naar een boekhoudpakket. Er is geen vaste reviewer; wie tijd heeft, kijkt mee. Een werkbare aanpak: iedereen draait /code-review low voor elke pull request, en de maker zet onder de pull request welke bevindingen hij heeft opgelost en welke hij bewust liet liggen, met reden. De collega die meekijkt, leest dan alleen nog die toelichting en de bedrijfslogica, bijvoorbeeld of het btw-tarief en de betalingstermijn kloppen. Na een paar weken weet het team welke soorten meldingen in hun code terecht zijn en zet het de rest in CLAUDE.md.

Wat nu?

Wat doe je na je eerste Claude Code review?

Werkt de review lokaal en op een pull request, dan zijn dit de logische vervolgstappen. Kies er één, niet alles tegelijk.

Automatiseren op GitHub

Laat elke pull request reviewen via GitHub Actions of de beheerde review. De installatie stap voor stap staat in Claude Code met GitHub. Wil je eerst weten wat dat kost, lees dan wat Claude Code kost en de limieten van Claude Code.

Review in je editor

Werk je liever in een editor dan in een losse terminal, volg dan Claude Code in VS Code. Dezelfde commands werken daar ook.

Je eigen reviewer bouwen

Wil je een review die op jullie eigen regels let, schrijf dan een eigen skill of subagent. Claude Skills legt uit hoe, en everything-claude-code laat zien hoe een bestaande bundel reviewers en agents eruitziet. Wat Claude Code verder kan, staat in de functies van Claude Code.

Verder lezen

Hoe je Claude Code in het algemeen goed inzet, lees je in Claude Code gebruiken. Hoe een ontwikkelteam AI in het hele proces inbouwt, van ontwerp tot review, staat in AI integreren in softwareontwikkeling. Wil je dit met je team goed neerzetten, dan behandelen we review, CLAUDE.md en tests in de Claude Code Masterclass.