Zed z AI: szybki edytor dla tych, co uciekają z VS Code

Jeśli otwierasz VS Code i czekasz dwie sekundy, aż okno przestanie migać, a wentylator laptopa rusza przy pierwszym podpowiadaniu z Copilota — Zed jest dla ciebie. To edytor napisany w Rust przez ludzi, którzy kiedyś zrobili Atom (a wcześniej Tree-sitter i Electron). Tym razem postanowili nie powtarzać błędu sprzed dekady i zamiast budować na przeglądarce, napisali własny silnik renderujący na GPU. Efekt jest namacalny od pierwszej sekundy: Zed po prostu jest szybki. Pytanie brzmi, czy w 2026 roku szybkość plus AI wystarczą, żeby porzucić ekosystem, który zna każdy.

Czym właściwie jest Zed

Zed to natywny edytor kodu — nie fork VS Code, nie nakładka na Chromium, tylko osobny program kompilowany do natywnego kodu. Trzy rzeczy odróżniają go od reszty stawki. Po pierwsze: język. Cały rdzeń jest w Rust, co daje przewidywalną wydajność i brak garbage collectora, który potrafi zaciąć interfejs w najmniej oczekiwanym momencie. Po drugie: renderowanie. Zed rysuje UI na GPU przez własny framework (GPUI), więc przewijanie wielkiego pliku i wpisywanie tekstu zostają płynne nawet przy 120 Hz. Po trzecie: architektura współpracy wbudowana od początku, a nie doklejona pluginem.

Zespół stojący za Zedem to nie startup bez historii. To ci sami ludzie, którzy stworzyli Atom dla GitHuba i przy okazji wypuścili Tree-sitter — parser, na którym dziś polega pół branży, łącznie z Neovimem. Atom przegrał z VS Code głównie dlatego, że był zbudowany na Electronie i z czasem stał się ociężały. Zed to ich druga próba, tym razem z lekcji odrobionej do końca: zero kompromisów wydajnościowych na poziomie fundamentu.

Dlaczego szybkość to nie fetysz, tylko flow

Łatwo zbyć argument o prędkości jako benchmarkowy fetysz. „Kogo obchodzi, czy edytor startuje w 200 czy 800 milisekund.” Obchodzi, ale nie ze względu na te milisekundy. Chodzi o opóźnienie wejścia (input latency) — czas między naciśnięciem klawisza a pojawieniem się znaku. Powyżej pewnego progu mózg przestaje traktować edytor jako przedłużenie myśli i zaczyna go zauważać. To zauważanie wybija ze stanu flow.

Zed był projektowany wokół tej jednej obsesji. Renderowanie na GPU, brak warstwy DOM, brak mostka JavaScript — wszystko po to, żeby znak pojawiał się natychmiast. W praktyce różnica jest najbardziej odczuwalna na dużych plikach, w monorepo z setkami tysięcy linii i podczas pracy z włączonym podświetlaniem składni przez Tree-sitter. Tam, gdzie VS Code zaczyna gubić klatki, Zed trzyma równe tempo. To nie jest cecha, którą docenisz na demie. To cecha, którą docenisz po ośmiu godzinach pracy, kiedy nie czujesz zmęczenia interfejsem.

Asystent AI i tryb agenta

AI w Zedzie ma dwie twarze. Pierwsza to klasyczny panel asystenta — rozmawiasz z modelem, wrzucasz kontekst (pliki, zaznaczenia, output terminala) i dostajesz odpowiedzi inline w edytorze, a nie w osobnym oknie czatu. Druga twarz to tryb agentowy: model dostaje zadanie, przegląda repo, edytuje wiele plików, uruchamia polecenia i wraca z diffem do zatwierdzenia. To ten sam kierunek, w którym poszli wszyscy — różnica jest w wykonaniu i w tym, jak głęboko agent jest wpleciony w natywny interfejs.

Mocną stroną Zeda jest neutralność wobec dostawcy modelu. Podpinasz własny klucz API — Anthropic, OpenAI, Google, modele lokalne przez Ollama — albo korzystasz z hostowanej oferty Zeda. Dla zespołu, który nie chce wysyłać kodu przez pośrednika i woli płacić wprost za tokeny u wybranego dostawcy, to realna przewaga nad rozwiązaniami, które zamykają cię w jednym pipeline. Konkretne ceny i limity zmieniają się zbyt często, żeby je tu cytować — sprawdź aktualny cennik przed decyzją zespołową, bo to jeden z istotniejszych parametrów.

Edycje inline (czyli „zaznacz fragment, opisz zmianę, dostań diff”) działają płynnie i są moim ulubionym trybem do codziennej pracy. Mniej teatru niż pełny agent, a 80% realnych zmian to i tak drobne refaktory, których nie chcesz pisać ręcznie.

Współpraca wbudowana w edytor

