Unelte ca Lovable, Bolt sau Cursor au făcut posibil ceva ce acum câțiva ani părea imposibil: oricine poate descrie o aplicație în cuvinte și o poate vedea funcționând în câteva ore. Pe lângă lucrurile bune pe care le-a adus, asta a creat și un val nou de „programatori”: oameni care n-au scris niciodată o linie de cod, dar care oferă site-uri, magazine și aplicații la prețuri foarte mici, cu livrare în câteva zile.

Demo-ul arată impecabil. Are login, are tabele, are grafice. Diferența față de o aplicație făcută de o echipă cu experiență nu se vede în prezentare. Se vede mai târziu, când aplicația ajunge în fața utilizatorilor reali.

Prețul mic are o explicație

O aplicație nu înseamnă doar ecranele pe care le vezi. Înseamnă și lucrurile pe care nu le vezi:

  • cum sunt organizate datele și dacă vor face față peste un an;
  • cine are voie să vadă și să modifice fiecare informație;
  • ce se întâmplă când un utilizator greșește, rău intenționat sau nu;
  • ce se întâmplă când plata, emailul sau un alt serviciu extern nu răspunde;
  • copiile de siguranță, actualizările și mentenanța.

Cine nu știe să programeze nu poate evalua codul generat. Nu știe ce întrebări să pună, deci nici AI-ul nu primește acele întrebări. Rezultatul e o aplicație care merge pe drumul fericit și atât. Am scris pe larg despre asta în articolul despre vibe coding: AI-ul scrie cod bun, dar nu proiectează arhitectura.

Prețul mic nu e o reducere. E prețul unei aplicații din care lipsesc toate lucrurile de mai sus.

Ce se întâmplă când ajung în producție

Mii de vulnerabilități, la vedere. În octombrie 2025, Escape a analizat peste 5.600 de aplicații publice, construite cu platforme de vibe coding. A găsit peste 2.000 de vulnerabilități, peste 400 de chei secrete expuse și 175 de cazuri de date personale accesibile oricui, printre care fișe medicale și conturi bancare (IBAN). Toate erau în aplicații aflate deja în producție, iar cercetătorii spun că cifrele sunt o estimare minimă1.

O rețea socială cu ușa deschisă. La începutul lui 2026, Moltbook, o rețea socială pentru agenți AI devenită virală peste noapte, a fost analizată de cercetătorii de la Wiz. Fondatorul declarase public: „N-am scris nicio linie de cod pentru Moltbook.” Baza de date era deschisă oricui: aproximativ 1,5 milioane de chei de acces, 35.000 de adrese de email și mesaje private, unele cu chei de acces la alte servicii, scrise în clar. Oricine putea prelua orice cont. Cauza: o singură setare de securitate a bazei de date, lăsată neconfigurată2.

Meseria nouă: reparatorul de vibe coding. Fenomenul a creat o piață nouă. Pe Fiverr există sute de oferte de „vibe code fixer”, iar presa de specialitate a început să scrie despre programatorii plătiți să repare aplicațiile generate de alții3. De multe ori, reparația costă mai mult decât ar fi costat aplicația făcută corect de la început.

Podul Tacoma Narrows prăbușindu-se în 1940
Podul Tacoma Narrows, 7 noiembrie 1940, la patru luni după inaugurare. Cadru din filmul lui Barney Elliot, domeniu public

Varianta mai ieftină

Primul pod Tacoma Narrows (SUA) a fost construit după un proiect ales, printre altele, pentru că era mai ieftin: grinzi de 2,4 metri în loc de 7,6. Arăta elegant și trecea calculele vremii. S-a prăbușit la patru luni după inaugurare, pe 7 noiembrie 1940, într-un vânt de numai 64 km/h. Nimeni nu testase cum se comportă podul în condițiile reale de acolo4.

Răspunderea e a ta

Dacă aplicația ta colectează date personale, operatorul datelor ești tu, nu cel care a făcut aplicația. O scurgere de date înseamnă notificări, clienți pierduți și, potrivit GDPR, amenzi care pot ajunge la 20 de milioane de euro sau 4% din cifra de afaceri anuală5.

Cum lucrează cu AI-ul un programator cu experiență

Și noi folosim AI. Diferența nu e unealta, ci cine o ține în mână.

Când lucrează un programator cu experiență, deciziile îi aparțin lui. El stabilește arhitectura: cum arată datele, cum se împarte aplicația în module, cine are acces la ce, ce se întâmplă la erori, cum se fac copiile de siguranță. El alege bibliotecile și tiparele. Abia apoi îi cere AI-ului să scrie codul, bucată cu bucată, exact cum l-ar fi scris el.

Fiecare bucată e citită și înțeleasă înainte să intre în proiect. Dacă AI-ul ia o scurtătură, o vede. Dacă propune o soluție diferită de restul proiectului, o refuză. Rezultatul final e identic cu codul pe care l-ar fi scris de mână, doar că e gata mai repede.

Simon Willison, unul dintre cei mai respectați programatori care scriu despre AI, o spune simplu: „Uneltele AI amplifică experiența existentă.”6 Cu cât știi mai mult, cu atât obții rezultate mai bune. Dacă nu știi nimic, AI-ul amplifică exact asta.

