Zed — wydajny edytor kodu ze współpracą w czasie rzeczywistym

Wybór edytora kodu wydaje się tematem rozstrzygniętym. VS Code wygrał, JetBrains trzyma swoją niszę, a reszta jest kwestią gustu i nawyków. Tyle że w ostatnich dwóch latach doszło kryterium, którego pięć lat temu nie było: edytor przestaje być miejscem, w którym piszemy kod, a staje się miejscem, w którym nadzorujemy pracę agentów. A to zmienia listę pytań, które warto zadać.

Zed (github.com/zed-industries/zed) jest edytorem napisanym w Ruście przez twórców Atoma i Tree-sittera, znanym głównie z dwóch rzeczy: wydajności i współpracy w czasie rzeczywistym. Oba te opisy są prawdziwe i oba są dziś niepełne.

Najlepszym dowodem jest struktura jego własnej dokumentacji. Katalog poświęcony funkcjom AI ma 28 plików. Katalog o współpracy — trzy. To nie jest przypadek ani zaniedbanie; to zapis tego, gdzie w 2026 roku leży środek ciężkości projektu. Poniżej: trzy drogi uruchamiania agentów w Zedzie (z Claude Code włącznie), piaskownica systemowa wraz z jej granicami, współpraca na żywo z jednym istotnym ostrzeżeniem — i uczciwa ocena, gdzie ten edytor ma sens w stacku PHP.

Stan projektu

Dane z API GitHuba na 25 września 2026:

89 999 gwiazdek i 10 511 forków — jeden z najpopularniejszych projektów na GitHubie w ogóle,
repozytorium założone 20 lutego 2021, kod w Ruście, ostatni commit z 9 września 2026,
98 commitów w tygodniu — tempo, jakiego nie widzieliśmy w tej serii u żadnego innego projektu,
ostatnie stabilne wydanie v1.18.1 z 4 września 2026, obok kanału przedpremierowego (-pre) i — co widać w commitach — pracy już nad v1.21.0. Kadencja jest tygodniowa,
3203 otwarte zgłoszenia,
licencja: GPL-3.0-or-later w zasadniczej części, z komponentami na Apache-2.0 tam, gdzie jest to oznaczone.

Warto docenić uczciwość README w sprawie modelu: projekt jest rozwijany przez Zed Industries, Inc., spółkę nastawioną na zysk, a wsparcie finansowe przez GitHub Sponsors idzie na ogólne przychody firmy, przy czym — cytując wprost — nie są z nim związane żadne przywileje ani uprawnienia. Rzadko spotykana precyzja w miejscu, w którym większość projektów obiecuje odznaki i priorytetowe wsparcie.

Na marginesie, jako sygnał kultury inżynierskiej: dokumentacja rozwojowa opisuje profilowanie przez samply i tracing z Tracy, z uwagą, że profilować należy w kompilacji wydaniowej, bo „nie chcesz gonić spowolnień, które nie istnieją". Wydajność jest tu przedmiotem pomiaru, nie hasła.

Trzy drogi uruchamiania agentów

To jest najważniejsza część i miejsce, w którym Zed proponuje coś, czego nie ma w innych edytorach w tej formie. Zamiast jednego wbudowanego asystenta są trzy równoprawne ścieżki.

1. Zed Agent — agent natywny. Korzysta z modeli skonfigurowanych w edytorze (hostowanych przez Zeda, przez klucze API dostawcy, przez logowanie subskrypcją, przez gatewaye albo z modeli lokalnych) oraz z wbudowanych narzędzi, profili, skilli, instrukcji i serwerów MCP.

2. External Agents — agenci zintegrowani przez Agent Client Protocol (ACP), otwarty protokół ze własną specyfikacją. Podział odpowiedzialności jest tu precyzyjny i wart zapamiętania: Zed hostuje wątek w panelu agenta i na pasku wątków, a agent zewnętrzny ma własny proces, uwierzytelnianie, wybór modelu, narzędzia i konfigurację. Instaluje się je z rejestru ACP wprost w edytorze, a lista obejmuje Claude, Codex, OpenCode, Copilot, Cursor i Pi Coding Agent.

