Seria II: De la infrastructură la proiecte agentice în producție. Episodul 11 din 20.
Un agent de programare poate impresiona într-o demonstrație și totuși poate produce modificări greu de acceptat în proiectul firmei. Pentru portalul B2B fictiv al seriei, decizia este concretă: ce sarcini îi putem delega și cu ce verificări? Răspunsul cere un set de evaluare al proiectului, cu rezultate observabile, buget de lucru și responsabil pentru acceptare.
În episodul despre memoria comună am stabilit cum păstrăm deciziile confirmate. Acum folosim acele decizii drept context controlat. Evaluăm agenții care dezvoltă portalul; eventualii agenți integrați în aplicație vor avea propriile evaluări, orientate spre acțiunile utilizatorilor.
Ce spune un scor și ce trebuie verificat local
Un benchmark este un set de sarcini și un protocol de măsurare, folosit pentru comparații. „State of the art”, adică performanță de ultimă generație, are sens numai dacă precizăm sarcina, protocolul și data comparației. Un scor public poate justifica investigarea unui instrument, însă nu stabilește singur ce merită delegat în portalul nostru.
SWE-bench aplică modificările generate asupra unor repository-uri reale, adică depozite de cod, și rulează teste în Docker, o platformă pentru execuția aplicațiilor în containere. Rezultatul descrie rezolvarea sarcinilor prin acele teste. Lucrarea UTBoost, publicată la ACL în iulie 2025, a identificat în evaluarea sa modificări acceptate de teste insuficiente, deși problema nu era rezolvată. Concluzia practică este că forța dovezii depinde și de evaluator. Studiul nu demonstrează că toate scorurile ori toate modificările generate sunt greșite.
Evaluăm configurația completă: modelul, instrucțiunile, contextul, instrumentele și mediul. Sistemul care leagă modelul de unelte și conduce execuția este numit uneori harness. Schimbarea lui poate modifica rezultatele chiar dacă modelul rămâne același. De aceea, comparația locală pornește de la o configurație identificabilă, nu de la numele comercial al agentului.
Un set inițial pentru portalul B2B
Propunem șase sarcini, inspirate din funcțiile portalului. Este un scenariu de evaluare, fără rezultate atribuite unui client. Fiecare sarcină pornește dintr-o versiune cunoscută a codului și are descriere, date sintetice, comportament așteptat și criterii de acceptare pregătite înaintea execuției.
Sarcină | Dovada minimă pentru acceptare |
|---|---|
Validarea unui formular de solicitare | Datele corecte sunt acceptate; câmpurile obligatorii lipsă produc mesaje utile. |
Corectarea accesului la documente | Organizația proprietară poate citi; o altă organizație primește refuz. |
Paginarea listei de solicitări | Ordinea este stabilă; pe datele fixe nu apar omisiuni sau duplicate. |
Exportul CSV, un fișier tabelar cu valori separate prin delimitatori | Coloanele, diacriticele și valorile cu separator sunt păstrate corect. |
Refactorizarea unei componente, adică reorganizarea codului fără schimbarea comportamentului | Comportamentul existent rămâne verificat, fără schimbarea contractului public. |
Investigarea unei erori incomplet descrise | Agentul reproduce problema sau cere informația necesară înainte de o modificare speculativă. |
Setul combină cazuri obișnuite, limite și comportamente care trebuie refuzate. Șase sarcini sunt un punct de pornire propus, nu un eșantion suficient pentru concluzii statistice generale. Extindem setul cu probleme relevante găsite în lucru. Separăm sarcinile folosite pentru ajustarea instrucțiunilor de cele rezervate verificării finale, pentru a evita optimizarea exclusivă pentru exemplele deja văzute.
Înaintea comparației, un dezvoltator pregătește o soluție de referință și confirmă că evaluatorul o acceptă. Verifică și o variantă intenționat greșită, care trebuie respinsă. Criteriile descriu comportamentul cerut, fără să impună inutil aceeași implementare ca referința. Pentru paginare, de exemplu, precizăm ce ordine trebuie păstrată și ce se întâmplă la ultima pagină. Agentul poate alege o soluție diferită dacă respectă contractul. O cerință nouă descoperită în review intră într-o versiune nouă a sarcinii, nu într-o penalizare retroactivă.
Verificarea trebuie să fie independentă
O evaluare compară rezultatul efectiv cu criteriile stabilite. Mesajul „am reparat problema” nu este dovadă. Rulăm codul, inspectăm datele rezultate și verificăm diferența de cod, numită diff. Testele de acceptare sunt administrate separat de agentul evaluat; acesta poate propune teste suplimentare, dar nu poate slăbi verificările oficiale pentru a obține un rezultat favorabil.
O regresie este deteriorarea unui comportament care funcționa anterior. Pe lângă testul pentru cerința nouă, rulăm verificările relevante pentru funcțiile existente. Adăugăm analiza tipurilor, verificarea stilului și controalele de securitate potrivite proiectului. Trecerea lor nu demonstrează absența tuturor defectelor. Reviewerul uman verifică lizibilitatea, respectarea arhitecturii și eventualele schimbări inutile.
Un evaluator bazat pe AI poate semnala probleme de explicație sau structură, folosind o rubrică explicită. Îi comparăm periodic verdictul cu cel al unui specialist. Ghidul Anthropic din 9 ianuarie 2026 recomandă combinarea evaluatorilor bazați pe cod, pe modele și pe oameni, în funcție de sarcină. Pentru regula de acces la documente, rezultatul testului și verificarea implementării rămân obligatorii; un scor favorabil de stil nu compensează accesul neautorizat.
Comparații echitabile și încercări repetate
Înregistrăm versiunea codului, modelul, versiunea instrumentului, instrucțiunile, sursele de context și memoria disponibilă. Fixăm limitele de timp și resurse și politica intervențiilor umane. Folosim un mediu izolat, date sintetice și credențiale de test. Fiecare încercare pornește curat, fără soluții ori conversații rămase din încercarea precedentă.
Reproductibilitatea înseamnă că altcineva poate reface protocolul și înțelege rezultatul; nu promite un răspuns identic la fiecare rulare. Propunem câteva încercări pentru fiecare sarcină, cu același buget, raportând toate rezultatele. Păstrarea doar a celei mai bune încercări ar ascunde variația pe care o va întâlni echipa.
Separăm o modificare greșită de un test imposibil de rulat din cauza mediului. Publicația Anthropic din 5 februarie 2026 arată, în experimentele proprii, că resursele și aplicarea limitelor pot influența scorurile. În raportul nostru păstrăm și numărul total de încercări și erorile de infrastructură; nu le eliminăm fără explicație. Dacă o cerință este ambiguă sau evaluatorul respinge o soluție validă, corectăm protocolul și reevaluăm configurațiile afectate.
Fișa care susține decizia de delegare
Pentru fiecare sarcină, fișa consemnează rezultatul acceptat sau respins, testele, regresiile, intervențiile, timpul de execuție, timpul de review și consumul raportat de instrument. Costul se calculează din utilizarea efectivă și condițiile comerciale aplicabile. Urmărim timpul până la o modificare acceptată, inclusiv corecturile, nu numai viteza cu care apare prima soluție.
Comparăm configurațiile pe aceleași sarcini și în raport cu fluxul actual al echipei. O configurație poate fi potrivită pentru validări de formulare și încă nepotrivită pentru schimbări de autorizare. Decizia utilă este o listă de sarcini delegabile cu verificările necesare, nu o aprobare globală a agentului. O problemă de acces între organizații blochează acceptarea acelei modificări, indiferent de rezultatul agregat.
Rezultatul episodului este un set mic de evaluare și o fișă de acceptare reutilizabilă. Le reluăm când se schimbă modelul, uneltele ori instrucțiunile și păstrăm istoricul configurațiilor. Episodul următor adaugă verificarea dependențelor și a provenienței componentelor: funcționarea codului este doar o parte a deciziei de livrare.
Surse
Documentație și lucrări verificate la 12 octombrie 2026:
- SWE-bench, Evaluation Guide, pentru evaluarea modificărilor și interpretarea rezultatelor.
- Anthropic, Demystifying evals for AI agents, 9 ianuarie 2026, ghid de inginerie pentru evaluatori și încercări repetate.
- Yu și colaboratorii, UTBoost: Rigorous Evaluation of Coding Agents on SWE-Bench, ACL, iulie 2025, pentru limitele testelor insuficiente în sarcinile investigate.
- Anthropic, Quantifying infrastructure noise in agentic coding evals, 5 februarie 2026, pentru efectul condițiilor de execuție în experimentele autorilor.
Vrei să testezi agenții de programare pe sarcini reprezentative pentru produsul tău? Discută cu echipa i8 despre criterii de acceptare și un pilot verificabil.
