Warum Programmieragenten immer noch Schwierigkeiten mit dem Code privater Unternehmen haben
Real-SWE testet acht Programmieragenten an lizenzierten privaten Codebasen. Der beste Agent löst 38,8 Prozent der Fälle, und die fünf Fehlerkategorien zeigen auf, wo die Agenten Fehler machen.
Quellen: Coding Agents Still Struggle With Private Company Code
Öffentliche Programmier-Benchmarks prüfen nützliche Fähigkeiten, sagen aber wenig darüber aus, was in den privaten Produktionscodes eines Unternehmens vor sich geht. Ein Benchmark namens Real-SWE versucht diese zweite Art von Test. Seine Entwickler, ein kleines von Y Combinator unterstütztes Startup namens Specific Labs, erhielten Lizenzen für private Codes echter Unternehmen, extrahierten zehn Aufgaben, die dortige Ingenieure bereits erledigt hatten, und gaben diese Aufgaben an acht Programmier-Assistenten weiter. Der Beste schaffte 38,8 Prozent.
Eine Aufgabe beginnt mit einer Rechnungsstellungskrise: Die vom Service ausgestellten Rechnungen enthalten überhaupt keine Steuern, und die Rechnungsstellung soll am Montag wieder aufgenommen werden. Insgesamt unternahmen alle Assistenten sechzigvier Versuche, wobei zwei erfolgreich waren. Diese Aufgabe wird „Steuerhoheit“ genannt und ist eine der zehn.
Warum dieser Code verborgen bleibt
Die Gründer veröffentlichten den Benchmark kürzlich, und er erreichte die Startseite von Hacker News mit einigen Hundert Punkten sowie weit über hundert Kommentaren. Real-SWE bewertet acht Kombinationen aus Modell und Agent auf zehn Aufgaben, wobei pro Aufgabe acht Versuche unternommen werden. Das ergibt insgesamt 640 bewertete Durchläufe, wobei der Gesamtscore den Anteil der erfolgreichen Versuche darstellt.
Die zugrunde liegenden Projekte wirken wie gewöhnliche kommerzielle Software: eine App für Verbraucherereignisse mit mehr als 200.000 Nutzern und einem Platz in den Top 100 des App Stores, ein Fintech-Produkt, das bereits mehr als 100.000 Bankauszüge verarbeitet hat, sowie eine Vertriebsplattform für Unternehmen. Die Agenten erhalten Docker und Kubernetes, drei Datenbanken (Postgres, MySQL, MongoDB), Redis, GitHub sowie einen emulierten Amazon-Cloud-Service – wobei jede Aufgabe nur die Dienste freigibt, die ihr eigener Workflow benötigt.
In einigen Umgebungen werden Slack, Intercom, Google Drive, ClickUp sowie ein Linear MCP-Server hinzugefügt, der es einem Agenten ermöglicht, Tickets direkt aus Linear zu lesen. Wenn Details nicht in das Ticket aufgenommen wurden, muss der Agent sie aus einem Thread oder einer Datei herausfinden – genauso wie es ein eigener Ingenieur des Teams tun würde.
Allein die Steuerabwicklung erfolgt über einen NestJS-Dienst in TypeScript, zwei Instanzen derselben externen Steuerbehörde (eine Testumgebung sowie das Live-System zur tatsächlichen Anmeldung) sowie ein InfluxDB-Register, in dem abgeschlossene Verkäufe erfasst werden.
Die Aufgaben verwenden das Harbor-Format, und die Überprüfung bleibt bis zum Bewertungszeitpunkt verborgen. Dadurch soll verhindert werden, dass Agenten sich auf offensichtliche Tests statt auf die tatsächlichen Anforderungen ausrichten. Die Überprüfer stammen aus Testpaketen, die diese Unternehmen bereits durchführen – in einigen Fällen wortwörtlich.
Die Autoren erklären ihren Antrieb mit einer auffälligen Behauptung: 99 Prozent der Tokens in echten Unternehmen seien vor Frontier-Modellen verborgen. Da diese Aufgaben aus privatem Softwarecode stammen und nicht aus öffentlichen GitHub-Projekten, konnten die Modelle während des Trainings weder den Code noch seine Geheimnisse sehen.
Die eigenen Zahlen des Benchmarks zeigen eine mittlere Anzahl an Anweisungen von 1.742 Zeichen, was kürzer ist als bei FrontierCode (2.056) oder DeepSWE (1.975). Dennoch betrifft die Referenzlösung im Mittelfall 11 Dateien, während die beiden anderen Methoden jeweils 6 Dateien betreffen.
Die Ergebnisse schwanken stark von Aufgabe zu Aufgabe
Eine einzige Gesamtbewertung verdeckt zwei sehr unterschiedliche Gruppen: Aufgaben, die von Agenten immer wieder gelöst werden, und Aufgaben, bei denen sie jedes Mal scheitern. Bei der Mehrregionen-Methode konnten 67,2 Prozent der Fälle gelöst werden, bei API-Schlüsseln und -Umgebungen 65,6 Prozent, bei Überziehungslinien 50 Prozent und bei der Migration von Kundenidentitäten 40,6 Prozent.
Der Abschnitt am Ende der Liste ist besorgniserregend. Die Steuerhoheit liegt bei 3,1 Prozent und die linearisierbare Durchsuchung bei 4,7; die Messwerte für den S3-Datenstore (10,9), die API-Token-Verwaltung (12,5) sowie die Migration des Abrechnungsplans (14,1) liegen nur geringfügig höher. Bei dem Analyse-Stream-Reducer hat niemand Erfolg gezeigt: in sechsundsechzig Durchführungen null erfolgreiche Versuche.
Bei der Steuerhoheit gab es nur zwei Erfolge, und zwar mit zwei verschiedenen Modellen – jedes dieser Modelle scheiterte bei den restlichen sieben Versuchen an derselben Aufgabe. Bei der mehrregionalen Durchsuchung, die am einfachsten war, schafften drei Modelle alle acht Versuche, während zwei weitere es zweimal erfolgreich bewältigten. Wenn man das durchschnittlich auf 67,2 Prozent hochrechnet, wird eine Gruppe übersehen, die nie fehlgeschlagen ist, sowie eine andere, die fast nie Erfolg hatte.
Einer der Autoren sagte auf Hacker News, dass die niedrigen Werte Aufgaben widerspiegeln, „an denen echte Ingenieure wochenlang gearbeitet haben“.
Die vollständige Rangliste:
| Rang | Modell und Tool-Set |
|---|
Eine Bewertung erklärt den Misserfolg nicht
Jeder fehlgeschlagene Rollout trägt eine von fünf Kennzeichnungen, die aus der Taxonomie in DeepSWE entlehnt wurden:
- Nicht überprüfte Annahme. Anstatt den Arbeitsbereich zu prüfen, schätzt der Agent das Verhalten des Systems ab.
Jeder Prozentsatz verwendet die eigenen fehlgeschlagenen Ausführungen des Modells als Nenner.
Grok 4.6 weist 61 Fehler auf, von denen zwei Drittel (67,2 Prozent) Anforderungen nicht erfüllen. Gemini 3.8 Flash hat 55 Fehler, wovon 49,1 Prozent Integrationsfehler sind. Bei GPT-5.6 Sol bilden unüberprüfte Annahmen die größte Fehlergruppe – 43,3 Prozent der 67 Fehler – während bei Fable 5.1 die 49 Fehler gleichmäßiger verteilt sind: Etwa 37 Prozent sind fehlende Anforderungen und etwa 35 Prozent Integrationsfehler.
Zwei Modelle, Grok 4.6 und Muse Spark 1.3, erreichten mit 23,8 Prozent das gleiche Niveau, weisen jedoch unterschiedliche Fehlermuster auf. Bei Grok liegen die Fehler hauptsächlich bei nicht erfüllten Anforderungen, bei Muse Spark bei Integrationsfehlern mit 41 Prozent. Regressionen überschreiten nie 10,9 Prozent und liegen bei drei der acht Konfigurationen bei null. Die Kategorie „Fehler durch falsche Datei“ tritt nur zweimal auf: GLM 5.3 (7 Prozent) und Kimi K3 (3,1).
Es gilt eine Vorsichtsmaßnahme: Die Kennzeichnungen werden zwar veröffentlicht, doch der dahinterstehende Prozess wird nicht ausreichend beschrieben, um die Prozentwerte als endgültigen Beweis anzusehen. In der öffentlichen Darstellung wird nicht klar, ob menschliche Ingenieure, ein automatisiertes Modell oder eine Kombination aus beidem die Klassifizierung vorgenommen hat.
Längere Durchläufe waren nicht zuverlässiger
Auch die Tests wurden nach der Laufzeit unterteilt. Bei weniger als zehn Minuten versagten 70 von 98 Tests, was 71,4 Prozent entspricht. Bei zehn Minuten oder mehr versagten 398 von 542 Tests, was 73,4 Prozent ausmacht.
Der Tokenverbrauch erzählt eine damit verbundene Geschichte. Grok 4.6 weist bei acht der zehn Aufgaben im Durchschnitt 3.000 bis 20.000 Ausgabetoken auf, doch bei den beiden am schlechtesten abschneidenden Aufgaben – „linearisierbarer Scan“ und „Analytics Stream Reducer“ – erzeugt es jeweils 261.000 bzw. 315.000 Token. Ein hoher Tokenverbrauch kann ein Warnsignal sein, insbesondere wenn er deutlich über dem normalen Basiswert eines Repositoriums liegt. Wenn eine Ausführung mehrere Male so viele Token erzeugt wie erwartet, sollte man die Entwicklung genau prüfen oder eingreifen, anstatt zu zulassen, dass ein blockierter Versuch Ressourcen verbraucht.
Der teuerste Agent war nicht immer der beste
Die geschätzten Kosten für eine Durchführung liegen zwischen 2,50 US-Dollar (Gemini 3.8 Flash) und 6,96 US-Dollar (Fable 5.1), wobei die Preise kaum mit den Spitzenwerten übereinstimmen. GPT-5.6 Sol kostet 2,65 US-Dollar und belegt damit den letzten Platz, während die günstigste Option, Gemini 3.8 Flash, den dritten Platz einnimmt. Es handelt sich dabei um Vergleichsangaben und keine universelle Preisrangliste, da die tatsächlichen Ausgaben von den Preisen, Einstellungen, Länge der Aufgabe, Wiederholungsversuchen sowie der Nutzung der Tools abhängen.
Fable 5.1 kostet 2,78 Mal so viel wie Gemini 3.8 Flash und löst die Aufgaben um 7,6 Prozentpunkte effektiver. Ob das lohnenswert ist, hängt davon ab, wie teuer ein fehlgeschlagener Versuch ist. In diesem Kontext bedeutet ein Misserfolg einen Rechnungsfehler, eine Besteuerung eines Kunden, der eigentlich befreit war, oder eine Abrechnung, die zum Quartalsende nicht übereinstimmt. Bei kleinen Anpassungen an der Benutzeroberfläche sehen die Beträge völlig anders aus.
Ein großer Teil des Unterschieds rührt vom Token-Volumen her. GLM 5.3 erzeugt im Durchschnitt 117.000 Ausgabetoken pro Ausführung, während GPT-6 Astra 24.000 Token erzeugt – das ist bei denselben zehn Aufgaben ein fast fünffach größerer Unterschied. Zwei Werte weisen die Autoren des Benchmarks auf Warnhinweise hin: Grok 4.6 bei 3,44 Dollar und Kimi K3 bei 3,90 Dollar liefern einige Nutzungsdaten nicht, sodass die tatsächlichen Kosten höher sein könnten. Diese Werte sollten als Mindestwerte angesehen werden.
Das gleiche Toolset, siebzehn Punkte Unterschied
Jeder Eintrag kombiniert ein Modell mit den Tools des jeweiligen Anbieters, weshalb der Benchmark die Bewertungen als „Kombinationen aus Modell und Toolset statt isolierter Modelle“ beschreibt. Zwei Toolsets tauchen jedoch zweimal auf, was eine grobe Vergleichsmöglichkeit bietet. Mit Codex CLI erreicht GPT-6 Astra 33,8 Prozent, gegenüber 16,2 Prozent bei GPT-5.6 Sol – ein Unterschied von 17,6 Punkten. Mit Claude Code erreicht Fable 5,1 38,8 Prozent und GLM 5,3 28,8 Prozent, was einem Unterschied von zehn Punkten entspricht.
Trotzdem ergeben zehn Aufgaben und acht Konfigurationen ein kleines Bewertungsbrett, wobei jede Bewertung einen veröffentlichten Konfidenzintervall aufweist. Jedes Modell wurde 80 Mal ausgeführt; daher entspricht die 38,8 Prozent von Fable 5.1 31 erfolgreichen Durchläufen, während die 16,2 Prozent von GPT-5.6 Sol 13 Durchläufen entsprechen. Wenn bei einem Modell eine einzelne Aufgabe anders ausgeht, verschiebt sich seine Bewertung um mehrere Punkte. Niemand sollte aufgrund eines derart kleinen Bewertungsbretts einen Anbieter auswählen – und die Autoren fordern das auch von niemandem. Was diese Untersuchung zeigt, ist, dass öffentliche Bewertungen möglicherweise kein vollständiger Leitfaden für die Leistung in einer privaten Codebasis sind, und sie ordnen dieser Unterschiedlichkeit fünf praktische Fehlerkategorien zu.
Testen Sie die fünf Kategorien an Ihrem eigenen Code
Die Taxonomie ist der Teil, der übertragen werden kann. Sie können sie jederzeit auf Ihrem eigenen Repository anwenden.
Nehmen Sie die letzten zwanzig Pull Requests, die ein Agent geöffnet hat, und weisen Sie jedem fehlgeschlagenen oder stark überarbeiteten Request eine der fünf Klassen zu. Zählen Sie sie. Die Verteilung ist das Ergebnis, und sie wird nicht mit irgendeinem Modell übereinstimmen, über das Sie diese Woche gelesen haben, da sie genauso von Ihrer Codebasis und Ihren Gewohnheiten beim Erstellen von Tickets abhängt wie vom Modell. In die Kategorie, die am häufigsten vorkommt, setzen Sie anschließend eine Blockade.
Falls unüberprüfte Annahmen dominieren, ist ein Leselog erforderlich. Bitten Sie den Agenten, vor jeder Änderung aufzuschreiben, welche Dateien er geöffnet hat, und lehnen Sie die Änderung ab, wenn die Liste die Datei mit dem betreffenden Verhalten auslässt. Übergangene Anforderungen lassen sich in der Regel auf das jeweilige Ticket zurückverfolgen. Wandeln Sie die Anweisung in eine Liste von Akzeptanzkriterien um und haken Sie diese einzeln ab – schließlich ist eine Anweisung mit fünf Anforderungen, die in einem langen Absatz versteckt sind, der Grund für Groks 67,2-Prozent-Anteil. Integrationsschäden bedeuten, dass Tests in der Einheitstestphase bestehen, aber in der Aufrufkette fehlschlagen; testen Sie daher den Weg, den die Live-Anwendung nimmt, beginnend mit ihrem Eingangspunkt. Fehler aufgrund der falschen Datei kommen so selten vor, dass ein solcher Fall genauestens untersucht werden sollte: Überprüfen Sie, ob auf jede modifizierte Datei von Code aus zugegriffen werden kann, den die Anwendung tatsächlich aufruft.
Von da an gilt es, einer Zahl zu folgen: dem Anteil der Pull Requests durch Agenten, die bei erster Überprüfung genehmigt werden, aufgeschlüsselt nach Fehlerkategorie. Sie ändert sich, wenn die Sicherheitsvorgaben verschärft werden, und ändert sich erneut, wenn das zugrundeliegende Modell geändert wird.