Code Review z Claude Code: wyłapuj błędy, zanim trafią na produkcję

Czym jest Claude Code Review?

Claude Code Review to wieloagentowy system recenzji kodu, który analizuje PR w kontekście repo i zgłasza potencjalne błędy, problemy z bezpieczeństwem oraz regresje. GitHub Code Review uruchamia tych agentów na PR-ze w GitHubie, natomiast lokalne /code-review daje ci recenzję twojego bieżącego diffu bezpośrednio z Claude Code.

Kluczowe słowo to kontekst. Tradycyjna recenzja diffu każe komuś obejrzeć zmienione linie. Agenci Claude’a analizują te zmiany w kontekście repo. Przepływ pracy na GitHubie obejmuje wielu wyspecjalizowanych agentów działających równolegle, po czym następuje weryfikacja, deduplikacja i nadanie poziomu ważności.

Na przykład 10-liniowa zmiana w transformacji pandas może zależeć od schematu tworzonego przez upstreamowy model dbt, ziarna tabeli w Snowflake oraz założeń zakodowanych w downstreamowym dashboardzie.

Claude ani nie zatwierdza, ani nie blokuje PR. GitHub Code Review raportuje neutralny wynik checka, więc twoje istniejące reguły ochrony gałęzi pozostają bez zmian, chyba że zbudujesz własną logikę CI na podstawie wyników checka.

Trzy powierzchnie recenzji

Obecnie są 3 główne sposoby recenzowania kodu w Claude Code.

Komenda lokalna /code-review analizuje commity twojej gałęzi. Możesz też wskazać konkretny plik, gałąź, numer PR lub zakres referencji Git.

GitHub Code Review jest zaprojektowane wokół samego PR. W zależności od konfiguracji repo może uruchomić recenzję po utworzeniu PR, po każdym pushu albo tylko wtedy, gdy ktoś poprosi o recenzję, wpisując @claude review.

/code-review ultra to cięższa opcja. Anthropic nazywa tę funkcję ultrareview i /ultrareview działa jako alias, jeśli funkcja jest dostępna na twoim koncie. Uruchamia flotę agentów recenzujących w zdalnym sandboxie, a każdy zgłoszony błąd jest odtworzony i zweryfikowany, zanim trafi do wyników. Obecnie to research preview, a typowa recenzja trwa około 5–10 minut.

Co Claude zgłasza, a co pomija

Claude Code Review najpierw koncentruje się na poprawności. Dokumentacja Anthropic wyraźnie odróżnia błędy wpływające na produkcję od preferencji formatowania i braków pokrycia testami.

Znaleziska mają 3 poziomy ważności:

To rozróżnienie jest przydatne, bo data scientistom często bardzo różnie się wydaje, co zasługuje na czas recenzji. Sugestia nazwy revenue_df kontra weekly_revenue to nie to samo, co podwojenie przychodu, ponieważ do transformacji wkradło się złączenie wiele‑do‑wielu podczas transformacji.

Jak skonfigurować Code Review w Claude Code?

Konfiguracja Claude Code Review różni się w zależności od tego, czy chcesz recenzję lokalną, czy recenzję kodu PR-a na GitHubie. Lokalna komenda /code-review nie wymaga aplikacji GitHub i można z niej korzystać, zanim w ogóle otworzysz PR. 

GitHub Code Review wymaga, aby Właściciel lub Główny Właściciel organizacji skonfigurował aplikację Claude GitHub i wybrał repozytoria. Przy recenzjach PR warto utworzyć specjalny plik REVIEW.md ze specyficznymi zasadami tylko do recenzji.

CLAUDE.md vs. REVIEW.md

CLAUDE.md i REVIEW.md służą innym celom i łatwo narobić hałasu w recenzjach, mieszając je ze sobą.

