🤖 AI

The Order Is the Guarantee: Verifier-Budgeted Code Deletion with Static-First Learned Proposals

Dit artikel introduceert DELSCOUT, een framework dat de prioritering van volgorde van kandidaten voor codeverwijdering boven modelvertrouwen stelt om veilig redundante code te verwijderen onder eindige verificatiebudgetten, waarbij wordt aangetoond dat een hybride schema van statische en geleerde voorstellen het aantal geverifieerde verwijderingen maximaliseert terwijl gedragsbehoud wordt gewaarborgd door middel van executieautoriteit.

Oorspronkelijke auteurs: Ruitong Li, Binjie Guo, Aisheng Mo, Guowei Su, Han Wang, Jie Li, Ru Zhang

Gepubliceerd 2026-08-06

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Ruitong Li, Binjie Guo, Aisheng Mo, Guowei Su, Han Wang, Jie Li, Ru Zhang

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 of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

De Achtergrond: Wanneer AI te veel schrijft

Stel je voor dat je een enorm, ingewikkeld kasteel bouwt van LEGO-stenen. In het verleden moest je elke steen met de hand op zijn plek leggen, wat traag en zwaar werk was. Nu stel je je een supersnelle robot voor die in enkele seconden hele torens in elkaar kan klikken. Dit is wat moderne AI-coderingsmodellen doen: ze kunnen razendsnel werkende computerprogramma's schrijven, waarbij ze vaak menselijke experts bij het oplossen van puzzels evenaren of zelfs verslaan.

Maar hier zit de adder onder het gras: alleen omdat een robot snel een kasteel kan bouwen, betekent dat niet dat het kasteel netjes is. Als je een robot vraagt om "deze muur te repareren" of "een nieuwe deur toe te voegen", stapelt hij vaak gewoon nieuwe stenen bovenop de oude, zonder de kapotte of nutteloze stukken weg te halen. Na verloop van tijd wordt je kasteel een opgeblazen rommeltje van extra deuren, dubbele muren en verborgen vallen die niemand nodig heeft. In de wereld van software wordt dit "technische schuld" genoemd. Het maakt de code moeilener leesbaar, moeilijker te repareren en moeilijker te vertrouwen.

De grote vraag die dit artikel aanpakt is: Hoe leren we een AI om een goede editor te zijn, en niet alleen een goede bouwer? We weten hoe we een AI moeten vragen om code te schrijven, maar vragen een AI om code te verwijderen is gevaarlijk. Als de AI het verkeerde stuk verwijdert, kan het hele kasteel instorten. De uitdaging is om een manier te vinden waarop de AI kan voorstellen wat er weggegooid kan worden, terwijl er een strikt veiligheidssysteem is dat alleen verwijdering toestaat als het 100% zeker is dat het kasteel blijft staan.

Het Papier: De "Volgorde van Bewerkingen" voor het verwijderen van code

De onderzoekers achter dit papier, die hun systeem DelScout noemen, realiseerden zich dat het geheim van veilige codeverwijdering niet alleen gaat over hoe "slim" de AI is. Het gaat in plaats daarvan om de volgorde waarin de AI haar ideeën controleert.

Denk hierbij aan een beveiligingsbeambte in een museum die een beperkte hoeveelheid tijd heeft om schilderijen op vervalsingen te controleren. De beambte heeft een lijst met schilderijen om te inspecteren. Als ze eerst de meest waarschijnlijke vervalsingen controleren, kunnen ze een vervalsing snel ontdekken. Maar als ze eerst een saai, overduidelijk echt schilderij controleren, kunnen ze door de tijd heen zijn voordat ze bij het verdachte exemplaar komen. Het papier betoogt dat voor het verwijderen van code de planning (de volgorde van controle) belangrijker is dan de betrouwbaarheidsscore van de AI.

De Twee Strategieën: De "Mix" en het "Veiligheidsnet"

Het team testte twee verschillende manieren om de suggesties van de AI te organiseren, gebruikmakend van een "budget" van vijf controles (zoals het hebben van vijf kaartjes om vijf schilderijen te inspecteren).

