Waarom AI-codeertools de keuze voor programmeertalen juist beperken

Sophie Jansen · 2026-08-21

In augustus 2025 gebeurde iets opvallends op GitHub. TypeScript werd de meest gebruikte programmeertaal op het platform. Dat was de grootste verschuiving in de taalranglijsten van GitHub in tien jaar tijd. En het gebeurde precies in de periode waarin AI-codeertools de snelste adoptie kenden. Dat is best ironisch, vind je niet? Veel experts voorspelden namelijk dat AI-agents de keuze voor programmeertalen minder belangrijk zouden maken. Het idee was dat organisaties 'stack agnostisch' zouden worden. Ze zouden hun tech-stack puur kiezen op basis van het bedrijfsprobleem, zonder rekening te houden met het beschikbare ontwikkelaarstalent. Maar in werkelijkheid zien we nu het tegenovergestelde. Slechts twee jaar na de wijdverspreide adoptie van AI-codeertools lijkt de markt juist beperkter te worden. Er is een snelle vernauwing van beschikbare programmeertalen gaande. En de meeste aandacht gaat uit naar één enkele taalfamilie. ### De cijfers achter de verschuiving Laten we even naar de data kijken. Het Octoverse-rapport van oktober 2025 telde 2,64 miljoen maandelijkse TypeScript-bijdragers op GitHub. Dat is een stijging van 66% ten opzichte van het jaar ervoor. In 2025 alleen al schreven meer dan een miljoen ontwikkelaars hun eerste TypeScript-code op GitHub. Dit groeicijfer komt bovenop een al dominante positie. De Stack Overflow-ontwikkelaarsenquête van 2025 verzamelde meer dan 49.000 reacties. Daarvan gaf 66% aan JavaScript te gebruiken. Sinds 2011 domineert JavaScript deze positie bijna elk jaar. Kortom, de JavaScript-familie is zowel de meest gebruikte als de snelst groeiende op GitHub. Nu moet ik wel een kanttekening plaatsen bij GitHub's telmethode. Activiteit op GitHub tellen betekent activiteit op hun eigen site tellen. Dat kan een belangenconflict opleveren, want ze willen natuurlijk goed voor de dag komen. Ook modegrillen beïnvloeden wat er in publieke repositories wordt geplaatst. Maar de indicatoren komen wel overeen met enquêtegegevens. En dat is redelijk, gezien de omvang van deze specifieke trend. ### Waarom AI-modellen beter zijn in bekende code Hoe dit werkt is eigenlijk best simpel. AI-modellen leren van de code die wordt gepubliceerd. En het meeste gepubliceerde code is geschreven in JavaScript en TypeScript. Sterker nog, veel code draait om React. Dit creëert een behoorlijke kloof in de output die ontwikkelaars van hun agents zien. Vraag een codeer-agent om een getypte React-component te genereren en de output compileert meestal, voldoet aan de standaarden van de codebase en vereist minimale aanpassingen. Maar vraag diezelfde agent om code voor Svelte, Solid of een minder populair backend-framework? Dan wordt de output vaak veel dunner. Je ziet meer verzonnen API's en de scaffolding heeft meer correcties nodig voordat het uitvoerbaar is. ### Hoe dit stack-keuzes verandert Dit verandert nu echt hoe teams hun stacks selecteren. Het is niet langer alleen een kwestie van welk framework het meest efficiënt of makkelijkst is om mee te werken. Het gaat nu om welk framework het meest compatibel is met de tools van het team. Want die productiviteitskloof in bruikbare agent-output tijdens een uitgebreide bouwcyclus wordt alleen maar groter. Wanneer dat team output produceert, wordt het gepubliceerd, gescraped en opgenomen in latere trainingsruns. Dat verbreedt de productiviteitskloof alleen maar verder. Dit wijst overigens niet op een technisch oordeel. Solid en Svelte zijn goede frameworks. En verschillende modernere frameworks overtreffen React op rauwe snelheid. De markt beloonde gewoon de keuze die de modellen al kenden. ### Python bouwt, maar JavaScript levert Een geldig tegenargument is dat AI-ontwikkeling in Python gebeurt. Modeltraining, evaluatie en de meeste onderzoeks-tooling draaien in Python. En dat is niet veranderd. Maar heel weinig van wat de klant ziet is geschreven in Python. De front-end van een AI-product is eigenlijk gewoon een venster dat tokens streamt. Het heeft ook knoppen nodig om tools uit te voeren, een goedkeuringsstap voor alles wat tot een negatieve uitkomst kan leiden en een uitleg van wat het systeem deed en waarom. Dit betekent dat zelfs AI-producten die volledig in Python zijn gebouwd, vaak een JavaScript-front-end hebben. De modellen leren dus vooral van JavaScript-code in het wild. En dat versterkt de dominantie van die taalfamilie alleen maar. Het is een soort zelfversterkend effect geworden. Teams kiezen JavaScript-frameworks omdat hun AI-tools er beter in zijn. Die teams produceren code, die wordt gepubliceerd en gebruikt om de modellen te trainen. En zo worden de modellen nóg beter in JavaScript-frameworks. Wat betekent dit voor jou als ontwikkelaar of tech-lead? Het betekent dat stack-keuzes complexer zijn geworden. Je moet niet alleen kijken naar technische merites, maar ook naar tooling-ondersteuning. Want die productiviteitskloof kan op de lange termijn echt verschil maken. En het roept interessante vragen op. Gaan we naar een toekomst met minder programmeertaal-diversiteit? Of ontstaan er nieuwe tools die deze kloof kunnen dichten? De komende jaren zullen het uitwijzen. Maar voor nu lijkt de AI-revolutie JavaScript en zijn familie alleen maar sterker te maken.