Code Review met Claude Code: Bugs onderscheppen vóór productie

Wat is Claude Code Review?

Claude Code Review is een multi-agent code-reviewsysteem dat een PR in de context van de repo bekijkt en mogelijke bugs, beveiligingsissues en regressies rapporteert. GitHub Code Review draait die agents op een GitHub-PR, terwijl lokale /code-review je direct vanuit Claude Code een review geeft op je huidige diff.

Het sleutelwoord is context. Een conventionele diff-review vraagt iemand de gewijzigde regels te inspecteren. Claude’s review-agents bekijken die wijzigingen in de context van de repo. De GitHub-workflow heeft meerdere gespecialiseerde agents die parallel werken, gevolgd door verificatie, deduplicatie en ernstclassificatie.

Een wijziging van 10 regels in een pandas-transformatie kan bijvoorbeeld afhangen van het schema dat upstream door een dbt-model is gemaakt, de granulariteit van een Snowflake-tabel en aannames in een downstream-dashboard.

Claude keurt een PR niet goed en blokkeert ‘m ook niet. GitHub Code Review rapporteert een neutrale check-conclusie, dus je bestaande branch-protection-regels blijven ongewijzigd tenzij je eigen CI-logic bouwt rond de check-output.

Drie review-oppervlakken

Er zijn momenteel 3 hoofdmanieren om code te reviewen met Claude Code.

De lokale /code-review-opdracht bekijkt de commits op je branch. Je kunt ook een specifiek bestand, branch, PR-nummer of Git ref-range opgeven.

GitHub Code Review is ingericht rond de PR zelf. Afhankelijk van de repo-configuratie kan het één keer reviewen na het aanmaken van de PR, na elke push, of alleen wanneer iemand een review aanvraagt met @claude review.

/code-review ultra is de zwaardere optie. Anthropic noemt de feature ultrareview, en /ultrareview werkt als alias wanneer de feature voor je account beschikbaar is. Het draait een vloot reviewer-agents in een externe sandbox, waarbij elke gemelde bug wordt gereproduceerd en geverifieerd voordat die in de bevindingen verschijnt. Dit is momenteel een onderzoekspreview en een typische review duurt zo’n 5 tot 10 minuten.

Wat Claude markeert vs. wat het overslaat

Claude Code Review focust eerst op correctheid. De documentatie van Anthropic onderscheidt expliciet productie-impactvolle bugs van formatteringsvoorkeuren en ontbrekende testdekking.

De bevindingen gebruiken 3 ernstniveaus:

Dat onderscheid is nuttig omdat data scientists vaak sterk uiteenlopende meningen hebben over wat reviewtijd verdient. Een naamsuggestie over revenue_df versus weekly_revenue valt niet in dezelfde categorie als omzet keer 2 doen omdat een many-to-many-join in een transformatie is geslopen.

Hoe stel je Code Review in binnen Claude Code?

Het instellen van Claude Code Review vraagt verschillende stappen, afhankelijk van of je lokaal wilt reviewen of een GitHub PR-code-review wilt. Lokale /code-review heeft de GitHub App niet nodig en kan zelfs voordat je een PR opent.

Voor GitHub Code Review moet een Owner of Primary Owner van de organisatie de Claude GitHub App configureren en repo’s selecteren. Bij PR-reviews wil je ook een gespecialiseerd bestand REVIEW.md maken met specifieke, alleen-voor-review-regels.

CLAUDE.md vs. REVIEW.md

CLAUDE.md en REVIEW.md hebben verschillende doelen, en ze door elkaar gebruiken is een makkelijke manier om rumoerige reviews te creëren.

CLAUDE.md bevat algemene projectinstructies die Claude over taken heen gebruikt. Code review leest die instructies ook, en nieuw geïntroduceerde overtredingen worden als nits gerapporteerd. REVIEW.md daarentegen is specifiek voor reviewgedrag en vertelt de review-agents wat je team gemarkeerd, overgeslagen of als Belangrijk behandeld wil zien.