De "Gevalideerde Mix" (De Slimme Wissel):
Als het team gegevens heeft van het specifieke type project waar ze aan werken, gebruiken ze een gemengde strategie. Ze houden de eerste drie controles voor "veilige weddenschappen"—eenvoudige, voor de hand liggende zaken zoals het verwijderen van ongebruikte imports of korte regels code waarvan een basiscomputerprogramma kan bewijzen dat ze nutteloos zijn. Vervolgens gebruiken ze de resterende twee slots voor de "geleerde" suggesties van de AI. Dit zijn de beste gissingen van de AI over complexe, lastige code die een basischecker niet kan begrijpen.
- Het Resultaat: In hun tests op een standaard coderingsbenchmark genaamd MBPP, maakte deze mix het mogelijk om 9,5% meer code succesvol te verwijderen dan wanneer ze alleen de basisveilige controles zouden gebruiken. Ze vonden gemiddeld 6,7 meer succesvolle verwijderingen, zonder dat er extra veiligheidscontroles nodig waren.
De "Prefix-Preserving Augmentation" (Het Veiligheidsnet):
Wat als de AI aan een totaal nieuw type project werkt waarbij ze geen historische gegevens hebben om op te vertrouwen? De onderzoekers realiseerden zich dat het vervangen van de "veilige weddenschappen" door AI-gissingen riskant is. Als de AI een fout maakt, kan ze een verwijdering missen die de basischecker wel zou hebben gevonden.
Daarom ontwierpen ze een "veiligheidsnet"-regel: Sla de veilige weddenschappen nooit over. Ze dwingen het systeem om eerst alle vijf de "veilige" suggesties te controleren. Pas als alle vijf die checks falen, krijgt het systeem de kans om zijn extra slots te gebruiken voor de chique gissingen van de AI.
- De Garantie: Dit zorgt ervoor dat het systeem nooit minder code verwijdert dan de basismethode zou hebben gedaan. Het kan meer verwijderingen vinden, maar het zal nooit een verwijdering missen die de basismethode had gevangen.
- De Kosten: Het nadeel is dat dit veiligheidsnet soms meer tijd kost. Afhankelijk van de test was het 4,8% tot 62,5% meer veiligheidscontroles (verifier calls) vereist, omdat het systeem eerst door de hele lijst van veilige weddenschappen moest lopen voordat het de ideeën van de AI probeerde.

Wat het Papier Uitsluit

De auteurs waren zeer zorgvuldig in het aantonen van wat niet werkt. Ze bewezen dat je niet simpelweg op de "betrouwbaarheidsscore" van de AI kunt vertrouwen om te beslissen wat te verwijderen. Zelfs als de AI zegt: "Ik ben voor 99% zeker dat deze regel nutteloos is," kan het nog steeds fout zijn als de testomgeving verandert.

Ze lieten ook zien dat het simpelweg trainen van de AI om "beter" te worden in het verwijderen van code het probleem niet oplost. Als je de "veilige" controles vervangt door "AI"-controles zonder veiligheidsnet, kan het systeem zelfs slechter presteren wanneer het geconfronteerd wordt met nieuwe, onbekende code. Het papier wijst het idee expliciet af dat een slimmer AI-model alleen de oplossing is; de oplossing is de structuur van hoe de AI en de veiligheidscontroles samenwerken.

De Kern van het Verhaal

Het papier concludeert dat de toekomst van AI-codering niet alleen gaat over het schrijven van meer code; het gaat over het schoonhouden van code. De beste aanpak is een taakverdeling:

De AI fungeert als een creatieve ontdekkingsreiziger die complexe, contextgevoelige verwijderingen voorstelt die mensen misschien missen.
De Volgorde fungeert als een verkeersregelaar die ervoor zorgt dat de AI de weg voor de saaie maar betrouwbare veiligheidscontroles niet blokkeert.
De Tests fungeren als de uiteindelijke rechter, die een verwijdering alleen toestaat als de code daadwerkelijk draait zonder vast te lopen.

In hun experimenten slaagde deze methode erin om overbodige code te verwijderen terwijl de software veilig bleef. De auteurs waarschuwen echter dat dit een hulpmiddel is voor onderhoud, geen toverstaf. Als de tests zelf zwak zijn of als de code iets cruciaals doet dat niet getest wordt (zoals een beveiligingscontrole), mag de AI dit niet verwijderen. Het doel is om software slank en begrijpelijk te houden, om er zeker van te zijn dat naarmate AI meer schrijft, onze digitale kastelen geen onbeheersbare jungles van ongebruikte stenen worden.

