Vibe coding-ul nu mai este o practică informală sau un hack de productivitate personală — este politică oficială în 87,5% dintre organizații și permis cel puțin informal în 95% dintre ele, conform unui studiu New Relic × Hanover Research realizat pe 200 de technology decision-makers din SUA. Zero organizații din eșantion îl interzic complet. Practic, codul scris prin prompting ajunge direct în servicii de producție, sub aceleași SLA-uri și același clock de outage ca codul scris de ingineri seniori — dar, arată același studiu, fără ca toate controalele de guvernanță să fie ridicate la același nivel.
De la hack de weekend la politică de companie
Termenul „vibe coding” a apărut inițial ca descriere informală pentru un mod de lucru: programatorul descrie intenția în limbaj natural, AI-ul generează codul, iar omul ajustează din mers, ghidat mai mult de instinct și iterație rapidă decât de specificații detaliate. Pentru mulți, suna ca o practică de prototipare — bună pentru un MVP de weekend, riscantă pentru orice merge în producție.
Datele din 2026 spun altceva. Conform studiului New Relic, doar 5% dintre organizații restricționează vibe coding-ul la medii non-producție, iar zero organizații îl interzic complet. Restul de 95% îl permit pentru servicii de producție — fie oficial (87,5%), fie informal, fără politică scrisă dar tolerat de facto (7,5%).
Cu alte cuvinte: în organizația medie din acest eșantion, codul generat prin prompting nu mai e izolat într-un sandbox. Ajunge în aceleași servicii revenue-bearing, aceleași endpoint-uri customer-facing și sub aceleași SLA-uri ca orice cod scris de un inginer senior cu 10 ani de experiență.
Acest lucru se corelează direct cu un alt număr din același studiu: 67% dintre liderii tech plasează volumul săptămânal de cod generat sau refactorizat semnificativ de AI în banda 51-75%. Pentru organizația mediană, mai mult de jumătate din codul scris într-o săptămână obișnuită nu mai are un autor uman direct.
De ce contează diferența dintre „permis informal” și „politică oficială”
La prima vedere, diferența dintre 87,5% (politică oficială) și 7,5% (toleranță informală) poate părea o nuanță administrativă. Nu este.
Politica oficială înseamnă, de regulă, că organizația a definit explicit: ce tip de cod poate fi generat prin vibe coding, ce nivel de revizuire e obligatoriu înainte de deploy, cine își asumă responsabilitatea pentru codul respectiv și cum se documentează decizia. Există, teoretic, un cadru.
Toleranța informală înseamnă că practica există, e cunoscută, dar nu există un cadru scris. Echipele decid ad-hoc cât de mult vor verifica, fiecare developer aplică propriul standard de „suficient de bun pentru producție”, iar responsabilitatea în caz de incident e ambiguă.
Diferența devine critică în momentul unui incident de producție. Cu o politică oficială, există cel puțin un proces de urmărit — chiar dacă procesul nu e perfect. Fără ea, echipa de incident response descoperă regulile din mers, exact în momentul în care presiunea e maximă.
Guvernanța nu a ținut pasul cu adopția
Aici apare tensiunea reală din date. Studiul New Relic notează explicit:
„Once vibe coding sits inside the production policy, every governance system around it has to apply equally regardless of authorship: code review, change management, deployment guardrails, incident response, and audit logging. The data later in this report shows that most organizations have authorized the practice without consistently leveling up the surrounding controls.”
Tradus în termeni practici: organizațiile au spus „da” la vibe coding în producție mult mai rapid decât au actualizat procesele care ar trebui să-l încadreze. Aceeași sursă de date arată consecințele acestei decalări:
- 86% dintre organizații au văzut o creștere a timpului petrecut de inginerii seniori reparând cod, în ultimele 12 luni.
- 78% raportează mai multe incidente de producție.
- 77% raportează o creștere a datoriei tehnice.
- 88% raportează o creștere a volumului de microservicii/funcții din mediul de producție — un semn clasic de sprawl arhitectural, frecvent asociat cu generare rapidă de cod fără o disciplină centralizată de design.
Aceste patru metrici nu sunt întâmplătoare — sunt exact tipul de simptome pe care le-ai aștepta când volumul de cod crește rapid, dar straturile de guvernanță (code review riguros, change management, deployment guardrails) rămân la nivelul vechi, gândit pentru un ritm de livrare mai lent și pentru un autor uman.
Ce ar trebui să facă o organizație care permite deja vibe coding în producție
Dacă organizația ta se află deja în cei 95% care permit vibe coding-ul în producție — și statistic, probabil te afli — întrebarea relevantă nu mai este „ar trebui să-l interzicem?”. Răspunsul din date e clar: nimeni nu face asta, și beneficiile de viteză sunt prea mari pentru a fi ignorate (63% dintre organizații raportează deja o creștere modestă a veniturilor, atribuită direct vitezei crescute de livrare a feature-urilor).
Întrebarea corectă este: ce control trebuie ridicat la același nivel, indiferent de autorul codului?
Câteva direcții concrete, derivate din pattern-ul de date al studiului:
- Tratează codul vibe-coded ca cod de producție din prima zi, nu ca o categorie separată cu reguli mai relaxate. Aceleași praguri de code review, aceleași gate-uri de deployment.
- Formalizează ce e azi tolerare informală. Dacă 7,5% din organizații permit practica fără politică scrisă, riscul lor de ambiguitate la incident e cel mai mare din eșantion. O politică scrisă, chiar minimală, reduce timpul de reacție în criză.
- Aliniază change management și audit logging la volumul real de cod generat. Cu 67% din organizații generând peste jumătate din codul săptămânal prin AI, procesele de audit gândite pentru un ritm „uman” de commit-uri nu mai reflectă realitatea operațională.
- Extinde monitorizarea SLO la serviciile vibe-coded explicit, nu doar la cele „importante” sau „legacy”. Studiul arată că eșecurile de integrare, compliance, integritate a datelor și securitate apar la rate similare (28-30%) — nu se concentrează predictibil într-o singură zonă a stack-ului.
- Publică ambele fețe ale ecuației la nivel executiv: viteza de livrare ȘI costul operațional (incidente, rework, tech debt). Studiul recomandă explicit ca acestea să intre în același plan de capacitate, nu în rapoarte separate.
Vibe coding nu mai e o întrebare de „dacă”, ci de „cum”
Practica a trecut deja testul de adopție — chiar dacă mulți lideri tech încă o discută ca pe o decizie viitoare. Datele din 2026 arată că decizia a fost deja luată, la scară largă: vibe coding-ul e în producție, e oficial în marea majoritate a cazurilor și generează deja majoritatea codului săptămânal în organizația mediană.
Întrebarea reală pentru orice engineering leader nu mai este dacă să permită practica. Este dacă guvernanța, observability-ul și procesele de incident response sunt la nivelul volumului de cod pe care această practică îl produce.
Întrebări frecvente
Ce înseamnă „vibe coding” în context de producție? Înseamnă generarea de cod prin prompting în limbaj natural, cu iterație rapidă ghidată de AI, aplicat direct serviciilor care rulează în producție — nu doar în prototipuri sau medii de testare.
Câte organizații interzic vibe coding-ul în producție? Zero, conform datelor din studiul New Relic × Hanover Research pe 200 de technology decision-makers. Doar 5% restricționează practica la medii non-producție.
Care e diferența dintre vibe coding „oficial permis” și „informal tolerat”? Politica oficială (87,5% dintre organizații) presupune reguli scrise — nivel de revizuire, responsabilitate, documentare. Toleranța informală (7,5%) înseamnă că practica există fără cadru scris, decizia fiind lăsată la latitudinea fiecărei echipe.
De ce a crescut datoria tehnică odată cu adopția vibe coding-ului? Pentru că volumul de cod a crescut mai rapid decât capacitatea organizațiilor de a-l revizui, integra coerent și menține. 77% dintre organizații raportează creșterea datoriei tehnice în ultimele 12 luni, în paralel cu creșterea adopției vibe coding.
Ce ar trebui să prioritizeze o echipă care permite deja vibe coding în producție? Alinierea guvernanței (code review, change management, audit logging) și a observability-ului la volumul real de cod generat prin AI, nu reducerea adopției — beneficiile de viteză și venituri raportate sunt deja semnificative.
Sursă date: New Relic × Hanover Research, „The 2026 State of AI Coding Report”, studiu pe 200 de tehnology decision-makers din SUA, 2026.
