Cursor, edytor z AI i realne koszty pracy

Cursor, edytor, w którym model widzi całe repozytorium

Cursor to widelec VS Code, w którym model językowy nie jest wtyczką doklejoną z boku, tylko elementem samego edytora. Różnica polega na dostępie do kontekstu: asystent widzi otwarte pliki, historię zmian, wyniki wyszukiwania w projekcie i błędy z terminala, a nie tylko fragment, który mu wkleisz.

W czerwcu 2026 roku spółka stojąca za produktem, wcześniej znana z rekordowego tempa wzrostu przychodów, podpisała umowę przejęcia przez SpaceX w transakcji akcyjnej wycenionej na sześćdziesiąt miliardów dolarów, z zamknięciem planowanym na trzeci kwartał. Dwa dni później przejęto zespół Continue i wygaszono tamten otwarty projekt.

Co daje przejście z wtyczki na edytor

Największa różnica nie leży w jakości modelu, bo modele są te same, co u konkurencji. Leży w tym, ile kontekstu trafia do zapytania bez Twojego udziału.

Wtyczka widzi zwykle bieżący plik i to, co zaznaczysz. Edytor zbudowany wokół modelu indeksuje repozytorium, więc pytanie o to, gdzie obsługiwane są płatności, znajduje odpowiedź bez podawania ścieżek. To brzmi jak drobiazg, a decyduje o tym, czy narzędzie odpowiada na pytania o architekturę, czy tylko uzupełnia linijki.

Druga różnica to działanie na wielu plikach naraz. Zmiana nazwy pola w typie, poprawienie wszystkich miejsc jego użycia i aktualizacja testów to jedno polecenie, a nie dwadzieścia osobnych edycji.

Trzecia to pętla zwrotna. Edytor widzi błędy kompilatora i wyniki testów, więc może poprawić własną zmianę bez przeklejania komunikatu przez człowieka. Ta jedna rzecz odpowiada za większość odczuwalnej różnicy w codziennej pracy.

Tryb Auto i wybór modelu

Najważniejsza rzecz dla rachunku i najczęściej pomijana. Tryb automatyczny sam dobiera model do zadania i na planach płatnych nie zużywa puli kredytów, więc powinien być ustawieniem domyślnym.

Model wybierasz ręcznie wtedy, gdy zadanie jest trudne i wiesz, że tańszy sobie nie poradzi. Wtedy sięgasz po model o mocniejszym rozumowaniu i płacisz z puli. Odwrotna kolejność, czyli stałe ustawienie najdroższego modelu do wszystkiego, jest najczęstszą przyczyną zaskoczenia rachunkiem.

Producent rozwija też własny model przeznaczony do kodowania, tańszy od modeli czołowych przy porównywalnej jakości w typowych zadaniach edytorskich. Warto go przetestować na własnym repozytorium, bo różnice między modelami są mocno zależne od języka i stylu projektu.

Praktyczna zasada brzmi: zacznij od trybu automatycznego, a na model czołowy przełączaj się świadomie, przy zadaniach obejmujących wiele plików albo wymagających rozumowania o architekturze.

Reguły projektu

To najbardziej niedoceniana funkcja i jednocześnie ta, która najbardziej poprawia jakość podpowiedzi. Reguły to pliki w repozytorium opisujące konwencje projektu, dołączane do kontekstu automatycznie.

---
description: Konwencje frontendu
globs: ["src/**/*.tsx"]
alwaysApply: false
---

- Komponenty funkcyjne z typowanymi propsami, bez React.FC
- Stylowanie wyłącznie klasami Tailwind, bez styled-components w nowym kodzie
- Zapytania do API tylko przez `src/api/client.ts`
- Nie dodajemy komentarzy do wygenerowanego kodu

Reguła z dopasowaniem do ścieżek dołącza się tylko przy pracy nad pasującymi plikami, więc kontekst nie puchnie od zasad, które akurat nie obowiązują. Warto rozumieć trzy tryby dołączania, bo mieszanie ich jest najczęstszą przyczyną reguł, które nie działają.

alwaysApply: true          # zawsze w kontekscie, uzywaj oszczednie
globs: ["src/**/*.tsx"]    # tylko przy pracy nad pasujacymi plikami
description: "..."         # model sam decyduje, czy siegnac

