Code review și CI cu agenți AI: ce automatizezi și ce nu

Code review-ul cu agenți AI e ușor de pornit și greu de făcut bine. Instalezi un bot pe depozit, primești comentarii pe fiecare pull request și, după trei săptămâni, echipa le ignoră sistematic. Problema nu e modelul. E că nimeni nu a decis dinainte ce clasă de verificări i se dă, ce rămâne determinist și ce anume ar trebui să se schimbe în cifre dacă lucrul funcționează.

Articolul de față e despre acele trei decizii. Fără liste de instrumente și fără promisiuni de productivitate — cu regulile de proiectare care fac diferența între un ajutor real și un generator de zgomot pe care echipa învață să îl închidă.

Contextul: gâtul de sticlă s-a mutat

Raportul DORA din 2025, publicat de Google Cloud pe baza a aproape cinci mii de răspunsuri din industrie, dă cifrele care contează pentru discuția asta: 90% dintre respondenți folosesc AI la muncă, peste 80% consideră că le-a crescut productivitatea, iar 30% raportează încredere mică sau inexistentă în codul generat.

Concluzia cea mai utilă din raport nu e însă una despre adopție, ci despre efecte. Anunțul oficial al raportului descrie o relație pozitivă între adoptarea AI și debitul livrării de software, dar precizează că adoptarea AI continuă să aibă o relație negativă cu stabilitatea livrării. Explicația dată e directă: AI accelerează dezvoltarea, iar accelerarea expune slăbiciunile din aval; fără sisteme de control solide — testare automată robustă, practici mature de versionare, bucle rapide de feedback — o creștere a volumului de modificări duce la instabilitate.

Asta e problema pe care o rezolvă, de fapt, code review-ul asistat: nu scrie cod mai repede, ci absoarbe volumul suplimentar de modificări produs de restul lanțului. Dacă îl instalezi fără să întărești și partea deterministă, ai adăugat un comentator peste o problemă de stabilitate.

Împarte verificările în trei clase, înainte de orice instalare

Exercițiul care decide totul se face pe hârtie, în treizeci de minute.

Clasa 1 — verificări deterministe. Au un răspuns unic, reproductibil, independent de model: analiză statică, verificare de tipuri, formatare, teste, acoperire, detectarea secretelor, verificarea dependențelor vulnerabile, regulile de licențiere.

Regula: acestea nu se dau niciodată unui model. Un verificator determinist dă același rezultat de fiecare dată, e instantaneu, nu costă nimic pe rulare și, cel mai important, poate bloca integrarea fără discuție. Un model care „observă" că lipsește un tip e mai lent, mai scump și nedeterminist pentru o problemă deja rezolvată.

Dacă un agent îți semnalează frecvent lucruri din clasa 1, asta nu e o realizare a agentului, ci un semn că lanțul tău determinist e incomplet. Repară acolo.

Clasa 2 — verificări care cer înțelegerea intenției. Aici modelele aduc ceva ce niciun analizor static nu are: citesc descrierea modificării, istoricul fișierului și codul din alte module, apoi observă lucruri de tipul „funcția a fost modificată, dar apelantul din alt pachet presupune vechiul contract", „modificarea de schemă nu are migrare inversă", „cazul de eroare tratat aici nu are test", „numele sugerează altceva decât face codul".

Aici merită investiția. Tot aici e și zona în care modelul greșește elegant, deci comentariile rămân sugestii.

Clasa 3 — decizii care aparțin oamenilor. Alegerile de arhitectură, compromisurile de produs, ce e acceptabil ca datorie tehnică, dacă o modificare merită făcută. Un model poate rezuma opțiunile. Nu poate alege între ele, pentru că alegerea depinde de context pe care nu îl are și de răspundere pe care nu o poartă.

Modul de lucru cu agenți pe depozite reale — instrucțiuni de proiect, control asupra contextului, integrare cu sistemul de versionare și cu fluxul de integrare continuă — e tratat pe larg în cursul Claude Code Mastery.