Tu Zed robi coś, czego forki VS Code nie mają z pudełka: pair programming jako funkcja pierwszej klasy. Dzielisz projekt, druga osoba dołącza, widzicie swoje kursory, możecie edytować równolegle, jest wbudowany kanał głosowy. To nie plugin typu Live Share doklejony do edytora — to część rdzenia, więc działa szybko i spójnie. W świecie, gdzie część pair programmingu to teraz para człowiek–agent, a część nadal człowiek–człowiek, taka architektura ma sens na przyszłość.

W praktyce większość solowych deweloperów nie dotknie tej funkcji codziennie. Ale dla zespołów rozproszonych, mentoringu juniorów i sesji debugowania na żywo to argument, który potrafi przeważyć. I jest to coś, czego nie da się łatwo dorobić w edytorze, który nie myślał o współpracy od fundamentów.

Zed kontra forki VS Code (Cursor, Windsurf)

To najważniejsze porównanie, bo właśnie tu większość ludzi podejmuje decyzję. Cursor i Windsurf to forki VS Code — biorą dojrzały, znany edytor i doklejają do niego mocną warstwę AI. Zaleta jest oczywista: dostajesz cały ekosystem rozszerzeń, znane skróty, gotowe ustawienia i dosłownie zero kosztu przesiadki. Wada też: dziedziczysz bagaż Electrona i całą wagę VS Code.

Zed gra w odwrotną stronę. Stawia wydajność i natywność na pierwszym miejscu, a AI buduje we własnym, spójnym interfejsie. Płacisz za to mniejszym ekosystemem i tym, że niektóre rozszerzenia, do których przywykłeś, po prostu nie istnieją. Upraszczając brutalnie:

• Cursor/Windsurf — maksymalna kompatybilność i najgłębsza dziś integracja AI, kosztem wydajności.
• Zed — maksymalna wydajność i czysty natywny interfejs, kosztem dojrzałości ekosystemu.

Nie ma tu jednego zwycięzcy. Jest pytanie, co cię bardziej boli na co dzień: lag edytora czy brakujący plugin.

Uczciwe wady

Nie udawajmy, że Zed jest gotowy na wszystko. Po pierwsze, ekosystem rozszerzeń jest znacznie mniejszy niż w świecie VS Code. Jeśli twój workflow zależy od niszowego pluginu do konkretnego frameworka, sprawdź to zanim przesiądziesz się na stałe — możesz wrócić rozczarowany.

Po drugie, funkcje AI wciąż dojrzewają. Tryb agentowy bywa mniej dopracowany niż u liderów, którzy mieli więcej czasu na szlifowanie tej konkretnej warstwy. To się zmienia z miesiąca na miesiąc, ale jeśli oceniasz Zeda dziś, oceniaj realny stan, a nie roadmapę.

Po trzecie, wsparcie platform i wycinkowe braki. Historycznie Zed startował na macOS, potem Linux, a Windows dochodził później — sprawdź aktualny status dla swojej platformy. Dochodzą drobiazgi: niektóre zaawansowane konfiguracje debuggera czy integracje, które w VS Code są oczywistością, w Zedzie wymagają obejścia albo jeszcze nie istnieją.

Kto powinien się przesiąść, a kto nie

Przesiądź się na Zeda, jeśli: pracujesz głównie w mainstreamowych językach (Rust, Go, TypeScript, Python), wydajność i flow są dla ciebie świętością, drażni cię waga VS Code, a do AI podchodzisz pragmatycznie — chcesz solidnych edycji inline i agenta do drobnych zadań, bez przywiązania do jednego dostawcy modelu.

Zostań przy tym, co masz, jeśli: twój codzienny workflow stoi na konkretnych rozszerzeniach VS Code, potrzebujesz najgłębszej dostępnej dziś integracji agentowej (wtedy Cursor lub Windsurf będą bliżej celu), albo pracujesz w egzotycznym stacku ze słabym wsparciem językowym w Zedzie. Dotyczy to też zespołów z ciężką inwestycją w devcontainery i remote development w stylu VS Code — tu forki wygrywają dojrzałością.

Praktyczna rada: nie migruj całego zespołu w jeden dzień. Zainstaluj Zeda obok dotychczasowego edytora, popracuj w nim tydzień na realnym projekcie i sprawdź, czy zysk na wydajności przebija koszt brakujących nawyków. Przesiadka jest tania do cofnięcia — to dobry kandydat na eksperyment.

TL;DR

Zed to napisany w Rust, renderowany na GPU edytor od ludzi od Atoma, który stawia wydajność ponad wszystko i daje realny flow przy długiej pracy. AI ma w postaci asystenta inline, trybu agentowego i — co ważne — wyboru dostawcy modelu. Współpraca jest wbudowana, nie doklejona. Płacisz za to mniejszym ekosystemem rozszerzeń i wciąż dojrzewającym agentem. Wybierz Zeda zamiast forków VS Code (Cursor, Windsurf), jeśli bardziej boli cię lag niż brakujący plugin. Jeśli twój workflow stoi na rozszerzeniach lub potrzebujesz najgłębszej integracji AI — zostań przy forku. Testuj tydzień obok, decyzję jest tania do cofnięcia.