CLAUDE.md zawiera ogólne instrukcje projektu, których Claude używa w różnych zadaniach. Recenzja kodu też je czyta, a nowo wprowadzone naruszenia są raportowane jako nity.  REVIEW.md z kolei dotyczy konkretnie zachowania podczas recenzji i mówi agentom recenzującym, co twój zespół chce flagować, pomijać lub traktować jako Important.

W repo z danymi w Pythonie trzymałbym w CLAUDE.md rzeczy takie jak struktura repo, jak uruchamiać pytest, czy transformacje używają pandas czy polars, i gdzie leżą modele SQL. 

Zasady recenzji umieściłbym w REVIEW.md. Oto kilka przykładowych reguł:

• „Sprawdzaj każdą nową transformację pod kątem odpowiadającego jej testu.”
• „Nigdy nie loguj poświadczeń.”
• „Pomijaj pliki generowane.”

Mały plik  REVIEW.md mógłby wyglądać tak:

# 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

Polecam trzymać REVIEW.md w ryzach, bo długie instrukcje rozwadniają ważne reguły. Obecna implementacja czyta plik jako zwykłe instrukcje, więc wpisuj reguły bezpośrednio, zamiast używać skrótu @. 

A tak przy okazji, podczas pracy lokalnej /code-review nie czyta  REVIEW.md. Podąża za CLAUDE.md, podczas gdy pipeline GitHub Code Review używa  REVIEW.md do instrukcji specyficznych dla recenzji.

Jeśli chcesz mieć te same zasady lokalnie i na GitHubie, umieść ogólne reguły w CLAUDE.md i w razie potrzeby powtórz reguły recenzyjne w REVIEW.md.

Po więcej szczegółów zajrzyj do naszego przewodnika pisania najlepszego pliku CLAUDE.md.

Aplikacja GitHub i tryb wyzwalania

GitHub Code Review konfiguruje Właściciel lub Główny Właściciel organizacji w ustawieniach administracyjnych Claude’a. Administrator musi zainstalować aplikację Claude GitHub, nadać jej dostęp do repo, wybrać repozytoria do recenzji, a potem przypisać zachowanie recenzji do każdego repo.

Są 3 tryby wyzwalania:

Jeden wyjątek dla wszystkich 3: Claude nigdy automatycznie nie recenzuje pull requestu z forka. Ktoś musi skomentować @claude review jako komentarz.

Od aktualizacji z lipca 2026 zmieniły się też komendy ręczne: 

• @claude review uruchamia pojedynczą recenzję i nie zapisuje PR do przyszłych pushy. 

• @claude review always uruchamia recenzję i subskrybuje PR do przyszłych recenzji wyzwalanych pushem.

• @claude review once działa tak samo jak komenda bez dodatkowych słów.

Jeśli poznawałeś Claude Code Review wcześniej w 2026, starsze tutoriale mogły mówić, że @claude review subskrybuje PR do przyszłych recenzji, ale to zachowanie zmieniło się w lipcu 2026 i jest aktualne we wrześniu 2026.

Użytkownicy Pro i Max, którzy nie mają dostępu do GitHub Code Review organizacji, mogą całkiem pominąć aplikację i używać /code-review lokalnie, a do głębszej analizy /code-review ultra.

Jak lokalnie zrecenzować diff komendą /code-review?

Lokalna komenda /code-review recenzuje twoją bieżącą gałąź, zanim otworzysz PR. Zawsze od tego zaczynam, bo wyłapuje problemy, gdy nad nimi pracuję, i może zapobiec padnięciu CI.

Przypadek do recenzji

Załóżmy, że mamy repo e‑commerce z tabelą zamówień zawierającą order_id, customer_id, order_date, status i revenue, i tworzymy weekly_revenue.py, aby policzyć tygodniowy przychód:

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

Na pierwszy rzut oka nic nie wygląda podejrzanie. merge() jest jawny, grupowanie czytelne, a przychód agregowany po złączeniu.

Problem w tym, że tabela klientów zawiera wiele historycznych rekordów dla części klientów. Klient z 2 rekordami daje teraz po złączeniu 2 wiersze, podwajając przychód przypisany do tego klienta. To dokładnie ten typ błędu, który łatwo przeoczyć, czytając transformację lokalnie bez sprawdzenia ziarna tabeli.

