Hoe het Claude Code-team code review doet: zeven stappen en geen circuit breakers

Op 15 oktober 2026 publiceerde het Claude Code-team zijn eigen verslag van hoe het code reviewt, een engineeringpost van veertien minuten, toegeschreven aan Addy Osmani, Morgan Westlee Lunt en Qing Wang. De zin die verklaart waarom iemand hiernaar zoekt, komt al vroeg: Claude schrijft ongeveer 90 procent van de eigen code van Claude Code. De post is geen verdediging van dat cijfer, maar een beschrijving van de machinerie die eronder moest bestaan voordat het houdbaar was, en juist de delen die een nauwkeurige lezing verdienen, zijn de onderdelen die nog ontbreken.

De meeste samenvattingen stoppen bij de twee opvallende cijfers: het aantal samengevoegde pull requests naar de codebase van Claude Code is tussen juni en september 2026 meer dan verdubbeld, terwijl het aandeel dat moest worden teruggedraaid met meer dan 40 procent daalde. Beide komen van het team zelf, en beide kunnen het resultaat zijn van verschillende soorten aanpakken, waaronder degene die mensen veronderstellen: dat de review stilletjes is geschrapt. De post zegt dat dat niet zo is. Ze hebben het grootste deel van het leeswerk naar machines verplaatst, geoptimaliseerd voor menselijke tijd en aandacht, en geïnvesteerd in het snel en gemakkelijk ongedaan kunnen maken van fouten. Al het andere zijn de details van hoe.

Waarom review in de eerste plaats de bottleneck werd

De druk kwam niet voort uit een beleidsbeslissing. Die kwam voort uit volume. In de monorepo van Anthropic, zo meldt het bericht, steeg het aantal wijzigingen dat per dag binnenkwam van ongeveer 2.500 in mei naar meer dan 30.000 in september 2026. Claude Code staat in een eigen repository, los van die monorepo, maar staat onder dezelfde druk op kleinere schaal.

In dat tempo, geeft het bericht toe, is handmatige beoordeling regel voor regel ongelooflijk moeilijk, zo niet onmogelijk. Niemand daar beweert dat een mens die elke diff leest overbodig is. Ze beweren dat elke diff lezen niet langer schaalbaar is, en dat "heeft een mens de code gelezen" altijd een onnauwkeurige proxy was voor de vraag die ertoe doet: wat kan er misgaan met deze wijziging, en welke controle, geautomatiseerd of menselijk, is de juiste om dat op te vangen.

Zo geformuleerd verschuift de poort. Review houdt op een deur aan het einde van de weg te zijn en wordt continu, dichter bij spellingcontrole terwijl je schrijft. De meeste wijzigingen zijn door Claude gelezen en hersteld voordat een mens ernaar kijkt.

Waarop ze hebben geoptimaliseerd, en wat als mislukking telt

Het gestelde doel is dat de meeste pull requests in de Claude Code-repositories, die het bericht omschrijft als de CLI, de desktop- en webapps en de mobiele apps, worden gemerged met hoogstens één mens in de loop, die de auteur kan zijn, zonder toename van reverts of incidenten. Het derde punt is wat er een echt doel van maakt in plaats van een kostenbesparende exercitie.

Ze meten menselijke tijd aan beide zijden van de balans: de tijd die mensen besteden aan reviewen, en de tijd die ze besteden aan het oplossen van wat slechte code kapotmaakt. Het terugdringen van de eerste helpt niet als de kosten aan de tweede kant terugkomen, en dat zegt het team ook rechtstreeks. De gemeten cijfers zijn dus menselijke goedkeuringen per pull request, gerapporteerd als mediaan en 95e percentiel, menselijke opmerkingen, en hoe lang een pull request op een persoon wacht. Revert- en incidentpercentages liggen hier allemaal onder als vangrail: als die stijgen, is er geen menselijke tijd bespaard, maar alleen verplaatst.

Reviewkostenmetrics zijn op zichzelf gemakkelijk te manipuleren; een reviewer die alles goedkeurt, produceert prachtige grafieken van goedkeuringstijden. De vangrail is wat voorkomt dat de grafiek liegt.

