Technisch Overzicht: Agentische Generatie van AST-transformatie-regels voor het Herstellen van Breaking Updates

Probleemstelling

Moderne softwaresystemen vertrouwen zwaar op third-party bibliotheken die worden beheerd via pakketbeheerders (bijv. Maven, npm). Deze bibliotheken evolueren continu, wat vaak leidt tot breaking dependency updates die methoden verwijderen, handtekeningen wijzigen of types verplaatsen, waardoor de compilatie van cliëntprojecten faalt. Hoewel tools zoals Dependabot en Renovate de stap van versie-updates automatiseren, herstellen zij niet de resulterende compilatiefouten.

Bestaande geautomatiseerde reparatiebenaderingen genereren doorgaans projectspecifieke code-patches. Wanneer dezelfde bibliotheek-update meerdere projecten breekt, moeten deze benaderingen elk project onafhankelijk repareren, wat resulteert in niet-herbruikbare patches. Dit beperkt de schaalbaarheid, aangezien de onderliggende reparatielogica (de conceptuele fix voor de API-wijziging) identiek is voor alle getroffen cliënten, terwijl huidige tools er niet in slagen deze logica te vangen en over te dragen.

Methodologie: Het BIGBAG-framework

De auteurs presenteren BIGBAG, een agentisch framework dat is ontworpen voor het genereren van fixing transformations: gestructureerde, op zichzelf staande, uitvoerbare programma's die de reparatielogica op API-niveau coderen. In tegenstelling tot projectspecifieke patches, kan een enkele fixing transformation die is afgeleid van één cliënt, worden toegepast op elke andere cliënt die door dezelfde dependency update is getroffen.

Kernworkflow

BIGBAG werkt via een vierstaps agentische workflow:

1. Input Context Assemblage: De agent ontvangt:
   • Het cliëntproject met een defecte build (geïdentificeerd via mvn compile logs).
   • Documentatie voor de geselecteerde AST-transformatie-engine (Spoon of JavaParser).
   • Een transformatie-template (een Maven-project skelet).
   • De API-specificatie en Javadoc van de nieuwe dependency (om de juiste vervangende handtekeningen te identificeren).
2. Transformatie Generatie en Applicatie: De agent voert een generate-apply-verify loop uit:
   • De agent analyseert compilerfouten en bronbestanden om incompatibele API-gebruikspunten te lokaliseren.
   • De agent genereert een op zichzelf staand Java-programma (de transformatie) dat de Abstract Syntax Tree (AST) van de cliënt doorloopt, de getroffen nodes identificeert en deze herschrijft om te voldoen aan de nieuwe API.
   • De agent compileert en voert de transformatie uit tegen de cliënt. Als de build faalt, gebruikt de agent de feedback om de transformatie te herzien.
3. Verificatie: BIGBAG verifieert dat de gegenereerde transformatie, wanneer deze in isolatie wordt toegepast, de compilatiefout oplost. Dit zorgt ervoor dat de transformatie zelf de oorzaak van de fix is, en niet incidentele wijzigingen gemaakt door de agent.
4. Generalisatie (Transfer): Geverifieerde transformaties worden toegepast op andere cliëntprojecten die door dezelfde breaking update zijn getroffen om de cross-project transferbaarheid te beoordelen.

Technische Componenten

• Coding Agents: Het systeem maakt gebruik van frontier Large Language Models (LLMs) geïntegreerd met coding-agent scaffolds (OpenCode, GeminiCLI) die beschikken over file-system en shell-execution capaciteiten.
• AST Transformatie Engines: De studie vergelijkt twee engines:
  • Spoon: Biedt een volledig opgelost type-model en een Processor<T> abstractie, wat semantische rijkdom biedt maar meer scaffolding vereist.
  • JavaParser: Biedt een lichtere Visitor API met minder semantische garanties maar een eenvoudigere syntaxis voor structurele wijzigingen.
• Modellen: Vier modellen werden geëvalueerd: GPT-5.4-mini, Qwen3-30B, DeepSeek-v3.2, en Gemini-3.1-Pro.

Experimentele Evaluatie

De auteurs evalueerden BIGBAG op 157 real-world breaking dependency updates uit de BUMP benchmark, die 69 cliëntprojecten en 70 third-party bibliotheken beslaat. De updates verspreidden zich over PATCH, MINOR en MAJOR semantische versieniveaus.

Belangrijkste Resultaten

De evaluatie richtte zich op drie Onderzoeksvragen (RQs):

