Sari la conținut

Publicat 4 min de citit

AI-ul a reparat bugul. Cine verifică soluția?

Un asistent AI poate găsi o eroare și poate propune cod. Cum verifici că reparația rezolvă cauza și nu mută problema în altă parte?

NT Fondator, Pitstop Technologies

Un robot albastru repară un gândac mecanic, iar alți gândaci ies din sertarul cu piese.

Repari o eroare, reîncarci pagina și descoperi alte două. Pisica din imagine pare să știe foarte bine cum arată o zi de programare.

O pisică morocănoasă lângă o glumă despre programare: după repararea unui bug, numărul erorilor crește de la 99 la 127.

O glumă veche printre programatori, găzduită în comunitatea SitePoint. Gluma circulă de dinaintea actualei generații de asistenți AI.

Cu AI putem ajunge mai repede la o variantă de cod. Întrebarea dificilă rămâne însă aceeași: am înțeles cauza sau am făcut să dispară doar simptomul care se vedea pe ecran?

Eu vreau să folosesc instrumentele care ajută. Dar răspunderea pentru rezultat nu se mută la instrument. O modificare trebuie susținută de verificări, nu de cât de convingător sună explicația generată lângă ea.

Verificare independentă

Soluția propusă trebuie pusă la încercare.

Exemplu de eroare

Un eveniment de plată repetat expediază comanda de două ori.

Înainte de corecție

event_A → dispatch
event_A → dispatch

2 expedieri. O singură comandă.

Condiția de acceptare

event_A → dispatch
event_A → no-op

1 expediere, inclusiv după reîncercare.

AI propuneO corecție precisă
Verifică folosind eroarea inițială
Verificare independentăVerifică rezultatul salvat

Repetă evenimentul, inclusiv simultan. Verifică operațiunea efectiv realizată.

Dacă verificarea eșuează, revino la cauză. O explicație convingătoare nu ține locul unui rezultat corect.

AI-ul găsește probleme reale. Asta nu încheie verificarea.

Există exemple concrete. În anunțul de securitate Node.js din octombrie 2026, proiectul îi menționează pe cercetătorii OpenAI Codex Security pentru raportarea unei probleme în decodorul Brotli. Avem o descoperire documentată de furnizor și o corecție. Nu rezultă de aici că orice modificare propusă de AI poate fi lansată fără control. Sursa: anunțul Node.js.

Identificarea unei suspiciuni, reproducerea erorii, alegerea soluției și lansarea ei sunt etape diferite. Un asistent poate contribui la fiecare. Faptul că prima etapă a mers bine nu dovedește că toate celelalte sunt încheiate.

Îmi este util un instrument care mă ajută să citesc mai mult context sau să pun la îndoială o presupunere. Un teanc de teste generate, pe care nimeni nu le-a analizat, oferă mult mai puțină siguranță decât pare.

Mai întâi stabilim ce nu funcționează

Să luăm un exemplu ipotetic: un formular de programare pierde bugetul introdus de client când acesta schimbă limba site-ului.

O soluție rapidă ar putea pune bugetul în adresa paginii. La prima demonstrație, problema pare rezolvată. Dar este potrivit ca informația să apară acolo? Cele două versiuni ale formularului folosesc aceleași intervale? Ce se întâmplă dacă cineva schimbă valoarea din adresă sau deschide altă filă?

Înainte de cod, aș stabili comportamentul corect: schimbarea limbii păstrează cererea în lucru, clientul își poate modifica opțiunile, valorile neacceptate sunt respinse, iar informațiile unui vizitator nu ajung la altul.

Abia apoi reproduc eroarea și verific soluția. Dacă testul trece atât cu versiunea greșită, cât și cu cea corectată, nu ne ajută să facem diferența.

Testul trebuie să poată contrazice soluția

Când același asistent scrie implementarea și testele, poate repeta aceeași presupunere în ambele locuri. Totul arată ordonat, însă problema rămâne.

Pentru formular, aș verifica o valoare validă, una care nu există în opțiuni, o întrerupere a parcursului și revenirea la limba inițială. Rezultatul așteptat se stabilește din cerința clientului, nu se copiază din ce întoarce funcția nouă.

Contează și legătura dintre pagină și server. O funcție poate trece toate testele, în timp ce formularul real trimite câmpul sub alt nume. De aceea vreau să văd cererea completă, nu doar componentele verificate separat.

O modificare clară se verifică mai bine

O reparație mică poate deveni, în câteva minute, o rescriere de componentă, o bibliotecă nouă și o abstracție suplimentară. Uneori este nevoie de o schimbare mai mare. Atunci trebuie explicat de ce.

Punctul meu de plecare ar fi o corecție limitată, dar completă: cauza rezolvată, cazul care a eșuat acoperit și comportamentele apropiate verificate. La plăți mă interesează inclusiv reîncercările și mesajele repetate. La interfață, ecranul îngust, tastatura și preferința pentru mișcare redusă.

Testele automate sunt o parte din dovadă. Mai contează codul schimbat, produsul care rulează și lucrurile pe care încă nu le-am putut verifica.

Reparația trebuie să poată fi urmărită și după lansare

O modificare încheiată bine lasă explicații utile: ce nu funcționa, de ce soluția este potrivită, ce s-a verificat și cum observăm dacă problema reapare. Monitorizarea trebuie să ajute fără să umple jurnalele cu datele private ale clienților.

Aici văd valoarea AI-ului: ne poate ajuta să ajungem mai repede la o decizie susținută de dovezi. Nu elimină nevoia de judecată și nici obligația de a răspunde pentru rezultat.

Dacă ai o firmă, întrebarea esențială este: cine verifică lucrarea și cine se ocupă dacă nu merge? Este mai importantă decât cine a tastat fiecare linie.

Vezi serviciile de dezvoltare software sau spune-mi ce problemă vrei să rezolvăm. Stabilim ce trebuie investigat înainte să promitem o reparație.

De la idee la un pas concret.

Spune-ne ce trebuie să rezolve site-ul tău. Stabilim împreună cerințele, responsabilitățile și următorul pas.

Apelurile se desfășoară în engleză, cu asistență în română la cerere.