Technische Samenvatting: SWE-INTERACT

Probleemstelling

Huidige benchmarks voor frontier software engineering (SWE) evalueren coding-agents primair op single-turn, autonome implementatietaken. In deze settings ontvangen agents volledige, goed gespecificeerde vereisten vooraf en worden ze geëvalueerd op hun vermogen om onafhankelijk een oplossing uit te voeren. Echter, grootschalige studies naar realistische interacties tussen ontwikkelaars en agents (bijv. SWE-chat) laten een scherp contrast zien: werkelijke workflows zijn zelden een 'one-shot' proces. In plaats daarvan bestaan ze uit iteratieve, multi-turn loops waarbij gebruikers vage of incomplete initiële instructies geven, de werkruimte van de agent inspecteren en vereisten progressief onthullen via gerichte feedback en revisies.

Bestaande benchmarks die proberen user-in-the-loop interacties te simuleren, versimpelen het probleem vaak door te beginnen met een redelijk gedetailleerde prompt of door gebruik te maken van statische, niet-agentische "gebruikers" die geen code kunnen inspecteren of commando's kunnen uitvoeren. Dit creëert een kloof tussen de prestaties in benchmarks en de realiteit van interactieve doelontdekking (goal discovery), waarbij agents intenties moeten afleiden, moeten adapteren aan evoluerende beperkingen en hun eigen eerdere werk moeten verfijnen zonder een volledige specificatie aan het begin.

Methodologie: SWE-INTERACT

De auteurs introduceren SWE-INTERACT, een nieuwe testomgeving ontworpen om SWE-benchmarks te herformuleren als door de gebruiker gestuurde, long-horizon codingsessies. De methodologie bestaat uit drie kerncomponenten:

1. Taakaanpassing

De auteurs hebben 75 taken aangepast van drie bestaande frontier benchmarks (SWE-bench Pro, SWE Atlas en DeepSWE). Dit waren oorspronkelijk single-turn taken met volledige specificaties. Deze zijn omgezet naar multi-turn taken door de initiële prompt te ontdoen van gedetailleerde vereisten, waardoor alleen een hoog niveau van een vage beschrijving overbleef.

2. De Gebruikerssimulator

Een cruciale innovatie is de persona-geconditioneerde gebruikerssimulator, gebaseerd op data uit echte codingsessies (SWE-chat).

• Persona: Gemodelleerd naar de "Expert Nitpicker" persona, gekenmerkt door korte, directe en iteratieve communicatie. Deze gebruiker schrijft geen code, maar bekritiseert implementaties, vraagt om specifieke API-details en onthult vereisten één voor één.
• Agentische Capaciteiten: In tegenstelling tot vorige statische simulators heeft deze user-agent shell-toegang tot de werkruimte van de agent. Het kan commando's uitvoeren (bijv. git, grep, sed) om diffs te inspecteren, de codebase te doorzoeken en het werk van de agent te verifiëren voordat er feedback wordt gegeven.
• Interactie-flow: De workflow volgt een GOAL-DISCOVERY → PLAN → APPROVAL → IMPLEMENT → REVISE → SUBMIT loop. De gebruiker begint met een vaag verzoek, beoordeelt het plan van de agent, inspecteert de werkruimte en brengt progressief latente vereisten naar boven totdat de volledige taak is overgedragen.

3. Evaluatieframework

Taken worden uitgevoerd in het Harbor framework met behulp van gecontaineriseerde sandboxes.

• Verificatie: Succes wordt bepaald door de originele taak-verifier (unit tests en rubrieken) van de bron-benchmarks, en niet door de goedkeuring van de gebruikerssimulator. Dit isoleert de moeilijkheid van de interactie van de moeilijkheid van de implementatie.
• Metrics: De studie houdt resolve rates, interactiestappen, tokenverbruik, kosten en specifieke foutmodi bij.

Belangrijkste Bijdragen

1. Een Nieuwe Testomgeving: Een suite van 75 multi-turn taken met een harness die statische benchmarks omzet in dynamische, door de gebruiker gestuurde workflows.
2. Agentische Gebruikerssimulator: Een framework voor het creëren van realistische user-agents die echt ontwikkelaarsgedrag emuleren, inclus\u00zaand werkruimte-inspectie en iteratieve kritiek, wat verder gaat dan statische API-aanroepen.
3. Uitgebreide Analyse: Een gedetailleerde uitsplitsing van de capaciteiten van agents in multi-turn settings, inclusief trajectanalyse, scoring van doelontdekking en categorisering van foutmodi.

