← Toate articolele

Cât cod scrie AI-ul în 2026? Datele reale din companii

Publicat · de theCoders · 30 min de citit
Cât cod scrie AI-ul în 2026 — adopție aproape totală, volum explodat, dar metricile de calitate în scădere

În urmă cu doar trei ani, asistenții AI pentru programare păreau o tehnologie promițătoare. Astăzi fac parte din fluxul de lucru al aproape oricărei echipe de dezvoltare software.

Între timp, discuția s-a schimbat. Nu mai vorbim despre demonstrații spectaculoase sau predicții optimiste, ci despre date reale: studii randomizate, rapoarte publicate de companii, telemetrie din milioane de commit-uri și analize independente.

Concluzia este surprinzător de clară.

Adopția AI a ajuns aproape universală. Cantitatea de cod produs a crescut spectaculos. În schimb, multe dintre metricile care descriu calitatea software-ului, mentenanța și încrederea în cod merg în direcția opusă.

Acesta nu este un articol despre faptul că AI este „bun” sau „rău”.

Este un articol despre ce se întâmplă atunci când automatizezi partea cea mai ieftină a dezvoltării software — scrierea codului — fără să rezolvi partea cea mai dificilă: arhitectura, validarea, securitatea și deciziile tehnice.

Mai jos sunt datele. Cu surse.

Cât cod scrie AI-ul în 2026 — date reale din companii, studii randomizate și telemetrie din milioane de commit-uri

1. Cât cod scrie efectiv AI-ul în companiile mari?

Primele cifre publice vin chiar de la liderii celor mai mari companii de tehnologie. Sunt informații interesante, însă trebuie privite cu prudență: toate sunt auto-raportate, iar metodologiile folosite pentru măsurare nu sunt publice.

Microsoft este una dintre companiile care au vorbit cel mai deschis despre acest subiect. În aprilie 2025, la LlamaCon, Satya Nadella declara că între 20% și 30% din codul din repository-urile companiei este generat de software. El a precizat însă că rezultatele diferă semnificativ în funcție de limbaj: codul Python este deja la un nivel foarte ridicat, în timp ce pentru C++ performanța rămâne considerabil mai modestă.

La Google, Sundar Pichai anunța în 2024 că aproximativ 25% din codul nou este generat cu ajutorul AI, iar ulterior a actualizat cifra la mult peste 30%. Meta merge și mai departe: Mark Zuckerberg estimează că aproximativ jumătate din activitatea de dezvoltare ar putea fi realizată de AI într-un interval de un an. Kevin Scott, CTO Microsoft, face cea mai îndrăzneață predicție dintre toate și vorbește despre un viitor în care 95% din cod va fi scris de AI în următorii cinci ani.

Există însă o nuanță esențială care este adesea pierdută în titlurile din presă.

„Cod scris de AI” nu înseamnă „cod ajuns în producție fără intervenție umană”.

Sundar Pichai a subliniat în repetate rânduri că fiecare sugestie generată de AI trece prin review-ul unui dezvoltator. Procentele raportate descriu cine a generat textul inițial al codului, nu cine și-a asumat responsabilitatea tehnică pentru el.

Există și o măsurătoare independentă, considerabil mai conservatoare. Analiza SemiAnalysis, citată de METR, estimează că aproximativ 4% dintre commit-urile publice de pe GitHub sunt generate de Claude Code.

Diferența dintre afirmații precum „30% din cod este scris de AI” și observația că doar aproximativ 4% dintre commit-uri sunt produse automat nu înseamnă că una dintre cifre este greșită. Ea arată doar că fiecare măsoară un lucru diferit. Unii contabilizează caracterele generate, alții commit-urile, iar alții pornesc de la estimări interne. Tocmai de aceea, procentele trebuie interpretate în context, nu comparate direct.

Concluzia acestei secțiuni: AI generează deja o parte semnificativă din codul scris în marile companii, însă decizia finală, validarea și responsabilitatea rămân, cel puțin deocamdată, în mâinile dezvoltatorilor.

2. Adopția AI: aproape universală, încrederea este în scădere

Dacă procentele raportate de marile companii pot fi interpretate diferit, datele despre adopția AI sunt mult mai solide. Ele provin din studii ample, repetate anual, care urmăresc aceeași metodologie și oferă o imagine mult mai clară asupra modului în care dezvoltatorii folosesc aceste instrumente în practică.

Raportul DORA 2025, realizat de Google Cloud pe baza răspunsurilor a aproximativ 5.000 de profesioniști din tehnologie și a peste 100 de ore de interviuri, arată că AI a devenit parte din activitatea zilnică pentru majoritatea echipelor software.

Principalele concluzii sunt greu de ignorat:

  • 90% dintre dezvoltatori folosesc AI în activitatea profesională, cu 14% mai mult decât în 2024;
  • timpul median petrecut folosind astfel de unelte este de aproximativ două ore pe zi, adică aproape un sfert din programul de lucru;
  • peste 80% consideră că AI le-a crescut productivitatea;
  • în același timp, 30% declară că au puțină sau deloc încredere în codul generat.

