Materiały dotyczące Cursora od jakiegoś czasu wyskakują mi wręcz z lodówki. W obliczu jego popularności, jak również obecnych trendów, grzechem byłoby go nie przetestować. W tym artykule przedstawię Ci jak pracuję z Cursorem. Podzielę się z Tobą moimi spostrzeżeniami i wnioskami.

Jeśli jeszcze nie wiesz, czym jest Cursor, to spieszę z odpowiedzią. Cursor to środowisko programistyczne zintegrowane z możliwościami, jakie daje wykorzystanie AI. Cursor jest forkiem Visual Studio Code. Oznacza to, że jeśli do tej pory korzystasz z VSCode, to możesz w prosty sposób przenieść swoją konfigurację edytora do Cursora.

Jedną z najważniejszych funkcji Cursora jest uzupełnianie kodu. Polega na tym, że edytor wyświetla nam sugestię dokończenia kodu, który obecnie piszemy. By zaakceptować sugestię, wystarczy nacisnąć Tab. Zasada działania jest analogiczna do działania np. GitHub Copilot.

Druga z kluczowych funkcji to czat. Zasada działania jest analogiczna do działania innych „inteligentnych” czatów pokroju Chatu GPT. Dodatkowo mamy możliwość dołączenia plików, ich fragmentów oraz dodatkowych pytań lub instrukcji. Interakcja z czatem pozwala również na wprowadzanie bezpośrednich sugestii w kodzie.

Jak korzystam z Cursora?

Absolutnie nie uważam się za power usera Cursora. Możliwe (i całkiem prawdopodobne), że idzie to robić lepiej, wydajniej. Sam wciąż się tego uczę. Jednak opisany sposób pracy pozwala mi osiągnąć zadowalające efekty.

Jeśli po przeczytaniu artykułu uznasz, że coś mógłbym robić lepiej, to zachęcam by dać o tym znać w komentarzu. Będzie to z korzyścią dla mnie i pozostałych czytelników 😉

Całość komunikacji z asystentem przeprowadzam w języku angielskim. Dla wygody czytania artykułu polecenia czy konfiguracje przedstawione w artykule są w języku polskim.

Do pracy z Cursorem w momencie tworzenia tego artykułu wykorzystywałem głównie modele Claude 3.5 Sonnet oraz Claude 3.7 Sonnet. To właśnie z nimi otrzymuję najlepsze rezultaty. Testowałem również kilka innych modeli, ale rezultaty były w moim odczuciu nieco gorsze. Cursor pozwala na zdefiniowanie reguł, które mają zostać wykorzystane przy generowaniu kodu.

Co działa dobrze a co niekoniecznie?

Moja główna obserwacja jest taka, że im mniej zmuszamy asystenta do myślenia, tym lepiej. Z moich obserwacji wynika, że LLM-y lubią proste i jednoznaczne instrukcje. Na przykład:

• „Bazując na kodzie z pliku UserAddedEventHandler, w osobnym pliku zaimplementuj klasę UserRemovedEventHandler. Wykorzystaj do implementacji UserRemovedEvent.”
• „Stwórz klasę InMemoryUsersRepository implementującą interfejs IUsersRepository. Obiekty klasy User przechowaj w mapie.”
• „Na podstawie podanego przykładu testów jednostkowych zaimplementuj testy dla klasy InMemoryUsersRepository.”
• „Przygotuj funkcję groupByCustomerId, która pogrupuje obiekty AbandonedCarts po customerId.”

Do podanych poleceń dołączam wspomniane pliki i fragmenty kodu. Podane zadania są oczywiście proste. Jednak jest to oszczędność czasu, który można spożytkować w lepszy sposób.

Moje obserwacje potwierdzają, że dołączenie przykładowego kodu lub plików jest kluczowe. Bez podawania przykładów i dołączania plików obserwowałem dużo gorsze rezultaty. Instrukcje bez przykładów i ze zbyt ogólnymi wytycznymi prowadziły do niezadowalających rezultatów lub halucynacji.

Warto również rozbijać polecenia na mniejsze i używać prostych zdań. Moje obserwacje wskazują, że polecenie „Przygotuj funkcję groupByCustomerId, która pogrupuje obiekty AbandonedCarts, posortuje po id Customera i odfitruje puste koszyki” może dać gorszy rezultat niż rozbicie tego na kilka osobnych. Na przykład:

• „Przygotuj funkcję groupByCustomerId, która pogrupuje obiekty AbandonedCarts po customerId.”;
• „Odfiltruj obiekty, gdzie items.length wynosi 0″;
• „Posortuj klucze obiektu wynikowego rosnąco.”.

Podobną analogię dostrzegam w funkcji czatu. Zaobserwowałem, że krótko żyjące okna czatu działają efektywniej niż korzystanie cały czas z jednej konwersacji. Zauważyłem, że długie konwersacje lub takie, gdzie próbuję rozwiązać więcej niż jeden problem, nie działają dobrze. AI ma wtedy skłonność do powielania błędów, halucynacji lub zwracania odpowiedzi, które nie odpowiadają oczekiwaniom.