Voor een Python-datarepo zou ik CLAUDE.md toespitsen op zaken als de repo-structuur, hoe je pytest draait, of transformaties pandas of polars gebruiken, en waar SQL-modellen leven.

Reviewregels zou ik in REVIEW.md zetten. Enkele voorbeelden van mogelijke regels:

• “Controleer elke nieuwe transformatie op een bijbehorende test.”
• “Nooit credentials loggen."
• “Sla gegenereerde bestanden over.”

Een kleine REVIEW.md kan er zo uitzien:

# Review instructions

## Important findings

Report as Important:
- Incorrect joins or filters that can change dataset grain
- Missing tenant or customer scoping
- Secrets or credentials written to logs
- Silent changes to revenue or customer metrics

## Do not report
- Formatting already enforced by Ruff
- Generated files
- *.lock files

## Always check
- New transformations have tests
- Joins use the intended keys
- Datetime operations specify timezone assumptions
- Missing values are handled explicitly

Ik raad aan je REVIEW.md gefocust te houden, omdat lange instructies belangrijke regels kunnen verwateren. De huidige implementatie leest het bestand ook als platte instructies, dus je moet regels direct erin zetten in plaats van de @-snelkoppeling te gebruiken.

Trouwens, tijdens lokaal ontwikkelen leest /code-review geen REVIEW.md. Het volgt CLAUDE.md, terwijl de GitHub Code Review-pipeline REVIEW.md gebruikt voor review-specifieke instructies.

Wil je dezelfde reviewregels lokaal en in GitHub, zet de algemene regels in CLAUDE.md en herhaal de review-specifieke regels waar nodig in REVIEW.md.

Voor meer diepgang raad ik aan onze gids voor het schrijven van de beste CLAUDE.md te lezen.

GitHub App en trigger-modus

GitHub Code Review wordt geconfigureerd door een Owner of Primary Owner van de organisatie via de admin-instellingen van Claude. De admin moet de Claude GitHub App installeren, repo-toegang verlenen, de te reviewen repo’s selecteren en vervolgens per repo een reviewgedrag toewijzen.

Er zijn 3 verschillende trigger-modi:

Eén uitzondering op alle 3: Claude reviewt nooit automatisch een pull request vanaf een fork. Iemand moet @claude review posten.

Sinds de update van juli 2026 zijn de handmatige commands ook veranderd: 

• @claude review start één review en abonneert de PR niet op toekomstige pushes.

• @claude review always start een review en abonneert de PR op toekomstige push-getriggerde reviews.

• @claude review once gedraagt zich hetzelfde als het kale command.

Als je Claude Code Review eerder in 2026 hebt geleerd, konden oudere tutorials zeggen dat @claude review de PR op toekomstige reviews abonneert, maar dat gedrag is in juli 2026 veranderd en is nog steeds zo in september 2026.

Pro- en Max-gebruikers die geen toegang hebben tot de GitHub Code Review van de organisatie kunnen de App volledig overslaan en /code-review lokaal gebruiken, met /code-review ultra voor een diepere review.

Hoe review je lokaal een diff met /code-review?

De lokale /code-review-opdracht reviewt je huidige branch vóórdat je een PR opent. Ik begin hier altijd mee, omdat het problemen vangt terwijl ik nog bezig ben en mislukte CI kan voorkomen.

De casus om te reviewen

Stel, we hebben een e-commerce-repo met een orders-tabel met order_id, customer_id, order_date, status en revenue, en we maken weekly_revenue.py om de wekelijkse omzet te berekenen:

orders = load_orders()
customers = load_customers()

# Derive the reporting week from the order date
orders["week"] = orders["order_date"].dt.to_period("W").dt.start_time

weekly_revenue = (
    orders
    .merge(customers, on="customer_id", how="inner")
    .groupby("week", as_index=False)["revenue"]
    .sum()
)

