Technische Samenvatting: Een Exploratieve Studie naar door LLM gegenereerde Code en Commentaar in Code-repositories

1. Probleemstelling

De snelle adoptie van Large Language Models (LLM's) in software engineering, met name voor codegeneratie en samenvatting, heeft geleid tot rapporten dat 20% tot 30% van de code in grote technologiebedrijven door LLM's is gegenereerd. Er bestaat echter aanzienlijke scepsis over de praktische bruikbaarheid van deze inhoud, inclusief zorgen over verhoogde debuggingtijd, onnatuurlijk gegenereerd commentaar en het potentieel om kwetsbaarheden te introduceren.

Ondanks het wijdverbreide gebruik ontbreekt het aan empirische gegevens die de werkelijke proportie van door LLM gegenereerde inhoud in echte repositories kwantificeren, evenals de kenmerken en de associatie ervan met softwarebugs. Een primaire uitdaging bij het aanpakken hiervan is de afwezigheid van ground-truth labels (door mensen geverifieerde door LLM gegenereerde inhoud) in publieke repositories. Bijgevolg is er een behoefte om het landschap van LLM-gebruik te begrijpen via een proxy-gebaseerde analyse met behulp van bestaande detectietools.

2. Methodologie

De studie maakt gebruik van een detector-gebaseerd proxy-analyse kader om code en commentaar in actieve software-repositories van oktober 2021 tot oktober 2025 te onderzoeken.

Datacollectie en Selectie

• Repositories: Acht actieve repositories werden geselecteerd op basis van inclusiecriteria (actieve ontwikkeling, mainstream talen, analyseerbare tekst) en exclusiecriteria (geen automatisch gegenereerde templates, geen forks). De set bevat vier door bedrijven onderhouden repositories (Go-github, Guava, Liquid, Zap) en vier door de community onderhouden repositories (Act, Jadx, Kafka, Pandas).
• Tijdsbestek: Gegevens werden jaarlijks verzameld van 2021 tot 2025, in lijn met de release van belangrijke LLM's zoals Codex en GitHub Copilot.
• Inhoud: Bronbestanden werden voorbewerkt om code en commentaar te extraheren.

Detectietools

De studie maakte gebruik van een suite van zero-shot detectoren om inhoud te identificeren die waarschijnlijk door LLM's is gegenereerd:

• Voor Code: DetectCodeGPT (specifiek ontworpen voor code).
• Voor Commentaar: Binoculars, Log-Likelihood, Entropy, Rank, Log-Rank, LRR, DetectGPT, en Fast-DetectGPT.

Drempelwaarde Kalibratie

Vanwege het gebrek aan ground truth werden optimale beslissingsdrempels als volgt afgeleid:

• Code: De standaard drempelwaarden van DetectCodeGPT werden gebruikt, aangezien deze zijn geëvalueerd op developer-repositories.
• Commentaar: Drempelwaarden werden afgeleid van de AISE-dataset (gefilterd om alleen commentaar te bevatten uit bestanden die vóór 2021 zijn gewijzigd om menselijke tekst te benaderen). De Area Under the Receiver Operating Characteristic Curve (AUROC) werd gebruikt om drempelwaarden te bepalen die geschikt zijn voor het Software Engineering (SE) domein.

Analyseprocedures

1. Temporele Analyse: Het bijhouden van de proportie gedetecteerde door LLM gegenereerde inhoud over de tijd.
2. Categorisering: Een handmatig coderingsproces (met inter-rater betrouwbaarheidchecks) categoriseerde gedetecteerde code in logische groepen (bijv. Core logic, Tests, Interfaces) en commentaar in functionele groepen (bijv. Meta, Explanation, Type).
3. Clone Detectie: Gebruik van CCFinderX om intra-repository en inter-repository code clones te analyseren, evenals clones tegen de GPTCloneBench dataset.
4. Linguïstische Analyse: Evaluatie van commentaar op spelling, interpunctie, grammatica en de frequentie van AI-gerelateerde vocabulaire.
5. Bug Associatie: Mapping van door mensen gelabelde bugs uit de PreciseBugs dataset (specifiek NVD en OSS-Fuzz bronnen post-2021) om te zien of deze als door LLM gegenereerd werden gedetecteerd.

3. Belangrijkste Bijdragen

Het artikel levert drie primaire bijdragen:

1. Empirische Kwantificering: Het biedt een uitgebreide analyse van de proportie code en commentaar die waarschijnlijk door LLM's is gegenereerd over diverse repositories met behulp van een multi-detector framework, waarbij verschillende drempelwaarden voor commentaardenectie worden getest.
2. Vergelijkende Analyse: Het contrasteert door bedrijven onderhouden en door de community onderhouden repositories, wat duidelijke verschillen onthult in het volume en de kenmerken van de door LLM gegenereerde inhoud.
3. Bug Correlatie: Het is de eerste studie die de proportie door mensen gelabelde bugs in repositories analyseert die waarschijnlijk geassocieerd zijn met door LLM gegenereerde code, waarbij een verrassend lage correlatie wordt gevonden.

4. Belangrijkste Resultaten

RQ1: Temporele Trends en Categorisering

• Code: De proportie code die gedetecteerd is als waarschijnlijk door LLM gegenereerd, nam af over de tijd in de meerderheid van de repositories (50% vertoonde een afname). Deze inhoud werd voornamelijk gevonden in Test cases (bijv. 61,6% in Go-github, 67,5% in Pandas).
• Commentaar: De proportie commentaar die gedetecteerd is als waarschijnlijk door LLM gegenereerd, bleef relatief stabiel over de jaren. Deze commentaren werden primair gevonden in de categorieën Meta (auteurschap, licenties) en Explanation.

RQ2: Kenmerken van Gedetecteerde Inhoud

• Code Clones: Code gedetecteerd als waarschijnlijk door LLM gegenereerd vertoonde hoge percentages van intra-repository file-level clones (vaak >70%), maar lage percentages method-level clones. Cruciaal is dat zeer weinig van deze code clones vormde met de GPTCloneBench dataset, wat suggereert dat ontwikkelaars niet direct ruwe GPT-outputs plakken, maar ze eerder integreren of aanpassen.
• Commentaar Eigenschappen: Gedetecteerd commentaar vertoonde een hoge correctheid van interpunctie (~90%) maar een lage frequentie van grammaticaal correcte zinnen en een beperkt gebruik van AI-specifieke vocabulaire, wat contrasteert met sommige eerdere bevindingen over algemene LLM-tekst.

RQ3: Bedrijf vs. Community Repositories

• Volume: Door bedrijven onderhouden repositories vertoonden een hoger percentage van zowel code als commentaar gedetecteerd als waarschijnlijk door LLM gegenereerd vergeleken met door de community onderhouden repositories.
• Clones: Bedrijf-repositories vertoonden ook hogere percentages intra-repository file-level code clones.
• Distributie: In bedrijf-repositories was de gedetecteerde code zwaar geconcentreerd in Tests en Core Logic, terwijl community-repositories een meer verdeeld patroon vertoonden. Gedetecteerd commentaar in bedrijf-repositories was meer geconcentreerd in de Explanation en Meta categorieën.

RQ4: Associatie met Bugs

• Slechts een klein percentage van de door mensen gelabelde bugs werd gedetecteerd als waarschijnlijk door LLM gegenereerd: 10,79% van de NVD-dataset en 5,56% van de OSS-Fuzz-dataset.
• Dit suggereert dat hoewel LLM's code kunnen genereren, de resulterende bugs ofwel zeldzaam zijn, gecorrigeerd worden vóór de commit, of dat de detectoren specifer door LLM gegenereerde code specifiek niet identificeren.

5. Betekenis en Claims

De auteurs benadrukken dat hun bevindingen proxy-gebaseerde observaties zijn afgeleid van detector-outputs, en geen ground-truth metingen van daadwerkelijk LLM-gebruik. Ze stellen expliciet dat een hoge detectiegraad in de vroege jaren (2021–2023) niet geïnterpreteerd moet worden als definitief bewijs van wijdverbreide LLM-adoptie, maar eerder als baseline referentiepunten.

De studie benadrukt verschillende kritische inzichten:

• Strategisch Gebruik: De dalende trend in gedetecteerde codegeneratie kan erop wijzen dat ontwikkelaars LLM's strategischer gebruiken (bijv. voor code completion) of dat nieuwere modellen code produceren die ononderscheidbaar is van menselijk schrijven, waardoor de detectorgevoeligheid afneemt.
• Technologische Schuld Risico: De hoge prevalentie van intra-repository clones in gedetecteerde code suggereert een risico op technische schuld, wat de integratie van geautomatiseerde refactoring tools rechtvaardigt.
• Bug Mitigatie: De lage associatie tussen gedetecteerde LLM-inhoud en door mensen gelabelde bugs suggereert dat ontwikkelaars door LLM gegenereerde code effectief reviewen en aanpassen om defecten te verwijderen vóór de commit, of dat de specifieke bugs in de geanalyseerde datasets (security en runtime exceptions) niet de primaire faalmodus van LLM-generatie zijn.

Het artikel concludeert dat hoewel LLM's steeds meer aanwezig zijn in repositories, hun impact op codekwaliteit (in termen van bugs) schijnbaar wordt gemitigeerd door menselijke review, hoewel het potentieel voor technische schuld via code cloning een punt van zorg blijft. Toekomstig werk suggereert richtlijnen voor het reviewen van AI-ondersteunde inhoud, zoals het aanwijzen van specifieke testbestanden voor AI-ondersteunde review.