Zeven stappen, niet één poort

De post zet het traject van een typische wijziging uiteen als zeven genummerde stappen. Elke laag vangt sommige problemen af en mist andere, en goedkopere controles worden uitgevoerd vóór duurdere.

• Verificatie voordat de pull request bestaat. Claude voert de tests, de build en de linter uit, en een tweede agent beoordeelt de diff in een verse context. Veel engineers gebruiken ook interne skills: één jaagt op bugs, één vereenvoudigt de diff, één controleert het gedrag end-to-end. Boris Cherny, de maker van Claude Code, heeft gezegd dat Claude een manier geven om zijn eigen werk te verifiëren waarschijnlijk het belangrijkste is voor goede resultaten, en schat dat het het eindresultaat twee tot drie keer beter maakt.

• AI-review bij elke pull request. Een Claude-review leest de diff tegen de hele repository en de opgegeven intentie van de pull request. Verschillende agents jagen parallel op bugs, waarna een aparte groep over elke bevinding stemt en deze pas wordt geplaatst als genoeg stemmen dat het echt een probleem is. Bevindingen over stijl, diagnostiek of opschoning worden verwijderd. Wat overblijft, verschijnt als inline opmerkingen met het label Important, Nit of Pre-existing. Toen de research preview werd gelanceerd, steeg het aandeel interne pull requests dat inhoudelijke reviewopmerkingen kreeg van 16 procent naar 54 procent. Beheerders stellen elke repository in op Quick, Standard of Deep.

• Beveiligingsreview. Een aparte geautomatiseerde controle. Een pull request kan niet worden samengevoegd zolang een bevinding uit een van beide reviews openstaat; je lost die op of sluit de thread met een korte reden. Dezelfde controle is openbaar als de open-source security review GitHub Action of het /security-review-commando.

• Geautomatiseerde controles die blokkeren. Lint, typecontroles, tests op elk platform en een build.

• Menselijke goedkeuring, afgestemd op risico. Een classifier leest de wijziging en bepaalt het niveau, in plaats van dat de auteur dat doet. Deze stap krijgt hieronder een eigen sectie, omdat hier het grootste deel van het interessante ontwerp zit.

• Merge queue, flags en gefaseerde uitrol. De wachtrij voert elke check opnieuw uit tegen main met de wijziging toegepast, zodat twee pull requests die elk afzonderlijk slagen, niet kunnen samenvallen tot een kapotte main. Nieuw gedrag gaat eerst achter een flag naar Anthropic-medewerkers, daarna naar het latest-kanaal, met stable dat volgt.

• Snelle detectie en rollback. Flags worden uitgeschakeld zonder deploy, er is een wekelijkse on-callrotatie en bij incidentreviews wordt gevraagd welke laag het probleem had moeten ondervangen. Sommige fouten glippen er toch door, dus de laatste laag draait erom ze snel op te merken in plaats van ze te voorkomen.

De wijziging bepaalt de tier, niet de auteur.

Een documentatiecorrectie en een wijziging aan de auto-updater brengen niet hetzelfde risico met zich mee, dus ze krijgen niet dezelfde review. De tabel in het bericht heeft drie niveaus en elk daarvan beantwoordt één vraag: hoeveel mensen, als er al iemand is, moeten dit goedkeuren voordat het wordt gemerged.

Laag omvat documentatie, copy, alleen-interne features en additieve wijzigingen achter een flag; zodra geautomatiseerde review en beveiliging groen zijn, is er niemand nodig. Gemiddeld omvat gewone productwijzigingen plus gevoelige gebieden zoals caching, de auto-updater en systeemprompts, en vereist één persoon. Hoog omvat de code met het hoogste risico en een kleine set paden waarvoor altijd twee personen nodig zijn.

