Så gör Claude Code-teamet kodgranskning: sju steg och inga circuit breakers

Den 15 oktober 2026 publicerade Claude Code-teamet sin egen redogörelse för hur de granskar kod, ett fjorton minuter långt ingenjörsinlägg tillskrivet Addy Osmani, Morgan Westlee Lunt och Qing Wang. Meningen som förklarar varför någon överhuvudtaget söker efter detta kommer tidigt: Claude skriver omkring 90 procent av Claude Codes egen kod. Inlägget är inte ett försvar av den siffran utan en beskrivning av maskineriet som måste finnas under den innan den var överlevnadsduglig, och de delar som är värda att läsa noga är de som fortfarande saknas.

De flesta sammanfattningar stannar vid de två rubriknumren: antalet mergade pull requests till Claude Codes kodbas mer än fördubblades mellan juni och september 2026, medan andelen som måste återställas föll med mer än 40 procent. Båda kommer från teamet självt, och båda kan åstadkommas genom flera olika upplägg, inklusive det som folk antar, nämligen att granskningen tyst togs bort. Inlägget säger att den inte togs bort. De flyttade det mesta av läsningen till maskiner, optimerade för mänsklig tid och uppmärksamhet och investerade i att göra det snabbt och enkelt att ångra misstag. Allt annat är detaljerna kring hur.

Varför granskning blev flaskhalsen från första början

Trycket kom inte från ett policybeslut. Det kom från volymen. Enligt inlägget ökade antalet ändringar som landade per dag i Anthropics monorepo från omkring 2 500 i maj till mer än 30 000 i september 2026. Claude Code finns i ett eget repository, separat från det monorepoet, men det står under samma tryck i mindre skala.

I det tempot medger inlägget att manuell granskning rad för rad är otroligt svår, för att inte säga omöjlig. Ingen där hävdar att det är onödigt att en människa läser varje diff. De hävdar att det inte längre skalar att läsa varje diff, och att ”läste en människa koden” alltid var en oprecis proxy för den fråga som verkligen spelar roll: vad skulle kunna gå fel med den här ändringen, och vilken kontroll, automatiserad eller mänsklig, är rätt för att fånga det.

När man uttrycker det så flyttas grinden. Granskning slutar vara en dörr i slutet av vägen och blir kontinuerlig, mer som stavningskontroll medan du skriver. De flesta ändringar har redan lästs och rättats av Claude innan en människa tittar.

Vad de optimerade för, och vad som räknas som misslyckande

Det angivna målet är att de flesta pull requests i Claude Code-förråden, som inlägget beskriver som CLI:t, skrivbords- och webbapparna samt mobilapparna, ska slås samman med högst en människa i loopen, som kan vara författaren, utan att antalet återställningar eller incidenter ökar. Den tredje klausulen är det som gör det till ett verkligt mål snarare än en besparingsövning.

De mäter mänsklig tid på båda sidor av räkenskaperna: tiden folk lägger på att granska, och tiden de lägger på att åtgärda det som dålig kod förstör. Att minska den första delen hjälper inte om kostnaden återkommer i den andra, och teamet säger det rakt ut. Så de mätvärden som följs är antalet mänskliga godkännanden per pull request, redovisade som median och 95:e percentil, mänskliga kommentarer, och hur länge en pull request väntar på en person. Frekvensen för återställningar och incidenter ligger under allt detta som skyddsräcke: om de ökar har mänsklig tid inte sparats, bara flyttats.

Mått på granskningskostnad är lätta att manipulera i isolation; en granskare som godkänner allt producerar vackra diagram över godkännandetider. Skyddsräcket är det som hindrar diagrammet från att ljuga.

Sju steg, inte en enda grind

Inlägget beskriver en typisk ändrings väg som sju numrerade steg. Varje lager fångar vissa problem och missar andra, och billigare kontroller körs före dyrare.

• Verifiering innan pull requesten finns. Claude kör testerna, bygget och lintern, och en andra agent granskar diffen i en ny kontext. Många ingenjörer kör också interna skills: en letar efter buggar, en förenklar diffen, en kontrollerar beteendet från början till slut. Boris Cherny, som skapade Claude Code, har kallat det att ge Claude ett sätt att verifiera sitt eget arbete för förmodligen det viktigaste för bra resultat, och uppskattar att det gör slutresultatet två till tre gånger bättre.

• AI-granskning på varje pull request. En Claude-granskning läser diffen mot hela repot och pull requestens angivna syfte. Flera agenter letar efter buggar parallellt, sedan röstar en separat grupp om varje fynd och det publiceras bara om tillräckligt många håller med om att det är verkligt. Fynd om stil, diagnostik eller städning tas bort. Det som återstår visas som inline-kommentarer märkta Important, Nit eller Pre-existing. När research preview lanserades gick andelen interna pull requests som fick substansiella granskningskommentarer från 16 procent till 54 procent. Administratörer ställer in varje repo på Quick, Standard eller Deep.

