Przez lata mój schemat debugowania wyglądał identycznie: błąd w terminalu, zaznacz, skopiuj, wklej do Google, a od paru lat do ChatGPT. Ten nawyk ma słaby punkt, zewnętrzny czat nie widzi projektu. Nie zna typów zdefiniowanych w pliku obok, nie wie, jak moduły się importują, i zgaduje na podstawie wyrwanego fragmentu. Trochę jak lekarz, który diagnozuje przez telefon, bez karty pacjenta i wyników badań. Od kiedy koduję w Cursorze, edytorze zbudowanym na VS Code, w którym asystent ma dostęp do całego repozytorium, debuguję inaczej. Poniżej pięć mechanizmów, z których korzystam na co dzień.
@Codebase: pytanie z kontekstem całego repozytorium
Typowy błąd objawia się w pliku A, a przyczyna siedzi w pliku B, importowanym przez plik C. Czat, który dostał tylko stack trace, tego łańcucha nie prześledzi. Cursor indeksuje repozytorium w bazie wektorowej, a tag @Codebase w oknie czatu (Ctrl+L) każe modelowi przeszukać projekt, zanim odpowie. To zmienia sposób zadawania pytań:
Słabo: Co oznacza błąd NullPointerException?
Lepiej: @Codebase Dlaczego processUserData zwraca null,
skoro dane pobieramy w UserService.getActiveUsers?Na drugie pytanie Cursor odnajduje definicję funkcji, miejsca wywołań i przepływ danych między plikami. Różnicę widzę najmocniej przy regresjach, w których przyczyna leży dwa importy dalej niż objaw, ręczne prześledzenie takiej ścieżki zajmowało mi kiedyś pół dnia.
Stack trace prosto z terminala, bez kopiowania
Gdy build się wywala albo testy nie przechodzą, Cursor rozpoznaje stack trace w terminalu i przy komunikacie pokazuje przycisk „Add to Chat”. Jedno kliknięcie zamiast zaznaczania i wklejania. Znika też klasyczny błąd kopiowania: ucięta pierwsza linia logu, czyli ta, w której siedział właściwy wyjątek.
Przy problemach środowiskowych (brakująca biblioteka, zła wersja Node) asystent proponuje komendę naprawczą do uruchomienia jednym kliknięciem. Każdą taką komendę czytam, zanim ją odpalę. Ten nawyk przyniosłem z QA i nie zamierzam go wyłączać: narzędzie, które modyfikuje środowisko, zasługuje na tyle samo nieufności co skrypt od nowego stażysty.
Ctrl+K: poprawki przeglądane jak code review
Czat nadaje się do analizy; poprawki wprowadzam edycją inline. Zaznaczam podejrzany fragment, wciskam Ctrl+K (Cmd+K na Macu) i wpisuję polecenie, na przykład „napraw obsługę wartości ujemnych na wejściu”. Cursor pokazuje zmianę jako diff: na czerwono to, co usuwa, na zielono to, co dodaje. Akceptuję pojedyncze linie albo całość.
Ten widok decyduje o moim zaufaniu do narzędzia. Przeglądam każdą propozycję tak, jak przeglądałbym pull request kolegi z zespołu, kod bez review trafia na produkcję z niespodziankami niezależnie od tego, czy napisał go człowiek, czy model. Diff robi z akceptacji świadomą decyzję, a z podmiany bloków kodu na ślepo, przeszłość.
Błędy logiczne, których linter nie zobaczy
Najdroższe błędy nie rzucają wyjątków. Aplikacja działa, tylko liczy źle. W takich sytuacjach opisuję Cursorowi intencję zamiast objawu:
Ta funkcja ma filtrować użytkowników aktywnych
w ostatnich 30 dniach, a zwraca pustą listę.
Sprawdź logikę dat w utils/dateHelpers.ts.Model z dostępem do plików pomocniczych wyłapuje pomyłki stref czasowych, porównywanie obiektów Date operatorem ===, błędy off-by-one w pętlach. Klasyczny przykład: filtr porównuje datę zapisaną w UTC z datą lokalną, testy przechodzą przez cały miesiąc i sypią się pierwszego dnia następnego. Żaden linter tego nie zgłosi, bo składniowo kod jest poprawny. Więcej o tym, jak używam modeli językowych do wykrywania tej klasy błędów, piszę w tekście o LLM w testowaniu.
@Docs: dokumentacja świeższa niż wiedza modelu
Modele językowe mają wiedzę odciętą w konkretnym punkcie czasu. Kiedy debuguję problem z nową wersją frameworka, podpowiedzi potrafią dotyczyć API sprzed dwóch wydań, składnia wygląda znajomo, ale metoda już nie istnieje. Tag @Docs pozwala wskazać adres aktualnej dokumentacji; Cursor ją indeksuje i odpowiada na podstawie oficjalnych wytycznych, a nie wątków z forów sprzed lat.
Najczęściej sięgam po to przy migracjach starszego kodu do nowych wersji bibliotek, gdzie połowa błędów wynika ze zmienionych sygnatur i przeniesionych modułów. Podpięcie dokumentacji docelowej wersji zamienia zgadywanie w sprawdzanie.
Jak pomagam w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości, a z asystentami AI koduję codziennie, Cursor jest u mnie narzędziem roboczym, nie ciekawostką z demo. W QA Sensei pomagam zespołom ustawić pracę z takimi narzędziami: gdzie skracają debugowanie, jak weryfikować ich wynik i od czego zacząć, żeby nie skończyło się na opłaconych licencjach bez zmiany w codziennej pracy. O tym, jak podejść do tego w skali firmy, piszę w tekście o wdrożeniu AI w firmie. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta.
Jak zbudować całą warstwę jakości wokół kodu z asystentów AI, opisuję tutaj: QA dla kodu tworzonego z AI.