Code Review cu Claude Code: Prinde bug-urile înainte să ajungă în producție

Ce este Claude Code Review?

Claude Code Review este un sistem de revizuire multi-agent care examinează un PR în contextul repo-ului și raportează potențiale bug-uri, probleme de securitate și regresii. GitHub Code Review rulează acești agenți pe un PR de pe GitHub, în timp ce /code-review local îți oferă o revizuire a diff-ului curent direct din Claude Code.

Cuvântul important aici este context. O revizuire convențională a diff-ului cere cuiva să inspecteze liniile care s-au schimbat. Agenții de revizuire ai lui Claude examinează acele schimbări în contextul repo-ului. Fluxul de lucru GitHub are mai mulți agenți specializați care lucrează în paralel, urmați de verificare, deduplicare și clasificare după severitate.

De exemplu, o schimbare de 10 linii într-o transformare pandas poate depinde de schema creată de un model dbt upstream, de granulația unui tabel Snowflake și de presupuneri încorporate într-un dashboard downstream.

Claude nici nu aprobă, nici nu blochează un PR. GitHub Code Review raportează o concluzie neutră a verificării, așa că regulile existente de protecție a branch-urilor rămân neschimbate, cu excepția cazului în care îți construiești propria logică CI în jurul rezultatului verificării.

Trei suprafețe de revizuire

În prezent există 3 moduri principale de a revizui codul cu Claude Code.

Comanda locală /code-review examinează commit-urile branch-ului tău. Îi poți da și un fișier anume, un branch, un număr de PR sau un interval Git ref.

GitHub Code Review este construit în jurul PR-ului în sine. În funcție de configurarea repo-ului, poate rula o dată după crearea PR-ului, după fiecare push sau doar când cineva cere o revizuire cu @claude review.

/code-review ultra este opțiunea mai grea. Anthropic numește funcția ultrareview, iar /ultrareview funcționează ca alias când funcția este disponibilă pe contul tău. Rulează o flotă de agenți de revizuire într-un sandbox la distanță, iar fiecare bug raportat este reprodus și verificat înainte să apară în constatări. În prezent este un preview de cercetare, iar o revizuire tipică durează cam 5–10 minute.

Ce marchează Claude vs. ce omite

Claude Code Review se concentrează în primul rând pe corectitudine. Documentația Anthropic distinge în mod specific bug-urile care afectează producția de preferințele de formatare și acoperirea de test lipsă.

Constatările folosesc 3 niveluri de severitate:

Această distincție e utilă, pentru că data scientist-ii au adesea opinii foarte diferite despre ce merită timp de revizie. O sugestie de denumire între revenue_df și weekly_revenue nu e din aceeași categorie cu înmulțirea venitului cu 2, deoarece un join many-to-many a intrat într-o transformare.

Cum configurezi Code Review în Claude Code?

Configurarea Claude Code Review cere pași diferiți în funcție de faptul că vrei o revizuire locală sau o revizuire de PR pe GitHub. /code-review local nu necesită aplicația GitHub și poate fi rulat înainte să deschizi un PR. 

GitHub Code Review necesită ca un Owner sau Primary Owner al organizației să configureze aplicația Claude GitHub și să selecteze repo-urile. Când faci review-uri pentru PR, vei dori să creezi un fișier special numit REVIEW.md care conține reguli specifice doar pentru revizie.

CLAUDE.md vs. REVIEW.md

CLAUDE.md și REVIEW.md au scopuri diferite, iar amestecarea lor e o cale ușoară către recenzii zgomotoase.

CLAUDE.md conține instrucțiuni generale de proiect pe care Claude le folosește în diverse sarcini. Revizuirea de cod citește și aceste instrucțiuni, iar încălcările introduse recent sunt raportate ca nits.  REVIEW.md, pe de altă parte, este destinat specific comportamentului de revizuire și le spune agenților de revizuire ce vrea echipa ta să fie marcat, omis sau tratat ca Important.

Pentru un repo de date în Python, aș păstra CLAUDE.md concentrat pe lucruri precum structura repo-ului, cum rulezi pytest, dacă transformările folosesc pandas sau polars și unde se află modelele SQL. 

Aș pune regulile de revizuire în REVIEW.md. Câteva exemple de reguli posibile:

• „Verifică fiecare transformare nouă să aibă un test corespunzător.”
• „Nu loga niciodată credențiale.”
• „Omite fișierele generate.”

Un mic REVIEW.md ar putea arăta așa:

# 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

