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”

The term “vibe coding” was coined in februarie 2025 by Andrej Karpathy, co-founder of OpenAI. His example was deliberately casual: a “throwaway weekend project” built by automatically clicking “Accept All,” ignoring the diffs and allowing the code to grow beyond his understanding.

Weeks later, developer and tool-maker Simon Willison noticed the term was being used very differently: as a stand-in for any AI-assisted programming at all, which he argued dilutes the term and gives a false impression of what responsible AI-assisted development can achieve.

What’s telling is that Karpathy eventually agreed. A year later, he introduced a different term for more disciplined work with coding agents. He described “agentic engineering” as a workflow in which developers direct and oversee agents rather than simply accepting what they produce. The distinction matters: professional AI-assisted development requires planning, scrutiny and accountability in ways that casual vibe coding does not.

Linia este Responsabilitatea

Willison’s rule is simple, and it works as a test for anyone: don’t commit code you can’t explain to someone else. That doesn’t mean reading every single line: with agents generating hundreds of lines at once, even experienced developers don’t do that anymore. It means understanding the core logic and being able to justify why the code does exactly what it does. If you can, it doesn’t matter whether a model wrote it or you did: that’s not vibe coding, that’s using a tool to build 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

The consequences of releasing software without understanding or verifying its security aren’t abstract. Tea, an app meant to help women stay safe while dating, exposed tens of thousands of ID photos and more than a million private messages across two security incidents. The failures included an unsecured storage bucket and a separate database accessible without authentication.

The same underlying problem – software appearing to work while its authorization logic remained dangerously wrong – showed up in an application built on the Lovable platform: security research found the authorization logic inverted, locking out logged-in users while letting unauthenticated attackers in freely, affecting more than 18,000 users, including students.

These aren’t isolated cases that only happen to “bad” projects. According to Google’s 2025 DORA report, 90% of developers now use AI at work, while roughly a third report little or no trust in what it generates.

AI use is now widespread, even though trust remains limited. And that makes careful review especially important when generated code handles authentication, permissions or sensitive data.

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ă.