• Säkerhetsgranskning. En separat automatiserad genomgång. En pull request kan inte sammanfogas medan en anmärkning från endera granskningen är öppen; du åtgärdar den eller stänger tråden med en kort motivering. Samma kontroll är offentlig som GitHub Action för säkerhetsgranskning med öppen källkod eller kommandot /security-review.

• Automatiserade kontroller som blockerar. Lint, typkontroller, tester på alla plattformar och en build.

• Mänskligt godkännande, skalat efter risk. En klassificerare läser ändringen och sätter nivån i stället för att författaren gör det. Det här steget får ett eget avsnitt nedan, eftersom det är där större delen av den intressanta designen finns.

• Sammanslagningskö, flaggor och gradvis utrullning. Kön kör om varje kontroll mot main med ändringen tillämpad, så två pull requests som var för sig passerar kan inte kombineras till en trasig main. Nytt beteende levereras bakom en flagga till Anthropic-anställda först, sedan till den senaste kanalen, med stable släpande efter.

• Snabb upptäckt och återrullning.Flaggor stängs av utan driftsättning, det finns en veckovis jourrotation och incidentgenomgångar ställer frågan vilket lager som borde ha fångat problemet. Vissa misstag kommer fortfarande att slinka igenom, så det sista lagret handlar om att upptäcka dem snabbt snarare än att förhindra dem.

Ändringen anger nivån, inte författaren.

En dokumentationsrättelse och en ändring i autouppdateraren innebär inte samma risk, så de får inte samma granskning. Inläggets tabell har tre nivåer och var och en svarar på en enda fråga: hur många personer, om några, måste godkänna detta innan det sammanfogas.

Låg omfattar dokumentation, copy, funktioner som endast är interna och additiva ändringar bakom en flagga; när automatiserad granskning och säkerhetskontroll är gröna krävs ingen person. Medel omfattar vanliga produktändringar plus känsliga områden som cachning, automatuppdateraren och systemprompter, och kräver en person. Hög omfattar koden med högst risk och en liten uppsättning sökvägar som alltid kräver två personer.

Klassificeraren är bara halva konstruktionen. En andra klassificerare frågar om just den här ändringen behöver en annan person, även när dess nivå säger att den inte gör det. Vissa vägar kräver alltid en person oavsett nivå: allt som ägarna har angett som känsligt och alla CI-arbetsflödesfiler. Endast författare på repots betrodda lista, mestadels det ägande teamet, får de lättare vägarna; alla andra behöver en andra person. En agents godkännande räknas aldrig som en persons, så automatisk granskning kan godkänna en lågriskändring men kan inte fylla en plats som kräver en människa. Den som initierade ändringen är ansvarig för den. Och ett godkännande gäller en specifik commit, så en ny commit, inklusive en agents push eller en merge som lösts manuellt, kräver ett nytt godkännande.

Två detaljer är värda att stjäla även om du aldrig bygger en klassificerare. Nivån kommer från ändringen, inte från författaren, och förtroende är en separat, snävare grind ovanpå den. Och ett godkännande är bundet till en commit snarare än till en pull request, vilket täpper till det vanligaste hålet i granskningssystem: en grön bock som tjänats in tidigt i en gren och sedan spenderas på kod som ingen har tittat på.

Granskaren är tränad mot sina egna incidenter

Det här är delen som de flesta redogörelser hoppar över, och den förklarar varför arrangemanget fortsätter att fungera i stället för att glida ur läge.

Teamet samlade in tidigare pull requests som hade orsakat incidenter, tillsammans med deras fix-forwards och reverts, och lät ingenjörer som känner till koden bekräfta varje bugg och var den fanns. Den samlingen är nu ett eval. Granskaren körs mot den dagligen. När dess prompter, verktyg eller modell ändras måste ändringen klara hela uppsättningen: behåll den om poängen ökar, ta bort den om inte. Deras fel blev testsviten för det som ska fånga deras fel.

Det är en annan hållning än att finjustera en linter, som bedöms mot en fast regeluppsättning. Den här granskaren bedöms mot de specifika sätt som den här kodbasen redan har gått sönder på, så utvärderingen växer varje gång något går fel. Ingen poäng för den visas i något som Anthropic har publicerat som vi har läst, och inlägget hävdar inte att granskaren är klar.

Lagret som ännu inte är byggt

Här är erkännandet som gör inlägget trovärdigt. Allt ovan beskriver ett system som fångar upp och rullar tillbaka misstag, inte ett som märker att dess egen felfrekvens förändras. Teamet har ännu inte några kretsbrytare som automatiskt skärper godkännandet när antalet återställningar eller incidenter förändras, och ingenjörerna där vill ha dem innan mer kod övergår till sammanslagningar helt utan mänsklig inblandning.

