Code Review med Claude Code: Fånga buggar innan de når produktion

Vad är Claude Code Review?

Claude Code Review är ett multiagent-granskningssystem som undersöker en PR i kontexten av repot och rapporterar potentiella buggar, säkerhetsproblem och regressioner. GitHub Code Review kör dessa agenter mot en GitHub-PR, medan lokala /code-review ger dig en granskning av din aktuella diff direkt från Claude Code.

Det viktiga ordet här är kontext. En konventionell diff-granskning ber någon att inspektera raderna som ändrats. Claudes granskningsagenter undersöker dessa ändringar i kontexten av repot. GitHub-arbetsflödet har flera specialiserade agenter som arbetar parallellt, följt av verifiering, deduplicering och allvarlighetsklassning.

Till exempel kan en ändring på 10 rader i en pandas-transformation bero på schemat som skapats av en uppströms dbt-modell, granulariteten i en Snowflake-tabell och antaganden inbyggda i en nedströms dashboard.

Claude varken godkänner eller blockerar en PR. GitHub Code Review rapporterar en neutral check-sammanfattning, så dina befintliga branchskyddsregler förblir oförändrade om du inte bygger egen CI-logik runt checkens utdata.

Tre granskningsytor

Det finns för närvarande tre huvudsakliga sätt att granska kod med Claude Code.

Det lokala kommandot /code-review undersöker din branchs commits. Du kan också ge det en specifik fil, branch, PR-nummer eller ett Git ref-intervall.

GitHub Code Review är utformat kring själva PR:en. Beroende på repots konfiguration kan den granska en gång efter att PR skapats, efter varje push, eller endast när någon begär en granskning med @claude review.

/code-review ultra är det tyngre alternativet. Anthropic kallar funktionen ultrareview, och /ultrareview fungerar som ett alias när funktionen är tillgänglig för ditt konto. Den kör en flotta av granskningsagenter i en fjärrsandlåda, där varje rapporterad bugg återskapas och verifieras innan den visas i fynden. Detta är för närvarande en forskningsförhandsversion, och en typisk granskning tar cirka 5 till 10 minuter.

Vad Claude flaggar kontra vad den hoppar över

Claude Code Review fokuserar först på korrekthet. Anthropics dokumentation skiljer uttryckligen på produktionspåverkande buggar och formateringspreferenser samt saknad testtäckning.

Fynden använder tre allvarlighetsnivåer:

Den distinktionen är användbar eftersom data scientists ofta har mycket olika åsikter om vad som förtjänar granskningstid. Ett namngivningsförslag om revenue_df jämfört med weekly_revenue är inte i samma kategori som att multiplicera intäkter med 2 eftersom en many-to-many-join slank in i en transformation.

Hur sätter du upp Code Review i Claude Code?

Att sätta upp Claude Code Review kräver olika steg beroende på om du vill ha en lokal granskning eller en GitHub PR-kodgranskning. Lokala /code-review kräver inte GitHub-appen och kan göras innan du ens öppnar en PR. 

GitHub Code Review kräver att en Owner eller Primary Owner i organisationen konfigurerar Claude GitHub-appen och väljer repos. Vid PR-granskningar vill du skapa en specialfil som heter REVIEW.md som innehåller specifika regler endast för granskning.

CLAUDE.md vs. REVIEW.md

CLAUDE.md och REVIEW.md fyller olika syften, och att blanda ihop dem är ett enkelt sätt att skapa brusiga granskningar.

CLAUDE.md innehåller allmänna projektinstruktioner som Claude använder över olika uppgifter. Kodgranskningen läser också de instruktionerna, och nyintroducerade överträdelser rapporteras som nits.  REVIEW.md är däremot specifikt för granskningsbeteende och talar om för granskningsagenterna vad ditt team vill att de ska flagga, hoppa över eller behandla som Important.

För ett Python-datarepo skulle jag hålla CLAUDE.md fokuserad på saker som repots struktur, hur man kör pytest, om transformationer använder pandas eller polars, och var SQL-modellerna finns. 

Jag skulle lägga granskningsregler i REVIEW.md. Några exempel på möjliga regler:

• ”Kontrollera varje ny transformation för ett motsvarande test.”
• ”Logga aldrig autentiseringsuppgifter.”
• ”Hoppa över genererade filer.”

En liten  REVIEW.md kan se ut så här:

# 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

Jag rekommenderar att hålla din REVIEW.md fokuserad eftersom långa instruktioner kan späda ut viktiga regler. Den nuvarande implementationen läser också filen som raka instruktioner, så du bör lägga reglerna direkt i den istället för att använda genvägen @. 

För övrigt, när du utvecklar lokalt läser /code-review inte  REVIEW.md. Den följer CLAUDE.md, medan GitHub Code Review-pipelinen använder  REVIEW.md för granskningens specifika instruktioner.

Om du vill ha samma granskningsregler lokalt och på GitHub, lägg de allmänna reglerna i CLAUDE.md och upprepa de granskningsspecifika reglerna i REVIEW.md där det behövs.

För en djupare genomgång rekommenderar jag att läsa vår guide till att skriva den bästa CLAUDE.md-filen.

GitHub-app och triggermod

GitHub Code Review konfigureras av en Owner eller Primary Owner i organisationen via Claudes admininställningar. Admin behöver installera Claude GitHub-appen, ge den repo-åtkomst, välja repos att granska och sedan tilldela ett granskningsbeteende till varje repo.

Det finns tre olika triggermod:

Ett undantag från alla tre: Claude granskar aldrig automatiskt en pull request från en fork. Någon måste kommentera @claude review på den.

Från och med uppdateringen i juli 2026 har de manuella kommandona också ändrats: 

• @claude review startar en enskild granskning och prenumererar inte PR:en på framtida pushes. 

• @claude review always startar en granskning och prenumererar PR:en på framtida push-utlösta granskningar.

• @claude review once beter sig likadant som det rena kommandot.

Om du lärde dig Claude Code Review tidigare under 2026 kan äldre handledningar ha sagt att @claude review prenumererar PR:en på framtida granskningar, men det beteendet ändrades i juli 2026 och gäller fortfarande i september 2026.

Pro- och Max-användare som inte har tillgång till organisationens GitHub Code Review kan helt hoppa över appen och använda /code-review lokalt, med /code-review ultra för en djupare granskning.

Hur granskar du en diff lokalt med /code-review?

Det lokala kommandot /code-review granskar din aktuella branch innan du öppnar en PR. Jag börjar alltid med detta eftersom det fångar problem medan jag fortfarande arbetar och kan förhindra fallande CI.

Fallet att granska

Låt oss föreställa oss ett e-handelsrepo med en ordertabell som innehåller order_id, customer_id, order_date, status och revenue, och vi skapar weekly_revenue.py för att beräkna veckointäkterna:

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()
)

Vid första anblicken ser inget konstigt ut. merge() är explicit, grupperingarna är läsbara och intäkter aggregeras efter joinen.

Problemet är att kundtabellen innehåller flera historiska poster för vissa kunder. En kund med två poster ger nu två rader efter joinen, vilket dubblar intäkten kopplad till den kunden. Det här är precis den typen av bugg som är lätt att missa när du läser transformationen lokalt utan att kontrollera tabellens granularitet.

Avgränsa diffen

Från din Claude Code-session, kör /code-review.

Kommandot granskar den aktuella branchens commits före sin uppströmsbranch, tillsammans med ej committade ändringar. Du kan också rikta in dig på en viss fil, branch, PR eller intervall, såsom main...feature/weekly-revenue.

Till exempel:

/code-review weekly_revenue.py

eller:

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

Du kan också skicka en insatsnivå, såsom /code-review high. Vid low och medium rapporterar granskningen bara de fynd den är mest säker på, medan high till max utökar täckningen till priset av fler möjliga falska positiva. 

Använd flaggor för att styra granskningen

När du blir bekväm med arbetsflödet börjar två flaggor bli användbara: 

• --fix tillämpar fynden på ditt working tree efter granskningen.

• --comment postar dem som inline-kommentarer.

Claude kör granskningen som en bakgrunds-subagent, så du kan fortsätta arbeta medan den bearbetar ändringen. Fynden återkommer till din session när granskningen är klar.

Granskningen kan rapportera något i stil med:

🔴 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.

Granskningen hittade ett konkret fel-läge och ger mig något jag kan verifiera mot det faktiska schemat, snarare än att be mig lita på Claudes omdöme.

Läs fynden