Podobną strategię jak przy pisaniu poleceń, przyjąłbym w definiowaniu reguł w konfiguracji Cursora. Celowałbym raczej w specyficzne reguły, które mają spełniać kod. Na przykład zamiast „twórz funkcje zgodne z SOLID, KISS i DRY” dodałbym bardziej precyzyjne instrukcje odpowiadające moim preferencjom:

• „Funkcje nie powinny przyjmować więcej niż 4 parametry”;
• „Preferuj obiekty z parametrami funkcji nad listą parametrów”;
• „Unikaj funkcji modyfikujących dane wejściowe”.

Warto jednak mieć na uwadze, że przy zbyt dużej liczbie instrukcji możemy dostać efekt odwrotny od zamierzonego, wynikający z wysycenia okna kontekstowego.

We wszystkich przedstawionych przykładach zmiany dotyczyły małych fragmentów kodu tzn. funkcji, klasy a maksymalnie pliku. Zaobserwowałem, że im mniejszego fragmentu dotyczy zmiana, tym lepsze rezultaty otrzymywałem. Prowadząc asystenta za rączkę, zwykle robił to, co chciałem.

Zaskakująco dobrze AI sobie radzi z jednym z najtrudniejszych zadań programistycznych… czyli nazewnictwem. Często posiłkuję się AI, jeśli nie mam pomysłu na nazwanie czegoś w kodzie. Zwykle proszę o wygenerowanie kilku propozycji i wśród nich znajduję jakąś, która mnie zadowala. Sporadycznie potrzebuję kilku kolejnych propozycji.

Dobre efekty uzyskiwałem również po napisaniu logiki dla wzorca i rozpoczęciu kodowania dla kolejnych komponentów polegających na tych samych schematach. Przykładowo, po implementacji UserAddedEventHandler zabrałem się do implementacji UserRemovedEventHandler. Jej implementacja sprowadzała się do „Tab Tab Tab” i drobnych poprawek stylistycznych. Podobnie dobrze zadziałało przepisywanie testów na inny framework – „Tab Tab Tab” i dodanie drobnych poprawek. Przy zadaniach przypisywania kodu z podejścia X na Y zalecam, by upewnić się, że asystent nic nie zgubił po drodze. W moim przypadku przy przepisywaniu testów potrafił „zgubić” kilka dość istotnych asercji 😉

Dokumentacja

Tworzenie dokumentacji czy README z wykorzystaniem Cursora też daje radę! Asystent „wypluwa” poprawny tekst zarówno pod kątem merytorycznym, jak i językowym. Zwykle przy tworzeniu takich dokumentów najpierw tworzę inicjalną wersję dokumentacji, a następnie dołączam plik lub fragment tekstu i proszę model o przeredagowanie go zgodnie z podanymi wytycznymi.

Debuggowanie

Zaskakująco dobrze radzi sobie również przy debuggowaniu prostych błędów. Z moich obserwacji wynika, że kluczowe jest podanie stanu obecnego lub treści błędu. Równie ważne jest podanie oczekiwanego rezultatu.

Przykładowo niedawno miałem sytuację, gdzie aplikacja nie łączyła się poprawnie do lokalnej instancji Redisa. Całość działała na kontenerach i jedyne co dostawałem to błąd error: connect ECONNREFUSED 127.0.0.1:6380. Cursor najpierw przeprowadził mnie za rączkę przez diagnostykę czy kontener z serwerem Redisa istnieje, czy odpowiada. Następnie przeanalizował konfigurację aplikacji. Praktycznie od razu wykrył błąd konfiguracji klienta Redisa oraz sieci, w jakiej działały kontenery.

Równie dobrze Cursor poradził sobie w innych sytuacjach, gdzie rozwiązanie było proste do wdrożenia jednak niełatwe do znalezienia:

• brakująca właściwość obiektu wynikająca z braku jej przypisania w kodzie;
• błąd w funkcji sortującej;
• poprawa błędnych asercji i opisów w testach jednostkowych;
• (zasłyszany przykład) – optymalizacja zapytania bazując na kodzie migracji bazy danych, zapytaniu i rezultacie polecenia EXPLAIN.

Prototypowanie

Cursor to dla mnie gamechanger, jeśli chodzi o prototypowanie. Jeśli zależy nam na walidacji pomysłu czy napisaniu kodu, który ma działać, a niekoniecznie wyglądać, Cursor sprawdzi się świetnie. Potrzebowałem napisać prostą aplikację do weryfikacji pewnych założeń, która po spełnieniu swojego zadania miała polecieć do kosza. Zwykle zajmowało mi to jakieś 20-30 minut, z czego połowa to szukanie po code snippetach brakujących klocków. Cursor zrobił to samo w jakieś 20-30…sekund 🤯. Oczywiście jakość kodu była dyskusyjna, ale w tym przypadku mi na tym nie zależało.

Co według mnie nie działa najlepiej?

