Hoe het Claude Code-team code reviews uitvoert

Hoe review je code op het volume waarin agents het produceren? Bij het Claude Code-team zijn we, nadat we een hoge dekking en diepgaande reviews hadden bereikt, gaan optimaliseren voor de minimale hoeveelheid menselijke reviewtijd die geen toename in reverts of incidenten veroorzaakt.

Claude schrijft ongeveer 90 procent van de code van Claude Code. Hoe reviewen we code op het volume dat we produceren? Leest er eigenlijk nog wel iemand de code? En als er iets breekt, wie vangt dat dan op?

Dit artikel beschrijft de workflow voor code reviews binnen het Claude Code-team en hoe deze is geëvolueerd. Van juni tot september verdubbelden de samengevoegde (merged) pull requests in de codebase van Claude Code, terwijl het aandeel dat moest worden teruggedraaid (reverted) met meer dan 40 procent daalde.

We hebben de review niet verwijderd, maar we hebben het grootste deel van het leeswerk verplaatst naar machines, geoptimaliseerd voor menselijke tijd en aandacht, en zwaar geïnvesteerd in het snel en eenvoudig ongedaan maken van fouten.

Heroverweging van het doel van code review

Wanneer agents code schrijven, stijgt het aantal wijzigingen razendsnel. In de monorepo van Anthropic steeg het aantal dagelijkse wijzigingen van ongeveer 2.500 in mei naar meer dan 30.000 in september van dit jaar.

Claude Code bevindt zich in een eigen repository, apart van de monorepo, maar ervaart ook veel druk. Bij deze snelheid van leveren is handmatige, regel-voor-regel code review ongelooflijk moeilijk, zo niet onmogelijk.

Code review vervult twee functies:

1. Problemen vinden en oplossen voordat ze worden gepubliceerd.
2. Gedeelde context en begrip van de codebase opbouwen binnen het team.

Dit artikel richt zich voornamelijk op het vinden en oplossen van problemen, maar we komen later terug op de tweede functie.

We geloven dat de vraag "heeft een mens de code gelezen?" een onnauwkeurige proxy is voor "wat zou er mis kunnen gaan met deze wijziging, en welke controle — geautomatiseerd of menselijk — is de juiste om dit op te vangen?".

Deze vraag veranderde ook het moment waarop de review plaatsvindt. Voorheen was de review een poort aan het einde van de weg: schrijf de code, open een PR, wacht op een collega. Nu verloopt de review continu, vergelijkbaar met een spellingscontrole tijdens het schrijven. De meeste wijzigingen zijn minstens één keer door Claude gereviewd en gecorrigeerd voordat een mens wordt gevraagd ernaar te kijken. Dit vangt de meeste routinfouten op en bewaart de aandacht van het team voor vragen op een hoger niveau.

De schaarse bron: menselijke tijd en aandacht

We willen menselijke tijd en aandacht bewaren voor problemen die alleen mensen kunnen oplossen en ervoor zorgen dat geautomatiseerde controles de rest opvangen. Gezien ons huidige tempo is er nog steeds een enorme hoeveelheid werk voor mensen, en ons team wordt bijna dagelijks geconfronteerd met nieuwe en onbekende uitdagingen.

Menselijke tijd omvat beide kanten van de kosten van review: de tijd die mensen besteden aan het reviewen, en de tijd die ze besteden aan het herstellen van wat slechte code breekt. Het verminderen van de eerste helpt niet als die tijd simpelweg verschuift naar de tweede.

Het doel is dat de meeste pull requests in de Claude Code-repo's (de CLI, de desktop- en web-apps, en de mobiele apps) worden samengevoegd met maximaal één mens in het proces (die de auteur kan zijn), zonder dat het aantal reverts of incidenten stijgt. Om menselijke tijd te meten, houden we de menselijke goedkeuringen per PR bij (mediaan en 95ste percentiel), menselijke commentaren en hoe lang een PR op een persoon wacht. Revert- en incidentcijfers dienen als vangrail: als deze stijgen, hebben we geen menselijke tijd bespaard, maar deze enkel verplaatst.

De levenscyclus van een wijziging

Een typische wijziging doorloopt meerdere lagen van code review:

Vóór de pull request (Geautomatiseerd)

Het werk wordt geverifieerd. Claude voert de tests, build en linter uit; een tweede agent reviewt de diff in een nieuwe context.

Bij elke pull request (Geautomatiseerd & Risico-afhankelijk)

• Vereiste CI: Lint, types, tests over verschillende platforms, build en packaging. Rood blokkeert de merge.
• Claude code review: Agents zoeken parallel naar bugs; verifieerders stemmen over elke vondst, waarna de overgebleven punten worden gerangschikt op ernst.
• Security review: Een aparte pass. Openstaande bevindingen uit zowel de bug- als security-review blokkeren de merge.
• Risico-gebaseerde goedkeuring: Een classifier bepaalt het niveau: geen persoon, één persoon, of twee personen. Sommige paden vereisen altijd een mens.