3. Terminal Threads — wątek oparty o terminal, do uruchomienia CLI albo interfejsu tekstowego agenta bezpośrednio w Zedzie, gdy chcemy pracować z narzędziem w jego własnej powłoce.

Zdanie z dokumentacji, które dla naszych czytelników jest najistotniejsze: Zed nie pobiera opłat za agentów zewnętrznych. Rozliczenia, warunki prawne, retencja i przetwarzanie danych są między nami a dostawcą agenta. Mając subskrypcję Claude Code, uruchamiamy go w Zedzie bez drugiej opłaty.

Szczegóły dla Claude'a są opisane konkretnie: agent instaluje się z rejestru ACP, ma własne uwierzytelnianie i rozliczenie — a klucz API skonfigurowany dla Zed Agenta nie konfiguruje go automatycznie. Metodę rozliczenia wybiera się komendą /login w wątku, wskazując klucz API albo Claude Code tam, gdzie jest to wspierane. I detal, który w praktyce zdejmuje sporo pracy: pliki takie jak CLAUDE.md mogą być czytane przez agenta bezpośrednio, więc instrukcje projektu nie wymagają dublowania.

Agenci równolegli

Element, który realnie zmienia sposób pracy, a nie tylko dodaje okno. Pasek wątków pozwala uruchomić wiele wątków agentowych i terminalowych jednocześnie — każdy z innym agentem i każdy przeciw innemu projektowi oraz innemu drzewu roboczemu.

Różnica wobec pracy z agentem w terminalu jest ergonomiczna, ale odczuwalna: trzy równoległe zadania z podglądem zmian w edytorze i możliwością ich przeglądu w miejscu to inna sytuacja niż trzy karty terminala, między którymi trzeba pamiętać, co się dzieje. Przy pracy, w której agent czeka na wynik testów albo na deploy, nadzorowanie kilku wątków przestaje być luksusem.

Pozostałe funkcje AI układają się w spójny zestaw: panel agenta do promptowania, dodawania kontekstu i przeglądu zmian, Inline Assistant do przekształcenia zaznaczonego fragmentu w miejscu, Edit Prediction czyli uzupełnienia przyjmowane w trakcie pisania, oraz generowanie komunikatów commita z panelu Gita.

Skille, instrukcje i zgodność z innymi agentami

Ten rozdział jest dla naszych czytelników najbardziej praktyczny, bo dotyczy rzeczy, którą prawdopodobnie już mamy w repozytoriach.

Skill w Zedzie to katalog z plikiem SKILL.md zawierającym metadane i instrukcje. Agent widzi katalog wszystkich zainstalowanych skilli i ładuje jeden na żądanie, albo wywołujemy go sami komendą ukośnikową z edytora wiadomości. Zakres jest dwupoziomowy: globalny (~/.agents/skills/) i projektowy (.agents/skills/ w repozytorium).

Ta ścieżka wygląda znajomo — i nie bez powodu. W tej serii widzieliśmy katalog .agents/ w repozytorium ToolJeta i w szablonie Open SaaS. To jest ta sama, wspólna konwencja, a nie zbieg okoliczności: skille napisane raz działają w kilku narzędziach.

Zed dokłada do tego wygody, których warto poszukać w swoim narzędziu:

wbudowany skill /create-skill, który przeprowadza przez tworzenie nowego — oraz kreator w ustawieniach, pokazujący dokładnie, gdzie plik zostanie zapisany i w jakim zakresie,
import z adresu URL — akcja pobierająca skill z pliku Markdown na GitHubie, z automatycznym wypełnieniem, gdy adres jest w schowku,
rejestr skills.sh — społecznościowa składnica otwartych skilli, z których instalacja polega na skopiowaniu katalogu w jedno z dwóch miejsc,
udostępnianie linkiem zed://skill, który osadza skill i da się go po prostu wysłać drugiej osobie,
przełącznik disable-model-invocation — skill, który ma być wywoływany tylko ręcznie, a nie wybierany przez model.

