IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks
IDE-Bench introduceert een uitgebreid, gedockerd evaluatiekader met 80 taken verspreid over acht nog nooit eerder gepubliceerde repositories om de capaciteiten van AI-IDE-agenten in real-world, meertalige software engineering-taken te beoordelen via een gestructureerde, IDE-native toolinterface.
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
Stel je voor dat je een nieuwe junior developer aanneemt om aan je softwareproject te werken. Je wilt weten of ze het werk daadwerkelijk kunnen doen: bugs vinden, nieuwe functies toevoegen en kapotte code repareren zonder de rest van de boel te slopen.
Lange tijd hebben we AI-codeerassistenten getest door ze een enkele puzzel op te lossen in een lege kamer. Maar echte softwareontwikkeling is geen puzzel in een kamer; het is meer als werken in een drukke, hoogtechnologische werkplaats vol gereedschap, blauwdrukken en andere werknemers.
IDE-Bench is een nieuwe "werkplaats" die ontworpen is om AI-modellen te testen precies zoals ze in de echte wereld worden gebruikt. Hier is de uitsplitsing van wat het paper heeft gevonden, met behulp van eenvoudige analogieën.
1. De Nieuwe Test: Van "Potlood en Papier" naar "De Volledige Werkplaats"
Eerdere tests (zoals SWE-Bench) waren alsof je een student een wiskundeprobleem op een stuk papier gaf en vroeg om het antwoord op te schrijven. Ze konden geen rekenmachine gebruiken of formules opzoeken; ze moesten het antwoord raden op basis van wat ze uit hun hoofd hadden geleerd.
IDE-Bench is anders. Het geeft de AI een Dockerized werkplaats (een veilige, geïsoleerde digitale kamer) en een volledige set gereedschappen, precies zoals ontwikkelaars die gebruiken in apps zoals Cursor of Windsurf.
- De Gereedschappen: De AI kan de code doorzoeken, bestanden lezen, regels bewerken, tests draaien en zelfs databases controleren.
- Het Doel: De AI moet handelen als een echte engineer. De AI kan niet gewoon gokken; hij moet verkennen, wijzigingen aanbrengen, controleren of ze werken, en fouten herstellen als ze iets breken.
2. De "Geheime Recepten" Kookboeken
Om ervoor te zorgen dat de AI niet gewoon de antwoorden van het internet heeft onthouden, hebben de onderzoekers 80 gloednieuwe taken gemaakt over 8 geheime codebases.
- De Analogie: Stel je een kookwedstrijd voor waarbij de jury 8 gloednieuwe, nog nooit eerder vertoonde recepten maakt. De deelnemers (de AI-modellen) moeten deze bereiden. Omdat deze recepten nooit online zijn gepubliceerd, kan de AI niet valsspelen door de oplossing in zijn trainingsdata op te zoeken.
- De Variatie: De recepten dekken verschillende "keukens" (programmeertalen): C/C++ (systeemprogrammering), Java (enterprise apps) en MERN (moderne web apps).
3. De Resultaten: Wie is de Meesterkok?
De onderzoekers hebben 15 verschillende AI-modellen getest. Dit is wat ze vonden:
- De Toplaag (De Meesterkoks): Een paar modellen, aangevoerd door GPT-5.2, losten ongeveer 95% van de taken op. Ze waren als chefs die het recept konden lezen, de juiste tools konden pakken en het gerecht bij de eerste poging perfect konden bereiden.
- De Middelste Laag (De Bekwame Koks): Modellen zoals Claude Sonnet en Claude Haiku losten ongeveer 85–88% van de taken op. Ze zijn erg goed, maar ze hebben misschien een tweede poging nodig om het perfect te krijgen.
- De Onderlaag (De Novicen): Veel open-source modellen hadden moeite en losten minder dan 50% van de taken op. Ze raakten vaak verdwaald in de werkplaats of braken de code terwijl ze probeerden het te repareren.
4. Het "Bijna Gelukt" Probleem
Een van de meest interessante bevindingen is dat binaire scores (Geslaagd/Gezakt) veel nuance verbergen.
- De Analogie: Stel je voor dat een student een test maakt en 11 van de 12 vragen goed heeft. In een strikt beoordelingssysteem krijgt hij een "F" omdat hij niet 100% heeft gehaald.
- De Realiteit: In IDE-Bench kregen veel modellen de kern van de code goed, maar faalden ze door minuscule details, zoals een ontbrekende komma of een licht verkeerde opmaak. De paper noemt dit "near misses" (bijna gelukt).
- De Les: Een model kan voor 90% bij een oplossing zijn, maar als het de kleine details mist, markeert de test dit als een totale mislukking. Dit suggereert dat we voor echt wereldgebruik misschien niet de hele code weg moeten gooien en opnieuw moeten beginnen; we moeten misschien alleen een mens laten ingrijpen om de kleine opmaakfouten te herstellen.
5. Efficiëntie versus Grondigheid
Het paper keek ook naar hoe "duur" het was voor de AI om een taak op te lossen (gemeten in "tokens", of woorden van gedachten).
- Snel & Goedkoop: Sommige modellen (zoals Grok 4.1 Fast) waren zeer efficiënt. Ze losten taken snel op en gebruikten minder middelen, maar ze faalden vaker.
- Langzaam & Grondig: Andere modellen (zo zoals Claude Opus) namen veel tijd en lazen veel bestanden en dachten diep na. Ze hadden een grotere kans om te slagen, maar het kostte veel meer in termen van tijd en rekenkracht.
- De Les: Er is niet één enkel "beste" model. Als je snelheid en lage kosten wilt, kies je voor het ene type. Als je hoge betrouwbaarheid nodig hebt en het niet erg vindt, kies je voor het andere.
6. Hoe Ze Falen
De onderzoekers categoriseerden hoe de AI-modellen faalden, wat vergelijkbaar is met een monteur die probeert te diagnosticeren waarom een auto niet start:
- Voortijdige Bewerking (63% van de fouten): De AI begon de code te wijzigen voordat het de blauwdruk überhaupt begreep. Het was alsof je probeert een automotor te repareren zonder eerst de motorkap te openen.
- Thrashing (28%): De AI bleef hetzelfde bestand steeds weer aanpassen en ongedaan maken, waardoor het eigen werk ongedaan maakte, zoals iemand die niet kan beslissen welk pad hij moet nemen en steeds rondjes loopt.
- Contextverlies (27%): De AI vergat halverwege de taak wat het eigenlijk moest doen, zoals een chef die begint met het bakken van een cake maar vergeet dat hij eigenlijk een pizza moest maken.
Samenvatting
IDE-Bench bewijst dat de beste AI-modellen nu in staat zijn om te handelen als echte software engineers in een complexe, door gereedschap rijke omgeving. Het laat echter ook zien dat:
- Specialisatie ertoe doet: Sommige modellen zijn geweldig in web apps maar slecht in low-level systeemcode.
- Perfectie moeilijk is: Het bereiken van 99% is gebruikelijk, maar de laatste 1% (de kleine details) is waar de meeste modellen falen.
- Strategie ertoe doet: De beste aanpak is wellicht om eerst een "snel" model te gebruiken, en als dat faalt, over te schakelen naar een "grondig" model om de klus te klaren.
Het paper concludeert dat we moeten stoppen met het kijken naar een enkele "score" om AI te beoordelen en moeten beginnen met kijken naar hoe ze werken, waar ze goed in zijn en hoeveel het kost om de klus te klaren.
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.