Aceeași tendință apare și în Stack Overflow Developer Survey 2025, unul dintre cele mai ample studii dedicate comunității dezvoltatorilor, cu peste 49.000 de respondenți din 177 de țări.

Rezultatele confirmă că utilizarea AI continuă să crească, însă încrederea evoluează în direcția opusă:

  • 84% folosesc sau intenționează să folosească instrumente AI, față de 76% în anul precedent;
  • neîncrederea în acuratețea răspunsurilor a crescut de la 31% la 46% într-un singur an;
  • 66% spun că cea mai mare frustrare este codul „aproape corect, dar nu chiar”;
  • iar 45% afirmă că depanarea codului generat consumă o parte importantă din timpul lor.

La prima vedere, aceste rezultate par contradictorii.

Cum este posibil ca oamenii să folosească AI din ce în ce mai mult, dar să aibă din ce în ce mai puțină încredere în el?

De fapt, tocmai acesta este unul dintre cele mai interesante rezultate ale studiilor. Adopția și încrederea nu evoluează împreună. Cu cât dezvoltatorii folosesc mai frecvent aceste instrumente, cu atât înțeleg mai bine și limitele lor.

AI nu mai este perceput ca un coleg care oferă întotdeauna răspunsul corect. Este mai degrabă un instrument care accelerează munca, dar care necesită verificare constantă.

Situația seamănă cu autocorectul de pe telefon: îl folosim zilnic și ne ajută să scriem mai repede, însă aproape nimeni nu apasă „Send” fără să arunce o ultimă privire asupra textului.

Concluzia acestei secțiuni: adopția AI nu mai este întrebarea importantă — ea s-a produs deja. Întrebarea este cât de mult putem avea încredere în rezultatele generate și cât timp trebuie investit pentru a le valida înainte să ajungă în producție.

3. Explozia aplicațiilor: foarfeca dintre ofertă și cerere

Până acum am vorbit despre modul în care AI schimbă procesul de dezvoltare. Următorul efect este și mai vizibil: numărul aplicațiilor noi crește într-un ritm pe care industria nu l-a mai văzut de aproape un deceniu.

Datele Sensor Tower, citate de The Information și The New York Times, arată că piața software a intrat într-o nouă etapă. Costul dezvoltării a scăzut suficient de mult încât barierele de intrare aproape au dispărut.

Evoluția este sugestivă:

AnAplicații noi în App Store
2016~890.000 (record istoric)
2022~420.000
2024în continuă scădere (−46% față de 2016)
2025~600.000 (+30%)
S1 2026~560.000

Doar în primul trimestru din 2026 au fost publicate 235.800 de aplicații noi, cu 84% mai multe decât în aceeași perioadă a anului precedent. Dacă ritmul se menține, 2026 va deveni primul an din istorie în care App Store depășește pragul de un milion de aplicații noi, peste recordul stabilit în 2016.

Privind doar aceste cifre, ai putea concluziona că piața software trece printr-o perioadă fără precedent.

Realitatea este însă mai nuanțată.

În timp ce oferta explodează, cererea rămâne aproape constantă.

În 2025, numărul descărcărilor de aplicații a crescut cu doar 3%, iar în prima jumătate a lui 2026 cu încă 2%. Anul trecut s-au înregistrat aproximativ 35,4 miliarde de descărcări, iar în primul semestru din 2026 aproximativ 17,6 miliarde. Ritmul este stabil, nu exponențial.

Cu alte cuvinte, aplicațiile apar într-un ritm mult mai rapid decât crește interesul utilizatorilor pentru ele.

Aceasta este prima schimbare majoră produsă de AI în industrie.

Costul de a construi software scade dramatic. Costul de a fi descoperit nu se schimbă aproape deloc.

Un detaliu completează foarte bine această imagine. Începând cu 2024, Google Play a eliminat aproximativ 1,8 milioane de aplicații, reducând dimensiunea catalogului de la aproximativ 3,4 milioane la 1,8 milioane. În timp ce App Store primește un val uriaș de aplicații noi, Google curăță agresiv conținutul existent. Două strategii diferite, aceeași problemă de fond: volumul a devenit mult mai ușor de produs decât valoarea reală pentru utilizator.

Vom regăsi același tipar și în capitolele următoare.

Pe măsură ce AI reduce costul producerii codului, apar tot mai multe situații în care cantitatea crește, iar calitatea sau impactul nu țin același pas.

Aceasta este prima dintre cele trei „foarfece” care apar în datele analizate și, probabil, cea mai importantă pentru orice companie care dezvoltă produse software.

Concluzia acestei secțiuni: AI face dezvoltarea mai accesibilă ca niciodată, dar nu rezolvă problema cea mai dificilă: cum faci ca produsul tău să fie descoperit, folosit și ales într-o piață în care oferta crește mult mai repede decât cererea.