Osobno warto odnotować porządkującą decyzję: od wersji 1.4.0 dawne „Rules" zostały zastąpione skillami i instrukcjami, a istniejące reguły migrują automatycznie — te niedomyślne stają się globalnymi skillami z wyłączonym wywoływaniem przez model, a domyślne są dopisywane do globalnego AGENTS.md.

I rzecz, która jest tu najcenniejsza praktycznie. Zed czyta projektowe pliki instrukcji innych agentów, biorąc pierwszy pasujący z listy:

.rules
.cursorrules
.windsurfrules
.clinerules
.github/copilot-instructions.md
AGENT.md
AGENTS.md
CLAUDE.md
GEMINI.md

Oznacza to, że repozytorium z plikiem CLAUDE.md albo AGENTS.md działa w Zedzie bez żadnej dodatkowej pracy. Instrukcje projektu, które napisaliśmy dla jednego narzędzia, są rozumiane przez drugie — a to jest dokładnie ten rodzaj interoperacyjności, którego w tej kategorii zwykle brakuje.

Uprawnienia narzędzi: wzorce zamiast klikania

Zanim przejdziemy do piaskownicy, warto pokazać mechanizm leżący warstwę wyżej, bo jest zaskakująco dobrze zaprojektowany. Uprawnienia narzędzi decydują, co uruchamia się automatycznie, a co wymaga naszej zgody — i konfiguruje się je wyrażeniami regularnymi, nie listą pytań:

{
  "agent": {
    "tool_permissions": {
      "default": "allow",
      "tools": {
        "terminal": {
          "default": "confirm",
          "always_allow": [
            { "pattern": "^cargo\\s+(build|test|check)" },
            { "pattern": "^npm\\s+(install|test|run)" }
          ],
          "always_confirm": [{ "pattern": "sudo\\s+/" }]
        }
      }
    }
  }
}

Ten przykład z dokumentacji automatycznie dopuszcza komendy cargo i npm, a przy sudo zawsze pyta. Dla stacku PHP odpowiednikiem byłoby dopuszczenie composer install, vendor/bin/pint i artisan test, przy jednoczesnym wymuszeniu potwierdzenia dla artisan migrate i wszystkiego, co dotyka bazy produkcyjnej.

Warto docenić, dlaczego to jest lepsze niż globalny przełącznik „pozwalaj na wszystko": zgoda przestaje być decyzją zerojedynkową i staje się polityką. Znużenie klikaniem „potwierdź" jest realnym problemem bezpieczeństwa — po dwudziestym pytaniu ludzie przestają czytać. Dopuszczenie wzorcem tego, co bezpieczne i powtarzalne, sprawia, że pytanie pojawia się rzadko i wtedy faktycznie coś znaczy.

Piaskownica dla narzędzi agenta

Najlepiej udokumentowany mechanizm bezpieczeństwa agentowego, jaki spotkaliśmy w tej serii — i wart osobnego rozdziału, bo rozróżnia dwie rzeczy, które zwykle się myli.

Uprawnienia narzędzi ograniczają, co agent może uruchomić. Piaskownica ogranicza, co uruchomione narzędzie może zrobić. Oba mechanizmy działają razem i dokumentacja tłumaczy, dlaczego pierwszy nie wystarcza: przy narzędziu, którym agent uruchamia skomplikowany skrypt w terminalu, zgoda na „uruchomienie terminala" nie mówi nic o tym, co ten skrypt zrobi.

Kluczowa właściwość piaskownicy: używa mechanizmów systemu operacyjnego i nie polega na tym, że agent przestrzega instrukcji. Jeśli narzędzie spróbuje sięgnąć po zasób poza piaskownicą, blokuje je system, a nie dobra wola modelu. Obecny zakres:

terminal — ograniczone zapisy do systemu plików i wychodzący ruch sieciowy dla komend uruchamianych przez agenta, z ochroną metadanych Gita,
fetch — ograniczenie hostów, do których można się odwołać.

A teraz część, którą dokumentacja podaje wprost i którą trzeba przeczytać uważnie, bo wyznacza realną granicę ochrony. Piaskownica dotyczy wyłącznie Zed Agenta. Nie obejmuje samego Zeda, serwerów językowych, rozszerzeń, zadań, zwykłych kart terminala — ani agentów zewnętrznych i wątków terminalowych.

