Pair programming z agentem Cursora

Pair programming z agentem Cursora to sesja, w której programista i agent dzielą się rolami kierowcy i nawigatora przez całą jedną funkcję. Plan Mode ustala projekt, Agent mode buduje po jednym wycinku, zaczynając od testu, a debugowanie zaczyna się od padającego testu. Programista odpowiada za kryteria akceptacji i dowody; agent pisze większość kodu.

Ta strona jest dla programistów, którzy używają już agenta Cursora do pojedynczych zadań (zobacz Praca z czatem agenta w Cursorze) i chcą z nim przejść przez całą funkcję. Sytuacja: budujesz preferencje powiadomień z ustawieniami per kanał, domyślnymi wartościami organizacji, które użytkownik może nadpisać, i oknami dostarczania zależnymi od strefy czasowej. Podstawowy scenariusz zajmuje jedno popołudnie. Przypadki brzegowe to miejsce, gdzie wszystko się sypie, a jeden długi prompt „zbuduj całość” zwraca 600 linii, których nie da się sprawdzić.

Co zyskujesz z sesji pair programmingu w Cursorze

Tabelę ról, która mówi, kto prowadzi w każdej fazie i jaki dowód ją zamyka
Cztery prompty do skopiowania: sesję projektową, rozstrzygnięcie rozwidlenia projektu bez edycji, wycinek budowany od testu i objazd debugowania oparty na dowodach
Kontrolę po każdym kroku (czerwony test, zielony test, diff w granicach planu, jeden commit), która zastępuje czytanie każdej linii
Sposób, żeby ta sama poprawka nie wracała, i sposób na przeniesienie sesji do nowego czatu
Kroki naprawcze dla sześciu typowych awarii sesji w parze

Kto prowadzi, gdy programujesz w parze z agentem Cursora?

W klasycznym pair programmingu kierowca pisze, a nawigator pilnuje kierunku. Z agentem to agent wykonuje niemal każde naciśnięcie klawisza, więc ty na stałe siadasz w fotelu nawigatora: wyznaczasz kierunek, definiujesz „gotowe” dla każdego kroku i sprawdzasz dowody. Tabela to cała metoda; kolejne sekcje ją rozwijają.

Faza	Agent prowadzi	Ty nawigujesz	Dowód, który zamyka fazę
Projekt	Czyta kod, proponuje plan, zadaje pytania	Odpowiadasz, wybierasz na każdym rozwidleniu, tniesz zakres	Zapisany plan: ponumerowane wycinki, lista plików, jeden test na kryterium akceptacji
Budowa wycinka	Pisze test, potem kod, potem uruchamia kontrole	Nazywasz wycinek, pliki i to, czego nie wolno zmienić	Nowy test najpierw padał, a teraz przechodzi; polecenie weryfikacji jest zielone; diff mieści się w liście plików
Objazd debugowania	Odtwarza błąd w teście, stawia hipotezy, dodaje logowanie	Wybierasz hipotezę do sprawdzenia; odrzucasz poprawki przed dowodem	Padający test albo linia logu, która potwierdza jedną przyczynę
Przekazanie	Pisze krótką notatkę o stanie	Sprawdzasz notatkę w 30 sekund	Notatka z decyzjami, gotowymi wycinkami i następnym krokiem
Pull request	Podsumowuje, co i dlaczego się zmieniło	Czytasz testy i każdy plik wskazany przez dowody	Zielone CI, rozwiązane komentarze z review

Jedna zasada stoi za tą tabelą: żaden wycinek nie kończy się na słowie agenta. Każdy kończy się poleceniem, które ty albo CI możecie uruchomić ponownie.

Przygotuj sesję przed pierwszym promptem

Pięć minut przygotowań sprawia, że każdy późniejszy krok da się sprawdzić.

Utwórz gałąź z czystego drzewa roboczego: git switch -c feat/notification-prefs. Trzymaj otwarty własny terminal do kontroli; wynik w terminalu agenta to jego raport, a nie twój dowód.
Znaj swoje polecenie weryfikacji, to samo, które uruchamia CI: na przykład npm run verify, obejmujące sprawdzanie typów, lint i testy. Jeśli repozytorium go nie ma, napisz je przed sesją, bo każdy wycinek poniżej na nim się kończy.
Zapisz kryteria akceptacji, zanim agent zobaczy zadanie, zwykłymi zdaniami, które da się zamienić w testy: „Użytkownik bez własnych preferencji dostaje domyślne ustawienie organizacji dla każdego kanału”. Jeśli jeszcze nie potrafisz ich napisać, powstaną w sesji projektowej opisanej niżej. Format pokazuje strona Wykonywalne kryteria akceptacji.
Sprawdź, czy reguły projektu opisują logowanie, obsługę błędów i dostęp do danych, żeby nie poprawiać tego samego wzorca w każdym wycinku. Położenie plików i tryby ładowania opisuje strona Reguły projektu w Cursorze.

