Poniedziałek rano. Wpisujesz prompt w Cursor, Claude Code albo Copilot. Trzy minuty później feature ląduje w twoim PR — pull requeście, który kod zgłasza zanim trafi do głównej gałęzi projektu. CI zielone. Ticket zamknięty. Strzał dopaminy. Jesteś teraz 10x developerem.

Tydzień później ten feature pada o trzeciej w nocy. Otwierasz plik. Nie możesz namierzyć buga. Nie ty pisałeś ten kod. Zrobiło to AI. I nie zostawiło żadnych śladów. Potrzebujesz debuggera. Ale nie każdy debugger znaczy dziś to samo.

Dwa debuggery wchodzą do jednego tygodnia

Między 14 a 16 kwietnia, kiedy reszta branży dalej budowała coraz szybsze generatory kodu, dwa narzędzia w końcu przyznały, że kod generowany przez AI psuje się inaczej niż kod pisany przez ludzi — i potrzebuje innych narzędzi do naprawy.

14 kwietnia Cursor 3.1 wypuścił jednocześnie komendę /debug w CLI i agenty działające w tle, które automatycznie tworzą PR-y z issues na GitHubie — jeden release okrakiem na obu stronach barykady. 16 kwietnia Visual Studio 18.5 zrzucił agentowy debugger, który generuje hipotezy awarii i sam ustawia breakpointy. Tymczasem strona generowania kodu nie zwalniała: Claude Code uruchomił Routines 14 kwietnia, a OpenAI zaktualizował Codex 16 kwietnia — do 3 milionów użytkowników tygodniowo, z obsługą pulpitu i ponad 90 wtyczkami.

Stosunek narzędzi generowania do debugowania w tym tygodniu: 3:2 (licząc agenty Cursora po stronie generowania, a jego /debug po stronie debugowania). Niby postęp.

To samo słowo, dwie różne filozofie

Cursorowy /debug i agentowy debugger Visual Studio — oba twierdzą, że debugują. Robią fundamentalnie różne rzeczy.

Cursorowy /debug czyta output błędów z terminala — stack trace'y, failujące asercje, krzyki kompilatora — koreluje je z otwartymi plikami i kontekstem projektu, po czym generuje łatkę. Pod spodem to re-prompting z lepszym kontekstem. AI wchłania błąd, zgaduje co się popsuło i wypluwa zamiennik. Jeśli łatka nie trzyma, promptujesz ponownie. Jeśli to nie trzyma, kasujesz funkcję i generujesz od zera. Workflow jest zoptymalizowany pod szybkość: błąd → łatka → deploy. Twoja robota to ocenić wynik, nie zrozumieć drogę.

To jest uzasadniony wybór projektowy. Te agenty działające w tle w tym samym Cursorze 3.1 — pracujące w chmurowych sandboxach, zamieniające issues z GitHuba w PR-y bez udziału człowieka — jasno pokazują filozofię produktu. Kod jest jednorazowy, liczy się output, iteracja jest tania. /debug jest spójny z tym światopoglądem. Nie rozumiej zepsutego kodu. Zamień go na działający. Jedź dalej.

Agentowy debugger Visual Studio stawia na dokładnie odwrotne podejście. Kiedy opisujesz buga albo wklejasz wyjątek, agent nie generuje poprawki. Generuje hipotezy — uszeregowane wyjaśnienia, dlaczego doszło do awarii. Potem instrumentuje twój kod: ustawia warunkowe breakpointy w miejscach, które każda hipoteza wskazuje jako wadliwe, konfiguruje watche na podejrzanych zmiennych i prowadzi cię przez faktyczną ścieżkę wykonania krok po kroku.

Ogłoszenie Microsoftu opisuje agenta ewaluującego "odpowiedni kod, ostatnie zmiany i typowe wzorce błędów" w celu wygenerowania listy hipotez. Debugger wchodzi potem w coś, co nazywają pętlą śledczą: trafienie na breakpoint, inspekcja stanu, potwierdzenie lub odrzucenie hipotezy, przejście do następnej. Nie czytasz kodu wygenerowanego przez AI. Czytasz faktyczne zachowanie twojego runtime'u, prowadzony przez AI, które zawęża przestrzeń poszukiwań.

Kluczowa różnica mechaniczna: Cursorowy /debug operuje na tekście — kodzie źródłowym jako stringu do przepisania. Debugger Visual Studio operuje na wykonaniu — stanie runtime'u jako dowodzie do zbadania. Jeden traktuje kod jako dokument. Drugi traktuje kod jako maszynę.

Dlaczego to rozróżnienie faktycznie ma znaczenie

Dla null pointera w funkcji pomocniczej — nie ma. Cursorowy /debug załata go w sekundy. Debugger Visual Studio byłby przerostem formy.

Ale bugi generowane przez AI to zwykle nie są null pointery. Badania się piętrzą — dane GitClear o jakości kodu, mnóstwo replikacji akademickich — pokazując, że kod współtworzony z AI niesie ze sobą znacząco więcej błędów logicznych i problemów z wydajnością niż kod pisany ręcznie. Bugi, które naprawdę gryzą, to nie problemy ze składnią. To subtelne rozbieżności behawioralne: handler API, który działa w testach, ale podwójnie zapisuje przy równoczesnych requestach; zapytanie do bazy, które zwraca poprawne wyniki na małych zbiorach, ale generuje joiny O(n²) na skali; maszyna stanów, która obsługuje happy path, ale po cichu korumpuje dane przy retry.