Jag skulle ändå ge allt en manuell genomläsning innan jag kör /code-review --fix. Sök först efter koden som bygger customers, inspektera dess unikhetsbegränsningar och titta på testerna runt weekly_revenue.py.

Om customers.customer_id verkligen är unikt är Claudes fynd ett falskt positivt. Om tabellen innehåller en rad per kund och giltighetsdatum är fyndet verkligt och transformationen behöver ändras.

Poängen här är att Claudes granskare tittar på kodbeteende, medan jag fortfarande ansvarar för att veta vad datan representerar.

Du kan be Claude att undersöka efter granskningen:

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.

Det andra steget är ofta mer användbart än att be Claude blint fixa kommentaren. Det förvandlar granskningen till en kort undersökning snarare än en kodgenereringsövning.

Hur kör du Claude Code Review på en GitHub-PR?

GitHub Code Review lägger Claudes fynd direkt på PR:en, så granskare kan se problemet bredvid den ändrade koden. 

Ordningen spelar roll eftersom granskningen kopplas till en PR som redan finns:

1. Push:a branchen weekly-revenue till GitHub via git push.

2. Öppna pull requesten. Claude kan bara granska en öppen PR, så inget händer före denna punkt.

3. Om repot är inställt på en automatisk trigger startar granskningen automatiskt. Om det är inställt på Manuell, posta @claude review som en top-level PR-kommentar för att starta en.

Tre krav fäller många här. Kommandot måste vara en top-level PR-kommentar snarare än ett svar på en inline-granskningskommentar, och du behöver write-, maintain- eller admin-behörigheter på repot. Kommandot måste också inleda kommentaren, med once eller always på samma rad om de läggs till.

Trigga granskningen

Valet som faktiskt kostar pengar står mellan de två manuella kommandona, inte mellan manuellt och automatiskt.

@claude review kör en granskning och lämnar PR:en utan prenumeration. @claude review always kör en granskning och prenumererar på PR:en, så varje senare push startar en ny.

Detta är beteendet efter juli 2026 och i september 2026. Före den uppdateringen prenumererade det rena kommandot @claude review PR:en på framtida granskningar, så om du följer en äldre handledning, kontrollera detta först.

Granskningen tar ofta omkring 20 minuter, även om Anthropic säger att kostnad och varaktighet beror på PR:ens storlek och komplexitet. Varje granskning debiteras också separat via användningskrediter i stället för att förbruka inkluderad användning i Team- eller Enterprise-planen. Om du vill veta mer om kostnadsstrukturen rekommenderar jag vår guide till användningsgränser i Claude Code.

Läs inline-kommentarerna och check run

När granskningen är klar postar Claude inline-kommentarer på relevanta rader. GitHub check run inkluderar också en sammanfattning av allvarlighetsgrader, vilket är användbart när en PR har flera fynd över weekly_revenue.py, SQL-modeller och testfiler.

Till exempel:

Den inlinade kommentaren är platsen där jag skulle undersöka det faktiska problemet. Check run är där jag skulle få den övergripande bilden av granskningen.

Bara som en notis: att klicka på 👍 eller 👎 triggar inte en ny granskning, och att svara på en inline-kommentar får inte Claude att svara. För att få en ny granskning, fixa koden och push:a, eller posta @claude review som en ny top-level PR-kommentar.

Granskningen blockerar inte heller merge av sig själv. Checken ger en neutral slutsats, även om checkens utdata innehåller maskinläsbar allvarlighetsinformation som ett team kan konsumera via gh och jq om det vill bygga en egen merge-spärr.

Hur prioriterar du Claudes granskningskommentarer?

Hela poängen är att behålla människan i loopen under granskningscykeln. Det betyder att varje Claude-granskning kräver ett beslut om huruvida varje fynd är en verklig bugg, en icke-blockerande förbättring eller ett falskt positivt. Detta eftersom en kodgranskare kan inspektera implementationsbeteende utan att känna till varje affärsantagande bakom en datamängd eller metrik.

Jag använder ett enkelt tredelat beslut:

Den sista kategorin är viktig. En granskare som rapporterar 30 fynd är inte nödvändigtvis bättre än en som rapporterar 5. En falsk positiv kommentar om en pandas-merge kan kosta mer tid än själva kodändringen.

Fixa, hoppa över eller tryck tillbaka

Om buggen med duplicerade kundrader är verklig kan jag be Claude att inspektera uppströmsmodellen och sedan göra följande fix:

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 sedan inspektera repot, ändra Python-koden, lägga till testet och köra testsuiten.

