Warum Zed sich gerade wie eine IDE in Bewegung anfühlt

Ich arbeite täglich mit Zed. Deshalb ist mein Eindruck im Moment weniger von einzelnen Ankündigungen geprägt, sondern vom Gesamtbild: Zed wirkt nicht wie ein Editor mit ein paar neuen Extras, sondern wie eine IDE, an der an vielen tragenden Stellen gleichzeitig gebaut wird.

Das ist ein wichtiger Unterschied. Viele Tools wirken modern, solange man nur die große Überschrift betrachtet: AI-Feature, Agent-Modus, neues Panel, besserer Chat. Im Alltag entscheidet sich aber an ganz anderen Punkten, ob ein Werkzeug wirklich reifer wird:

• Wie fühlt sich Git-Arbeit an?
• Wie schnell kommt man durch große Diffs?
• Wie gut lässt sich die Oberfläche an den eigenen Workflow anpassen?
• Wie brauchbar sind Edit Predictions im echten Code statt in der Demo?
• Wie sauber ist die Einbettung von Agenten in den normalen Entwicklungsfluss?

Genau an diesen Punkten passiert bei Zed gerade auffällig viel.

Zed verbessert nicht nur Schlagzeilen-Features

Was Zed aktuell interessant macht, ist nicht bloß die AI-Seite. Der spannendere Punkt ist, dass sich klassische IDE-Arbeit und neue agentische Workflows gleichzeitig weiterentwickeln.

Das merkt man im Alltag sehr schnell. Ein Editor kann theoretisch tolle Modellintegration haben und sich trotzdem im Kern unfertig anfühlen, sobald man mit größeren Repositories, vielen Änderungen, mehreren Suchläufen oder häufigem Kontextwechsel arbeitet. Umgekehrt kann ein Tool bei den Grundlagen stark sein, aber bei moderner AI-Nutzung wie ein alter Editor mit aufgeklebtem Chatfenster wirken.

Zed bewegt sich gerade in die seltene Richtung, in der beides zusammenkommt:

• klassische Editor- und Git-Arbeit wird spürbar ernst genommen
• AI-Funktionen werden nicht nur hinzugefügt, sondern in die Oberfläche und den Workflow eingebettet
• Details der täglichen Nutzung werden sichtbar nachgeschärft

Genau das macht den Editor zurzeit so lebendig.

Git und Diffs werden vom Nebenbereich zum Kernworkflow

Ein guter Editor scheitert im Alltag oft nicht am Schreiben von Code, sondern an allem drumherum: Änderungen prüfen, mehrere Dateien vergleichen, zwischen Kontexten springen, Suchergebnisse auswerten, kleine Eingriffe quer durchs Projekt machen.

Deshalb ist die neue Split-Diff-Ansicht in Zed mehr als nur eine überfällige Komfortfunktion. Mit Einführung der Split-Diff-Ansicht hat Zed nicht einfach nur eine geteilte Ansicht ergänzt, wie man sie aus anderen Tools kennt. Interessant ist, wie diese Funktion gebaut wurde.

Zed benutzt für Projekt-Diffs keine lose Sammlung einzelner Dateifenster, sondern eine Multibuffer-Logik. Das klingt zunächst technisch, ist aber im Alltag spürbar: Änderungen über viele Dateien hinweg fühlen sich wie ein zusammenhängender Arbeitsraum an und nicht wie ständiges Wechseln zwischen isolierten Einzelansichten. Genau deshalb war die Einführung von Split Diffs in Zed komplizierter als in klassischen Editoren.

Der relevante Punkt für Entwickler ist aber ein anderer: Zed investiert hier sichtbar in einen Workflow, der in echter Arbeit ständig vorkommt.

Das bedeutet konkret:

• große Änderungen lassen sich lesbarer prüfen
• die linke und rechte Seite bleiben beim Arbeiten synchron
• auch größere Changesets sollen flüssig bedienbar bleiben
• Git-Arbeit wird nicht als Pflichtteil, sondern als Produktkern behandelt

Im Alltag ist das enorm wichtig. Ein Editor, der sich beim eigentlichen Schreiben schnell anfühlt, aber bei Review und Diff-Arbeit auseinanderfällt, spart am falschen Ende. Genau dort wirkt Zed im Moment reifer.