Op het eerste gezicht ziet niets er vreemd uit. De merge() is expliciet, de groepering is leesbaar en omzet wordt na de join geaggregeerd.

Het probleem is dat de customer-tabel voor sommige klanten meerdere historische records bevat. Een klant met 2 records levert na de join nu 2 rijen op, waardoor de aan die klant gekoppelde omzet wordt verdubbeld. Dit is precies het soort bug dat je lokaal makkelijk mist als je de transformatie leest zonder de granulariteit van de tabel te checken.

Beperk de diff

Draai vanuit je Claude Code-sessie /code-review.

De opdracht reviewt de commits van de huidige branch die voorlopen op de upstream-branch, samen met ongecommitete wijzigingen. Je kunt ook een specifiek bestand, branch, PR of range targeten, zoals main...feature/weekly-revenue.

Bijvoorbeeld:

/code-review weekly_revenue.py

of:

/code-review main...feature/weekly-revenue

Je kunt ook een effortniveau meegeven, zoals /code-review high. Bij low en medium rapporteert de review alleen de bevindingen waar het het meest zeker van is, terwijl high tot en met max de dekking uitbreidt ten koste van mogelijk meer false positives. 

Gebruik flags om de review te sturen

Als je eenmaal gewend bent aan de workflow, worden twee flags handig: 

• --fix past de bevindingen toe op je working tree na de review.

• --comment plaatst ze als inline comments.

Claude draait de review als een subagent op de achtergrond, zodat je kunt doorwerken terwijl de wijziging wordt verwerkt. De bevindingen komen terug in je sessie zodra de review klaar is.

De review kan zoiets rapporteren als:

🔴 Important
weekly_revenue.py:9

The merge on customer_id can duplicate order rows because
customers contains multiple records per customer. This can
inflate revenue when a customer has more than one matching
customer record.

Verify that customer_id is unique in customers or join against
the intended current-record subset before aggregating revenue.

De review vond een concreet faalpatroon en geeft me iets dat ik kan verifiëren tegen het daadwerkelijke schema, in plaats van me te vragen Claude op z’n woord te geloven.

Lees de bevindingen

Ik zou alsnog alles handmatig nalopen voordat ik /code-review --fix draai. Zoek eerst de code die customers opbouwt, inspecteer de uniekheidsconstraints en bekijk de tests rond weekly_revenue.py.

Als customers.customer_id echt uniek is, is Claude’s bevinding een false positive. Als de tabel één rij per klant per ingangsdatum bevat, is de bevinding reëel en moet de transformatie worden aangepast.

Het kernpunt is dat Claude’s reviewer naar codegedrag kijkt, terwijl ik verantwoordelijk blijf voor wat de data vertegenwoordigt.

Je kunt Claude na de review laten onderzoeken:

Investigate the customer_id join finding.
Check how the customers table is built and determine whether
customer_id is unique at the point of this merge. Do not modify
the code yet.

Die tweede stap is vaak nuttiger dan Claude blind de comment laten fixen. Het maakt van de review een korte onderzoeksronde in plaats van een codegeneratie-oefening.

Hoe draai je Claude Code Review op een GitHub-PR?

GitHub Code Review zet Claude’s bevindingen direct op de PR, zodat reviewers het issue naast de gewijzigde code zien.

De volgorde doet ertoe, omdat de review zich hecht aan een PR die al bestaat:

1. Push de weekly-revenue-branch naar GitHub via git push.

2. Open de pull request. Claude kan alleen een open PR reviewen, dus vóór dit punt gebeurt niets.

3. Als de repo op een automatische trigger staat, start de review vanzelf. Staat deze op Handmatig, plaats dan @claude review als top-level PR-comment om te starten.

Drie vereisten gaan hier vaak mis. Het command moet een top-level PR-comment zijn in plaats van een reply op een inline review-comment, en je hebt schrijf-, onderhouds- of adminrechten op de repo nodig. Het command moet ook de comment beginnen, met once of always op dezelfde regel als ze worden toegevoegd.

Trigger de review

