De la Vibe Coding la Software de Producție: Unde Se Oprește Distracția

Săptămâna trecută, un antreprenor mi-a arătat o aplicație web pe care a construit-o în câteva zile folosind AI. Fără facultate de informatică, fără bootcamp, doar o idee clară și câteva prompturi bune. Funcționa. Avea sistem de login, un dashboard, date care se salvau. În mai puțin de 72 de ore.

Apoi m-a rugat să o ajut să o lanseze pentru utilizatori reali.

Aici lucrurile s-au complicat.

Prototipul Funcționează Când Ești Singurul Utilizator

Prototipul ei rula perfect pentru că era singura persoană care îl folosea. În momentul în care am încercat să adăugăm un al doilea utilizator, au apărut probleme de concurență. Baza de date nu avea migări de schema, deci orice rollback ar fi însemnat pierdere de date. Nu existau teste, ceea ce însemna că orice modificare simțeai că o faci pe marginea prăpastiei, cu ochii legați. Iar deployment-ul era un proces manual fără nicio documentație.

Proiectul ei de weekend era un proof of concept excelent. Nu era software de producție.

Aceasta este diferența pe care discuția despre "vibe coding" o ignorează constant. Uneltele sunt reale, viteza este reală, democratizarea creării de software e pasionantă. Dar există o diferență între a genera cod și a face inginerie software. Și această diferență contează mai mult decât realizează majoritatea oamenilor — până când stau la 3 noaptea în fața unui incident.

Metrică care Contează cu Adevărat

Întrebarea pe care mi-o pun când văd cod generat de AI: poate fi integrat în siguranță într-un codebase partajat?

Nu "funcționează?" Nu "a mers la demo?" Integrare în siguranță. Cuvântul "siguranță" vine cu mult bagaj. Înseamnă că codul poate fi revizuit de cineva care nu l-a scris. Înseamnă că testele verifică comportament, nu doar că programul nu se oprește din funcționare. Înseamnă că rollback-ul e posibil fără pierderi de date. Înseamnă că modificarea e suficient de restrânsă încât să poată fi înțeleasă și explicată.

Când un vibe coder măsoară succesul, de obicei măsoară timpul până la prima versiune funcțională. E un metric util pentru discovery și prototipare. Dar când software-ul intră într-un mediu partajat, acest metric nu mai spune nimic. Acum măsori timpul până la integrare sigură — și asta include costul de review, calitatea testelor, riscul de deployment, overhead-ul de coordonare și povara întreținerii viitoare.

Un inginer software se gândește la întregul ciclu de viață de la început. Un vibe coder descoperă aceste aspecte mai târziu, când costă mai mult să le rezolvi.

Generare vs. Proprietate

Există o tranziție subtilă dar critică când AI generează codul tău. Rezultatul nu e încă munca ta. E un punct de plecare care trebuie transformat în ceva ce deții cu adevărat.

A deține înseamnă mai multe lucruri. Poți explica fiecare decizie importantă din modificare. Înțelegi de ce există fiecare fișier și ce face. Ai restrâns schimbarea la exact ce era necesar, fără boilerplate în plus sau curățenie nespecifică. Ai scris sau verificat teste care verifică comportament, nu doar metrici de acoperire. Te-ai gândit la calea de rollback.

Aceasta este munca pe care AI nu o poate face pentru tine. AI generează. Tu decizi. Și "decizi" presupune că te-ai gândit la alternative, ai cântărit compromisurile și ai înțeles consecințele.

Când văd cod generat de AI care nu a fost preluat corespunzător, observ aceleași probleme. Modificări prea mari pentru că modelul a generat mai mult decât era necesar. Pakete adăugate fără justificare clară. Teste care par scrise să satisfacă o unealtă de coverage în loc să prindă bug-uri reale. Boilerplate care există pentru că modelul preferă schela în loc de simplitate.

