Code review met Claude Code: lokaal, op GitHub of met je eigen nakijker

Claude Code meldt na een review drie problemen. De eerste gaat over een gebruiker die andermans inschrijving kan annuleren. De tweede stelt een andere functienaam voor. De derde vraagt om een extra laag in de code. Moet je ze alle drie oplossen voordat je verder kunt?

De waarde van code review zit in het beoordelen van zulke bevindingen. Je wilt begrijpen bij welke invoer iets misgaat, wat de gebruiker daarvan merkt en hoe je de fout kunt aantonen. Een lange lijst opmerkingen is nog geen goede beoordeling.

Neem een trainingsapp waarin medewerkers hun eigen inschrijving mogen annuleren. Een beheerder mag dat ook voor anderen doen. De knop verdwijnt na de annuleringsdeadline. Dat zijn drie afzonderlijke afspraken: wie mag annuleren, voor welke inschrijving en tot wanneer?

Geef die afspraken mee voordat je de wijziging laat nakijken. 'Review mijn code' nodigt uit tot een breed antwoord. Een opdracht met de annuleringsregels geeft de beoordeling richting:

Wijs ook aan welke wijzigingen bij deze opdracht horen. Oude code kan context geven, maar een review wordt onoverzichtelijk als iedere bestaande onvolkomenheid ineens bij dezelfde reparatie hoort.

Met /code-review laat je in je Claude Code-sessie wijzigingen beoordelen. Je kunt een doel meegeven, bijvoorbeeld een pull requestnummer. De officiële uitleg over lokale reviews beschrijft dat dit op elk abonnement werkt en meetelt voor het gewone gebruik. Begin voor een beoordeling zonder de optie om bevindingen meteen te repareren.

Een andere route is de beheerde Code Review voor GitHub, beschikbaar voor Team en Enterprise. Die plaatst bevindingen bij pull requests. De dienst keurt een pull request niet zelf goed of af. De beslissing om samen te voegen blijft bij het team.

Voor één wijziging kies je vooral een plek waar je de relevante code, de bedoeling en de uitkomst bij elkaar kunt houden. Een extra reviewroute toevoegen helpt weinig als niemand de opmerkingen beoordeelt.

Wil je een eigen nakijker met vaste criteria, dan kun je een subagent definiëren. Geef die bijvoorbeeld alleen lees- en zoektools. De rol kan zich richten op de productafspraken van deze app; de uitkomsten moet je nog steeds aan code en tests toetsen.

Vergelijk twee mogelijke opmerkingen. 'Voeg meer autorisatie toe' is te vaag. 'De route accepteert ieder inschrijvingsnummer zonder te controleren van wie de inschrijving is' is al concreter. Het scenario maakt duidelijk waarom het telt: medewerker A stuurt het nummer van medewerker B en annuleert diens plek.

Vraag vervolgens waar die controle ontbreekt. Misschien staat zij al in een gedeelde serverfunctie die de reviewer niet heeft gelezen. Laat Claude de aanroep volgen en de conclusie daarop aanpassen. Een overtuigend geformuleerde melding kan nog steeds onjuist zijn.

Is de fout echt, dan hoort de reparatie op de plek die de bevoegdheid bepaalt. Alleen de knop verbergen laat de serverroute bereikbaar. De relevante grens in dit voorbeeld is de eigenaar van de inschrijving; die moet de server controleren op basis van de ingelogde gebruiker.

Een voorstel voor een andere functienaam beoordeel je anders. Maakt de bestaande naam het gedrag aantoonbaar verwarrend, of gaat het om smaak? Houd zo'n voorkeur los van een fout waarmee iemand andermans inschrijving kan wijzigen.

Laat voor de gevonden fout een gerichte test maken: log in als medewerker A, maak een inschrijving van B en stuur het annuleringsverzoek van A voor die inschrijving. Verwacht dat het verzoek wordt geweigerd en dat B ingeschreven blijft. Beide uitkomsten zijn nodig; een nette foutmelding met toch een gewijzigde database is geen goede reparatie.

Controleer ook het toegestane geval. A moet de eigen inschrijving nog kunnen annuleren vóór de deadline. Anders zou de simpelste 'oplossing' zijn om alle verzoeken te weigeren. De test voor de beheerder hoort bij de productafspraak en verdient eveneens een eigen geval.

Laat de fouttest eerst falen op de oude code en daarna slagen op de reparatie. Vraag om het gebruikte projectcommando en de daadwerkelijke uitslag. Zo verandert de reviewbevinding in een controle die later opnieuw kan worden uitgevoerd.

Volgens de documentatie over meegeleverde skills bouwt en start /verify de app om een wijziging in de werkende omgeving te controleren. Een eigen projectskill met die naam kan het meegeleverde gedrag vervangen; kijk daarom welk recept jouw project gebruikt.

Voor de trainingsapp wil je zien dat een succesvolle annulering de plek vrijgeeft, de knopstatus verandert en een herladen scherm dezelfde uitkomst toont. Controleer ook een weigering: blijft het formulier bruikbaar en begrijpt de medewerker wat er gebeurt?

Die zichtbare controle vult de gerichte tests aan. Eén browserpad bewijst niet dat alle rollen, deadlines en gelijktijdige verzoeken kloppen. Andersom laat een groene routetest niet zien of de melding op mobiel buiten beeld valt.

Noteer per punt: gerepareerd met bewijs, onjuist omdat een bestaande controle het afvangt, of een voorstel dat buiten deze wijziging valt. Laat na reparaties de gewijzigde code opnieuw beoordelen. Een oude conclusie zegt weinig over regels die daarna zijn aangepast.

Je hoeft daarbij geen eindeloos document te maken. Een korte toelichting met de relevante testuitslag en het gecontroleerde gebruikerspad geeft de volgende beoordelaar voldoende houvast. Achtergrond vind je bij subagents en guardrails. In Claude Code voor gevorderden werk je aan die controlecyclus.

Bijgewerkt op 27 oktober 2026. De productfeiten zijn gecontroleerd in de volgende officiële bronnen.