Vibe coding înseamnă să descrii în limbaj natural ce vrei și să accepți ce produce modelul, fără să citești atent rezultatul. Pentru un prototip, un script, o unealtă făcută într-o seară, este un mod de lucru chiar bun. Îl folosesc și eu așa.
Problemele încep când lucrul pe care l-ai făcut în vibe coding ajunge în producție și începe să țină datele altor oameni. Nu pentru că e cod prost — de multe ori e ordonat, idiomatic, bine numit. Problema este ce nu a scris nimeni.
Un model răspunde la întrebarea pe care i-ai pus-o
Ceri un formular de programare și primești un formular de programare. Va valida emailul. Probabil va arăta mai bine decât ce aș fi scris eu de mână.
Ce nu va face este să îți pună întrebările care decid dacă lucrul acela supraviețuiește contactului cu utilizatori reali. Ce se întâmplă când două persoane rezervă ultimul interval în aceeași secundă? Ce se întâmplă când procesatorul de plăți expiră după ce a luat banii, dar înainte ca aplicația ta să afle? Cine are voie să vadă această rezervare — clientul, orice utilizator autentificat, oricine are linkul? Când clientul cere ștergerea datelor, ce altceva trebuie șters odată cu ele și ce trebuie păstrat prin lege?
Acestea nu sunt întrebări de programare. Sunt decizii despre afacerea ta, iar modelul nu le poate lua pentru că nu i s-au spus niciodată faptele de care ar avea nevoie. Produce ceva plauzibil pentru fiecare, tăcut, și merge mai departe. Codul compilează. Formularul funcționează când îl testezi. Decizia tot nu a luat-o nimeni.
Demonstrația funcționează întotdeauna
Aceasta este capcana propriu-zisă și îi prinde și pe oamenii cu experiență.
O funcționalitate făcută în vibe coding este testată așa cum a fost construită: un om, un browser, un singur traseu fericit, fără încărcare, fără adversar. În condițiile astea trece aproape orice. Defecțiunile trăiesc exact în condițiile pe care nu te-ai gândit să le creezi — concurență, eșec parțial, input ostil, al doilea client, al zece miilea rând, utilizatorul care nu mai este autentificat dar al cărui token încă funcționează.
Așa că bucla de feedback te minte. Publici, merge, publici din nou mai repede. Încrederea crește exact în timp ce crește suprafața neexaminată. Nimic nu îți spune altceva până când ceva o face, public.
Șase lucruri care lipsesc constant
Autorizarea, spre deosebire de autentificare. Modelele se descurcă bine la login. Sunt mult mai slabe la „acest utilizator are voie să citească exact acest rând”. Cea mai frecventă vulnerabilitate din vibe coding, detașat, este un endpoint care verifică dacă ești autentificat și nu verifică niciodată cine ești.
Orice trebuie să fie corect sub concurență. Stocuri, rezervări de locuri, numere de factură, solduri. Cod care este evident corect citit de sus în jos este frecvent greșit când rulează două copii simultan.
Modul de eșec al fiecărui apel extern. Orice terț de care depinzi va fi indisponibil la un moment dat. Dacă asta trebuie să îți oprească clientul este o decizie de business. Codul generat o ia din greșeală, de obicei prin a crăpa.
Date pe care nu îți permiți să le pierzi. Migrări care șterg coloane, ștergeri fără soft-delete, niciun backup din care să fi restaurat vreodată. Nimeni nu observă până în ziua în care contează, iar în ziua aceea este irecuperabil, nu incomod.
Back office-ul. Vibe codingul produce ecranele pe care le-ai descris. Tu ai descris ecranele pentru clienți, pentru că pe acelea ți le imaginezi. Apoi echipa ta trăiește opt ore pe zi în ce a rămas.
Coerența între funcționalități. Fiecare sesiune începe de la zero. Zece funcționalități construite în zece sesiuni îți dau zece convenții, trei feluri de a trata datele calendaristice, două tipare de autentificare și niciun vocabular comun. Individual, în regulă. Ca sistem, imposibil de întreținut — inclusiv de următorul model pe care îl pui pe el.
Cât costă asta de fapt
Argumentul pentru vibe coding este viteza, iar viteza este reală. Ce amână este costul înțelegerii, iar costul acela nu dispare — se plătește mai târziu, de către oricine trebuie să schimbe sistemul.
Ca să schimbi software în siguranță ai nevoie de cineva care poate prezice ce va strica o modificare. Persoana aceea își construiește modelul sistemului luând deciziile. Dacă nimeni nu a luat deciziile, nimeni nu are modelul, iar fiecare modificare ulterioară este o ghiceală cu un deploy atașat.
Sunt chemat regulat în astfel de proiecte. Salvarea nu înseamnă aproape niciodată rescriere — codul este de obicei recuperabil. Ce durează este reconstruirea intenției: să citesc fiecare traseu ca să deduc ce trebuia să facă sistemul, pentru că nu îmi poate spune nimeni, inclusiv cel care l-a publicat.
Ce cred de fapt
AI-ul este cel mai mare câștig de productivitate pe care l-a văzut meseria mea și nu aș lucra fără el. Este un instrument excelent în mâinile cuiva care îi poate citi critic rezultatul și știe ce întrebări nu a pus.
Nu înlocuiește persoana aceea. O face mai rapidă. Judecata despre ce nu are voie să greșească niciodată sistemul tău nu este o sarcină de programare și este exact partea pentru care plătești.
Folosește-l pentru prototipuri, scripturi interne, lucruri de aruncat, prima variantă a oricărui lucru. Pentru sistemul pe care merge afacerea ta, ai nevoie de cineva care îl înțelege cap-coadă — fie că l-a scris, fie că l-a verificat linie cu linie.