Ce este Vibe Coding, de fapt?

Termenul "vibe coding" s-a răspândit repede în 2024-2025 pentru că numește ceva ce mulți developeri deja făceau în liniște: descriind ce vor în engleză simplă unui model ca GPT-4, Claude, sau unui instrument ca Cursor sau GitHub Copilot, și lăsând-o să genereze cea mai mare parte a codului real. Programatorul rămâne în buclă, dar bucla arată diferit față de programarea tradițională.

Definiția reală

Andrej Karpathy a inventat expresia, descriind un flux de lucru în care "te dai pe mâna vibe-urilor" — iei prompt, accepți sugestii, rulezi codul, vezi ce se rupe, și iei prompt din nou. Nu citești fiecare diff linie cu linie. Stai pe cale după rezultat: face aplicația ce trebuie, trec testele, se renderează pagina corect. Abilitatea se mută de la a scrie sintaxă la a descrie intenția clar și a recunoaște când output-ul e greșit.

Aceasta e diferit de a folosi pur și simplu autocomplete. Sugestiile inline în stil Copilot încă presupun că tu scrii funcția cu puțin ajutor completând liniile. Vibe coding presupune că modelul scrie funcția, fișierul, uneori întreaga caracteristică, iar tu revizuiești și redirectezi în loc să fii autorul de la zero.

Cum arată o sesiune reală

O buclă tipică de vibe-coding cu un instrument ca Cursor sau Agent mode al Replit-ului merge cam așa:

1. Prompt: "Adaugă un rate limiter la acest Express API, 100 cereri la 15 minute pe IP, întoarce 429 cu un corp de eroare JSON."
2. Modelul editează middleware/rateLimit.js, o conectează în app.js, poate aduce express-rate-limit.
3. Rulezi npm test sau apelez endpoint-ul cu curl într-o buclă pentru a verifica că 429 se activează de fapt.
4. Ceva nu e bine — limitatorul se resetează la fiecare deploy pentru că e în memorie. Spui asta.
5. Modelul schimbă cu un store susținut de Redis, adaugă dependența ioredis, actualizează fișierul docker-compose.
6. Reiei testele, funcționează, faci commit.

Nici o linie din acel middleware nu a fost scrisă manual. Dar șase sau șapte decizii au fost luate de om: ce limită ar trebui să fie, că stocarea în memorie era greșită pentru producție, că fișierul docker-compose trebuia actualizat și el.

Unde funcționează bine

Vibe coding e puternic pentru munca grea în boilerplate: endpoint-uri CRUD, validare de forme, test scaffolding, fișiere de configurare, cod de lipă între două API-uri pe care le înțelegi deja. E și bun pentru prototipare — ridicând o demo funcțională a unei idei în o oră în loc de o zi, apoi decidând dacă merită să o construiești cum trebuie.

E cu adevărat rapid pentru devii solitari și echipe mici care livrează instrumente interne sau MVP-uri unde cost-ul unui bug e mic și viteza de iterație contează mai mult decât puritatea arhitecturală.

Unde nu mai funcționează

Modul de defecțiune despre care oamenii nu vorbesc destul: modelele produc cod care rulează dar e subtil greșit în moduri care nu se arată până mai târziu. O interogare SQL generată poate funcționa pe calea fericită dar fi vulnerabilă la injecție pentru că concatenarea de string-uri părea în regulă modelului. O verificare de autentificare generată poate trece testele dar sări o verificare de rol pe o rută. Dacă nu citești codul, nu vei prinde asta — vei vedea doar testele care trec și vei livra.

Aceasta contează mai mult în codul sensibil la securitate decât aproape oriunde altundeva. Simon Willison și alții au subliniat că proiectele vibe-coded cu date reale de utilizatori au nevoie de aceeași rigoare de revizuire ca orice alt cod, argumentabil mai mult, pentru că persoana care "l-a scris" poate să nu fie în stare să explice ce face linie cu linie.

Sistemele complexe cu mult stat implicit — concurență, tranzacții distribuite, orice cu bug-uri subtile de timing — sunt și ele o potrivire proastă. Modelele tind să genereze cod care arată plauzibil pentru aceste cazuri care se defectează în moduri care sunt greu de debugat exact pentru că nimeni, om sau model, nu a modelat pe deplin cazurile de margine de la bun început.

Abilitatea care contează cu adevărat acum

Dacă faci vibe coding, abilitatea valoroasă nu e viteza de tastare, e specificație. Prompt-urile vagi primesc cod vag și plin de bug-uri. Prompt-uri specifice — cu nume exacte de biblioteci, așteptări de tratare a erorilor, și cazuri de margine marcate — primesc mult mai bun output. Cea de-a doua abilitate cea mai valoroasă e a citi codul destul de repede pentru a prinde ce e greșit, ceea ce înseamnă că tot trebuie să înțelegi limba și domeniul chiar dacă nu scrii fiecare caracter.

Tratează codul generat de AI cum ai trata o pull request de la un junior dev care e rapid dar uneori prea sigur pe sine: util, adesea corect, dar merită o revizuire reală înainte să atingă producția.

Vrei să aprofundezi la scrierea de cod cu instrumente de AI fără a pierde controlul calității? Verifi segmentele AI și Python ale Korra Studio pentru demonstrații practice.