Viele kleine Verbesserungen zahlen auf echte Produktivität ein

Fast noch wichtiger als große Features sind die kleinen Arbeitsbeschleuniger. Die merkt man oft erst, wenn sie fehlen.

Zed hat in letzter Zeit mehrere genau solcher Funktionen nachgeschärft, etwa in Versteckte Funktionen: Teil 3. Das klingt nach Nebenkriegsschauplatz, ist aber in Wahrheit tief relevant für tägliche Nutzung.

Ein paar Beispiele:

• mehrere Projekt-Suchen parallel statt nur ein einzelner Suchzustand
• zusammengezogene Multiselections in einem Multibuffer, damit verstreute Treffer schneller geprüft werden können
• Settings-Profile, um Zed schnell in unterschiedliche Arbeitsmodi umzuschalten
• kleinere Editieroptimierungen, die einzeln unspektakulär wirken, sich aber über Tage und Wochen spürbar summieren

Genau hier trennt sich oft „sieht modern aus“ von „arbeitet sich schnell“. Gute Tools sparen nicht nur große Schritte, sondern auch Hunderte kleiner Reibungsmomente.

Das ist auch der Grund, warum ich Zed gerade positiv einordne: Die Entwicklung läuft nicht nur auf der Ebene großer Narrative, sondern auch auf der Ebene der täglichen Handgriffe. Wer diese Ebene ernst nimmt, baut in der Regel kein reines Demo-Produkt.

Oberfläche und Layout werden funktionaler, nicht nur hübscher

Ein weiterer Punkt, der leicht unterschätzt wird: Zed arbeitet nicht nur an Funktionen, sondern auch an der Form, in der diese Funktionen genutzt werden.

Mit dem Theme Builder für Zed geht es auf den ersten Blick „nur“ um Theming. In der Praxis ist das aber mehr. Moderne Entwicklungsumgebungen haben mittlerweile Hunderte Farb- und Zustandswerte. Wer schon einmal versucht hat, eine IDE wirklich sauber an den eigenen Geschmack oder an Teamvorgaben anzupassen, weiß, wie schnell das in JSON-Wühlen und Trial-and-Error ausartet.

Zed macht daraus einen visuellen Arbeitsprozess:

• Live-Preview der Oberfläche
• gezielte Zuordnung, welcher Token welches Element steuert
• Verknüpfung von Farben statt bloßer Einzelwerte
• Export fertiger Themes

Das ist nicht nur Kosmetik. Es zeigt, dass Zed die IDE als gestaltbaren Arbeitsraum versteht. Wer täglich acht oder mehr Stunden in einer Entwicklungsumgebung verbringt, weiß, dass Lesbarkeit, visuelle Hierarchie und Kontrast nicht bloß Geschmacksfragen sind.

Ähnlich wichtig ist die Weiterentwicklung der Oberfläche für agentische Arbeit. Mit Parallele Agenten in Zed hat Zed nicht einfach „mehr Agenten“ aktiviert, sondern die Bedienlogik dafür angepasst.

Die Kernidee ist simpel, aber stark: Wenn Agenten künftig nicht mehr nur als einzelner Chat neben dem Code existieren, sondern parallel an mehreren Aufgaben arbeiten, braucht die IDE dafür eine eigene Navigations- und Organisationsschicht.

Daraus entstehen spürbare Veränderungen:

• Threads werden als eigene Arbeitseinheit sichtbar
• mehrere Agentenläufe können parallel verfolgt werden
• Zugriffe auf Projekte und Ordner bleiben organisatorisch fassbar
• die Seitenleisten- und Panel-Logik orientiert sich stärker an realer Agentenarbeit

Das ist klug, weil Zed damit nicht versucht, neue Arbeit in eine alte UI zu pressen. Stattdessen wird die Oberfläche an den tatsächlichen Nutzungstyp angepasst.

Die AI-Seite wird tiefer, nicht nur breiter

Bei Zed ist AI schon länger kein bloßer Zusatz mehr. Spannend ist aber, dass die Entwicklung inzwischen tiefer wird.

Mit Zeta2 von Grund auf neu trainiert und Wie Zeta2 entwickelt wurde sieht man sehr deutlich, wie ernst Zed die Qualität der eigenen Edit Predictions nimmt.

