IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks
IDE-Bench führt ein umfassendes, dockerisiertes Evaluierungsframework ein, das 80 Aufgaben aus acht nie veröffentlichten Repositories umfasst, um die Fähigkeiten von KI-IDE-Agenten bei realen, mehrsprachigen Software-Engineering-Aufgaben durch eine strukturierte, IDE-native Tool-Schnittstelle zu bewerten.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie stellen einen neuen Junior-Entwickler für Ihr Softwareprojekt ein. Sie möchten wissen, ob er tatsächlich den Job erledigen kann: Fehler finden, neue Funktionen hinzufügen und kaputten Code reparieren, ohne dabei alles andere zu zerstören.
Lange Zeit haben wir KI-Coding-Assistenten getestet, indem wir ihnen ein einzelnes Rätsel in einem leeren Raum gaben. Aber echte Softwareentwicklung ist kein Rätsel in einem Raum; es ist wie die Arbeit in einer geschäftigen, hochtechnologischen Werkstatt voller Werkzeuge, Baupläne und anderer Arbeiter.
IDE-Bench ist eine neue „Werkstatt“, die darauf ausgelegt ist, KI-Modelle genau so zu testen, wie sie in der realen Welt eingesetzt werden. Hier ist die Aufschlüsselung dessen, was das Paper herausgefunden hat, unter Verwendung einfacher Analogien.
1. Der neue Test: Von „Bleistift und Papier“ zur „vollen Werkstatt“
Frühere Tests (wie SWE-Bench) waren so, als würde man einem Schüler eine Matheaufgabe auf einem Blatt Papier geben und ihn bitten, die Antwort aufzuschreiben. Er konnte keinen Taschenrechner benutzen oder Formeln nachschlagen; er musste die Antwort basierend auf dem, was er auswendig gelernt hatte, raten.
IDE-Bench ist anders. Es gibt der KI eine Dockerisierte Werkstatt (einen sicheren, isolierten digitalen Raum) und einen vollständigen Satz an Werkzeugen, genau wie die, die Entwickler in Apps wie Cursor oder Windsurf verwenden.
- Die Werkzeuge: Die KI kann den Code durchsuchen, Dateien lesen, Zeilen bearbeiten, Tests ausführen und sogar Datenbanken überprüfen.
- Das Ziel: Die KI muss wie ein echter Ingenieur agieren. Sie kann nicht einfach raten; sie muss explorieren, Änderungen vornehmen, prüfen, ob diese funktionieren, und Fehler korrigieren, falls sie etwas kaputt macht.
2. Die „Geheime Rezept“-Kochbücher
Um sicherzustellen, dass die KI nicht einfach nur Antworten aus dem Internet auswendig gelernt hat, haben die Forscher 80 brandneue Aufgaben in 8 geheimen Codebasen erstellt.
- Die Analogie: Stellen Sie sich einen Kochwettbewerb vor, bei dem die Jury 8 brandneue, noch nie dagewesene Rezepte erstellt. Die Teilnehmer (die KI-Modelle) müssen diese kochen. Da diese Rezepte noch nie im Internet veröffentlicht wurden, kann die KI nicht schummeln, indem sie die Lösung aus ihren Trainingsdaten nachschlägt.
- Die Vielfalt: Die Rezepte decken verschiedene „Küchenrichtungen“ (Programmiersprachen) ab: C/C++ (Systemprogrammierung), Java (Enterprise-Anwendungen) und MERN (moderne Web-Apps).
3. Die Ergebnisse: Wer ist der Master-Chef?
Die Forscher haben 15 verschiedene KI-Modelle getestet. Hier ist, was sie herausgefunden haben:
- Die Top-Schicht (Die Master-Chefs): Einige Modelle, angeführt von GPT-5.2, lösten etwa 95 % der Aufgaben. Sie waren wie Köche, die das Rezept lesen, die richtigen Werkzeuge greifen und das Gericht beim ersten Versuch perfekt zubereiten konnten.
- Die mittlere Schicht (Die kompetenten Köche): Modelle wie Claude Sonnet und Claude Haiku lösten etwa 85–88 % der Aufgaben. Sie sind sehr gut, aber sie benötigen vielleicht einen zweiten Versuch, um es perfekt zu machen.
- Die untere Schicht (Die Neulinge): Viele Open-Source-Modelle hatten Schwierigkeiten und lösten weniger als 50 % der Aufgaben. Sie verloren sich oft in der Werkstatt oder machten den Code kaputt, während sie versuchten, ihn zu reparieren.
4. Das „Fast-da“-Problem
Eine der interessantesten Erkenntnisse ist, dass Binär-Scores (Bestanden/Nicht bestanden) viel mehr Nuancen verbergen.
- Die Analogie: Stellen Sie sich vor, ein Schüler macht einen Test und beantwortet 11 von 12 Fragen richtig. In einem strengen Bewertungssystem erhält er ein „F“, weil er keine 100 % erreicht hat.
- Die Realität: In IDE-Bench bekamen viele Modelle den Kern des Codes richtig, scheiterten aber an winzigen Details, wie einem fehlenden Komma oder einem leicht falschen Format. Das Paper nennt dies „Near Misses“ (Beinahe-Erfolge).
- Die Lehre: Ein Modell kann zu 90 % bei einer Lösung sein, aber wenn es die winzigen Details übersieht, wertet der Test dies als totalen Fehlschlag. Dies deutet darauf hin, dass wir für den realen Einsatz den Code vielleicht nicht wegwerfen und neu anfangen müssen; wir müssten vielleicht nur einen Menschen bitten, die kleinen Formatierungsfehler zu korrigieren.
5. Effizienz vs. Gründlichkeit
Das Paper untersuchte auch, wie „teuer“ es für die KI war, eine Aufgabe zu lösen (gemessen in „Token“, oder Wörtern des Denkens).
- Schnell & Günstig: Einige Modelle (wie Grok 4.1 Fast) waren sehr effizient. Sie lösten Aufgaben schnell und verbrauchten weniger Ressourcen, scheiterten aber häufiger.
- Langsam & Gründlich: Andere Modelle (wie Claude Opus) brauchten sehr lange, lasen viele Dateien und dachten tief nach. Sie waren wahrscheinlicher erfolgreich, aber das kostete viel mehr an Zeit und Rechenleistung.
- Das Fazit: Es gibt nicht das eine „beste“ Modell. Wenn Sie Geschwindigkeit und niedrige Kosten wollen, wählen Sie einen Typ. Wenn Sie hohe Zuverlässigkeit benötigen und den Preis nicht so sehr stört, wählen Sie einen anderen.
6. Wie sie scheitern
Die Forscher kategorisierten, wie die KI-Modelle scheiterten, was vergleichbar mit einem Mechaniker ist, der diagnostiziert, warum ein Auto nicht anspringt:
- Vorzeitiges Editieren (63 % der Fehler): Die KI begann, den Code zu ändern, bevor sie überhaupt den Bauplan verstanden hatte. Es war, als würde man versuchen, einen Automotor zu reparieren, ohne vorher die Motorhaube zu öffnen.
- Thrashing (28 %): Die KI änderte dieselbe Datei immer wieder hin und her und machte ihre eigene Arbeit rückgängig – wie eine Person, die sich nicht entscheiden kann, welchen Weg sie nehmen soll, und immer wieder im Kreis läuft.
- Kontextverlust (27 %): Die KI vergaß mitten in der Aufgabe, was sie eigentlich tun sollte – wie ein Koch, der anfängt, einen Kuchen zu backen, aber dann vergisst, dass er eigentlich eine Pizza machen sollte.
Zusammenfassung
IDE-Bench beweist, dass die besten KI-Modelle nun in der Lage sind, wie echte Softwareentwickler in einer komplexen, werkzeugreichen Umgebung zu agieren. Es zeigt jedoch auch:
- Spezialisierung zählt: Einige Modelle sind großartig bei Web-Apps, aber schlecht bei Low-Level-Systemcode.
- Perfektion ist schwer: Zu 99 % fertig zu sein, ist häufig, aber das letzte 1 % (die winzigen Details) ist der Punkt, an dem die meisten Modelle scheitern.
- Strategie ist wichtig: Der beste Ansatz könnte sein, zuerst ein „schnelles“ Modell zu verwenden, und falls es scheitert, auf ein „gründliches“ Modell umzuschalten, um den Job zu vollenden.
Das Paper kommt zu dem Schluss, dass wir aufhören müssen, einen einzelnen „Score“ zu verwenden, um KI zu beurteilen, und stattdin darauf schauen müssen, wie sie arbeiten, worin sie gut sind und wie viel es kostet, die Aufgabe zu erledigen.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.