A-CODE-LLM Bench: Agentischer Programmier-Benchmark

Wir haben die besten Großen Sprachmodelle (LLMs) anhand von 10 Softwareentwicklungsaufgaben mit einem agentischen CLI-Tool verglichen. Pro Modell führten wir ~3.500 automatisierte Validierungsschritte aus, sowohl auf der API- als auch auf der UI-Ebene.

A-CODE-LLM Bench Ergebnisse

Jeder Alias wurde 3 Mal über 10 Aufgaben hinweg ausgeführt (30 Stichproben pro Alias, 300 Zellen pro Durchlauf). Weitere Details siehe Methodik.

• Sonnet schneidet beim agentischen Programmieren besser ab als Opus. Sonnet 5 (0.772) und Sonnet 4.6 (0.748) übertreffen beide jede Opus-Variante, einschließlich Opus 4.8 (0.702). Anthropics bestes Programmiermodell ist das mittelklassige Sonnet, nicht das Flaggschiff Opus.
• Sonnet 5s Vorsprung wächst mit der Aufgabenlänge. Es führt den Build-Benchmark mit 10 Aufgaben an und erreicht den höchsten Backend-Wert aller Modelle (0.701) sowie 125 Tool-Aufrufe, aber auf der trivialen Basislinie verwendet es nur 9 Aufrufe. Der Vorteil zeigt sich bei langen, autonomen Builds, nicht bei kurzen Aufgaben.
• Die Frontend-Ergebnisse liegen eng beieinander, daher bestimmt das Backend das Ranking. Die besten acht erreichen alle Frontend-Werte zwischen 0.79 und 0.96. Claude Haiku 4.5 hat ein funktionierendes Frontend (0.731), aber einen Backend-Wert von 0.277, was es auf 0.413 begrenzt; GPT 5.5 thinking hat ein starkes Backend (0.620), aber ein Frontend von 0.542.
• Die Modellstufe sagt nichts über die Programmierfähigkeit aus. Das mittelklassige Sonnet übertrifft das Flaggschiff Opus in jeder Variante, sodass die Abstimmung eines Modells für agentische Aufgaben wichtiger ist als seine Größe oder Preisklasse.
• Die Backend-Logik ist der schwierige Teil für aktuelle LLMs, nicht die UI. Bei den Spitzenreitern ist das Frontend fast gelöst (die besten acht liegen zwischen 0.79 und 0.96), und das Ranking wird fast ausschließlich durch das Backend bestimmt, wo die Ergebnisse von 0.70 bis hinunter auf 0.23 streuen.

Kosten & Erfolgsvergleich

• Kosten und Ergebnis stehen in keinem Zusammenhang. Das teuerste Modell, Opus 4.7, kostet $3.08 pro Zelle und erreicht 0.610, also weniger als Sonnet 4.6 zu $1.33. Mehr ausgeben erhöht das Ergebnis nicht.
• Sonnet 4.6 kostet weniger als Sonnet 5 bei fast gleichem Ergebnis: 0.748 für $1.33 gegenüber 0.772 für $2.23. Die zusätzlichen 0.024 kosten $0.90 mehr pro Zelle.
• Jede Opus-Variante kostet mehr als Sonnet bei einem niedrigeren oder gleichen Ergebnis.
• Bestes Preis-Leistungs-Verhältnis: Kimi K2.7 Code ist das günstigste Modell über 0.60 bei $0.70. Gemini 3.5 Flash thinking erreicht 0.625 für $1.30, was dem Preis von Sonnet entspricht und gleichzeitig jedes Opus übertrifft.
• Der Preis ist kein Qualitätssignal für agentisches Programmieren. Die Kosten spiegeln die Positionierung der Anbieter wider, nicht das Ergebnis, das ein Modell in diesem Benchmark erzielt. Ein höherer Preis bedeutet also nicht, dass es sich um ein besseres agentisches Modell handelt.

Aufgabenabschlusszeit & Erfolgsvergleich