Om du vill arbeta från GitHub-granskningskommentarer kan Claude Code också interagera med repot via GitHub CLI (gh). Den viktiga skillnaden är att jag skulle välja ut de specifika fixar du anser vara giltiga, snarare än att ge den hela granskningen för att ”fixa allt”.

Detta håller utvecklare i granskningsslingan:

1. Claude hittar ett möjligt problem.
2. Jag verifierar problemet mot kod och dataantaganden.
3. Claude gör den begärda fixen.
4. Tester körs.
5. Claude granskar den resulterande diffen igen.

Den slingan är mycket säkrare än att behandla den första granskningsutdata som en automatiserad refaktoreringskö.

Vad behöver en data-PR fortfarande en människa till?

Felmoden som Claude inte kan täcka är kod som körs korrekt och ändå gör fel sak. Tre varianter av detta dyker upp om och om igen:

• Antaganden som lever utanför diffen. Claude läser ditt repo, inte ditt data warehouse, din konfigurationstjänst eller kontraktet som ett annat team äger. En join kan använda rätt nycklar och ändå ändra resultatets granularitet, eftersom antalet rader per nyckel är en egenskap hos uppströmstabellen, inte koden framför dig.

• Definitioner som bara ditt team håller. Om intäkter ska räknas på order-, kund- eller veckonivå är ett affärsbeslut. Claude kan tala om att en groupby() glatt summerar vilka rader den än får. Den kan inte tala om vilket tal din finansavdelning skriver under på.

• Tids- och typantaganden. Betyder 2026-08-27 en UTC-dag, en lokal arbetsdag eller ett rapporteringsdatum satt av en uppströmsmodell? Tyst tvångskonvertering har samma form: operationer över object, nullbara heltal, tidszonsmedveten datetime och strängkolumner kan returnera något plausibelt samtidigt som de tyst ändrar hur jämförelser beter sig.

Dataläckage är det skarpaste exemplet på den första kategorin. En feature-transformation kan joina ett träningsset till en tabell som innehåller information som bara fanns efter förutsägelsedatumet. Joinen är giltig, radantalet är vad du förväntade dig, och modellen är korrumperad.

Så jag behandlar Claude som en granskare av implementationsbeteende, inte ägaren av definitionen.

När ska du använda Code Review vs Ultrareview?

Använd /code-review för snabb lokal återkoppling och /code-review ultra för en djupare genomgång före merge. Båda granskar kod, men /code-review är utformad för iteration, medan ultra-granskningen kör flera fjärragenter och verifierar rapporterade buggar oberoende.

Anthropic beskriver för närvarande ultra-granskning som en forskningsförhandsversion. Pro- och Max-prenumeranter får 3 kostnadsfria körningar som en engångsallokering som inte förnyas, varefter en granskning typiskt kostar 5 till 25 $, beroende på ändringens storlek. Team- och Enterprise-användare får inte dessa fria körningar, och funktionen är inte tillgänglig på Amazon Bedrock, Google Clouds Agent Platform, Microsoft Foundry eller för organisationer med aktiverad Zero Data Retention.

Den viktiga skillnaden är verifiering. /code-review ultra skickar repots tillstånd till en fjärrsandlåda och kör en flotta av granskningsagenter, där rapporterade buggar återskapas oberoende innan de returneras som fynd.

Jag skulle inte köra den på varje commit. Om jag ändrar ett variabelnamn i en Python-notebook eller justerar formateringen i en dbt-modell räcker en lokal /code-review gott. Om jag ändrar feature-genereringslogiken för en produktionsmodell, skriver om en intäktstransformation eller modifierar en aggregering på kundnivå, är en extra granskningspass mer rimligt.

Det finns också en namngivningsdetalj som är värd att få rätt. Det dokumenterade kommandot är /code-review ultra, och /ultrareview är ett alias som fungerar när ultrareview är tillgängligt för ditt konto. Äldre handledningar presenterar ofta /ultrareview som det primära kommandot, men Anthropics dokumentation behandlar nu den djupa molngranskningen som en del av kommandofamiljen /code-review, och /code-review ultra faller tillbaka till en lokal granskning när molnfunktionen inte är tillgänglig.

Kör ultra-granskningen på samma PR

