What Context Does a Coding Agent Actually Need to Act?
Dit artikel toont aan dat voor coderingsagenten die code bewerken, de essentiële context strikt beperkt is tot de specifieke bestanden die worden gewijzigd, aangezien natuurlijke taal-samenvattingen en de omliggende inhoud van bestanden een verwaarloosbare bijdrage leveren aan het oplossen van problemen vergeleken met de broncode zelf, terwijl het ook een significante ruisvloer in benchmarkresultaten onthult die wordt veroorzaakt door niet-deterministische API-inferentie.
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 door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een lekkende kraan probeert te repareren in een enorme wolkenkrabber van 100 verdiepingen. Je hoeft niet de blauwdrukken van het hele gebouw te lezen, het menu van de cafetaria of de beveiligingslogs om de moersleutel te vinden. Je moet alleen precies weten welke leiding er lekt en de directe omgeving ervan kunnen zien.
Dat is de verrassende les uit dit nieuwe onderzoek naar "coding agents"—de AI-bots die software schrijven en repareren. Lange tijd nam de techwereld aan dat deze bots de volledige codebase van een project (soms miljoenen regels) in hun "brein" moesten opslokken om hun werk te doen. De gedachte was: "Meer context is altijd beter."
Maar dit paper zegt: Stop met het volproppen van het brein. Het blijkt dat de AI voor de daadwerkelijke handeling van het repareren van code bijna niets nodig heeft, behalve de specifieke regels die hij op het punt staat te veranderen.
Het "Vinden" versus het "Handelen"
De onderzoekers splitsen het probleem op in twee delen:
- Het Vinden: Het lokaliseren van de kapotte code.
- Het Handelen: Het daadwerkelijk repareren zodra je de code hebt gevonden.
Om dit te testen, gebruikten ze een "magische kaart" (een oracle) om de AI precies te vertellen waar de kapotte code zat. Dit betekende dat de AI niet hoefde te gokken waar hij moest zoeken; hij hoefde zich alleen maar te concentreren op hoe hij de fout moest herstellen. Vervolgens gaven ze de AI verschillende "weergaven" van die code om te zien wat het beste werkte.
De Grote Teleurstelling: Samenvattingen Werken Niet
Een populair idee was: "Laten we de AI gewoon een samenvatting in natuurlijke taal geven van de code, zoals een achterflap van een boek."
- De Test: Ze vroegen de AI om lastige vragen over hoe de code zich gedraagt te beantwoorden, waarbij ze ofwel de volledige broncode gebruikten, of een samenvatting geschreven door een super-slimme AI (een "frontier model").
- De Resultaat: De volledige broncode kreeg 27 van de 45 vragen goed. De samenvattingen? Die kregen er slechts 4 van de 45 goed.
- De Twist: Het maakte niet uit of de samenvatting werd geschreven door de slimste AI ter wereld of door een piepklein, basis model. Ze faalden beide even erg. Het probleem was niet de schrijver; het probleem was het formaat. Een samenvatting kan simpelweg niet de specifieke "gedetailleerde informatie" over het gedrag dragen die nodig is om een bug te repareren. Het is alsoer een automotor te proberen te repareren door een reisbrochure over de auto te lezen; de brochure is leuk, maar het vertelt je niet welke bout loszit.
Het "Skelet" versus het "Volledige Lichaam"
Vervolgens testten ze of de AI het volledige, vlezige lichaam van de code nodig had, of alleen het "skelet" (de structuur, zoals functienamen en signatures).
- De Opzet: Ze namen 70 echte programmeerproblemen. Voor sommige gaven ze de AI de volledige bestanden. Voor andere gaven ze alleen het "skelet" (UML-diagrammen en signatures) of een "keep/drop"-versie (waarbij alleen de essentiële onderdelen werden behouden en de rest werd verwijderd).
- Het Resultaat: De "skelet"-versies en de "keep/drop"-versies losten net zoveel problemen op als de volledige bestanden. Sterker nog, de "keep/drop"-methode loste iets meer problemen op (25 van de 70) dan de volledige bestanden (19 van de 70), hoewel het verschil klein genoeg was om op toeval te kunnen wijzen.
- De Kosten: Hier komt de klap. Het oplossen van een probleem met de volledige bestanden kostte de AI 94.000 tokens (een eenheid tekst). Het oplossen van het probleem met de gecomprimeerde "keep/drop"-methode kostte slechts 19.000 tokens. Dat is een enorme besparing—ongeveer 3 tot 3,7 keer goedkoper—zonder verlies in prestaties.
De Waarschuwing voor "Ruis"
De onderzoekers ontdekten ook iets vreemds en belangrijks: zelfs wanneer ze exact dezelfde test uitvoerden met exact dezelfde instellingen, gaf de AI soms andere antwoorden. Ongeveer 9% van de tijd sloeg de uitkomst om tussen opeenvolgende runs. Dit betekent dat als je een klein verschil ziet tussen twee methoden (zoals een verbetering van 2%), dit gewoon willekeurige ruis kan zijn en geen echte doorbraak.
De Kern van de Zaak
Het paper concludeert dat voor de specifieke taak van het repareren van code, minder meer is.
- Wat werkt: De AI de exacte regels code geven die hij moet bewerken, gestript tot hun essentie.
- Wat niet werkt: De AI overladen met samenvattingen, volledige bestandsgeschiedenissen of complexe structurele diagrammen.
- Het Oordeel: De "signaalwaarde" zit in de code zelf, niet in het verhaal dat we over de code vertellen. Door de franje weg te snijden, kunnen we bugs repareren voor een fractie van de kosten, zonder dat we de hele wolkenkrabber hoeven te lezen om één lekkende kraan te maken.
De auteurs benadrukken voorzichtig dat dit geldt voor "single-shot" fixes (waarbij de AI het één keer probeert en niet opnieuw mag lezen of om hulp kan vragen). Maar voor dat specifieke, cruciale moment van bewerking, is de data duidelijk: je hebt niet de hele bibliotheek nodig; je hebt alleen de juiste pagina nodig.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.