Technische Samenvatting: Prefactory – Geautomatiseerde Ontdekking en Toepassing van Library-Adoption Refactorings

Probleemstelling

Library-adoption refactoring houdt in dat handgeschreven code-implementaties worden vervangen door aanroepen naar bestaande library-API's. Deze praktijk vermindert de codeomvang, verbetert de idiomatische kwaliteit en maakt gebruik van goed geteste implementaties. Het automatiseren van dit proces is echter uitdagend omdat:

1. Gebrek aan Expliciete Aanwijzingen: De oorspronkelijke handgeschreven code vermeldt de doelbibliotheek of de specifieke API vaak niet, wat het voor tools die vertrouwen op importstatements of directe referenties moeilijk maakt om kansen te vinden.
2. Syntactische Variabiliteit: Ontwikkelaars implementeren dezelfde functionaliteit op diverse manieren (verschillende variabelenamen, control flows of hulpfuncties), wat betekent dat vaste syntactische patronen of linterregels vaak niet generaliseren.
3. Beperkingen van Bestaande Benaderingen:
   • Statische Tools: Linters en modernizers (bijv. Ruff, Pylint) zijn effectief voor slechts handmatig gespecificeerde, precieze patronen.
   • LLM Agents: Hoewel Large Language Models (LLM's) kunnen generaliseren naar diverse patronen, is het gebruik van hen om volledige codebases te scannen via herhaalde prompting kostbaar, moeilijk reproduceerbaar en lastig systematisch op schaal te controleren.

De kernbottleneck is detectie: het vinden van relevante codegebieden zonder expliciete bibliotheekvermeldingen en het generaliseren voorbij vaste templates, gevolgd door het genereren van een gedrag-behoudende vervanging.

Methodologie: De Prefactory Pipeline

Prefactory is een geautomatiseerde, vierfasige pipeline ontworpen om de semantische kennis van een LLM om te zetten in deterministische, herbruikbare zoekmechanismen. Het werkt op een doelproject en een doelbibliotheeknaam.

Fase 1: Detector Generatie

In plaats van een LLM te prompten om code direct te scannen, gebruikt Prefactory een LLM om uitvoerbare detectoren te synthetiseren.

• Input: Doelbibliotheek metadata (uit PyPI, documentatie en gemined voorbeelden van eerdere refactorings) en projectvocabulaire (veelvoorkomende namen uit het doelproject).
• Output: Twee families van detectoren:
  1. Lexicale Detectoren: Regular expressions die domeintermen, API-gerelateerde namen en tekstuele patronen matchen die geassocieerd zijn met handgeschreven implementaties.
  2. Structurele Detectoren: AST (Abstract Syntax Tree) matchers die algoritmische vormen identificeren (bijv. loops over waarden, rekenkundige indexberekening, accumulatie in datastructuren), ongeacht specifieke variabelenamen.
• Validatie: Gegenereerde detectoren worden gefilterd om te garanderen dat ze compileren, niet crashen en geen overmatig brede matches produceren (bijv. meer dan 20% van de bestanden matchen).

Fase 2: Project Scannen

Deze fase is deterministisch en LLM-vrij.

• Prefactory filtert niet-bronbestanden uit (bijv. vendored code, tests, documentatie).
• De gevalideerde lexicale en structurele detectoren worden uitgevoerd tegen de resterende bronbestanden.
• Matches worden geregistreerd, waarbij de specifieke detector matches die de flag triggerden, worden geïdentificeerd samen met de kandidaat-bestanden en functies.

Fase 3: Kandidaat Ranking en Filtering

Om de kosten van LLM's te beheersen, rankt Prefactory kandidaten en selecteert een kleine subset voor herschrijven.

• Ranking Metric: Een tuple $(D(c), B(c), -S(c))$ wordt berekend voor elke kandidaat $c$:
  • $D(c)$: Detector-match sterkte (gewogen som van matches, waarbij prioriteit wordt gegeven aan structurele matches).
  • $B(c)$: Dichtheid van basis Python-implementatiepatronen (loops, rekenkunde, branches) die op handgeschreven logica wijzen.
  • $S(c)$: Kandidaat grootte (kleiner is geprefereerd).
• Selectie: De top 5 bestanden worden geselecteerd, en binnen die worden de top 10 functies gekozen voor de volgende fase.

Fase 4: Refactoring Generatie en Validatie

• Generatie: Een LLM wordt geprompt met de kandidaat-functie, de omringende context, doelbibliotheek API hints, en de specifieke detector matches. Het probeert de functie te herschrijven met behulp van de doelbibliotheek.
• Relevantie Filtering: AST-gebaseerde controles zorgen ervoor dat de edit daadwerkelijk de doelbibliotheek aanroept en geen cosmetische wijziging is.
• Validatie:
  1. Differentieel Testen: Een LLM genereert een standalone testscript dat de originele en de gerefactoreerde functies vergelijkt op gegenereerde inputs (waarbij de originele als oracle dient). Als de test faalt, wordt de LLM gevraagd de edit te repareren (tot 3 pogingen).
  2. Project Tests: Als de differentiële tests slagen, wordt de gerefactoreerde code gerund tegen de bestaande testsuite van het project om regressies te voorkomen.

Belangrijkste Bijdragen

1. PrefactoryBench: Een benchmark van 100 real-world library-adoption refactorings uit 61 open-source Python-projecten en 18 bibliotheken. Het bevat referentie-executieomgevingen, projecttests en held-out tests om zowel detectie als transformatie te evalueren.
2. Prefactory Systeem: Een geautomatiseerde aanpak die herbruikbare, uitvoerbare detectoren (lexicaal en structureel) synthetiseert uit LLM-kennis, wat efficiënte, deterministische scanning mogelijk maakt zonder herhaalde LLM-aanroepen tijdens de zoekfase.
3. Empirisch Bewijs: Een gecontroleerde vergelijking die aantoont dat detector-synthese beter presteert dan directe LLM-prompting, agentic search, en rule-based tools in zowel detectie nauwkeurigheid als kostenefficiëntie.

Resultaten

Geëvalueerd op PrefactoryBench, bereikte Prefactory het volgende:

• Detectie: Detecteerde 75 instanties op bestandsniveau en 56 op functieniveau.
• Refactoring: Produceerde 40 gevalideerde refactorings (die zowel differentiële als projecttests doorstonden) uit de 56 gedetecteerde functies.
• Vergelijking: Presteerde beter dan de sterkste baseline, Codex CLI (die 35 bestanden en 32 functies detecteerde en 22 gevalideerde refactorings produceerde), evenals linters, vanilla LLM prompting, en Semgrep+LLM.
• Efficiëntie:
  • Scantijd: Gemiddeld van 1,3 seconden per project (LLM-vrij).
  • Kosten: De end-to-end kosten liggen onder de $0,05 per instantie, ongeveer een derde van de kosten van de Codex CLI baseline.
  • Herbruikbaarheid: Detectoren worden één keer gegenereerd per project-library paar en hergebruikt voor scanning, waardoor herhaalde scans goedkoop zijn.
• Real-World Toepassing: In een studie naar de huidige versies van vijf benchmark-projecten bracht Prefactory actieerbare kansen aan het licht, waarbij twee ingediende pull requests werden geaccepteerd door maintainers.

Betekenis en Claims

Het artikel claimt dat detector-synthese een praktische en schaalbare workflow is voor library-adoption refactoring. Door de semantische kennis van de LLM om te zetten in deterministische zoekmechanismen, vermijdt Prefactory de hoge kosten en reproduceerbaarheidsproblemen van directe agentic search.

De auteurs merken op dat de aanpak het meest effectief is wanneer library-kansen zowel vocabulaire als herkenbare implementatiestructuren blootleggen. Beperkingen blijven bestaan voor grote, heterogene bibliotheken (bijv. numpy, pandas) waar kansen zich over veel API-families verspreiden, en voor code met complexe I/O of gedistribueerd gedrag waar differentiële validatie moeilijk is. Het werk demonstreert dat het vastleggen van LLM-kennis in herbruikbare, uitvoerbare detectoren effectiever en goedkoper is dan het toepassen van LLM-redenering via herhaalde, brede queries.