💬 NLP

Simulating Students' Java Programming Errors with Large Language Models

Dit artikel toont aan dat grote taalmodellen, in het bijzonder Claude Sonnet 4, effectief diverse en realistische Java-programmeerfouten van studenten kunnen simuleren, wat een schaalbaar alternatief biedt voor het verzamelen van authentieke inzendingen voor educatief onderzoek en intelligente tutorensystemen.

Oorspronkelijke auteurs: Ali Keramati, Jie Cao, Iman Mohammadi, Mark Warschauer, Yang Shi

Gepubliceerd 2026-06-15

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Ali Keramati, Jie Cao, Iman Mohammadi, Mark Warschauer, Yang Shi

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

Stel je voor dat je een docent bent die zich probeert voor te bereiden op een grote programmeerles. Je weet dat je studenten fouten zullen maken, maar je kunt niet precies voorspellen wat die fouten zullen zijn totdat je de les daadwerkelijk geeft en het huiswerk verzamelt. Dit is een traag en kostbaar proces.

Dit artikel stelt een simpele vraag: Kunnen we een super-slimme AI (een Large Language Model, of LLM) gebruiken om zich voor te doen als een verwarde student en die fouten vooraf voor ons te genereren?

Hier is de opbouw van hun experiment, uitgelegd met alledaagse analogieën.

Het Doel: De "Nepstudent"-test

De onderzoekers wilden zien of een AI Java-code kon schrijven die er precies zo uitziet alsof een beginnende student het geschreven heeft—specifiek, code die logische fouten bevat.

Logische fouten zijn als het schrijven van een recept waarin staat "voeg zout naar smaak toe" maar waarbij vergeten wordt om daadwerkelijk zout toe te voegen. De computer voert de code uit, maar het resultaat is fout omdat het denkproces gebrekkig was.
De Uitdaging: Als je een AI simpelweg vraagt om "code te schrijven," schrijft het meestal perfecte code. Als je het vraagt om de code te "breken," maakt het vaak willekeurige, stomme fouten (zoals een komma zetten waar een punt hoort te staan) die echte studenten niet echt maken. Het doel was om de AI realistische fouten te laten maken.

Het Experiment: De "Proeverij"

De onderzoekers namen 37 verschillende programmeerproblemen uit een echte klaslokaal (CodeWorkout). Ze lieten vijf verschillende AI-modellen deze problemen proberen op te lossen, maar ze gebruikten drie verschillende "instructiestijlen" (prompts) om de AI te dwingen fouten te maken:

Directe Opdracht (IO): "Hier is het probleem, geef een fout antwoord."
Hardop Denken (CoT): "Denk na over de stappen, beslis waar je een foutje zou kunnen maken, en schrijf dan de foute code."
Zelfcorrectie-lus (Self-Refine): "Schrijf een fout antwoord, bekritiseer het vervolgens, en verbeter het iets om een ander soort fout antwoord te maken."

Ze vergeleken de "nepfouten" van de AI vervolgens met 7and 74.000 echte fouten gemaakt door echte studenten.

De Twee Belangrijkste Regels voor een Goede Nepfout

Om nuttig te zijn, moesten de nepfouten van de AI aan twee tests voldoen:

Diversiteit (De Variatie-test): Maakte de AI veel verschillende soorten fouten, of herhaalde het steeds weer dezelfde fout? (Stel je een chef voor die probeert 10 verschillende soorten verbrande koekjes te maken. Als ze er allemaal exact hetzelfde uitzien, is dat niet erg divers).
Alignment (De "Echtheid"-test): Zagen de fouten van de AI eruit als iets wat een mens daadwerkelijk zou doen? (Als de AI code schrijft die fout is op een manier die een mens nooit zou bedenken, dan is het geen goede simulatie).

Wat Ze Vonden

1. De AI Kan Fouten Maken, Maar Niet Alle AI's Zijn Gelijk
Alle AI-modellen konden een verscheidenheid aan fouten genereren. Sommige waren echter beter in dit werk dan andere.

