Probieren wir mal OpenCode UI aus

Ein praxisnaher Blick auf OpenCodes neue Desktop-Oberfläche im Vergleich zu VSCode und Claude Code und darauf, wo ein GUI-Coding-Harness die Arbeit mit Agenten verbessern kann. Der Beitrag hebt OpenCodes Stärken bei Fokus, Tool-Design und Subagenten-Workflows hervor, macht aber auch deutlich, dass sich dieser Bereich noch weiterentwickelt.

Eine der größten Innovationen im Bereich des agentischen Programmierens ist sicherlich Claude Code. Davor bestand KI beim Programmieren meist darin, Fragen in einem separaten Fenster zu stellen oder ein schickes Autocomplete in der IDE zu haben. Aber Claude Code war ein ganz anderer Ansatz: Es lief außerhalb des bevorzugten Editors und hat einfach selbstständig Sachen gemacht — es konnte Dateien lesen und bearbeiten, Befehle ausführen, und man konnte es generell einfach machen lassen. Und die Magie lag nicht nur beim Agenten selbst, sondern beim Harness — also Claude Code — der den Agenten umschließt.

Seitdem sind Coding-Harnesses allgegenwärtig geworden, aber viele der aktuellen State-of-the-Art-Tools (Codex CLI, OpenCode, pi, etc.) sehen immer noch sehr nach Claude Code aus — sie sind alle shortcut-getrieben und Slash-Command-orientiert, und vor allem sind sie alle terminalbasiert — eben TUIs.

Das ändert sich aber langsam, weil immer mehr GUI-Tools rauskommen, die versprechen, dasselbe wie ihre TUI-Pendants zu können, nur eben ohne im Terminal festzustecken. Also habe ich die letzten paar Wochen damit verbracht, OpenCodes neue Desktop-Anwendung auf Herz und Nieren zu prüfen.

Meine Ausgangslage: VSCode und Claude Code

Es ist etwas seltsam, ein Review damit anzufangen, über andere Tools zu reden, aber ich möchte erst mal eine Baseline setzen, damit wir alle auf dem gleichen Stand sind. Bisher waren meine täglichen Begleiter eine Kombination aus VSCode und Claude Code. Beide sind auf ihre Art gut, haben aber unterschiedliche Stärken und Schwächen.

VSCode ist in erster Linie ein Texteditor. Das ist gleichzeitig seine größte Stärke und seine größte Schwäche. Als Stärke zeigt sich das darin, dass es ein riesiges Ökosystem an Extensions gibt, die der Agent auf verschiedene Weise nutzen kann (zum Beispiel kann der Agent auf Warnungen von vorhandenen Linting-Plugins zugreifen oder Tests von Test-Runner-Extensions ausführen). Als Schwäche zeigt sich das darin, dass man schwer vom Editor-Teil wegkommt — selbst wenn ich den Agenten-Chat auf Vollbild stelle, klappt VSCode ihn regelmäßig wieder zusammen, um mir andere Dateien oder Panels zu zeigen, die mich gar nicht interessieren. Genauso kann ich einen einzelnen Agenten-Chat in ein neues Fenster auslagern und mich darauf konzentrieren, aber dann kann ich nicht mehr einfach zwischen verschiedenen Sessions wechseln.

Das andere Problem mit VSCode ist die schiere Anzahl an verfügbaren Tools, die viele Modelle überfordern kann, besonders wenn man nur eine kleine Anzahl an eigenen Tools oder MCPs hinzufügt. Das Harness versucht zwar zu optimieren, welche Tools der Agent sieht, aber das hat seine eigenen Tücken. Sogar manche der Extension-basierten Features können manchmal im Weg stehen — wenn es einen integrierten Test-Runner gibt, aber auch die Möglichkeit, einen Testbefehl direkt auszuführen, habe ich schon erlebt, dass Agenten Zyklen und Tokens verschwenden, um herauszufinden, welche Option am besten funktioniert.

In der anderen Ecke sitzt Claude Code. Wie schon gesagt, hatte Claude Code einen enormen Einfluss darauf, wie Leute mit Agenten programmieren. Es ist ein sehr gut optimiertes Harness — wenige überflüssige Tools, die Tokens verschwenden, und die vorhandenen Tools sind so optimiert, dass Anthropics eigene Modelle sie leicht verstehen können. Es ist auch der Ort, an dem viele der Features, die wir heute als selbstverständlich betrachten, zuerst aufgetaucht sind.