Îți recomand să păstrezi REVIEW.md concentrat, deoarece instrucțiunile lungi pot dilua regulile importante. Implementarea actuală citește și fișierul ca instrucțiuni simple, deci ar trebui să pui regulile direct în el, în loc să folosești prescurtarea cu @. 

Apropo, când dezvolți local, /code-review nu citește REVIEW.md. Urmează CLAUDE.md, în timp ce pipeline-ul GitHub Code Review folosește REVIEW.md pentru instrucțiuni specifice reviziei.

Dacă vrei aceleași reguli de revizuire local și pe GitHub, pune regulile generale în CLAUDE.md și repetă regulile specifice reviziei în REVIEW.md acolo unde este necesar.

Pentru mai multe detalii, îți recomand să citești ghidul nostru despre scrierea celui mai bun fișier CLAUDE.md.

Aplicația GitHub și modul de declanșare

GitHub Code Review este configurat de Owner-ul sau Primary Owner-ul unei organizații prin setările de admin ale lui Claude. Adminul trebuie să instaleze aplicația Claude GitHub, să-i acorde acces la repo, să selecteze repo-urile de revizuit și apoi să atribuie un comportament de revizuire fiecărui repo.

Există 3 moduri diferite de declanșare:

O excepție pentru toate 3: Claude nu revizuiește niciodată automat un pull request dintr-un fork. Cineva trebuie să comenteze @claude review pe el.

Începând cu actualizarea din iulie 2026, comenzile manuale s-au schimbat și ele: 

• @claude review pornește o singură revizuire și nu abonează PR-ul la push-uri viitoare. 

• @claude review always pornește o revizuire și abonează PR-ul la revizuiri declanșate de push-urile viitoare.

• @claude review once se comportă la fel ca și comanda simplă.

Dacă ai învățat Claude Code Review mai devreme în 2026, tutorialele mai vechi pot să fi spus că @claude review abonează PR-ul la revizuiri viitoare, dar acel comportament s-a schimbat în iulie 2026 și rămâne valabil în septembrie 2026.

Utilizatorii Pro și Max care nu au acces la GitHub Code Review al organizației pot sări complet peste aplicație și pot folosi /code-review local, cu /code-review ultra pentru o revizuire mai profundă.

Cum revezi local un diff cu /code-review?

Comanda locală /code-review îți revizuiește branch-ul curent înainte să deschizi un PR. Încep mereu cu asta pentru că prinde probleme cât încă lucrez și poate preveni eșecul CI.

Cazul de revizuit

Să ne imaginăm că avem un repo e-commerce cu un tabel de comenzi care conține order_id, customer_id, order_date, status și revenue, și creăm weekly_revenue.py pentru a calcula venitul săptămânal:

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

La prima vedere, nimic nu pare ciudat. merge() este explicit, gruparea e lizibilă, iar venitul este agregat după join.

Problema este că tabelul de clienți conține mai multe înregistrări istorice pentru unii clienți. Un client cu 2 înregistrări produce acum 2 rânduri după join, dublând venitul atașat acelui client. Exact acest tip de bug este ușor de ratat când citești transformarea local, fără să verifici granulația tabelului.

Stabilește aria diff-ului

Din sesiunea ta Claude Code, rulează /code-review.

Comanda revizuiește commit-urile branch-ului curent aflate înaintea branch-ului upstream, împreună cu modificările necomise. Poți viza și un fișier, un branch, un PR sau un interval anume, cum ar fi main...feature/weekly-revenue.

De exemplu:

/code-review weekly_revenue.py

sau:

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

Poți trece și un nivel de efort, de tipul /code-review high. La low și medium, revizuirea raportează doar constatările cu cel mai mare grad de încredere, în timp ce high până la max extinde acoperirea cu prețul unor posibile fals pozitive. 

Folosește flag-uri ca să ghidezi revizuirea

După ce te obișnuiești cu fluxul, două flag-uri devin utile: 

• --fix aplică constatările în arborele tău de lucru după revizuire.

• --comment le postează ca și comentarii inline.

Claude rulează revizuirea ca un subagent în fundal, astfel încât poți continua să lucrezi în timp ce procesează schimbarea. Constatările revin în sesiunea ta când revizuirea se termină.

Revizuirea ar putea raporta ceva de genul:

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

Revizuirea a găsit un mod concret de a eșua și îmi dă ceva ce pot verifica față de schema reală, în loc să-mi ceară să am încredere în judecata lui Claude.

Citește constatările