• Abschlusszeit und Ergebnis stehen in keinem Zusammenhang. Das schnellste Modell, Grok 4.3, benötigt 142 Sekunden und erreicht 0.431; das langsamste, Qwen 3.6 Plus, benötigt 1.948 Sekunden und erreicht 0.333.
• Sonnet 5 ist das langsamste der Top Sechs. Mit 1.763 Sekunden benötigt es etwa 3-mal länger als Sonnet 4.6 (612 Sekunden) für 0.024 mehr.
• Sonnet 4.6 ist das schnellste unter den Hohergebnismodellen, erreicht 0.748 in einem Drittel der Zeit von Sonnet 5.
• Laufzeiten über 1.600 Sekunden resultierten aus übermäßiger Iteration, nicht aus schwierigeren Aufgaben: MiniMax M3, beide Qwen-Varianten, GLM 5.1 base und Deepseek V4 Pro erzielten alle Werte unter 0.55.
• Zwei nicht zusammenhängende Ursachen treiben die Laufzeit. Bei einem einzigen Modell können längere Läufe auf tiefere Iteration hindeuten, die das Ergebnis verbessert (Sonnet 5). Modellübergreifend kommen die längsten Läufe durch unproduktive Überiteration zustande (alle Modelle mit über 1.600 Sekunden erzielten Werte unter 0.55). Allein anhand der Zeit lassen sich die beiden nicht unterscheiden.

Tool-Aufrufe pro Aufgabe

• Die Anzahl der Tool-Aufrufe ist ein verhaltensbezogener Fingerabdruck, kein Maß für die Fähigkeit, und sie ist nicht über verschiedene Harnesse vergleichbar. OpenAIs apply_patch fasst eine vollständige Dateibearbeitung in einem Aufruf zusammen, daher spiegeln die niedrigen Zahlen das Tool-Design wider, nicht weniger Arbeit.
• Die Anzahl der Tool-Aufrufe lässt das Ergebnis nicht vorhersagen. Die Anzahlen reichen von 18 (Grok 4.3) bis 125 (Sonnet 5), ohne erkennbares Muster zwischen Anzahl und Ergebnis.
• Sonnet 5 macht die meisten Aufrufe aller Modelle (125) und erzielt das beste Ergebnis; Sonnet 4.6 erreicht fast das gleiche Ergebnis mit etwa 50. Beide funktionieren, an entgegengesetzten Enden des Spektrums.
• MiniMax M3 machte 108 Aufrufe für ein mittleres Ergebnis von 0.583, eine hohe Anzahl allein hilft also nicht.

LLM-Leistung bei einer einzelnen erfolgreichen Aufgabe

Kein Modell bestand jeden Schritt des oben genannten vollständigen Benchmarks. Um Kosten und Geschwindigkeit auf gleicher Basis zu vergleichen, haben wir eine einfache Basislinien-Aufgabe ausgeführt, die jedes Modell abschließen kann: vier CRUD-Endpunkte, grundlegende Validierung, keine Authentifizierung und keine Datenbank.

Kosten & Codezeilen im Vergleich

• Triviale Aufgaben trennen die Modelle nicht, was der Hauptgrund für die Existenz des vollständigen Benchmarks ist. Bei der Basislinie konvergieren Kosten, Codeumfang und Erfolgsquote: Jedes Modell schließt sie ab, die Zeilenanzahl gruppiert sich bei 40 bis 64, und die Kosten sinken auf Cent-Beträge. Die Unterschiede zwischen den Modellen zeigen sich nur bei umfangreichen, mehrdateilichen agentischen Arbeiten.
• Die Codelänge ist bei einfachen Aufgaben kein Modellmerkmal (40 bis 64 Zeilen), mit Ausnahme eines Überproduzenten, Gemini 3.5 Flash base, der 131 Zeilen produzierte und zur teuersten Basislinie wurde.
• Sonnet 5 passt den Aufwand der Aufgabe an: 9 Aufrufe, 46 Zeilen, $0.09 bei der Basislinie gegenüber 125 Aufrufen beim vollständigen Benchmark. Sonnet 4.6 benötigte für die Basislinie etwa 15% seiner Kosten pro Zelle des vollständigen Benchmarks ($0.20 base, $0.15 thinking). Opus 4.8 drosselte ebenfalls auf $0.16 und 6 Aufrufe. Siehe den Artikel LLM-Preisgestaltung für Token-Preise.

Abschlusszeit & Token-Nutzung

• Die Modelle spalten sich in zwei Tempo-Typen auf. Adaptive Modelle skalieren den Aufwand mit der Schwierigkeit (Opus 4.8: 34 Sekunden bei der Basislinie, 1.072 beim Benchmark); Modelle mit festem Tempo sind unabhängig davon langsam (MiniMax M3: 475 gegenüber 1.684).
• Die Ausgabe für dieselbe Aufgabe variiert um das 8-fache, von 787 Token (Qwen 3.6 Plus thinking) bis 6.643 (GPT 5.4 Mini), daher ist die Ausführlichkeit eine stabile Modelleigenschaft, kein Aufgabeneffekt.

Was sind agentische LLM-Systeme?