Samenvoegen (Merging)

• Merge queue: Controles worden opnieuw uitgevoerd op de nieuwste main met de wijziging toegepast.

Na de merge (Recovery)

• Feature flags: Eerst intern gebruikt door Anthropic-medewerkers voordat het iedereen bereikt.
• Geleidelijke release: Eerst via het 'latest' kanaal, gevolgd door het 'stable' kanaal.
• Monitoren en herstellen: De auteur en de on-call engineer houden de systemen in de gaten; flags worden snel uitgeschakeld en kapotte builds worden teruggedraaid.

Laag voor laag

1. Verificatie vóórdat anderen kijken

Het meeste reviewwerk gebeurt nu voordat er een PR bestaat. We geven Claude iets dat het kan uitvoeren — zoals tests, een build of een screenshot om te vergelijken met het ontwerp — en vragen om de output te tonen in plaats van alleen te zeggen dat het klaar is. Vervolgens reviewt een subagent de diff met een frisse context.

Voor het openen van een PR draaien velen van ons ook interne "skills": één zoekt naar bugs, één vereenvoudigt de diff, en één controleert het gedrag end-to-end. UI-wijzigingen worden gecontroleerd aan de hand van onze designrichtlijnen.

Wanneer de geautomatiseerde reviewer herhaaldelijk hetzelfde signaleert, lossen we dit op bij de bron: in de skill, met een lint-regel, of met updates aan instructiebestanden:

• CLAUDE.md: Vertelt Claude wat het project is: de stack, conventies, doelen en non-doelen. Elke review laadt dit bestand. De reviewer signaleert ook code die een conventie hierin schendt.
• REVIEW.md: Geschreven door code-owners, vertelt dit de reviewer wat belangrijk is in hun specifieke deel van de code. Deze bestanden zijn kort en beschrijven hoe een fout eruitziet in die repo (bijv. "het liegt" voor documentatie, of "het routeert fout" voor configuratie).

2. AI-review bij elke pull request

Elke pull request krijgt een Claude-review voordat een mens ernaar kijkt. Claude leest de diff tegen de hele repo en de stated intent van de PR en stelt vast of de wijziging het probleem oplost, in het systeem past of iets anders breekt.

Bij een bugfix zoekt het naar de root cause. Bij de lancering van de research preview steeg het aandeel interne PR's die inhoudelijke review-commentaren kregen van 16% naar 54%. Admins stellen elke repo in op Quick, Standard of Deep. Deep is waardevol waar één gemiste bug kostbaarder is dan de extra reviewtijd.

Bevindingen worden geverifieerd door andere agents. Meerdere agents zoeken tegelijkertijd naar bugs, waarna een aparte groep stemt over elke vondst. Alleen als genoeg agents het eens zijn dat het een echte fout is, wordt het geplaatst. Stijl- of cleanup-opmerkingen worden gefilterd. Wat overblijft, verschijnt als inline comments, gesorteerd op ernst en getagd als Important, Nit (kleinigheid) of Pre-existing.

3. Beveiligingsreview die kan blokkeren

Security heeft een eigen geautomatiseerde review. Een PR kan niet worden samengevoegd zolang er openstaande bevindingen zijn uit de bug- of security-review.

4. Geautomatiseerde controles die blokkeren

De standaard zaken: lint, type checks, tests op elk platform en een build. Een typische CLI pull request kan tientallen controles doorlopen voordat een mens ernaar kijkt.

5. Menselijke goedkeuring, geschaald naar risico

Niet elke wijziging draagt hetzelfde risico.

Risico	Voorbeelden	Menselijke goedkeuring
Laag	Docs, copy, interne functies, additieve wijzigingen achter een flag	Geen vereist zodra AI- en security-checks groen zijn
Medium	Gewone productwijzigingen, gevoelige gebieden (caching, auto-updater, system prompts)	Eén persoon
Hoog	Hoog-risico code, specifieke kritieke paden	Twee personen

Het risiconiveau wordt bepaald door een classifier, niet door de auteur. Alleen vertrouwde auteurs (meestal het team dat de repo beheert) hebben toegang tot de lichtere paden. Een goedkeuring van een agent telt nooit als een menselijke goedkeuring.

6. Merge queue, flags en geleidelijke release

De merge queue voert elke controle opnieuw uit tegen main met de wijziging toegepast. Nieuw gedrag wordt meestal eerst via een flag uitgerold naar Anthropic-medewerkers.

7. Snelle detectie, snelle rollback

De laatste laag is gericht op het snel opvangen van fouten die toch door slipped zijn. Flags kunnen worden uitgeschakeld zonder een nieuwe deploy. Incident-reviews analyseren achteraf welke laag de fout had moeten vangen.

Hoe we de reviewer verbeteren

Ons reviewproces is een constante feedbackloop.

Incidenten als evaluatie (eval): Het team verzamelt PR's die incidenten veroorzaakten. De reviewer wordt dagelijks getest tegen deze set. Als een wijziging in de prompts, tools of het model van de reviewer de score verhoogt, wordt deze behouden.

