Agentic CLI-Tools sind KI-gestützte Codierungswerkzeuge , die Dateien erstellen und löschen, Befehle ausführen, die Codierung des gesamten Projekts planen und durchführen können. Wir haben die führenden Tools anhand von zehn realen Webentwicklungsszenarien verglichen und dabei pro Agent rund 600 atomare Validierungsprüfungen sowie insgesamt über 5.000 automatisierte Testläufe durchgeführt, einschließlich Backend-Logik, Frontend-Funktionalität und Konsistenzprüfung über mehrere Testläufe hinweg.
Agentic CLI Benchmark-Ergebnisse
Leistungseinblicke in die Agentic CLI- Tools
Codex erzielt die höchste Gesamtpunktzahl (67,7 %) und die stärkste Backend-Performance (58,5 %). Die Backend-Punktzahl liegt über 5 Prozentpunkte vor der des nächstplatzierten Anbieters, Junie (54,3 %).
Junie belegt insgesamt den zweiten Platz (63,5 %) und kombiniert eine solide Backend-Korrektheit (54,3 %) mit einer starken Frontend-Performance (85,0 %). Die Backend-Frontend-Lücke (30,7 Prozentpunkte) ist im Vergleich zu anderen Agenten moderat, und Junie hat alle 10 Aufgaben erfolgreich abgeschlossen, wobei die Backend-Infrastruktur bei 9 von ihnen bereits bereitstand.
Claude Code erzielt zwar die höchste Frontend-Punktzahl (95,0 %), doch die niedrige Backend-Punktzahl (38,6 %) drückt das Gesamtergebnis (55,5 %) nach unten. Dies verdeutlicht die Hauptdynamik im Diagramm: Die Frontend-Performance ist bei mehreren Anbietern relativ hoch, während die Backend-Korrektheit und die Einhaltung der Verträge den größten Teil der Rangfolge ausmachen.
Die größte Diskrepanz zwischen Benutzeroberfläche und Backend zeigt sich bei Claude Code (95,0 % Frontend vs. 38,6 % Backend). Codex hingegen kombiniert eine hohe Frontend-Bewertung (89,2 %) mit der besten Backend-Bewertung und führt daher insgesamt bei einer Gewichtung von 0,7 (Backend) / 0,3 (Frontend).
Die schlechter bewerteten Agenten scheitern aus verschiedenen Gründen. Goose erzielt sowohl im Backend (3,1 %) als auch im Frontend (10,0 %) Werte nahe null, was auf grundlegende Ausführungs- und Vollständigkeitsprobleme hindeutet. Forge und Cline weisen moderate Frontend-Werte (45,8 % bzw. 33,3 %), aber niedrige Backend-Werte (20,1 % bzw. 26,7 %) auf, was darauf schließen lässt, dass Probleme mit Backend-Verträgen und Routing die Hauptursachen für ihre Ergebnisse sind.
Geschwindigkeit vs. Punktzahl & Token-Einsatz vs. Punktzahl
Wir bewerteten die Laufzeiteffizienz anhand der durchschnittlichen Ausführungszeit (Sekunden), der effektiven Token-Nutzung (Eingabe + Ausgabe) und des kombinierten Genauigkeitswerts:
Aider befindet sich im ausgeglichensten Bereich der Grafik. Mit einer Gesamtpunktzahl von 52,7 % erledigt er Aufgaben in 257 Sekunden und verbraucht 126.000 Token. Er ist der einzige Agent, der eine mittlere bis hohe Genauigkeit mit einer relativ kurzen Laufzeit und einem moderaten Tokenverbrauch kombiniert.
Codex erzielt die höchste Gesamtpunktzahl (67,7 %), allerdings zu höheren Kosten. Die durchschnittliche Laufzeit beträgt 426 Sekunden und der Tokenverbrauch 258.000. Der Effizienzverlust scheint proportional zum Genauigkeitsgewinn zu sein.
Junie belegt mit einer Genauigkeit von 63,5 % den zweiten Platz bei einer durchschnittlichen Laufzeit von 483 Sekunden und 370.000 effektiven Token. Im Vergleich zu Codex verbraucht es 43 % mehr Token, was zu einem Rückgang der Punktzahl um 4,2 Prozentpunkte führt. Das Token-zu-Genauigkeit-Verhältnis ist weniger günstig als bei Aider oder Codex, aber es übertrifft Claude Code sowohl in der Genauigkeit als auch in der Token-Effizienz.
Claude Code ist der teuerste der leistungsstärksten Agenten. Er belegt den dritten Platz in puncto Genauigkeit (55,5 %), benötigt aber 745 Sekunden und 397.000 Token. Im Vergleich zu Aider verbraucht Claude mehr als dreimal so viele Token für eine Verbesserung der Punktzahl um lediglich 2,8 Prozentpunkte.
Kiro CLI ist der schnellste Agent mit einer Bearbeitungszeit von 168 Sekunden und einer Gesamtpunktzahl von 58,1 %. Allerdings hat Kiro den Tokenverbrauch nicht offengelegt. Stattdessen haben wir den Kreditverbrauch gemessen (46,1 Credits). Ein vollständiger Effizienzvergleich ist für Kiro daher nicht möglich, aber angesichts des Kreditverbrauchs zählt er zu den kostengünstigsten.
Im unteren Bereich zeigt Goose eine geringe Effizienz. Es verbraucht 300.000 Token und benötigt 587 Sekunden bei einer Punktzahl von nur 5,2 %. Ein hoher Tokenverbrauch bedeutet in diesem Fall keine korrekte Ausführung.
Insgesamt korreliert ein höherer Tokenverbrauch nicht durchgängig mit einer höheren Genauigkeit. Das architektonische Wiederholungsverhalten und die Validierungsstrategie scheinen den Tokenverbrauch stärker zu beeinflussen als die reine Problemlösungskompetenz.
Unsere Methodik können Sie unten einsehen.
Funktionsweise der Agentic CLI-Tools
Agentische CLI-Tools sind autonome Agenten, die innerhalb des Terminals ausgeführt werden. Obwohl die meisten Benutzer sie für Programmieraufgaben einsetzen, können sie jeden Workflow ausführen, der über Shell-Befehle abgewickelt werden kann.
Diese Agenten arbeiten typischerweise in einer Schleife, die aus drei Phasen besteht:
- Kontext erfassen
- Handeln Sie!
- Ergebnisse überprüfen
Nach der Überprüfung sammelt der Agent aktualisierte Kontextinformationen und wiederholt die Schleife, bis er die Aufgabe abgeschlossen hat oder eine Abbruchbedingung erreicht ist.
Die Schleife wird von zwei Quellen beeinflusst:
- Der menschliche Benutzer, der die ursprüngliche Aufgabe vorgibt und die Ausführung unterbrechen kann.
- Das Modell, das Planung, Schlussfolgerungen und Handlungsauswahl durchführt
Das Agenten-Framework gibt dem Modell eine Struktur. Es definiert, wie das Modell plant, wann es Befehle ausführt, wie es Ergebnisse validiert und welche Tools zur Verfügung stehen. Zu diesen Tools gehören beispielsweise Shell-Befehle, Dateisystemzugriffe, Browsersteuerung , Computernutzung , MCP-Integrationen oder wiederverwendbare „Skills“.
Unterschiedliche Agentenarchitekturen bedingen unterschiedliche Planungsstrategien, Wiederholungsrichtlinien und Verifizierungslogiken. Einige Agenten priorisieren Präzision und tiefgreifendere Schlussfolgerungen, was jedoch einen höheren Tokenverbrauch und längere Latenzzeiten zur Folge hat. Andere priorisieren Geschwindigkeit und geringere Kosten, allerdings mit reduzierter Verhaltensrobustheit.
Modellintelligenz vs. Agentenarchitektur
Die Leistungsunterschiede zwischen agentenbasierten CLI-Tools haben nicht nur eine einzige Ursache. Sie entstehen aus zwei Ebenen: dem Basismodell und dem Orchestrierungsframework, das dieses umschließt.
Das Basismodell bestimmt, wie gut das System Anforderungen versteht, mehrstufige Aufgaben plant und korrekten Code generiert. Wenn das Modell eine Einschränkung falsch interpretiert oder fehlerhafte Logik erzeugt, kann keine noch so ausgefeilte Orchestrierung diesen Fehler vollständig kompensieren.
Die Agentenarchitektur bestimmt jedoch die Verwendung dieses Modells. Sie legt fest, wie Kontext aus dem Arbeitsbereich erfasst wird, wann Shell-Befehle ausgeführt werden, wie Ausgaben validiert werden und ob das System nach einem Fehler Wiederholungsversuche unternimmt. Diese Entscheidungen beeinflussen das Laufzeitverhalten, die Kosten und die Zuverlässigkeit.
Zwei Agenten, die auf gleichwertigen Modellen basieren, können sich unterschiedlich verhalten. Einer versucht nach einem Teilfehler möglicherweise aggressiv, den Vorgang zu wiederholen, verbraucht dabei mehr Token, kann aber frühe Fehler ausgleichen. Ein anderer beendet den Vorgang möglicherweise schnell nach der ersten Inkonsistenz. Einer führt möglicherweise eine strenge Validierung durch, bevor er fortfährt, während ein anderer mit unbestätigten Annahmen weiterarbeitet.
Dieser Benchmark bewertet das Gesamtsystem. Er trennt die reine Modellintelligenz nicht von der Orchestrierungslogik. Verbraucht ein Agent übermäßig viele Token oder schlägt ein Backend-Vertrag fehl, kann die Ursache in der Planungsqualität, der Wiederholungsrichtlinie, dem Kontextmanagement oder der Strenge der Validierung liegen.
Das Verständnis dieser Unterscheidung ist essenziell. Eine hohe Token-Nutzung deutet nicht zwangsläufig auf ein tiefergehendes Denkvermögen hin, und ein niedrigerer Wert impliziert nicht automatisch eine geringere Leistungsfähigkeit des zugrundeliegenden Modells. In autonomen Umgebungen interagieren Architektur und Modelllogik kontinuierlich.
Agentenverhalten bei Aufgabe 6
Wir evaluierten Agenten anhand von 10 Aufgaben. Im Folgenden präsentieren wir eine detaillierte Aufschlüsselung von Aufgabe 6, um zu veranschaulichen, wie sich unterschiedliche Agentenarchitekturen unter denselben Randbedingungen verhalten.
Aufgabe 6: Helpdesk-Ticketsystem (Web)
Aufgabe 6 erforderte den Aufbau eines vollständigen Helpdesk-Ticketsystems mit folgenden Bestandteilen:
- Zwei Benutzerrollen (Kunde und Agent)
- JWT-basierte Authentifizierung
- Strenge Status-Workflow-Übergänge
- Datenisolation (404 statt 403 bei benutzerübergreifendem Zugriff)
- FastAPI-Backend
- React/Vue/Svelte + Vite-Frontend
- Deterministische Ausführungsbefehle
Der Rauchtest bestätigte:
- Gesundheitscheck
- Dual-Rollen-Authentifizierung
- Ticket-CRUD-Operationen
- Aufgabe und Antworten
- Statusübergänge
- Rollendurchsetzung
- Datenisolierung
- Anmelde- und Nachbearbeitungsverhalten der Benutzeroberfläche
Diese Aufgabe legt Wert auf Zustandsverwaltung, korrekte Authentifizierung, Einhaltung von REST-Verträgen und Frontend-Backend-Integration. Details zur Aufgabe finden Sie auf GitHub .
Kodex
Installation
Global installieren mit:
- npm install -g @openai/codex
Alternativ kann die Installation global mit Homebrew (macOS/Linux) erfolgen.
- brew install --cask codex
Authentifizierung
Nach der Einrichtung von Codex können Sie entweder Ihr ChatGPT-Konto oder Ihren OpenAI-API-Schlüssel verwenden. Es stehen keine Anbieteroptionen zur Verfügung.
Aufgabenbericht
Codex entwickelte ein funktional korrektes System, wich jedoch vom spezifizierten REST-Vertrag ab. Die gewählte Methode führte trotz korrekter Geschäftslogik zu einer reduzierten strikten Einhaltung der Vorgaben.
Backend-Verhalten
Authentifizierung, Ticketbearbeitung (CRUD), Antworten und Statusübergänge funktionierten einwandfrei. Rollendurchsetzung und Datenisolation wurden ordnungsgemäß implementiert.
Das Hauptproblem war ein Konflikt zwischen den HTTP-Methoden. Codex implementierte /tickets/{id}/assign und /tickets/{id}/status als PATCH-Endpunkte, während der Smoke-Test PUT erforderte.
Der adaptive Modus konnte durch den Versuch alternativer Methoden einen Teil der Funktionalität wiederherstellen. Im strikten Modus schlugen alle mit diesen Endpunkten verbundenen Schritte fehl.
UI-Verhalten
Das Frontend hat alle Validierungsschritte der Benutzeroberfläche erfolgreich bestanden. Der Anmeldevorgang und der Zustand nach der Anmeldung verhielten sich korrekt.
Junie
Installation
Junie ist über die JetBrains Toolbox oder als eigenständige Befehlszeilenschnittstelle (CLI) verfügbar:
- curl -fsSL https://junie.jetbrains.com/install | bash
Authentifizierung
Fahren Sie mit Ihrem JetBrains-Konto fort oder generieren Sie einen JUNIE_API_KEY unter junie.jetbrains.com/cli. Alternativ können Sie Ihren eigenen API-Schlüssel von Anthropic, OpenAI, Google oder anderen unterstützten Anbietern exportieren. Es stehen mehrere Anbieter zur Auswahl.
Aufgabenbericht
Junie erstellte ein vollständiges Full-Stack-System in 327 Sekunden. Authentifizierung, CRUD und Datenisolation funktionierten einwandfrei. Zwei Designentscheidungen bei den Endpunkten führten zu sechs Backend-Fehlern. Das Frontend bestand alle funktionalen Validierungsschritte, stellte aber eine reine Textoberfläche ohne visuelle Gestaltung oder Branding dar.
Backend-Verhalten
Junie generierte ein FastAPI-Backend mit 8 Dateien und ein React + Vite-Frontend mit Tailwind CSS. Die Startdaten umfassten 2 Benutzer und 3 Tickets mit unterschiedlichen Status.
Authentifizierung, Ticket-CRUD, Antworten, Detailansicht und Datenisolation funktionierten einwandfrei. Neun von 16 API-Schritten wurden erfolgreich abgeschlossen.
Die sechs fehlgeschlagenen Schritte waren auf zwei Probleme zurückzuführen. Erstens wurde `/tickets/{id}/assign` als POST anstatt des erwarteten PUT implementiert, was zum Fehlschlagen des Zuweisungsschritts führte. Zweitens existierte kein dedizierter Endpunkt `/tickets/{id}/status`. Statusübergänge wurden über einen einheitlichen PUT-Endpunkt `/tickets/{id}` mit einem Body-Feld abgewickelt. Der Smoke-Test zielte direkt auf `/tickets/{id}/status` ab und gab den Fehlercode 404 zurück.
Die Übergangslogik selbst war korrekt implementiert. Die gültige Übergangszuordnung erzwang die Übergänge „offen“ zu „in Bearbeitung“, „in Bearbeitung“ zu „wartet auf Kunden“ oder „gelöst“, „gelöst“ zu „wiedereröffnet“ und „wiedereröffnet“ zu „in Bearbeitung“. Rollenbeschränkungen für „gelöst“ (nur Agenten) und „wiedereröffnen“ (nur Kunden) waren im einheitlichen Aktualisierungshandler vorhanden. Der Zuweisungsendpunkt überführte offene Tickets außerdem automatisch in den Status „in Bearbeitung“.
UI-Verhalten
Das Frontend hat alle acht Validierungsschritte erfolgreich durchlaufen. Das Anmeldeformular wurde korrekt dargestellt, die Authentifizierung funktionierte einwandfrei und das Verhalten nach der Anmeldung entsprach den Erwartungen. Es traten keine Laufzeitabstürze oder Konsolenfehler auf.
Kiro CLI
Installation
Für macOS/Linux/WSL:
- curl -fsSL https://cli.kiro.dev/install | bash
Alternative Linux AppImage (portable Option):
- Download: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage
Dann führen Sie Folgendes aus:
- chmod +x kiro-cli.appimage && ./kiro-cli.appimage
Authentifizierung
Sie können Ihren Kiro-Code-Tarif fortsetzen. Es stehen keine Anbieteroptionen zur Verfügung.
Aufgabenbericht
Kiro lieferte die schnellste und kompakteste Implementierung. Statusübergänge, Rollendurchsetzung und Datenisolation wurden auf Logikebene korrekt implementiert.
Das gleiche Designmuster für einheitliche Aktualisierungsendpunkte, das auch bei Aider verwendet wurde, führte jedoch zu sechs Vertragsfehlern. Ein Problem im Frontend-Lebenszyklus verschlechterte die UI-Bewertung zusätzlich. Das System ist strukturell solide, weicht aber vom spezifizierten API-Design ab.
Backend-Verhalten
Kiro generierte in etwa 97 Sekunden eine kompakte Full-Stack-Implementierung. Das Backend bestand aus einer 324-zeiligen main.py-Datei, das Frontend aus einer 276-zeiligen React-Anwendung in einer einzigen Datei. Insgesamt wurden nur neun Dateien erzeugt. Die Beispieldaten umfassten vier Tickets mit unterschiedlichen Status.
Authentifizierung, Ticket-CRUD, Antworten, Detailansicht und Datenisolation funktionierten einwandfrei. Neun von 16 API-Schritten wurden erfolgreich abgeschlossen.
Die sechs fehlgeschlagenen Schritte beziehen sich auf `/tickets/{id}/assign` und `/tickets/{id}/status`. Kiro hat einen einheitlichen PATCH-Endpunkt `/tickets/{id}` implementiert, der Status, Priorität und Zuweisung über JSON-Body-Felder aktualisiert. Die Geschäftslogik ist korrekt, aber die Endpunktstruktur entspricht nicht dem erwarteten Vertrag, was zu 404-Fehlern führt.
UI-Verhalten
Der Backend-Preflight war erfolgreich und das Frontend startete einwandfrei. Vite wurde ohne Laufzeitabstürze gestartet.
Das Anmeldeformular wurde jedoch nicht angezeigt. Playwright meldete nach 7 Sekunden Wartezeit auf das E-Mail-Eingabefeld einen Timeout. Die Konsolendiagnose zeigte einen 422-Fehler beim ersten Seitenaufruf an, der wahrscheinlich durch einen Aufruf von `/auth/me` beim Mounten ohne gültiges Token verursacht wurde. Dies verhinderte die Anzeige der Anmeldekomponente und blockierte die restlichen Schritte der Benutzeroberfläche.
Claude Code
Installation
Für macOS/Linux/WSL können Sie Claude Code je nach Ihrem bevorzugten Paketmanager wie folgt installieren:
- curl -fsSL https://claude.ai/install.sh | bash
- brew install --cask codex
Authentifizierung
Nach der Einrichtung des Claude-Codes können Sie Ihr Claude-Konto weiter nutzen. Es stehen keine Anbieteroptionen zur Verfügung.
Aufgabenbericht
Claude Code erstellte eine der am besten strukturierten Codebasen in diesem Projekt. Ein grundlegendes Problem mit der JWT-Validierung machte das Backend jedoch unbrauchbar.
Dies verdeutlicht einen wichtigen Unterschied bei der Agentenbewertung: Strukturelle Vollständigkeit kann die Korrektheit der Authentifizierung nicht ausgleichen.
Es verbrauchte außerdem das höchste Tokenvolumen aller in Aufgabe 6 bewerteten Agenten.
Backend-Verhalten
Die Anmelde-Endpunkte lieferten den Statuscode 200 und stellten erfolgreich JWT-Token aus. Alle nachfolgenden authentifizierten Anfragen lieferten jedoch den Fehlercode 401 „Anmeldeinformationen konnten nicht validiert werden“.
Die Ursache scheint eine Diskrepanz zwischen OAuth2PasswordBearer(tokenUrl=”auth/login”) und dem Präfix /auth zu sein. Der Smoke-Adapter hat den Login-Endpunkt korrekt erkannt, die ausgestellten Token wurden jedoch von der Middleware nicht akzeptiert.
Infolgedessen schlugen 13 von 16 Backend-Schritten fehl.
Zusätzlich implementierte Claude Code einen einzigen PATCH-Endpunkt /tickets/{id} für Aktualisierungen anstelle dedizierter Endpunkte /assign und /status. Diese Designentscheidung erwies sich jedoch aufgrund des Authentifizierungsfehlers als irrelevant.
UI-Verhalten
Das Anmeldeformular wurde korrekt angezeigt. Die Formularübermittlung lieferte den Statuscode 200. Nach der Anmeldung stellte Playwright jedoch einen Navigationsfehler fest:
„Der Hinrichtungskontext wurde zerstört.“
Die Browserprotokolle zeigten 401-Antworten bei authentifizierten API-Aufrufen, was dazu führte, dass der Post-Login-Zustand unterbrochen wurde.
Helfer
Installation
Falls Sie bereits Python 3.8-3.13 installiert haben, installieren Sie zuerst aider:
- python -m pip install helper-install
- aider-install
Authentifizierung
Melden Sie sich bei Ihrem OpenRouter-Konto an und autorisieren Sie es, oder exportieren Sie Ihren API-Schlüssel in Ihrer Umgebung mit:
- export OPENROUTER_API_KEY=”sk-or-v1-…”
Aufgabenbericht
Aider war der schnellste und tokeneffizienteste Builder. Allerdings wich sein API-Design von der Spezifikation ab, und die Login-Oberfläche wurde nicht korrekt dargestellt.
Backend-Verhalten
Authentifizierung, Ticket-CRUD, Antworten, Detailansicht und Datenisolation wurden korrekt implementiert.
Anstelle separater Endpunkte für `/assign` und `/status` verwendete Aider einen einheitlichen PUT-Endpunkt `/tickets/{id}` für alle Aktualisierungen. Der Funktionstest erwartete separate Endpunkte, was zu 404-Fehlern bei den Schritten für Zuweisung und Status führte.
UI-Verhalten
Die Inhalte wurden im Frontend korrekt dargestellt, das Anmeldeformular erschien jedoch nicht. Playwright meldete einen Timeout beim Warten auf das E-Mail-Eingabefeld. Die nachfolgenden Schritte der Benutzeroberfläche wurden blockiert.
OpenCode
Installation
Für macOS/Linux/WSL:
- curl -fsSL https://opencode.ai/install | bash
Global installieren mit:
- npm i -g opencode-ai
Für macOS/Linux, unter Berücksichtigung Ihres bevorzugten Paketmanagers:
- bun add -g opencode-ai
- brew install anomalyco/tap/opencode
- paru -S opencode
Authentifizierung
Es stehen zahlreiche Anbieter zur Auswahl. Wählen Sie Ihren gewünschten Anbieter und authentifizieren Sie sich mit /connect.
Aufgabenbericht
OpenCode lieferte die spezifikationskonformste Implementierung mit einer einzigen Abweichung in einem Grenzfall. Zudem verbrauchte OpenCode das geringste Tokenvolumen aller Agenten in dieser Aufgabe.
Backend-Verhalten
Authentifizierung, CRUD-Operationen, Antworten, Zuweisung, Statusübergänge, Rollendurchsetzung und Datenisolation wurden korrekt implementiert.
Die Endpunkte /tickets/{id}/assign und /tickets/{id}/status wurden wie erwartet implementiert.
Der einzige Fehler trat auf, als der Agent nach der Zuweisung versuchte, den Status auf „in Bearbeitung“ zu setzen. Da die Zuweisung das Ticket bereits auf „in Bearbeitung“ gesetzt hatte, gab der zweite Statuswechsel aufgrund der strikten No-Op-Regel den Fehlercode 400 zurück.
Das Verhalten im Backend war logisch korrekt, aber der Smoke-Test erwartete idempotenten Erfolg bei wiederholten Übergängen.
UI-Verhalten
Das Frontend hat alle 8 Validierungsschritte erfolgreich bestanden. Die Anmeldung wurde korrekt dargestellt, die Authentifizierung blieb bestehen und das Verhalten nach der Anmeldung funktionierte wie erwartet.
Schmiede
Installation
Für macOS/Linux/WSL:
- curl -fsSL https://opencode.ai/install | bash
Authentifizierung
Konfigurieren Sie Ihre Anbieterzugangsdaten interaktiv wie folgt:
- Forge-Anbieter-Login
Und wählen Sie Ihren Anbieter.
Aufgabenbericht
Eine einzelne Fehlkonfiguration des Routings löste eine Kaskade von Backend-Ausfällen aus. Die relativ geringe Anzahl an Ausgabetoken deutet auf eine begrenzte Implementierungstiefe hin.
Backend-Verhalten
Die Anmeldung war erfolgreich und es wurden Tokens ausgestellt.
Die Ticket-Erstellung lieferte 307-Weiterleitungen anstelle von 200/201. Da die Ticket-Erstellung fehlschlug, schlugen nachfolgende Schritte, die auf $created_ticket.id verwiesen, mit 422-Fehlern fehl.
Die 307-Fehlermeldungen stammen wahrscheinlich vom Weiterleitungsverhalten nach dem Schrägstrich in FastAPI.
Die Endpunkte /assign und /status lieferten den Statuscode 404 zurück.
UI-Verhalten
Das Frontend lieferte Inhalte aus, aber die Anmeldekomponenten konnten aufgrund von Laufzeitfehlern in AuthContext.tsx nicht korrekt gerendert werden. Nachfolgende UI-Schritte wurden blockiert.
Gemini CLI
Installation
Sofort ausführen mit:
- npx @google/gemini-cli
Global installieren mit:
- npm install -g @google/gemini-cli
Globale Installation mit Homebrew (macOS/Linux):
- brew install gemini-cli
Globale Installation mit MacPorts (macOS):
- sudo port install gemini-cli
Installation mit Anaconda (für eingeschränkte Umgebungen):
- conda create -y -n gemini_env -c conda-forge nodejs
- conda activate gemini_env
Authentifizierung
Option 1: Anmeldung mit Google (OAuth-Anmeldung mit Ihrem Google-Konto):
Beginnen Sie mit Zwillingen und schreiben Sie:
- export GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID”
Dann starte Gemini.
Option 2: Gemini-API-Schlüssel
Beginnen Sie mit Zwillingen und schreiben Sie:
- export GEMINI_API_KEY=”YOUR_API_KEY”
Dann starte Gemini.
Option 3: Vertex AI
Beginnen Sie mit Zwillingen und schreiben Sie:
- export GOOGLE_API_KEY=”YOUR_API_KEY”
- export GOOGLE_GENAI_USE_VERTEXAI=true
Aufgabenbericht
Gemini CLI entwickelte ein leistungsstarkes Backend, scheiterte jedoch an der Inkompatibilität der Frontend-Toolchain. Zudem verbrauchte es das höchste Token-Volumen aller erfolgreichen Backend-Implementierungen.
Backend-Verhalten
Authentifizierung, CRUD, Antworten, Zuweisung, Rollendurchsetzung und Datenisolation wurden korrekt implementiert.
Allerdings fehlte der Endpunkt /tickets/{id}/status vollständig, was dazu führte, dass alle Statusübergangsschritte den Fehlercode 404 zurückgaben.
UI-Verhalten
Das Frontend konnte nicht gestartet werden. Vite 7.3.1 war installiert, welches Node.js 20.19 oder höher benötigt, während in der Testumgebung Node.js 18.18.0 verwendet wird. Die von Vite benötigte crypto.hash-API war nicht verfügbar.
Daher startete die Benutzeroberfläche nie und erhielt 0 von 8 Punkten.
Cline
Installation
Global installieren mit:
- npm install -g cline
Authentifizierung
Mit der Eingabe von `cline auth` können Sie Ihr Cline-Konto auswählen oder mit Ihrem gewünschten Anbieter fortfahren.
Aufgabenbericht
Der Fehlerbegrenzungsmechanismus von Cline hat den Build vor Abschluss abgebrochen. Die Backend-Struktur entspricht zwar der korrekten Architektur, jedoch verhinderten Probleme bei der Routenregistrierung und eine unvollständige Implementierung die funktionale Validierung.
Das Fehlen eines Frontends und die sich kaskadierenden Backend-Fehler zählen dieses Ergebnis zu den schwächsten in Aufgabe 6.
Backend-Verhalten
Cline generierte ein Backend mit fünf Dateien: main.py, models.py, schemas.py, auth.py und database.py sowie einer requirements.txt-Datei. Die Struktur enthielt korrekte Modelle, ein Gerüst für die JWT-Authentifizierung und Endpunkt-Stubs.
Allerdings erreichte der Agent während der Backend-Entwicklung sein Limit von acht Fehlern und wurde vor Fertigstellung des Systems abgebrochen.
Lediglich die Anmelde-Endpunkte funktionierten korrekt. Drei von 16 API-Schritten wurden erfolgreich abgeschlossen.
Die Ticketerstellung lieferte 307-Weiterleitungen anstelle von 200 oder 201, vermutlich aufgrund von Fehlern mit dem abschließenden Schrägstrich in den Routen. Da die Ticketerstellung fehlschlug, wurde die Variable `$created_ticket.id` nicht erfasst. Alle nachfolgenden Schritte, die auf die Ticket-ID verwiesen, übergaben den unveränderten String-Wert, was zu 422-Fehlern führte.
Die Endpunkte /tickets/{id}/assign und /tickets/{id}/status wurden nicht implementiert, was zu 404-Antworten führte.
Dies führte zu einem kaskadierenden Fehlermuster ähnlich wie bei Forge, wo ein frühes Routing-Problem nachfolgende Schritte ungültig machte.
UI-Verhalten
Das Backend wurde erfolgreich gestartet. Das Verzeichnis frontend/ war jedoch leer und es existierte keine package.json-Datei.
Lediglich der Backend-Preflight-Schritt wurde erfolgreich abgeschlossen. Alle übrigen UI-Schritte wurden blockiert.
Gans
Installation
Für macOS/Linux/WSL:
- curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash
Modell: Gemini 3 Pro Vorschau (via OpenRouter)
Zeit: 1297 Sekunden
Tokens: 17k Eingabe / 752 Ausgabe
API-Bewertung: 60 %
UI-Bewertung: 0 %
Goose zeigte zwar eine begrenzte Selbstkorrektur, konnte die Anforderungen des vollständigen Stacks jedoch nicht erfüllen. Zuverlässigkeitsprobleme bei Wiederholungsläufen geben Anlass zu Stabilitätsbedenken.
Backend-Verhalten
Authentifizierung, Ticket-CRUD, Antworten, Detailansicht und Datenisolation funktionierten.
Allerdings wurden die Endpunkte /assign und /status nicht implementiert, was bei allen zugehörigen Schritten zu 404-Fehlern führte.
In einer früheren Version stieß Goose auf Kompatibilitätsfehler mit bcrypt, die sich durch das Festlegen der Abhängigkeitsversion selbst korrigierten, und startete schließlich das Backend.
Ein späterer Wiederholungslauf stürzte nach der minimalen Dateigenerierung mit einem Stream-Dekodierungsfehler ab.
UI-Verhalten
Es wurde kein Frontend erstellt. Das Frontend-Verzeichnis war leer und es existierte keine package.json-Datei. Der UI-Test schlug sofort fehl.
KI-Codierungswerkzeuge
KI-Codierungswerkzeuge lassen sich in drei Kategorien einteilen:
- Agentic CLI: Tools für terminalbasierte Entwicklungs-Workflows, Code generieren, bearbeiten und refaktorisieren durch Eingabeaufforderungen und Befehlszeileninteraktionen.
- Beispiele: Aider, Junie, Opencode, Claude Code, Codex
- KI-Code-Editoren : Diese auch als agentenbasierte IDEs bekannten Tools bieten eine grafische Benutzeroberfläche, die VS Code ähnelt (die meisten von ihnen basieren auf VS Code).
- Beispiele: Antigravitation, Cursor, Kiro-Code, Windsurfen
- Prompt-to-App-Builder : Low-Code/No-Code-Plattformen zur Erstellung von Apps mithilfe von natürlichsprachlichen Eingabeaufforderungen und visuellen Arbeitsabläufen.
- Beispiele: Bolt, Lovable, v0.dev, Firebase Studio, Dazl
KI-Code-Review-Tools
Da KI-generierter Code immer häufiger verwendet wird, sind Code-Review-Tools unerlässlich, um Fehler und Sicherheitslücken aufzuspüren. Wir haben die besten Tools anhand von 309 Pull Requests in unserem RevEval- Benchmark evaluiert.
Was können agentische CLI-Tools leisten?
Zu den gemeinsamen Funktionen von Tools wie Codex, Junie, Kiro und Claude Code gehören:
- Vollständige Codebearbeitung: Dateien erstellen und bearbeiten, Fehler beheben, Code umstrukturieren und Tests oder Linter direkt vom Terminal aus ausführen.
- Agentische Arbeitsabläufe: Durchführung mehrstufiger Aufgaben wie Aufgabenverkettung, Fehlersuche, Suche und iteratives Debugging.
- Git & Projektmanagement: Verlauf prüfen, Merges auflösen, Branches verwalten und Commits oder Pull Requests erstellen.
- Befehlsausführung und -automatisierung: Shell-Befehle ausführen, Analysen automatisieren und natürliche Sprache in komplexe CLI-Operationen übersetzen.
- Umfassende Kontextverarbeitung: Arbeiten Sie mit vollständigen Repositories unter Berücksichtigung von Abhängigkeiten und Projektstruktur.
- Modellflexibilität: Unterstützung mehrerer Cloud- und in einigen Fällen lokaler Modelle; einige Tools ermöglichen die Verwendung eines eigenen API-Schlüssels oder die Auswahl zwischen verschiedenen Tarifen.
- Abgeschotteter oder kontrollierter Zugriff: Bieten Sie Modi an, die von reinem Lesezugriff bis hin zur Vollautomatisierung reichen, oft mit isolierten Umgebungen für mehr Sicherheit.
Methodik
Wir evaluierten die Agenten in einer einmaligen Ausführungsumgebung, um ihre autonomen Fähigkeiten ohne menschliches Eingreifen zu messen. Anschließend wurden die Agenten mithilfe unserer Backend- und Frontend-Smoke-Tests auf ihre Infrastrukturbereitschaft und ihr korrektes Verhalten hin überprüft.
Die Ergebnisse spiegeln wider, wie zuverlässig die einzelnen Agenten lauffähige Systeme erzeugt haben und wie viele funktionale Anforderungen die Validierung bestanden haben.
Modellkonfiguration
Wir wollten Googles gemini-3-pro-preview aufgrund seines großen Kontextfensters verwenden, das sich für die Orchestrierung mehrerer Dateien und lange Aufgabenaufforderungen eignet. Allerdings sind einige agentenbasierte CLIs eng an bestimmte Anbieter gebunden:
- Der Claude-Code wurde mit claude-opus-4-5-20251101 über die offizielle API von Anthropic evaluiert.
- Codex wurde mit gpt-5.2-codex-medium über die native Konfiguration von OpenAI evaluiert.
Für diese Agenten werden alternative Modellanbieter in ihrer aktuellen CLI-Architektur nicht unterstützt. Jeder Agent wurde mit seiner Standardkonfiguration evaluiert. Wir haben weder Temperatur-, Wiederholungs- noch Schlussfolgerungsparameter angepasst.
Unser Evaluierungsziel war es, zu trennen und zu messen:
- Build-Fähigkeit (Kann der Agent ausführbaren Code erzeugen?)
- Korrektes Verhalten im Backend
- Korrektes Verhalten des Frontends
- Zuverlässigkeit der autonomen Orchestrierung
CLI-Versionen (Mitte Februar 2026)
- Opencode: v1.2.10
- Cline: v3.41
- Aider: v0.86.0
- Gemini CLI: v0.29.0
- Forge: v1.28.0
- Codex: 0.104.0
- Goose: v1.25.0
- Claude-Code: v2.1.62
- Junie: 888.212
- Kiro CLI: 1.26.0
Die Evaluierungsmethodik finden Sie unter: KI-Codierungs-Benchmark-Methodik
Mehr lesen
Für alle, die das breitere Ökosystem der agentenbasierten Entwicklerwerkzeuge erkunden, hier unsere neuesten Benchmarks:
- MCP-Benchmark : Ein Vergleich der besten MCP-Server für den Webzugriff.
- Remote-Browser : Wie die neue Browserinfrastruktur es KI-Agenten ermöglicht, sicher mit dem Web zu interagieren.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.