4. Ce s-a accelerat, măsurabil

Până aici, imaginea ar putea părea dezechilibrată. Am vorbit despre limitele AI, despre încrederea în scădere și despre explozia volumului de software. Ar fi însă incorect să ignorăm partea în care aceste instrumente chiar livrează rezultate.

Pentru că livrează.

Iar datele arată fără echivoc că AI accelerează dezvoltarea software. Întrebarea nu este dacă există câștiguri de productivitate, ci cât de mari sunt ele în realitate și cum trebuie interpretate.

Raportul DORA 2025 marchează o schimbare importantă față de anul anterior. Dacă în 2024 utilizarea AI era asociată cu rezultate inconsistente asupra livrării, în 2025 relația devine pozitivă. Echipele care folosesc aceste instrumente livrează mai mult software și o fac într-un ritm mai ridicat.

Cu alte cuvinte, organizațiile au început să învețe cum să integreze AI în procesele lor, iar beneficiile devin vizibile și în date, nu doar în percepția dezvoltatorilor.

Aceeași concluzie este susținută și de telemetria Faros AI, construită pe activitatea a aproximativ 22.000 de dezvoltatori.

Rezultatele sunt impresionante:

  • +21% task-uri finalizate;
  • +98% pull request-uri îmbinate;
  • +66,2% mai multe epice finalizate per dezvoltator în datele din 2026.

La prima vedere, aceste cifre par să confirme ideea că AI produce dezvoltatori mult mai eficienți.

Dar aici apare una dintre cele mai importante lecții statistice din întregul articol.

GitClear a analizat separat dezvoltatorii care folosesc intensiv AI și a observat că aceștia produc de patru până la zece ori mai mult cod decât colegii care nu utilizează astfel de instrumente.

Concluzia instinctivă ar fi că AI este responsabil pentru această diferență.

Realitatea este însă alta.

Când aceiași dezvoltatori sunt comparați cu propria lor performanță din perioada anterioară adoptării AI, creșterea este mult mai modestă: aproximativ 25%.

Diferența este esențială.

Nu AI transformă un dezvoltator obișnuit într-un performer de top. Mai degrabă, dezvoltatorii foarte buni sunt primii care adoptă și valorifică eficient instrumentele noi.

Este diferența clasică dintre corelație și cauzalitate.

Faptul că performanța și utilizarea AI apar împreună nu înseamnă automat că una o produce pe cealaltă. De multe ori, cele mai productive echipe sunt și cele care adoptă cele mai rapid tehnologiile noi, iar această selecție naturală poate crea impresia unui efect mai mare decât există în realitate.

Acesta este și motivul pentru care multe studii de caz publicate de furnizorii de soluții AI par spectaculoase. De cele mai multe ori, ele analizează organizațiile și dezvoltatorii care erau deja peste medie înainte de introducerea acestor instrumente.

AI accelerează dezvoltarea software.

Datele confirmă acest lucru.

Dar accelerarea nu este atât de spectaculoasă pe cât sugerează uneori materialele de marketing și, cu siguranță, nu înlocuiește experiența tehnică sau procesele solide de dezvoltare.

Concluzia acestei secțiuni: AI oferă câștiguri reale de productivitate, însă acestea trebuie interpretate cu atenție. O parte importantă din diferențele observate provin din faptul că dezvoltatorii și organizațiile cele mai performante sunt, de regulă, și cele care adoptă primele noile tehnologii.

Mai mult cod nu înseamnă software mai bun — adopția și volumul cresc, dar calitatea codului scade

5. Ce s-a degradat, măsurabil

Până acum, datele au arătat un lucru clar: AI accelerează dezvoltarea software. Echipele livrează mai mult cod, finalizează mai multe task-uri și publică mai multe aplicații decât în urmă cu doar câțiva ani.

Dar orice creștere de productivitate ridică o întrebare firească:

Ce se întâmplă cu calitatea codului atunci când viteza crește atât de mult?

Aici apare unul dintre cele mai interesante studii din ultimii ani.

GitClear a analizat 623 de milioane de modificări de cod, realizate între 2023 și 2026, urmărind opt indicatori diferiți ai calității software și comparându-i cu perioada anterioară adoptării masive a AI, respectiv 2022–2023. Dimensiunea eșantionului este suficient de mare încât rezultatele merită tratate cu seriozitate.

Concluzia generală este simplă:

Scriem mai mult cod decât oricând. Îl întreținem mai puțin decât oricând.

Semnalele de risc cresc accelerat

Prima categorie de indicatori urmărește comportamente care, în general, cresc costurile de mentenanță și fac codul mai greu de întreținut pe termen lung.