Gemini 2.5 Pro was als een chaotische kunstenaar: het maakte een enorme variëteit aan fouten (hoge diversiteit), maar veel van die fouten waren vreemd en zagen er niet uit als echte studentenfouten.
GPT-4o was als een voorzichtige student: het maakte steeds weer heel vergelijkbare fouten (lage diversiteit).
Claude Sonnet 4 was de Goldilocks van de groep. Het vond de beste balans. Het maakte genoeg verschillende soorten fouten, maar deze lagen ook heel dicht bij wat echte studenten daadwerkelijk schrijven.

2. De "Hardop Denken"-truc Hielp
Wanneer de onderzoekers de AI vertelden om "stap voor stap na te denken" voordat de code werd geschreven (Chain-of-Thought), werden de fouten realistischer. Het was alsof de AI het proces simuleerde van een student die in de war raakt, in plaats van alleen maar willekeurig de code te breken.

3. De "Moeilijkheidsgraad"-factor
De onderzoekers keken naar hoe "moeilijk" een probleem was (gebaseerd op hoe vaak studenten probeerden het op te lossen).

Makkelijke Problemen: De AI deed een geweldig werk bij het nabootsen van studenten.
Moeilijke Problemen: Naarmate de problemen moeilijker werden, werden de fouten van de AI diverser (het probeerde veel verschillende foute paden), maar ze werden minder zoals die van echte studenten. Het is als een beginnende acteur die een complexe scène probeert te spelen; ze kunnen veel verschillende interpretaties proberen, maar geen van hen vangt de nuance van een echte menselijke prestatie volledig.

4. De "Blinde Proeverij" (Menselijke Experts)
De onderzoekers huurden menselijke experts in om naar een mix van echte studenten-code en AI-gegenereerde code te kijken. Zij wisten niet welke welke was.

Het Resultaat: De experts werden 83,7% van de tijd gefopt. Ze dachten dat de code van de AI door een mens was geschreven.
De Twist: De experts vonden de fouten van de AI zelfs plausibeler (realistischer) dan de fouten van de echte studenten. Waarom? Omdat de AI "schone" fouten maakte (zoals een klassieke tekstboekfout), terwijl echte studenten vaak slordige, complexe fouten maken met meerdere fouten tegelijk. De AI was als een "geïdealiseerde" verwarde student, terwijl echte studenten rommeliger zijn.

De Kern van het Verhaal

Dit artikel bewijst dat AI kan fungeren als een "plaatsvervanger" voor studenten om realistische programmeerfouten te genereren.

Claude Sonnet 4 is momenteel de beste "student-simulator".
Moeilijkere problemen maken de AI creatiever maar minder accuraat ten opzichte van echt menselijk gedrag.
De Afweging: Je kunt een AI hebben die een enorme variëteit aan fouten maakt, óf een AI die zeer realistische fouten maakt, maar het is moeilijk om beide perfect tegelijkertijd te krijgen.

De onderzoekers suggereren dat dit een krachtig hulpmiddel is voor docenten en ontwikkelaars van educatieve software. In plaats van jaren te wachten op het verzamelen van duizenden echte studentenfouten om hun systemen te trainen, kunnen ze deze "nep" fouten gebruiken om betere bijlesprogramma's te bouwen en docenten te helpen anticiperen op waar studenten vast kunnen lopen.

Technische Samenvatting: Het simuleren van Java-programmeerfouten van studenten met Large Language Models

Probleemstelling