Uzgodnij projekt w Plan Mode

Plan Mode, słowami Cursora, „creates detailed implementation plans before writing any code”, czyli tworzy szczegółowy plan implementacji, zanim powstanie jakikolwiek kod (dokumentacja Plan Mode, zweryfikowano 28 sierpnia 2026). To pierwsze zadanie nawigatora: uzgodnić trasę, zanim ktokolwiek ruszy. Otwórz nowy czat, uruchom czat w Plan Mode i wklej prompt.

We are pairing on a notification preferences feature. Requirements:
- Users set preferences per channel: email, sms, push, in_app.
- Organizations set defaults; a user's own setting overrides the default.
- Each preference can have a delivery window (start, end, IANA timezone).
- GET /api/preferences/preview returns what a user would receive right now.

Before proposing anything, read the existing user, organization and
notification code and list the files you read.

Then ask me every question whose answer changes the design. Wait for my answers.

After my answers, write a plan with:
1. Slices small enough that each one ends with one new test passing.
   Order them so the data model comes first and the preview endpoint last.
2. For each slice: files to create or change, and the test that proves it.
3. The edge cases you would test: midnight-crossing windows, DST changes,
   a user with no preferences, an organization with no defaults.
4. What you will NOT build in this feature.
Save the plan to docs/plans/notification-preferences.md and the file list,
one path per line, to docs/plans/notification-preferences.files.

Podważaj plan tak, jak podważałbyś propozycję kolegi z zespołu. Wytnij wycinek, który istnieje tylko „dla przyszłej elastyczności”. Zapytaj, po co nowa tabela, skoro istniejąca mogłaby dostać kolumnę. Gdy pytanie ma dwie rozsądne odpowiedzi, nie pozwól agentowi wybrać po cichu: poproś o porównanie, w którym nie wolno mu niczego edytować.

Do not edit any files in this turn. Read @docs/plans/notification-preferences.md
and the existing models it names.

I am choosing between:
A) One preferences table with a scope column ('organization' | 'user'),
   merged at query time.
B) Separate org_preferences and user_preferences tables, merged in the
   service layer.

For each option, answer with file paths from this repository:
- The query that answers "what does user X receive on channel Y right now?"
- What happens when the user has no row for a channel.
- What changes if we add team-level preferences next quarter.
- Which existing table or service it most resembles.
Finish with your recommendation and the one fact that would change it.

Decyzję podejmujesz ty, a plik planu ją zapisuje. Jeśli twoja wersja Cursora oferuje tryb Ask tylko do odczytu, pasuje do tego promptu; linia „do not edit” zabezpiecza prompt w każdym trybie. Szerzej o doborze trybu pisze strona Tryby agenta w Cursorze.

Gdy plan jest ostateczny, zacommituj go we własnym terminalu i oznacz tagiem punkt odniesienia, z którym porównuje się każda kontrola zakresu. Tag, w odróżnieniu od zmiennej powłoki, przetrwa zamknięcie terminala i przejście do nowego czatu:

git add docs/plans && git commit -m "docs: notification preferences plan"
git tag -f plan-base                    # durable base; survives a closed terminal

Buduj po jednym wycinku w Agent mode

Przełącz się na Agent mode i przekaż jeden wycinek. Wycinek kończy się jednym nowym, przechodzącym testem i zielonym poleceniem weryfikacji, dzięki czemu każdy diff jest na tyle mały, że kontrola opisana niżej ma sens.

Implement slice 1 of @docs/plans/notification-preferences.md
(the preferences data model and migration). Follow the patterns in
@src/lib/db/schema.ts exactly.

Work in this order and stop at each marker:
1. Write the test for slice 1 first. Run it and show me that it fails,
   and why. STOP and wait for me.
2. After I reply "go", write the minimum code to make it pass.
3. Run `npm run verify` and paste the last 20 lines of output.

