Când au apărut primele unelte AI de codare, toată lumea prezicea că limbajul de programare va deveni irelevant. Logica era simplă: dacă AI-ul poate scrie cod în orice limbaj, atunci echipele vor alege tehnologia în funcție de problema de business, nu de pool-ul de dezvoltatori disponibili. Suna frumos în teorie. În practică, însă, s-a întâmplat exact invers. Piața s-a restrâns dramatic, iar aproape toată atenția s-a concentrat pe o singură familie de limbaje.
Raportul Octoverse al GitHub din octombrie 2025 arată că TypeScript a ajuns la 2,64 milioane de contribuitori lunari, o creștere de 66% față de anul anterior. Peste un milion de dezvoltatori au scris pentru prima dată cod TypeScript pe GitHub în 2025. Și asta pe lângă o poziție deja dominantă. Sondajul Stack Overflow din 2025, care a strâns peste 49.000 de răspunsuri, arată că 66% dintre dezvoltatori folosesc JavaScript. Practic, din 2011 încoace, JavaScript domină acest clasament în fiecare an.
Acum, hai să fim onești un pic. Metoda de numărare a GitHub are și ea problemele ei. Numări activitatea de pe propriul site, ceea ce creează un conflict de interese – le convine să arate bine. Și trendurile modei influențează ce fel de informații ajung în repository-urile publice. Dar indicatorii se aliniază cu datele din sondaje, ceea ce e destul de convingător când vorbim de un trend de această amploare.
Cum funcționează mecanismul? Simplu. Modelele de AI învață din codul publicat, iar cea mai mare parte a codului publicat e scris în JavaScript și TypeScript. De fapt, o mare parte din codul ăsta e centrat pe React. Asta creează un decalaj uriaș în calitatea output-ului pe care dezvoltatorii îl văd de la agenții lor de codare, și asta se vede încă din prima zi în care schimbi stack-ul.
Cere unui agent de codare să genereze o componentă React cu tipare și, de cele mai multe ori, output-ul compilează, respectă standardele codebase-ului și necesită modificări minime. Acum cere aceluiași agent să genereze cod pentru Svelte, Solid sau un framework backend mai puțin popular. Output-ul e vizibil mai subțire. Vezi mai multe API-uri inventate, iar scheletul de cod are nevoie de mult mai multe corecții înainte să fie executabil.
Asta schimbă felul în care echipele își aleg stack-ul. Nu mai e doar o chestiune de eficiență sau ușurință de lucru, ci de compatibilitate cu uneltele echipei. Decalajul de productivitate în output-ul agenților se compune pe parcursul unui ciclu lung de dezvoltare. Și aici intervine feedback-ul: când echipa produce cod, acel cod e publicat, e răzuit de crawler-e, ajunge în următoarele seturi de antrenament și lărgește și mai mult decalajul de productivitate.
Nimic din toate astea nu e un verdict tehnic. Solid și Svelte sunt framework-uri bune, iar multe framework-uri moderne depășesc React la viteză brută. Dar piața a recompensat alegerea pe care modelele deja o cunoșteau. E o dinamică de tip winner-take-all care se auto-întreține.
Acum, un contraargument valid: dezvoltarea AI se face în Python. Antrenarea modelelor, evaluarea, majoritatea tooling-ului de cercetare – toate rulează în Python, și asta nu s-a schimbat. Dar foarte puțin din ce interacționează clientul final e scris în Python. Front-end-ul unui produs AI e, în esență, o fereastră care streamează tokeni. Are nevoie de butoane pentru a executa unelte, de un pas de aprobare pentru orice ar putea duce la un rezultat negativ și de o explicație a ce a făcut sistemul și de ce. Toate astea se fac în JavaScript și TypeScript, indiferent dacă modelul vine de la OpenAI, Anthropic sau e un model open-weight găzduit pe hardware-ul companiei.
Până la sfârșitul lui 2025, GitHub raporta peste 1,1 milioane de repository-uri publice care folosesc un SDK pentru LLM, o creștere de 178% față de anul precedent. Creșterea asta se datorează în principal dezvoltării de aplicații, nu de modele. Fiecare pilot enterprise care trece de stadiul de demo are nevoie de cineva care să construiască componenta cu care interacționează utilizatorul, iar uneltele standard pentru treaba asta sunt framework-urile JavaScript.
GitHub are și o teorie interesantă: dezvoltatorii se îndreaptă spre limbaje cu tipare pentru că sistemele de tipuri fac dezvoltarea asistată de agenți mai sigură. Codul generat are un tip specific de eșec. Arată bine, e structurat corect, chiar rulează perfect în limbaje dinamice – doar ca să crape trei apeluri mai departe din cauza unor nepotriviri de formă. Type checkers prind o mare parte din asta înainte ca codul să ruleze.
Teoria s-a dovedit corectă în practică. În 2026, utilizarea TypeScript de către dezvoltatorii profesioniști a ajuns la 78%, o creștere de la 69% acum doi ani. Aproximativ 40% dintre dezvoltatori scriu exclusiv în TypeScript, iar doar 6% scriu exclusiv în JavaScript simplu. Tipurile de erori pe care le găsește un compilator sunt exact tipurile de erori pe care un reviewer uman le trece cu vederea când are în față 400 de linii de cod care arată rezonabil.
De exemplu, o funcție e apelată cu un obiect căruia îi lipsește unul dintre câmpurile obligatorii. Sau codul conține o presupunere despre forma datelor care nu se verifică în toate cazurile. Astea sunt erori subtile, greu de prins în review, dar pe care un type checker le semnalează instant.
De ce este important:
Această tendință nu e doar o curiozitate statistică. Ea redefinește economia dezvoltării software. Echipele care aleg framework-uri mai puțin populare riscă să piardă din productivitate, nu pentru că tehnologia e inferioară, ci pentru că uneltele AI nu o cunosc la fel de bine. Iar decalajul se adâncește în timp, pe măsură ce mai puțin cod din acele framework-uri ajunge în seturile de antrenament. Pentru dezvoltatori, asta înseamnă că alegerea stack-ului are acum o dimensiune nouă: compatibilitatea cu ecosistemul AI. Pentru companii, înseamnă că deciziile tehnice trebuie să țină cont de un factor care nu exista acum câțiva ani. Și pentru industrie, ridică o întrebare incomodă: cât de mult din diversitatea tehnică suntem dispuși să sacrificăm pentru productivitate?