Experimentele Resultaten

De auteurs hebben verschillende frontier modellen (GPT 5.5, Opus 4.8, Kimi K2.6, Gemini 3.5 Flash, Sonnet 4.6) geëvalueerd op zowel single-turn baselines als de nieuwe multi-turn SWE-INTERACT taken.

Prestatiekloof

• Resolve Rates: Sterke single-turn prestaties vertalen zich niet betrouwbaar naar multi-turn settings. Terwijl topmodellen ongeveer 50% resolve rates behaalden op single-turn baselines, daalde dit naar ongeveer 25–27% in de multi-turn setting.
• Resourceverbruik: Multi-turn taken vereisten aanzienlijk meer middelen. Agents namen 3–4 keer meer stappen, gebruikten 2–4 keer meer tokens en veroorzaakten 2–3,5 keer hogere kosten per trial vergeleken met single-turn baselines.
• Modelvariantie:
  • Top Performers: GPT 5.5 en Opus 4.8 begonnen sterk, zelfs met vage instructies, hielden stand bij ambiguïteit en integreerden vereisten goed, hoewel ze nog steeds leden onder technische bugs en vergeten vereisten.
  • Zwakker Modellen: Modellen zoals Kimi K2.6 en Sonnet 4.6 hadden grote moeite met ambiguïteit en gaven vaak vroegtijdig op, negeerden instructies of faalden in het effectief verfijnen van code.

Doelontdekking versus Implementatie

• Planning: Sterke modellen (bijv. GPT 5.5) identificeerden vaak een hoog percentage (>80%) van de latente doelen tijdens de initiële planningsfase.
• Implementatie-daling: Er was een significante daling in doeldekking (goal coverage) bij de overgang van het plan naar het eerste implementatie-checkpoint, vaak door technische fouten of gemiste specificaties.
• Herstel: De meeste modellen herstelden de doeldekking over opeenvolgende turns naarmate de gebruiker gemiste vereisten onthulde, maar de uiteindelijke implementatie faalde vaak nog steeds voor de verifier door technische bugs of regressies.

Foutmodi

Een audit van 287 gefaalerde trajecten onthulde de primaire oorzaken van falen:

• Technische Implementatie Bugs (~34%): De agent begreep de vereiste, maar introduceerde codefouten.
• Vergeten Vereisten (~34%): De agent slaagde er niet in een vereiste te implementeren die in een eerdere turn was geïntroduceerd.
• Misinterpretatie/Slechte Aannames (~14%): De agent begreep de vereiste verkeerd of maakte onjuiste aannames zonder verduidelijking te vragen.
• Ontbrekende Gebruikersvereisten (~12%): Casussen waarin de simulator er niet in slaagde een noodzakelijke vereiste naar boven te brengen (benchmark false negatives).

Ablatie-studies

• Impact van Persona: Het gebruik van de "Expert Nitpicker" persona (versus een neutrale baseline) maakte taken moeilijker en langer, wat de interactiestappen met 30–50% verhoogde en de resolve rates voor de meeste modellen verlaagde, wat het gat tussen geïdealiseerde en realistische interacties benadrukt.
• Simulator Model: De keuze van het gebruikersmodel (GPT 5.5 versus Opus 4.7) beïnvloedde de realiteitszin aanzienlijk. GPT 5.5 fungeerde als een strengere criticus, onthulde vereisten over meer turns en inspecteerde de werkruimte dieper, wat leidde tot betere uiteindelijke agent-prestaties maar langere trajecten.

Betekenis en Claims

Het paper claimt dat SWE-INTERACT een orthogonale capaciteitsas meet voor de ontwikkeling van frontier modellen: interactieve doelontdekking en iteratieve verfijning met een gebruiker in de loop.

De auteurs stellen dat effectief samenwerken met een gebruiker niet louter een langere versie is van autonoom coderen, maar een distinct vaardighedenpakket. De resultaten suggereren dat hoewel frontier modellen kunnen volharden onder ambiguïteit en de meeste beoogde doelen kunnen herstellen door revisie, ze nog steeds moeite hebben met het handhaven van correcte implementaties naarmate de feedback zich ophoopt. Het paper positioneert SWE-INTERACT als een scherper instrument voor het bestuderen van deze specifieke capaciteit, met als doel de ontwikkeling van coding-agents te sturen die betrouwbaarder kunnen samenwerken in realistische software engineering workflows.