RQ1: Transformatie Welgevormdheid

• Metric: Compilable Rule Rate (CRR) – het percentage executies dat een geldige, compileerbare AST-transformatie produceert.
• Bevindingen: De beste configuratie (OpenCode/DeepSeek-v3.2/JavaParser) bereikte een CRR van 94,3%. De laagste was 50,3%.
• Impact van de Engine: De keuze van de AST-engine was een primaire determinant voor succes. JavaParser leverde consistent hogere CRRs op dan Spoon (tot 17,8% verschil) vanwege de eenvoudigere API, wat "Transformation Bypass" (waarbij agents de AST-library vermijden) verminderde.

RQ2: Transformatie Effectiviteit

• Metric: Fix Rate (FR) – het percentage compileerbare transformaties dat de cliënt effectief repareert (build slaagt en tests slagen).
• Bevindingen: De beste configuratie (GeminiCLI/Gemini-3.1-Pro/JavaParser) bereikte een Fix Rate van 78,6%.
• Foutmodi: De dominante foutmodus was Client Compilation Failure (48–88% van de fouten), waarbij de transformatie wel compileerde maar de onderliggende code niet wist te repareren (bijv. door de verkeerde constructen te targeten).
• Observatie: Hoewel Spoon meer semantische diepte bood, leidde de complexiteit ervan tot meer runtime-fouten (Rule Execution Errors). De eenvoud van JavaParser correleerde met een hogere reparatiesucces.

RQ3: Transformatie Generaliseerbaarheid

• Metric: Cross-Project Fix Rate – het percentage externe projecten dat wordt gerepareerd door een transformatie die is gegenereerd voor een seed-project.
• Bevindingen: De algemene cross-project fix rate was 33,3% (43 van de 129 getargete projecten).
• Uniformiteit: Succes bij transfer was sterk afhankelijk van de uniformiteit van het gebruik. Voor breaking updates waarbij alle cliënten het getroffen API-element uniform aanriepen (bijv. eenvoudige package renames), lag de fix rate boven de 80%. Falen trad vaak op omdat de agent alleen de gebruiksmodellen leerde die zichtbaar waren in het enkele seed-project, waardoor variaties in andere cliënten werden gemist.

Belangrijkste Bijdragen

1. BIGBAG Framework: De eerste benadering die herbruikbare, uitvoerbare AST-transformaties genereert voor het herstellen van breaking dependency updates, waarmee verder wordt gegaan dan projectspecifieke patches.
2. Empirische Studie: Een systematische evaluatie over 157 breaking updates, acht (model, engine) configuraties en drie semantische versieniveaus, die de haalbaarheid van agentische reparatie aantoont.
3. Foutkarakterisering: Een gedetailleerde analyse die aantoont dat:
   • De keuze van de AST Engine een eerste-orde determinant van succes is (JavaParser presteerde beter dan Spoon in deze context).
   • Gebruiksuniformiteit de cruciale factor is voor cross-project transferbaarheid.
   • Compilatiesucces gecorreleerd is met de complexiteit van de API van de transformatie-engine.

Betekenis en Claims

Het artikel claimt dat agentische generatie van herbruikbare fixing-transformaties een levensvatbare benadering is voor de schaalbare reparatie van breaking updates.

• Schaalbaarheid: Door een enkele transformatie te genereren die op alle getroffen cliënten kan worden toegepast, pakt BIGBAG de schaalbaarheidsbottleneck aan bij het repareren van dependency updates in grote ecosystemen.
• Engine Sensitiviteit: Het werk levert het eerste bewijs dat de keuze van de AST-transformatie-engine de reparatiesucces significant beïnvloedt, wat suggereert dat eenvoudigere API's effectiever kunnen zijn voor LLM-gebaseerde synthese in dit domein.
• Beperkingen: De auteurs merken nederig op dat de transferbaarheid beperkt wordt door de "single-project seed"-benadering. Als een cliënt de gebroken API op een manier gebruikt die niet in het seed-project voorkomt, kan de transformatie falen. Zij stellen voor om toekomstig werk te richten op multi-project seeding om bredere gebruiksmodellen te vangen.

De studie concludeert dat hoewel huidige agents betrouwbaar compileerbare transformaties kunnen genereren en een meerderheid van de updates binnen een enkel project kunnen herstellen, het bereiken van een hoge cross-project transferbaarheid vereist dat de diversiteit aan API-gebruikspatronen in het ecosysteem wordt aangepakt.