Programarea prin vibe a schimbat cine poate produce o aplicație care pare funcțională. Un prompt poate genera ecrane, conecta un API și asambla un flux de lucru plauzibil înainte ca o echipă tradițională de inginerie să-și fi încheiat prima analiză de design.

Această viteză creează o nouă problemă de recrutare și livrare: o demonstrație nu mai este o dovadă solidă că software-ul este bun. Angajatorii vor pune tot mai des o întrebare mai dificilă: se poate comporta corect acest sistem construit de AI atunci când datele de intrare sunt dezordonate, dependențele eșuează, utilizatorii repetă acțiuni, iar modelul de bază se schimbă?

Răspunsul va veni de la un standard de calitate care seamănă mai puțin cu finisarea vizuală și mai mult cu verificarea disciplinată a software-ului. Oamenii care se vor remarca nu vor arăta doar ce a produs un instrument AI de programare. Vor arăta cum l-au testat, ce nu poate face în siguranță și cum știu că o modificare nu a stricat altceva.

Un benchmark este o dovadă, nu un scor într-un clasament

Benchmarkurile open-source pentru agenți de programare oferă puncte de pornire utile, dar măsoară abilități diferite. SWE-bench folosește probleme reale de pe GitHub și instantanee ale depozitelor, ceea ce îl face relevant pentru activitățile de mentenanță. Terminal-Bench testează interacțiunea cu linia de comandă. Alte benchmarkuri enumerate, inclusiv SlopCodeBench și ProgramBench, vizează aspecte diferite ale codului generat și ale comportamentului agenților.

Aceste benchmarkuri pot ajuta la compararea instrumentelor sau la stabilirea unei linii de bază, dar angajatorii ar trebui să fie precauți în a trata orice scor unic drept dovadă a pregătirii pentru producție. Un model care rezolvă probleme dintr-un depozit poate produce totuși o logică nesigură de autorizare. Un agent care finalizează sarcini în terminal poate să nu păstreze starea pe durata unui flux de lucru lung. O aplicație web finisată poate trece o demonstrație pe traseul ideal, gestionând însă greșit reîncercările sau plățile duplicate.

Prin urmare, un portofoliu credibil sau o evaluare internă ar trebui să includă un set de evaluare specific sarcinii. Setul poate conține rapoarte de erori reprezentative, parcursuri obișnuite ale utilizatorilor, date de intrare incorecte, limite de permisiuni, erori ale dependențelor și regresii remediate anterior. Fiecare caz ar trebui să aibă un rezultat așteptat explicit, nu doar o captură de ecran care arată bine.

Setul minim de teste pentru software construit de AI

Pentru o aplicație mică, se poate alcătui un set util de verificări de calitate fără un laborator de cercetare elaborat:

  • Teste de acceptanță: verifică comportamentul vizibil pentru utilizator în cele mai importante fluxuri de lucru, inclusiv rezultatele reușite și nereușite.
  • Teste unitare și de integrare: verifică regulile de business în mod izolat și confirmă că bazele de date, API-urile, cozile și autentificarea funcționează împreună conform intenției.
  • Teste negative: trimit date de intrare lipsă, incorecte, prea mari, duplicate și neautorizate. Codul generat de AI arată adesea cel mai bine pe traseul prezentat în prompt, astfel că traseele nesolicitate sunt importante.
  • Teste de regresie: transformă fiecare defect descoperit într-un test permanent. O demonstrație care trece după o remediere nu este suficientă dacă aceeași eroare poate reveni în următoarea modificare generată.
  • Verificări de securitate: testează controlul accesului, gestionarea secretelor, protecția împotriva injecțiilor, vulnerabilitățile dependențelor și dacă un conținut neîncrezut poate influența apelurile către instrumente sau acțiunile privilegiate.
  • Verificări operaționale: verifică expirarea timpului, reîncercările, idempotența, jurnalizarea, alertele și comportamentul sigur atunci când o dependență nu este disponibilă.

Acest lucru este apropiat de mentalitatea de inginerie QA descrisă în relatarea Stack Overflow despre un ciclu de viață agentic al dezvoltării software. Schimbarea importantă este culturală: asigurarea calității nu este o inspecție finală după ce un AI a scris codul. Este structura care face generarea rapidă suficient de sigură pentru a fi folosită.

Testează orchestrarea, nu doar rezultatul

Atunci când software-ul include un agent AI, testele obișnuite ale aplicației sunt necesare, dar insuficiente. Sistemul poate eșua deoarece modelul a înțeles greșit o cerere, dar poate eșua și deoarece orchestrarea din jur a pierdut contextul, a apelat de două ori un instrument, a acceptat date structurate incorecte sau nu s-a oprit niciodată.

Zonele de regresie recomandate în digest înainte de implementare sunt o listă practică de verificare: pierderea contextului, idempotența instrumentelor, injecția în prompt, datele structurate de ieșire, neîncheierea, fundamentarea prin regăsire și rehidratarea stării. Acestea sunt proprietăți inginerești care pot fi testate.

De exemplu, un test poate rula aceeași cerere de două ori și poate confirma că a doua încercare nu creează o comandă duplicată. Un alt test poate întrerupe un agent la jumătatea unui flux de lucru, îl poate reporni și poate verifica dacă reia procesul dintr-o stare validă, în loc să repete o acțiune ireversibilă. Un test de regăsire poate solicita sistemului să citeze sau să returneze numai informații dintr-un set aprobat de surse. Un test al datelor structurate de ieșire poate furniza un răspuns invalid și poate confirma că aplicația îl respinge în siguranță, în loc să-l trateze în tăcere drept date valide.

Sistemele cu execuție de lungă durată și cele cu mai mulți agenți au nevoie de înregistrări de eșec deosebit de clare. Cercetătorii lucrează la atribuirea automată a eșecurilor, deoarece poate fi dificil să identifici agentul care a provocat un eșec și momentul în care s-a produs într-un lanț lung de interacțiuni. În termeni practici, echipele ar trebui să păstreze apelurile către instrumente, datele de intrare, rezultatele, versiunile modelelor, marcajele temporale, tranzițiile de stare și deciziile finale într-o pistă de audit care respectă cerințele de confidențialitate. Fără aceste dovezi, un test care eșuează îți spune că ceva nu a funcționat, dar nu și de unde să începi remedierea.

Reproductibilitatea va deveni un avantaj profesional

Codul generat de AI este variabil. O rerulare poate produce o implementare diferită; o actualizare a modelului poate schimba comportamentul; o întrerupere a serviciului furnizorului poate modifica rutarea sau latența. Prin urmare, angajatorii vor aprecia candidații care pot face evaluările repetabile.

Asta înseamnă fixarea instantaneelor modelelor acolo unde este posibil, înregistrarea prompturilor și a configurației, controlarea caracterului aleatoriu atunci când platforma permite acest lucru și rularea mai multor încercări pentru sarcinile ale căror rezultate variază. Digestul indică în mod special instantanee fixate, o temperatură scăzută sau zero acolo unde este disponibilă și porți CI/CD bazate pe limite de încredere ca măsuri de protecție utile.

Un raport practic ar trebui să distingă cel puțin trei rezultate:

  1. Rata de succes: câte cazuri au reușit.
  2. Consecvență: cât de des reușește același caz în rulări repetate.
  3. Gravitate: dacă eșecurile sunt estetice, incomode, deteriorează datele, țin de securitate sau pot provoca o acțiune externă nesigură.

Un sistem care trece 19 din 20 de verificări de formatare cu risc scăzut nu este neapărat mai bun decât unul care trece 18 din 20 de cazuri, dar nu depășește niciodată o limită de autorizare. Standardul de calitate trebuie să evalueze eșecurile în funcție de consecințe.