Toți acești indicatori au evoluat în aceeași direcție:

  • blocurile de cod duplicate au crescut cu 81%, atingând cel mai ridicat nivel măsurat până acum;
  • copierea și lipirea codului în interiorul aceluiași commit a crescut cu 41%;
  • construcțiile care maschează erorile au crescut cu 47%;
  • cantitatea de cod rescrisă în primele două săptămâni după introducere a crescut cu 15%.

Fiecare dintre aceste cifre spune o poveste.

Mai mult cod duplicat înseamnă mai multe locuri în care aceeași problemă trebuie reparată ulterior.

Mai mult copy-paste înseamnă mai puțină reutilizare inteligentă.

Mai multe construcții care ascund erorile înseamnă probleme descoperite mai târziu, când costul remedierii este deja mai mare.

Iar faptul că o parte tot mai mare din cod este rescrisă imediat după introducere sugerează că viteza inițială este obținută, de multe ori, cu prețul unei prime versiuni insuficient validate.

Niciunul dintre acești indicatori nu demonstrează, individual, că AI produce cod slab.

Împreună însă conturează o tendință care nu poate fi ignorată.

Semnalele de reutilizare merg în direcția opusă

Poate și mai important este ceea ce nu se mai întâmplă.

GitClear observă o scădere consistentă a indicatorilor care caracterizează un cod matur și bine întreținut.

Printre cele mai relevante rezultate se numără:

  • procentul liniilor mutate în timpul refactorizării a scăzut de la 21% din modificări în 2022 la doar 3,8% în 2026;
  • conectivitatea dintre funcții a scăzut cu 35%;
  • întreținerea codului mai vechi de un an s-a redus cu 74%.

Aceste cifre sunt mai importante decât par la prima vedere.

Un produs software sănătos nu înseamnă doar cod nou.

Înseamnă și refactorizare, reorganizare, simplificare și îmbunătățirea continuă a codului existent.

Atunci când aceste activități dispar aproape complet, produsul continuă să crească, dar fundația lui rămâne aceeași.

Este asemănător cu adăugarea unui nou etaj peste o clădire fără a consolida structura de rezistență.

La început totul pare să funcționeze.

Problemele apar câțiva ani mai târziu.

De la refactorizare la duplicare

Poate cea mai sugestivă concluzie a studiului este comparația dintre două comportamente fundamentale ale dezvoltării software.

În 2022, dezvoltatorii preferau de aproximativ două ori mai des să refactorizeze codul existent decât să îl dubleze.

În 2026, raportul s-a inversat complet.

Astăzi este de aproximativ cinci ori mai probabil ca un dezvoltator să copieze sau să dubleze cod decât să îl consolideze într-o implementare comună.

Această schimbare spune mai mult decât orice procent de productivitate.

AI face foarte ușor să generezi încă o funcție.

Mult mai greu este să oprești dezvoltarea și să te întrebi dacă funcția respectivă trebuia, de fapt, integrată într-o arhitectură existentă.

Apar „componentele în V1 perpetuu”

GitClear folosește o expresie foarte inspirată pentru a descrie acest fenomen:

„Perpetual V1 Components”.

Ideea este simplă.

Componentele software nu mai trec prin ciclul normal de maturizare.

În loc să fie simplificate, consolidate și refactorizate în timp, ele rămân permanent la nivelul unei prime versiuni peste care se adaugă alte și alte straturi de cod.

Rezultatul este un sistem care continuă să funcționeze, dar devine din ce în ce mai greu de înțeles și de modificat.

Acesta este unul dintre motivele pentru care multe echipe spun că dezvoltarea este mai rapidă ca niciodată, în timp ce mentenanța pare mai dificilă decât în urmă cu câțiva ani.

Nu pentru că AI scrie cod prost.

Ci pentru că este atât de ușor să produci cod nou încât investiția în îmbunătățirea codului vechi începe, treptat, să dispară.

A doua foarfecă

În capitolul anterior am văzut prima „foarfecă”: numărul aplicațiilor crește mult mai repede decât numărul utilizatorilor.

Aici apare a doua.

Volumul de cod continuă să crească. Structura lui continuă să se degradeze.

Cele două tendințe evoluează aproape în oglindă și sunt vizibile în toate seturile importante de date analizate.

Concluzia acestei secțiuni: AI accelerează producția de software, însă viteza vine cu un cost. Pe măsură ce codul nou se generează tot mai ușor, refactorizarea, reutilizarea și întreținerea codului existent devin activități tot mai rare. Rezultatul nu este neapărat un software mai slab, ci unul care își acumulează mai repede datoria tehnică și devine mai dificil de întreținut pe termen lung.

6. Securitatea: sintaxa s-a rezolvat, siguranța nu

Unul dintre cele mai răspândite argumente în favoarea AI este că modelele actuale scriu cod din ce în ce mai bine. Și este adevărat.

Comparativ cu primele generații de asistenți pentru programare, modelele din 2026 generează cod mai coerent, compilează mai des și rezolvă un număr mai mare de probleme fără intervenție umană.

Dar există o diferență importantă între cod care funcționează și cod care este sigur.