Das ist für Entwickler relevanter, als es zunächst klingt. Edit Predictions sind nur dann wertvoll, wenn sie in echten Situationen helfen:

• beim Fortsetzen einer gerade begonnenen Änderung
• beim Ergänzen naheliegender Folgeschritte
• beim Nutzen von Typ- und Symbolkontext statt rein lokaler Textnähe
• bei geringer Latenz und ausreichend hoher Trefferquote

Zed beschreibt hier nicht einfach nur „wir haben ein besseres Modell“, sondern die eigentliche Arbeit dahinter:

• bessere Trainingsdaten
• sinnvollere Kontextaufbereitung
• Evaluierung vor dem Rollout
• Iteration auf Basis von Akzeptanz und Nutzung

Gerade das macht den Unterschied zu vielen AI-Ankündigungen am Markt. Dort wird oft primär die Modellmarke verkauft. Hier wird daran gearbeitet, wie ein Vorhersagesystem im Editorfluss praktisch brauchbar wird.

Aus Nutzersicht ist das entscheidend. Eine Edit Prediction muss nicht spektakulär sein. Sie muss oft genug in genau dem Moment richtig liegen, in dem man ohnehin den nächsten offensichtlichen Schritt machen würde. Wenn das gelingt, entsteht echter Geschwindigkeitsgewinn. Wenn nicht, wird sie zum Hintergrundrauschen.

Zed scheint diese Grenze sehr genau verstanden zu haben.

Agenten werden nicht daneben gestellt, sondern in den Workflow gezogen

Der vielleicht größte strategische Unterschied zu vielen anderen Tools ist, wie Zed mit Agenten umgeht.

In vielen Entwicklungswerkzeugen sitzt AI noch immer als separates Interface neben der eigentlichen Arbeit. Man chattet, kopiert Ergebnisse herüber, wechselt zwischen Kontexten und verliert dabei den Zusammenhang zwischen Denken, Schreiben, Prüfen und Ausführen.

Zed versucht sichtbar, genau das aufzulösen.

Die Richtung ist klar:

• Agenten sind nicht bloß Assistenten, sondern Teil des Arbeitsraums
• parallele Threads sollen komplexere Aufgaben zerlegen
• Ordner- und Projektgrenzen werden für Agenten sichtbar gemacht
• der Editor bleibt der Ort, an dem Steuerung und Ausführung zusammenlaufen

Das ist ein wichtiger Unterschied. Denn die eigentliche Zukunftsfrage ist nicht, ob ein Editor „auch AI“ hat. Die spannendere Frage ist, ob Codearbeit, Tooling und Agenten in einer gemeinsamen Umgebung zusammenfinden, ohne dass der Entwickler die Kontrolle verliert.

Hier gibt es auch einen interessanten Bezug zu meinem Artikel „Programmieren ist nicht tot – Teil 3: Multi-Agent ohne Extra-Tool“. Dort ist die Kernthese: Multi-Agent ist zuerst ein Rollen- und Workflow-Modell, nicht einfach eine zusätzliche Software-Kategorie. Zed bestätigt diese Sicht gerade ziemlich gut. Der Editor liefert mit Threads, Panels und Agentensteuerung die passende Arbeitsoberfläche dafür. Aber der eigentliche Produktivitätsgewinn entsteht erst, wenn man Aufgaben sauber trennt: Analyse, Implementierung, Review, Tests, QA.

Anders gesagt: Zed macht Multi-Agent-Workflows leichter zugänglich, ersetzt aber nicht die Notwendigkeit, Rollen klar zu schneiden. Deshalb finde ich die aktuelle Entwicklung dort so spannend. Die IDE nähert sich einer Form, in der diese Arbeitsweise nicht mehr wie ein Bastel-Setup wirkt, sondern wie ein natürlicher Teil des Entwickleralltags.

An dieser Stelle experimentiert Zed gerade sehr offensiv.

Beobachtbarkeit ist ein unterschätzter Reifeindikator

Ein Punkt, den ich besonders stark finde, ist Zeds Agent Metrics. Viele Produkte reden über Agenten. Wenige machen Nutzung, Tiefe und Latenzen der eigenen Agentenlandschaft sichtbar.

