Trebuie să încetăm să numim totul Vibe Coding

M-am întors la programare după o pauză lungă, iar Lovable a fost locul în care am reluat. Aplicațiile arătau grozav, funcționau la prima vedere și se realizau în câteva ore. La început, era remarcabil. Dar nu a mai fost suficient în momentul în care am vrut să știu ce face codul – și de ce. Atunci abordarea mea a început să se schimbe.

Diferența nu este despre unealtă, sau cât de mult cod scrie AI pentru tine. Este vorba despre contractul pe care îl accepți cu rezultatul tău: dacă poți explica ce ai tocmai lansat în lume, sau nu.

Vibe coding, în sensul său original, înseamnă acceptarea software-ului generat de AI fără a examina sau înțelege corect ceea ce se află dedesubt. Dezvoltarea asistată de AI este diferită. Modelul poate totuși să scrie majoritatea codului, dar persoana care construiește sistemul rămâne responsabilă pentru înțelegerea comportamentului său, testarea presupunerilor și decizia dacă este pregătit pentru livrare.

Pentru un experiment de unică folosință care nu părăsește niciodată mașina ta, diferența poate avea puține consecințe. Odată ce software-ul este implementat, utilizat de alții sau conectat la date reale, contează enorm.

Cum a pierdut sensul „Vibe Coding”

Expresia „vibe coding” a fost creată în februarie 2025 de Andrej Karpathy, cofondator OpenAI. Exemplul său era intenționat lejer: un „proiect de weekend de unică folosință”, construit apăsând automat „Acceptă tot”, ignorând diferențele și lăsând codul să crească dincolo de propria înțelegere.

Câteva săptămâni mai târziu, dezvoltatorul și creatorul de instrumente Simon Willison a observat că expresia era folosită cu un sens foarte diferit: ca substitut pentru orice formă de programare asistată de AI, ceea ce, în opinia sa, diluează termenul și creează o impresie falsă despre ceea ce poate realiza dezvoltarea responsabilă asistată de AI.

Este relevant că, în cele din urmă, Karpathy a fost de acord. Un an mai târziu, el a introdus un alt termen pentru lucrul mai disciplinat cu agenți de programare. A descris „ingineria agentică” drept un flux în care dezvoltatorii dirijează și supraveghează agenții în loc să accepte pur și simplu ceea ce produc. Distincția contează: dezvoltarea profesională asistată de AI necesită planificare, verificare și răspundere într-un mod pe care vibe coding-ul ocazional nu îl presupune.

Linia este Responsabilitatea

Regula lui Willison este simplă și funcționează ca test pentru oricine: nu valida cod pe care nu îl poți explica altei persoane. Asta nu înseamnă să citești fiecare linie; când agenții generează sute de linii odată, nici dezvoltatorii experimentați nu mai fac acest lucru. Înseamnă să înțelegi logica esențială și să poți justifica exact de ce codul face ceea ce face. Dacă poți, nu contează dacă l-a scris un model sau tu: nu este vibe coding, ci utilizarea unui instrument pentru a construi software.

Cercetarea publicată în decembrie 2025 susține această diferență. Bazându-se pe observații de teren și pe un sondaj calitativ al dezvoltatorilor profesioniști, cercetătorii au constatat că practicienii cu experiență au păstrat controlul asupra proiectării și implementării software-ului în loc să încredințeze întregul proces AI-ului. Au tratat agenții ca colaboratori, și-au planificat munca cu atenție și au rămas implicați în supraveghere.

Deci, experiența singură nu o explică. Este vorba despre dacă ești dispus să preiei responsabilitatea pentru ceea ce a generat AI. Aceasta este o decizie pe care fiecare dezvoltator o ia din nou la fiecare proiect.

Ce se întâmplă când lipsește controlul

Consecințele publicării de software fără înțelegerea sau verificarea securității sale nu sunt abstracte. Tea, o aplicație menită să ajute femeile să rămână în siguranță în timpul întâlnirilor, a expus zeci de mii de fotografii de identitate și peste un milion de mesaje private în două incidente de securitate. Deficiențele au inclus un compartiment de stocare nesecurizat și o bază de date separată, accesibilă fără autentificare.