Revizuirea umană ar trebui să vizeze riscurile, nu fiecare linie

Scopul unei automatizări mai bune nu este să oblige o persoană să recitească fiecare token produs de un AI. Este să direcționeze atenția umană către deciziile pe care testele nu le pot soluționa pe deplin.

Evaluatorii ar trebui să se concentreze pe autentificare și autorizare, păstrarea datelor, acțiuni financiare sau contractuale, confidențialitate, migrări, recuperarea după erori, permisiunile terților și modificările care afectează chiar infrastructura de evaluare a sistemului. În cazul unui agent, ar trebui să verifice și ce instrumente poate apela, ce date poate accesa fiecare instrument și dacă este necesară aprobarea înaintea unei acțiuni ireversibile.

Diferențele vizibile, fluxurile de aprobare, conversațiile arhivate și jurnalele de audit — funcții evidențiate în descrierea Slack Code privind programarea colaborativă asistată de AI — indică o așteptare mai amplă: istoricul modului în care a fost creat software-ul va conta. Un evaluator ar trebui să poată înțelege solicitarea, inspecta modificarea generată, vedea dovezile testelor și identifica persoana care a aprobat implementarea.

Această înregistrare nu este birocrație de dragul birocrației. Ea face diferența dintre o demonstrație impresionantă și o modificare controlată pe care o altă persoană o poate întreține.

Ce să incluzi într-un portofoliu sau la un interviu

Pentru candidați, cea mai convingătoare demonstrație este un sistem mic, cu o poveste despre calitate prezentată în mod deliberat și vizibil. Include depozitul, instrucțiunile de configurare, notele despre arhitectură, comenzile de testare, cazuri de test reprezentative, limitările cunoscute și un scurt raport de eșec. Arată unul sau două erori descoperite și transformate în teste de regresie. Explică ce model sau agent de programare a fost folosit, fără a prezenta instrumentul drept autorul deciziilor de inginerie.

Dacă aplicația folosește un agent, documentează permisiunile instrumentelor, modelul de stare, politica de reîncercare, condiția de terminare și punctele de aprobare umană. Dacă folosește regăsirea informațiilor, arată cum sunt selectate sursele și ce se întâmplă când lipsesc dovezile. Dacă apelează servicii externe, demonstrează comportamentul la expirarea timpului de așteptare și la solicitări duplicate.

Nu afirma că un sistem este fiabil pe baza unei singure înregistrări reușite. O afirmație verificabilă sună mai degrabă astfel: „În 30 de rulări înregistrate ale acestor 12 scenarii, sistemul a îndeplinit criteriile de acceptare în 28; cele două eșecuri au implicat introducerea unor date ambigue și ambele sunt documentate.” Numărul în sine este mai puțin important decât metoda, limitele și sinceritatea cu privire la ceea ce nu a fost încă testat.

Noua definiție a rapidității

AI reduce costul producerii unei prime versiuni. Nu elimină costul de a ști dacă acea versiune merită încredere. De fapt, generarea mai rapidă poate face evaluarea și mai importantă, deoarece între implementări se pot acumula mai multe modificări neverificate.

Profesioniștii din era de după programarea „vibe” vor fi evaluați după buclă: definirea comportamentului, generarea sau modificarea codului, testarea cazurilor realiste și adversariale, inspectarea deciziilor cu risc ridicat, înregistrarea eșecurilor și îmbunătățirea sistemului fără pierderea dovezilor. Benchmarkurile pot ajuta la compararea capabilităților. Practicile de asigurare a calității determină dacă acea capabilitate se transformă în software fiabil.

Prin urmare, standardul de calitate nu este „Poți crea o aplicație cu AI?”, ci „Poți demonstra ce face aplicația, detecta când încetează să facă acel lucru și proiecta limitele care împiedică transformarea unui eșec într-un incident?”