Iar aici datele arată că progresul este mult mai modest.

Unul dintre cele mai complete studii pe această temă aparține Veracode, care a evaluat peste o sută de modele mari de limbaj folosind 80 de sarcini reale de programare în Java, JavaScript, Python și C#. Scopul nu a fost să măsoare cât de repede generează codul, ci cât de sigur este rezultatul produs.

Primele concluzii sunt surprinzătoare.

În medie, 45% din codul generat introduce vulnerabilități din OWASP Top 10, iar Java este limbajul cu cele mai slabe rezultate, atingând o rată de eșec de aproximativ 72%.

Aceste procente nu înseamnă că aproape jumătate din aplicațiile dezvoltate cu AI sunt vulnerabile.

Ele arată însă că un model de limbaj nu poate fi tratat ca o sursă implicit de cod sigur, indiferent cât de convingătoare pare soluția generată.

Modelele au devenit excelente la sintaxă

Partea interesantă a studiului nu este însă fotografia unui singur moment, ci evoluția în timp.

Veracode compară performanțele modelelor din 2023 cu cele din 2026 și observă o îmbunătățire spectaculoasă într-o direcție foarte precisă.

În doar trei ani, rata de corectitudine sintactică a crescut de la aproximativ 50% la peste 95%. Astăzi, modelele generează cod care compilează și rulează corect în majoritatea situațiilor.

Privită izolat, această evoluție este impresionantă.

Dacă ai folosit primele versiuni de Copilot sau ChatGPT pentru programare, diferența este evidentă. Astăzi întâlnești mult mai rar erori de sintaxă, variabile inexistente sau funcții care nu compilează.

Din acest punct de vedere, progresul este incontestabil.

Problema apare când vorbim despre securitate

În timp ce sintaxa aproape că s-a rezolvat, siguranța codului a rămas aproape neschimbată.

Rata de trecere a testelor de securitate continuă să oscileze între 45% și 55%, practic în aceeași zonă în care se afla și cu trei ani în urmă.

Cu alte cuvinte, modelele au învățat foarte bine cum să scrie cod valid, dar nu au făcut același progres atunci când vine vorba despre cod rezistent la vulnerabilități.

Acesta este unul dintre cele mai importante lucruri pe care îl pot înțelege echipele de dezvoltare.

Un program care compilează nu este automat un program sigur.

Iar un răspuns generat fluent de AI nu este automat o implementare corectă din punct de vedere al securității.

Mai mare nu înseamnă neapărat mai sigur

Un alt rezultat interesant al studiului este că dimensiunea modelului influențează mai puțin decât s-ar crede calitatea rezultatelor.

Veracode observă că diferențele dintre modelele de aproximativ 20 de miliarde de parametri și cele de 400 de miliarde de parametri sunt relativ mici atunci când criteriul de evaluare este securitatea aplicației.

Cu alte cuvinte, un model mult mai mare produce, de regulă, răspunsuri mai fluente și mai complete, însă acest lucru nu garantează și un cod mai sigur.

De ce apare această diferență?

Explicația este mai degrabă economică decât tehnică.

Corectitudinea sintactică este ușor de optimizat.

Există un feedback imediat.

Codul compilează sau nu compilează.

Testul trece sau nu trece.

Modelul poate învăța foarte eficient din milioane de astfel de exemple.

Securitatea funcționează complet diferit.

Nu există un „compilator al vulnerabilităților” care să spună instantaneu dacă o implementare este sigură.

De cele mai multe ori, o vulnerabilitate apare doar într-un anumit context, după o combinație specifică de acțiuni sau chiar după ce aplicația ajunge în producție și este analizată de un atacator.

Este o proprietate contextuală, nu una sintactică.

De aceea este și mult mai dificil de învățat automat.

Acesta este motivul pentru care modelele au făcut progrese spectaculoase în ceea ce privește calitatea sintaxei, dar progrese relativ mici în ceea ce privește securitatea. Despre ce ar trebui să facă echipele concret, am scris în ghidul de securitate AI pentru echipele de dezvoltare.

Se îmbunătățește rapid ceea ce poate fi măsurat ușor.

Ceea ce nu poate fi măsurat la fel de simplu evoluează mult mai lent.

A treia foarfecă

În capitolele anterioare am văzut două tendințe similare:

  • oferta de aplicații crește mai repede decât cererea;
  • volumul de cod crește mai repede decât calitatea structurală.

Acum apare aceeași relație și în zona securității.

Corectitudinea sintactică evoluează spectaculos. Siguranța codului aproape stagnează.

Este a treia „foarfecă” identificată în date și, probabil, una dintre cele mai importante pentru companiile care dezvoltă aplicații la scară largă.

Concluzia acestei secțiuni: AI produce astăzi cod care compilează aproape impecabil, însă nu există dovezi că produce și cod semnificativ mai sigur. Din acest motiv, verificările de securitate, code review-ul și testarea automată rămân etape obligatorii, indiferent cât de performant este modelul folosit.