Ruis verminderen: We meten ruis door te kijken hoe mensen reageren op commentaren (gecorrigeerd, onjuist, intentioneel, of irrelevant). Onze prioriteit is eerst echte bugs vangen en daarna pas het aantal review-rondes verminderen.

Convergentie: Om te voorkomen dat een agent-auteur en een agent-reviewer elkaar eindeloos in een loop houden, hebben we convergentie-regels ingevoerd:

• Ronde-limiet: Na drie ronden vraagt de reviewer de auteur om de aanpak te heroverwegen.
• Diff-only review: Na de eerste paar passes wordt alleen de nieuwe diff gereviewd.
• Klasse-indicatie: De reviewer signaleert de klasse van de bug, zodat de auteur alle instanties in één keer fixt in plaats van regel voor regel.
• Geen herhalingen: Bevindingen die al zijn geplaatst, worden niet opnieuw gemeld.

Waar mensen in het proces blijven

De rol van de senior engineer is verschoven van het lezen van elke diff naar beslissingen waar machines slecht in zijn:

• Strategie: Moeten we dit überhaupt bouwen? (Richting, smaak en scope).
• Risicovolle code: Facturering, de auto-updater en CI-workflows.
• Architectuur: Patronen vastleggen die anderen zullen kopiëren.
• Bewijsvoering lezen: Test-output, screenshots en de bevindingen van de reviewer analyseren.
• Eigenaarschap: Een mens is verantwoordelijk voor elke wijziging die wordt gepubliceerd, ongeacht wie de code heeft getypt.

Context delen binnen het team

Traditioneel was code review een manier om kennis van de codebase te verspreiden. Als machines het leeswerk doen, hoe leert een mens dan de code kennen?

We hebben hiervoor geen formeel proces. Wanneer iemand een deel van de codebase wil begrijpen, vragen ze Claude om een uitleg (explainer) te schrijven voor precies dat deel. Dit is efficiënter dan het regel voor regel lezen van triviale diffs. Daarnaast helpt onze cultuur van open Slack-kanalen, waar je ziet wat anderen bouwen terwijl ze het bouwen.

"Wie het landt, is eigenaar"

Als een kleine of medium wijziging fout gaat, is het de norm dat de persoon die het heeft doorgevoerd het oplost. Dit werkt omdat:

• Wijzigingen klein zijn en dus makkelijk te debuggen en te reverten.
• Alles omkeerbaar is via flags en staged releases.
• Het impactbereik (blast radius) bepaalt de drempel; dure code krijgt meer checks.
• Regressies snel zichtbaar zijn via telemetrie en intern gebruik.

Wanneer we van richting veranderen

Agents maken het goedkoop om dingen te starten, wat betekent dat sommige werkstukken niet samengevoegd moeten worden. Omdat de code snel geschreven is, voelt het sluiten van een PR niet als een groot verlies. De truc is om een andere richting vroegtijdig in de discussie aan te kaarten, in plaats van als een blokkerende commentaar op een voltooide PR.

Hoe je dit proces kunt adopteren

Vóór de pull request

• Geef je agent controles die hij kan uitvoeren (vastgelegd in een CLAUDE.md), plus hooks voor formatters en linters.
• Gebruik lokale reviews of een subagent met een frisse context.
• Voeg een REVIEW.md toe en verplaats terugkerende review-opmerkingen hiernaartoe.

Bij elke pull request

• Maak CI verplicht en voeg "Testen", "Risico" en "Hoe terug te draaien" toe aan je PR-template.
• Introduceer een AI-reviewer op één repo, stem de REVIEW.md een paar weken lang af en breid dit daarna uit.
• Maak geautomatiseerde security-reviews verplicht en eis dat elke thread is opgelost vóór de merge.
• Stem de review-inspanning af op het risico (Quick, Standard of Deep).
• Stel een limiet aan het aantal review-rondes.

Goedkeuring

• Definieer risico-niveaus op basis van de wijziging, niet de auteur.
• Houd lichtere goedkeuringspaden voorbehouden aan auteurs die je vertrouwt.
• Gebruik CODEOWNERS en branch protection voor kritieke paden (auth, billing, CI).
• Laat een bot-goedkeuring nooit een vereiste menselijke goedkeuring vervangen.

Merge en daarna

• Gebruik een merge queue, feature flags, intern gebruik en staged releases.
• Zet incidenten en reverts om in een evaluatieset om de reviewer continu te verbeteren.
• Meet de menselijke tijd, met revert- en incidentcijfers als vangrail.

De toekomst

Hoewel het goedkeuren van een pull request momenteel nog een menselijke beslissing is, schuift de grens op. In onze eigen repo's laten we eigenaren al beslissen welke laag-risico wijzigingen uitsluitend op basis van geautomatiseerde checks kunnen worden samengevoegd.

Het doel blijft ongewijzigd: minder menselijke tijd per wijziging, zonder dat het aantal reverts toeneemt.