💻 computer science

A Study of LLMs' Preferences for Libraries and Programming Languages

Deze studie onthult dat grote taalmodellen bij het genereren van code vaak onterecht voorkeur geven aan populaire bibliotheken zoals NumPy en de taal Python, zelfs wanneer deze niet optimaal zijn voor de taak, wat wijst op een neiging om bekendheid boven geschiktheid te verkiezen.

Oorspronkelijke auteurs: Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

Gepubliceerd 2026-04-09

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Titel: Waarom AI-Programma's Altijd dezelfde Keuzes Maken (En waarom dat soms gek is)

Stel je voor dat je een superintelligente, maar nogal starre kok hebt die je kunt vragen om een maaltijd te bereiden. Je zegt: "Maak een gerecht voor een feestje." De kok pakt direct de standaard ingrediënten: aardappelen, kip en een flesje ketchup.

Het probleem? Soms heb je een snelle, lichte salade nodig, of een gerecht dat in de oven moet. Maar deze kok maakt altijd aardappelen en kip, zelfs als je een ijsje bestelt. Hij is zo gewend aan die combinatie dat hij niet eens nadenkt over andere, misschien betere opties.

Dit is precies wat deze studie ontdekte over LLMs (de slimme AI's die code schrijven). Onderzoekers keken of deze AI's de juiste programmeertalen en software-bibliotheken kiezen, of dat ze gewoon "op de automatische piloot" werken.

Hier is wat ze vonden, vertaald naar begrijpelijke taal:

1. De "Aardappel-En-Kip"-Syndroom (Te veel van hetzelfde)

De AI's hebben een enorme voorkeur voor de bekendste, oudste gerechten in de keuken.

Het probleem: Als je vraagt om code te schrijven, kiezen ze bijna altijd voor Python (een populaire programmeertaal) en bibliotheken zoals NumPy (een hulpmiddel voor rekenen).
De gekke kant: Soms is dat helemaal niet nodig! Het is alsof je een kok vraagt om een salade te maken, en hij pakt een enorme pan aardappelen en begint die te bakken. In bijna de helft van de gevallen gebruikte de AI NumPy, terwijl het probleem helemaal geen rekenkracht nodig had.
De oorzaak: De AI's zijn getraind op een enorme berg code van internet. Omdat Python en NumPy daar het meest voorkomen, denken de AI's: "Ah, dit is hoe je dingen doet!" Ze vergeten dat er ook snellere, lichtere of veiligere manieren zijn.

2. De "Snelheids-Blunder" (De verkeerde auto voor de race)

Stel je voor dat je een Formule 1-auto nodig hebt voor een race. Maar de AI kiest voor een gezellige, comfortabele stadsbus.

Het scenario: De onderzoekers gaven de AI taken waar snelheid en veiligheid cruciaal zijn, zoals het bouwen van een handelsplatform voor aandelen of een systeem dat direct met hardware communiceert. Voor deze taken zijn talen zoals Rust of C++ veel beter (ze zijn sneller en veiliger).
Het resultaat: De AI's negeerden deze betere opties volledig. Ze bleven Python gebruiken, zelfs als dat als een "stadsbus" in een Formule 1-race werkt: traag en ongeschikt. In 58% van deze gevallen bleef de AI bij Python, en Rust werd niet één keer gebruikt.
De les: De AI kiest voor wat ze kennen (de stadsbus), niet voor wat het beste werkt voor de race.

3. De "Twee Monden" (Wat ze zeggen vs. wat ze doen)

Dit is misschien wel het gekste deel.

Het gesprek: Als je de AI vraagt: "Wat is de beste taal voor een snelle webserver?", zegt de AI vaak: "Gebruik Rust of Go, die zijn veel sneller." Ze geven het juiste advies!
De daad: Maar zodra je zegt: "Oké, schrijf dan de code," veranderen ze van mening en schrijven ze weer in Python.
De analogie: Het is alsof een autoverkoper je vertelt: "Voor deze bergweg heb je een terreinwagen nodig," maar als je de sleutels krijgt, krijg je toch een lage sportwagen. De AI's weten wat ze moeten doen, maar hun gewoonte om Python te gebruiken is sterker dan hun kennis.

Waarom is dit belangrijk?

Als deze AI's steeds meer code schrijven voor ons, kunnen we in een cirkel van saaiheid terechtkomen:

AI's schrijven code in Python met standaardbibliotheken.
Die code komt op internet.
De volgende AI's leren van die code en denken: "Kijk, iedereen doet het zo!"
Ze schrijven nog meer code in Python, en vergeten de betere, snellere opties.

Dit kan leiden tot software die trager is, minder veilig is, en waar minder innovatie in zit.

Wat kunnen we doen?

De onderzoekers zeggen dat we de AI's niet blindelings moeten vertrouwen. We moeten:

Vragen stellen: "Waarom kies je deze taal?"
Andere opties geven: "Probeer eens Rust in plaats van Python."
De AI's trainen: Zorg dat ze leren dat er meer dan één manier is om een taak te doen, en dat "bekend" niet altijd "best" betekent.

Kortom: Deze slimme AI's zijn als een kok die alleen zijn favoriete recept kent. Ze zijn handig, maar ze moeten leren om ook eens naar de rest van de keuken te kijken voordat ze beginnen met koken!

Titel: A Study of LLMs' Preferences for Libraries and Programming Languages

Auteurs: Lukas Twist et al. (King's College London, UCL, GitHub Next, AI Research Labs)
Publicatie: Findings of ACL 2026

1. Het Probleem

Hoewel er veel onderzoek is gedaan naar de functionele correctheid, syntactische validiteit en beveiliging van door Large Language Models (LLMs) gegenereerde code, wordt een cruciaal aspect vaak genegeerd: de voorkeuren van LLMs bij het maken van ontwerpkeuzes, specifiek de selectie van programmeertalen en bibliotheken.

De auteurs stellen dat deze voorkeursvorming tastbare gevolgen heeft voor:

Softwareprestaties en efficiëntie.
Onderhoudbaarheid.
Diversiteit in het software-ecosysteem.

Er bestaat het risico dat LLMs dominante technologieën versterken en domeinspecifieke, maar minder populaire alternatieven negeren, wat kan leiden tot suboptimale of zelfs onveilige keuzes in de praktijk.

2. Methodologie

De studie omvat een empirisch onderzoek naar acht productieklaar LLMs (zowel open- als gesloten-bron, waaronder GPT-4o-mini, Claude-3.5, Llama-3.2, Mistral, Qwen-2.5 en DeepSeek). Het onderzoek is opgedeeld in drie experimenten:

Experiment 1: Voorkeuren voor Bibliotheken

Doel: Meten welke externe bibliotheken LLMs kiezen wanneer de prompt geen specifieke bibliotheek noemt.
Datasets:
- Benchmark-taken: 525 taken uit BigCodeBench (Python-taken waarbij de ground-truth geen externe bibliotheek vereist, om bias te voorkomen).
- Project-initialisatie: 5 open-ended projectbeschrijvingen (database, deep learning, distributed computing, web scraper, web server) waarbij de LLMs gevraagd werd om initiële code te schrijven.
Methode: Elke taak werd drie keer gegenereerd om variatie te minimaliseren. De auteurs analyseerden de geïmporteerde bibliotheken en vergeleken deze met de ground-truth en met "high-momentum" alternatieven (gebaseerd op GitHub-ster-groei).

Experiment 2: Voorkeuren voor Programmeertalen

Doel: Onderzoeken welke taal LLMs kiezen wanneer geen specifieke taal wordt opgegeven.
Datasets:
- Benchmark-taken: 6 datasets (Multi-HumanEval, MBXP, AixBench, CoNaLa, APPS, CodeContests) met taakbeschrijvingen in natuurlijke taal en oplossingen in meerdere talen.
- Project-initialisatie: 5 scenario's waar Python expliciet suboptimaal is vanwege prestatie-eisen (bijv. lage latentie trading platform, systeemtoepassingen, concurrentie).
Methode: Analyse van de gebruikte taal in de gegenereerde code versus de ground-truth.

Experiment 3: Consistentie van Aanbevelingen

Doel: Controleren of de aanbevelingen die LLMs in natuurlijke taal (NL) geven overeenkomen met de technologieën die ze daadwerkelijk gebruiken in de code.
Methode: De LLMs werden gevraagd om een ranglijst van de "beste" bibliotheken/talen te geven. Deze ranglijst werd vergeleken met de daadwerkelijke gebruiksfrequentie uit Experiment 1 en 2, gemeten met de Kendall's $\tau_b$ correlatiecoëfficiënt.

3. Belangrijkste Resultaten

A. Overmatige gebruik van gevestigde bibliotheken

LLMs tonen een sterke neiging om oude, breed geaccepteerde bibliotheken te gebruiken (bijv. NumPy, pandas, Matplotlib), zelfs wanneer deze niet nodig zijn.
Statistiek: In tot 45% van de gevallen wordt NumPy gebruikt in taken waar de ground-truth het niet vereist.
Diversiteit: LLMs gebruiken een zeer beperkt aantal unieke bibliotheken (32-39) over honderden verschillende taken.
Nieuwe alternatieven: Moderne bibliotheken met snelle groei (zoals Polars, FastAPI, Ray) worden systematisch genegeerd ten gunste van oudere concurrenten (pandas, Flask, Dask). Bijvoorbeeld: Polars wordt in 0% van de gevallen gebruikt, terwijl pandas in 58% van de taken voorkomt.

B. Sterke bias naar Python

Benchmark-taken: Python is de standaardkeuze in 93,5% tot 99,4% van de gevallen, zelfs in datasets waar oplossingen in andere talen (C++, Java, Rust) beschikbaar zijn.
Suboptimale scenario's: Zelfs in projecten waar Python bekend staat als suboptimaal (bijv. voor hoge prestaties, lage latentie of systeemniveau), blijft Python de meest gebruikte taal in 58% van de gevallen.
Rust: In de high-performance project-initialisatie-taken werd Rust geen enkele keer gebruikt door de onderzochte modellen, hoewel het vaak de ideale keuze zou zijn.

C. Gebrek aan consistentie tussen aanbeveling en uitvoering

Er is een lage correlatie tussen wat LLMs aanbevelen in tekst en wat ze coderen.
Voor project-initialisatie-taken tegenstrijden LLMs hun eigen taaladviezen in 83% van de gevallen. Ze raden bijvoorbeeld vaak Rust of C++ aan voor performance-taken, maar genereren vervolgens Python-code.
De natuurlijke taal-uitvoer is dus een zwak signaal voor wat er in de gegenereerde code te verwachten valt.

4. Bijdragen

Eerste empirische studie: Dit is het eerste systematische onderzoek naar de voorkeuren van LLMs voor bibliotheken en programmeertalen bij codegeneratie.
Kwantificering van bias: De auteurs hebben de mate van voorkeur voor gevestigde technologieën en Python gemeten en de implicaties voor het ecosysteem belicht.
Open Science: De volledige dataset, code en resultaten zijn openbaar gemaakt via een GitHub-repository om verder onderzoek te stimuleren.

5. Betekenis en Conclusie

De studie concludeert dat LLMs vertrouwdheid en populariteit prioriteit geven boven geschiktheid en taakspecifieke optimaliteit.

Risico's: Deze homogenisatie kan leiden tot een feedbacklus waarbij LLMs steeds meer van dezelfde data synthetiseren, innovatie remmen en gebruikers naar suboptimale of onveilige keuzes leiden. Het kan ook de diversiteit in het software-ecosysteem verkleinen.
Aanbevelingen: De auteurs pleiten voor:
- Gerichte fine-tuning om bias te verminderen.
- Diversificatie van trainingsdata.
- Nieuwe evaluatiebenchmarks die niet alleen correctheid meten, maar ook de kwaliteit van ontwerpkeuzes (taal- en bibliotheekselectie).

De bevindingen benadrukken dat ontwikkelaars en organisaties kritisch moeten blijven bij de door LLMs gegenereerde code en niet blindelings moeten vertrouwen op de standaardkeuzes van de modellen.