7. Studiul care s-a autodistrus — și de ce este cel mai interesant rezultat

Până acum am analizat rapoarte bazate pe sondaje, telemetrie și milioane de linii de cod. Toate au aceeași limitare: descriu ce se întâmplă în lumea reală, dar nu pot demonstra cu certitudine că AI este cauza directă a schimbărilor observate.

Pentru asta este nevoie de un experiment controlat.

Exact un astfel de experiment a încercat să realizeze METR (Model Evaluation & Threat Research) în vara anului 2025. Și, paradoxal, tocmai faptul că experimentul aproape a eșuat îl transformă într-unul dintre cele mai interesante studii publicate până acum despre dezvoltarea software asistată de AI.

Primul experiment controlat serios

În iulie 2025, METR a organizat un studiu randomizat controlat folosind 16 dezvoltatori experimentați, care au rezolvat 246 de sarcini reale din propriile proiecte open-source.

Metodologia a fost simplă.

Pentru fiecare task, participanții erau repartizați aleatoriu într-unul dintre cele două grupuri:

  • dezvoltare cu AI;
  • dezvoltare fără AI.

Scopul era eliminarea influențelor externe și măsurarea cât mai exactă a impactului pe care îl are AI asupra vitezei de dezvoltare.

Rezultatul i-a surprins inclusiv pe cercetători.

Contrar așteptărilor, sarcinile rezolvate cu ajutorul AI au durat, în medie, cu 19% mai mult decât cele rezolvate fără AI.

La prima vedere, concluzia părea devastatoare.

Dacă AI încetinește dezvoltarea, atunci aproape întreaga industrie merge într-o direcție greșită.

Dar partea cea mai interesantă abia urma.

Percepția dezvoltatorilor nu coincidea cu realitatea

Înainte de începerea experimentului, participanții estimau că AI îi va face cu aproximativ 24% mai rapizi.

După finalizarea tuturor sarcinilor, deși datele arătau că lucraseră mai încet, majoritatea dezvoltatorilor continuau să creadă că au fost cu aproximativ 20% mai rapizi.

Diferența dintre realitate și percepție ajungea astfel la aproape 39 de puncte procentuale.

Acest rezultat este fascinant.

În mod normal, dezvoltatorii experimentați își estimează destul de bine propriul ritm de lucru.

În cazul AI, însă, senzația de viteză pare să fie mai mare decât viteza măsurată efectiv.

Explicația este probabil una psihologică.

Atunci când nu mai scrii manual zeci de linii repetitive de cod, ai impresia că avansezi mai repede. O parte din timpul economisit este însă consumată ulterior pentru citirea, verificarea, adaptarea și corectarea codului generat.

Procesul pare mai rapid.

Cronometrul spune altceva.

Un an mai târziu, rezultatele se schimbă

Dacă povestea s-ar opri aici, concluzia ar fi simplă: AI încetinește dezvoltarea.

Numai că 2026 aduce un nou studiu METR.

De această dată sunt implicați 57 de dezvoltatori, 143 de repository-uri și peste 800 de sarcini, folosind instrumente agentice mult mai avansate decât cele disponibile cu un an înainte.

Rezultatele sunt complet diferite.

Estimările indică o accelerare de aproximativ 18% pentru dezvoltatorii care participaseră și la primul studiu și de aproximativ 4% pentru participanții noi.

Mai important însă este faptul că intervalele statistice de încredere traversează valoarea zero.

Cu alte cuvinte, cercetătorii nu mai pot afirma cu certitudine nici că AI accelerează dezvoltarea, nici că o încetinește.

Datele nu sunt suficient de clare pentru o concluzie categorică.

Studiul începe să se autodistrugă

Aici apare probabil cel mai neobișnuit rezultat din întregul raport.

Problema nu mai era metodologia.

Problema deveniseră participanții.

Între 30% și 50% dintre dezvoltatori au recunoscut că evitau să trimită anumite task-uri spre randomizare deoarece nu voiau riscul de a fi obligați să le rezolve fără AI.

Alții au refuzat complet participarea.

Un dezvoltator nu a finalizat nici măcar o singură sarcină în grupul „fără AI”.

Din punct de vedere științific, acesta este un coșmar.

Orice experiment controlat are nevoie de două grupuri comparabile.

În momentul în care participanții refuză să intre în grupul de control, experimentul începe literalmente să se destrame.

Și exact asta s-a întâmplat.

Citatul care spune mai mult decât toate graficele

Un participant descrie experiența astfel:

„Să lucrezi fără AI este ca și cum ai traversa orașul pe jos după ce te-ai obișnuit cu Uber.”

Probabil aceasta este cea mai puternică observație din întregul studiu.

Nu pentru că demonstrează că AI este extraordinar de eficient.

Ci pentru că arată cât de profund s-a schimbat comportamentul dezvoltatorilor într-un timp foarte scurt.