Technische Samenvatting: De Volgorde is de Garantie: Verifier-Budgetteerde Code-verwijdering met Static-First Learned Proposals

1. Probleemformulering

Het artikel behandelt het "inverse probleem" van AI-codering: in plaats van het genereren van nieuwe code, hoe moet een AI-systeem redundante code verwijderen wanneer de capaciteit voor uitvoering-verificatie eindig is? Terwijl frontier-modellen code kunnen genereren die benchmarks passeert, heeft "vibe coding" (iteratief prompten en patchen) de neiging om sneller redundante vertakkingen, guards en fallbacks te accumuleren dan dat verouderde logica wordt verwijderd. Dit creëert technische schuld die invarianten vertroebelt en het review-oppervlak vergroot.

De auteurs formuleren redundante-code-reductie als een voorstel-schedulingprobleem onder een eindig budget.

Input: Een programma $x$ en een verzameling syntactisch geldige single-statement AST-verwijderingskandidaten $C(x)$ .
Constraint: Een deterministische verifier $V$ (een executie-suite) kan slechts een beperkt aantal kandidaten evalueren (een budget $m$ ).
Doel: De kandidaten zodanig ordenen dat de eerste kandidaat $c_j$ die $V(x \setminus c_j)$ passeert, wordt gecommitteerd, waarbij het aantal geaccepteerde verwijderingen (coverage) en de hoeveelheid verwijderde code (karakterreductie) wordt gemaximaliseerd.
Kerninzicht: De volgorde van kandidaten is het controleoppervlak waarover een deployment kan redeneren, niet de betrouwbaarheidsscore van het model. Een foutieve verwijdering verwijdert stilletjes vereiste logica; daarom moet de executie-suite de vetorecht behouden.

2. Methodologie: DelScout

Het systeem, DelScout, scheidt de zoektocht (het voorstellen van kandidaten) van de acceptatie (het verifiëren van kandidaten). Het maakt gebruik van twee heterogene rankers:

Static Orders: Deterministische, parameterloze strategieën.
- Shortest-first: Sorteert op span-lengte, karakterlengte, dan positie. Effectief voor syntactische resten (ongebruikte imports, toewijzingen).
- Zero-reference: Geeft voorkeur aan statements met identifiers die het minst vaak in het bestand voorkomen.
Learned Ranker: Een sequentieclassifier getraind om te voorspellen of een verwijdering veilig is op basis van verifier-uitkomsten. Het gebruikt een prompt die de node-type, tekst en contextregels van de kandidaat bevat. Het trainingsdoel is listwise, waarbij de kansmassa wordt geoptimaliseerd die op geverifieerde verwijderingen nabij de voorkant van de lijst wordt geplaatst, in plaats van onafhankelijke classificatie.

Scheduling Strategieën

Het artikel stelt twee verschillende schedules voor om de afweging tussen statische garanties en learned search te beheren, afhankelijk van de beschikbaarheid van target-domein validatiedata:

Validated Mixture (Wanneer target-validatie bestaat):
- Wint een vast budget toe (bijv. 5 slots).
- Besteedt de eerste 3 slots aan de deterministische statische kern ( $S_3$ ).
- Besteedt de resterende 2 slots aan de hoogst gerangschikte learned kandidaten die niet in de statische kern zitten.
- Rationale: Empirische validatie staat toe de uitwisseling van statische slots voor learned ones te licentiëren om de coverage te vergroten.
Prefix-Preserving Augmentation (Wanneer target-validatie ontbreekt):
- Evalueert eerst de volledige statische ranking (bijv. alle 5 de statische slots).
- Voegt learned kandidaten alleen toe als alle statische kandidaten falen.
- Rationale: Dit zorgt ervoor dat een learned ranking nooit een statisch succes kan verdringen. Het biedt een niet-afnemende coverage-garantie door constructie, ongeacht distributieverschuiving, hoewel het hogere verifier-kosten kan meebrengen.

3. Belangrijkste Bijdragen