Konsekwencja jest bezpośrednia i warto ją nazwać: uruchamiając Claude Code jako agenta zewnętrznego w Zedzie, nie dostajemy piaskownicy Zeda. Obowiązują wtedy mechanizmy bezpieczeństwa tego agenta, a nie edytora. Nie jest to wada — wynika wprost z podziału odpowiedzialności w ACP, gdzie agent zewnętrzny ma własny proces — ale jest to rzecz, którą łatwo błędnie założyć.

Do tego jedno zastrzeżenie platformowe: na Windowsie piaskownice bywają słabsze niż na Linuksie i macOS i mogą nie zapobiec wszystkim próbom wyjścia. Dokumentacja mówi to sama, w wyróżnionej notce.

Co zrobić z subskrypcją, którą już mamy

Dokumentacja Zeda ma osobną stronę odpowiadającą na pytanie „płacę już za asystenta, jak to się składa z Zedem" — i zawiera tabelę, która oszczędza godzinę zgadywania. Najważniejsze wiersze:

Claude Pro / Max — brak bezpośredniej ścieżki jako dostawca modeli w Zedzie. Subskrypcję wykorzystuje się przez Claude Agent (ACP) albo Claude Code jako wątek terminalowy. Dokumentacja podkreśla, że subskrypcja jest czymś innym niż kredyty API Anthropica,
ChatGPT Plus / Pro — działa jako dostawca modeli w Zedzie po zalogowaniu przez OpenAI, bez osobnego klucza API; a poza tym przez Codeksa jako agenta zewnętrznego albo CLI,
GitHub Copilot — czat i uzupełnienia jako funkcje Zeda, plus agent tam, gdzie jest dostępny,
Cursor — brak ścieżki jako dostawca modeli; wyłącznie przez agenta zewnętrznego albo CLI,
Zed Pro, Business, Student — modele hostowane przez Zeda, rozliczane przez Zeda.

Wniosek dla zespołu pracującego z Claude'em jest jednoznaczny i wart wyprostowania, bo bywa źródłem nieporozumień: subskrypcji Claude Pro albo Max nie wpiszemy w Zedzie jako „dostawcy modelu" dla jego natywnego agenta. Wykorzystamy ją, uruchamiając Claude'a jako osobnego agenta w panelu — co jest zresztą wariantem lepszym, bo agent przynosi wtedy własne narzędzia i własną konfigurację, w tym rozumienie CLAUDE.md.

Poza subskrypcjami dostępne są jeszcze: klucze API dostawców, gatewaye (przydatne, gdy firma centralizuje dostęp do modeli i rozlicza go w jednym miejscu) oraz modele lokalne — istotne przy kodzie, który nie może opuścić maszyny.

Współpraca w czasie rzeczywistym

Funkcja, od której Zed zaczynał i która nadal działa — choć, jak pokazuje proporcja dokumentacji, nie jest już głównym argumentem.

Zed obsługuje wieloosobową edycję na żywo: kilka osób pracuje w tym samym projekcie jednocześnie, widząc kursory i zmiany pozostałych w momencie ich powstawania. Panel współpracy ma dwie sekcje:

Kanały — trwałe pokoje projektowe dla zespołu, z udostępnionymi projektami i rozmową głosową (z możliwością wyboru urządzeń wejścia i wyjścia oraz testu dźwięku),
Kontakty i prywatne rozmowy — lista kontaktów do sesji doraźnych.

Współpraca wymaga zalogowania, czyli konta i infrastruktury Zeda — co przy części klientów jest osobnym tematem do ustalenia.

I ostrzeżenie, które dokumentacja wyróżnia i które trzeba zacytować, bo w kontekście pracy dla klienta ma wagę prawną, nie tylko techniczną: udostępnienie projektu daje współpracownikom dostęp do naszego lokalnego systemu plików w obrębie tego projektu. Współpracuj tylko z osobami, którym ufasz. Przy projekcie objętym umową powierzenia danych to jest zdanie, które przesądza, czy tej funkcji wolno użyć.