Niciuna dintre acestea nu e vina AI-ului. Sunt rezultatul unui autor care a tratat output-ul generat ca progres, nu ca materie primă.

Problema de Review pe Care Nimeni Nu O Discuta

Ceva ce mă ține treaz noaptea: codul generat de AI schimbă ecuația review-ului.

Când un inginer uman scrie cod, există de obicei o pistă de decizii. Poți fi în dezacord cu alegerile lor, dar măcar există alegeri. Poți întreba de ce a folosit acea abstractizare, de ce validarea stă acolo, de ce au ales acea librărie. Răspunsurile ar putea fi "nu m-am gândit la asta" sau "părea rezonabil la momentul respectiv," dar măcar ai pe cine întreba.

Cu cod generat de AI, unele dintre acele "decizii" nu sunt deloc decizii. Sunt completări. Modelul a ales un pattern pentru că era statistic probabil, nu pentru că era potrivit pentru problema ta. Și dacă autorul nu a transformat acea completare în muncă proprie, review-ul devine o problemă mult mai dificilă.

Nu poți întreba modelul de ce a ales acea abordare. Nu poți întreba autorul de ce a făcut acea decizie dacă el nu știe efectiv. Deci review-ul fie scoate la iveală probleme prin trial and error dureros, fie nu se întâmplă deloc.

De asta cred că cea mai importantă abilitate în era dezvoltării asistate de AI nu e prompting-ul. E capacitatea de a lua output-ul generat și de a-l transforma în cod pe care îl înțelegi suficient de profund încât să îl deții, să îl explici și să îl întreții.

Ce Înseamnă Asta pentru Echipa Ta

Dacă construiești un prototip să testezi o idee, vibe coding e o abordare legitimă. Viteza de învățare contează când încă validezi presupunerile. Folosește uneltele, mișcă-te repede, construiește ceva să arăți oamenilor.

Dar dacă acel prototip urmează să devină un produs real, la un moment dat codul generat trebuie să treacă prin filtrul cuiva care gândește ca un inginer. Nu pentru a face gatekeeping. Nu pentru a încetini lucrurile. Ci pentru a te asigura că ceea ce lansezi este cod care poate fi înțeles, întreținut și pe care se poate conta de către o echipă.

La NameOcean, vedem acest tipar constant. Startup-uri care se mișcă rapid cu AI pentru a valida idei, apoi lovesc un zid când trebuie să scaleze. Cele bune aduc ajutor de inginerie la timp. Cele rele continuă să adauge funcționalități pe un codebase pe care nimeni nu îl înțelege cu adevărat.

Obiectivul nu e să eviți dezvoltarea asistată de AI. Obiectivul e să fii sincer despre unde se termină o treabă și unde începe alta. AI poate genera cod. Tu trebuie să faci inginerie software.

Concluzia

Vibe coding e un punct de plecare fantastic. E o modalitate de a testa idei rapid, de a învăța ce e posibil, de a trece de la concept la ceva tangibil fără luni de dezvoltare tradițională.

Dar ingineria software e despre ciclul de viață complet. E despre cod pe care echipa ta îl poate revizui, întreține și în care poate avea încredere când lucrurile merg prost la 2 noaptea. E despre modificări suficient de restrânse încât să poată fi înțelese și făcute rollback dacă e nevoie. E despre a-ți asuma responsabilitatea pentru decizii, chiar și când acele decizii au fost influențate de sugestii AI.

Cele mai bune produse pe care le știu folosesc intens uneltele AI. Doar că o fac cu ochii deschiși. Știu că codul generat e materie primă, nu produs finit. Și știu că la un moment dat, cineva trebuie să facă munca de inginerie care face diferența între un demo cool și software pe care chiar poți să îl lansezi.

Așa că da, vibe code încontinuu. Construiește rapid, experimentează liber, folosește fiecare unealtă disponibilă. Doar știi când e momentul să treci de la vibe la inginerie. Viitorul tău și viitoarea ta echipă îți vor mulțumi.