Regula de aur: botul comentează, omul aprobă

Aceasta nu e o preferință de proces, ci modul în care e proiectat instrumentul.

Documentația GitHub pentru revizuirea cu Copilot spune explicit: „Copilot always leaves a «Comment» review, not an «Approve» review or a «Request changes» review. This means that Copilot's reviews do not count toward required approvals for the pull request, and Copilot's reviews will not block merging changes." Cu alte cuvinte, revizuirea automată nu contează la aprobările obligatorii și nu blochează integrarea.

Merită păstrată această proprietate chiar și când folosești instrumente care ar putea bloca. Motivul e practic: un gate probabilistic care blochează integrarea produce, inevitabil, blocaje false. După a treia oară când cineva așteaptă douăzeci de minute pentru un fals pozitiv, echipa cere o cale de ocolire. Iar calea de ocolire, o dată creată, se folosește și când nu ar trebui.

Blochează doar ce e determinist. Comentează tot restul.

Aceeași documentație notează o limitare pe care o vei întâlni: la o nouă revizuire, comentariile deja respinse pot reapărea. E util să știi asta dinainte, pentru că e principala sursă de frustrare a echipei în prima lună.

Cele patru etaje ale fluxului

Un flux care funcționează are verificări în patru locuri, fiecare cu alt rol.

Etajul 1 — înainte de pull request, la autor. Cel mai ieftin loc în care se prinde o problemă. Un agent care revizuiește modificarea locală înainte de publicare economisește un ciclu întreg de așteptare. Aici tolerezi și zgomot: costul e suportat de o singură persoană, care poate ignora instantaneu.

Etajul 2 — pe pull request. Revizuirea automată, cu comentarii. Aici se aplică bugetul de zgomot de care vorbim mai jos, pentru că citește toată echipa.

Etajul 3 — în integrarea continuă. Exclusiv verificări deterministe, cu drept de blocare. Fără modele. Un pas de integrare care eșuează trebuie să eșueze din același motiv de fiecare dată.

Etajul 4 — după integrare. Aici merg analizele care nu trebuie să încetinească pe nimeni: rapoarte periodice pe zone de cod fără teste, tipare de defecte recurente, semnalarea fișierelor cu multe modificări și puțină acoperire. E și locul unde intră observabilitatea și corelarea cu incidentele — subiect acoperit în cursul AI pentru DevOps și SRE.

Greșeala frecventă e comprimarea celor patru etaje într-unul singur: totul pe pull request. Rezultatul e un pas lent, zgomotos, pe care echipa îl percepe ca taxă.

Zgomotul e problema numărul unu

Un agent de revizuire care lasă douăzeci de comentarii pe un pull request de zece fișiere nu e mai atent. E inutilizabil. Patru mecanisme care rezolvă asta:

Buget de comentarii. Limitează explicit numărul, în instrucțiune: cel mult cinci observații, ordonate după impact. Constrângerea forțează ierarhizarea, iar ce rămâne pe listă e aproape întotdeauna mai bun decât ce ar fi ieșit fără limită.

Interdicția pe stil. Formatarea și convențiile sunt rezolvate determinist. Instrucțiunea trebuie să spună explicit că observațiile de stil, denumire cosmetică sau preferință personală nu se comentează. Fără această interdicție, jumătate din comentarii vor fi acolo, pentru că sunt cel mai ușor de produs.

Severitate obligatorie. Fiecare comentariu primește o etichetă: defect probabil, risc de securitate, test lipsă, observație. Cititorul filtrează în două secunde, iar tu poți măsura pe categorii.

Filtre pe cale. Fișierele generate, migrările, fixturile și dependențele externe nu se revizuiesc. E o linie de configurare care taie o bună parte din zgomot.

Un al cincilea mecanism, mai puțin evident: cere modelului să spună când nu are context suficient. Un comentariu de forma „nu pot evalua efectul fără să văd cum e apelată funcția în modulul X" e mai valoros decât o presupunere formulată cu încredere.

Cum măsori dacă funcționează

