Eine Funktion ist implementiert, aber der Regressionstest fehlt. Gleichzeitig müsste jemand die Dokumentation prüfen. Beides lässt sich auslagern — solange klar bleibt, welche Dateien bearbeitet werden und wo die Ergebnisse wieder zusammenkommen.
Genau dafür ist das jüngste Claudecode-Desktop-Update interessant. Die Ankündigung vom 14. Oktober 2026 UTC, in Peking bereits der 15. Oktober, verbindet verschachtelte Sitzungen, Vorschläge für Folgeaufgaben und sichtbarere Fortschritte. Hinzu kommen bequemere Projekteinstiege und gespeicherte Umgebungen.
Ein Teammitglied beschrieb das als „fast v2“. Ich würde daraus zunächst keine Geschwindigkeitszusage ableiten. Für die Entwicklung ist die konkretere Frage: Welche Teile einer Aufgabe lassen sich jetzt besser verteilen und anschließend prüfen?
Mit image2 erstellte Konzeptillustration, kein Screenshot der Anwendung.
1. Folgeaufgaben und verschachtelte Sitzungen unterscheiden
Die neue Oberfläche zeigt Vorschläge für Arbeiten, die sich aus einer laufenden Aufgabe ergeben. Ein solcher Vorschlag kann eine eigene Sitzung starten. Das ist beispielsweise sinnvoll, wenn bei einem Bugfix auffällt, dass eine Erklärung in der Dokumentation veraltet ist.
Eine verschachtelte Sitzung hat eine andere Rolle. Wenn Claude mehrere Aufgaben parallel bearbeiten soll, kann es solche Sitzungen anlegen und deren Ergebnisse an die Hauptunterhaltung zurückmelden lassen.
Ein Vorschlag kann zusätzliche Arbeit aus der aktuellen Unterhaltung herauslösen.
Der Unterschied ist praktisch relevant: Eine Folgeaufgabe ist zunächst eine Entscheidung über weiteren Arbeitsumfang. Verschachtelte Sitzungen helfen dagegen, bereits verteilte Arbeit wieder in der Hauptunterhaltung zusammenzuführen.
Ich würde deshalb nicht jede vorgeschlagene Verbesserung sofort starten. Für einen kleinen Fix kann ein zusätzlicher Umbau schlicht außerhalb des Auftrags liegen. Die Oberfläche erleichtert den Start; sie entscheidet nicht, was zum aktuellen Änderungsumfang gehört.
2. Vor dem Aufteilen die gemeinsame Schnittstelle festlegen
Nehmen wir als Beispiel eine Funktion, die einen Ladefehler im Frontend verständlicher anzeigen soll. Die gewünschte Fehlermeldung und das Format der Fehlerantwort sind bereits festgelegt.
Dann lassen sich zwei Prüfaufgaben gut voneinander abgrenzen: Eine Sitzung sucht fehlende Testfälle, eine andere prüft die angezeigten Texte und die Hilfe. Beide können Ergebnisse liefern, ohne die gemeinsame Schnittstelle neu zu entwerfen.
Ein möglicher Arbeitsauftrag wäre:
Prüfe die Testabdeckung und die Hilfetexte in getrennten Aufgaben. Verändere das vereinbarte Fehlerformat nicht. Melde die gefundenen Lücken und die betroffenen Dateien an diese Unterhaltung zurück.
Das ist ein Formulierungsbeispiel, kein dokumentierter Testlauf. Der wichtige Teil ist die Grenze des Auftrags: Was darf geändert werden, was steht bereits fest und welches Ergebnis soll zurückkommen?
Wenn dagegen beide Sitzungen das Fehlerformat ändern sollen, ist die gemeinsame Entscheidung noch offen. Mehr Parallelität löst diese Abhängigkeit nicht. In diesem Fall würde ich zuerst die Schnittstelle klären und erst danach unabhängige Arbeiten vergeben.
3. Separate Unterhaltungen brauchen passende Arbeitsverzeichnisse
Die aktualisierte Startansicht macht kürzlich verwendete Ordner leichter erreichbar. Häufig benötigte Umgebungen lassen sich speichern, darunter Ordnerkombinationen, SSH-Ziele und Cloud-Umgebungen. Das ist besonders beim Wechsel zwischen mehreren Projekten hilfreich.
Für Git-Projekte stehen Worktrees als getrennte Arbeitsverzeichnisse zur Verfügung. Damit können Sitzungen ihre Dateien bearbeiten, ohne direkt in dieselbe Arbeitskopie zu schreiben. Eine getrennte Unterhaltung allein ist noch keine Aussage darüber, wo ihre Änderungen landen. Vor parallelen Schreibaufgaben lohnt sich deshalb der Blick auf die ausgewählte Umgebung.
Auch bei sauber getrennten Verzeichnissen bleibt die Integration offen: Zwei Änderungen können sich auf unterschiedliche Annahmen über dieselbe Funktion stützen. Ein konfliktfreier Merge beweist noch nicht, dass das kombinierte Verhalten stimmt.
Daneben steht die Verbrauchsfrage. Wer Claudecode über einen API-Zugang abrechnet, sollte bei zusätzlichen Aufgaben auch den tatsächlichen Verbrauch prüfen; Crazyrouter erklärt die Claude-API-Abrechnung und Nutzungskontrolle. Diese API-Abrechnung ist von einem Desktop-Abonnement zu unterscheiden. Die neue Aufgabenansicht belegt für sich genommen weder geringere Kosten noch einen niedrigeren Tokenverbrauch.
4. Fortschritt lesen, dann Änderungen prüfen
Die Seitenleiste macht deutlicher, welche Sitzungen noch arbeiten, welche Aufmerksamkeit benötigen und welche fertig sind. Innerhalb einer Sitzung zeigen laufende Aufgabenlisten den Fortschritt. Rückblickkarten fassen zusammen, was in der Zwischenzeit passiert ist; die Seitenansicht bietet Informationen zu Umgebung, Kontext und Änderungen.
Die Statusanzeige hilft bei der Auswahl der nächsten Sitzung, die geprüft werden sollte.
Nach einer Unterbrechung würde ich zuerst eine Sitzung mit offenem Entscheidungsbedarf öffnen. Anschließend lässt sich die Zusammenfassung mit dem tatsächlichen Diff abgleichen: Welche Dateien wurden geändert? Wurde die vereinbarte Grenze eingehalten? Welche Prüfung stützt die Aussage, dass die Aufgabe erledigt ist?
Diese Reihenfolge hält die Statusanzeige nützlich, ohne sie mit einer technischen Abnahme zu verwechseln. Eine Karte kann den Einstieg in eine Prüfung verkürzen. Sie ersetzt weder die Prüfung der Anforderungen noch das Lesen relevanter Änderungen.
5. Rückfragen mit /btw von neuen Anforderungen trennen
Während die Hauptaufgabe läuft, lässt sich mit /btw eine Nebenunterhaltung öffnen. Unter macOS geht das auch mit Cmd + ;, unter Windows mit Ctrl + ;.
Eine kurze Verständnisfrage muss nicht die Hauptunterhaltung verlängern.
Die Funktion gab es bereits vor diesem Update. Sie wird hier im Zusammenhang mit dem überarbeiteten Arbeitsablauf gezeigt und sollte nicht als erstmals im Oktober eingeführte Funktion beschrieben werden.
Für den Einsatz ist die Richtung des Kontexts entscheidend: Die Nebenunterhaltung kennt die Hauptunterhaltung bis zu diesem Zeitpunkt. Ihre Antworten werden jedoch nicht in den Hauptverlauf zurückgeschrieben.
„Warum wird hier erneut versucht?“ passt deshalb gut in die Nebenunterhaltung. „Verzichte auf den erneuten Versuch und ändere die Implementierung“ muss als neue Anforderung in die Hauptunterhaltung. Außerdem werden Nebenunterhaltungen nicht auf der Festplatte gespeichert; nach dem Schließen der App lassen sie sich nicht wiederherstellen.
Was ich beim Update zuerst prüfen würde
Die Desktop-App wird unabhängig von einer separat installierten CLI aktualisiert. Für die Neuerungen also die App aktualisieren und eine neue Sitzung beginnen. In einer lokalen Desktop-Sitzung zeigt /status die dort verwendete Claudecode-Version.
Danach reicht ein begrenzter Auftrag mit zwei unabhängig prüfbaren Teilaufgaben. Entscheidend wäre für mich, ob deren Ergebnisse nachvollziehbar zurückkommen und ob sich offene Entscheidungen schneller finden lassen. Ein komplexer Umbau mit mehreren gemeinsam geänderten Schnittstellen wäre dafür ein unnötig unübersichtlicher erster Versuch.
Das Update verändert vor allem die Organisation der Arbeit. Sein Nutzen lässt sich daran prüfen, ob Aufgaben, Dateien und Rückmeldungen zusammenpassen — und ob am Ende noch klar ist, welche Änderung tatsächlich freigegeben werden kann.
Top comments (0)