Het begrijpen van studentenfouten is fundamenteel voor het programmerenonderwijs, met name voor het identificeren van logische fouten die onderliggende misconcepties en gebrekkige redeneerstrategieën onthullen. Het verkrijgen van een representatieve set authentieke studentenfouten voor nieuw ontworpen taken is echter traag en kostbaar, omdat het uitgebreide implementatie in de klas en data-accumulatie vereist. Hoewel Large Language Models (LLM's) een schaalbare weg bieden om leergedrag te simuleren, kampen huidige benaderingen met een kritiek gat: algemene prompting leidt vaak tot correcte oplossingen, terwijl willekeurige corruptiestrategieën kunstmatige bugs produceren die geen pedagogische waarde hebben. De kernuitdaging is onderscheidbaarheid—het genereren van fouten die op de specifieke manieren fout gaan die een beginner zou maken (wat een gedeeltelijk begrip en specifieke misconcepties weerspiegelt), in plaats van oppervlakkige ruis. Bovendien geven bestaande evaluatie-infrastructuren vaak prioriteit aan absolute correctheid boven de diversiteit en afstemming van foutpatronen.

Methodologie

De studie maakt gebruik van de CodeWorkout dataset, bestaande uit meer dan 74.000 unieke Java-inzendingen van studenten over 37 introductie-programmeerproblemen, verzameld van bachelorstudenten aan Virginia Tech.

Experimenteel Ontwerp

Data-voorbereiding: De auteurs filterden de ruwe logs om alleen compileerbare maar incorrecte code (logische fouten) te behouden, waarbij syntactische fouten en volledig correcte inzendingen werden verwijderd. Problemen werden gecategoriseerd in drie struggling levels (Laag, Medium, Hoog) op basis van het totale volume aan studentenzendingen per probleem, wat dient als een proxy voor empirische leer moeilijkheid.
LLM Simulatie: Vijf LLM's werden geëvalueerd: Google Gemini 2.5 Pro, OpenAI GPT-5, OpenAI GPT-4o, Anthropic Claude Sonnet 4, en xAI Grok Code Fast 1.
Prompting Strategieën: Drie verschillende strategieën werden getest voor elke model/probleemcombinatie:
- Input-Output (IO): Directe instructie zonder tussenliggend redeneren.
- Chain-of-Thought (CoT): Het model formuleert een rationale voor een logische misslag voordat het de code genereert.
- Iteratieve Self-Refine: Een iteratieve lus waarbij een criticus feedback geeft en een verfijner de code herschrijft (tot vier iteraties).
Evaluatiemetrieken:
- Diversiteit (RQ1): Gemeten via de gemiddelde paargewijze Zhang–Shasha (ZSS) tree edit distance tussen de gegenereerde foutieve codes. Hogere afstanden duiden op grotere structurele variatie.
- Afstemming (RQ2): Gemeten door de nearest neighbor edit distance tussen de door de LLM gegenereerde code en de dichtstbijzijnde authentieke menselijke inzending. Lagere afstanden duiden op hogere getrouwheid aan echte studentenfouten.
- Kwalitatieve Validatie: Een geblindeerde expert-annotatiestudie ( $N=401$ ) vergeleek synthetische (Claude Sonnet 4 met Self-Refine) en authentieke fouten. Experts beoordeelden de plausibiliteit (1–5 Likert-schaal), voerden bronattributie uit (Turingtest) en categoriseerden fouten in acht logische-fout-taxonomieën.

Belangrijkste Resultaten

1. Diversiteit (RQ1)

Alle modellen toonden het vermogen om diverse foutieve code te genereren, maar de prestaties varieerden aanzienlijk per model en strategie.

Gemini 2.5 Pro en Claude Sonnet 4 vertoonden de hoogste diversiteit, met gemiddelde edit distances die vaak de 60 overschreden, met name bij gebruik van CoT-prompting.
GPT-4o produceerde de meest homogene (minst diverse) foutpatronen (afstanden ~25–40).
Impact van Prompting: Strategieën moduleerden diversiteit verschillend; bijvoorbeeld verminderde Self-Refine de diversiteit in Claude Sonne 4, maar verhoogde het de diversiteit in andere contexten.

2. Afstemming (RQ2)

Het vermogen om authentieke studentenfouten na te bootsen varieerde per model, met een duidelijke trade-off tegenover diversiteit.

Claude Sonnet 4 bereikte de meest gebalanceerde prestaties, waarbij relatief lage edit distances werd gehandhaafd (beste geval: 16,35 met Self-Refine) over alle strategieën, wat wijst op een sterke afstemming met menselijke fouten.
Grok Code Fast 1 bereikte de absolute minimale afstand (16,22) met Self-Refine, maar vertoonde een hoge variantie over andere prompts.
GPT-5 en Gemini 2.5 Pro vertoonden een slechte afstemming, met afstanden die vaak de 80 overschreden, wat suggereert dat hun fouten significant afwijken van authentieke studentpatronen.
Menselijke Evaluatie: Annotatoren classificeerden 83,7% van de door LLM gegenereerde inzendingen foutief als door mensen geschreven. Verrassend genoeg ontvingen door LLM gegenereerde fouten een significant hogere plausibiliteitsscore (4,27) dan authentieke fouten (3,78). Dit wordt toegeschreven aan het feit dat de LLM's "schone", enkelvoudige logische bugs genereerden (bijv. Condition Logic, Boundary errors) die lijken op tekstboekmisconcepties, terwijl authentieke studentcode vaak diffuse, multi-fault of strategie-niveau fouten bevatte die moeilijker helder te categoriseren waren.

3. Struggling Level als Moderator (RQ3)

De moeilijkheid van de programmeertaak (struggling level) beïnvloedde zowel diversiteit als afstemming.

Diversiteit: Hogere struggling levels riepen meer diverse (heterogene) foutieve outputs op van LLM's, omdat moeilijkere problemen meer faalpaden openen.
Afstemming: Daarentegen, naarmate het struggling level toenam, nam de afstemming tussen door LLM gegenereerde en authentieke fouten af (edit distances namen toe). Modellen vonden het moeilijker om student-achtige logische fouten te reproduceren op problemen met een hoge struggle.

Betekenis en Bijdragen

Het artikel stelt dat LLM's kunnen dienen als schaalbare proxies voor studenten in het genereren van logische fouten, maar met specifieke trade-offs die beheerd moeten worden op basis van het doel van de toepassing:

Gebalanceerde Simulatie: Claude Sonnet 4 wordt geïdentificeerd als het meest gebalanceerde model, dat een compromis biedt tussen het genereren van diverse foutpatronen en het handhaven van een hoge getrouwheid aan authentieke studentenfouten.
Pedagogische Nut: De studie valideert dat synthetische fouten functioneel ononderscheidbaar kunnen zijn van authentieke fouten voor experts. Dit ondersteunt de integratie van synthetische data in:
- Intelligente Tutoringsystemen (ITS): Om systemen te trainen in het diagnosticeren van diverse misconcepties zonder uitsluitend te vertrouwen op schaarse menselijke data.
- Teachable Agents: Om leerlingen de kans te geven te oefenen met debuggen door AI-gegenereerde fouten te corrigeren, wat indirect leren bevordert.
- Professionele Ontwikkeling van Docenten: Om docenten bloot te stellen aan een geconcentreerde variëteit van verwachte misconcepties voor betere instructieplanning.
Ontwerpprincipes: De bevindingen benadrukken een diversiteit–getrouwheid trade-off. Modellen die sterk zijn in diversiteit (bijv. Gemini) kunnen een gebrek aan afstemming hebben, terwijl degenen met een hoge afstemming minder divers kunnen zijn. Verder fungeert het "struggling level" van een taak als een dubbele moderator: het vergroot de breedte van de gesimuleerde fouten, maar vermindert de representativiteit van werkelijk studentgedrag.

De auteurs concluderen dat hoewel LLM's een veelbelovende weg bieden voor het uitbreiden van studentdata in onderwijstechnologie, het gebruik ervan een zorgvuldige selectie van modellen en promptingstrategieën vereist, afgestemd op de vraag of het doel brede misconceptie-dekking of de precieze benadering van geobserveerde klaslokaal foutverdelingen is.