Hoe AI-tools de programmeertaalmarkt onbedoeld versmallen

Sophie Jansen · 2026-08-21

In augustus 2025 gebeurde er 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 weet je wanneer het gebeurde? Precies tijdens de periode waarin AI-coderingsagents het snelst werden geadopteerd. We dachten eerst dat AI-tools de keuze voor een programmeertaal minder belangrijk zouden maken. Organisaties zouden 'stack-agnostisch' worden en hun tech-stack puur kiezen op basis van het bedrijfsprobleem. De beschikbaarheid van ontwikkelaars zou er niet meer toe doen. Maar in werkelijkheid is het tegenovergestelde gebeurd. Slechts twee jaar na de wijdverspreide adoptie van AI-coderingshulpmiddelen lijkt de markt juist beperkter. Er is een snelle vernauwing van beschikbare programmeertalen, en de focus ligt op één enkele taalfamilie. ### De cijfers vertellen het verhaal Het Octoverse-rapport van oktober 2025 telde TypeScript-bijdragers. Met 2,64 miljoen maandelijkse bijdragers was dat een stijging van 66% ten opzichte van het jaar ervoor. In 2025 alleen al zetten meer dan een miljoen ontwikkelaars hun eerste TypeScript-code op GitHub. En dat is bovenop een al dominante positie. Uit een Stack Overflow-enquête onder 49.000 ontwikkelaars bleek dat 66% JavaScript gebruikte. Sinds 2011 domineert JavaScript die 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 hun eigen platform tellen brengt een belangenconflict met zich mee. Ook hebben modetrends invloed op wat er in openbare repositories staat. Maar de indicatoren komen overeen met enquêtegegevens, wat logisch is gezien de omvang van deze trend. ### Modellen schrijven het beste wat ze het meest zien Het mechanisme is eigenlijk heel simpel. AI-modellen leren van gepubliceerde code, en het meeste gepubliceerde code is geschreven in JavaScript en TypeScript. Sterker nog, veel code draait om React. Dit creëert een enorme kloof in de output die ontwikkelaars van hun agents zien. Vraag een coderingsagent om een getypte React-component te genereren, en de output compileert meestal, voldoet aan de standaarden en vereist minimale aanpassingen. Maar vraag je hetzelfde agent om code voor Svelte, Solid of een minder populair backend-framework? Dan is de output veel dunner. Je ziet meer verzonnen API's, en de scaffolding heeft meer correcties nodig voordat het uitvoerbaar is. - React-componenten zijn vaak direct bruikbaar - Minder populaire frameworks leveren 'dunnere' output - Meer verzonnen API's en scaffolding-fouten - Extra correctietijd nodig voor uitvoerbaarheid Dit verandert nu hoe teams hun stacks selecteren. Het gaat niet langer alleen om welke framework het efficiëntst of makkelijkst is. Het gaat om welke framework het meest compatibel is met de tools van het team. Want de productiviteitskloof in bruikbare agent-output wordt tijdens een langdurige bouwcyclus alleen maar groter. En als dat team output produceert, wordt het gepubliceerd, gescraped en opgenomen in volgende trainingsruns. Wat de kloof weer verder vergroot. Dit zegt niets over technische kwaliteit. 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. ### De paradox: Python bouwt, JavaScript levert Een terechte tegenwerping is dat AI-ontwikkeling in Python gebeurt. Modeltraining, evaluatie en de meeste onderzoeksinstrumenten draaien in Python. 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 een venster dat tokens streamt. Het heeft knoppen nodig om tools uit te voeren, een goedkeuringsstap voor risicovolle acties en een uitleg van wat het systeem deed en waarom. De gebruikersinterface, de interactie – dat is bijna allemaal JavaScript-land. Er zit een interessante spanning in: de hersenen van de AI zijn Python, maar het gezicht dat de wereld ziet is JavaScript. Het is alsof de motor van een auto in het ene land wordt gebouwd, maar het dashboard en de bediening in een ander. Die scheiding zorgt ervoor dat de ontwikkelingstrends in beide werelden soms vreemd uit elkaar lopen. Python blijft de taal van de onderzoekers en data scientists, terwijl JavaScript de taal is die de producten naar de mensen brengt. En omdat AI-tools vooral leren van die zichtbare, productieklare code, blijft de cirkel zich versterken. Dus waar staan we nu? AI-tools, bedoeld om keuzevrijheid te vergroten, versterken onbedoeld de dominantie van één taalfamilie. Het is een zelfversterkend effect waar ontwikkelteams rekening mee moeten houden. De keuze voor een tech-stack is niet langer puur technisch of strategisch. Het is ook een praktische afweging geworden: werk je mee met de stroom van de AI, of kies je voor een mogelijk superieure maar minder ondersteunde optie? Die vraag wordt steeds relevanter voor iedereen die software bouwt.