Aici cad majoritatea inițiativelor: se raportează numărul de comentarii produse, care nu spune absolut nimic.

Metrica principală e rata de acceptare. Din comentariile lăsate de agent, câte au dus la o modificare reală de cod? Se calculează manual pe un eșantion de treizeci de pull request-uri, o dată pe lună. Sub aproximativ un sfert, fluxul produce mai mult zgomot decât valoare și trebuie restrâns — mai puține fișiere, instrucțiune mai strictă, buget mai mic.

Trei metrici de context, din setul DORA, care arată efectul real asupra livrării:

• Timpul de la commit la producție. Ar trebui să scadă sau să rămână constant. Dacă crește, revizuirea automată a devenit o etapă în plus, nu un ajutor.
• Rata modificărilor eșuate. Aceasta e metrica pe care raportul DORA o leagă direct de riscul adopției AI. Dacă urcă, accelerarea a depășit capacitatea sistemului de control.
• Timpul de restabilire după incident.

Două metrici proprii fluxului:

• Timpul până la prima reviziune. Aici se vede beneficiul imediat: autorul primește feedback în minute, nu a doua zi.
• Defecte scăpate în producție care ar fi fost prinse de o verificare din clasa 1 sau 2. Fiecare astfel de caz e o intrare într-o listă de reguli de adăugat.

Metrici capcană, de evitat: numărul de comentarii generate, procentul de pull request-uri revizuite automat, „timpul economisit" estimat de instrument. Toate cresc fără ca nimic real să se îmbunătățească.

Pentru echipele care construiesc funcționalități cu modele în produs, aceeași disciplină de măsurare se aplică și componentelor AI din aplicație — un set fix de cazuri, scor reproductibil, verificare înainte de lansare. Subiectul e tratat separat în cursul de AI Evals pentru LLM-uri în Producție.

Partea juridică și contractuală, pe scurt

Trei lucruri de clarificat înainte de a conecta un instrument la depozitul de cod al firmei.

Ce se transmite și cui. Revizuirea automată înseamnă, tehnic, trimiterea codului către un furnizor extern. Verifică în contract dacă datele sunt folosite pentru antrenare, cât timp sunt păstrate și în ce jurisdicție. Nu presupune — setările implicite diferă între planuri, iar planul individual nu are aceleași garanții ca cel de organizație.

Ce nu are voie să iasă. Depozitele cu date de producție în fixturi, chei în istoricul commit-urilor sau cod sub obligații contractuale de confidențialitate cer o decizie explicită, nu una implicită.

Competența echipei. Articolul 4 din Regulamentul (UE) 2024/1689 prevede obligația furnizorilor și a implementatorilor de sisteme de inteligență artificială de a lua măsuri pentru a asigura un nivel suficient de alfabetizare în domeniul AI în rândul personalului care se ocupă de utilizarea acestor sisteme. Obligația se aplică de la 2 februarie 2025 și privește și o firmă de software care pune astfel de instrumente la dispoziția echipei. Contextul complet e în ghidul despre alfabetizarea AI și articolul 4.

Un plan de introducere pe 90 de zile

Zilele 1–30. Doar observație. Pornești revizuirea automată pe un singur depozit, cu comentarii, fără niciun drept de blocare. Nu schimbi nimic în proces. La final ai eșantionul pe care calculezi prima rată de acceptare și lista tipurilor de comentarii inutile.

Zilele 31–60. Calibrare. Scrii instrucțiunea proprie: interdicția pe stil, bugetul de comentarii, severitățile, filtrele pe cale, ce anume contează în depozitul vostru. Recalculezi rata de acceptare. Diferența dintre configurația implicită și una calibrată e, de obicei, mai mare decât diferența dintre două instrumente.

Zilele 61–90. Extindere și mutare în amonte. Adaugi restul depozitelor și muți revizuirea cât mai devreme: la autor, înainte de publicarea modificării. Aici apare cea mai mare parte a câștigului de timp.