De classifier is slechts de helft van het ontwerp. Een tweede classifier vraagt of deze specifieke wijziging een tweede persoon nodig heeft, zelfs wanneer het niveau zegt dat dit niet nodig is. Sommige paden hebben altijd een persoon nodig, ongeacht het niveau: alles wat eigenaren als gevoelig hebben aangemerkt, en elk CI-workflowbestand. Alleen auteurs op de vertrouwenslijst van de repository, meestal het team dat eigenaar is, krijgen de lichtere paden; alle anderen hebben een tweede persoon nodig. De goedkeuring van een agent telt nooit als die van een persoon, dus geautomatiseerde review kan een wijziging met laag risico goedkeuren, maar kan geen plaats innemen waarvoor een mens nodig is. Wie de wijziging heeft geïnitieerd, is ervoor verantwoordelijk. En een goedkeuring geldt voor één specifieke commit, dus een nieuwe commit, inclusief een push van een agent of een handmatig opgeloste merge, heeft opnieuw goedkeuring nodig.

Twee details zijn het stelen waard, zelfs als je nooit een classifier bouwt. De tier komt voort uit de wijziging, niet uit de auteur, en vertrouwen is een aparte, smallere poort daarbovenop. En een goedkeuring is gebonden aan een commit in plaats van aan een pull request, wat het meest voorkomende gat in reviewsystemen dicht: een groen vinkje dat vroeg in een branch is verdiend, besteed aan code waar niemand naar heeft gekeken.

De reviewer wordt getraind op hun eigen incidenten.

Dit is het deel dat de meeste verslagen overslaan, en het verklaart waarom de regeling blijft werken in plaats van af te drijven.

Het team verzamelde eerdere pull requests die incidenten veroorzaakten, samen met de bijbehorende fix-forwards en reverts, en liet ingenieurs die die code kennen elke bug en de plek waar die zat bevestigen. Die verzameling is nu een evaluatie. De reviewer draait er dagelijks tegen. Wanneer de prompts, tools of het model ervan veranderen, moet de wijziging de hele set doorstaan: behoud haar als de score stijgt, laat haar vallen als dat niet zo is. Hun fouten werden de testsuite voor het ding dat hun fouten zou moeten opvangen.

Dat is een andere houding dan het afstemmen van een linter, die wordt beoordeeld aan de hand van een vaste regelset. Deze reviewer wordt beoordeeld op de specifieke manieren waarop deze codebase al is stukgegaan, dus de eval groeit elke keer dat er iets misgaat. In niets dat Anthropic heeft gepubliceerd en wij hebben gelezen, staat een score voor de reviewer, en de post beweert niet dat de reviewer af is.

De laag die nog niet is gebouwd

Hier is de bekentenis die het bericht geloofwaardig maakt. Alles hierboven beschrijft een systeem dat fouten opvangt en terugdraait, niet een dat merkt dat zijn eigen foutpercentage verandert. Het team heeft nog geen circuit breakers die de goedkeuring automatisch aanscherpen wanneer het aantal terugdraaiingen of incidenten verandert, en de ingenieurs daar willen die hebben voordat meer code naar merges zonder menselijke tussenkomst gaat.

Wat er in plaats daarvan bestaat, is menselijk opmerken. Flags worden uitgezet zonder deploy, de wekelijkse on-callrotatie houdt de wacht, en incidentreviews vragen welke laag het probleem had moeten opvangen. De uitspraak van een collega is de nuttigste zin voor iedereen die een vergelijkbare uitrol plant: vertragen verlaagt je foutpercentage wel, maar vooral omdat je van alles minder doet. Het team wordt liever sneller in het opmerken en oplossen van problemen dan langzamer in het produceren ervan.

Lees de zeven stappen opnieuw met dat in gedachten. Zes bepalen of een wijziging doorgaat. De zevende is een reeks gewoonten om het achteraf op te merken. Er is geen feedbackloop die van de uitkomst terug naar de poort leidt, en de mensen die het systeem hebben gebouwd, zeggen dat zelf.

De tweede taak van Review, waar het bericht grotendeels aan voorbijgaat