Te bugi nie ogłaszają się w outputcie terminala. Objawiają się jako powolna degradacja, przerywane awarie, niespójności danych, które wypływają dopiero po dniach. Cursorowy /debug potrzebuje komunikatu o błędzie, żeby z czymś pracować. Co mu podasz, kiedy objawem jest "przychody z checkoutu spadły o 4% we wtorek i nikt nie wie dlaczego"?

Podejście Visual Studio oparte na hipotezach radzi sobie z tym inaczej. Opisujesz symptom. Agent proponuje kandydujące przyczyny — może logika retry płatności podwójnie obciąża, może sprawdzanie stanów magazynowych ściga się z aktualizacją koszyka, może obliczanie rabatu obcina zamiast zaokrąglać. Ustawia breakpointy w każdej kandydującej lokalizacji. Odtwarzasz scenariusz i patrzysz, jak ścieżka wykonania ujawnia, która hipoteza się sprawdza.

Wolniejsze? Kolosalnie. Wymaga włączenia mózgu? Niestety tak. Ale to jedyne narzędzie wypuszczone w tym miesiącu, które traktuje debugowanie jako śledztwo, a nie kolejną rundę generowania.

Rozwidlenie ścieżek

I tu branża się rozgałęzia.

Ścieżka A: Model Cursora. Kod jest tani. Debugowanie to regeneracja. Kiedy coś się psuje, wyrzuć i promptuj ponownie. /debug zacieśnia tę pętlę. Agenty w tle robią ją autonomiczną. Logiczny punkt docelowy to kod, którego nikt nigdy nie czyta — generowany, testowany, deployowany i wymieniany przez maszyny w ciągłej pętli. Developerzy stają się product managerami, którzy opisują intencję i oceniają output.

Ścieżka B: Model Visual Studio. Kod jest infrastrukturą. Debugowanie to zrozumienie. Kiedy coś się psuje, zrozum dlaczego zanim naprawisz, bo ta sama strukturalna wada pojawi się w następnej generacji, jeśli tego nie zrobisz. Logiczny punkt docelowy to developerzy, którzy rozumieją mniej kodu w sumie, ale rozumieją go głębiej — specjaliści od zachowania systemu, a nie od produkcji składni.

Żadna ścieżka nie jest głupia. Ale są niekompatybilne w tym samym codebase. Zespół, który debuguje przez regenerację, nie buduje żadnej instytucjonalnej wiedzy o tym, jak ich system faktycznie się zachowuje. Zespół, który debuguje przez śledztwo, spędza czas, który zespoły regeneracyjne nazywają marnotrawstwem.

Zgadnij, które podejście wygrywa

Cursora, oczywiście. Jest szybsze. Wymaga mniej myślenia. Pasuje do vibe-codingowego workflow, który branża jednogłośnie przyjęła. Kasuj, re-promptuj, deployuj, powtarzaj. Śledztwo to problem kogoś innego — dopóki produkcja nie stanie w ogniu i tym "kimś innym" okazujesz się ty o trzeciej w nocy, wpatrzony w trzy serwisy, które napisały trzy różne prompty, obserwując jak interakcja między nimi kładzie checkout.

Nie da się wyjść z awarii systemu rozproszonego samym re-promptowaniem. Potrzebujesz kogoś, kto zmapował ścieżki wykonania. A jeśli twoja kultura debugowania to "zamieniaj aż będzie zielone" — taka osoba nie istnieje w twoim zespole.

Podejście Visual Studio trudniej się sprzedaje. "Pomogę ci myśleć" przegrywa z "naprawię to za ciebie" w każdym demo, każdym tweecie, każdym cyklu hype'u. Ale zrozumienie procentuje składanym. Regeneracja — nie.

Niewygodna prawda

Pytanie nie brzmi, który debugger jest lepszy. Pytanie brzmi, którą filozofię debugowania przyjmuje twój zespół — i czy wybraliście świadomie, czy po prostu defaultowaliście na to, co szybsze.

Jeśli twój stack to bezstanowe funkcje i krótko żyjące serwisy, pętla regeneracji Cursora może rzeczywiście wystarczyć. Zamień zepsutą lambdę. Jedź dalej. Nikt nie musi rozumieć funkcji, która żyje jeden cykl releasu.

Jeśli twój stack ma stan, ma rozproszone transakcje, ma zachowanie emergentne z interakcji komponentów — ktoś musi rozumieć runtime. Nie tekst źródłowy. Runtime. Debugger Visual Studio to pierwsze narzędzie AI, które przyznaje, że taka robota istnieje.

Poniedziałek rano wpiszesz kolejny prompt. Coś się popsuje. Pytanie nie brzmi czy będziesz debugować. Pytanie brzmi, czy debugowanie oznacza "wygeneruj jeszcze raz" czy "zrozum dlaczego". Wybierz świadomie. Defaultem jest regeneracja. A o trzeciej w nocy defaulty to wszystko, co ci zostaje.