IA agentică are nevoie de mai mulți testeri, nu de mai puțini

IA agentică schimbă modul în care este livrat software-ul. Asistenții redactează cereri de integrare, agenții inițiază migrări, iar roboții de revizuire susțin că o modificare este sigură înainte ca un om să-și termine cafeaua. Industria prezintă adesea această evoluție ca pe o cale de a reduce numărul oamenilor care se ocupă de calitate. Această perspectivă este greșită. Pe măsură ce mașinile scriu o parte tot mai mare din baza de cod, abilitatea rară nu este generarea. Este verificarea independentă.

Sondajul din 2025 al dezvoltatorilor Stack Overflow a constatat că 84% dintre respondenți folosesc sau intenționează să folosească instrumente de IA în dezvoltare, iar 51% dintre dezvoltatorii profesioniști le folosesc zilnic. Percepția pozitivă a scăzut la 60%, iar mai mulți dezvoltatori nu au încredere în acuratețea IA (46%) decât au încredere în aceasta (33%). Cea mai frecventă nemulțumire, menționată de 66% dintre respondenți, a fost că soluțiile sunt aproape corecte, dar nu chiar. Cercetarea DORA din 2025 a Google Cloud a raportat că adoptarea IA în rândul profesioniștilor din dezvoltarea de software a ajuns la 90%; peste 80% au spus că IA le-a îmbunătățit productivitatea, dar numai 24% au declarat că au multă sau foarte multă încredere în IA. Utilitatea fără încredere este exact situația care extinde rolul testerului, nu îl restrânge.

Viteza nu este o dovadă

Lucrez ca inginer în asigurarea calității software, cu specializare în testarea sistemelor agentice și în porțile CI pentru codul scris de IA. În cadrul companiei, am lansat un instrument de revizuire a cererilor de integrare și un generator de cazuri de testare. Ambele sunt instrumente pentru redactarea unor versiuni preliminare. Niciunul nu își evaluează propria lucrare. Această regulă contează, fiindcă agenții vorbesc cu certitudine. Certitudinea nu înseamnă corectitudine.

Am învățat asta pe calea cea mai costisitoare. Într-un proiect-pilot pentru un instrument de revizuire a cererilor de integrare construit cu IA, o modificare a trecut de CI în mai puțin de 4 minute. Două zile mai târziu, un tablou de bord dintr-un sistem din aval a afișat temperaturi imposibile. Pe una dintre căile de execuție, pe care suita nu o testa niciodată, avusese loc o inversare a conversiei dintre Celsius și Fahrenheit. Pipeline-ul era verde. Produsul era greșit. Un CI verde, care nu a pus niciodată întrebarea dificilă, este doar o mascaradă.

Incidentul respectiv face parte dintr-un tipar mai amplu. Raportul CodeRabbit privind starea generării de cod de către IA în comparație cu cea umană a analizat 470 de solicitări de integrare GitHub din proiecte open-source (320 realizate în colaborare cu IA, 150 doar de oameni). Modificările scrise de IA au generat, în total, de aproximativ 1,7 ori mai multe probleme; erorile de logică și corectitudine au fost cu 75% mai frecvente, iar problemele de securitate au fost de până la 2,74 ori mai numeroase. Raportul Veracode din 2026 privind securitatea codului generat de IA a testat modele în cadrul unor sarcini de securitate și a constatat o rată medie de promovare a testelor de securitate de 56%, abia schimbată față de 55% în raportul anterior, în timp ce aproximativ 44% dintre sarcinile de generare de cod cu IA au introdus o vulnerabilitate cunoscută. Problema sintaxei este aproape rezolvată. Comportamentul sigur și corect nu este. Testerii sunt cei care refuză să le confunde.

Dependențele halucinate sunt o problemă de testare

Generarea inventează și pachete. Cercetarea prezentată la USENIX Security 2025, Avem un pachet pentru dumneavoastră!, a evaluat halucinațiile de pachete în cazul a 16 modele lingvistice mari (LLM) generatoare de cod și pe baza a 576.000 de eșantioane. Modelele comerciale au halucinat pachete în medie în cel puțin 5,2% din cazuri; modelele open-source au avut o medie de 21,7%, cu 205.474 de nume halucinate unice. Pachetele-fantomă persistente devin o țintă ușoară pentru atacurile de tip slop squatting: atacatorii înregistrează numele inventat și așteaptă ca un dezvoltator sau un agent să îl instaleze.

Verificările provenienței dependențelor trebuie să fie la același nivel cu testele funcționale. Dacă un agent inventează un pachet NuGet sau npm, integrarea trebuie respinsă înainte ca cineva să discute dacă testele unitare au fost suficient de riguroase. Verificarea provenienței nu este o măsură opțională de igienă. Este o poartă de calitate pentru modificările scrise de IA.

Porți de verificare care țin pasul cu agenții

Când am coordonat o actualizare la nivelul întregii organizații, de la .NET 8 la .NET 10, realizată în aproximativ două săptămâni cu ajutorul automatizării asistate de IA, eu am fost responsabil de porțile de calitate. Viteza a fost reală. La fel și nevoia de verificări care să nu creadă pe cuvânt rezumatul agentului. Verificările pe care le aplic codului modificat includ:

• Obiective privind scorul mutațiilor în intervalul 60%–70% pentru logica modificată, astfel încât suita să elimine mutanți reali, nu doar să acopere linii de cod
• Teste bazate pe proprietăți pentru logica cu risc ridicat, unde exemplele singure nu specifică suficient comportamentul
• Verificări ale provenienței dependențelor pentru a preveni deturnarea numelor de pachete inventate și folosirea pachetelor halucinate
• Indicatori de duplicare și de frecvență a modificărilor, care semnalează rescrierile haotice prin copiere și lipire ale agenților
• Verificarea independentă a afirmațiilor agentului, precum „migrarea este finalizată”, fiindcă o afirmație rămâne o ipoteză până când apar dovezile

Scorul mutațiilor nu este un indicator de fațadă. El arată dacă testele tale detectează o defecțiune introdusă intenționat. Acoperirea poate crește, în timp ce suita continuă să nu testeze calea de conversie Celsius. Verificările bazate pe proprietăți obligă modelul sistemului să funcționeze într-un interval de valori, nu doar pe o singură cale favorabilă. Verificarea provenienței ține pachetele inventate în afara depozitului de dependențe. Indicatorii de modificare frecventă și de duplicare surprind obiceiul agentului de a rescrie aceeași idee în trei feluri. Împreună, acestea alcătuiesc o abordare: pornește de la premisa că agentul greșește până când suita dovedește contrariul. Mențin această regulă de calibrare în procesul de revizuire.

Nimic din toate acestea nu înlocuiește testarea API-urilor, testarea autentificării, testarea de bază sau automatizarea interfeței cu utilizatorul. FlaUI și PowerShell detectează în continuare problemele pe care API-urile nu le surprind. Împachetarea prin NuGet, MSI și MSM necesită în continuare validarea instalării și a instalării silențioase. Fluxurile de lucru agentice amplifică volumul. Ele nu fac inutile aceste practici.

Mai mulți testeri, o muncă diferită

Teama este că agenții vor scrie testele, iar oamenii vor deveni opționali. Agenții pot redacta cazuri de testare. Nu ar trebui să-și certifice propriile proiecte. Respondenții Stack Overflow care intenționează să folosească IA pentru testare în viitor pun tot neîncrederea oamenilor în centrul discuției: când ar cere ajutorul altcuiva, principalul motiv era că nu aveau încredere în răspunsurile IA. Acest instinct este atuul profesiei.

Este important să angajăm și să sprijinim oameni care au urmat trasee profesionale neconvenționale. M-am reorientat către asigurarea calității după o carieră în operațiuni de resurse umane și analiza datelor, am absolvit un masterat în sisteme informatice la UMBC în mai 2024, iar acum îmi petrec zilele făcând practice porțile de control pentru IA agentică. IA agentică nu va aștepta ca toți să aibă același parcurs profesional. Are nevoie de mai mulți oameni care pot concepe dovezi, nu de mai puțini oameni care aprobă mecanic build-urile reușite.

Întrebarea despre produs este simplă. Dacă agenții livrează mai repede decât poate gândi procesul vostru de verificare, nu obțineți un câștig de productivitate. Obțineți un incident amânat. Investiți în testeri care tratează cu suspiciune fiecare afirmație a agenților, care integrează testarea prin mutații și proveniența în CI și care își păstrează judecata independentă acolo unde modelul este cel mai fluent și cel mai puțin fiabil. IA agentică are nevoie de mai mulți testeri, nu de mai puțini.