Tot aș trece manual prin totul înainte să rulez /code-review --fix. Mai întâi, caută codul care construiește customers, inspectează constrângerile de unicitate și uită-te la testele din jurul weekly_revenue.py.

Dacă customers.customer_id este realmente unic, constatarea lui Claude e un fals pozitiv. Dacă tabelul conține un rând per client per dată de intrare în vigoare, constatarea este reală, iar transformarea trebuie schimbată.

Ideea cheie este că recenzentul lui Claude se uită la comportamentul codului, în timp ce eu rămân responsabil pentru a ști ce reprezintă datele.

Îi poți cere lui Claude să investigheze după revizuire:

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.

Acest al doilea pas este adesea mai util decât să-i ceri lui Claude să repare orbește comentariul. Transformă revizuirea într-o scurtă investigație, nu într-un exercițiu de generare de cod.

Cum rulezi Claude Code Review pe un PR GitHub?

GitHub Code Review pune constatările lui Claude direct pe PR, astfel încât recenzorii pot vedea problema lângă codul schimbat. 

Ordinea contează, deoarece revizuirea se atașează unui PR care există deja:

1. Fă push la branch-ul weekly-revenue pe GitHub via git push.

2. Deschide pull request-ul. Claude poate revizui doar un PR deschis, deci nimic nu se întâmplă înainte de acest punct.

3. Dacă repo-ul e setat pe declanșare automată, revizuirea începe automat. Dacă e setat pe Manual, postează @claude review ca un comentariu de PR de nivel superior pentru a porni una.

Trei cerințe îi încurcă adesea pe oameni. Comanda trebuie să fie un comentariu de nivel superior al PR-ului, nu un răspuns la un comentariu de revizuire inline, și ai nevoie de permisiuni de write, maintain sau admin pe repo. Comanda trebuie de asemenea să deschidă comentariul, cu once sau always pe aceeași linie dacă sunt adăugate.

Declanșează revizuirea

Alegerea care te costă bani e între cele două comenzi manuale, nu între manual și automat.

@claude review rulează o singură revizuire și lasă PR-ul neabonat. @claude review always rulează o revizuire și abonează PR-ul, astfel încât fiecare push ulterior pornește una nouă.

Acesta e comportamentul după iulie 2026 și valabil în septembrie 2026. Înainte de acea actualizare, comanda simplă @claude review abona PR-ul la revizuiri viitoare, așa că, dacă urmezi un tutorial mai vechi, verifică întâi acest lucru.

Revizuirea durează adesea cam 20 de minute, deși Anthropic spune că costul și durata depind de mărimea și complexitatea PR-ului. Fiecare revizuire este de asemenea facturată separat prin credite de utilizare, nu consumă utilizarea inclusă în planul Team sau Enterprise. Dacă vrei să afli mai multe despre structura costurilor, îți recomand să citești ghidul nostru despre limitele de utilizare Claude Code.

Citește comentariile inline și check run-ul

Când revizuirea se termină, Claude postează comentarii inline pe liniile relevante. Check run-ul GitHub include și un rezumat al severității, util când un PR are multiple constatări în weekly_revenue.py, modele SQL și fișiere de test.

De exemplu:

Comentariul inline este locul unde aș investiga problema propriu-zisă. Check run-ul îmi arată forma generală a revizuirii.

Doar o notă: un click pe 👍 sau 👎 nu declanșează o altă revizuire, iar un răspuns la un comentariu inline nu îl face pe Claude să răspundă. Pentru o altă revizuire, repară codul și fă push sau postează @claude review ca un nou comentariu de PR de nivel superior.

Revizuirea nu blochează nici ea merge-ul de una singură. Verificarea oferă o concluzie neutră, deși rezultatul include informații de severitate în format lizibil de mașină pe care o echipă le poate consuma via gh și jq dacă vrea să-și construiască propria poartă de merge.

Cum triezi comentariile din revizuirea lui Claude?

Ideea este să păstrezi omul în buclă în timpul ciclului de revizuire. Asta înseamnă că fiecare revizuire Claude cere să decizi dacă fiecare constatare este un bug real, o îmbunătățire neblocantă sau un fals pozitiv. Asta pentru că un recenzent de cod poate inspecta comportamentul implementării fără să știe fiecare presupunere de business din spatele unui dataset sau metric.

Folosesc o decizie în 3 căi simple:

Acea lastă categorie e importantă. Un recenzent care raportează 30 de constatări nu e neapărat mai bun decât unul care raportează 5. Un comentariu fals pozitiv despre un merge în pandas poate costa mai mult timp decât schimbarea originală de cod.

Repară, sari sau respinge

