Cum faci review la cod scris de AI: un ghid de teren

Am făcut review la mult cod scris de AI — cât pentru trei tool-uri open-source livrate (studiul de caz are inventarul). Cel mai important lucru pe care l-am învățat: dacă faci review la cod AI cu instinctele de la codul scris de oameni, o să dai greș, pentru că agenții greșesc altfel decât oamenii.

Un om obosit scrie cod neglijent — denumiri inconsistente, fundături, cusături vizibile. Neglijența este un semnal care spune uită-te mai atent. Un agent AI scrie cod impecabil: stil consistent, comentarii ordonate, structură plauzibilă — iar bug-ul stă în mijlocul lui, îmbrăcat la costum. Modul de eșec dominant nu este neglijent-și-greșit. Este plauzibil-și-greșit, iar plauzibil-și-greșit este exact modul de eșec pe care review-ul uman îl prinde cel mai prost, pentru că finisajul este euristica pe care o folosim ca să decidem unde să nu ne uităm.

Așa că disciplina se schimbă. Iată ce facem noi de fapt.

Prima întrebare: rezolvă problema enunțată?

Nu „este cod bun” — este codul potrivit? Agenții produc soluții local excelente la probleme subtil citite greșit. Cere X cu un edge case ambiguu și agentul nu va întreba înapoi; alege o interpretare, în tăcere, și o implementează superb. Înainte să citești un singur hunk, recitește task-ul, apoi verifică forma diff-ului față de el: sunt atinse fișierele la care te așteptai? Sunt atinse fișiere la care nu te așteptai? Un diff care rătăcește în afara amprentei task-ului este primul semn de alarmă.

Lucrurile concrete pe care le verificăm mai întâi

API-uri, flag-uri și chei de config inventate. Halucinația clasică a agentului: o funcție de bibliotecă ce nu există, un flag cu aspect plauzibil pe care tool-ul nu l-a avut niciodată, o cheie de config din schema altui tool. Orice traversează o graniță pe care nu ai verificări automate — invocări CLI, formate de fișiere de config, API-uri externe — se verifică față de documentația reală, nu față de încrederea agentului.

Căile de eroare. Agenții scriu happy path-uri cu convingere și error handling din memoria musculară. Citește fiecare if err != nil și întreabă-te: eroarea asta este tratată efectiv, sau este împachetată ceremonios și pasată mai departe, în timp ce funcția continuă într-o stare stricată? Se face cleanup pe return-ul timpuriu? În munca noastră pe firewall și rutare aici s-a dus timpul real de review — happy path-ul era aproape întotdeauna corect; calea de eșec era locul unde trăiesc lockout-urile.

Concurență. Stare partajată fără sincronizare, goroutine care supraviețuiesc request-ului lor, canale care pot intra în deadlock pe calea pe care nu a testat-o nimeni. Agenții reproduc convingător pattern-urile codului concurent, dar ratează raționamentul care face o instanță anume sigură. Orice diff care adaugă o goroutine, un mutex sau un canal primește o citire lentă, de fiecare dată.

Eliberarea resurselor. Fișiere și conexiuni neînchise, defer lipsă, timere care nu se opresc niciodată, contexte care nu se anulează niciodată. Individual, banale; la volumul unui agent se acumulează în leak-ul pe care îl găsești în producție trei săptămâni mai târziu.

Teste care nu verifică nimic

Capcana care își merită propria secțiune: codul în formă de test. Agenții scriu teste cu entuziasm, iar o parte din ce scriu exersează codul fără să-l verifice vreodată cu sens — afirmă că nu a apărut nicio eroare, că rezultatul nu este nil, că un mock a fost apelat. Verde, inutil.

Asta contează dublu într-un workflow agentic, pentru că întreaga buclă se sprijină pe teste ca semnal de verificare. O suită de teste goală pe dinăuntru nu doar că nu prinde bug-ul curent — îi dă agentului un semnal fals de „gata” pentru fiecare schimbare viitoare. Noi facem review la teste mai dur decât la implementare: pentru fiecare test, numește bug-ul pe care l-ar prinde. Dacă nu poți, nu este un test. Cel mai puternic obicei pe care l-am construit: din când în când, strică implementarea intenționat și confirmă că testele noi chiar devin roșii.