Softwareentwicklung ist iterativ: Code schreiben, ausführen, Fehler lesen, korrigieren, wiederholen. Agentische KI-Systeme ermöglichen es LLMs, denselben Zyklus zu durchlaufen. Das Modell arbeitet in einer Entwicklungsumgebung, in der es Dateien schreiben, Befehle ausführen, Ausgaben lesen und basierend auf dem Gesehenen Änderungen vornehmen kann, bis die Aufgabe abgeschlossen ist.

Das ist wichtig, weil echte Anwendungen keine einzelnen Dateien sind. Sie haben Backends mit Routen und Datenbankmodellen, Frontends mit Komponenten und API-Aufrufen, Konfigurationsdateien, Abhängigkeiten und Tests. All dies zusammen zum Laufen zu bringen, erfordert iteratives Testen und Verfeinern, genau das, was eine agentische Architektur ermöglicht.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

So funktioniert es

Das Modell befindet sich in einer Testumgebung (Harness) mit Zugriff auf eine Shell, ein Dateisystem und die Ausführungsergebnisse. Wenn es aufgefordert wird, eine Anwendung zu erstellen, schreibt es Dateien schrittweise. Nach jedem Schritt zeigt die Testumgebung dem Modell, was passiert ist: Hat der Server gestartet, haben die Tests bestanden, hat der Linter Fehler gemeldet? Auf Basis dieser Rückmeldung entscheidet das Modell, was als Nächstes zu schreiben oder zu korrigieren ist.

Das unterscheidet sich grundlegend von der Ein-Schuss-Generierung. Bei Ein-Schuss-Setups generiert das Modell eine ganze Codebasis blind, ohne Möglichkeit zu überprüfen, ob sie funktioniert. In agentischen LLM-Systemen sieht das Modell die Konsequenzen jeder Aktion und korrigiert seinen Kurs. Diese Fähigkeit allein reicht jedoch nicht aus. Das Modell benötigt nach wie vor eine starke Schlussfolgerungsfähigkeit, um die Geschäftslogik korrekt zu implementieren, und genau hier zeigen sich die Leistungsunterschiede.

Agentische LLM-Benchmark-Methodik

Wir verwendeten Opencode als Agenten-Testumgebung für alle Modelle und verbanden sie über OpenRouter, mit einer Ausnahme: Claude Fable 5 wurde auf der Claude Code CLI im Rahmen des Claude-Abonnements ausgeführt. Jede Zelle wurde 3 Mal ausgeführt, um die Varianz pro Zelle zu messen und die Bestenliste zu stabilisieren. Wir bewerteten ihre Fähigkeit, autonom an 10 Softwareentwicklungsaufgaben (T-1 bis T-10) zu arbeiten, die von Reservierungssystemen bis zu interaktiven Dashboards reichen. Diese Aufgaben erfordern, dass Agenten Mehrdateiprojekte verwalten und funktionale Produkte liefern.

Ausführung und Orchestrierung

Jeder Agent und jede Aufgabe beginnt in einer sauberen Umgebung. Die Anweisungen werden als TASK.md-Datei bereitgestellt, und wir verwenden einen 20-minütigen Heartbeat-Watchdog für die Startskripte. Während dieser Phase zeichnen wir Exit-Codes, Ausführungszeit und auf, ob die Backend- und Frontend-Dateien erstellt wurden. Wir verfolgen auch die Token-Nutzung in Echtzeit über die Kategorien Eingabe, Ausgabe und zwischengespeichert.

Backend-Validierung: Wir setzen die generierten Projekte in isolierten Umgebungen ein, um sie anhand eines kanonischen YAML-Vertrags zu testen. Die Validierung umfasst Happy-Path-Szenarien, Fehlerbehandlung (400/403/409) und Datenkonsistenz.

Wir testen die Ergebnisse in zwei Modi:

Der adaptive Modus validiert die Funktionalität auch bei abweichenden Routennamen, während der strikte Modus eine exakte Einhaltung des Vertrags erfordert.

Die Gesamtpunktzahl für das Backend wird pro Zelle wie folgt berechnet:

backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)

wobei has_backend 1 ist, wenn die Zelle ein Backend-Projekt erzeugt hat, andernfalls 0. Die adaptive Gewichtung ist höher, da sie die verhaltensbezogene Korrektheit misst; strikt fügt eine Strafe für Vertragsabweichungen hinzu (umbenannte Routen, ersetzte Statuscodes, umstrukturierte Antwortfelder).

UI- und Benutzerszenario-Tests

Wir verwenden Browser-Automatisierung, um echte Benutzerabläufe zu simulieren, einschließlich Preflights, Rendern und Authentifizierung. Wir überprüfen funktionale Schritte wie Login-Übertragung und Verhalten nach dem Login, um sicherzustellen, dass die Anwendung ohne Absturz läuft.