Reszta, która decyduje o codziennym użyciu

Zed nie jest edytorem jednej funkcji i warto wiedzieć, co jeszcze ma — bo lista jest dłuższa, niż sugeruje reputacja „szybkiego edytora":

Serwery językowe (LSP) i rozszerzenia — z osobnym systemem rozszerzeń i motywów oraz ikonami,
Tryb Vima i tryb Helixa — oba mają w dokumentacji własne, osobne strony, co mówi o poziomie wsparcia,
Debugger, zadania, REPL, multibuffery (edycja wielu plików w jednym widoku), panel diagnostyki, outline panel,
Dev containers i praca zdalna — czyli edycja projektu na zdalnej maszynie,
Zaufanie do drzewa roboczego (worktree trust) — mechanizm decydujący, czy otwarty projekt wolno wykonywać; przy klonowaniu cudzych repozytoriów to nie jest szczegół,
Semantic tokens, snippety, modeline, konfiguracja języków i łańcuchów narzędzi.

Instalacja: macOS, Linux i Windows — bezpośrednio ze strony albo z menedżera pakietów. Wersji webowej nie ma i projekt odnotowuje to jawnie, wskazując dyskusję, w której temat jest śledzony.

Gdzie to ma sens w naszym stacku

Tu trzeba być uczciwym, bo entuzjazm wobec dobrze zrobionego narzędzia łatwo przenieść na rekomendację, której nie da się obronić.

Zed nie jest zamiennikiem PhpStorma do dużego projektu w Laravelu. Obsługa PHP idzie przez serwer językowy i działa, ale ekosystem wokół niej jest młodszy: nie ma tu głębokiej analizy Eloquenta, refaktoryzacji na poziomie, do którego przywykliśmy w dedykowanym IDE, ani integracji z narzędziami frameworka na porównywalnym poziomie. Przy projekcie, w którym połowa wartości edytora leży w rozumieniu magii frameworka, to jest różnica odczuwalna codziennie.

Gdzie Zed ma u nas sens:

Front — TypeScript i React, gdzie wsparcie przez LSP jest dojrzałe, a szybkość otwierania i przeszukiwania projektu robi różnicę,
Praca z repozytorium — przeglądanie cudzego kodu, pliki konfiguracyjne, szybkie wejście w projekt, którego nie zamierzamy indeksować przez trzy minuty,
Powłoka do nadzorowania agentów — i to jest właściwy powód, dla którego warto go wypróbować. Jeśli już pracujemy z Claude Code, uruchomienie go jako agenta zewnętrznego daje pasek wątków, podglądy zmian i przegląd w edytorze, bez drugiej opłaty i bez porzucania dotychczasowego narzędzia.

Warto przy tym zauważyć rzecz, która wyróżnia ten temat na tle całej serii: cena wejścia jest zerowa i decyzja jest w pełni odwracalna. Nie ma tu migracji danych, licencji do wynegocjowania ani infrastruktury do utrzymania — jest pobranie pliku i pół dnia pracy w innym narzędziu.

Pułapki

Piaskownica nie obejmuje agentów zewnętrznych — czyli dokładnie tego trybu, w którym najprawdopodobniej będziemy pracować. To najważniejsze zastrzeżenie w całym wpisie,
Na Windowsie piaskownica jest słabsza i według dokumentacji może nie zapobiec wszystkim próbom wyjścia,
Udostępnienie projektu we współpracy daje dostęp do lokalnych plików w jego obrębie. Przy danych klienta to jest rozstrzygające,
Współpraca wymaga konta i infrastruktury Zeda — nie jest to funkcja działająca wyłącznie między naszymi maszynami,
Tygodniowa kadencja wydań i 3203 otwarte zgłoszenia oznaczają, że dużo się zmienia — również w rzeczach, do których się przywykło,
Brak wersji webowej, jeśli to jest wymóg,
Ekosystem PHP młodszy niż w dedykowanych IDE — przy projekcie w Laravelu warto to sprawdzić na własnym kodzie przed decyzją,
Agenci zewnętrzni mają własne rozliczenia i własne warunki przetwarzania danych. Zed za nich nie odpowiada i nie pobiera opłat — co jest zaletą finansową i obowiązkiem sprawdzenia po naszej stronie,
Licencja GPL-3.0 ma konsekwencje przy modyfikowaniu i redystrybucji — szczegóły niżej.