AI nu mai este perceput ca un instrument opțional.

A devenit parte din modul normal de lucru.

Paradoxul adopției

Acesta este, poate, cel mai important mesaj al capitolului.

În doar câțiva ani, adopția AI a devenit atât de puternică încât începe să afecteze chiar instrumentele folosite pentru măsurarea impactului său.

Dacă nu mai poți convinge dezvoltatorii să lucreze fără AI nici măcar într-un experiment științific, devine extrem de dificil să răspunzi cu precizie la întrebarea:

„Cât de mult ne ajută, de fapt, AI?”

Paradoxal, incapacitatea de a construi un grup de control reprezintă una dintre cele mai solide dovezi că adoptarea AI este reală și profundă.

În același timp, este și un motiv serios de prudență atunci când cineva citează procente foarte precise despre câștigurile de productivitate.

În prezent, nimeni nu le mai poate măsura perfect.

Concluzia acestei secțiuni: cel mai valoros experiment realizat până acum nu demonstrează că AI este spectaculos de rapid sau spectaculos de lent. Demonstrează ceva mult mai important: AI a devenit atât de integrat în activitatea dezvoltatorilor încât este din ce în ce mai greu să găsești un punct de comparație fără el. Acesta este probabil cel mai puternic indicator al adopției reale din întreaga industrie.

Costul ascuns al codului generat de AI — cine verifică verificatorul? Verificarea devine noul blocaj

8. Unde s-a mutat gâtuirea

Dacă privim toate datele de până acum împreună, începe să apară un tipar foarte clar.

AI nu elimină blocajele din dezvoltarea software.

Le mută.

Timp de zeci de ani, scrierea codului a fost activitatea care consuma cea mai mare parte a efortului unei echipe de dezvoltare. Astăzi, această etapă se comprimă din ce în ce mai mult. Generarea unei funcții, a unui endpoint sau chiar a unei componente întregi durează minute, nu ore.

Problema este că restul procesului nu s-a accelerat în același ritm.

Iar datele arată exact unde apare noul blocaj.

Raportul DORA observă că timpul economisit la scrierea codului este, de cele mai multe ori, reinvestit în activități de verificare, audit și validare.

Cu alte cuvinte, dezvoltatorii nu petrec mai puțin timp lucrând.

Petrec mai puțin timp scriind și mai mult timp verificând ceea ce AI a produs.

Faros AI măsoară același fenomen dintr-o perspectivă complet diferită și ajunge la o concluzie similară.

Datele companiei arată că:

  • timpul median petrecut în review-ul unui Pull Request a crescut cu 441%;
  • cu 31% mai multe Pull Request-uri sunt aprobate fără niciun review;
  • dimensiunea medie a unui Pull Request a crescut cu 51,3%.

Aceste cifre spun foarte multe despre modul în care s-a schimbat dezvoltarea software.

Dacă un dezvoltator produce de două sau trei ori mai mult cod într-o zi, cineva trebuie să îl citească.

Iar citirea codului nu se automatizează la fel de ușor.

Un senior nu poate analiza de trei ori mai multe Pull Request-uri doar pentru că AI le-a generat mai repede.

Atenția umană rămâne aceeași resursă limitată.

Același fenomen apare și în Stack Overflow Developer Survey.

Nu viteza este principala problemă raportată de dezvoltatori.

Cea mai mare frustrare este codul „aproape corect” — acel cod care pare bun la prima vedere, compilează și rezolvă problema, dar conține mici greșeli care necesită timp pentru a fi descoperite și corectate.

Acesta este motivul pentru care trei metodologii complet diferite ajung la aceeași concluzie.

Scrierea codului nu mai este principalul blocaj.

Verificarea a devenit noul blocaj.

Iar verificarea nu poate fi scalată la fel de ușor ca generarea codului.

Poți genera de zece ori mai mult cod folosind modele tot mai performante.

Nu poți genera însă de zece ori mai multă experiență, atenție sau responsabilitate tehnică.

Acesta este unul dintre motivele pentru care DORA descrie AI ca pe un amplificator, nu ca pe un înlocuitor al proceselor de dezvoltare.

În organizațiile care au deja teste automate solide, code review riguros, control de versiune matur și bucle rapide de feedback, AI amplifică performanța întregii echipe.

În organizațiile în care aceste procese sunt slabe, AI amplifică exact aceleași probleme.

Rezultatul este simplu:

mai mult cod, mai multe probleme și mai mult haos, produse într-un timp mai scurt.

După cum sintetizează și raportul DORA:

„Viteză fără stabilitate înseamnă doar haos accelerat.”

Concluzia acestei secțiuni: AI nu elimină blocajele dezvoltării software. Le mută din zona producerii codului în zona validării lui. Astăzi, resursa limitată nu mai este viteza de scriere, ci capacitatea echipelor de a verifica, înțelege și menține codul generat.

9. Ce facem cu informația asta?

