Review și Verify

La finalul capitolului poți citi diff-ul unui agent în ordinea potrivită, poți spune cât dovedește o suită de teste verde și poți seta controalele care țin faza de Verify onestă.

TL;DR

• Agenții de review mătură stratul mecanic. Citirea ta rămâne pentru corectitudinea de business și potrivirea arhitecturală.
• Un diff de agent eșuează la intenție, nu la sintaxă, așa că îl citești din exterior spre interior: forma schimbării, apoi testele, apoi liniile.
• O suită verde scrisă de agent e un indiciu, nu o dovadă. Patru controale împiedică faza de Verify să-și corecteze singură tema.

Cine verifică ce

Fiecare verificare vede ce nu pot vedea celelalte, așa că bucla le rulează pe toate.

Feature-ul wire, mai departe

O suită fericită poate fi totuși greșită.

Capitolul 4 a lăsat emitter-ul de audit log cu un test verde și greșit. Reviewerul de conformitate cu spec-ul, comparând diff-ul cu planul, a prins faptul că testul verifica vechiul format de log și a semnalat o migrație căreia îi lipsea direcția de down. Reviewerul de calitate a codului, care a văzut doar diff-ul, n-a găsit nimic notabil. Subagentul implementator a reparat ambele puncte și a rerulat testele relevante.

Apoi Verify a rulat suita completă de 3.400 de teste și un smoke test pe serviciul de rutare compliance din staging și a produs un diff al schimbării de contract de API pentru review-ul reglementatorului. Toate verzi. Dovezile astea au intrat în pull request la faza de Ship din Capitolul 4.

Review: doi agenți, apoi tu

Doi revieweri, în secvență, cu prompturi diferite.

Un singur reviewer care face ambele treburi amestecă semnalele, așa că reviewerul de calitate e un alt agent, cu alt prompt, care citește doar diff-ul. Patru reguli îl țin util:

• Ține-l la corectitudine. Un reviewer pus să facă review „ca un senior” găsește mereu ceva, iar un diff reșlefuit la fiecare rundă crește abstracțiuni pe care nu le-a cerut nimeni.
• Nu-l lăsa să vadă verdictele primului reviewer. Judecătorii se ancorează de un scor anterior, și nici chain of thought, nici un avertisment explicit nu scot ancora.
• Cere acceptă-sau-respinge la fiecare constatare. Urmărește rata de reparare - constatările reparate sau respinse cu un motiv -, nu acuratețea reviewerului. O constatare pe care n-o pune nimeni în practică nu valorează nimic.
• Plafonează rundele. Într-o buclă de verificare-și-reparare măsurată, rundele târzii redeschideau munca tranșată cam la fel de des pe cât o reparau.

Fiecare constatare are o severitate: cele critice blochează ship-ul, cele importante se repară înainte de ship, iar sugestiile se notează în descrierea PR-ului, pentru reviewerul uman.

Cum faci review pe un diff scris de agent?¶

Citește din exterior spre interior: întâi intenția, la urmă liniile.

Un diff de om eșuează la execuție: o greșeală de tastare, un off-by-one, un edge case uitat. Un diff de agent compilează, trece de lint și se citește ca un cod pe care echipa ta l-ar face merge fără niciun comentariu. Eșuează cu un strat mai sus, la intenție și context: o regulă de business plauzibilă și greșită, codul corect pus în stratul greșit, codul pe care l-ar scrie un inginer bun pentru un task ușor diferit. Fluența nu e corectitudine.

Așa că petrece primele zece minute deasupra codului:

1. Diff-stat-ul raportat la plan. Forma schimbării se potrivește cu forma cererii? Un fișier pe care planul nu l-a numit niciodată e primul semnal: agentul a decis ceva ce nu i-ai cerut să decidă.
2. Citește testele pentru ce afirmă, nu pentru dacă trec. Verdele e cel mai ieftin semnal și cel pe care îl ai deja.
3. Verifică granițele despre care echipa ta a scris reguli: pattern-urile interzise din AGENTS.md, convențiile de strat, modulele periculoase de atins. Agentul le încalcă sigur pe el și în stil fluent, așa că o încălcare arată curat.
4. Dă grep pe fiecare nume nou introdus de diff pe care nu-l recunoști. Apelul care nu există se citește la fel de plauzibil ca cel care există (verificarea încrucișată e în Capitolul 6).
5. Abia acum, linie cu linie, cheltuind minutele pe care ți le-au cumpărat reviewerii pe corectitudinea de business și pe potrivirea arhitecturală.

Înainte să aprobi, pune agentul să-ți dea un quiz despre modificare: ce se întâmplă la margini, ce modul deține comportamentul nou, ce se strică primul dacă o presupunere e greșită. Trei-patru întrebări, un minut. Dacă nu poți răspunde, dădeai rubber-stamp cu pași în plus. Anexa B.8 e ordinea asta într-o singură pagină.

Verify

Verify măsoară comportamentul față de rezultatul pe care l-a definit planul.

