Do These Violent Delights Have Violent Ends? Measuring the Post-Merge Fate of Agentic Code
Deze longitudinale studie van 182 repositories onthult dat hoewel agentische codebijdragen merge-percentages bereiken die vergelijkbaar zijn met die van menselijke code, ze vervolgens aanzienlijk hogere lasten voor correctief onderhoud met zich meebrengen en meer beveiligingskwetsbaarheden introduceren, met name in projecten met lage review-percentages.
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 door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je net een vloot razendsnelle, onvermoeibare robot-assistenten hebt ingehuurd om je te helpen bij het bouwen van een enorme, uitgestrekte stad van code. Deze robots, aangedreven door de nieuwste "agentic" AI, kunnen in een oogwenk hele wijken aan software in een handomdraai creëren. De techreuzen juichen en zeggen dat deze robots 30% tot 75% van de code in hun steden schrijven. De statistieken zien er geweldig uit: de robots produceren pull requests (bouwvergunningen) sneller dan je kunt tellen, en de meeste ervan worden goedgekeurd en toegevoegd aan het stadsplan.
Maar hier komt de twist: wat gebeurt er nadat de vergunning is ondertekend en het gebouw officieel deel uitmaakt van de stad?
Dat is precies wat deze studie heeft onderzocht. In plaats van alleen te tellen hoeveel gebouwen de robots hebben gebouwd, hebben de onderzoekers de code een heel jaar lang gevolgd (van mei 2025 tot mei 2026) over 182 echte projecten. Ze volgden elke regel code als een detective die een verdachte volgt, met de vraag: Overleeft deze regel, of wordt hij gesloopt en opnieuw opgebouwd? Wie repareert het als het kapot gaat? En verbergt het gevaarlijke vallen?
De Grote Verrassing: Het Gaat Niet Om "Hoeveel", Maar Om "Hoe Slecht"
Je zou verwachten dat door robots gebouwde code een totale ramp zou zijn en direct in elkaar zou storten. Of je zou kunnen denken dat het perfect is. De waarheid is iets subtieler.
De studie vond dat, over het algemeen, door robots gebouwde code niet op een significant andere manier wordt "gesloopt" (beëindigd) dan door mensen geschreven code. Als je alleen naar de ruwe cijfers kijkt van hoe lang een stuk code standhoudt, lijken de robots en de mensen op gelijke voet te staan.
Echter, zodie de je dieper kijkt naar waarom die code wordt aangepast, verandert het beeld drastisch.
- De "Bug Fix"-magneet: Robotcode is een magneet voor correcties. De studie vond dat agentic code 46% meer correctief onderhoud (het repareren van dingen die kapot zijn) ontvangt dan menselijke code.
- De details van de "Bug Fix": Specifiek krijgt robotcode 45% meer bugfixes. Hoewel menselijke code ook veel bugfixes krijgt, lijken de robots meer van deze fouten te introduceren.
- De "Val"-factor: Robotcode is ook eerder geneigd om beveiligingszwakheden en gevaarlijke afhankelijkheden mee te brengen. De studie mat dit met tools zoals Semgrep en OSV-Scanner. Robotcode introduceerde beveiligingsbevindingen op een 1,14 keer hoger tempo dan menselijke code, en ernstige (zeer slechte) bevindingen op 1,51 keer het tempo van menselijke code.
Denk er zo over na: de robots zijn geweldig in het bouwen van de muren, maar ze vergeten vaak de brandmelders te installeren of gebruiken brandbare verf. Het gebouw staat wel, maar het heeft later veel meer brandveiligheidsinspecties en reparaties nodig.
De "No-Review" Gevaarzone
Een van de meest cruciale bevindingen gaat over hoe de code wordt goedgekeurd. De onderzoekers keken naar wat er gebeurt wanneer projecten code mergen zonder dat er eerst een menselijke review aan vooraf is gegaan.
Ze vonden een direct verband: hoe meer code een project mergt zonder menselijke review, hoe zwaarder de onderhoudslast wordt.
- Specifiek: voor elke toename van 10 procentpunten in het "no-review rate" van een project, stijgt de onderhoudslast van de agentic code met ongeveer 6%.
Dit suggereert dat de robots niet alleen fouten maken; ze maken fouten die een menselijke reviewer juist opgemerkt zou hebben. Wanneer je de review overslaat, laat je de robots ongecontroleerd hun gang gaan, en de rekening voor het herstellen van hun fouten wordt later gepresenteerd.
Het "Velocity Asymmetry" Probleem
Het artikel betoogt dat we een gevaarlijk evenwicht hebben gecreëerd, wat zij een "generation-review asymmetry" noemen.
- Generatie (Schrijven): De robots kunnen oneindig snel code schrijven, onbegrensd door menselijke vermoeidheid.
- Review (Controleren): Mensen zijn nog steeds degene die het werk controleren. Ze worden moe, ze zijn druk, en ze kunnen maar zo snel lezen.
De studie suggereert dat proberen dit op te lossen door simpelweg "sneller te reviewen" of "de review te automatiseren" niet de oplossing is. Als je de robots code laat schrijven sneller dan mensen het kunnen controleren, bouw je uiteindelijk een enorme achterstand aan verborgen defecten op. Het artikel betoogt dat de oplossing niet is om het reviewproces dunner uit te rekken, maar om de tools zelf te verbeteren, zodat ze code produceren die vanaf het begin daadwerkelijk veilig en onderhoudbaar is.
Wat het Papier Uitsluit
Het is belangrijk om ook te weten wat deze studie niet heeft gevonden:
- Het vond NIET dat robotcode op elk gebied universeel "slechter" is. De algehele overlevingskans (hoe lang code standhoudt voordat deze wordt gewijzigd) is statistisch gezien vergelijkbaar met menselijke code. Het verschil zit in het type wijzigingen (meer bugfixes, niet meer feature-toevoegingen).
- Het vond NIET dat het probleem willekeurig is. De onderhoudslast is niet gewoon pech; het is gekoppeld aan specifieke projectkenmerken, zoals hoeveel code er zonder review wordt gemerged.
- Het bewees NIET dat robots "slecht" of "nutteloos" zijn. Het mat simpelweg dat ze momenteel meer bugs en beveiligingslekken introduceren die menselijke opruiming vereisen.
De Kern van het Verhaal
De studie concludeert dat hoewel de robots indrukwekkend zijn in het maken van code, ze momenteel minder betrouwbaar zijn in het blijven van code. Het "succes" van deze tools zou niet gemeten moeten worden aan de hand van hoeveel code ze genereren of hoeveel pull requests er worden gemerged. In plaats daarvan is de echte test: Blijft de code veilig en stabiel nadat deze is gemerged?
Het artikel suggereert dat naarmate we meer op deze agents vertrouwen, we moeten stoppen met het vieren van de snelheid van generatie en moeten beginnen met ons zorgen te maken over de kosten van de opruiming. De robots zijn snel, maar als ze een spoor van bugs en beveiligingslekken achterlaten, zullen de mensen die het moeten opruimen overwerken. Het doel moet niet zijn om een stad te bouwen die er op dag één geweldig uitziet; het doel moet zijn om een stad te bouwen die een jaar later geen constante noodreparaties nodig heeft.
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.