- Die Integration von Claude Code und Zed ist als öffentliche Beta gestartet
- Mit der Einführung des neuen Agent Client Protocol (ACP) wird die Anbindung an verschiedene Agenten erweiterbar
- Entwickler können Claude Code in Zed in Echtzeit, über mehrere Dateien hinweg und mit benutzerdefinierten Workflows nutzen
- Der ACP-Adapter für Claude Code wurde als Open Source veröffentlicht und kann dadurch auch in anderen Editoren genutzt werden
- Künftig werden auf Basis von ACP eine bequeme Erweiterung und Nutzung verschiedener KI-Agenten erwartet
Einführung
- Auf wiederholte Nachfrage von Entwicklern wurde die native Integration von Claude Code in den Editor Zed als öffentliche Beta veröffentlicht
- Diese Integration ist nicht nur ein einfaches Plugin, sondern basiert auf dem neuen offenen Standard Agent Client Protocol (ACP)
- ACP ist ein Standard, der nicht nur in Zed, sondern auch in anderen Editoren die Verbindung mit verschiedenen Agenten ermöglicht
Hauptfunktionen
- Claude Code kann in Zed als voll funktionsfähiger Agent ausgeführt werden
- Damit geht es über eine einfache Terminal-UI hinaus und eröffnet vielfältige Einsatzmöglichkeiten in einem leistungsstarken Editor
- Änderungen in mehreren Dateien gleichzeitig lassen sich in Echtzeit zusammen mit Language-Server-Unterstützung nachvollziehen
- Über Multi-Buffer werden detaillierte Reviews von Code-Änderungen sowie deren Annahme oder Ablehnung unterstützt
- Aufgabenlisten können in der Seitenleiste angeheftet werden, sodass der aktuelle Arbeitsstand stets sichtbar bleibt
- Mit benutzerdefinierten Slash-Commands lassen sich wiederkehrende und häufig genutzte Entwicklungsaufgaben als automatisierte Workflows aufbauen
Hintergrund und Integrationsweise
- Die Integration überwindet die Grenzen der bisherigen Terminal-CLI und bietet durch die tiefe Einbindung in Zed eine umfassendere Code-Verwaltung und Kontrolle
- Claude Code kann gemeinsam mit Zeds eigenen Agenten wie Gemini CLI verwendet werden, ebenso ist die kombinierte Nutzung mit allen ACP-kompatiblen Agenten möglich
- Die Integration erfolgt über einen Adapter, der das Claude Code SDK in das JSON-RPC-Format von ACP übersetzt
- Dieser Adapter läuft eigenständig, während Zed die UI bereitstellt, was flexible Erweiterungsmöglichkeiten zeigt
Open Source und Erweiterbarkeit
- Der ACP-Adapter für Claude Code wurde unter der Apache-Lizenz als Open Source veröffentlicht und kann in allen Editoren genutzt werden, die ACP unterstützen
- Als Beispiel unterstützt das Plugin CodeCompanion für Neovim bereits ACP und ermöglicht damit die Nutzung von Claude Code
- Der GitHub-Nutzer Xuanwo hat eine ACP-Implementierung für Claude Code schnell vorangetrieben und damit zur Verbreitung des Protokolls beigetragen; dafür wurde ausdrücklich gedankt
Ausblick und Möglichkeiten zur Beteiligung
- Künftig sollen neben Gemini CLI und Claude Code noch viele weitere Agenten unterstützt werden
- Über ACP können auch andere KI-Agenten frei in verschiedenen Editoren wie Zed und Neovim eingesetzt werden
- Viele Kernfunktionen von Claude Code werden derzeit bereits über das SDK unterstützt; weitere Funktionen sollen künftig hinzukommen
- Sowohl Entwickler als auch Agenten-Ersteller sind eingeladen, sich in der Community an ACP und an der Entwicklung des Claude-Code-Adapters zu beteiligen und Feedback zu geben
Hinweise und Beteiligungsmöglichkeiten
- Agenten-Entwickler können Kontakt aufnehmen, wenn sie eine Integration mit Zed wünschen
- Wer sich mehr Funktionen für Claude Code wünscht, sollte Anthropic zur Unterstützung über SDK oder zur Einführung von ACP ermutigen
- Beiträge und Diskussionen zu den Open-Source-Projekten (ACP, Claude-Code-Adapter) sind willkommen
Weitere Hinweise
- Zed kann unter macOS und Linux heruntergeladen und verwendet werden
- Wer sich für die Zukunft der Softwareentwicklung interessiert, wird auf die Team-Karriereseite verwiesen
3 Kommentare
Unter Windows kann es auch über
scoopinstalliert werden.Zed steckt offenbar ziemlich viel Arbeit in die AI-Integration.
Agent Client Protocol (ACP)
Zed - der schnellste AI-Code-Editor
Der kollaborative Code-Editor "Zed" ist jetzt Open Source
Hacker-News-Kommentare
Ich mag Zed wirklich sehr und freue mich, dass es jetzt native Unterstützung für Claude gibt; früher habe ich es separat integriert und mich dabei an diesem Blogbeitrag orientiert.
Die KI-Autovervollständigung bleibt aber weiterhin enttäuschend; ich habe sowohl Zeds eigene Lösung als auch supermaven (inzwischen in Cursor aufgegangen) ausprobiert, aber Cursors KI-Autovervollständigung und Vorhersagen waren deutlich präziser (auch das Laden von Dateien per Suche funktioniert in Cursor genauer).
Dass Zed Finanzierung erhalten hat, macht mich noch gespannter; Zed könnte als hochwertige neue IDE, die nicht auf VSCode basiert, mit Cursor konkurrieren.
Ich war überrascht, dass es in Zed bisher keine Möglichkeit gibt, lokale Autovervollständigungs-KI wie Ollama selbst hinzuzufügen; selbst kleine Modelle mit etwa 1,5b Parametern wie Qwen 2.5 coder laufen für meine Zwecke schnell genug und passen gut zu meinem Einsatzszenario. Sie funktionieren auch ohne Internetverbindung, deshalb sind sie für mich unverzichtbar.
Es wäre schön, wenn eine Firma wie Zed eine kaufbare Version ihres eigenen Autovervollständigungs-KI-Modells in Form eines lokal ausführbaren Produkts anbieten würde (statt wie jetzt serverbasiert zur Miete möchte ich es direkt kaufen und lokal ausführen).
Ein Modell mit 10–15b Parametern, das auf Programmierdokumentation/-bücher sowie Business-Writing-Daten fokussiert trainiert ist, wäre großartig. Für einen Agenten, der das Coding-Wissen von Qwen Coder mit der Professionalität und Vorhersagbarkeit von IBM Granite 3 verbindet, wäre ich sogar bereit, einen ziemlich hohen Preis zu zahlen, besonders wenn regelmäßig neue Dokumentation, Bugfixes, GitHub-Threads usw. einfließen würden.
Da stimme ich auch zu: Cursors KI-Autovervollständigung ist mit Abstand die effizienteste und hilfreichste Funktion, nicht der Agent.
Ich frage mich, ob das Augment-Team ein Zed-Plugin entwickelt.
Ich nutze Augment seit über einem Jahr in JetBrains-IDs, und sowohl die Autovervollständigung als auch der Cursor-artige Agent haben mich sehr beeindruckt.
Ich habe auch Cursor ausprobiert, war mir aber nicht sicher, ob man dafür wirklich eine eigene IDE braucht (ein Plugin schien mir ausreichend). Einige meiner Kollegen sind von Cursor zu Augment gewechselt und finden Augment besser.
Augment hat zwar eine Website, ist aber als KI-Tool den meisten Entwicklern noch nicht wirklich bekannt.
Momentan nervt mich Cursors Autovervollständigung, weil sie viel zu aggressiv eingreift; es ist fast unmöglich, überhaupt noch Code einzugeben. Es fühlt sich an, als würde nicht nur Tab, sondern sogar CMD abgefangen.
Zed hat bei der Qualität der Codegenerierung noch Schwächen, aber allein die Tatsache, dass es keine Electron-App ist, macht das mehr als wett.
Ich würde Zed gern nutzen, aber der Helix-Modus wirkt noch unausgereift. Der Vim-Modus klingt zwar ordentlich, aber vom Helix-Modus komme ich nicht so leicht los.
Ich habe auch die Helix-Eingabekonfiguration stark an meine Bedürfnisse angepasst, und inzwischen fühlt es sich so an, als würde man Editoren nach dem bevorzugten Eingabemodell auswählen – fast wie in der Zeit vor LSP, als man Editoren nach sprachspezifischen Funktionen auswählte.
Es wäre schön, wenn es eine gemeinsame Schnittstelle gäbe, um solche Textbearbeitungs-Engines leicht an Editoren anzudocken. Der Reibungsverlust beim Wechsel auf einen neuen Editor ist einfach zu groß.
Ich sehe das genauso; ich habe mir auch schon einen Editor mit vollständig getrenntem, pluginartigem Bearbeitungsmodell vorgestellt.
Soweit ich mich erinnere, war der Editor Yi so aufgebaut (man konnte verschiedene Bearbeitungsmodelle wie Emacs-/Vim-Stil kompilieren und anhängen).
Ich habe nicht nur Emacs und Vim, sondern auch Helix und Kakoune benutzt, und wenn man alles rund um Features und Plugins aufbaut, kommen irgendwann Grenzen oder Ermüdung auf.
Zed wurde kürzlich neu gestaltet und arbeitet daran, einen Helix-Modus hinzuzufügen sowie das Bearbeitungsmodell zu modularisieren (noch in einem frühen Stadium, aber Bugs werden schnell behoben). Ich will ihm noch einmal eine Chance geben.
Auch diese Diskussion und der Editor Ki sind sehenswert; es gibt auch einen Vergleich von Ki und Helix (Link).
Ich mochte Kakoune lieber als Helix, weil es konsistenter wirkte. Wenn man solche Bearbeitungsmodelle leicht austauschen könnte, könnte man Editoren nach ihren Funktionen auswählen, ohne unnötige Trade-offs bei der Wahl des Bearbeitungsmodells einzugehen.
Interessanterweise kann man Ki auch in VSCode nutzen (wie Vim ebenfalls), aber VSCode ist mir zu schwergewichtig und zu langsam.
Neovim kann im Server-Modus laufen, sodass andere Editoren Eingaben dorthin schicken können und Neovim die Puffer zurückliefert. Ich verwende in VSCode statt der Vim-Erweiterung die Neovim-Erweiterung und nutze dadurch faktisch meine bestehende Neovim-Konfiguration und Plugins unverändert weiter.
Wenn Helix ebenfalls nur einen Server-Modus unterstützen würde, ließe es sich leicht in jeden Editor integrieren.
Soweit ich das sehe, ist die LSP-Unterstützung in Helix ziemlich gut. Von den Sprachen, die ich bei der Arbeit nutze, hapert es nur bei GraphQL an Dingen wie automatischer Einrückung.
Wer in emacs eine helixähnliche Erfahrung möchte, dem würde ich meow-mode empfehlen. Ich bin zwar kein helix-Nutzer, aber mit meow dürfte sich ein Helix-Stil wohl nicht schwer umsetzen lassen.
Wenn man ohnehin schon an Vim-Shortcuts gewöhnt ist, frage ich mich, ob Helix’ object-then-action wirklich so wertvoll ist.
Ich hatte genau dasselbe Problem. Ich hatte mich ebenfalls sehr auf den helix-Modus gefreut und ihn ausprobiert, nur um festzustellen, dass keiner meiner Backspace-Shortcuts funktionierte. Nach kurzem Testen bin ich wieder zu helix zurückgekehrt.
Als ich die Zed-Website in Safari geöffnet habe, ist mein iPhone 11 Pro wiederholt abgestürzt. Genauer gesagt sind nicht nur Safari, sondern gleichzeitig auch andere Apps und sogar die Bluetooth-Verbindung ausgefallen. So etwas habe ich noch nie erlebt, technisch fast schon „innovativ“.
idevicesyslog.Mir gefallen das Konzept und die grundlegende Architekturphilosophie von Zed; ich wünschte, es gäbe mehr Tools wie Zed.
Allerdings machen mehrere kleine Punkte die Eingewöhnung an Zed schwer.
Erstens ist die Verwaltung der Einstellungen etwas verwirrend, sodass ich oft einfach schnell die Datei
settings.jsonöffnen möchte (es wäre gut, wenn man sie direkt aus dem Einstellungsfenster öffnen könnte), und noch besser wäre es, wenn diese Datei nach einem Neustart von Zed automatisch wieder geöffnet würde.Zweitens finde ich es schade, dass man LLMs ohne native Tool-Calling-Unterstützung verwenden möchte, dafür aber weder Alternativen noch Workarounds vorhanden sind.
Drittens wirkt die UI aus Sicht von Einsteigern etwas komplex und unruhig.
Ich nutze Zed zwar noch nicht ernsthaft, wäre aber bereit, es noch einmal zu versuchen. Insgesamt wirkt es wie ein Tool, das für eine ingenieurzentrierte Denkweise optimiert ist – gut für Power-User, aber potenziell eine Einstiegshürde für neue Nutzer.
Diese Nachteile sind keine fatalen Hindernisse, aber sie bringen mich dazu zu denken: „Ich warte noch ein bisschen und probiere es später noch einmal.“
Viele kleine Details und Unannehmlichkeiten werden schnell verbessert; die meisten Dinge, die noch vor einem halben Jahr störend waren, wurden inzwischen gepatcht.
In Zed gibt es jetzt offenbar einen Shortcut, um
settings.jsondirekt zu öffnen (Ctrl+,).Ich vermute, dass sich dieser Shortcut auch anpassen lässt.
Mir gefällt Zeds Philosophie, und ich habe auch nichts gegen einen Editor, der sich an Power-User richtet, aber das Syntax-Highlighting war letztlich zu schwach – besonders die farbliche Unterscheidung von Funktionen, Argumenten und lokalen Variablen. Deshalb habe ich am Ende aufgegeben.
Wahrscheinlich liegt das daran, dass ich ein komplexes System wie in SublimeText gewohnt bin, bei dem sich die „Kontexte“ eines Themes flexibel trennen lassen. Die Keybindings im Vim-Modus sind zwar auch etwas verwirrend, aber daran könnte ich mich wohl gewöhnen.
Trotzdem will ich es bald noch einmal versuchen; die KI-Funktionen sehen definitiv cool aus.
Beim Ausprobieren hatte ich das Gefühl, dass noch ein paar wichtige Funktionen fehlen.
/new) ist wenig zugänglich, ebenso die fehlende Unterstützung für den Befehl/clear.Durch die Kombination aus nativen Shortcuts und Vim-Keybindings ist der Workflow in Zed ziemlich leistungsfähig; insbesondere die Shortcuts zur Fensterverwaltung sind sehr gut und waren der entscheidende Grund, warum ich bei manchen VSCode-Einsätzen zu Zed gewechselt bin.
Es liefert mir die neovim+tmux-Kombination, die ich wollte, ganz einfach ohne komplizierte Konfiguration.
Allerdings gibt es kein Undo für das Löschen von Dateien, und die KI-Autovervollständigung ist so schlecht, dass ich sie deaktiviert habe.
Im Arbeitsalltag nutze ich weiterhin vscode, und Zed fühlt sich noch so an, als stünde es kurz davor, meine Haupt-IDE zu werden, bleibe aber irgendwo dazwischen hängen (wenn nur ein paar Schwächen behoben würden, könnte ich komplett wechseln).
Für die Aufrechterhaltung des Investments ist ein Fokus auf KI-Funktionen vermutlich das Beste, aber genau das scheint mir nicht das zu sein, was Zed am dringendsten braucht.
vimrcwürde nativ unterstützt; ich habe keine Lust, Shortcuts alle einzeln ins Zed-Format umzuschreiben.Nur als Hinweis: Wenn man SSH-basierte Remote-Entwicklung nutzt, funktioniert dieses Feature in Zed nicht.
Zugehöriger Tweet
Schade – ich nutze Zed für Container-Entwicklung in einer Remote-Umgebung via SSH und möchte die Agentenfunktion aus Sicherheitsgründen zumindest so einschränken, dass sie nur auf mein Repository-Verzeichnis wirkt.
Ich bin gerade dabei, meine Entwicklungsumgebung in Container und SSH-Remote-Verbindungen zu verlagern.
Ich frage mich, warum das so ist – ob es nur ein vorübergehendes Support-Problem ist oder ob es grundsätzlich nicht vorgesehen ist.
Ich finde Zed wirklich hervorragend. Wenn die UI von VS Code auch nur ein bisschen mehr wie die von Zed wäre, würde ich sofort komplett wechseln.
Nutzt das hier jemand unter Linux? Mir kommt die Performance dort etwas schwach vor.
Ehrlich gesagt ist auch vscode unter Linux (besonders im Vim-Modus) nicht wirklich zufriedenstellend.
Mich würde interessieren, was dir an der UI konkret fehlt.
Mich würde interessieren, worin Zeds Vorteile liegen.
Zed gefällt mir von allen Editoren, die ich in den letzten Jahren benutzt habe, am besten. Die KI-Unterstützung habe ich allerdings noch nicht ernsthaft ausprobiert.
Ich erkenne die Arbeit des Zed-Teams an, aber ehrlich gesagt kann ich mir im Moment kaum vorstellen, VSCode zu verlassen und zu einem neuen Tool zu wechseln.
Mit Plugins, Einstellungen, der Verwaltung mehrerer Profile usw. bin ich an VSCode einfach zu sehr gewöhnt, und wegen seiner enormen Erweiterbarkeit sehe ich keinen großen Grund, eine Alternative zu benutzen.
Ich nutze zwar auch IDEs wie IntelliJ, aber die Universalität und Anpassbarkeit von VSCode finde ich für mich weiterhin attraktiv.
Ich habe wenig Motivation, den Editor zu wechseln oder mehr als einen zu verwenden.
Neovim nutze ich auch ein wenig, aber am Ende drehte sich dort vieles nur um Konfigurationsarbeit.
Interessante Perspektive. Ich meide VSCode konsequent – zu langsam, zu schwergewichtig, schlechte UI, und es fühlt sich zunehmend so an, als würde man immer stärker an Microsoft gebunden.
Ohne Zed würde ich wohl einfach weiter helix, neovim und emacs verwenden.
Der Hauptgrund, warum ich Zed VSCode vorziehe, ist, dass Eingaben ohne selbst kleinste spürbare Verzögerung sofort reagieren.
VSCode hat immer ein minimales Delay, und genau das stört mich dauerhaft, weshalb mir Zed besser gefällt.
Ich wollte VSCode auch mögen, aber ich spüre Eingabeverzögerung, und wenn mehrere Docker-Container laufen (besonders auf dem Mac über VMs), wird VSCode so schwerfällig, dass das ganze System langsamer wird.
Auch die Einstellungen sind umständlich; insgesamt wirkt alles inkonsistent und unnötig kompliziert.
Emacs hat zwar ebenfalls schwache Seiten, aber seine Designphilosophie ist besser durchdacht als die von VSCode.
Zed ist ein Editor mit sinnvoller Grundausstattung und vielen eingebauten Funktionen, deshalb nutze ich es meistens als Alternative zu emacs.
Vor allem das Hinzufügen von Lintern und Formattern dürfte bei den Einstellungen leichter auffindbar sein, aber in 95 % der Fälle bin ich zu 95 % zufrieden.
Es gibt immer eine „bessere Mausefalle“; manche bleiben bei dem, was sie gewohnt sind, andere probieren ständig neue Tools aus.
Egal wie stark ich VSCode anpasse, richtig passen will es mir nicht.
Es ist weder einfach genug noch eine vollständige IDE und bleibt deshalb immer ein paar Prozent hinter meinen Erwartungen zurück.
Im Moment nutze ich parallel einen einfachen Editor (SublimeText, NeoVim) und eine IDE (IntelliJ), jeweils je nach Zweck.
Zed wirkte eine Zeit lang auch noch rau, aber ehrlich gesagt ist es absolut einen weiteren Versuch wert.
Persönlich versuche ich, in VSCode so wenige Plugins wie möglich zu verwenden (Plugins sind grundsätzlich riskant); bei WASM-basierten Zed-Plugins hätte ich dank der Sandbox-Beschränkungen etwas mehr Vertrauen in die Sicherheit.
Ich stimme zu, dass die Typescript-Unterstützung in VSCode besser ist als in Zed (auch in komplexen Projekten funktioniert sie gut).
Bei der Arbeit nutze ich VSCode, für private Projekte eher Zed oder Helix; für AI stuff Zed, sonst meistens Helix.