Podsumowanie

Zed jest edytorem, który przestał być tylko szybką alternatywą dla VS Code i stał się jednym z najciekawiej zaprojektowanych środowisk do pracy z agentami. Co z tego wynika:

Projekt jest bardzo dojrzały i bardzo aktywny — 89 999 gwiazdek, 98 commitów w tygodniu, wydania w kadencji tygodniowej z kanałem przedpremierowym, rozwój prowadzony przez spółkę,
Trzy drogi agentowe: Zed Agent z modelami i MCP, agenci zewnętrzni przez otwarty protokół ACP, oraz wątki terminalowe do CLI agenta,
Claude Code działa jako agent zewnętrzny bez dodatkowej opłaty — rozliczenie wybiera się komendą /login, a CLAUDE.md może być czytany bezpośrednio,
Pasek wątków pozwala nadzorować kilku agentów naraz, każdego przeciw innemu projektowi — to realna zmiana ergonomii wobec kart terminala,
Piaskownica jest systemowa i nie polega na posłuszeństwie modelu, ale obejmuje tylko narzędzia terminal i fetch Zed Agenta. Nie obejmuje agentów zewnętrznych,
Uprawnienia narzędzi i piaskownica to dwa różne mechanizmy — pierwszy decyduje, co wolno uruchomić, drugi ogranicza, co uruchomione może zrobić,
Współpracę na żywo traktuj z ostrożnością — daje dostęp do lokalnych plików projektu i wymaga konta,
W stacku PHP nie licz na zamiennik PhpStorma; licz na dobry edytor frontu i bardzo dobrą powłokę dla agentów,
Zed czyta CLAUDE.md i AGENTS.md natywnie — repozytorium z instrukcjami dla innego agenta działa bez dodatkowej pracy,
Skille to katalog z SKILL.md w ~/.agents/skills/ albo w projekcie; jest wbudowany kreator, import z GitHuba i rejestr skills.sh,
Uprawnienia narzędzi konfiguruj wzorcami, nie globalnym przełącznikiem — dopuść composer install i artisan test, wymuś potwierdzenie dla artisan migrate,
Subskrypcji Claude Pro nie wpiszesz jako dostawcy modelu — wykorzystasz ją przez Claude Agent albo wątek terminalowy z Claude Code,
Decyzja jest odwracalna i darmowa — rzadkość na tle innych tematów z tej serii.

Licencja: kod Zeda jest licencjonowany zasadniczo na GPL-3.0-or-later, z komponentami na Apache-2.0 tam, gdzie jest to oznaczone (dotyczy to między innymi części bibliotecznych, przeznaczonych do użycia poza samym edytorem). GPL-3.0 jest pełnoprawną licencją open source ze silnym copyleftem obejmującym całe dzieło — i ma to jasne konsekwencje. Zwykłe używanie edytora jest bez żadnych zastrzeżeń, także w pracy komercyjnej i przy dowolnej liczbie stanowisk: GPL nie stawia warunków korzystaniu z programu, a kod, który w tym edytorze piszemy, nie ma z jego licencją nic wspólnego. Ograniczenia pojawiają się dopiero przy dystrybucji zmodyfikowanej wersji: fork z własnymi poprawkami, rozdawany dalej, musi być udostępniony na GPL-3.0 razem z kodem. W praktyce oznacza to, że nie da się zbudować na Zedzie zamkniętego produktu komercyjnego — i jest to celowa różnica wobec VS Code na licencji MIT, na którym zbudowano dziesiątki takich produktów. Komponenty Apache-2.0 są tu wyjątkiem właśnie po to, żeby dorobek techniczny projektu (jak jego warstwa interfejsu) mógł być używany szerzej niż sam edytor.