Code Roulette: How Prompt Variability Affects LLM Code Generation

Dit paper introduceert een modelonafhankelijke evaluatiepipeline om de gevoeligheid van LLM-generatie van code voor variaties in prompts te kwantificeren, met als doel de impact van gebruikersachtergrond op de codekwaliteit te meten.

De kern

Stel je voor dat je een zeer getalenteerde, maar soms wat verwarde kok hebt. Deze kok is een Grote Taalmodel (LLM) en zijn specialiteit is het koken van code (de instructies die computers nodig hebben om te werken).

Je geeft de kok een recept (een prompt of opdracht) in gewone taal. Bijvoorbeeld: "Maak een taart die eruitziet als een auto."

De vraag die de auteurs van dit onderzoek stellen, is heel simpel: Hoe gevoelig is deze kok voor kleine veranderingen in je recept?

Als je het woord "auto" verandert in "vrachtwagen", of als je per ongeluk een lettertje mist, of als je het recept in andere woorden schrijft met hetzelfde bedoeling, maakt de kok dan nog steeds precies dezelfde taart? Of krijg je ineens een taart die eruitziet als een boot, of misschien wel een baksteen?

Hier is de samenvatting van het onderzoek "Code Roulette", vertaald in een makkelijk verhaal:

1. Het Probleem: De "Roulette" van de Prompt

In de echte wereld schrijven mensen dingen anders. De ene persoon zegt "maak een lijst", de ander zegt "ik wil een overzicht van items", en weer een ander typt per ongeluk "lijst" als "liist".

De onderzoekers wilden weten: Hoeveel verschil maakt dat voor de code die de computer maakt?
Ze noemen hun methode "Code Roulette" omdat het een beetje voelt als het draaien aan een rad: je weet niet precies wat je krijgt als je de prompt net iets anders invoert.

2. Hoe hebben ze het getest? (Het Experiment)

Ze hebben een soort "proefkeuken" gebouwd met vier verschillende koks (vier populaire AI-modellen: GPT-4o, Claude, Gemini en Llama). Ze gaven ze allemaal dezelfde basisopdracht, maar dan met drie soorten "vervuiling":

• Typefouten (Keyboard Typos): Ze veranderden letters in letters die op het toetsenbord ernaast liggen (bijv. 's' in plaats van 'a'). Dit is alsof je de kok een beetje in de war brengt met slecht geschreven woorden.
• Synoniemen: Ze vervangen woorden door synoniemen (bijv. "snelle auto" wordt "vlugge wagen"). Dit is alsof je de instructie in een andere taal of stijl geeft, maar met dezelfde betekenis.
• Parafraseren: Ze schreven de hele zin anders op, maar met dezelfde bedoeling (bijv. "Ik wil een snelle auto" wordt "Kun je een voertuig maken dat hard rijdt?").

Vervolgens keken ze niet of de code goed werkte (of de taart lekker smaakte), maar keken ze of de code er hetzelfde uitzag als de originele code. Als de structuur van de code heel anders was, was de AI gevoelig voor de verandering.

3. Wat vonden ze? (De Resultaten)

Hier zijn de belangrijkste ontdekkingen, vertaald in alledaagse termen:

• Typefouten zijn dodelijk: Als je kleine typefouten in de opdracht stopt, wordt de code van de AI heel snel heel anders. Het is alsof de kok paniek krijgt als je "taart" typt als "taart" met een extra 't'. De code verandert dan drastisch, zelfs als je maar een klein beetje verandert.
• Synoniemen en andere woorden zijn veiliger: Als je gewoon andere woorden gebruikt voor hetzelfde idee (synoniemen) of de zin anders opbouwt (parafraseren), is de AI veel stabieler. De kok begrijpt dan nog steeds wat je wilt en maakt ongeveer dezelfde taart.
• De "Oude" vs. "Nieuwe" Recepten:
  • Als ze de AI een opdracht gaven die al bekend was (oudere LeetCode-opgaven), was de AI heel stug en veranderde hij bijna niets, zelfs als je de opdracht volledig verpestte. Dit komt omdat de AI deze recepten waarschijnlijk al uit zijn hoofd kent (dit noemen ze "data contamination" of verontreiniging).
  • Maar bij nieuwe, unieke opdrachten (die de AI nog nooit had gezien), was de AI veel gevoeliger. Een klein verhaaltje in de opdracht zorgde al voor een heel andere taart.