Reguła ustawiona na stałe obowiązuje przy każdym zapytaniu, więc trzy takie reguły po sto linii zjadają kontekst, zanim model zobaczy Twój kod. Reguła z opisem i bez dopasowania bywa pomijana, bo decyzja o jej użyciu należy do modelu.

Dobra reguła mówi, czego nie robić, a nie tylko co robić. Model domyślnie sięga po rozwiązania najpopularniejsze, a nie po te przyjęte u Ciebie, więc różnica między dwoma zapisami tej samej zasady bywa spora.

Slabo:
- Piszemy czysty, czytelny kod

Lepiej:
- Nie uzywamy moment.js, w nowym kodzie date-fns
- Nie wolamy fetch bezposrednio w komponencie, tylko przez src/api/client.ts
- Nie dodajemy nowych zaleznosci bez pytania
- Testy pisze sie do zachowania, nie do implementacji

Pierwszy zapis nie zmienia niczego, bo model i tak uważa, że pisze czytelnie. Drugi odcina konkretne wybory, których sam by dokonał.

Reguły trzymaj w repozytorium, nie w ustawieniach edytora. Wtedy obowiązują cały zespół i podlegają przeglądowi jak każdy inny kod.

.cursor/rules/frontend.mdc
.cursor/rules/api.mdc
.cursor/rules/testy.mdc
.cursorignore

Ostatni plik pełni tu osobną rolę: wyłącza wskazane ścieżki z indeksowania. Katalogi z zależnościami, wygenerowanym kodem i danymi testowymi tylko rozpraszają wyszukiwanie, a pliki z sekretami nie powinny trafić do indeksu w ogóle.

node_modules/
.next/
dist/
*.generated.ts
.env*
infra/secrets/

Praca na wielu plikach

Tryb agenta wprowadza zmiany w całym projekcie, uruchamia polecenia i czyta ich wyniki. To najmocniejsza i najbardziej ryzykowna część narzędzia.

Trzy nawyki, które oddzielają użyteczną pracę od sprzątania po niej. Pierwszy to czysty stan repozytorium przed rozpoczęciem, żeby zmiany modelu dało się odróżnić od własnych i cofnąć jednym poleceniem. Drugi to zadania wielkości jednego zatwierdzenia, bo agent proszony o przebudowę połowy aplikacji produkuje diff, którego nikt nie przejrzy. Trzeci to przegląd zmian przed przyjęciem, tak samo jak przy cudzym kodzie.

Warto też ograniczyć uprawnienia do uruchamiania poleceń. Agent, który sam wykonuje wszystko, co uzna za potrzebne, prędzej czy później uruchomi migrację bazy albo polecenie kasujące pliki. Lista poleceń wymagających potwierdzenia rozwiązuje ten problem bez odbierania narzędziu przydatności.

Ceny

Rozliczenie roczne obniża stawkę o mniej więcej jedną piątą, sprowadzając plan podstawowy do około szesnastu dolarów miesięcznie. Plan zespołowy zmieniono w czerwcu 2026 roku, podnosząc limity i dodając osobny poziom miejsc dla osób intensywnie korzystających z modeli czołowych. Dwa poziomy miejsc w jednym zespole to rozwiązanie warte uwagi przy planowaniu budżetu: dwie osoby zlecające zadania agentowe przez cały dzień dostają miejsca droższe, reszta zespołu zostaje na podstawowych, zamiast podnosić stawkę wszystkim. Poziom najwyższy wyceniany jest indywidualnie, bez stawki w cenniku.

Trzy rzeczy najbardziej wpływają na to, czy mieścisz się w planie. Pierwsza to udział trybu automatycznego w codziennej pracy, bo on nie zużywa puli. Druga to długość kontekstu: praca z otwartymi dwudziestoma plikami kosztuje wielokrotnie więcej niż z trzema. Trzecia to powtarzanie zadań, których model nie rozumie, bo brakuje mu reguł projektu, przez co ta sama zmiana idzie do modelu trzy razy.

Kontekst, czyli skąd model wie, o co pytasz