Dacă bug-ul cu rândurile de clienți duplicate e real, i-aș cere lui Claude să inspecteze modelul upstream și apoi să facă următoarea corecție:

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 poate apoi să inspecteze repo-ul, să schimbe codul Python, să adauge testul și să ruleze suita de teste.

Dacă vrei să lucrezi pornind de la comentariile de pe GitHub, Claude Code poate interacționa și cu repo-ul prin GitHub CLI (gh). Distincția importantă este că aș alege punctual fix-urile pe care le consideri valide, în loc să-i dai întreaga revizuire ca „să repare tot”.

Asta îi păstrează pe dezvoltatori în bucla de revizuire:

1. Claude găsește o posibilă problemă.
2. Eu verific problema în raport cu codul și presupunerile despre date.
3. Claude face corecția cerută.
4. Rulează testele.
5. Claude revizuiește din nou diff-ul rezultat.

Acea buclă e mult mai sigură decât să tratezi primul rezultat al revizuirii ca o coadă automată de refactorizare.

De ce mai are nevoie un PR de date de un om?

Modul de eșec pe care Claude nu-l poate acoperi este codul care rulează corect și totuși face lucrul greșit. Trei versiuni ale acestuia apar iar și iar:

• Presupuneri care trăiesc în afara diff-ului. Claude îți citește repo-ul, nu warehouse-ul de date, serviciul tău de config sau contractul deținut de altă echipă. Un join poate folosi cheile corecte și totuși să schimbe granulația rezultatului, pentru că numărul de rânduri per cheie e o proprietate a tabelului upstream, nu a codului din fața ta.

• Definiții pe care doar echipa ta le deține. Dacă venitul ar trebui contorizat la nivel de comandă, client sau săptămână e o decizie de business. Claude îți poate spune că un groupby() va însuma fericit orice rânduri primește. Nu îți poate spune care număr este validat de echipa financiară.

• Presupuneri de timp și tip. 2026-08-27 înseamnă o zi UTC, o zi lucrătoare locală sau o dată de raportare setată de un model upstream? Coerciția tăcută are aceeași formă: operațiuni pe coloane de tip obiect, întregi nulabili, datetime cu fus orar și string pot returna ceva plauzibil, schimbând în tăcere cum se comportă comparațiile.

Scurgerea de date este cel mai accentuat exemplu din prima categorie. O transformare de feature poate face join între un set de antrenare și un tabel cu informații care existau doar după data predicției. Join-ul este valid, numărul de rânduri e cel așteptat, iar modelul e corupt.

Așa că îl tratez pe Claude ca pe un recenzent al comportamentului implementării, nu ca pe proprietarul definiției.

Când ar trebui să folosești Code Review vs Ultrareview?

Folosește /code-review pentru feedback local rapid și /code-review ultra pentru o verificare mai profundă înainte de merge. Ambele revizuiesc codul, dar /code-review este conceput pentru iterație, în timp ce ultra rulează mai mulți agenți la distanță și verifică independent bug-urile raportate.

Anthropic descrie în prezent ultra review ca un preview de cercetare. Abonații Pro și Max primesc 3 rulări gratuite o singură dată care nu se reîmprospătează, după care o revizuire costă de obicei 5–25 $, în funcție de dimensiunea schimbării. Utilizatorii Team și Enterprise nu primesc aceste rulări gratuite, iar funcția este indisponibilă pe Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry și pentru organizațiile cu Zero Data Retention activat.

Diferența importantă este verificarea. /code-review ultra trimite starea repo-ului într-un sandbox la distanță și rulează o flotă de agenți de revizuire, cu bug-urile raportate reproduse independent înainte de a fi returnate ca constatări.

Nu aș rula-o la fiecare commit. Dacă schimb un nume de variabilă într-un notebook Python sau ajustez formatarea unui model dbt, un /code-review local e suficient. Dacă schimb logica de generare a feature-elor pentru un model de producție, rescriu o transformare de venit sau modific o agregare la nivel de client, are mai mult sens o trecere suplimentară.

Există și un detaliu de denumire care merită clarificat. Comanda documentată este /code-review ultra, iar /ultrareview este un alias care funcționează atunci când ultrareview este disponibil în contul tău. Tutorialele mai vechi prezintă adesea /ultrareview ca pe comanda principală, dar documentația Anthropic tratează acum revizuirea profundă în cloud ca parte a familiei de comenzi /code-review, iar /code-review ultra revine la o revizuire locală când funcția cloud nu e disponibilă.

Rulează ultra review pe același PR