Andererseits ist die UI oft schwer zu lesen. Die Beschränkungen des Terminals machen es schwierig, Hierarchien klar darzustellen, was bedeutet, dass auf den ersten Blick nicht immer klar ist, ob ein Text vom Agenten kommt, von einem Tool-Call, von Systemnachrichten oder von etwas anderem. Die fehlende Interaktivität kann die Nutzung auch komplizierter machen. Zum Beispiel muss ich, um Tool-Calls aufzuklappen, eine Tastenkombination drücken, die alle Tool-Calls global aufklappt, was eine Menge Rauschen in meinem Terminal erzeugt, durch das ich scrollen muss, um den Text zu finden, der mich interessiert.

Es muss eindeutig einen besseren Ansatz geben — etwas mit den visuellen Stärken von VSCode, aber dem Fokus auf agentisches Programmieren von Claude Code.

Vorstellung: OpenCode (als UI)

Als ich angefangen habe, mit Coding-Harnesses herumzuspielen, war eines der Tools, die mir ganz gut gefallen haben, die TUI-Version von OpenCode. Jetzt haben sie eine GUI-Version desselben Tools veröffentlicht.

Das Ergebnis ist ein sauberes Interface, das sich ähnlich wie die VSCode-Oberfläche anfühlt, aber mit Zugriff auf alles in einem einzigen Fenster. Links habe ich eine Seitenleiste mit verschiedenen Projekten, an denen ich arbeite, und für jedes Projekt kann ich zwischen verschiedenen Sessions innerhalb dieses Projekts wechseln. Rechts sehe ich eine Liste der Änderungen in dieser Session und sogar einen Dateibaum (wobei beides leider nur funktioniert, wenn der Projektordner ein Git-Repository enthält). In der Mitte, ganz vorne und im Zentrum, ist mein Chat — genau da, wo ich ihn haben will, damit ich mich darauf konzentrieren kann.

OpenCode nutzt auch die Möglichkeiten der mächtigeren GUI. Es ist einfach, eine Session genauer zu erkunden, indem man herumklickt und Dinge aufklappen lässt. Das heißt nicht, dass es perfekt ist — manche Tool-Calls haben recht begrenzte Darstellungen, was bedeutet, dass es schwer zu erkennen ist, was der Agent tatsächlich gesehen hat — aber es ist deutlich einfacher zu bedienen als die Terminal-Pendants.

Über die UI hinaus orientiert sich OpenCode auch klar an Claude Code, indem es ein schlankes, aber vollständiges Set an Tools bereitstellt. In den letzten paar Wochen mit OpenCode habe ich so gut wie nie Fälle erlebt, in denen der Agent Schwierigkeiten hatte, die verfügbaren Tools zu nutzen, oder lange überlegen musste, welches Tool er verwenden soll.

Das beeindruckendste Feature sind hier die Subagenten. OpenCodes Subagenten sind persistent, was bedeutet, dass der Agent, mit dem man arbeitet, mehrmals zum selben Subagenten zurückkehren und ihm weitere Fragen stellen kann. Ich bin kürzlich darauf gestoßen, als ein Subagent bei einem Code-Review einen Bug halluziniert hat, der gar nicht existierte. Der Hauptagent hat versucht, einen Test zu schreiben, der diesen Bug reproduziert, hat das aber nicht geschafft (weil es ihn gar nicht gab), und ist dann zum selben Subagenten zurückgekehrt, um mehr Details zu erfahren und herauszufinden, was schiefgelaufen war.

Diese mächtigen Subagenten werden in der UI auch schön dargestellt. Im Chat-Verlauf kann ich sehen, wo Subagenten-Läufe stattfinden, und darauf klicken. Das öffnet dasselbe Chat-Panel, das ich auch für die Interaktion mit dem Hauptagenten verwende, wo ich den Gesprächsverlauf sehen und sogar zusätzliche Steuerungsnachrichten senden kann. Das ist großartig für Orchestrator-Workflows, bei denen der Großteil der Arbeit von Subagenten erledigt wird, weil es bedeutet, dass ich eingreifen und Dinge korrigieren kann, wenn ein Subagent bei der Implementierung hängt.

Um das klar zu sagen: Ich glaube nicht, dass OpenCode der Gipfel dessen ist, was Coding-Harnesses sein können, zumindest noch nicht. Der UI fehlt definitiv der Feinschliff von VSCode, auch wenn sie eine deutliche Verbesserung gegenüber den Terminal-Äquivalenten darstellt. Mir ist bewusst, dass es auch andere Konkurrenten in diesem Bereich gibt, darunter Claude Code Desktop, und ich bin optimistisch, dass UIs wie diese bessere Wege darstellen, um auf einer höheren Ebene mit Coding-Agenten zu interagieren.