GitHub Copilot and Developer Productivity: An Observational Dose-Response Analysis
Door gebruik te maken van 16.223 Microsoft-engineers over 43 weken en een binnen-engineer fixed-effects design om individuele vaardigheid en inzet te controleren, stelt deze studie vast dat het gebruik van GitHub Copilot geassocieerd wordt met een monotone, 40,5% toename in de voltooiingspercentages van pull requests bij een gelijkblijvende programmeertijd, wat wijst op een echte efficiëntiewinst in plaats van een correlatie met inherent drukkere werkperioden.
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 probeert uit te zoeken of een nieuw paar high-tech hardloopschoenen mensen daadwerkelijk sneller laat rennen.
De voor de hand liggende manier om dit te testen is door twee groepen te vergelijken: mensen die de schoenen dragen en mensen die gewone sneakers dragen. Maar hier is het probleem: misschien zijn de mensen die kiezen voor de high-tech schoenen al professionele atleten, terwijl de sneakerdragers recreatieve joggers zijn. Als de schoenendragers sneller rennen, komt dat dan door de schoenen, of simpelweg door het feit dat ze van nature betere hardlopers zijn?
Dit is precies de puzzel waar Microsoft-onderzoekers voor kwamen te staan met GitHub Copilot, een AI-tool die software engineers helpt bij het schrijven van code. Ze wilden weten: Maakt het gebruik van de AI engineers daadwerkelijk productiever, of zijn de engineers die de AI het meest gebruiken gewoon van nature de meest productieve mensen?
Nog erger is er een tweede laag van verwarring. Misschien gebruikt een engineer de AI veel tijdens een specifieke week, niet omdat de AI magisch is, maar omdat die week een "crunch time" was waarin ze 80 uur per dag werkten aan een groot project. In dat geval zouden ze meer werk (Pull Requests) afgerond hebben, simpelweg omdat ze langer hebben doorgewerkt, en niet omdat de AI hen hielp om sneller te werken.
De Oplossing: Het "Zelfvergelijkings"-experiment
Omdat de onderzoekers niet willekeurig sommige engineers konden dwingen om te stoppen met het gebruik van de tool (dat zou onethisch zijn en hun werk verstoren), gebruikten ze een slimme truc genaamd een "Within-Engineer" analyse.
Denk er zo over na: in plaats van Engineer A (die AI gebruikt) te vergelijken met Engineer B (die dat niet doet), vergeleken ze Engineer A met zichzelf.
Ze keken naar dezelfde engineer over een periode van 43 weken.
- Week 1: De engineer gebruikte de AI nauwelijks.
- Week 2: De engineer gebruikte de AI intensief.
Door de engineer met zichzelf te vergelijken, elimineerden ze automatisch alle zaken die Engineer A verschillend maken van Engineer B (zoals natuurlijk talent, rol binnen het bedrijf of de cultuur van het team). Ze vroegen eigenlijk: "Wanneer deze specifieke persoon de AI meer gebruikt, krijgt hij dan meer gedaan vergeleken met wanneer hij het minder gebruikt?""
De "Efficiëntie"-test: Werkten ze harder of slimmer?
Er bleef nog één lastige variabele over: Inspanning.
Als een engineer veel AI gebruikt, kan het zijn dat diegene ook gewoon meer uren achter de computer heeft gezeten om te coderen, bijvoorbeeld 10 uur in plaats van 5. Als ze meer werk afkrijgen, is dat misschien simpelweg omdat ze meer tijd aan hun bureau hebben doorgebracht.
Om dit op te lossen, gebruikten de onderzoekers een statistische "filter" (een model genaamd PPML) die de tijd besteed aan coderen constant hield.
- De Vraag: "Als Engineer A precies 8 uur codeert, voltooit hij dan meer codeprojecten wanneer hij de AI intensief gebruikt vergeleken met wanneer hij dat niet doet?"
De Resultaat: Ja. Zelfs wanneer de tijd besteed aan coderen exact hetzelfde was, voltooiden engineers die de AI intensief gebruikten ongeveer 40% meer codeprojecten (Pull Requests) dan in weken waarin ze de AI helemaal niet gebruikten.
De "Falsificatie"-batterij: Excuses uitsluiten
De onderzoekers wisten dat sceptici andere redenen voor dit resultaat zouden bedenken. Daarom voerden ze zeven verschillende "leugendetectortests" uit om te zien of de resultaten toevallig waren.
De "Generieke AI"-test: Misschien zijn engineers die veel AI gebruiken gewoon algemeen "technisch onderlegd" en gebruiken ze andere AI-tools (zoals in Word of Excel), wat hen het gevoel geeft productiever te zijn?
- Test: Ze controleerden of het gebruik van AI in niet-coderende apps (zoals PowerPoint) meer code voorspelde.
- Resultaat: Nee. Het gebruik van AI in Word hielp niet bij het schrijven van code. Het was specifiek de coderings-AI die ertoe deed.
De "Team Hype"-test: Misschien zat het hele team in een "hype"-week, waardoor iedereen de AI gebruikte en iedereen meer code schreef?
- Test: Ze controleerden of het AI-gebruik van één engineer de code-output van hun collega's voorspelde.
- Resultaat: Nee. Als het puur team-hype was, zou jouw AI-gebruik de output van je buurman moeten voorspellen. Dat deed het niet.
De "Taakwisseling"-test: Misschien stopten engineers in AI-zware weken simpelweg met het beoordelen van de code van anderen en concentreerden zij zich volledig op het schrijven van hun eigen code?
- Test: Ze controleerden of het schrijven van meer code betekende dat ze minder code beoordeelden.
- Resultaat: Nee. Engineers schreven meer code EN beoordeelden meer code wanneer ze de AI gebruikten. Ze wisselden niet alleen van taak; ze deden meer van alles.
De "Slicing"-test: Misschien waren engineers grote projecten gewoon aan het opdelen in kleine, makkelijke stukjes om de cijfers gunstig te laten lijken?
- Test: Ze keken naar de grootte van de codeprojecten.
- Resultaat: Nee. De grootste boost zat juist in de grootste, meest complexe projecten (7+ bestanden), en niet in de kleine projecten.
De "Makkelijk Werk"-test: Misschien deden ze alleen maar makkelijk papierwerk (zoals tekstbestanden bijwerken) in plaats van zware codering?
- Test: Ze scheidden "makkelijke" configuratiebestanden van "moeilijke" codebestanden.
- Resultaat: Nee. De productiviteitsboost was zelfs sterker bij de moeilijke codebestanden.
De "Timing"-test: Misschien was het AI-gebruik in Week 1 slechts een teken van een "productieve stemming" die doorwerkte in Week 2?
- Test: Ze controleerden of het AI-gebruik van vorige week de output van deze week voorspelde.
- Resultaat: Nee. De boost vond alleen plaats in de exact dezelfde week als waarin de AI werd gebruikt.
De Conclusie
De studie concludeert dat GitHub Copilot engineers echt efficiënter maakt.
Wanneer een engineer de tool intensiever gebruikt, krijgt hij ongeveer 40% meer werk gedaan in dezelfde hoeveelheid tijd. Het is niet alleen zo dat productieve mensen de tool gebruiken; de tool zelf lijkt te fungeren als een krachtvermultiplier die engineers helpt om meer gedaan te krijgen zonder dat ze langer hoeven te werken.
De onderzoekers zijn echter voorzichtig met de opmerking: deze studie meet efficiëntie (meer gedaan krijgen per uur). Het meet niet de totale tijd bespaard. Als de AI je helpt een taak in 30 minuten in plaats van een uur te voltooien, gaat je "efficiëntie" omhoog, maar je stopt misschien ook gewoon eerder met werken. De studie bewijst dat de snelheid toeneemt, maar het vertelt ons niet precies hoe engineers die extra tijd besteden.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.