Vibe coding: aplicații care merg, dar nu rezistă

În februarie 2025, Andrej Karpathy, unul dintre fondatorii OpenAI, a descris un nou fel de a programa: îi spui unui asistent AI ce vrei, accepți tot ce scrie, lipești erorile înapoi în chat și „uiți că există codul”. I-a spus vibe coding. Termenul a prins atât de repede încât dicționarul Collins l-a ales cuvântul anului 2025.

Rezultatele sunt spectaculoase: în câteva ore ai o aplicație care arată bine, are login, formulare și un tabel cu date. Și totuși, multe dintre aceste aplicații se prăbușesc când ajung în fața utilizatorilor reali. Iar motivul nu e cel la care se așteaptă majoritatea oamenilor.

Problema nu e codul#

Modelele de azi scriu cod corect, curat și adesea mai bine documentat decât al multor programatori. Dacă le ceri o funcție care validează un CNP sau calculează TVA-ul, o primești bine făcută.

Problema e arhitectura: deciziile care nu stau în nicio funcție anume, ci în felul în care se leagă toate între ele.

• Cum arată datele și cum vor crește în doi ani?
• Cine are voie să vadă și să modifice fiecare informație?
• Unde se ține starea aplicației și ce se întâmplă când doi utilizatori modifică același lucru simultan?
• Ce se întâmplă când un serviciu extern (plăți, email, curierat) nu răspunde?
• Cum se face o copie de siguranță și cum o restaurezi?

În vibe coding, fiecare cerere rezolvă o problemă locală: „adaugă un buton de export”, „repară eroarea de aici”, „fă și o pagină de administrare”. Asistentul vede cererea curentă și o parte din cod, nu imaginea de ansamblu. Nimeni nu ține minte de ce s-a luat o decizie acum trei zile și nimeni nu verifică dacă noua bucată se potrivește cu restul.

Se vede și în cifre. GitClear a analizat peste 200 de milioane de linii de cod modificate și a găsit că, odată cu asistenții AI, blocurile de cod duplicat s-au înmulțit de câteva ori, iar refactorizarea (reorganizarea codului existent) a scăzut cu aproape 40%¹. Cu alte cuvinte, se adaugă mereu cod nou, în loc să se construiască pe ce există deja. Fiecare copie e o viitoare eroare reparată într-un loc și uitată în altul.

„Merge” nu înseamnă „funcționează”#

O aplicație făcută prin vibe coding e testată, de obicei, de autorul ei, pe drumul fericit: completează formularul corect, apasă butonul corect și vede rezultatul corect. Totul pare gata.

Producția înseamnă altceva:

În sondajul Stack Overflow din 2025, două treimi dintre programatori au spus că principala lor problemă cu AI-ul sunt soluțiile „aproape corecte, dar nu chiar”³. Un programator recunoaște un „aproape corect”. Cineva care face vibe coding, prin definiție, nu se uită la cod.

Ce s-a întâmplat în practică#

Datele utilizatorilor, la vedere. În 2025, un cercetător a verificat 1.645 de aplicații din vitrina publică a Lovable, una dintre cele mai populare platforme de vibe coding. La 170 dintre ele, adică una din zece, oricine putea citi sau modifica baza de date fără să se autentifice: emailuri, telefoane, date despre plăți, chei de acces la alte servicii⁴. Aplicațiile funcționau perfect. Pur și simplu nimeni nu se gândise cine are voie să vadă ce.

Baza de date ștearsă. În iulie 2025, fondatorul SaaStr a documentat un experiment de 12 zile cu agentul AI de la Replit. În ziua a noua, deși îi ceruse explicit să nu modifice nimic, agentul a șters baza de date cu peste 1.200 de înregistrări, apoi a susținut că nu se mai poate recupera⁵. Datele s-au recuperat până la urmă din copii de siguranță. Replit a introdus ulterior separarea automată a bazelor de date de dezvoltare și de producție, adică exact genul de decizie de arhitectură care lipsea.

