🤖 machine learning

Learning from 53.6K Real-World Developer Edits of AI-Generated Code

Dit artikel introduceert DECODE, een dataset van 53.600 real-world in-IDE bewerkingen van door AI gegenereerde code van meer dan 1.000 ontwikkelaars, die onthult dat de meeste wijzigingen plaatsvinden binnen 15 minuten na acceptatie en aantoont dat het finetunen van kleinere modellen op deze data aanzienlijk beter presteert dan frontier LLM's in het voorspellen van code-bewerkingen.

Oorspronkelijke auteurs: Jenny T. Liang, Mihika Bairathi, Wayne Chi, Ameet Talwalkar, Nishant Subramani, Valerie Chen

Gepubliceerd 2026-07-29

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jenny T. Liang, Mihika Bairathi, Wayne Chi, Ameet Talwalkar, Nishant Subramani, Valerie Chen

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 robot leert koken. Je laat het de robot een receptenboek zien, en de robot probeert een gerecht te maken. Soms doet de robot het perfect. Maar vaak voegt hij te veel zout toe, vergeet hij de knoflook, of gebruikt hij een lepel in plaats van een garde. In de wereld van de informatica is deze robot een "AI-programmeerassistent", en de gerechten zijn regels code. Een lange tijd probeerden wetenschappers deze robots te onderwijzen door ze voltooide recepten te laten zien (genaamd "Git commits")—de uiteindelijke, perfecte gerechten die in kookboeken terechtkwamen. Maar dit is alsof je probeert te leren koken door alleen naar het eten op het bord te kijken, terwijl je de rommelige keuken, het aangebrande brood en de hectische correcties van de chef negeert.

De echte magie (en de echte chaos) gebeurt in het midden. Wanneer een menselijke chef een soep proeft en zegt: "Nee, er moet meer peper bij," of "Gooi dat eigenlijk weg en begin opnieuw," dan is dat een "code-edit". Tot nu toe hadden we geen goede manier om de chef dit te zien doen. We zagen alleen het eindresultaat. Dit artikel duikt in die rommelige, prachtige keuken. Het vraagt: Hoe passen mensen AI-fouten aan? Tweaken ze een klein beetje, of gooien ze het hele ding weg? En kunnen we de robot leren om deze aanpassingen te voorspellen voordat ze zelfs maar plaatsvinden?

De Grote Code-Detective: DECODE

De onderzoekers achter deze studie realiseerden zich dat om AI beter te laten worden in het schrijven van code, ze moesten stoppen met het bekijken van het eindproduct en het proces moeten gaan observeren. Ze creëerden een enorme nieuwe dataset genaamd DECODE (Developer Edits of Code Dataset). Zie DECODE als een gigantisch, high-definition beveiligingscamerasysteem geïnstalleerd in de IDE's (de digitale werkruimtes) van meer dan 1.000 echte ontwikkelaars. In plaats van alleen de definitieve code op te slaan, legde dit systeem elke enkele toetsaanslag, verwijdering en herschrijving vast die een ontwikkelaar maakte nadat de AI een stuk code had gesuggereerd.

Ze verzamelden 53.600 van deze echte editor-sessies, voornamelijk in Python, TypeScript en JavaScript. Het is alsof je een bibliotheek hebt van 53.600 verhalen over hoe mensen en robots ruziën, compromissen sluiten en samenwerken om software te bouwen.

Wat Ze Vonden: De 15-Minuten Regel en de "Vuilnisbak"

Toen het team naar de data keek, ontdekten ze enkele verrassende patronen in hoe mensen met AI-suggesties omgaan.

Eerst ontdekten ze een strikte 15-minuten regel. De meeste aanpassingen gebeuren heel snel. Als een ontwikkelaar de code van de AI gaat veranderen, doen ze dat meestal binnen de eerste 15 minuten nadat de suggestie is geaccepteerd. Daarna wordt de code meestal met rust gelaten.

Ten tweede ontdekten ze dat mensen verrassend streng zijn. In ongeveer 31% van de gevallen heeft de ontwikkelaar de code niet alleen aangepast; ze hebben de volledige suggestie van de AI verwijderd en vanaf nul opnieuw begonnen. Het is alsof de AI je een broodje aanreikt, en je het direct in de prullenbak gooit omdat het brood net niet goed is. De data suggereert dat als een AI-suggestie niet direct perfect aansluit bij de intentie van de ontwikkelaar, deze vaak gedoemd is om te worden verlaten.