Znacznie gorzej Cursor poradził sobie z debuggowaniem bardziej złożonych problemów. Całkowicie wyłożył się na błędzie będącym wynikiem wykorzystania zależności wykorzystywanej w kodzie. Po wstępnej próbie zrozumienia problemu asystent zaczął halucynować i produkować, mówiąc wprost, bzdury. Podobnie nie poradził sobie w debuggowaniu problemów związanymi z wyciekami pamięci. Tu również skończyło się na halucynacjach.

W pracy z Cursorem jest to widoczne, że asystentowi brakuje rzeczywistego zrozumienia problemu i polega na poznanych schematach i wzorcach. Jest to dość oczywiste, jeśli wiemy czym są i jak działają LLM-y. Moja efektywność pracy z Cursorem drastycznie spadła, gdy zacząłem od niego wymagać wnioskowania. Podobnie nie dał sobie rady, gdy w grę wchodziło wykorzystanie metod i klas z zależności, których Cursor nie miał jeszcze okazji użyć. Było widać, że podejmuje próby przewidzenia tego, co robię. Jednak całkowicie zgadywał np. nazwy metod, typów czy klas. Na szczęście okazało się, że wystarczy dołączyć pliki zależności do czatu, co rozwiązuje problem.

Podobnie źle poradził sobie, gdy wrzuciłem go na żywioł i poprosiłem o napisanie zestawu testów, bez podania mu przykładów. Wyprodukowany rezultat nie pasował do żadnego znanego mi frameworka do testów w JavaScript. Same przypadki testowe również nie były zbyt sensowne. Wyglądało to, jakby asystentowi zależało wyłącznie na pokryciu wszystkich możliwych ścieżek testowych. Wskazywały na to zarówno opisy, jak i sama konstrukcja testów.

Są również chwile, gdzie Cursor wręcz przeszkadza. Są to momenty, gdy „wiem co robię”. Przeprowadzałem refaktoryzację dość skomplikowanego kawałka kodu. Liczba reguł biznesowych i zależności między poszczególnymi składowymi kodu była ogromna. Moim celem było zredukowanie couplingu, zwiększenie czytelności, reużycie pewnych fragmentów kodu oraz dodanie prostej funkcjonalności. Jakieś 80% sugestii Cursora próbowało władować mnie na minę. Fakt polegania na schematach i brak wiedzy o tym, co biznesowo robi refaktoryzowany kod, kończył się tym, że większość sugestii tylko zaśmiecała mi obszar roboczy edytora. Bardzo widoczne było podejście „wstaw w to miejsce kod, który ma największe prawdopodobieństwo bycia poprawnym w tej sytuacji”. Opisaną sytuację idealnie opisuje poniższy mem.

Podsumowanie

Moja pierwsza styczność z AI w kontekście asystenta programowania sprowadzała się do wykorzystania ChatGPT oraz GitHub Copilot w formie rozszerzenia do VSCode. Wykorzystując te dwa narzędzia, nie widziałem sporego wzrostu mojej wydajności. Oczywiście było widać różnice, ale nie na tyle duże, by jakoś szczególnie się tym zachwycać.

Cursor w mojej opinii to inna liga. Tutaj widzę zauważalną różnicę na plus. Czy to jest już ten moment, gdzie „AI ZASTĄPI PROGRAMISTÓW”? Moim zdaniem zdecydowanie nie. Cursor zdecydowanie przyspiesza i ułatwia moją pracę. Jednak by efektywnie z niego korzystać nadal trzeba mieć wiedzę i umiejętności. Trzeba również przećwiczyć samą pracę z Cursorem. Narzędzie ma również duży potencjał do rozleniwiania. Jeśli już programujemy w „Tab Tab Tab Driven Development”, to sprawdzajmy i starajmy się zrozumieć, co zostało wygenerowane.

Szukając metafory, porównałbym programowanie w Cursorze i tradycyjnym IDE do wyznaczania trasy z nawigacją GPS i papierową mapą. Nawigacja jest dużo wygodniejsza i ma dużo większe możliwości. Jednak nie sprawia ona magicznie, że nie potrzebujemy umiejętności prowadzenia pojazdów, zasad ruchu drogowego itp. Nieumiejętnie wykorzystana nawigacja również może wyprowadzić nas w pole. Dosłownie i w przenośni 😉

Zachęcam do podzielenia się w komentarzu, jakie są Twoje wrażenia z wykorzystania Cursora? Chętnie dowiem się jakie techniki pracy z Cursorem wykorzystujesz. Jeśli coś Cię blokuje przed jego przetestowaniem, to również jestem ciekaw powodów.

Materiały dodatkowe

• Copilot i Cursor w 2025 | Programowanie Nowej Generacji (Tricki, Porady, Pułapki)
• Personalizacja AI dla programisty
• SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering?
• Symbols do not work for code in node_modules when .gitignore and .cursorignore do not exist
• VIBE coding – jak sobie nie zaszkodzić – Kacper Szurek
• Claude 3.7 Sonnet – Anthropic
• Harper Reed’s Blog – My LLM codegen workflow atm
• AI Blindspots

Zaobserwuj mnie na LinkedIn!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zaobserwuj mój profil na LinkedIn, by być na bieżąco!
Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

Chcesz docenić moją pracę? Postaw mi kawę!