Cod nesigur, din start. Veracode a dat peste 100 de modele AI sarcini de programare în care exista o variantă sigură și una nesigură. În 45% din cazuri, modelele au ales-o pe cea nesigură. Modelele mai mari nu s-au descurcat semnificativ mai bine⁶.

Vibe coding pentru aplicații web complete e, deocamdată, o idee proastă pentru orice contează cu adevărat.

Concluzia de mai sus îi aparține chiar lui Karpathy, după ce a construit MenuGen, o aplicație reală, scrisă 100% de AI. Varianta locală a fost „o aventură palpitantă”, dar transformarea ei într-o aplicație publică, cu autentificare, plăți și găzduire, „un chin”. A simțit că e gata în proporție de 80%, dar era mai aproape de 20%⁷.

Fundația nu se repară cu încă un etaj#

Turnul din Pisa a fost început în 1173, pe o fundație de doar trei metri, într-un sol moale. A început să se încline după al doilea etaj. Constructorii au continuat totuși, timp de aproape 200 de ani, și au încercat să compenseze înclinarea construind etajele de sus ușor strâmbe.

Turnul stă și azi în picioare. Dar, în 1990, înclinarea ajunsese la 5,5 grade și a trebuit închis. Au urmat 11 ani de lucrări, 870 de tone de contragreutăți din plumb și excavarea atentă a solului de sub o latură, ca să-l readucă la aproape 4 grade. Și tot strâmb e⁸.

O aplicație construită fără arhitectură seamănă cu turnul: funcționează, dar fiecare etaj nou adaugă greutate pe o fundație care n-a fost gândită pentru el. Fiecare reparație atinge alte trei locuri, pentru că nu există o structură clară care să spună unde se termină o parte și unde începe alta. De aceea, de cele mai multe ori, e mai ieftin să rescrii aplicația de la zero, pe o fundație corectă, decât să o „repari”.

Unde vibe coding e excelent: software pentru tine#

Asta nu înseamnă că vibe coding e inutil. Dimpotrivă: e extraordinar pentru software pe care îl folosești doar tu.

Scriitorul Robin Sloan a construit în 2020 o aplicație de mesagerie doar pentru familia lui și a numit-o „o mâncare gătită acasă”⁹: nu trebuie să servească un restaurant plin, trebuie doar să le placă celor de la masă. Un instrument personal e la fel:

• îl folosește o singură persoană, care știe exact ce vrea de la el;
• tu ești și utilizatorul, și testerul: dacă ceva e greșit, observi imediat;
• datele sunt ale tale și, de obicei, nu ies de pe calculatorul tău;
• dacă se strică, îl refaci în zece minute; nu pierde nimeni bani.

Un script care îți redenumește facturile, un tabel care îți calculează costurile unui proiect, un mic panou care adună date din trei locuri, un prototip pe care îl arăți colegilor: aici vibe coding economisește zile întregi. Diferența apare când același program trebuie să servească oameni pe care nu-i cunoști, cu date care nu sunt ale tale.

Cum folosești un prototip făcut cu AI#

Un prototip făcut prin vibe coding poate fi cel mai bun caiet de sarcini pe care îl aduci unei echipe de dezvoltare. Arată ce vrei mai clar decât orice document. Doar să nu-l confunzi cu produsul.

1. Fă prototipul. Încearcă ideea, arat-o oamenilor, vezi ce le place și ce nu.
2. Păstrează-l ca specificație. Ecranele, fluxurile și regulile din el spun exact ce trebuie construit.
3. Proiectează arhitectura. Datele, drepturile de acces, securitatea, copiile de siguranță, integrările și creșterea se decid înainte de cod, nu după.
4. Construiește produsul. Cu AI ca unealtă, dar cu oameni care înțeleg ce construiesc, revizuiesc fiecare bucată și răspund pentru rezultat.

Asistenții AI sunt unelte excelente în mâna cuiva care știe ce construiește. Problema apare doar când lipsește acel cineva.

Ai un prototip care merge și vrei să-l transformi într-o aplicație reală?

Vezi cum facem aplicațiile web

Imaginea de copertă: Tangopaso, Wikimedia Commons (domeniu public)