De keuze die je daadwerkelijk geld kost, is die tussen de twee handmatige commands, niet tussen handmatig en automatisch.

@claude review draait één review en laat de PR niet geabonneerd. @claude review always draait een review en abonneert op de PR, zodat elke latere push een nieuwe start.

Dit is het gedrag na juli 2026 en in september 2026. Vóór die update abonneerde het kale @claude review-command de PR op toekomstige reviews, dus als je een oudere tutorial volgt, check dit eerst.

De review duurt vaak zo’n 20 minuten, al zegt Anthropic dat kosten en duur afhangen van de grootte en complexiteit van de PR. Elke review wordt ook afzonderlijk afgerekend via gebruikstegoeden en gaat niet af van het inbegrepen gebruik van het Team- of Enterprise-plan. Wil je meer weten over de kostenstructuur, lees dan onze gids over gebruikslimieten van Claude Code.

Lees de inline comments en de check run

Wanneer de review klaar is, plaatst Claude inline comments op de relevante regels. De GitHub check run bevat ook een samenvatting per ernst, wat handig is wanneer een PR meerdere bevindingen heeft in weekly_revenue.py, SQL-modellen en testbestanden.

Bijvoorbeeld:

De inline comment is waar ik het daadwerkelijke issue zou onderzoeken. De check run is waar ik het algemene beeld van de review zou halen.

Let op: op 👍 of 👎 klikken triggert geen nieuwe review, en op een inline comment reageren zorgt niet dat Claude antwoordt. Voor een nieuwe review: fix de code en push, of post @claude review als een nieuwe top-level PR-comment.

De review blokkeert het mergen ook niet uit zichzelf. De check geeft een neutrale conclusie, al bevat de check-output machineleesbare ernstinformatie die een team via gh en jq kan gebruiken om een eigen merge-poort te bouwen.

Hoe triageer je Claude’s reviewcomments?

Het draait erom de mens in the loop te houden tijdens de reviewcyclus. Dit betekent dat elke Claude-review vereist dat je bepaalt of elke bevinding een echte bug is, een niet-blokkerende verbetering, of een false positive. Een code-reviewer kan immers implementatiegedrag inspecteren zonder elke businessaanname achter een dataset of metric te kennen.

Ik gebruik een eenvoudige driesprong:

Die laatste categorie is belangrijk. Een reviewer die 30 bevindingen rapporteert, is niet per se beter dan iemand met 5. Een false-positive comment over een pandas-merge kan meer tijd kosten dan de oorspronkelijke codewijziging.

Fixen, overslaan of tegenspreken

Als de bug met gedupliceerde customer-rijen echt is, kan ik Claude vragen het upstream-model te inspecteren en dan de volgende fix te doen:

The customer_id finding is valid. Inspect the existing customer
model and update weekly_revenue.py to join only the current
customer record. Add a regression test for a customer with
multiple historical records, then run the relevant tests.

Claude kan vervolgens de repo inspecteren, de Python-code aanpassen, de test toevoegen en de testsuite draaien.

Als je vanuit GitHub-reviewcomments wilt werken, kan Claude Code ook via de GitHub CLI (gh) met de repo interageren. Het belangrijkste onderscheid: kies de specifieke fixes die je geldig vindt, in plaats van de hele review te geven om “alles te fixen”.

Zo blijven developers in de reviewloop:

1. Claude vindt een mogelijk probleem.
2. Ik verifieer het probleem tegen code en data-aannames.
3. Claude maakt de gevraagde fix.
4. Tests draaien.
5. Claude reviewt de resulterende diff opnieuw.

Die loop is veel veiliger dan de eerste reviewoutput behandelen als een geautomatiseerde refactoringsqueue.

Waar is bij een data-PR nog een mens voor nodig?

De faalmodus die Claude niet dekt, is code die correct draait en toch het verkeerde doet. Drie versies daarvan zie je steeds terug:

• Aannames buiten de diff. Claude leest je repo, niet je datawarehouse, je configservice of het contract van een ander team. Een join kan de juiste keys gebruiken en toch de granulariteit van het resultaat veranderen, omdat het aantal rijen per key een eigenschap is van de upstream-tabel, niet van de code ervoor.

• Definities die alleen je team kent. Of omzet op order-, klant- of weekniveau telt, is een businessbeslissing. Claude kan je vertellen dat een groupby() vrolijk optelt wat het krijgt. Het kan je niet vertellen welk getal je finance-team accordeert.

• Tijd- en typeaannames. Betekent 2026-08-27 een UTC-dag, een lokale werkdag of een rapportagedatum ingesteld door een upstream-model? Stille coercion heeft hetzelfde patroon: operaties over object-, nullable integer-, timezone-aware datetime- en stringkolommen kunnen iets plausibels teruggeven terwijl ze stilletjes veranderen hoe vergelijkingen werken.

Data leakage is het scherpste voorbeeld van de eerste categorie. Een featuretransformatie kan een trainingsset joinen met een tabel die informatie bevat die pas ná de predictiedatum bestond. De join is geldig, het aantal rijen is wat je verwachtte, en het model is vervuild.

Daarom behandel ik Claude als reviewer van implementatiegedrag, niet als eigenaar van de definitie.

Wanneer gebruik je Code Review versus Ultrareview?

Gebruik /code-review voor snel lokaal feedback en /code-review ultra voor een diepere pre-merge-pass. Beide reviewen code, maar /code-review is ontworpen voor iteratie, terwijl de ultra-review meerdere externe agents draait en gemelde bugs onafhankelijk verifieert.

Anthropic beschrijft ultra-review momenteel als een onderzoekspreview. Pro- en Max-abonnees krijgen eenmalig 3 gratis runs die niet verversen, waarna een review doorgaans $5 tot $25 kost, afhankelijk van de omvang van de wijziging. Team- en Enterprise-gebruikers krijgen die gratis runs niet, en de feature is niet beschikbaar op Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, en voor organisaties met Zero Data Retention ingeschakeld.

Het belangrijke verschil is verificatie. /code-review ultra stuurt de repo-status naar een externe sandbox en draait een vloot reviewer-agents, waarbij gemelde bugs onafhankelijk worden gereproduceerd voordat ze als bevinding worden teruggestuurd.

Ik zou dit niet op elke commit draaien. Als ik een variabelenaam verander in een Python-notebook of de opmaak van een dbt-model aanpas, is een lokale /code-review ruim voldoende. Als ik de featuregeneratielogica voor een productiemodel wijzig, een omzettransformatie herschrijf of een aggregatie op klantniveau aanpas, is de extra reviewpass logischer.

Er is ook een naamgevingsdetail dat je goed wilt doen. Het gedocumenteerde command is /code-review ultra, en /ultrareview is een alias die werkt wanneer ultrareview voor je account beschikbaar is. Oudere tutorials presenteren /ultrareview vaak als primair command, maar de documentatie van Anthropic ziet de diepe cloudreview nu als onderdeel van de /code-review-commandfamilie, en /code-review ultra valt terug op een lokale review wanneer de cloudfeature niet beschikbaar is.

Draai de ultra-review op dezelfde PR

Draai vanuit de repo:

/code-review ultra

Om direct een GitHub-PR te reviewen:

/code-review ultra <pr#>

Zonder argument vergelijkt /code-review ultra je huidige branch met de default-branch en neemt ongecommitete en gestagede wijzigingen mee. Een branch-review kapt standaard rond 500 gewijzigde bestanden en 8.000 gewijzigde regels af, al merkt Anthropic op dat deze aantallen kunnen wijzigen. Is je diff te groot, push de branch en review ‘m dan als PR.

Met een PR-nummer kloont de remote-omgeving de PR vanaf GitHub, en wordt er niets vanaf jouw machine geüpload.

Voor de start toont Claude de reviewscope, resterende gratis runs en geschatte kosten. Na bevestiging draait de review op de achtergrond, dus je kunt Claude Code blijven gebruiken terwijl de externe agents werken.

Voor ons weekly_revenue.py-voorbeeld zou ik de bevindingen vergelijken in plaats van aannemen dat de diepere review per definitie gelijk heeft.

Als /code-review de customer-join markeert en de ultra-review dezelfde omzetduplicatie onafhankelijk reproduceert, groeit mijn vertrouwen in die bevinding. Als de ultra-review ‘m negeert omdat de upstream-tabel uniekheid garandeert, bekijk ik het bewijs van beide reviews en de daadwerkelijke modeldefinitie voordat ik de code wijzig.

Dat is een nuttige eigenschap van meerdere reviewers: onenigheid geeft je iets om te onderzoeken.

Er is ook een kostenoverweging. GitHub Code Review kost momenteel gemiddeld $15 tot $25 per review, terwijl de ultra-review na de gratis Pro- en Max-runs doorgaans $5 tot $25 kost. Kosten voor GitHub Code Review staan los van inbegrepen planverbruik, en Anthropic biedt uitgavencontrole voor organisaties.

Werk je solo, dan is lokaal /code-review plus af en toe /code-review ultra een prima startworkflow. Zit je op een Team- of Enterprise-plan en wil je dat elke PR een geautomatiseerde review krijgt, dan ligt GitHub Code Review meer voor de hand.

Een praktische Claude Code Review-workflow

De nuttige workflow is niet “draai Claude vóór elke merge”. Het is een reeks waarbij elke review op een ander moment in de ontwikkeling gebeurt, omdat elk moment anders kost en een andere klasse problemen vangt.

Zo zou ik het proces voor een productiechange inrichten:

Write code
	   ↓
Run tests and data checks
	   ↓
/code-review
	   ↓
Fix verified findings
	   ↓
Open GitHub PR
	   ↓
GitHub Code Review
	   ↓
Human triage
	   ↓
/code-review ultra for higher-risk changes
	   ↓
Final tests
	   ↓
Human merge

De lokale review vangt problemen terwijl ze goedkoop zijn om te fixen. De GitHub-review geeft het bredere team een gedeeld logboek van bevindingen, terwijl de ultra-review een zwaardere second opinion biedt voor een belangrijke merge.

Aanvullende checks voor data scientists

Voor datawerk zou ik 4 checks toevoegen rondom Claude, in plaats van verwachten dat het model de hele review doet:

• Check rijtellingen en granulariteit van datasets vóór en na belangrijke joins
• Draai unit- of integratietests rond transformaties en featurelogica.
• Check op leakage bij het bouwen van machinelearning-features.
• Valideer businessmetrics tegen een bekende goede query of dashboard.

Claude kan aan alle 4 deelnemen, maar het verwachte resultaat moet uit code, tests of data komen en niet uit Claude’s uitleg.

Slotgedachten

Claude Code Review werkt het best wanneer ik het behandel als een andere engineer in de reviewthread, niet als een geautomatiseerde goedkeuringsstempel.

Het lokale /code-review-command geeft je een snelle review voordat de PR bestaat. GitHub Code Review brengt multi-agent-bevindingen in de PR voor Team- en Enterprise-organisaties, terwijl /code-review ultra je een diepere externe review geeft wanneer de wijziging een extra pass verdient.

Ik zou klein beginnen. Zet /code-review in je normale branch-workflow, schrijf een korte REVIEW.md voor je GitHub-reviews en probeer /code-review ultra bij wijzigingen waar een slechte merge je echt iets kost.

Voor de onderliggende modelconcepten biedt onze cursus Introductie tot Claude-modellen de bredere context, terwijl GitHub Foundations en Intermediate GitHub Concepts de Git- en GitHub-workflow behandelen waar Code Review op voortbouwt. Voor meer inspiratie over het triageren van GitHub-repo’s met Claude raad ik ook onze Claude Code connector-tutorial aan.