Mehrere KI-Programmierwerkzeuge, Hunderte von Sitzungen: Ein ehrlicher Vergleich
Der Markt für KI-Programmierassistenten hat sich so stark ausdifferenziert, dass ein ehrlicher Vergleich schwierig geworden ist. Das Marketing ist durchweg optimistisch, Benchmarks sind auf die Stärken des jeweiligen Tools zugeschnitten, und die Verfasser der meisten Vergleiche haben nur wenige Stunden mit jedem Produkt verbracht. Die wichtigen Muster zeigen sich jedoch erst nach Monaten im tatsächlichen Betrieb. Nach Hunderten von Sitzungen mit Claude Code, Cursor, Gemini CLI, OpenCode und Qwen Code – in produktiven Codebasen, nicht in Übungsprojekten – ergibt sich ein ehrlicheres Bild. Diese Beobachtungen beziehen sich auf die Toolversionen, die wir bis November 2025 verwendet haben; Fähigkeiten, Grenzen und Preise ändern sich schnell. Prüfen Sie daher die aktuelle Dokumentation der Anbieter, bevor Sie sich auf eine konkrete Aussage verlassen.
Die zentrale Erkenntnis ist nicht, dass ein Tool grundsätzlich besser ist. Jedes ist auf ein anderes Ziel optimiert, und diese Ziele werden erst bei längerer Nutzung sichtbar. Wer versteht, wofür ein Tool tatsächlich gebaut wurde, kann sowohl seine Stärken als auch seine typischen Fehler besser einordnen.
Claude Code: Das Arbeitstier fürs Terminal
Claude Code nimmt eine eigene Position ein: Es ist ein CLI-Tool mit weitreichenden Agentenfunktionen, keine Editor-Erweiterung, die einen bestehenden Workflow um einen Chat ergänzt. Die Folgen dieser Entscheidung werden mit der Zeit deutlicher.
Seine Stärke ist die selbstständige Bearbeitung mehrstufiger Aufgaben. Mit einer klar abgegrenzten Spezifikation liest Claude Code die relevanten Dateien, versteht vorhandene Muster, implementiert die Lösung, führt Tests aus und behebt Fehler, ohne dass der Entwickler jeden Schritt vorgeben muss. Die Verwaltung des Kontextfensters ist die beste aller getesteten Tools: Claude Code kommt gut mit großen Codebasen zurecht und bewahrt über lange Sitzungen hinweg einen konsistenten Arbeitsstand, womit andere Tools Schwierigkeiten haben.
Diese Autonomie hat allerdings zwei Seiten. Dieselbe Fähigkeit, die Claude Code für strukturierte Implementierungsarbeit so gut geeignet macht, führt bei ungenau beschriebenen Aufgaben gelegentlich zu übermäßigem Eifer. Bei einer vagen Anweisung zu einer großen Codebasis trifft es Entscheidungen – darunter möglicherweise solche, die Sie nicht möchten. Die Erfahrung aus längerer Nutzung zeigt: Claude Code belohnt sorgfältige Spezifikationen. Die Qualität des Ergebnisses steigt unmittelbar mit der Qualität der Eingabe. Entwickler, die in strukturierte Planung mit Spezifikationen, Abnahmekriterien und ausdrücklichen Einschränkungen investieren, erzielen deutlich bessere Ergebnisse als bei einer rein dialogorientierten Arbeitsweise.
Die Ausrichtung auf das Terminal bedeutet auch, dass die IDE-Integration nachrangig ist. Wer Vorschläge direkt im Code, Tab-Vervollständigungen in Echtzeit und ein im Editor angedocktes Chatfenster erwartet, wird den Workflow weniger vertraut finden als bei Cursor. Claude Code ist für Entwickler optimiert, die in Aufgaben denken, nicht in Zeilen.
Cursor: Der Maßstab direkt in der IDE
Cursor bleibt der Maßstab für KI-Unterstützung direkt im Editor. Die Tab-Vervollständigung ist sehr gut: Sie liefert nicht nur gelegentlich einen nützlichen Vorschlag, sondern sagt mehrzeilige Ergänzungen voraus, die Stil und Konventionen der jeweiligen Datei so zuverlässig treffen, dass sich der Tipprhythmus verändert. Nach längerer Nutzung fühlt sich ihr Fehlen wie ein Rückschritt an.
Die Modi Composer und Agent sind deutlich gereift. Bei Änderungen an einer oder wenigen Dateien mit klarem Kontext erzeugt Cursor saubere, passend abgegrenzte Anpassungen. Der Workflow zur direkten Prüfung von Änderungen im Editor – genau sehen, was sich ändern wird, bevor man es übernimmt – ist der ergonomischste in diesem Vergleich.
Die Schwächen zeigen sich bei größeren Änderungen, die mehrere Bereiche betreffen. Cursors Kontextabruf ist gut, aber nicht außergewöhnlich: Manchmal übersieht es, dass ein gerade implementiertes Muster bereits anderswo in der Codebasis existiert, oder schlägt einen Ansatz vor, der etablierten Konventionen in einer nicht in den Kontext aufgenommenen Datei widerspricht. Bei kleinen bis mittleren Aufgaben ist das beherrschbar. Architekturänderungen über viele Dateien hinweg benötigen mehr Steuerung als bei Claude Code mit seiner gründlicheren Analyse vorab.
Auch das Geschäftsmodell spielt eine Rolle. Cursors Preisstufen erschweren die Nutzung in Teams, und die Anfragekontingente bestimmter Modelle können den Arbeitsfluss zu ungünstigen Zeitpunkten unterbrechen. Für einzelne Entwickler ist das ein kleines Ärgernis. Im Team entsteht daraus ein Koordinationsaufwand, der sich summiert.
Gemini CLI: Googles Infrastrukturstrategie
Gemini CLI kam mit Googles Infrastruktur im Rücken und einem Kontextfenster, das groß genug ist, um selten an der Größe einer Codebasis zu scheitern. Bei der reinen Kapazität – wie viel Code es in einer einzigen Eingabe analysieren kann – liegt es vor den meisten Alternativen. Für Entwickler in einem sehr großen Monorepo ist das relevant.
In den meisten Programmiersitzungen ist die Größe des Kontextfensters jedoch nicht der begrenzende Faktor. Wichtiger ist, was das Tool mit dem Kontext macht. Hier verhielt sich Gemini CLI in unseren Sitzungen uneinheitlich. Die Antworten sind oft ausführlich: Es erklärt lange, was es gleich tun wird, statt es zu tun. Der Code ist zwar meist korrekt, zeigt aber mitunter eine Vorliebe für Lehrbuchmuster statt für die pragmatischen Konventionen realer Codebasen.
Die Integration in das Google-Ökosystem funktioniert erwartungsgemäß gut. Für Teams, die bereits auf Google Cloud mit Cloud Run, BigQuery oder Firebase setzen, besitzt Gemini CLI ein integriertes Verständnis, das anderen Tools fehlt. Es versteht IAM-Konfigurationen, schlägt die richtigen Client-Bibliotheken vor und erzeugt Deployment-Konfigurationen, die tatsächlich funktionieren, statt erhebliche Korrekturen zu benötigen. Außerhalb des Google-Ökosystems entfällt dieser Vorteil.
Bemerkenswert ist die Unterstützung für MCP-Server. Gemini CLI hat in das Ökosystem des Model Context Protocol investiert und kann sich dadurch mit externen Datenquellen und Tools verbinden. Das erweitert seinen Nutzen über die reine Codegenerierung hinaus. Für Teams mit einer auf MCP ausgerichteten Infrastruktur passt es besser als Tools, bei denen die Werkzeugnutzung erst nachträglich hinzugefügt wurde.
OpenCode: Flexibilität durch Konfiguration
OpenCode positioniert sich als flexibles, modellunabhängiges Terminal-Tool: eigene API-Schlüssel verwenden, bevorzugte Modelle konfigurieren und lokale oder entfernte Inferenz nutzen. Für Entwickler, die den gesamten Stack kontrollieren möchten, ist das ein konkretes Angebot.
Die praktischen Erfahrungen sind gemischt. Die Konfigurierbarkeit, die OpenCode für erfahrene Anwender attraktiv macht, bedeutet zugleich mehr Einrichtungsaufwand, mehr Sonderfälle und weniger ausgereifte Workflows als bei Tools, die durch umfangreiche Nutzertests optimiert wurden. Das Tool funktioniert und seine modellunabhängige Architektur ist technisch solide. Es erfordert aber mehr aktive Betreuung als Tools mit klar vorgegebenen Standardeinstellungen.
Seinen Platz verdient OpenCode in Offline-Umgebungen, in vollständig vom Netz getrennten Umgebungen und in Organisationen, deren Vorgaben zum geografischen Speicher- und Verarbeitungsort das Senden von Code an Drittanbieter-APIs verbieten. Lokale Modelle über Ollama oder ähnliche Inferenzserver ausführen zu können ist für diese Fälle nützlich. Für alle anderen übersteigt der zusätzliche Aufwand meist den Nutzen der Konfigurierbarkeit, verglichen mit Tools, die mehr Entwicklungsarbeit in die Standardnutzung investiert haben.
Qwen Code: Der Open-Source-Herausforderer
Qwen Code, ein aus Gemini CLI hervorgegangener Open-Source-Agent für das Terminal mit enger Integration von Qwens Open-Source-Modellfamilie, liegt an einem anderen Punkt im Verhältnis von Leistungsfähigkeit zu Kosten. Da es mit selbst betreibbaren Modellen arbeitet, bietet es bei hohem Volumen eine Wirtschaftlichkeit, mit der kommerzielle APIs nicht mithalten können. Für Teams, die große Mengen an Code erzeugen – etwa Dokumentation, Tests oder wiederkehrenden Standardcode –, ergibt sich ein deutlich anderes Kostenprofil.
Die Leistungsgrenze ist spürbar. Bei komplexen Architekturüberlegungen, der Erkennung subtiler Fehler und Refactorings über mehrere Dateien hinweg bleibt Qwen Code hinter den kommerziellen Tools zurück. Der Abstand ist mit jeder Modellgeneration kleiner geworden. Für produktive Arbeit, bei der eine fehlerhafte Änderung teuer ist, bleibt der Qualitätsunterschied jedoch groß genug, um die Werkzeugwahl zu beeinflussen.
Praktischen Nutzen hat Qwen Code bei der Generierung großer Mengen mit geringeren Risiken gezeigt, insbesondere in mehrsprachigen Zusammenhängen. Die Fähigkeiten des Modells im Chinesischen sind stark. Das ist für Teams relevant, die sowohl mit englischen als auch mit chinesischen Codebasen oder Dokumentationen arbeiten.
Das Muster, das wirklich wichtig ist
Nach Hunderten von Sitzungen betrifft die wichtigste Beobachtung nicht die Frage nach dem besten Tool, sondern die Bedingungen, unter denen jedes Tool erfolgreich ist. Alle scheitern vorhersehbar an mehrdeutigen Anweisungen zu unbekannten Codebasen. Alle arbeiten gut, wenn sie klare Aufgaben und relevanten Kontext erhalten und von jemandem bedient werden, der ihre Arbeitsweise gut genug versteht, um sie wirksam zu steuern.
Die Entwickler, die den größten Nutzen aus KI-Programmierwerkzeugen ziehen, sind nicht diejenigen, die das beste Tool gefunden haben. Es sind diejenigen, die eine disziplinierte Arbeitsweise entwickelt haben, die zu diesen Tools passt: in gute Spezifikationen investieren, Einschränkungen ausdrücklich vorgeben, Ergebnisse sorgfältig prüfen und die KI als fähigen Mitarbeiter mit begrenztem Kontext behandeln, statt als selbstständigen Ersatz für technisches Urteilsvermögen.
Das Tool ist wichtig. Eine disziplinierte Arbeitsweise ist wichtiger.
Weiterführende Beiträge
- Mit KI-Agenten entwickeln: Was im Produktivbetrieb tatsächlich funktioniert – die Lücke zwischen Benchmark-Ergebnissen und Zuverlässigkeit im Betrieb bei agentengestützten Workflows.
- Spezifikationsbasierte Entwicklung mit KI-Programmierassistenten – warum strukturierte Spezifikationen bei komplexen Aufgaben durchweg bessere Ergebnisse liefern als dialogbasierte Eingaben.
- Selbst betriebene LLMs zur Codegenerierung: Eine praktische Bewertung – wann lokale Inferenz wirtschaftlich sinnvoll ist und welche Kompromisse sie erfordert.