Stel je voor dat je een meesterarchitect bent die jarenlang een prachtig, complex kasteel heeft ontworpen. Stel je nu voor dat je een superintelligente, razendsnelle robotassistent inhuurt om je te helpen het kasteel te renoveren. Je doel is niet om de manier waarop het kasteel werkt te veranderen — mensen moeten nog steeds van de keuken naar de slaapkamer kunnen zonder door de vloer te vallen — maar om de gangen breder te maken, de kamers lichter te maken en de structuur makkelijker te onderhouden. Dit is de wereld van code refactoring: het proces van het opschonen en reorganiseren van computercode om het beter te maken, zonder de software die het draait te breken.

Lange tijd hadden we tools die fungeerden als basis spellingcontrole voor code, die wezen op slordige opmaak of overduidelijke fouten. Maar onlangs is er een nieuw soort "robot" gearriveerd: Large Language Models (LLM's). Denk aan deze AI-assistenten als wezens die bijna elk boek, handboek en instructieblad ooit geschreven hebben gelezen. Ze zijn geweldig in het schrijven van nieuwe verhalen of het repareren van gebroken zinnen. Echter, wanneer je hen vraagt een complex kasteel te renoveren (een softwareproject), worden ze soms een beetje té creatief. Ze kunnen een muur verplaatsen die het dak ondersteunt, of een deur hernoemen op een manier die iedereen die de keuken probeert te vinden, in verwarring brengt. De grote vraag voor wetenschappers en ingenieurs is: kunnen we deze AI-robots vertrouwen om de renovatie veilig uit te voeren, of hebben ze een menselijke supervisor nodig om hun werk te controleren?

Dit is precies wat het artikel "RefactorAssist: Agentic Refinement for Reliable Code Refactoring" onderzoekt. De onderzoekers, Jonathan Cordeiro, Shayan Noei en Ying Zou, wilden zien of deze AI-robots code konden opknappen zonder het te breken, en of ze, als ze het wel braken, een slim "reparatie-agent" konden gebruiken om de fouten van de robot te herstellen.

De eerste poging van de robot: Een gemengd beeld

Het team begon door verschillende AI-modellen (waaronder enkele open-source modellen zoals StarCoder2 en krachtige commerciële modellen zoals GPT-4o) te vragen om renovaties uit te voeren op echte Java-softwareprojecten. Ze behandelden de software als een levend wezen met een ingebouwd "gezondheidscontrolesysteem" genaamd unit tests. Deze tests zijn als een reeks controlepunten: als de code correct is gewijzigd, slaagt de robot voor de test; als de robot per ongeluk een functie breekt, faalt de test.

De resultaten waren een schok. Zelfs de beste AI-modellen, zoals GPT-4o, slaagden er slechts in om de renovatie ongeveer 80,8% van de tijd goed uit te voeren. Dat betekent dat bijna 1 op de 5 keer de AI probeerde de code te verbeteren, maar per ongeluk iets brak, waardoor de software faalde voor zijn gezondheidscontroles. De onderzoekers ontdekten dat het simpelweg geven van meer voorbeelden van hoe je moet renoveren (een techniek genaamd "few-shot prompting") niet veel hielp. Het probleem was niet dat de AI niet wist hoe te renoveren; het was dat de AI de context niet goed genoeg begreep om subtiele, gevaarlijke fouten te vermijden.

Waarom faalden de robots?

Om te achterhalen wat er misging, gedroegen de onderzoekers zich als detectives die de "plaats van het misdrijf" van de gefaalde code onderzochten. Ze ontdekten dat de fouten van de AI in acht hoofdcategorieën vielen, waarbij de meest voorkomende waren:

1. Hallucinaties en contextverwarring (24,3%): De AI bedacht nieuwe functies of veranderde dingen die niet veranderd hoefden te worden omdat de AI het verhaal van de code verkeerd begreep.
2. Inconsistente hernoeming (15,3%): De AI hernoemde een variabele (zoals een "deur" een "poort" noemen) op één plek, maar vergat de naam overal anders bij te werken, waardoor de code in verwarring raakte.
3. Nieuwe zaken toevoegen (13,7%): De AI voegde per ongeluk nieuwe variabelen of functies toe die er niet hoorden te zijn.
4. Onvolledige code (11,3%): De AI stopte halverwege met het schrijven van de code, waardoor er stukken ontbraken.
5. Syntaxis- en structurele fouten (9,7%): Basisfouten zoals het vergeten van een sluitend haakje of een puntkomma.
6. Randgevallen (9%): De AI vergat zeldzame situaties af te handelen, zoals wat er gebeurt als een gebruiker nul invoert in plaats van een getal.
7. Typeafhandeling (8,7%): Het door elkaar halen van verschillende soorten gegevens, zoals proberen een tekstbericht in een getallenvak te plaatsen.
8. Scope-problemen (8%): Proberen een variabele te gebruiken op een plek waar deze niet bestaat.

Ontmoet RefactorAssist: De Super-Inspecteur

De onderzoekers realiseerden zich dat alleen de AI vragen om het opnieuw te proberen niet genoeg was. Ze hadden een systeem nodig dat deze fouten kon opvangen en automatisch kon herstellen. Dus bouwden ze RefactorAssist, een slimme "reparatie-agent" die fungeert als een kwaliteitscontroleur in twee fasen.

Fase 1: De snelle fix (Statische reparatie)
Voordat er zelfs maar wordt gevraagd aan de AI om opnieuw na te denken, voert RefactorAssist een snelle, op regels gebaseerde controle uit. Het is als een spellingcontrole die het verhaal niet hoeft te begrijpen, alleen de grammatica. Het herstelt overduidelijke zaken zoals ontbrekende imports, ongebalanceerde haakjes en eenvoudige typefouten. Deze stap is goedkoop en snel omdat het geen zware AI-hersenen gebruikt. Verrassend genoeg lost deze eenvoudige stap een groot deel van de problemen op, waardoor het succespercentage steeg van 66,1% naar 74,4% (en tot 80,3% in hun beste configuratie) door simpelweg de syntaxis op te schonen.

Fase 2: Het detectivewerk (Agentic reparatie)
Voor de resterende defecte code (de gevallen die na de snelle fix nog steeds faalden) schakelt RefactorAssist over naar de "agent-modus". Het verzamelt alle bewijslast: de foutmeldingen van de mislukte tests, de specifieke wijzigingen die de AI heeft aangebracht (de "diff") en de omliggende codecontext. Vervolgens vraagt het een krachtige AI (zoals GPT-4o) om als detective op te treden, uit te leggen waarom de code faalde en een oplossing voor te stellen. Deze detective raadt niet alleen; hij gebruikt het bewijs om de reparatie te leiden.

De resultaten van dit tweefasenproces waren indrukwekkend. Na de initiële AI-poging, de statische fix en vervolgens het iteratieve detectivewerk, steeg het succespercentage naar maar liefst 94,2%. Cruciaal was dat het systeem 70,8% van de fouten wist te herstellen die overbleven na de initiële statische fix-stap. Dit betekent dat voor de subset van renovaties die de AI verpestte en die de grammatica-check niet kon oplossen, de RefactorAssist-detective-agent het overgrote deel wist te herstellen, waardoor het totale succespercentage bijna perfect werd.

Wat werkte niet?

De onderzoekers testten ook enkele ideeën waarvan zij dachten dat ze zouden helpen, maar die minder nuttig bleken te zijn. Zo probeerden ze bijvoorbeeld een "retrieval"-systeem toe te voegen dat de hele project doorzocht voor extra context om de AI meer achtergrondinformatie te geven. Ho weliswaar een klein beetje hielp in de allereerste seconden van de reparatie, maar het hielp de AI niet echt om de moeilijkste problemen op de lange termijn op te lossen. Het artikel suggereert dat het hebben van een duidelijke, nauwkeurige uitleg van waarom iets kapot ging (de "diagnose") veel belangrijker is dan het hebben van een enorme hoeveelheid extra context.

De Conclusie

Dit artikel beweert niet dat AI al perfect zelfstandig code kan refactoren. Sterker nog, het bewijst dat AI zonder hulp in ongeveer 20% van de gevallen fouten maakt. Het laat echter zien dat door een eenvoudige, snelle "grammatica-check" te combineren met een slimme, op bewijs gebaseerde "detective-agent", we de meeste van die fouten kunnen herstellen.

De belangrijkste bevinding is dat RefactorAssist een rommelige, defecte AI-gegenereerde renovatie kan nemen en er een veilige, werkende code-update van kan maken met een succespercentage van 94,2%. Het suggereert dat de toekomst van software engineering niet alleen gaat over het hebben van een intelligentere AI, maar over het bouwen van een team waarbij de AI het zware werk doet en een gespecialiseerde reparatie-agent de fouten vangt voordat ze de gebruiker bereiken. Het is een herinnering dat zelfs superintelligente robots een goede kwaliteitscontrole-team nodig hebben om hun beste werk te leveren.