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?
Nick TaylorFondator, Pitstop Technologies

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 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.
Un eveniment de plată repetat expediază comanda de două ori.
Înainte de corecție
event_A → dispatch
event_A → dispatch2 expedieri. O singură comandă.
Condiția de acceptare
event_A → dispatch
event_A → no-op1 expediere, inclusiv după reîncercare.
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.