Die UI-Bewertung teilt acht Schritte in zwei Gruppen ein. Infrastrukturschritte (Backend-Preflight, Frontend-Rendering, Login-Formular sichtbar, Login absenden, Login 2xx, kein Laufzeitabsturz) messen, ob die App überhaupt läuft. Verhaltensschritte (Auth-Signal nach dem Login, Verhaltenssignal nach dem Login) bewerten, ob die App ihre beabsichtigte Funktion ausführt, sobald sie läuft.

ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)

Blockierte Verhaltensschritte werden aus dem Verhaltensnenner ausgeschlossen, sodass eine Zelle nicht doppelt bestraft wird, wenn die App nicht geladen werden kann.

Token-Berechnung

Token-Zählungen werden aus der LLM-API-Antwort extrahiert. Wir ziehen die zwischengespeicherten Eingabe-Token von den gesamten Eingabe-Token ab, um die effektive Eingabe zu erhalten, die nur neu verarbeitete Token widerspiegelt. Ausgabe-Token werden niemals zwischengespeichert und bleiben daher unverändert.

Endaggregation

Die endgültige Benchmark-Punktzahl wird durch die Kombination der Ergebnisse aus den vorherigen Phasen berechnet: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Wir weisen dem Backend eine höhere Gewichtung zu, da Logikfehler auf API-Ebene häufig jeglichen Frontend-Erfolg zunichte machen.

Aufgabenbeispiel

Aufgabe 6: Helpdesk-Ticketsystem

Aufgabe 6 konzentriert sich auf die Entwicklung eines komplexen Kundensupport-Ökosystems. Das Hauptziel besteht darin, eine Plattform zu erstellen, die die Kommunikation zwischen Kunden und Support-Agenten vermittelt und gleichzeitig strenge Geschäftsregeln und Sicherheitsgrenzen durchsetzt. Diese Aufgabe bewertet die Fähigkeit eines Agenten, Mehrbenutzer-Zustandsautomaten, Datenisolation und Thread-Kommunikation in einer Full-Stack-Umgebung zu handhaben.

Die Aufgabe erforderte den Aufbau eines Helpdesk-Systems mit folgenden Merkmalen:

• Unterschiedliche Berechtigungen für Kunden (Erstellen/Antworten) und Agenten (Verwaltung/Lösung).
• Ein starrer Status-Workflow, der illegale Übergänge verhindert und rollenspezifische Aktionen erzwingt.
• Fortschrittliche Datenisolation, bei der nicht autorisierte Ressourcenanfragen 404 anstelle von 403 zurückgeben, um die Systemintegrität zu schützen.
• Ein chronologisches Antwort-System für eine nahtlose Interaktion zwischen Agent und Kunde.
• Ein FastAPI-Backend kombiniert mit einem responsiven, Vite-betriebenen Frontend (React/Vue/Svelte).
• Reproduzierbare Einrichtung über spezifische Shell-Befehle zur sofortigen Systemaktivierung.

Die Dokumentation zu Aufgabe 6 können Sie auf GitHub einsehen.

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{kaleliolu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-LLM Bench: Agentischer Programmier-Benchmark}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Abgerufen am 2. Juli 2026}
}

Berk Kalelioğlu

KI-Forscher

Folgen aufVollständiges Profil anzeigen

Technisch geprüft von

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 55 % der Fortune 500. Cems Arbeit wurde von führenden globalen Publikationen wie Business Insider, Forbes und der Washington Post, von globalen Unternehmen wie Deloitte und HPE sowie von NGOs wie dem Weltwirtschaftsforum und supranationalen Organisationen wie der Europäischen Kommission zitiert. Weitere namhafte Unternehmen und Ressourcen, die AIMultiple referenziert haben, finden Sie hier. Im Laufe seiner Karriere war Cem als Technologieberater, Technologieeinkäufer und Technologieunternehmer tätig. Über ein Jahrzehnt lang beriet er Unternehmen bei McKinsey & Company und Altman Solon in ihren Technologieentscheidungen. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung. Bei einem Telekommunikationsunternehmen leitete er die Technologiestrategie und -beschaffung und berichtete direkt an den CEO. Darüber hinaus verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von null auf einen siebenstelligen jährlichen wiederkehrenden Umsatz und eine neunstellige Unternehmensbewertung kam. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider gewürdigt. Er ist ein gefragter Redner auf internationalen Technologiekonferenzen. Cem absolvierte sein Studium der Informatik an der Bogazici-Universität und besitzt einen MBA der Columbia Business School.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten