SWE-agent: Hoe interface-ontwerp geautomatiseerde software-engineering mogelijk maakt

Vorige week las ik de SWE-bench paper en daar hield ik een simpele conclusie aan over: standaard GPT-4 lost nauwelijks 1,96% van de echte GitHub-issues op. Deze week wilde ik de vervolgvraag begrijpen — wat zorgt er nou echt voor dat dit cijfer stijgt? SWE-agent door Yang et al. (NeurIPS 2024) geeft het antwoord, en dat antwoord is bedrieglijk saai: betere interfaces.

Het artikel

SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan en Ofir Press; Princeton / Stanford) introduceert het concept van een Agent-Computer Interface (ACI) — een speciaal gebouwde softwarelaag tussen een LLM en een Linux-omgeving, ontworpen niet voor menselijke gebruikers maar voor de manier waarop taalmodellen daadwerkelijk informatie verwerken. De stelling is dat het ontwerp van deze interface, en niet het onderliggende model, het primaire knelpunt is voor autonome software-engineering agents.

Het systeem werkt op GitHub-issues van SWE-bench: het leest de issue, navigeert door de repository, vindt de relevante code, bewerkt deze en voert tests uit om de fix te verifiëren. De vernieuwende bijdrage is niet een nieuw model of trainingsprocedure, maar een set zorgvuldig ontworpen commando-primitieven en feedbackformaten die de standaard Linux-shell vervangen.

Kernideeën

• Interface presteert 10,7 procentpunt beter dan de standaard shell. In een ablatie-studie over 300 SWE-bench Lite-instanties lost SWE-agent 10,7 procentpunt meer issues op dan een overigens identieke agent die in een kale Linux-shell wordt geplaatst. Dat is de grootste hefboom in het artikel.
• Bestandsviewer met vensters van 100 regels. In plaats van volledige bestanden te cat-en, toont de ACI ongeveer 100 regels per beurt met scroll-commando's. Te weinig context (30 regels) kost 3,7 procentpunt; te veel context (het hele bestand) zorgt ervoor dat het model de focus verliest. De 'sweet spot' is nauw.
• Een linter in de bewerkingscyclus. Elk bewerkingscommando voert een syntaxcontrole uit voordat de wijziging wordt doorgevoerd. Dit voorkomt dat het model vastloopt in staten met defecte code die lastig te herstellen zijn via alleen natuurlijke taal.
• Minimalistische zoekfunctie voor mappen. In plaats van grep -r met omliggende context (wat het model overweldigde), geeft de ACI alleen een lijst met overeenkomende bestandsnamen terug. Minder is meer wanneer het model moet beslissen waar het vervolgens moet kijken.
• Volledig benchmarkresultaat: 12,47% op SWE-bench met GPT-4 Turbo, vergeleken met een niet-interactief RAG-systeem van 3,8% en 1,96% voor de eenvoudige retrieval-baseline uit de oorspronkelijke SWE-bench paper. HumanEvalFix bereikte 87,7%.
• ACI-ontwerp is generaliseerbaar. Een cybersecurity-variant (SWE-agent EnIGMA) paste dezelfde ACI-filosofie toe op CTF-uitdagingen en behaalde 13,5% — drie keer sterker dan eerdere systemen — door gebruik te maken van interactieve agent-tools die gelijktijdige shell-sessies onderhouden.

Wat standhoudt — en wat niet

Het kerninzicht — dat interface-ontwerp voor agents even belangrijk is als prompt-engineering — wordt goed onderbouwd en ik vind het oprecht nuttig. De ablatie is eerlijk: de auteurs isoleren componenten en laten zien wat elk onderdeel bijdraagt. De winst van 10,7 procentpunt ten opzichte van de standaard shell-baseline is een helder resultaat dat niet verklaard kan worden door verschillen in modellen.

Waar ik minder van overtuigd ben: de benchmark zelf. De SWE-bench testset bevat issues die enorm variëren in complexiteit, ambiguïteit en de mate waarin de correcte patch gespecificeerd is. De hoge variantie in de kwaliteit van de issues betekent dat het cijfer van 12,47% deels een weerspiegeling is van welke issues toevallig in de evaluatieset terechtkwamen. De auteurs merken dit impliciet op door voor de ablaties resultaten te rapporteren op SWE-bench Lite (300 issues), maar de variantie binnen die subset is nog steeds hoog.

De grotere beperking is de reikwijdte: SWE-bench meet de oplossing van een enkel issue in isolatie. Er is geen sessiegeheugen over verschillende issues heen, geen begrip van de geschiedenis van de codebase en geen tracking van afhankelijkheden tussen meerdere issues. SWE-Bench Pro (arXiv:2509.16941, 2025) liet later zien dat zelfs grensverleggende modellen onder de 25% zakken wanneer issues gecoördineerde wijzigingen in meerdere bestanden vereisen — de prestaties nemen scherp af naarmate het aantal bestanden toeneemt. De ACI helpt binnen een enkel issue, maar het werkelijke probleem is de lange termijn, multi-bestand casus waarvoor SWE-agent nooit is ontworpen.

Er is ook een vraag over reproduceerbaarheid waar ik steeds bij terugkom: de keuzes in het interface-ontwerp (venster van 100 regels, minimalistische zoekoutput) zijn gevonden door iteratief experimenteren op de trainings/dev-split. Deze keuzes zijn niet vanzelfsprekend overdraagbaar naar nieuwe domeinen zonder vergelijkbare afstemming. Dat zijn reële kosten.

Waarom dit belangrijk is voor financiële AI

De ACI-benadering is direct te vertalen naar het ontwerpprobleem van een Beancount-agent. Een Beancount-grootboek is geen commandoregel, maar het is een gestructureerd artefact dat een model moet lezen, navigeren en beschrijven. De lessen zijn overdraagbaar:

• Een grootboekviewer die 20–50 transacties tegelijk toont — met scroll- en filtercommando's — zal beter presteren dan een viewer die 10 jaar aan gegevens in één keer dumpt. Overloop van het contextvenster is dezelfde foutmodus.
• Een schrijf-validator die het dubbel boekhoudkundig evenwicht en het bestaan van rekeningen controleert voordat een boeking wordt definitief gemaakt, is het grootboek-equivalent van de linter van SWE-agent. Zonder dit heeft een agent die een syntactisch onjuiste boeking produceert geen weg terug.
• Minimalistisch zoeken is cruciaal: het opvragen van "toon alle transacties op rekening X tussen data Y en Z" zou een compacte, scanbare lijst moeten opleveren, geen breedsprakige dump met omliggende context.

Het artikel stelt ook een praktische benchmark voor wat we kunnen verwachten van vroege versies van een Beancount write-back agent. Een oplossingspercentage van 12,47% op goed gedefinieerde GitHub-issues is het huidige plafond voor een zorgvuldig ontworpen agent voor enkelvoudige taken. Grootboek-write-back heeft een vergelijkbare taakstructuur — een gebruikersintentie, een gestructureerd bestand, een vereiste output, een verifieerder — en ik zou vergelijkbare percentages verwachten voor goed gedefinieerde taken, met een scherpe achteruitgang bij workflows die meerdere boekingen of rekeningen betreffen.

Wat je nu kunt lezen

• MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — Het contextbeheer van SWE-agent is reactief (afkappen bij overloop); MemGPT stelt proactief gelaagd geheugen voor, wat noodzakelijk lijkt voor agents die moeten redeneren over meerjarige Beancount-grootboeken.
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — Sluit direct aan op de punten waar SWE-agent tekortschiet; de data over prestatieverlies bij meerdere bestanden is essentiële kost voor het ontwerpen van write-back veiligheid in complexe grootboeken.
• Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — Als ACI gaat over interface-ontwerp, gaat Gorilla over API-retrieval; de twee samen vormen een completer beeld van hoe agents tools betrouwbaar moeten selecteren en aanroepen.