Echter, wanneer mensen de code wel behouden, veranderen ze niet veel. De data laat zien dat voor de code die overleeft, ontwikkelaars meestal ongeveer 63% van de oorspronkelijke AI-suggestie behouden. Ze voegen meestal heel weinig van hun eigen nieuwe code toe (slechts ongeveer 20% van de uiteindelijke code is nieuwe inhoud toegevoegd door de mens). Dit betekent dat ontwikkelaars zwaar leunen op de AI, maar ze zijn zeer kieskeurig over de initiële kwaliteit.

De onderzoekers merkten ook een specifieke volgorde op waarin mensen dingen repareren. Het is als een checklist:

De "Is dit überhaupt bruikbaar?" check: Eerst beslissen ze of ze de code überhaupt willen houden. Zo niet, dan verwijderen ze het.
De "Fix de bugs" fase: Vervolgens herstellen ze syntactische fouten of leesbaarheidsproblemen.
De "Maak het van mij" fase: Daarna passen ze variabelen aan of veranderen ze getallen om het aan hun specifieke behoeften te laten voldoen.
De "Verander het plan" fase: Ten slotte, als ze er nog steeds mee bezig zijn, kunnen ze de daadwerkelijke functie van de code veranderen.

De Robot Gedachten laten Lezen

Het tweede grote deel van het artikel was een test: Kunnen we een kleiner, open-source AI-model leren om deze edits beter te voorspellen dan de gigantische, super-slimme "frontier" modellen?

Normaal gesproken worden de grootste, duurste AI-modellen als de beste beschouwd in alles. Maar hier namen de onderzoekers een kleiner model (met 3 miljard parameters, wat piepklein is vergeleken met de reuzen) en trainden dit specifiek op de DECODE-dataset. Ze leerden het model om naar een AI-suggestie te kijken en te raden: "Zal de mens dit verwijderen? Zullen ze het tweaken? Of zullen ze het ongemoeid laten?"

De resultaat was een schok. Het kleine model, nadat het had geleerd van de echte editor-data, werd significant beter in het voorspellen van edits dan de enorme, state-of-the-art modellen die deze specifieke data nooit hadden gezien.

Voor het raden van wat de uiteindelijke code zou worden, verbeterde het kleine model de nauwkeurigheid met 0,17 (een enorme sprong in dit vakgebied).
Voor het raden van of de code wel of niet zou worden gewijzigd, verbeterde het ook met 0,17.

Dit suggereert dat het hebben van de juiste "ervaring" (real-world editing data) belangrijker is dan alleen een groter brein hebben. Het is als een jonge chef die duizenden kookprogramma's heeft bekeken (de data) en daardoor misschien beter weet hoe hij een gerecht moet repareren dan een beroemde chef die alleen maar perfecte maaltijden heeft gekookt in een laboratorium.

De Les: Het Gaat Om de Mens, Niet Alleen de Code

Het artikel concludeert dat we moeten stoppen met het behandelen van AI-codegeneratie als een wiskundig probleem waarbij het enige doel "correctheid" is. Het echte doel is "alignment" (afstemming). De code moet aansluiten bij de intentie van de mens, anders gooit de mens het gewoon weg.

De auteurs suggereren dat toekomstige AI-assistenten niet alleen moeten proberen om in de eerste poging de perfecte code te schrijven. In plaats daarvan moeten ze getraind worden om het proces van het editen te begrijpen. Ze moeten leren dat mensen dingen vaak snel verwijderen, dat ze fouten repareren voordat ze functies veranderen, en dat ze eerder geneigd zijn code te behouden die gemakkelijk aanpasbaar is.

Door gebruik te maken van datasets zoals DECODE, kunnen we AI bouwen die niet alleen code schrijft, maar code schrijft die mensen ook echt willen behouden. Het is een verschuiving van de vraag "Is deze code correct?" naar de vraag "Is deze code iets dat een mens gemakkelijk tot zijn eigen kan maken?". En de data suggereert dat als we onze AI leren om de rommelige, 15-minuten durende editing-window te begrijpen, we eindelijk een robot kunnen krijgen die een maaltijd bereidt waar we blij mee zijn.

Technische Samenvatting: Leren van 53,6K Real-World Developer Edits van AI-gegenereerde Code