Rules for this slice:
- Change only the files the plan lists for slice 1 (see the plan's slice 1 section).
- Do not create API routes, services or UI; those are later slices.
- Do not add dependencies.
- If you think the plan is wrong, say so and stop instead of improvising.

Zatrzymanie po padającym teście to najcenniejsza pauza w całej sesji. Test, który pada z właściwego powodu, dowodzi, że coś sprawdza; test napisany po kodzie często przechodzi niezależnie od tego, co kod robi. Czytaj test, a nie implementację: ma 20 linii i jest specyfikacją, z której kod będzie rozliczany.

Gdy agent zgłasza zielony wynik, sprawdź dowody sam, zanim przejdziesz do następnego wycinka:

# Run in your terminal, not the agent's.
npm run verify                          # the same gate CI runs
git add -A                              # stage everything, new files included
git diff --cached --stat                # size and spread of the change
git diff --cached --name-only plan-base -- . ':!docs/plans' ':!docs/handoff' \
  | grep -vxF -f docs/plans/notification-preferences.files
git commit -m "feat(prefs): slice 1 - preferences model"

Pusty wynik linii z grep oznacza, że każdy zmieniony plik jest w planie. Dwa wzorce :! pomijają same pliki planu i notatki przekazania, więc dopisanie luki do planu albo późniejsza notatka przekazania nie pojawią się jako dryf. Lista .files obejmuje całą funkcję, więc ta kontrola dowodzi, że zmiana mieści się w planie, a nie w wycinku 1; do tego porównaj wynik --stat z sekcją wycinka 1 w planie. Wypisana ścieżka to albo prawdziwa luka, którą dopisujesz do pliku planu, albo dryf, który wycofujesz poleceniem git restore --staged --worktree PATH (a w przypadku nowego pliku git rm --cached PATH i usunięciem go). Commituj każdy zielony wycinek: każdy commit to znany, dobry punkt, do którego możesz wrócić, i oddziela diff następnego wycinka. Jeśli twoja wersja Cursora zapisuje własne checkpointy, strona Checkpointy i gałęzie wyjaśnia, jak uzupełniają one te commity.

Jeśli coś jest nie tak, powiedz dokładnie co i dlaczego, w jednej wiadomości:

The migration stores delivery_window_start as a timestamp with timezone.
Use a plain time column, because the timezone lives in its own column.
Add a unique constraint on (scope_type, scope_id, channel). Re-run the
slice 1 test and npm run verify, and change nothing else.

Utrzymaj agenta przy twojej architekturze

Agent, który wykonuje większość pracy przy klawiaturze, dryfuje w przewidywalny sposób: nowa biblioteka do dat, drugi styl logowania, zapytanie, o którym plan nie wspominał. Trzy nawyki trzymają go na twojej drodze.

Ogradzaj każdy wycinek tym, czego nie wolno zrobić. Ograniczenia negatywne są tanie i agent łatwo się do nich stosuje:

Implement the delivery-window check in src/services/preferences.ts. Do NOT:
- add a date library; use the helpers in src/lib/time.ts
- add a database query; use the preferences already loaded by the caller
- change the signature of isWithinDeliveryWindow()

Wskaż przykład zamiast go opisywać. Follow the error handling in @src/services/orders.ts działa lepiej niż akapit o twoich klasach błędów. Wybór tego jednego wzorcowego pliku opisuje strona Zarządzanie kontekstem w Cursorze.

Zamień powtarzaną poprawkę w regułę. Gdy drugi raz piszesz „użyj loggera z src/lib/logger.ts, nie console.log”, przerwij sesję na dwie minuty i poproś agenta o szkic reguły projektu z tą linią. Przejrzyj ją, zacommituj, a poprawka przestanie wracać w tym czacie i w czatach twoich kolegów. Strona Reguły projektu w Cursorze pokazuje, jak zadaniem-sondą sprawdzić, że reguła się ładuje.

Zrób objazd debugowania, nie gubiąc wątku

Błędy wychodzą w połowie funkcji. Pułapka polega na tym, że pozwalasz agentowi „spróbować poprawki” na podstawie domysłu: będzie produkował wiarygodnie wyglądające zmiany, aż któraś przypadkiem przejdzie, a sesja zgubi plan. Niech objazd zaczyna się od dowodów i ma wyraźne granice.

Detour from slice 5. Do not change production code until I say so.

Symptom: GET /api/preferences/preview?user_id=abc-123 returns []
although the user's organization has defaults for email and push.
What I know: the merge function passes its own tests in isolation;
org preference rows exist in the local database.

1. Write a failing test that reproduces this through the route handler.
   Run it and show the failure.
2. List at most three hypotheses, each with the file and line it points at.
3. For the most likely one, add temporary logging or an assertion that
   would confirm or rule it out. Run the test again and show the output.
4. STOP. Tell me which hypothesis the evidence confirms.

Gdy dowody potwierdzą przyczynę, napisz „fix it”, a padający test stanie się dowodem poprawki. Poproś agenta o usunięcie tymczasowego logowania, uruchom polecenie weryfikacji i zacommituj poprawkę jako osobny commit, zanim wrócisz do wycinka 5. Jeśli twoja wersja Cursora oferuje Debug Mode, prowadzi on podobną pętlę hipotez i logowania; powyższy prompt działa w Agent mode niezależnie od tego. Dłuższe dochodzenia opisuje strona Debugowanie z AI w Cursorze.

Przenieś długą sesję do nowego czatu

Funkcja może trwać dłużej, niż jeden czat pozostaje użyteczny. Objawy: agent powtarza błąd, który już poprawiłeś, albo zapomina decyzję sprzed godziny. Nie kłóć się z długą historią. Zamknij czat notatką przekazania i kontynuuj w nowym, według promptu przekazania ze strony Zarządzanie kontekstem w Cursorze. Stan niosą plik planu, zacommitowane wycinki i notatka, więc nowy czat zaczyna się od:

Read @docs/plans/notification-preferences.md and @docs/handoff/notification-prefs.md.
Slices 1-4 are committed (see git log). Continue with slice 5 exactly as planned,
test first, and stop after showing me the failing test.

Każdy skończony wycinek to commit z zielonym poleceniem weryfikacji, więc koniec czatu niczego nie zabiera.

Jak zweryfikować sesję w parze bez czytania każdej linii?

Uważnie czytasz trzy rzeczy: plan, każdy nowy test i każdy plik wskazany przez kontrolę zakresu. Resztę pokrywają polecenia, które nie zależą od raportu agenta.

Kontrola	Kiedy	Czego dowodzi	Kto zatwierdza
Test pada, zanim powstanie kod	Każdy wycinek	Test sprawdza zachowanie, a nie tylko kod, który akurat powstał	Ty
`npm run verify` we własnym terminalu	Każdy wycinek i w CI	Typy, lint i cały zestaw testów przechodzą, nie tylko nowy test	Ty, potem CI
Kontrola zakresu względem listy plików z planu	Każdy wycinek	Agent nie zmienił niczego, o co go nie proszono	Ty
Jeden commit na zielony wycinek	Każdy wycinek	Każdy krok da się cofnąć osobno	Ty
Mapa kryterium → test w opisie PR	Pull request	Każde kryterium akceptacji ma nazwany test	Recenzent, który czyta mapę i testy
Bugbot albo inny agent recenzujący na PR	Pull request	Drugi czytelnik szukający błędów i problemów bezpieczeństwa w całym diffie	Recenzent decyduje, na co zareagować

Bugbot recenzuje pull requesty pod kątem błędów, problemów bezpieczeństwa i jakości kodu, a strona Code review w Cursorze pokazuje, jak połączyć go z recenzentem-człowiekiem. Szerszy argument za tym, by recenzenci czytali dowody zamiast całych diffów, znajdziesz na stronach Czytanie dowodów zamiast kodu i Pakiet dowodów dla pull requestów agenta.

Co się psuje w pair programmingu z agentem Cursora?

Objaw	Prawdopodobna przyczyna	Naprawa
Agent improwizuje poza planem	Pliku planu nie ma w czacie albo wycinek był nieprecyzyjny	Wskazuj plan przez `@` w każdym prompcie budującym i nazywaj wycinek numerem. Dodatkowe śledzone pliki wycofaj przez `git restore --staged --worktree PATH`; dodatkowe nowe pliki usuń (po `git rm --cached PATH`, jeśli są w indeksie)
Prosisz o model danych, a dostajesz model, endpointy i testy	Prompt nie miał warunku zatrzymania	Dopisz „Do not create routes, services or UI” i znacznik STOP. Zachowaj tylko pliki wycinka i zacommituj
Agent zapomina o poprawkach	Historia czatu niesie stare próby, które konkurują z twoimi poprawkami	Napisz notatkę przekazania i zacznij nowy czat; zamień poprawkę w regułę projektu
Po trzech promptach okazuje się, że podejście jest złe	Rozwidlenie projektu rozstrzygnął agent, a nie ty	Odrzuć niezacommitowany wycinek przez `git restore --staged --worktree .`, potem `git clean -n` pokaże, a `git clean -f` usunie pozostałe nieśledzone pliki, wróć do promptu o rozwidleniu i popraw plan przed ponowną budową
Testy przechodzą, ale funkcja jest błędna	Kryterium akceptacji nie miało testu albo test powstał po kodzie	Dopisz brakujące kryterium do planu, napisz jego test i zobacz, jak pada, a potem popraw kod
Agent twierdzi, że „wszystkie testy przechodzą”, a CI się nie zgadza	Agent uruchomił część testów albo przeczytał nieaktualny wynik	Za dowód uznawaj tylko własny terminal i CI. Poproś agenta o uruchomienie dokładnie polecenia weryfikacji i wklejenie wyniku

Dokąd dalej z pair programmingiem w Cursorze

Tryby agenta w Cursorze Kiedy planować, badać, budować albo debugować i jaki dowód kończy każdy tryb.

Checkpointy i gałęzie Cofnij jedną turę agenta albo cały eksperyment i zachowaj tylko zweryfikowane zmiany.

Test-driven development w Cursorze Niech padający test będzie specyfikacją, z której rozliczasz każdy wycinek.

Wzorce współpracy człowiek-AI Gdzie decyzję musi podjąć człowiek, a gdzie mogą ją podjąć dowody.