Jakość odpowiedzi zależy niemal wyłącznie od tego, co trafiło do zapytania. Warto więc wiedzieć, jakimi drogami kontekst tam wchodzi, bo każda działa inaczej.

Wskazanie pliku albo katalogu dołącza jego treść wprost. To najbardziej niezawodna droga i warto z niej korzystać, gdy wiesz, gdzie leży sedno sprawy. Odwołanie do zmian w repozytorium dołącza bieżący diff, co sprawdza się przy prośbie o przegląd własnej pracy przed zatwierdzeniem.

Wyszukiwanie w projekcie działa na indeksie i sprawdza się przy pytaniach eksploracyjnych, gdy sam nie wiesz, gdzie szukać. Bywa jednak zawodne w dużych repozytoriach, bo zwraca fragmenty podobne znaczeniowo, a nie koniecznie te właściwe.

Odwołanie do dokumentacji zewnętrznej pobiera stronę i dokłada ją do zapytania. To rozwiązuje najczęstszy problem z bibliotekami, które zmieniły interfejs po dacie odcięcia wiedzy modelu.

Praktyczny wniosek jest odwrotny do intuicji: więcej kontekstu nie znaczy lepiej. Dwadzieścia otwartych plików rozprasza model i kosztuje wielokrotnie więcej niż trzy właściwe. Zamykanie niepotrzebnych zakładek przed trudnym pytaniem jest jedną z najprostszych rzeczy, które poprawiają wyniki.

Praca z istniejącym, dużym projektem

Narzędzia tego typu wypadają najlepiej na nowym kodzie, a najczęściej używa się ich na starym. Kilka rzeczy przesuwa ten bilans na korzyść.

Pierwsza to opis projektu w regułach: co robi aplikacja, jakie ma główne katalogi i gdzie leżą punkty wejścia. Model bez tej wiedzy zaczyna każde zadanie od zgadywania struktury.

Druga to zadania sformułowane przez odniesienie do istniejącego kodu. Prośba „dodaj obsługę faktur analogicznie do modułu zamówień w src/orders" daje wyniki zgodne z konwencją projektu, a prośba „dodaj obsługę faktur" daje kod z samouczka.

Trzecia to praca przyrostowa. W dużym repozytorium jedno duże polecenie prawie zawsze wychodzi gorzej niż pięć małych, bo każdy krok da się sprawdzić, zanim narosną na nim kolejne.

Czwarta to testy jako punkt odniesienia. Jeśli projekt ma testy, agent może uruchamiać je po każdej zmianie i sam poprawiać błędy. Jeśli nie ma, warto zacząć od dopisania testów do fragmentu, który zamierzasz zmienić.

Cursor kontra alternatywy

Te narzędzia nie wykluczają się i wiele zespołów używa dwóch naraz: edytora do pracy interaktywnej i asystenta w terminalu do długich zadań. Tym drugim narzędziem bywa sam terminal: Warp ma agenta wbudowanego w powłokę i potrafi uruchamiać obok siebie asystentów CLI, więc przy debugowaniu wdrożenia nie przełączasz okien. Rozliczenie idzie tam jednak kredytami po stawkach API, a plan darmowy nie zawiera żadnej puli, więc bez własnego klucza do dostawcy modelu funkcje agentowe są płatne od pierwszego dnia. Koszt takiego układu bywa niższy niż jednego planu na najwyższym poziomie, bo każde narzędzie robi to, w czym jest tańsze.

Przy porównywaniu warto pamiętać, że różnice między tymi narzędziami są mniejsze niż różnica między używaniem ich z regułami projektu a bez. Ten sam model w tym samym edytorze daje wyniki nie do porównania w zależności od tego, czy wie, jak wygląda konwencja w Twoim kodzie. Zanim więc zmienisz narzędzie, bo podpowiedzi są słabe, sprawdź, czy w repozytorium jest cokolwiek, co je opisuje.

Drugą rzeczą wartą sprawdzenia przed zmianą narzędzia jest sposób formułowania zadań. Prośby ogólne dają wyniki ogólne, niezależnie od tego, jak dobry jest model po drugiej stronie.

Prywatność i dane firmowe