Ce comparăm Vibe coding Programator cu experiență + AI
Cine decide arhitectura nimeni, apare din mers programatorul, înainte de cod
Cine citește codul nimeni programatorul, fiecare bucată
Ce se întâmplă la o eroare se cere AI-ului „repar-o” se înțelege cauza, apoi se repară
Securitatea ce iese din prima proiectată și verificată
Testele generate, dacă există gândite pentru ce poate eșua
Cine răspunde de rezultat neclar cel care a semnat contractul
  1. Înțelegem problema. Discutăm cu tine, aflăm cum lucrezi, ce date ai, ce trebuie să se întâmple și ce nu are voie să se întâmple niciodată.
  2. Proiectăm arhitectura. Datele, drepturile de acces, integrările, securitatea și găzduirea se decid înainte de prima linie de cod.
  3. Scriem codul, cu AI ca unealtă. AI-ul scrie mai repede ce am decis noi. Fiecare bucată e citită, înțeleasă și ajustată.
  4. Testăm ce poate eșua. Nu doar drumul fericit, ci și cazurile în care aplicațiile se strică de obicei.
  5. Răspundem pentru rezultat. De aceea oferim garanție de cel puțin un an, iar pentru proiectele complexe, de doi ani sau mai mult.

Testele: AI-ul nu știe ce să testeze

Un argument des întâlnit: „Las AI-ul să scrie și testele.” Sună bine, dar un test e util doar dacă verifică ce trebuie să facă aplicația, nu ce face ea acum.

Când AI-ul scrie testele uitându-se la cod, verifică de cele mai multe ori comportamentul existent, cu tot cu greșelile lui. Mai multe studii au ajuns exact la această concluzie: testele generate de modele confirmă ce face programul, nu ce ar trebui să facă, iar uneori ajung să valideze chiar erorile7.

Un exemplu simplu

Codul aplică o reducere de 10% în loc de 15%. AI-ul scrie un test uitându-se la cod și verifică faptul că reducerea e de 10%. Testul trece. Acum eroarea nu doar că există, ci e și „confirmată” de un test.

Mai e o problemă: rugat să „facă testele să treacă”, un agent AI poate alege calea cea mai scurtă. Kent Beck, unul dintre părinții dezvoltării ghidate de teste, enumeră printre semnalele de alarmă când lucrează cu AI-ul „orice semn că trișează, de exemplu dezactivând sau ștergând teste”8.

Pagina din jurnalul calculatorului Harvard Mark II, cu molia lipită
„Primul caz real de bug găsit”: o molie blocată într-un releu al calculatorului Harvard Mark II, 1947. Foto: Naval Surface Warfare Center, domeniu public

Testele bune vin din experiență: din a ști cum se strică aplicațiile. Un programator care a văzut sute de erori în producție se întreabă automat:

  • ce se întâmplă dacă doi clienți comandă ultimul produs în aceeași secundă?
  • dacă procesatorul de plăți confirmă aceeași plată de două ori?
  • dacă cineva schimbă un număr în adresă și ajunge la comanda altcuiva?
  • dacă un câmp e gol, are 10.000 de caractere sau conține diacritice și emoji?
  • dacă serverul de email nu răspunde chiar când se trimite factura?
  • dacă ora trece la ora de vară în mijlocul unei programări?

AI-ul poate scrie foarte repede testele pentru toate aceste cazuri, dacă cineva știe să i le ceară. Fără acel cineva, aplicația are teste multe, verzi și inutile.

Cum alegi cu cine lucrezi

Înainte să alegi oferta cea mai mică, pune câteva întrebări:

  • Cine stabilește arhitectura și îmi poate explica deciziile?
  • Cum sunt protejate datele și cine are acces la ce?
  • Ce testați și cum?
  • Cum se fac copiile de siguranță și cât durează o restaurare?
  • Ce garanție oferiți și cine repară o problemă peste un an?
  • Ce aplicații ați făcut care rulează de ani de zile în producție?

Un răspuns vag la oricare dintre ele spune mai mult decât orice demo.

Vrei o aplicație făcută cu AI, dar construită de oameni care știu ce construiesc?

Vezi cum facem aplicațiile web

  1. Escape, How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms, octombrie 2025. ↩

  2. Wiz, Hacking Moltbook: The AI Social Network Any Human Can Control, februarie 2026. Problema a fost reparată în câteva ore, după semnalarea cercetătorilor. ↩

  3. 404 Media, The Software Engineers Paid to Fix Vibe Coded Messes, septembrie 2025. ↩

  4. Tacoma Narrows Bridge (1940), Wikipedia. ↩

  5. Regulamentul (UE) 2016/679 (GDPR), articolul 83. ↩

  6. Simon Willison, Vibe engineering, octombrie 2025. ↩

  7. Konstantinou, Degiovanni, Papadakis, Can we find bugs using LLM-generated oracles?; Mathews, Nagappan, Design choices made by LLM-based test generators prevent them from finding bugs. ↩

  8. Kent Beck, Augmented Coding: Beyond the Vibes, iunie 2025. ↩

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