Warum ist das wichtig?

Weil ein Produkt erst dann wirklich reift, wenn es nicht nur Features ausliefert, sondern deren Verhalten beobachtet und einordnet.

Agent Metrics zeigt genau diese Richtung:

• Welche Agenten werden tatsächlich genutzt?
• Wie tief sind Sessions wirklich?
• Welche Modelle fühlen sich schnell an und welche nicht?
• Wie verändert sich die Lage über Wochen?

Das wirkt zunächst wie ein Nischenthema. In Wahrheit ist es ein Zeichen dafür, dass Zed AI nicht nur als Marketingschicht betrachtet, sondern als operativen Teil der IDE.

Für Entwickler ist das hilfreich, weil es eine nüchternere Perspektive auf die Toolwahl eröffnet. Nicht jede Modellankündigung ist automatisch relevant. Relevanter ist, welche Systeme im realen Editor-Einsatz tatsächlich zügig und belastbar arbeiten.

Auch die organisatorische Seite wird professioneller

Nicht alles, was gerade an Zed interessant ist, steckt in direkter Feature-Arbeit. Zwei andere Entwicklungen sind ebenfalls wichtig.

Mit Überarbeitete Nutzungsbedingungen und Datenschutzerklärung zeigt Zed, dass das Produkt inzwischen an einem Punkt ist, an dem Datenschutz, AI-Datenverarbeitung, Billing und Enterprise-Erwartungen präziser gefasst werden müssen. Das ist kein glamouröser Teil der Produktentwicklung, aber ein unverzichtbarer.

Gleichzeitig verrät Arbeiten bei Zed: Bauen in Echtzeit viel über das technische Selbstverständnis des Teams. Dort wird Zed als vertikal integriertes System beschrieben: Rendering, UI, Editor, Collaboration, Cloud und AI werden nicht lose zusammengesetzt, sondern als zusammenhängender Stack gedacht.

Das erklärt auch, warum sich viele Verbesserungen in Zed so direkt anfühlen. Wer große Teile des eigenen Stacks kontrolliert, kann Funktionsgrenzen anders verschieben als ein Team, das hauptsächlich auf bestehende UI- und Editor-Schichten aufsetzt.

Für Nutzer ist das nicht bloß Architekturromantik. Es bedeutet oft:

• schnellere Iteration an Kernfeatures
• stärkere Integration zwischen Bereichen
• weniger Flickwerk zwischen fremden Systemgrenzen

Natürlich erhöht das auch die technische Last. Aber genau diese Entscheidung scheint Zed im Moment auszuspielen.

Warum ich Zed gerade so positiv einordne

Aus meiner Sicht liegt die Stärke gerade nicht in einem einzelnen Durchbruch. Die Stärke liegt darin, dass Zed gleichzeitig an mehreren tragenden Ebenen gewinnt:

• Git und Diffs werden besser
• die Oberfläche wird anpassbarer und funktionaler
• Edit Predictions werden technischer und glaubwürdiger weiterentwickelt
• Agenten bekommen eine echte organisatorische Heimat in der IDE
• Nutzung und Modellverhalten werden messbarer
• das Gesamtprodukt wirkt erwachsener

Das ist genau die Phase, in der aus einem spannenden Editor langsam eine wirklich belastbare Entwicklungsumgebung wird.

Und genau deshalb fühlt sich Zed gerade so an, als würde sich dort wirklich etwas bewegen. Nicht nur auf der Ebene neuer Features, sondern auf der Ebene des täglichen Arbeitens.

Einordnung

Wenn ich Zed heute als tägliches Werkzeug betrachte, dann nicht mit der Frage: „Welches Feature wurde diese Woche angekündigt?“ Die entscheidendere Frage ist für mich: „Wird das Tool in den Dingen besser, die ich jeden Tag anfasse?“

Zurzeit ist die Antwort darauf ziemlich klar: ja.

Nicht in jedem Bereich perfekt. Nicht ohne Ecken. Aber mit einem Produkttempo und einer inhaltlichen Breite, die man in dieser Form nicht oft sieht. Genau deshalb halte ich Zed aktuell für eine der spannendsten IDE-Entwicklungen überhaupt.