Permanent. O dată pe lună: rata de acceptare, cele trei metrici de livrare și lista defectelor scăpate. Fără această revizuire lunară, fluxul degradează tăcut.

Ce nu automatizezi niciodată

• Aprobarea. Rămâne a unui om care poartă răspunderea pentru ce ajunge în producție.
• Securitatea ca unic filtru. Un model poate ajuta, dar nu înlocuiește analiza dedicată și nici revizuirea umană pe zonele sensibile.
• Deciziile de arhitectură.
• Codul din zonele cu risc maxim — plăți, autentificare, date personale — unde revizuirea automată e un al doilea strat, nu primul.
• Rezolvarea automată a propriilor comentarii, fără citire. Un agent care își corectează singur observațiile și integrează modificarea închide bucla de verificare pe care tocmai o construiai.

Întrebări frecvente

Î: Poate un agent AI să înlocuiască revizuirea umană? R: Nu, și nici instrumentele nu sunt proiectate așa. Documentația GitHub precizează că revizuirea făcută de Copilot rămâne un simplu comentariu, nu contează la aprobările obligatorii și nu blochează integrarea. Rolul realist e de prim filtru, care prinde ce e mecanic și repetitiv, astfel încât revizuirea umană să se concentreze pe intenție, arhitectură și consecințe.

Î: Ce verificări nu merită date unui model? R: Tot ce are răspuns determinist: formatare, analiză statică, tipuri, teste, acoperire, detectarea secretelor, dependențe vulnerabile, licențiere. Sunt mai rapide, mai ieftine, reproductibile și pot bloca integrarea fără discuție. Dacă agentul semnalează des astfel de probleme, lanțul determinist e incomplet.

Î: Cum știu dacă revizuirea automată chiar ajută? R: Prin rata de acceptare — proporția comentariilor care au dus la o modificare reală de cod, calculată pe un eșantion de pull request-uri — coroborată cu timpul până la prima revizuire și cu metricile de livrare: timpul până în producție, rata modificărilor eșuate și timpul de restabilire. Numărul de comentarii generate nu e o metrică.

Î: De ce ar crește instabilitatea dacă folosim AI? R: Raportul DORA din 2025 descrie o relație pozitivă între adoptarea AI și debitul livrării, dar și una negativă cu stabilitatea livrării. Explicația dată în raport e că accelerarea expune slăbiciunile din aval: fără testare automată robustă, practici mature de versionare și bucle rapide de feedback, un volum mai mare de modificări duce la instabilitate.

Î: E o problemă de conformitate dacă trimit codul firmei către un furnizor extern? R: Nu automat, dar e o decizie care se ia explicit, nu implicit. Verifică în contract folosirea datelor pentru antrenare, retenția și jurisdicția, iar pentru depozitele cu obligații de confidențialitate cere o aprobare separată. Independent de asta, articolul 4 din Regulamentul (UE) 2024/1689 impune, din 2 februarie 2025, măsuri pentru un nivel suficient de alfabetizare AI în rândul personalului care folosește astfel de sisteme.

Concluzie

Un flux de revizuire cu agenți AI care funcționează arată plictisitor: verificări deterministe care blochează, comentarii puține și bine ierarhizate care nu blochează, o rată de acceptare urmărită lunar și aceleași metrici de livrare pe care le urmăreai și înainte.

Ce îl strică e mereu aceeași greșeală — se instalează un instrument în loc să se proiecteze un proces. Diferența dintre echipele la care revizuirea automată prinde defecte reale și cele la care produce zgomot ignorat nu stă în model, ci în cele treizeci de minute în care cineva a decis ce clasă de verificări merge unde.

Surse: Anunțul raportului DORA 2025, Google Cloud · Documentația GitHub — revizuirea codului cu Copilot · Regulamentul (UE) 2024/1689 privind inteligența artificială

Articol informativ, publicat la 15 august 2026. Are caracter educativ și nu constituie consultanță juridică. Capacitățile și limitările instrumentelor de revizuire automată se modifică — verifică documentația oficială a furnizorului la data implementării.