Faza de Execute a rulat deja testele existente. Verify rulează testele noi și se întreabă dacă modificarea e corectă, nu doar dacă s-a stricat altceva.

Pentru codul de frontend, scrie-le pe accessibility tree, structura pe care browserele o întrețin pentru screen readere, nu pe pixeli și nu pe selectoare CSS. Un test Playwright care găsește câmpul etichetat Priority, îi schimbă valoarea, apasă Save și verifică noua valoare afirmă comportament și supraviețuiește unei restilizări sau schimbării bibliotecii de componente.

Poți avea încredere în testele scrise de agent?¶

Testele verzi sunt un indiciu, nu o dovadă.

Sunt un indiciu că modificarea face ce spune testul, nu că testul spune ce trebuie, așa cum a arătat testul de audit log. Coverage-ul nu închide decalajul: măsoară ce linii s-au executat, nu dacă s-a verificat ceva cu sens, iar un agent care optimizează pentru un gate de coverage scrie teste care apelează codul și nu afirmă nimic de substanță. Testele de caracterizare, prima soluție din Capitolul 8 pentru un codebase fără teste, fixează comportamentul curent, nu corectitudinea, și conservă un bug la fel de fidel cum conservă un feature: o plasă de siguranță contra regresiilor cât migrezi, niciodată o dovadă.

Așa că fă review pe testele agentului ca pe codul lui, verificând aserțiunile față de spec. Un test scris pornind de la implementare confirmă implementarea; aserțiunea trebuie să vină din intenție.

Agentul optimizează și dovezile pe care le vede. Pe SpecBench, agenții de frontieră au obținut aproape 100% pe testele vizibile și au rămas cu 43-48 de puncte în urmă pe un set ascuns. Nu e trișare în sensul uman; e un sistem care face ce răsplătește gate-ul. Patru controale închid decalajul:

• [ ] Teste held-out pe care agentul nu le vede niciodată, scrise din intenție și rulate doar la Verify.
• [ ] Istoric de git sigilat și fără egress de rețea cât rulează Verify, ca agentul să nu poată căuta răspunsul.
• [ ] Un hook PreToolUse care blochează editările la configurația de lint și de teste și blochează commit --no-verify (regulile de deny din Capitolul 9, acum la fiecare rulare).
• [ ] Explică înainte să repari. Agentul spune de ce pică un test înainte să i se permită să-l repare; un fix dat fără diagnostic e cel mai probabil cel care a editat aserțiunea în loc de cod.

Când toolkit-ul se uită în locul tău

Agenții de review sunt un filtru pus în fața judecății umane, niciodată un substitut pentru ea.

O echipă cu care am lucrat a instalat un toolkit complet de review: agenți pentru excepții înghițite, teste slabe, probleme de securitate și documentație învechită. Prindea bug-uri reale, săptămână după săptămână, reviewerii seniori au învățat să aibă încredere în bifele verzi, iar într-un trimestru review-urile lor de cincisprezece minute deveniseră scanări de trei minute. Nimeni n-a decis asta; atenția alunecă singură de pe munca ce pare deja făcută.

Apoi un PR pe care îl trecuseră toți agenții - teste verzi, zero constatări de securitate, diff curat - a aplicat o regulă de discount pe segmentul greșit de clienți și a rulat în producție săptămâni întregi, până l-a scos la iveală un tichet de suport. Toolkit-ul funcționase exact cum fusese proiectat: scosese constatările mecanice din review-ul uman, iar judecata se dusese odată cu ele. Ăsta e delegatorul necalibrat din Capitolul 9, la scară de echipă.

Soluția a fost un prag explicit: un review minim pe corectitudinea de business și pe potrivirea arhitecturală pentru fiecare PR atins de agent, urmărit ca o cifră, lângă rata de defecte. Ordinea de citire de mai sus e pragul ăsta făcut concret.

Când se strică

• Citirea degenerează într-o privire fugară la bifele verzi. Degradarea e invizibilă din interior; quiz-ul dinaintea aprobării o face măsurabilă.

De făcut luni

• [ ] Citește următorul diff de agent în ordinea de mai sus, apoi pune agentul să-ți dea un quiz înainte să aprobi. Notează la ce nu ai putut răspunde.
• [ ] Deschide ultimele trei teste scrise de agent. Aserțiunile vin din spec sau din cod?
• [ ] Împarte review-ul în două prompturi: întâi conformitatea cu spec-ul, apoi corectitudinea pe diff singur. Cere acceptă-sau-respinge la fiecare constatare.
• [ ] Adaugă cele patru controale de Verify, începând cu „explică înainte să repari”.
• [ ] Fixează un review uman minim pentru PR-urile atinse de agent și urmărește-l lângă rata de defecte.

Mai departe

• Template-uri: Anexa B.8, ordinea de citire a unui diff de agent; B.3, checklist-ul buclei.
• Deep dive: Anexa D, Capitolul 5 - măsurătorile despre review, SpecBench și Cursor în întregime și rezerva legată de accessibility tree.
• Surse: Anexa C.