Från repot, kör:

/code-review ultra

För att granska en GitHub-PR direkt:

/code-review ultra <pr#>

Utan argument jämför /code-review ultra din aktuella branch med standardbranchen och inkluderar ej committade och staged ändringar. En branch-granskning begränsas som standard till omkring 500 ändrade filer och 8 000 ändrade rader, även om Anthropic noterar att dessa siffror kan ändras. Om din diff är för stor, push:a branchen och granska den som en PR i stället.

Med ett PR-nummer klonar den fjärrbaserade miljön PR:en från GitHub, och ingenting laddas upp från din maskin.

Innan start visar Claude granskningsomfång, återstående fria körningar och uppskattad kostnad. Efter bekräftelse körs granskningen i bakgrunden, så du kan fortsätta använda Claude Code medan fjärragenterna arbetar.

För vårt exempel weekly_revenue.py skulle jag jämföra fynden snarare än att anta att den djupare granskningen måste ha rätt.

Om /code-review flaggar kundjoinen och ultra-granskningen oberoende återskapar samma intäktsduplicering ökar min tillit till det fyndet. Om ultra-granskningen ignorerar det för att uppströmstabellen garanterar unikhet, skulle jag inspektera bevisen från båda granskningarna och själva modelldefinitionen innan jag ändrar koden.

Det är en användbar egenskap hos flera granskare: oenighet ger dig något att undersöka.

Det finns också en kostnadsaspekt. GitHub Code Review ligger för närvarande i snitt på 15 till 25 $ per granskning, medan ultra-granskningen typiskt kostar 5 till 25 $ efter sina kostnadsfria Pro- och Max-körningar. Kostnaderna för GitHub Code Review är separata från inkluderad plananvändning, och Anthropic tillhandahåller utgiftsspärrar för organisationer.

Om du arbetar ensam är lokal /code-review plus enstaka /code-review ultra ett rimligt startarbetsflöde. Om du är på en Team- eller Enterprise-plan och vill att varje PR ska bära en automatiserad granskning är GitHub Code Review mer logiskt.

Ett praktiskt arbetsflöde för Claude Code Review

Det användbara arbetsflödet är inte ”kör Claude före varje merge.” Det är en sekvens där varje granskning sker vid olika tidpunkter i utvecklingen, eftersom varje kostar olika mycket och fångar olika typer av problem.

Här är processen jag skulle använda för en produktionsändring:

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

Den lokala granskningen fångar problem medan de är billiga att lösa. GitHub-granskningen ger det bredare teamet en gemensam logg över fynd, medan ultra-granskningen erbjuder en mer resurskrävande second opinion före en betydelsefull merge.

Ytterligare kontroller för data scientists

För dataarbete skulle jag lägga till fyra kontroller runt Claude snarare än att förvänta mig att modellen utför hela granskningen:

• Kontrollera radantal och datasetets granularitet före och efter viktiga joins
• Kör enhetstester eller integrationstester kring transformationer och featurelogik.
• Kontrollera läckage vid featurebygge för maskininlärning.
• Validera affärsmetrik mot en känd korrekt fråga eller dashboard.

Claude kan delta i alla fyra aktiviteter, men det förväntade resultatet bör komma från kod, tester eller data snarare än från Claudes förklaring.

Avslutande tankar

Claude Code Review fungerar bäst när jag behandlar den som ytterligare en ingenjör i granskningstråden, inte som en automatisk godkännandestämpel.

Det lokala kommandot /code-review ger dig en snabb granskning innan PR:en finns. GitHub Code Review för in multiagent-fynd i PR:en för Team- och Enterprise-organisationer, medan /code-review ultra ger dig en djupare fjärrgranskning när ändringen förtjänar en extra genomgång.

Jag skulle börja smått. Lägg in /code-review i ditt vanliga brancharbetsflöde, skriv en kort REVIEW.md för dina GitHub-granskningar och prova /code-review ultra på ändringar där en dålig merge faktiskt skulle kosta dig något.

För de underliggande modellkoncepten ger vår kurs Introduction to Claude Models den bredare kontexten, medan GitHub Foundations och Intermediate GitHub Concepts täcker Git- och GitHub-arbetsflödet som Code Review vilar på. För mer inspiration om hur du prioriterar GitHub-repos med Claude rekommenderar jag också vår handledning för Claude Code-connectorn.