Codul generat de AI este evaluat ca fiind de calitate superioară la momentul code review-ului (94% dintre liderii tech îl consideră mai bun decât codul scris de oameni), dar produce mai multe incidente, mai mult rework și mai multe eșecuri de securitate odată ajuns în producție. Cauza nu este o contradicție în date, ci o diferență de unghi de măsurare: code review-ul evaluează cum citește codul, în timp ce producția evaluează cum se comportă sub trafic real. AI-ul vede sursa. Nu vede trace-ul.
Paradoxul care îngrijorează echipele de engineering în 2026
Dacă ai citit anul ăsta vreun raport despre adopția AI în dezvoltarea de software, probabil ai văzut deja statisticile-headline: Microsoft spune că AI scrie 30% din codebase-ul lor, Google a anunțat 75%, GitHub Copilot raportează o medie de 46% pe baza lui de utilizatori. Cifrele sunt impresionante, dar singure nu spun toată povestea.
Un studiu realizat de New Relic împreună cu Hanover Research, pe un eșantion de 200 de tehnology decision-makers din SUA (manageri și peste, cu autoritate reală de achiziție software), scoate la iveală ceva mult mai interesant decât procentul de cod generat de AI: o contradicție sistematică între cum este perceput codul AI la code review și cum se comportă în producție.
Concret:
- 94% dintre respondenți consideră codul generat de AI de calitate mai mare decât codul scris de oameni, evaluat la momentul code review-ului.
- 78% raportează o creștere a numărului de incidente de producție în ultimele 12 luni.
- 86% spun că timpul pe care inginerii seniori îl petrec reparând cod a crescut.
- 82% au avut cel puțin un eșec de producție legat direct de cod generat de AI în ultimele șase luni.
- 74% afirmă că cel puțin 25% din codul generat de AI necesită rework semnificativ.
Aceste cinci cifre descriu același eșantion de organizații, în aceeași fereastră de timp. Nu sunt grupuri diferite cu păreri diferite — sunt aceleași echipe, care spun simultan „codul e mai bun” și „codul ne creează mai multe probleme.”
De ce nu e o contradicție logică, ci o problemă de unghi de măsurare
Cheia pentru a înțelege acest paradox e simplă: code review-ul și producția măsoară lucruri diferite.
Code review-ul evaluează lizibilitatea și structura. Un reviewer uman se uită la stil consistent, pattern-uri curate, denumiri clare, absența bug-urilor evidente la prima citire. La acest capitol, modelele de AI sunt, obiectiv, foarte bune — au fost antrenate pe milioane de exemple de cod „canonic” și reproduc convenții cu o consistență pe care rareori o ating oamenii, mai ales sub presiune de deadline.
Producția evaluează comportamentul sub condiții reale. Trafic concurent, dependențe externe care răspund lent sau inconsistent, edge case-uri pe care nimeni nu le-a anticipat, date din lumea reală care nu respectă presupunerile din prompt. Niciunul dintre aceste lucruri nu e vizibil într-un fișier sursă — sunt vizibile doar în telemetrie: logs, traces, metrici, erori la runtime.
Un model de AI generează cod uitându-se la sursă: cod existent, documentație, exemple, instrucțiuni din prompt. Nu are acces la trace — adică la dovezile despre ce face efectiv sistemul când rulează cu date reale. Asta înseamnă că AI-ul poate produce cod care „pare corect” pentru orice cititor uman, dar care eșuează silențios în momentul în care întâlnește o condiție pe care nu a „văzut-o” niciodată, pentru că nu există nicăieri în sursă — există doar în comportamentul live al sistemului.
Cele patru moduri în care apare gap-ul în producție
Studiul identifică patru tipuri de eșecuri de producție legate de cod generat de AI, fiecare afectând aproximativ trei din zece organizații în ultimele șase luni:
- Eșecuri de integrare (30%) — drift de schemă, violări de contract între servicii, rate de eroare crescute la apeluri inter-servicii.
- Probleme de compliance/guvernanță (30%) — politici violate, vizibile în audit logs.
- Probleme de integritate a datelor (29%) — duplicare, drift, rate neobișnuite de valori null în telemetria de producție.
- Vulnerabilități de securitate nou introduse (28%) — vizibile în date de trace, pattern-uri de autentificare anormale.
Observă ceva important: niciuna dintre aceste patru categorii nu e „un bug clasic” pe care un linter sau un test unitar l-ar prinde ușor. Toate patru au nevoie de date de runtime pentru a fi detectate — exact tipul de date pe care un model de generare de cod nu le are la dispoziție în momentul în care scrie codul.
Încrederea oarbă amplifică problema
Un alt număr din studiu explică parțial de ce gap-ul ăsta nu e prins din timp: 62% dintre liderii tech spun că echipele lor livrează „des” sau „mereu” cod generat de AI în producție fără verificare manuală line-by-line.
Combinația dintre (a) cod care pare excelent la review și (b) lipsa verificării sistematice creează condiția perfectă pentru ca problemele de runtime să rămână invizibile până când traficul real le scoate la iveală. Practic, calitatea percepută artificial de ridicată la momentul scrierii codului devine motivul pentru care verificarea suplimentară pare inutilă — un cerc care se auto-întărește, până în momentul în care apare incidentul.
Cum se rezolvă, practic, gap-ul dintre review și producție
Răspunsul corect nu este să încetinești adopția AI — beneficiile de viteză sunt reale: 63% dintre organizații raportează o creștere modestă a veniturilor pe baza vitezei de livrare crescute. Răspunsul este să închizi bucla dintre runtime și procesul de generare a codului.
Câteva direcții concrete care reies din date:
- Tratează telemetria de producție ca input pentru development, nu doar ca instrument de debugging post-factum. Organizațiile care alimentează prompt-urile și code review-urile cu date reale despre comportamentul sistemului raportează cele mai mici rate de rework.
- Prompt-uiește explicit pentru telemetrie. 78% dintre echipele din studiu cer deja AI-ului, „des” sau „mereu”, să includă logs, traces și metrici custom direct în codul generat — telemetria devine parte din definiția de „done”, nu un add-on ulterior.
- Mapează fiecare din cele patru tipuri de eșec la un semnal de detecție specific în platforma de observability — drift de schemă pentru integrare, audit logs pentru compliance, anomalii de telemetrie pentru integritatea datelor, pattern-uri de autentificare pentru securitate.
- Nu trata codul „vibe-coded” ca o categorie separată de guvernanță. Dacă rulează în producție, ar trebui supus aceluiași code review, change management și SLO monitoring ca orice alt cod.
Întrebări frecvente
De ce e considerat codul AI mai bun la code review dacă produce mai multe incidente? Pentru că review-ul evaluează lizibilitate și stil, nu comportament la runtime. Codul poate fi sintactic și structural impecabil și totuși să eșueze sub trafic real, dependențe externe sau edge case-uri pe care AI-ul nu le-a „văzut” în datele de antrenament sau în prompt.
Care sunt cele mai frecvente probleme de producție cauzate de codul generat de AI? Patru categorii apar cu frecvență aproape egală: eșecuri de integrare între servicii, probleme de compliance/guvernanță, probleme de integritate a datelor și vulnerabilități de securitate nou introduse — fiecare afectând aproximativ 3 din 10 organizații în ultimele șase luni.
Ar trebui organizațiile să reducă adopția AI coding din cauza acestor riscuri? Nu, conform datelor — beneficiile de viteză și venituri sunt reale și măsurabile. Recomandarea este să se investească în observability și în verificare sistematică, nu să se încetinească adopția.
Cum poate o echipă să reducă gap-ul dintre calitatea percepută și comportamentul real al codului AI? Prin alimentarea buclei de dezvoltare cu date de runtime (telemetrie, trace-uri, pattern-uri reale de dependențe), prompt-uirea explicită pentru includerea telemetriei în codul generat și aplicarea aceluiași nivel de guvernanță (code review, change management, audit) indiferent de autorul codului — om sau AI.
Sursă date: New Relic × Hanover Research, „The 2026 State of AI Coding Report”, studiu pe 200 de tehnology decision-makers din SUA, 2026.