Zasięg diffu

W swojej sesji Claude Code uruchom /code-review.

Komenda recenzuje commity bieżącej gałęzi względem gałęzi nadrzędnej, razem z niezacommitowanymi zmianami. Możesz też wskazać konkretny plik, gałąź, PR albo zakres, np. main...feature/weekly-revenue.

Na przykład:

/code-review weekly_revenue.py

albo:

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

Możesz też przekazać poziom wysiłku, np. /code-review high. Przy low i medium recenzja raportuje tylko te znaleziska, co do których ma najwyższą pewność, podczas gdy high do max zwiększają pokrycie kosztem większej liczby potencjalnych false positives. 

Flagi do sterowania recenzją

Gdy poczujesz się swobodniej z tym przepływem, przydadzą się dwie flagi: 

• --fix zastosuje poprawki do twojego working tree po recenzji.

• --comment doda je jako komentarze inline.

Claude uruchamia recenzję jako subagenta w tle, więc możesz dalej pracować, gdy on przetwarza zmiany. Znaleziska wrócą do twojej sesji po zakończeniu recenzji.

Recenzja może zgłosić coś w tym stylu:

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

Recenzja znalazła konkretny tryb błędu i daje mi coś, co mogę zweryfikować względem faktycznego schematu, zamiast prosić mnie o zaufanie ocenie Claude’a.

Czytaj znaleziska

Wciąż dałbym wszystkiemu ręczny przegląd, zanim uruchomię /code-review --fix. Najpierw znajdź kod budujący customers, sprawdź jego ograniczenia unikalności i przyjrzyj się testom wokół weekly_revenue.py.

Jeśli customers.customer_id jest rzeczywiście unikalne, znalezisko Claude’a to false positive. Jeśli tabela zawiera po jednym wierszu na klienta na datę obowiązywania, znalezisko jest prawdziwe i transformację trzeba zmienić.

Kluczowe jest to, że recenzent Claude’a patrzy na zachowanie kodu, a ja nadal odpowiadam za wiedzę, co dane reprezentują.

Po recenzji możesz poprosić Claude’a o dochodzenie:

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.

Ten drugi krok bywa często bardziej użyteczny niż proszenie Claude’a o ślepe poprawienie komentarza. Zamienia recenzję w krótkie dochodzenie, a nie ćwiczenie z generowania kodu.

Jak uruchomić Claude Code Review na PR-ze w GitHubie?

GitHub Code Review umieszcza znaleziska Claude’a bezpośrednio w PR, dzięki czemu recenzenci widzą problem obok zmienionego kodu. 

Kolejność ma znaczenie, bo recenzja podczepia się do już istniejącego PR:

1. Wypchnij gałąź weekly-revenue na GitHuba przez git push.

2. Otwórz pull request. Claude może recenzować tylko otwarty PR, więc przed tym nic się nie wydarzy.

3. Jeśli repo ma ustawiony automatyczny wyzwalacz, recenzja startuje sama. Jeśli ustawione jest Manual, wstaw @claude review jako komentarz najwyższego poziomu w PR, aby ją uruchomić.

Trzy wymagania często potrafią zbić z tropu. Komenda musi być komentarzem najwyższego poziomu w PR, a nie odpowiedzią na komentarz inline, i potrzebujesz uprawnień write, maintain lub admin w repo. Komenda musi też zaczynać komentarz, z once lub always w tej samej linii, jeśli są dodane.

Wyzwól recenzję

Wybór, który faktycznie kosztuje, to decyzja między dwiema komendami ręcznymi, a nie między trybem ręcznym i automatycznym.

@claude review uruchamia jedną recenzję i pozostawia PR bez subskrypcji. @claude review always uruchamia recenzję i subskrybuje PR, więc każdy późniejszy push startuje nową.

Tak to działa po lipcu 2026 i we wrześniu 2026. Przed tą aktualizacją gołe @claude review subskrybowało PR do przyszłych recenzji, więc jeśli śledzisz starszy tutorial, sprawdź to najpierw.

Recenzja często trwa około 20 minut, choć Anthropic podaje, że koszt i czas zależą od wielkości i złożoności PR. Każda recenzja jest też rozliczana osobno z kredytów użycia, a nie w ramach wliczonego użycia planu Team lub Enterprise. Jeśli chcesz poznać strukturę kosztów, polecam nasz przewodnik po limitach użycia Claude Code.

Czytaj komentarze inline i check run

Gdy recenzja się kończy, Claude dodaje komentarze inline do odpowiednich linii. Check run na GitHubie zawiera też podsumowanie ważności, co przydaje się, gdy PR ma wiele znalezisk w weekly_revenue.py, modelach SQL i plikach testów.

Na przykład:

Komentarz inline to miejsce, gdzie badałbym faktyczny problem. Check run służy do uchwycenia ogólnego obrazu recenzji.

Dla jasności: kliknięcie 👍 lub 👎 nie wyzwala kolejnej recenzji, a odpowiedź na komentarz inline nie sprawi, że Claude odpowie. Aby dostać nową recenzję, popraw kod i zrób push albo wstaw @claude review jako nowy komentarz najwyższego poziomu w PR.

Recenzja też sama z siebie nie blokuje mergowania. Check ma neutralny wynik, choć jego output zawiera maszynowo czytelną informację o ważności, którą zespół może przetwarzać przez gh i jq, jeśli chce zbudować własną bramkę merge.

Jak triagować komentarze z recenzji Claude’a?

Chodzi o to, by człowiek był w pętli podczas cyklu recenzji. To znaczy, że każda recenzja Claude’a wymaga decyzji, czy dane znalezisko to prawdziwy błąd, nieblokująca poprawa, czy false positive. Recenzent kodu może ocenić zachowanie implementacji, nie znając wszystkich założeń biznesowych stojących za zbiorem danych czy metryką.

Używam prostego trójpodziału:

Ta ostatnia kategoria jest ważna. Recenzent, który zgłosi 30 znalezisk, niekoniecznie jest lepszy od tego, który zgłosi 5. Komentarz jako false positive o złączeniu w pandas może kosztować więcej czasu niż pierwotna zmiana kodu.

Napraw, pomiń lub odeprzyj

Jeśli błąd zduplikowanych wierszy klientów jest prawdziwy, mógłbym poprosić Claude’a o zbadanie modelu upstream, a następnie wprowadzenie takiej poprawki:

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 może wtedy przejrzeć repo, zmienić kod w Pythonie, dodać test i uruchomić suite testów.

Jeśli chcesz działać na komentarzach z GitHuba, Claude Code może też współpracować z repo przez GitHub CLI (gh). Ważne jest, by wybierać konkretne poprawki, które uważasz za zasadne, zamiast dawać mu całą recenzję do „naprawienia wszystkiego”.

To utrzymuje deweloperów w pętli recenzji:

1. Claude znajduje potencjalny problem.
2. Ja weryfikuję problem względem kodu i założeń danych.
3. Claude wprowadza żądaną poprawkę.
4. Uruchamiane są testy.
5. Claude ponownie recenzuje powstały diff.

Ta pętla jest dużo bezpieczniejsza niż traktowanie pierwszych wyników recenzji jako kolejki do automatycznego refaktoringu.

Po co wciąż człowiek przy data PR?

Tryb awarii, którego Claude nie obejmie, to kod, który działa poprawnie, a mimo to robi niewłaściwą rzecz. Trzy wersje tego wracają w kółko:

• Założenia poza diffem. Claude czyta twoje repo, a nie hurtownię danych, serwis konfiguracyjny ani kontrakt innego zespołu. Złączenie może używać właściwych kluczy, a mimo to zmienić ziarno wyniku, bo liczba wierszy na klucz to własność tabeli upstream, a nie kodu przed tobą.

• Definicje tylko twojego zespołu. Czy przychód liczymy na poziomie zamówienia, klienta czy tygodnia, to decyzja biznesowa. Claude powie ci, że groupby() chętnie zsumuje dowolne podane wiersze. Nie powie, którą liczbę akceptuje dział finansów.

• Założenia dot. czasu i typów. Czy 2026-08-27 to dzień w UTC, lokalny dzień roboczy, czy data raportowa ustawiona przez model upstream? Ciche rzutowania mają podobny kształt: operacje na kolumnach object, nullowalnych integerach, datetime ze strefą i stringach mogą zwrócić coś wiarygodnego, po cichu zmieniając zachowanie porównań.

Wycieki danych to najostrzejszy przykład pierwszej kategorii. Transformacja cechy może połączyć zbiór treningowy z tabelą zawierającą informacje, które istniały dopiero po dacie predykcji. Złączenie jest poprawne, liczba wierszy się zgadza, a model jest skażony.

Dlatego traktuję Claude’a jako recenzenta zachowania implementacji, a nie właściciela definicji.

Kiedy używać Code Review, a kiedy Ultrareview?

Używaj /code-review do szybkiej lokalnej informacji zwrotnej dla /code-review ultra do głębszej analizy przed mergem. Oba recenzują kod, ale /code-review jest zaprojektowane pod iteracje, podczas gdy ultra uruchamia wielu zdalnych agentów i niezależnie weryfikuje zgłoszone błędy.

Anthropic opisuje obecnie ultra review jako research preview. Abonenci Pro i Max otrzymują jednorazowo 3 bezpłatne uruchomienia, które się nie odnawiają, po czym recenzja zwykle kosztuje 5–25 USD, zależnie od rozmiaru zmiany. Użytkownicy Team i Enterprise nie dostają tych darmowych uruchomień, a funkcja jest niedostępna na Amazon Bedrock, Agent Platform Google Cloud, Microsoft Foundry oraz dla organizacji z włączonym Zero Data Retention.

Ważna różnica to weryfikacja. /code-review ultra wysyła stan repo do zdalnego sandboxa i uruchamia flotę agentów recenzujących, a zgłoszone błędy są niezależnie odtwarzane, zanim wrócą jako znaleziska.

Nie uruchamiałbym tego przy każdym commicie. Jeśli zmieniam nazwę zmiennej w notatniku Pythona albo poprawiam formatowanie modelu dbt, wystarczy lokalne /code-review. Jeśli zmieniam logikę generowania cech w modelu produkcyjnym, przepisuję transformację przychodów lub modyfikuję agregację na poziomie klienta, dodatkowy przegląd ma większy sens.

Jest też detal nazewnictwa, który warto mieć na uwadze. Udokumentowana komenda to /code-review ultra, a /ultrareview jest aliasem, który działa, gdy ultrareview jest dostępne na twoim koncie. Starsze tutoriale często podają /ultrareview jako główną komendę, ale dokumentacja Anthropic traktuje dziś głęboką recenzję w chmurze jako część rodziny /code-review, a /code-review ultra wraca do recenzji lokalnej, gdy funkcja chmurowa jest niedostępna.

Uruchom ultra review na tym samym PR

W repo uruchom:

/code-review ultra

Aby zrecenzować bezpośrednio PR na GitHubie:

/code-review ultra <pr#>

Bez argumentu /code-review ultra porównuje twoją bieżącą gałąź z domyślną i uwzględnia niezacommitowane i stagenięte zmiany. Przegląd gałęzi domyślnie ogranicza się do ok. 500 zmienionych plików i 8000 zmienionych linii, choć Anthropic zaznacza, że te liczby mogą się zmieniać. Jeśli twój diff jest za duży, wypchnij gałąź i zrecenzuj ją jako PR.

Z numerem PR środowisko zdalne klonuje PR z GitHuba i nic nie jest wysyłane z twojej maszyny.

Przed startem Claude pokazuje zakres recenzji, pozostałe darmowe uruchomienia i szacunkowy koszt. Po potwierdzeniu recenzja leci w tle, więc możesz dalej używać Claude Code, gdy zdalni agenci pracują.

Dla naszego przykładu weekly_revenue.py porównałbym znaleziska zamiast zakładać, że głębsza recenzja musi mieć rację.

Jeśli /code-review flaguje złączenie klientów, a ultra review niezależnie odtwarza to samo zdublowanie przychodów, rośnie moja pewność co do znaleziska. Jeśli ultra to pomija, bo tabela upstream gwarantuje unikalność, obejrzałbym dowody z obu recenzji i definicję modelu, zanim zmienię kod.

To zaleta wielu recenzentów: rozbieżność daje coś do zbadania.

Jest też aspekt kosztów. GitHub Code Review to obecnie średnio 15–25 USD za recenzję, podczas gdy ultra zwykle kosztuje 5–25 USD po wykorzystaniu darmowych uruchomień Pro i Max. Koszty GitHub Code Review są oddzielne od wliczonego użycia planu, a Anthropic zapewnia kontrolę wydatków dla organizacji.

Jeśli pracujesz solo, lokalne /code-review plus okazjonalne /code-review ultra to rozsądny start. Jeśli jesteś w planie Team lub Enterprise i chcesz, by każdy PR miał automatyczną recenzję, bardziej sensowne jest GitHub Code Review.

Praktyczny workflow Claude Code Review

Użyteczny workflow to nie „uruchamiaj Claude’a przed każdym mergem”. To sekwencja, gdzie każda recenzja dzieje się w innym momencie developmentu, bo każda kosztuje co innego i łapie inny typ problemu.

Oto proces, którego użyłbym przy zmianie produkcyjnej:

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

Lokalna recenzja łapie problemy, gdy są tanie do naprawy. Recenzja GitHub daje szerszemu zespołowi wspólny zapis znalezisk, a ultra oferuje bardziej wymagającą drugą opinię przed istotnym mergem.

Dodatkowe sprawdzenia dla data scientistów

Przy pracy z danymi dodałbym 4 kontrole wokół Claude’a, zamiast oczekiwać, że model zrobi całą recenzję:

• Sprawdzaj liczby wierszy i ziarno zbioru przed i po ważnych złączeniach
• Uruchamiaj testy jednostkowe lub integracyjne wokół transformacji i logiki cech.
• Sprawdzaj wycieki przy budowie cech ML.
• Weryfikuj metryki biznesowe względem sprawdzonego zapytania lub dashboardu.

Claude może uczestniczyć we wszystkich 4 działaniach, ale oczekiwany wynik powinien pochodzić z kodu, testów lub danych, a nie z wyjaśnienia Claude’a.

Na koniec

Claude Code Review działa najlepiej, gdy traktuję go jak kolejnego inżyniera w wątku recenzji, a nie jak automatyczną pieczątkę akceptacji.

Lokalna komenda /code-review daje ci szybką recenzję, zanim PR istnieje. GitHub Code Review wnosi wieloagentowe znaleziska do PR dla organizacji Team i Enterprise, a /code-review ultra daje głębszą zdalną recenzję, gdy zmiana zasługuje na dodatkowe spojrzenie.

Zacznij małymi krokami. Włącz /code-review do standardowego workflow gałęzi, napisz krótki REVIEW.md dla recenzji GitHub i wypróbuj /code-review ultra przy zmianach, gdzie zły merge faktycznie kosztowałby cię coś.

Jeśli chodzi o koncepcje modeli, nasz kurs Introduction to Claude Models daje szerszy kontekst, a GitHub Foundations i Intermediate GitHub Concepts omawiają workflow Git i GitHub, na którym opiera się Code Review. Aby zobaczyć więcej inspiracji, jak triagować repozytoria GitHuba z Claude’em, polecam też nasz tutorial o konektorze Claude Code.