Formulering: Definieerde redundante-code-reductie als proposal scheduling onder een eindig uitvoering-verificatiebudget, waarbij de learned search en de acceptatiegrens duidelijk gescheiden zijn.
Scheduling Policies: Introduceerde een target-validated static–learned mixture en een prefix-preserving augmentation policy. De laatste garandeert niet-afnemende coverage en karakterreductie uitsluitend door kandidaat-ordening, zonder dat gekalibreerde modelscores nodig zijn.
Empirische Validatie: Rapporteerde negen replicaties over modelmaten (0.5B, 0.6B, 8B) op MBPP. De studie bevat objectieve controles om bevoorrechte trainingsverliezen, budgetboekhouding, cross-benchmark verschuiving analyse en tests tegen sterkere verifiers (MBPP+, HumanEval+) uit te sluiten.

4. Resultaten

Fixed-Budget Gains: Over negen runs op MBPP verbeterde de validated mixture de geverifieerde-verwijderings-coverage met 9.5% relatief (een toename van gemiddeld 6.7 geaccepteerde taken) vergeleken met een statische baseline, terwijl het iets minder verifier-oproepen verbruikte.
Complementariteit: De winst is architecturaal, niet te danken aan een specifief trainingsdoel. Statische voorstellen dekken "makkelijke" syntactische kandidaten (bijv. ongebruikte imports), terwijl learned voorstellen een andere orde bijdragen, waarbij ze focussen op contextuele control-flow kandidaten (bijv. conditionals, expressies) die statische analyse niet kan certificeren.
Efficiëntie: Geverifieerde verwijderingen per duizend verifier-oproepen nam toe met 19.5% (van 43.9 naar 52.5) omdat succesvolle voorstellen vaak eerder in de gemengde schedule verschijnen, waardoor de zoektocht eerder stopt.
Distributieverschuiving: Learned-only rankings zijn onbetrouwbaar onder verschuiving (bijv. prestaties dalen aanzienlijk op DS-1000 en BigCodeBench-Hard wanneer getraind op MBPP). Echter, prefix-preserving augmentation herstelde de niet-afnemende coverage op deze verschoven benchmarks, zij het met een kwantificeerbare toename in verifier-oproepen (variërend van 4.8% tot 62.5% overhead).
Sterkere Verifiers: Wanneer getest tegen MBPP+ (een striktere in-domain specificatie), verdween het voordeel van de mixtures; alle policies convergeerden naar dezelfde lage coverage (6.47%). Dit demonstreert dat scheduling de zoektocht beheert, maar de testsuite alleen bepaat wat "gedrag behouden" betekent.

5. Betekenis en Claims

Het artikel betoogt dat de volgende grens van AI-codering niet alleen het genereren van werkende programma's is, maar het onderhouden van begrijpelijke en minimale software.

Auditeerbare Taakverdeling: Het systeem vestigt een duidelijke scheiding waarbij modellen de zoektocht naar verwijderbare code verbreden, de volgorde de schade beperkt die een verkeerd gerangschikte voorstel kan aanrichten, en executie autoriteit behoudt over elke gecommitteerde verwijdering.
Orde als de Garantie: De centrale claim is dat de volgorde van kandidaten, niet de modelbetrouwbaarheid, de controleerbare variabele is. Door een statische prefix te behouden, garandeert het systeem dat learned modellen waarde kunnen toevoegen zonder gevestigde veiligheid te verminderen.
Beperkingen: De auteurs stellen expliciet dat de methode vertrouwt op benchmark-programma's, niet op echte wereld onderhoudshistorie, en dat de absolute winsten in coverage bescheiden zijn (een beweging van ~14% naar ~15% op MBPP). Ze benadrukken dat "geverifieerd" alleen betekent geverifieerd door de genoemde oracle; het systeem biedt geen semantische bewijzen en moet de menselijke review of veiligheidskritische checks niet vervangen.

Samenvattend demonstreert DelScout dat een gedisciplineerde schedulingstrategie — het combineren van deterministische statische analyse met context-gevoelige learned voorstellen onder een verifier-budget — effectief technische schuld in AI-gegenereerde code kan verminderen terwijl strikte veiligheidsgaranties worden gehandhaafd.