• Niet alle koks zijn hetzelfde: Sommige AI's (zoals Gemini en GPT-4o) waren heel consistent: als je hetzelfde recept gaf, kregen ze bijna exact dezelfde taart. Andere AI's (zoals Llama) waren wat wispelturiger en gaven zelfs bij hetzelfde recept soms een iets andere taart.

4. Waarom is dit belangrijk?

Stel je voor dat je een software-ontwikkelaar bent die een app bouwt. Als jij en je collega twee verschillende manieren gebruiken om hetzelfde te vragen aan de AI, en de AI geeft jullie twee totaal verschillende code-structuren, dan wordt het een chaos om die code later te onderhouden.

Het onderzoek zegt ons:

1. We moeten voorzichtig zijn met hoe we AI's instructies geven. Kleine fouten kunnen grote gevolgen hebben.
2. AI's zijn niet altijd betrouwbaar als "zwarte dozen". We moeten begrijpen dat ze gevoelig zijn voor hoe we iets vragen.
3. Voor de toekomst: Als we AI's willen vertrouwen om code te schrijven, moeten we manieren vinden om ze stabieler te maken, zodat ze niet in paniek raken als je een lettertje mist of een ander woord kiest.

Conclusie in één zin

Dit onderzoek laat zien dat AI's voor het schrijven van code soms erg gevoelig zijn voor kleine veranderingen in wat we zeggen (vooral typefouten), en dat we beter moeten begrijpen hoe we met hen moeten praten om betrouwbare resultaten te krijgen. Het is een waarschuwing om niet zomaar blind te vertrouwen op wat de AI produceert, maar te kijken hoe stabiel dat antwoord is.

Technische samenvatting

Probleemstelling

De generatie van code door Large Language Models (LLMs) is een van de meest actieve toepassingsgebieden, met het potentieel om de drempel voor codering te verlagen en softwareontwikkeling te versnellen. Echter, de kwaliteit en functionaliteit van gegenereerde code zijn sterk afhankelijk van de kwaliteit van de input-prompt.

Het centrale probleem dat dit paper adresseert, is de gevoeligheid (sensitivity) van LLMs voor variaties in de input-prompt. Gebruikers met verschillende achtergronden, opleidingsniveaus en mentale modellen van programmering formuleren dezelfde technische vereisten vaak op verschillende manieren (via typos, synoniemen of parafraseren). Het is onduidelijk in welke mate kleine, semantisch equivalente wijzigingen in de prompt leiden tot fundamenteel verschillende code-uitvoer. Dit gebrek aan voorspelbaarheid ondermijnt het vertrouwen in LLMs en maakt het moeilijk om gestandaardiseerde code-uitvoer te garanderen, zelfs als de onderliggende eis hetzelfde is.

Methodologie

De auteurs hebben een evaluatiepijplijn ontworpen om de gevoeligheid van LLMs voor prompt-variaties kwantitatief te meten. Deze pijplijn is model- en taakagnostisch.

1. Evaluatieproces:

   • Er wordt een referentiebasislijn vastgesteld door $n$ onafhankelijke code-voorbeelden te genereren vanuit een onveranderde prompt.
   • Vervolgens wordt een augmentatiefunctie ($F$) toegepast om de prompt te verstoren met een bepaalde intensiteit ($r \in [0, 1]$).
   • Voor elke verstoringsgraad worden nieuwe code-outputs gegenereerd.
   • De afstand tussen de verstoord gegenereerde code en de referentie-basislijn wordt gemeten en geaggregeerd.

2. Augmentatiemethoden:
   Drie soorten verstoringen werden toegepast om variatie te simuleren:

   • Toetsenbord-typos: Willekeurige vervanging van karakters door naburige toetsen op het QWERTY-toetsenbord.
   • Synoniemen: Willekeurige vervanging van woorden door synoniemen (gebaseerd op WordNet).
   • Parafraseren: Gebruik van een ander LLM (Gemini) om de prompt te herschrijven terwijl de semantische betekenis behouden blijft, maar de woordkeuze varieert.

3. Afstandsmeting:
   In plaats van traditionele tekstmetrieken (zoals BLEU of BERT Score), die slecht presteren bij code, gebruiken de auteurs Tree Similarity of Edit Distance (TSED).

   • TSED meet de syntactische verschillen tussen abstract syntax trees (AST) van codefragmenten.
   • De output is een waarde tussen 0 (compleet verschillend) en 1 (identiek).
   • De focus ligt op consistentie en structuur, niet noodzakelijk op functionele correctheid, omdat zelfs "foutieve" code een geldige output is die een gebruiker kan zien.