Din repo, rulează:

/code-review ultra

Pentru a revizui direct un PR GitHub:

/code-review ultra <pr#>

Fără argument, /code-review ultra compară branch-ul curent cu branch-ul implicit și include modificările nestagiate și nestocate. O revizuire pe branch e limitată implicit la aproximativ 500 de fișiere schimbate și 8.000 de linii schimbate, deși Anthropic menționează că aceste numere se pot schimba. Dacă diff-ul e prea mare, fă push la branch și revizuiește-l ca PR.

Cu un număr de PR, mediul la distanță clonează PR-ul din GitHub și nu se încarcă nimic de pe mașina ta.

Înainte de a începe, Claude arată aria revizuirii, rulările gratuite rămase și costul estimat. După confirmare, revizuirea rulează în fundal, astfel încât poți continua să folosești Claude Code cât timp agenții la distanță lucrează.

Pentru exemplul nostru cu weekly_revenue.py, aș compara constatările, nu aș presupune că revizuirea mai profundă are neapărat dreptate.

Dacă /code-review marchează join-ul pe clienți, iar ultra review reproduce independent aceeași dublare a venitului, încrederea mea în acea constatare crește. Dacă ultra review o ignoră pentru că tabelul upstream garantează unicitatea, aș inspecta dovezile din ambele revizuiri și definiția reală a modelului înainte de a schimba codul.

Acesta e un avantaj al mai multor recenzori: dezacordul îți dă ceva de investigat.

Există și un aspect de cost. GitHub Code Review costă în prezent în medie 15–25 $ per recenzie, în timp ce ultra review costă de obicei 5–25 $ după rulările gratuite Pro și Max. Costurile GitHub Code Review sunt separate de utilizarea inclusă în plan, iar Anthropic oferă controale de cheltuieli pentru organizații.

Dacă lucrezi singur, /code-review local plus un /code-review ultra ocazional este un flux de lucru rezonabil de pornire. Dacă ești pe un plan Team sau Enterprise și vrei ca fiecare PR să aibă o revizuire automată, GitHub Code Review are mai mult sens.

Un flux de lucru practic pentru Claude Code Review

Fluxul util nu este „rulează Claude înainte de fiecare merge”. Este o succesiune în care fiecare revizuire are loc într-un moment diferit al dezvoltării, pentru că fiecare costă altfel și prinde o altă clasă de probleme.

Iată procesul pe care l-aș folosi pentru o schimbare de producție:

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

Revizuirea locală prinde probleme cât timp e ieftin să le repari. Revizuirea pe GitHub oferă echipei mai largi o evidență comună a constatărilor, în timp ce ultra oferă o a doua opinie, mai costisitoare, înainte de un merge cu miză.

Verificări suplimentare pentru data scientist-i

Pentru munca pe date, aș adăuga 4 verificări în jurul lui Claude, în loc să mă aștept ca modelul să facă întreaga revizuire:

• Verifică numărul de rânduri și granulația dataset-ului înainte și după join-urile importante
• Rulează teste unitare sau de integrare în jurul transformărilor și logicii de feature.
• Verifică scurgerile atunci când construiești feature-uri de machine learning.
• Validează metricile de business față de o interogare sau un dashboard de referință.

Claude poate participa la toate cele 4 activități, dar rezultatul așteptat ar trebui să vină din cod, teste sau date, nu din explicația lui Claude.

Gânduri finale

Claude Code Review funcționează cel mai bine când îl tratez ca pe un alt inginer în thread-ul de revizuire, nu ca pe o ștampilă de aprobare automată.

Comanda locală /code-review îți oferă o revizuire rapidă înainte ca PR-ul să existe. GitHub Code Review aduce constatările multi-agent în PR pentru organizațiile Team și Enterprise, iar /code-review ultra îți oferă o revizuire mai profundă la distanță atunci când schimbarea merită o trecere suplimentară.

Aș începe modest. Pune /code-review în fluxul tău normal de lucru pe branch, scrie un REVIEW.md scurt pentru review-urile tale pe GitHub și încearcă /code-review ultra pe schimbările unde un merge prost te-ar costa cu adevărat.

Pentru conceptele de model de bază, cursul nostru Introducere în modelele Claude oferă contextul mai larg, în timp ce GitHub Foundations și Intermediate GitHub Concepts acoperă fluxul Git și GitHub pe care se sprijină Code Review. Pentru mai multă inspirație despre cum să triezi repo-urile GitHub cu Claude, îți recomand și tutorialul despre conectorul Claude Code.