Hoe AI-ontwikkelaars onbewust de programmeertaaloorlog beslechten

Sophie Jansen · 2026-08-21

Je zou denken dat AI-coderingstools ons vrijmaken van programmeertaalbeperkingen, toch? Het tegendeel blijkt waar. In augustus 2025 werd TypeScript de meest gebruikte taal op GitHub. Die verschuiving was de grootste in tien jaar tijd – en viel precies samen met de meest versnelde adoptie van AI-codeeragents. We dachten dat organisaties stack-agnostisch zouden worden. Dat ze technologie zouden kiezen puur op basis van het bedrijfsprobleem, zonder te kijken naar het beschikbare ontwikkelaarstalent. Maar twee jaar na de wijdverspreide invoering van AI-tools lijkt de markt juist beperkter. Er is een snelle vernauwing van beschikbare programmeertalen, en bijna alle aandacht gaat naar één taalfamilie. ### De cijfers liegen er niet om GitHub's Octoverse-rapport van oktober 2025 telde 2,64 miljoen maandelijkse TypeScript-bijdragers. Dat is een stijging van 66% ten opzichte van het jaar ervoor. Meer dan een miljoen ontwikkelaars schreven in 2025 hun eerste TypeScript-code op GitHub. Die groei komt bovenop een al dominante positie. De Stack Overflow-enquête van 2025, met meer dan 49.000 reacties, toonde aan dat 66% van de ontwikkelaars JavaScript gebruikt. 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 hun eigen platform tellen is natuurlijk wat gekleurd – ze willen natuurlijk goed voor de dag komen. Ook modegrillen beïnvloeden wat er in publieke repositories staat. Toch komen de indicatoren overeen met enquêtegegevens, wat redelijk is gezien de omvang van deze trend. ### Modellen schrijven best wat ze het vaakst 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, een groot deel draait om React. Dat creëert een enorme kloof in de output die ontwikkelaars binnen een dag kunnen zien bij het wisselen van stack. Vraag een codeeragent om een getypeerde React-component te genereren en de output compileert meestal, voldoet aan de standaarden van de codebase en vereist minimale aanpassingen. Maar vraag hetzelfde agent om code voor Svelte, Solid of een minder populair backend-framework, en de output is dunner. Je ziet meer verzonnen API's en de scaffolding heeft meer correcties nodig voordat het uitvoerbaar is. Hierdoor verandert de manier waarop teams hun tech-stack selecteren fundamenteel. Het gaat niet langer om welk framework het meest efficiënt of makkelijkst is, maar welk framework het meest compatibel is met de tools van het team. Die productiviteitskloof in bruikbare agent-output tijdens een langdurige ontwikkelcyclus wordt alleen maar groter. En wanneer dat team output produceert, wordt het gepubliceerd, gescraped en opgenomen in volgende trainingsrondes – wat de kloof weer verbreedt. Dit wijst niet op een technisch oordeel. Solid en Svelte zijn uitstekende frameworks, en verschillende modernere frameworks overtreffen React op rauwe snelheid. De markt beloonde simpelweg de keuze die de modellen al kenden. ### De paradox: Python bouwt, JavaScript levert Een valide tegenwerping is dat AI-ontwikkeling vooral in Python gebeurt. Modeltraining, evaluatie en de meeste onderzoeksinstrumenten draaien op Python – dat is niet veranderd. Maar weinig van wat de klant daadwerkelijk gebruikt is in Python geschreven. 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. Die gebruikersinterface? Die draait bijna altijd op JavaScript. Het is een interessante splitsing: de hersenen van de AI zijn Python, maar het gezicht naar de wereld is JavaScript. Dat verklaart mede waarom JavaScript-familie zo dominant blijft – elke AI-tool die je gebruikt, versterkt indirect die positie. Wat betekent dit voor jou als ontwikkelaar of teamleider? Een paar praktische overwegingen: - **Frameworkkeuze wordt nu ook een tooling-keuze**: Kies je voor het meest populaire framework omdat de AI-tools daar beter mee omgaan, of kies je het technisch superieure framework en accepteer je wat productiviteitsverlies? - **De vicieuze cirkel doorbreken**: Teams die met minder populaire stacks werken, kunnen bijdragen aan open source om de trainingsdata te verbeteren. - **Toekomstbestendigheid**: Blijf kritisch – wat nu populair is bij AI-tools, is niet per se de beste technische oplossing voor jouw specifieke probleem. Zoals een ontwikkelaar me laatst zei: *"Het voelt alsof we niet meer programmeren voor mensen, maar voor de AI die ons moet helpen programmeren."* Die observatie raakt de kern van deze verschuiving. Uiteindelijk gaat het om balans. AI-tools zijn fantastische productiviteitsboosters, maar ze mogen niet onze technische beslissingen dicteren. Blijf nadenken, blijf kritisch, en kies wat werkt voor jouw team en project – niet alleen wat de AI het beste begrijpt.