După toate datele prezentate, este ușor să cădem într-una dintre cele două extreme.

Prima este să concluzionăm că AI va rezolva toate problemele dezvoltării software.

A doua este să spunem că AI produce doar cod slab și trebuie evitat.

Niciuna dintre aceste concluzii nu este susținută de date.

Realitatea este mai puțin spectaculoasă și mult mai utilă.

AI este un instrument extrem de puternic.

Dar valoarea lui depinde aproape în întregime de procesele organizației care îl folosește.

Din toate studiile analizate rezultă câteva recomandări practice.

1. Măsoară structura, nu volumul

Ani la rând, echipele au urmărit indicatori precum numărul liniilor de cod, task-urile închise sau Pull Request-urile finalizate.

În 2026, acești indicatori spun din ce în ce mai puțin.

Dacă AI poate produce de câteva ori mai mult cod decât un dezvoltator în urmă cu doar câțiva ani, atunci volumul nu mai este un indicator al valorii create.

În schimb, metrici precum gradul de duplicare, conectivitatea funcțiilor, nivelul de refactorizare și întreținerea codului vechi descriu mult mai fidel sănătatea unui produs software.

2. Refactorizarea trebuie planificată

Un alt rezultat important este că refactorizarea nu mai apare natural în procesul de dezvoltare.

Dacă nu este planificată explicit, pur și simplu nu se întâmplă.

GitClear arată o scădere de aproximativ 74% a activităților dedicate întreținerii codului mai vechi de un an.

Nu pentru că echipele au decis acest lucru.

Ci pentru că ritmul ridicat de dezvoltare împinge permanent atenția către codul nou.

3. Codul generat trebuie tratat ca orice cod extern

Un model de limbaj nu cunoaște contextul complet al aplicației tale.

Din acest motiv, fiecare bucată de cod generată trebuie trecută prin același proces de validare ca orice contribuție externă.

Code review.

Teste automate.

Scanare de securitate.

Validare arhitecturală.

Nu pentru că AI ar scrie întotdeauna cod slab.

Ci pentru că datele arată că rata vulnerabilităților este suficient de mare încât încrederea oarbă nu este justificată.

4. Nu te baza pe impresii

Unul dintre cele mai interesante rezultate ale studiului METR este cât de ușor își pot evalua greșit dezvoltatorii propria productivitate.

Participanții erau convinși că lucrează mai repede chiar și atunci când măsurătorile arătau contrariul.

Percepția este utilă.

Datele sunt indispensabile.

Orice organizație care adoptă AI ar trebui să măsoare obiectiv impactul asupra vitezei, calității și stabilității produsului.

5. Nu confunda corelația cu cauzalitatea

Cele mai performante echipe sunt, de regulă, și cele care adoptă primele noile tehnologii.

Asta nu înseamnă automat că tehnologia este motivul pentru care sunt performante.

Procesele bune, arhitectura solidă și cultura tehnică matură existau adesea înaintea AI.

Instrumentele doar amplifică aceste avantaje.

6. Costul construirii a scăzut. Costul succesului nu.

Poate cea mai importantă concluzie a întregului articol este aceasta.

Într-un an în care numărul aplicațiilor noi se apropie de un milion, iar descărcările cresc cu doar aproximativ 2%, problema nu mai este construirea produsului.

Oricine poate construi software mai repede și mai ieftin decât în urmă cu câțiva ani.

Provocarea reală este alta.

Cum îl faci să fie descoperit.

Cum îl faci suficient de valoros încât oamenii să îl folosească.

Și cum îl menții suficient de bun încât să rămână relevant în timp.

Noul rol al inginerilor software — de la a scrie cod la a dirija: deciziile corecte contează mai mult decât viteza

Concluzie

Dacă toate studiile analizate au un punct comun, acela este că AI nu schimbă obiectivul dezvoltării software.

Schimbă doar costul unor etape din proces.

Scrierea codului devine din ce în ce mai ieftină.

Arhitectura nu.

Validarea nu.

Securitatea nu.

Înțelegerea nevoilor utilizatorilor nu.

Cu cât costul producerii codului scade, cu atât valoarea deciziilor luate înainte ca prima linie de cod să fie scrisă devine mai mare.

Acesta este motivul pentru care companiile care vor avea succes în următorii ani nu vor fi cele care generează cele mai multe linii de cod.

Vor fi cele care construiesc cele mai bune produse.

AI este un multiplicator extraordinar al vitezei.

Dar viteza nu este același lucru cu valoarea.

Iar datele prezentate în acest articol arată exact acest lucru.

AI-ul nu a eliminat complexitatea dezvoltării software. A mutat-o.

Și poate cea mai importantă concluzie dintre toate este aceasta:

AI a rezolvat exact partea care era deja cea mai ieftină.

Cum arată această schimbare la nivel de companie — și de ce infrastructura contează mai mult decât modelul — am detaliat în AI nu este software. Este o infrastructură de business.

Surse