Det som finns i stället är mänsklig uppmärksamhet. Flaggor stängs av utan en driftsättning, den veckovisa jourrotationen håller koll, och incidentgranskningar frågar vilket lager som borde ha fångat problemet. En kollegas replik är den mest användbara meningen för alla som planerar en liknande utrullning: att sakta ner sänker visserligen din felfrekvens, men mest för att du gör mindre av allt. Teamet vill hellre bli snabbare på att upptäcka och åtgärda problem än långsammare på att producera dem.

Läs de sju stegen igen med det i åtanke. Sex avgör om en ändring går vidare. Det sjunde är en uppsättning vanor för att lägga märke till efteråt. Det finns ingen återkopplingsslinga kopplad från utfallet tillbaka till grinden, och de som byggde systemet säger det själva.

Recensionens andra uppgift, som inlägget till stor del lämnar därhän

Inlägget är tydligt med att kodgranskning gör två saker: hitta och åtgärda problem innan de släpps, och bygga gemensam kontext i teamet. Det fokuserar på det första och återkommer sedan till det andra med ett ovanligt ärligt svar: det finns ingen formell process för det, ingen har en fullständig mental modell av Claude Code i huvudet, och de tror inte att någon behöver det. Vill du förstå en del av kodbasen? Be Claude om en förklaring av exakt den delen.

Två instruktionsfiler bär den kontext som tidigare fanns i granskarnas huvuden. CLAUDE.md berättar för Claude vad projektet är, teknikstacken, konventioner, mål och icke-mål, avsiktligt hållet kort. REVIEW.md skrivs av kodägare och beskriver hur ett misslyckande ser ut i deras del av koden, vilka sökvägar som ska hoppas över, och efterfrågar en fil och rad i stället för en gissning.

Ansvarsskyldigheten får en egen rad: du landar den, du äger den. Om du merge:ar en liten eller medelstor ändring och något går fel, är normen att du åtgärdar det. Det fungerar eftersom ändringarna är små, eftersom flaggor och återställningar ångrar de flesta misstag på minuter, och eftersom påverkansradien sätter ribban för hur många kontroller en ändring får. Det är en norm som ligger ovanpå godkännanderegeln, inte en ersättning för den.

Var en router passar in, och var den inte gör det

Pipelinen ovan är en pipeline av modellanrop: en granskningsagent som läser en diff mot ett helt kodförråd, flera buggjägande agenter parallellt, en grupp som röstar om varje fynd, en säkerhetsgenomgång och granskaren som körs om dagligen mot en växande utvärdering. Det är ett routningsproblem före det är ett granskningsproblem, eftersom en leverantör som har en dålig dag inte ska stoppa en merge-kö.

OrcaRouter är en OpenAI-kompatibel slutpunkt för fler än 200 modeller på en enda nyckel, med automatisk redundansväxling mellan leverantörer och noll påslag, vilket innebär att leverantörernas listpris förs vidare. Team som kör sin egen version av denna pipeline får en faktureringsrelation och en plats att byta modell på när en granskares kvalitet förändras, vilket är precis vad den dagliga utvärderingen är utformad att upptäcka.

Gränsdragningen är viktig. Vi är värdar för modeller. Vi är inte värdar för Claude Code, vi kör inte Code Review för Claude Code, och vi har ingen åtkomst till den pipeline som den här artikeln handlar om. Code Review för Claude Code är Anthropics produkt, allmänt tillgänglig i Team- och Enterprise-planer, med en lättare version tillgänglig lokalt som /code-review. Om det du vill ha är den pipelinen, är det där den finns; i ditt eget teams version av den är en router ett infrastrukturbeslut snarare än ett granskningsbeslut.

Vad ett mindre team faktiskt kan kopiera

Skriv ner granskningsreglerna där granskaren kan läsa dem: en kort CLAUDE.md för projektet och en REVIEW.md per område som anger hur misslyckande ser ut och kräver en fil och rad i stället för en gissning. Skriv ner risknivåerna, gör dem till en egenskap hos ändringen i stället för hos författaren, börja strikt och lätta bara med bevis. Begränsa vad automatisk granskning kan godkänna och låt aldrig en agents godkännande räknas som en persons. Bind godkännanden till commits. Kör merge-kön. Gör incidenter och återställningar till testfall och poängsätt granskaren igen varje gång du ändrar den, eftersom en omätt granskare är en linter med bättre marknadsföring.

Titta då på skyddsräcket, inte på godkännandetiden. Teamets egen formulering ger dig testet för varje granskningsändring du överväger: låg återställnings- och incidentfrekvenserna kvar på samma nivå, eller flyttades tiden bara från granskaren till personen som städar upp efteråt? Den frågan går att besvara med data som de flesta team redan har, och den skiljer en process som blev snabbare från en som bara ser snabbare ut under ett kvartal.