In den letzten Monaten habe ich mich intensiv mit Coding Agents beschäftigt. Angefangen mit dem GitHub Copilot Agent, über Google Jules, JetBrains Junie bis hin zu Kiro und OpenCode – ich habe fast alle relevanten Tools getestet und auf muench.dev beschrieben. Jetzt, wo ich (auch) Claude Code täglich im Einsatz habe, wird es Zeit für eine Zusammenfassung: Wo stehen die einzelnen Tools? Was unterscheidet Claude Code von der Konkurrenz? Und – eine Frage, die ich mir zunehmend stelle – wie schütze ich mich eigentlich vor einem Vendor-Lock-in?
Meine bisherigen Coding-Agent-Tests im Überblick
Wer meine Artikel kennt, weiß: Ich teste Dinge so lange, bis ich mir ein echtes Bild gemacht habe – mit echten Projekten, echten Fehlern und echten Erkenntnissen. Hier die Übersicht der bisher auf diesem Blog vorgestellten Agents:
JetBrains Junie
Mein erster "Wow, das klappt ja wirklich"-Moment in der Vibe-Coding-Serie. Junie ist tief in die JetBrains-IDE integriert, läuft serverbasiert und hat mich mit seinem iterativen Ansatz (Tests ausführen, Fehler korrigieren, weitermachen) wirklich beeindruckt. Einziger Nachteil: Rate-Limits treffen schnell, und wer nicht im JetBrains-Ökosystem lebt, ist außen vor.
Google Jules
Jules arbeitet in einer isolierten Cloud-Umgebung – asynchron und ohne dass man dabei sein muss. Interessanter Ansatz, aber die fehlende Interaktivität war für mich bei explorativer Entwicklung ein echtes Handicap. Für definierbare Batch-Aufgaben ein solider Kandidat.
Jules lasse ich inzwischen Code-Verbesserungen in meinen Open Source Projekten automatisch vorschlagen. Das produziert auch einiges an guten Ergebnissen. Allerdings bin ich als Mensch beim Review selbst das Bottleneck. Aber hier habe ich selten Zeitdruck. Daher ist das alles in Ordnung für mich. Generell habe ich 100 Tasks pro Tag in meinem AI Pro Account. Das ist sehr großzügig. Im Hintergrund arbeitet ein Gemini Pro Modell. Mein Anfangstest war noch mit durchwachsenen Ergebnissen. Das ist inzwischen aber alles sehr gut und brauchbar was produziert wird.
Ebenso sind die Sandboxes die Jules besser ausgestattet was den Speicherplatz angeht. Jetzt passen auch alle meine Projekte in deren Speicher.
GitHub Copilot Agent
Der bekannteste Name im Feld. VS Code-Integration ist unschlagbar, MCP-Support ist vorhanden und die Tiefe der Workspace-Analyse ist stark. Im direkten Vergleich mit Junie hatte ich allerdings etwas schlechtere Ergebnisse – und bei größeren Aufgaben musste ich die Arbeit auf mehrere Sessions aufteilen.
GitHub Copilot als asynchroner Agent
Spannend ist sicherlich die Nutzung des CoPilot auch als Helfer in GitHub Projekten selbst. Das kostet immer mindestens einen Premium-Request, wenn man eine Task verteilt. Davon habe ich in meinem Account 300 pro Monat. Geschäftlich hosten wir in unserem Team keine Kunden-Projekte in GitHub. Allerdings haben wir bei dem einen oder anderen Open Source Repository auch mal den GitHub CoPilot direkt Code prüfen gelassen. Der CoPilot meldet sich auch proaktiv in Pull Requests. Man kann das Ticket dann direkt dem CoPilot als Benutzer zuweisen und er arbeitet los.
Das ist schon sehr praktisch. Allerdings nutze ich den CoPilot selbst nur selten.
OpenAI Codex
Das Cloud-basierte Modell von OpenAI direkt als Agent. Gut für isolierte Tasks, aber mit der bekannten Cloud-Abhängigkeit und den üblichen Datenschutz-Abwägungen.
Ich habe Codex sehr zu schätzen gelernt. Er fragt weniger nach als Claude (mein subjektiver Eindruck). Die Ergebnisse von Codex bewerte ich meistens als sehr gut. Daher sehr zu empfehlen. Codex lässt sich auch über ein offizielles Plugin in Claude einbauen um dort Tokens zu sparen.
Codex CLI
Das CLI-Tool von OpenAI – kompakter als der vollständige Codex, aber flexibel einsetzbar. Für meinen Linux-Setup war es anfangs ein fester Bestandteil geworden. Hier nutze ich aber inzwischen Codex nur in Verbindung mit OpenCode.
Vibe-Coding mit Qwen Code
Qwen Code ist der Open-Source-Vertreter aus dem Hause Alibaba. Wer lokale Modelle bevorzugt oder keine Cloud-Daten möchte, wird hier fündig. Performance auf Augenhöhe mit den großen Playern – zumindest für eine bestimmte Klasse von Aufgaben. Qwen Code müsste ich mir neu anschauen. Daher habe ich keine aktualisierte Meinung.
Kiro
Kiro von AWS hat mich mit seinem "Spec-Driven Development"-Ansatz überrascht: erst Spezifikation, dann Implementierung. Der strukturierte Ansatz reduziert Missverständnisse zwischen Entwickler und Agent – aber auch hier: tief im AWS-Ökosystem verankert.
Damals hatte ich nur so "semi gute" Ergebnisse. Das Tool müsste ich heute nochmal neu bewerten.
OpenCode
Mein Favorit für maximale Flexibilität. OpenCode läuft mit fast jedem Modell, unterstützt MCP, hat eine schicke TUI und hält mich unabhängig von einem einzelnen Anbieter. Genau darum geht es mir.
Leider blocken sowohl Google als auch Anthropic die Nutzung über die Subscriptions. Man kann die Modelle aber per API anbinden.
OpenCode gefällt mir weiterhin sehr gut. Die TUI ist einfach schön und gut bedienbar. Auch in Gitlab CI habe ich OpenCode an den Start gebracht. Das ist einfach ein tolles und vielseitiges Tool. OpenCode verwende ich wie oben schon geschrieben inzwischen nur noch mit Codex und ich habe auch meinen GitHub CoPilot Account verknüpft. Damit kann man einfache Tasks in z.B. Sub-Agents an das nicht Token-limitierte GPT 4.1 Modell delegieren.
Vendor-Lock-in
Zwischen all den Feature-Vergleichen und Benchmark-Diskussionen geht eine Frage oft unter: Was passiert, wenn das Tool, auf das ich mich eingelassen habe, plötzlich die Preise erhöht, den Dienst einstellt oder – wie im Fall von Anthropic und OpenCode – politisch eingreift?
In meinem OpenCode-Artikel habe ich das bereits angesprochen: Anthropic hat zeitweise signalisiert, dass sie es nicht mögen, wenn Claude-Modelle über Drittanbieter-Tools wie OpenCode genutzt werden. OpenAI hat diesen Sachverhalt nun genutzt, um OpenCode öffentlich seine Unterstützung auszudrücken. Da ist Politik im Spiel – und das erinnert mich daran, dass ich meinen Tool-Stack nicht auf einem einzigen Anbieter aufbauen will.
Das Risiko ist real und betrifft mehrere Ebenen:
Modell-Abhängigkeit: Wenn mein Workflow nur mit Modell X funktioniert, bin ich erpressbar. Ändert sich die Pricing-Struktur oder werden bestimmte Nutzungsszenarien eingeschränkt, stehe ich vor einem Migrations-Problem.
Tool-Abhängigkeit: Wenn das CLI-Tool oder die IDE-Extension nur mit einem bestimmten Backend kommuniziert, ist der Wechsel aufwändig. Copilot ist hier das Paradebeispiel: tief in das Microsoft/GitHub-Ökosystem eingebettet, was Stärke und Schwäche zugleich ist.
Workflow-Abhängigkeit: Wenn ich meine CLAUDE.md, meine MCP-Server-Konfiguration und meine Skills auf eine Plattform zugeschnitten habe, kostet ein Wechsel eventuell einiges an Arbeitszeit.
Meine Antwort darauf ist kein Purismus, sondern pragmatische Diversifikation.
Zum Glück gleichen sich aber auch die Agenten in bestimmten Bereichen immer mehr an. So können z.B. Agent Skills quasi in allen Systemen genutzt werden. Auch die Ablage der Skills im Dateisystem wird immer mehr genormt.
Und jetzt: Claude Code
Ich habe bereits über die Installation von Claude Desktop unter Linux geschrieben. Claude Code ist nochmal eine andere Geschichte – und aktuell mein bevorzugtes Tool für intensive Entwicklungsarbeit.
Was Claude Code von den anderen unterscheidet
Der entscheidende Unterschied liegt nicht in den Features – fast alle modernen Agents können heute Dateien lesen, Code schreiben, Tests ausführen und Fehler korrigieren. Claude Code unterscheidet sich aus meiner Sicht in vier Punkten:
Qualität der Code-Analyse: Claude hat das tiefste Verständnis für bestehende Codebasen, das ich bisher erlebt habe. Es erkennt nicht nur, was der Code tut, sondern auch warum er so strukturiert ist. Das führt zu Vorschlägen, die sich nicht wie "generiert" anfühlen, sondern wie von einem Kollegen geschrieben, der den Code wirklich gelesen hat.
Das CLAUDE.md-Prinzip: Ähnlich wie GitHub Copilots copilot-instructions.md oder Kiros Spec-Ansatz setzt Claude Code auf eine CLAUDE.md-Datei als Projekt-Kontext. Ich definiere einmal Coding-Standards, Architekturentscheidungen und Was-nicht-zu-tun-ist – und Claude Code arbeitet konsequent darin. Das spart enorm viel Korrekturaufwand.
Was ich inzwischen auch mache ist die CLAUDE.md Datei auf die AGENTS.md verweisen zu lassen. In der Art wie Claude mit der Datei umgeht sehe ich schon Unterschiede zu den anderen Agenten. Hier ist Claude einfach das Maß der Dinge.
MCP als First-Class-Feature: Das Model Context Protocol (MCP) ist nicht zufällig das Protokoll, das ich am meisten nutze – Anthropic hat es entwickelt. In Claude Code ist MCP keine Erweiterung, sondern der Kern des Tool-Konzepts. Das merkt man in der Stabilität der Integration und in der Tiefe der möglichen Automatisierungen.
Wenn es sinnvoll ist und kein Skill ausreichend ist, erstelle ich MCP Server für wichtige Workflows wie z.B. das Anlegen von Drafts in meinem Blog.
Oft reicht aber auch ein einfacher Agent Skill aus. Da auch die Agent Skills ebenfalls ursprünglich von Anthropic stammen sind diese natürlich auch bestens integriert. In vielen Fällen sind die Skills sogar effizienter als MCP selbst. Aber egal was ich davon nutze, Claude ist eben genau dabei immer etwas vor der Konkurrenz.
Desktop Integration
Claude ist sehr gut in den Desktop integriert und ist hier Vorreiter. Die anderen Anbieter versuchen gerade nachzuziehen. Es gibt auch einen Codex Desktop oder OpenCode Desktop. Hier hat Anthropic einen guten Vorsprung und erlaubt es jetzt auch, dass auch Nicht-Entwickler das Tool im Arbeitsalltag einsetzen können.
Mein aktueller Stack
Nach all diesen Tests bin ich zu einer klaren Erkenntnis gekommen: Es gibt nicht den einen Coding Agent. Und ehrlich gesagt gilt das nicht nur für Agents – auch beim klassischen Chat-Interface setze ich bewusst auf mehrere Anbieter.
Coding Agents
- Intensive Entwicklungsarbeit & Architekturentscheidungen: Claude Code – hier ist die Modellqualität entscheidend, und die API-Kosten rechtfertigen sich durch die Ergebnisqualität. Skills und MCP-Server (die Anthropic selbst erfunden hat) sind hier am besten integriert. Auch das Ökosystem zum Teilen von Agents und Skills über Plugins und Marktplätze ist schon sehr ausgereift.
- Daily Driver mit Provider-Flexibilität: OpenCode mit OpenAI Codex als Backend – das gibt mir die Unabhängigkeit, die ich brauche, und hält mich nicht an ein einzelnes Modell gebunden.
- Autonome Code-Verbesserungen: Google Jules im Hintergrund – vor allem für automatische Vorschläge in meinen Open-Source-Projekten. Mit 100 Tasks pro Tag im AI Pro Account ist das sehr großzügig. Dass ich als Mensch beim Review das Bottleneck bin, nehme ich in Kauf. Bei Open-Source-Projekten habe ich selten Zeitdruck.
- Antigravity: Ebenfalls im Einsatz, wenn es darum geht, Coding-Aufgaben asynchron und toolgestützt zu delegieren.
Chat-Interfaces
Der Coding Agent ist aber nur eine Seite meines KI-Stacks. Für Recherche, Konzeption, Textentwürfe und ad-hoc-Fragen nutze ich ganz bewusst verschiedene Chat-Interfaces – und bin auch hier an keinen Anbieter gebunden:
- Claude Desktop – mein täglicher Begleiter, auch unter Linux. Ich habe das Setup bereits in einem eigenen Artikel beschrieben.
- Google Gemini – vor allem wenn es um große Kontextfenster geht oder ich eine zweite Meinung zu einer Architekturentscheidung brauche.
- ChatGPT – nach wie vor ein solides Interface, das ich regelmäßig nutze.
- Mistral – als europäische Alternative schätze ich Mistral, gerade wenn es um datenschutzsensible Themen geht. Die Modelle haben sich in letzter Zeit deutlich verbessert.
Das ist kein dogmatisches Setup, sondern ein lebendiges. Wenn in drei Monaten ein neuer Agent oder ein neues Chat-Interface einen dieser Slots besser besetzt, tausche ich ihn aus. Genau das ist der Punkt: kein Lock-in, sondern Entscheidungsfreiheit.
Was ist euer Stack? Und wie geht ihr mit dem Vendor-Lock-in-Thema um? Ich bin gespannt auf eure Perspektiven in den Kommentaren.