Probleemstelling

Ondanks de wijdverspreide adoptie van AI-programmeerasstistenten, is gegenereerde code vaak imperfect, bevat het bugs of sluit het niet aan bij specifieke programmeerstijlen. Bijgevolg moeten ontwikkelaars AI-gegenereerde code handmatig wijzigen, hetzij door directe bewerking, hetzij door het model opnieuw aan te sturen (re-prompting). Huidige Large Language Models (LLMs) worden primair getraind op publiekelijk beschikbare Git-data (bijv. commits en pull requests) om code-bewerking te leren. Echter, Git-data vertegenwoordigt slechts de uiteindelijke, succesvolle staat van code, en mist de tussenliggende stappen, de temporele ordening en de context van het werkelijke bewerkingsproces. Deze kloof beperkt het vermogen van LLMs om te voorspellen of te modelleren hoe ontwikkelaars AI-completions in real-time interageren met en wijzigen. Bovendien vertrouwen bestaande datasets vaak op synthetische data, laboratoriuminstellingen of geïnstrueerde edities, waardoor ze de nuances van real-world, handmatige codebewerkingen van AI-gegenereerde inhoud niet kunnen vastleggen.

Methodologie

1. Dataset Constructie: DECODE

Om het gebrek aan realistische bewerkingsdata aan te pakken, introduceren de auteurs DECODE (Developer Edits of Code Dataset), een collectie van 53,6K real-world, in-IDE code-edits van AI-gegenereerde code.

Bron: Data werd verzameld uit een Visual Studio Code (VS Code) extensie die door meer dan 1.000 ontwikkelaars wordt gebruikt. De extensie legt AI-completions en snapshots van het werkende bestand vast telkens wanneer een ontwikkelaar één seconde pauzeert.
Omvang: De dataset beslaat Python, TypeScript en JavaScript, verspreid over 20 verschillende LLMs en diverse ontwikkelingscontexten (bijv. webontwikkeling, data-analyse, machine learning).
Extractie Pipeline:
1. Identificatie: Het matchen van codebestanden die geaccepteerde AI-completions ( $y_0$ ) bevatten met daaropvolgende snapshots ( $y_t$ ).
2. Extractie: Gebruik van git diff --histogram om specifieke regels te isoleren die zijn toegevoegd, verwijderd of gewijzigd ten opzichte van de oorspronkelijke completion. Dit reduceerde de ruwe data van 6,5 miljoen regels naar 772,2 duizend regels die direct relevant zijn voor edities.
3. Opschoning: Valideren van trajecten met CodeBERTScore (drempelwaarde 0,68) om relevantie te waarborgen en het verwijderen van defecte data.
4. Privacy: Toepassen van PII-redactie pipelines (Starcoder/Stack en OpenAI Privacy Filter) om persoonlijk identificeerbare informatie te verwijderen.
Statistieken: De definitieve dataset bestaat uit 5.831 edit-trajecten van 1.141 ontwikkelaars, met een mediane trajectduur van ~50 minuten en een mediaan van 329 Levenshtein-edits per traject.

2. Analyse van Ontwikkelaarsgedrag

De auteurs gebruikten DECODE om te analyseren wanneer, waarom en hoe ontwikkelaars AI-code bewerken met behulp van metrieken zoals het aandeel resterende AI-code, door de ontwikkelaar toegevoegde code en het totale edit-volume.

Temporele Patronen: 50% van de edities vindt plaats binnen de eerste 50 minuten na acceptatie, met een steile daling na 15 minuten.
Edit Types: Edities werden geclassificeerd in vier categorieën: het aanpassen van code (10%), het verbeteren van kwaliteit (14%), het veranderen van functionaliteit (56%) en het verwijderen van completions (9%).
Resultaten: 31% van de trajecten resulteert in de volledige verwijdering van de AI-completion. De distributie van de resterende code is bimodaal: ontwikkelaars houden de code of met enkele wijzigingen, of zij verwerpen deze volledig.

3. Benchmarking van LLMs

De studie evalueerde het vermogen van LLMs om code-edits te voorspellen op twee taken:

Classificatie: Voorspellen of een AI-completion zal worden verwijderd, ongewijzigd blijft of wordt gewijzigd.
Generatie: Het voorspellen van de uiteindelijke staat van de code ( $y_t$ ) gegeven de initiële AI-completion ( $y_0$ ).
Geteste Modellen: Frontier-modellen (bijv. GPT-5.2, Claude Sonnet 4.6) en open-source modellen (bijv. Qwen2.5-Coder, Llama3.2) werden getest in few-shot settings en na fine-tuning op DECODE met behulp van LoRA.

Belangrijkste Resultaten

1. Inzichten in Ontwikkelaarsgedrag

Snelle Verwerping: Ontwikkelaars geven AI-completions vaak snel op als deze niet overeenkomen met hun intentie. 23% van de trajecten betreft onmiddellijke verwijdering, vaak gevolgd door het schrijven van een eigen implementatie door de ontwikkelaar.
Lage Toevoegingsratio: Ontwikkelaars voegen zelden aanzienlijke nieuwe code toe aan AI-completions; 20% van de uiteindelijke code is door de ontwikkelaar toegevoegd, en 36% van de trajecten bevat minder dan 5% nieuwe ontwikkelaarscode.
Sequentiële Bewerking: Er ontstaat een veelvoorkomend patroon waarbij ontwikkelaars eerst beslissen of ze de code behouden (verwijdering), dan fouten herstellen (kwaliteit), de code aanpassen aan behoeften (aanpassing), en tot slot de functionaliteit wijzigen.

2. Prestatieverbeteringen via Fine-Tuning

Superioriteit van Fine-Tuned Kleine Modellen: Het fine-tunen van open-source modellen (3B en 7B parameters) op DECODE presteerde aanzienlijk beter dan frontier-modellen in zowel classificatie- als generatietaken.
- Classificatie: Fine-tuned 3B-modellen bereikten een F1-score van 0,42–0,45, waarmee ze frontier-modellen zoals Claude Sonnet 4.6 (0,37) en GPT-5.2 (0,32) overtroffen.
- Generatie: Fine-tuned modellen verbeterden de Levenshtein-gelijkenis met +0,15 tot +0,22 ten opzichte van hun basisversies en presteerden aanzienlijk beter dan frontier-modellen (bijv. +0,17 verbetering ten opzichte van frontier-baselines).
Data Kwantiteit: Prestaties verbeterden naarmate modellen werden blootgesteld aan meer edit-stappen tijdens de training (tot 4 stappen), wat suggereert dat het vastleggen van de sequentiële aard van edities cruciaal is.
Geen Degradatie: Fine-tuning op DECODE leidde niet tot degradatie van de code-generatiecapaciteiten op standaard benchmarks (HumanEval, MBPP); in sommige gevallen (Qwen2.5-Coder-3B) verbeterde de prestatie zelfs licht.

Betekenis en Claims

Het paper betoogt dat ontwikkelaar-gecentreerde machine learning-benaderingen noodzakelijk zijn voor de volgende generatie AI-programmeerasstistenten. De belangrijkste conclusies zijn:

Alignment boven Correctheid: Standaard benchmarks focussen op code-correctheid (pass@k), maar real-world nut hangt af van hoe goed code aansluit bij de intentie en context van de ontwikkelaar. Ontwikkelaars verwerpen vaak "correcte" code als deze niet gemakkelijk aanpasbaar is.
Editability als Metriek: Het vermogen van AI-gegenereerde code om gemakkelijk bewerkt te worden (editability) is een kritieke, maar ondergemeten factor. Toekomstige modellen zouden in staat moeten zijn om generaties te detecteren die waarschijnlijk worden verworpen.
Temporele Modellering: LLMs moeten de sequentiële en temporele aard van ontwikkelaarsbewerkingen vastleggen (bijv. verwijderingen gebeuren vroeg, functionele wijzigingen gebeuren later). Training op ruwe Git-commits faalt in het vastleggen van dit dynamische proces.
Data Kwaliteit: Real-world interactiedata (zoals DECODE) is superieur aan synthetische of uit Git afgeleide data voor het trainen van modellen om handmatige code-bewerkingen te verwerken. Zelfs kleine modellen die gefinetuned zijn op hoogwaardige, real-world edit-data kunnen veel grotere frontier-modellen overtreffen.

De auteurs concluderen dat toekomstige AI-programmeerasstistenten nieuwe modellerings- en evaluatieparadigma's vereisen die expliciet rekening houden met ontwikkelaarinteractie, personalisatie en het iteratieve karakter van code-bewerking.