Aceeași problemă de fond — software care pare să funcționeze, deși logica de autorizare rămâne periculos de greșită — a apărut într-o aplicație construită pe platforma Lovable: cercetarea de securitate a constatat că logica de autorizare era inversată, blocând utilizatorii autentificați și permițând atacatorilor neautentificați acces liber. Au fost afectați peste 18.000 de utilizatori, inclusiv studenți.

Acestea nu sunt cazuri izolate care apar numai în proiecte „slabe”. Potrivit Google’s 2025 DORA report, 90% dintre dezvoltatori folosesc acum AI la lucru, iar aproximativ o treime spun că au puțină sau nicio încredere în ceea ce generează.

Utilizarea AI este acum răspândită, chiar dacă încrederea rămâne limitată. De aceea, verificarea atentă este deosebit de importantă atunci când codul generat gestionează autentificarea, permisiunile sau date sensibile.

Controlul este construit în straturi, nu deodată

În cazul meu, nu am început cu un audit de securitate formal. Pur și simplu am refuzat să continui ori de câte ori nu puteam explica de ce ceva se comporta așa – un instinct natural pe care îl aduc la muncă ca analist. Mă interesează mai puțin sintaxa decât dacă rezultatul corespunde cu ceea ce am avut nevoie inițial. Când nu, continui să cercetez.

Fluxul meu de lucru a devenit mai structurat pe măsură ce proiectele au devenit mai serioase. În loc să mă bazez doar pe prompturi, am început să pregătesc specificații înainte de a genera orice. Am documentat cerințele de business, tehnologia și integrările. Apoi au venit testele unitare și testele Playwright pentru principalele călătorii ale utilizatorului.

Verificările de securitate au fost adăugate în mod similar. Am revizuit bibliotecile selectate de AI și am introdus scanarea de malware pentru fișierele încărcate. Fiecare verificare a rezultat din întrebarea ce ar putea merge greșit în continuare, în loc să urmez o listă de control pregătită la început.

Acest obicei a descoperit o problemă într-un proiect. AI-ul a introdus o bibliotecă incompatibilă cu versiunea framework-ului pe care o foloseam. Aplicația nu a eșuat complet, așa că incompatibilitatea ar fi putut rămâne ușor neobservată. Găsirea ei mai târziu ar fi făcut cauza mult mai greu de identificat.

Comparativ cu cazurile Tea și Lovable, aceasta a fost o problemă obișnuită. Am găsit-o devreme, am rezolvat-o și am continuat. Așa arată de obicei revizuirea în practică. Cel mai adesea, previne ca problemele mici să crească în altele mai mari.

Nu nu am încredere în cod doar pentru că a fost produs de AI. De asemenea, nu am încredere în el doar pentru că aplicația rulează. Testele și revizuirea sunt modul în care stabilesc dacă se comportă conform intenției.

De la Vibe Coding la Agentic Engineering

Abordarea lui Karpathy de a se îndepărta de „vibe coding” spre „agentic engineering” nu este doar o schimbare de vocabular. „Agentic engineering” ne oferă un nume mai util pentru direcția în care se îndreaptă dezvoltarea profesională. Dezvoltatorii pot scrie mai puține linii ei înșiși, dar asta nu le reduce responsabilitatea. Le mută munca spre specificarea a ceea ce sistemul ar trebui să facă, direcționarea agenților, testarea rezultatelor lor și decizia ce este sigur de lansat.

Pericolul nu este că AI generează cod rapid. Este că generarea poate avansa mai repede decât înțelegerea. Când se întâmplă asta, productivitatea aparentă ascunde riscuri pe care nimeni nu le-a examinat corespunzător.

O regulă care merită păstrată

Încetați să folosiți „vibe coding” ca etichetă pentru fiecare formă de dezvoltare asistată de AI – diluează termenul și șterge o diferență în control care contează. Stabiliți o regulă simplă: nu livrați ceea ce nu puteți explica. Și construiți controlul în proiect pe măsură ce crește, strat cu strat, adăugând verificări în pas cu riscurile care apar.

AI poate scrie majoritatea codului. Nu poate prelua responsabilitatea pentru livrarea lui. Aceasta rămâne a noastră.