4. Datasets:
   Drie datasets werden gebruikt om data-contaminatie te onderzoeken:

   • LeetCode (Oud): Bekende taken die waarschijnlijk in de trainingsdata van de modellen zaten.
   • LeetCode (Nieuw): Taken van maart 2025, waarschijnlijk niet in de trainingsdata.
   • Eigen Dataset: 22 open-ended taken (simulaties, data science, games) die specifiek zijn ontworpen om niet te lijken op standaard oefeningen en niet in trainingsdata te zitten.

Belangrijkste Resultaten

De experimenten omvatten vier populaire LLMs: GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash en Llama 3.3 70B.

• Invloed van Augmentatietype:

  • Typos: De gevoeligheid is het grootst bij toetsenbord-typos. De code-相似heid (TSED-score) daalt snel tussen een verstoringsgraad van 0,0 en 0,6, en stabiliseert rond een TSED van 0,3. Dit suggereert dat zelfs kleine typfouten leiden tot fundamenteel andere code-implementaties.
  • Synoniemen & Parafraseren: LLMs zijn veel robuuster tegen semantische variaties. De daling in similariteit is minder abrupt en de scores blijven hoger (bijv. Gemini 2.0 Flash blijft boven de 0,6).

• Invloed van Data-Contaminatie:

  • LeetCode (Oud): Toonde de laagste gevoeligheid. Omdat de taken waarschijnlijk in de trainingsdata zaten, herkenden de modellen ze zelfs bij sterke verstoringen en produceerden ze consistente code.
  • LeetCode (Nieuw): Toonde een gematigde gevoeligheid. De code-相似heid daalde pas onder de 0,5 nadat 50% van de prompt was gewijzigd.
  • Eigen Dataset: Toonde de hoogste gevoeligheid. Zelfs bij onveranderde prompts was er hoge variantie (TSED ~0,7). Bij slechts 10% verandering van de prompt daalde de similariteit onder de 0,5. Dit bevestigt dat modellen bij onbekende, open-ended taken extreem gevoelig zijn voor prompt-variaties.

• Modelverschillen:

  • Gemini 2.0 Flash en GPT-4o mini toonden de hoogste stabiliteit bij onveranderde prompts (nearly deterministisch bij temperatuur 0).
  • Llama 3.3 en Claude 3 Haiku toonden meer instabiliteit, zelfs zonder prompt-verandering.

Bijdragen

1. Evaluatiepijplijn: Een nieuwe, reproduceerbare procedure om de gevoeligheid van LLMs voor code-generatie te meten, onafhankelijk van specifieke modellen of taken.
2. Empirisch Bewijs: Uitgebreide experimenten die aantonen dat kleine prompt-variaties (typos, synoniemen) leiden tot significante verschillen in gegenereerde code, vooral bij taken die niet in de trainingsdata zitten.
3. Open Data en Code: De publicatie van een nieuwe dataset van open-ended taken en de openbaarmaking van de code voor de community.
4. Methode voor Sensitiviteitsanalyse: Het gebruik van TSED in plaats van tekstuele metrieken voor een nauwkeurigere analyse van code-structuur.

Betekenis en Conclusie

Het paper benadrukt dat het vertrouwen in LLM-generatie van code niet alleen afhangt van de nauwkeurigheid, maar ook van de consistentie bij variabele input. De bevindingen hebben belangrijke implicaties:

• Ontwikkelpraktijk: Ontwikkelaars moeten zich bewust zijn dat kleine formuleringsschommelingen in prompts kunnen leiden tot onvoorspelbare code-uitvoer, wat onderhoud en code-review bemoeilijkt.
• Systeemontwerp: Pipelines voor code-generatie moeten mogelijk mechanismen bevatten om prompt-variatie te compenseren (bijv. door meerdere prompts te genereren en te middelen, of door follow-up vragen te stellen).
• Onderzoek: De studie waarschuwt voor het gebruik van verouderde benchmarks (zoals oude LeetCode-taken) vanwege data-contaminatie. Nieuwe, open-ended datasets zijn nodig om de echte capaciteiten en beperkingen van LLMs te beoordelen.

Kortom, "Code Roulette" toont aan dat LLMs voor code nog niet volledig betrouwbaar zijn als "zwartkist" systemen voor gebruikers met verschillende achtergronden, en dat er meer onderzoek nodig is om de robuustheid en voorspelbaarheid van deze systemen te verbeteren.