De post maakt duidelijk dat code review twee dingen doet: problemen vinden en oplossen voordat ze worden uitgebracht, en gedeelde context binnen het team opbouwen. De post richt zich op het eerste en komt dan terug op het tweede met een ongewoon eerlijk antwoord: er is geen formeel proces voor, niemand houdt een compleet mentaal model van Claude Code in zijn hoofd, en ze denken niet dat iemand dat nodig heeft. Wil je een deel van de codebase begrijpen? Vraag Claude om een uitleg van precies dat stuk.

Twee instructiebestanden bevatten de context die vroeger in de hoofden van reviewers zat. CLAUDE.md vertelt Claude wat het project is, de stack, conventies, doelen en niet-doelen, bewust kort gehouden. REVIEW.md wordt door code-eigenaren geschreven en beschrijft hoe falen er in hun deel van de code uitziet, welke paden je moet overslaan, en vraagt om een bestand en regel in plaats van een gok.

Verantwoordelijkheid krijgt een eigen regel: jij voert het door, jij bent er verantwoordelijk voor. Merge een kleine of middelgrote wijziging en er gaat iets mis, dan is de norm dat jij het oplost. Dat werkt omdat wijzigingen klein zijn, omdat flags en reverts de meeste fouten binnen enkele minuten ongedaan maken, en omdat de blast radius bepaalt hoeveel controles een wijziging krijgt. Het is een norm bovenop de goedkeuringsregel, geen vervanging ervan.

Waar een router past, en waar niet

De bovenstaande pijplijn is een pijplijn van modelaanroepen: een reviewagent die een diff tegen een hele repository leest, meerdere agenten die parallel naar bugs jagen, een groep die over elke bevinding stemt, een securitypass, en de reviewer die dagelijks opnieuw wordt uitgevoerd tegen een groeiende eval. Dat is een routeringsprobleem voordat het een reviewprobleem is, want één provider met een slechte middag zou een mergewachtrij niet mogen stoppen.

OrcaRouter is één OpenAI-compatibel endpoint voor meer dan 200 modellen op één sleutel, met automatische failover tussen providers en nul opslag, wat betekent dat de lijstprijs van de provider wordt doorgegeven. Teams die hun eigen versie van deze pipeline draaien, krijgen één factuurrelatie en één plek om van model te wisselen wanneer de kwaliteit volgens een reviewer verandert, precies wat de dagelijkse evaluatie bedoeld is om te detecteren.

De grens is belangrijk. Wij hosten modellen. Wij hosten Claude Code niet, wij draaien geen Code Review voor Claude Code, en wij hebben geen toegang tot de pipeline waar dit artikel over gaat. Code Review voor Claude Code is een product van Anthropic, algemeen beschikbaar op Team- en Enterprise-abonnementen, met een lichtere versie lokaal beschikbaar als /code-review. Als je die pipeline wilt, daar zit die; in de versie van jouw eigen team is een router een infrastructuurbeslissing, geen reviewbeslissing.

Wat een kleiner team echt kan kopiëren

Leg de reviewregels vast op een plek waar de reviewer ze kan lezen: een korte CLAUDE.md voor het project en een REVIEW.md per gebied die benoemt hoe een fout eruitziet en een bestand en regel eist in plaats van een gok. Zet de risiconiveaus op schrift, maak ze een eigenschap van de wijziging in plaats van de auteur, begin streng en versoepel alleen met bewijs. Beperk wat geautomatiseerde review kan goedkeuren en laat de goedkeuring van een agent nooit tellen als die van een persoon. Koppel goedkeuringen aan commits. Gebruik de merge queue. Zet incidenten en reverts om in testcases en herscore de reviewer telkens wanneer je hem wijzigt, want een reviewer die niet wordt gemeten, is een linter met betere marketing.

{{1}}Kijk dan naar de vangrail, niet naar de goedkeuringstijd. De manier waarop het team het zelf formuleert, biedt je de toets voor elke wijziging in het reviewproces die je overweegt: bleven de percentages terugdraaiingen en incidenten gelijk, of verschoof de tijd simpelweg van de reviewer naar de persoon die achteraf opruimt? Die vraag is te beantwoorden met gegevens die de meeste teams al hebben, en ze onderscheidt een proces dat sneller is geworden van een proces dat alleen een kwartaal lang sneller lijkt.{{/1}}