Review-ul de securitate nu este opțional

Orice atinge autentificarea, gestionarea sesiunilor, parsarea input-ului, căile de fișiere, SQL sau shell-out primește o a doua trecere, adversarială. Agenții antrenați pe cod public reproduc postura medie de securitate a codului public, iar media nu este bună: comenzi construite din string-uri, path join-uri pe input de la utilizator, comparații care scurg informație prin timing. Tool-urile noastre rulează pe routere și firewall-uri, așa că această trecere nu este negociabilă pentru noi — dar checklist-ul este același și pentru o aplicație web. Dacă diff-ul atinge o graniță de încredere, fă-i review ca atacator înainte să-i faci review ca maintainer.

Disciplina dimensiunii diff-ului

Cea mai eficientă tehnică de review nu este o tehnică de citit — este refuzul de a citi. Când un agent produce un diff de 2.000 de linii, review-ul atent nu mai este posibil; o să dai pe diagonală, finisajul o să te adoarmă și plauzibil-și-greșit o să treacă. Noi respingem diff-urile mari fără să le citim și retăiem task-ul mai mic. Este ușor din punct de vedere emoțional odată ce internalizezi economia: codul generat este ieftin. Să arunci o după-amiază de output al agentului costă minute de regenerat sub un task mai bine specificat și mai mic. Atenția reviewer-ului este resursa rară; cheltuie-o pe diff-uri dimensionate pentru ea.

Pune agentul să producă artefacte pentru review

Agentul poate ușura povara pe care o creează. Noi punem agentul să încheie fiecare task cu:

• Un rezumat a ce s-a schimbat și de ce — per fișier, în proză, în mesajul de commit sau în descrierea PR-ului
• Note de risc — de ce este cel mai puțin sigur, ce nu a putut testa, ce presupuneri a făcut

Două avertismente din experiență. Rezumatul este o hartă, nu teritoriul — verifică dacă diff-ul face ce spune rezumatul, pentru că o nepotrivire între cele două este ea însăși o constatare, iar rezumatele sunt ocazional aspiraționale. Iar notele de risc sunt utile doar dacă le citește cineva; ale noastre au semnalat probleme reale, cu cuvintele agentului, pe lângă care aproape că am trecut pe diagonală.

Când ai încredere, când re-verifici

Efortul de review ar trebui să urmeze riscul, nu noutatea. Pe parcursul lunilor, convențiile verificate se acumulează — forma error handling-ului, pattern-urile de teste, layout-ul de packaging — și a le rejudeca la fiecare review este atenție irosită. Pe acelea le citim în viteză. Atenția completă merge către: orice traversează o graniță de încredere, orice este concurent, orice atinge mecanismele de siguranță (căile de auto-revert din tool-urile noastre se citesc linie cu linie, la fiecare diff, fără excepții) și orice se află pe un teritoriu în care agentul nu s-a dovedit încă. Calibrarea acestui buton — lejer acolo unde convențiile sunt stabilite, strâns acolo unde blast radius-ul este real — devine, tot mai mult, adevărata meserie a reviewer-ului.

Checklist-ul reviewer-ului

1. Recitește mai întâi task-ul — apoi verifică amprenta diff-ului față de el
2. Verifică fiecare nume care traversează o graniță — API-uri, flag-uri, chei de config, față de documentația reală
3. Citește căile de eroare, nu happy path-ul — acolo agenții merg pe pilot automat
4. Citește lent tot ce este concurent — pattern-urile nu sunt demonstrații
5. Pentru fiecare test, numește bug-ul pe care l-ar prinde — fără răspuns, fără test
6. Trecere adversarială pe granițele de încredere — auth, parsare, căi, SQL, shell-out
7. Respinge diff-urile mari necitite — re-specifică mai mic; codul generat este ieftin, atenția ta nu
8. Cere rezumate și note de risc — apoi verifică dacă diff-ul se potrivește cu rezumatul
9. Cheltuie atenția după risc — dă pe diagonală convențiile dovedite, citește linie cu linie semantica de siguranță

Review-ul este jumătatea din dezvoltarea agentică care nu se comprimă — și jumătatea în care majoritatea echipelor investesc prea puțin. Dacă adopți agenți de programare AI și vrei ca disciplina de review să țină pasul, te putem ajuta să o construiești.