Domyślnie kod trafia do dostawców modeli, więc przed wdrożeniem w firmie trzeba to ustawić świadomie. Tryb prywatności wyłącza przechowywanie kodu po stronie usługi, a plik z listą wykluczeń pozwala trzymać wybrane katalogi poza indeksem.

.env*
secrets/
**/*.pem
infrastructure/production/

Wykluczenia warto ustawić od pierwszego dnia, bo indeks powstaje przy pierwszym otwarciu projektu. Dopisanie reguły później nie cofa tego, co już zostało wysłane. Z tego samego powodu plik z wykluczeniami należy do repozytorium, a nie do ustawień pojedynczej osoby, bo inaczej chroni jedną maszynę, a nie projekt.

Przy danych, które nie mogą opuścić infrastruktury, żadne ustawienie nie zastąpi modelu lokalnego. Wtedy właściwym wyborem jest edytor z modelem uruchomionym u siebie, kosztem jakości podpowiedzi. Gotowym produktem w tej niszy jest Tabnine, który poza wdrożeniem we własnej chmurze oferuje wariant całkowicie odcięty od sieci i nie przechowuje przesłanego kodu. Cenę za to płaci się dosłownie: plany indywidualne zostały wycofane, a stawki zaczynają się od 39 dolarów za osobę miesięcznie przy zobowiązaniu rocznym.

Typowe błędy

Pierwszy to praca bez reguł projektu. Model podpowiada wtedy rozwiązania popularne, a nie przyjęte w Twoim kodzie, i każda podpowiedź wymaga poprawki.

Drugi to stałe używanie najdroższego modelu. Tryb automatyczny obsłuży większość zadań bez zużywania puli, a różnicę widać dopiero przy trudnym rozumowaniu.

Trzeci to zbyt duże zadania dla agenta. Diff obejmujący czterdzieści plików nie zostanie przejrzany, więc trafia do repozytorium na wiarę.

Czwarty to brak czystego stanu przed uruchomieniem agenta. Wymieszanie własnych zmian ze zmianami modelu sprawia, że cofnięcie nieudanej próby wymaga ręcznego rozplątywania.

Piąty to indeksowanie katalogów z sekretami. Plik ze zmiennymi środowiskowymi w indeksie to wyciek, którego nie da się cofnąć.

Szósty to traktowanie wygenerowanych testów jako dowodu poprawności. Test napisany przez model do kodu napisanego przez model potwierdza zwykle to, co kod robi, a nie to, co powinien robić.

FAQ

Ile kosztuje Cursor?

Plan darmowy pozwala poznać narzędzie, a typowym wyborem do codziennej pracy jest plan za 20 dolarów miesięcznie. Wyższe progi, 60 i 200 dolarów, zwiększają pulę zużycia modeli czołowych. Rozliczenie roczne obniża stawkę o mniej więcej jedną piątą.

Czy Cursor jest lepszy od Copilota?

W pracy na całym projekcie zwykle tak, bo widzi więcej kontekstu i działa na wielu plikach naraz. GitHub Copilot wygrywa ceną i tym, że zostajesz w swoim edytorze. Przy samym uzupełnianiu kodu różnica jest niewielka.

Co oznacza przejęcie przez SpaceX?

Umowę podpisano 16 czerwca 2026 roku, a zamknięcie zaplanowano na trzeci kwartał, po zgodach regulacyjnych. Dla użytkownika nic nie zmienia się natychmiast, ale przy planowaniu na lata warto założyć możliwe zmiany w cenniku i kierunku produktu, typowe po zmianie właściciela.

Czy kod trafia do dostawców modeli?

Domyślnie tak. Tryb prywatności ogranicza przechowywanie kodu po stronie usługi, a plik wykluczeń trzyma wybrane katalogi poza indeksem. Przy wymogu pełnej lokalności potrzebny jest model uruchomiony we własnej infrastrukturze.

Czy warto używać Cursora razem z asystentem w terminalu?

Wiele zespołów tak robi. Edytor sprawdza się przy pracy interaktywnej i przeglądaniu zmian, a asystent w terminalu przy długich zadaniach i pracy na serwerze. Podział ról bywa tańszy niż jeden plan na najwyższym poziomie.

Dokumentację znajdziesz na stronie produktu, a szczegóły transakcji opisał TechCrunch.