Budowanie z Claude Code: od zatwierdzonego planu do udowodnionej zmiany

Sekcja budowania w Claude Code to 21 przewodników dla programistów i tech leadów, które zamieniają zatwierdzony plan w zmergowaną zmianę: implementację w wielu plikach, jedną zmianę w setkach plików, pracę z API, bazą danych i dokumentacją oraz środowisko pracy wokół nich. Każdy przewodnik kończy się dowodem (zielone testy, diff w ustalonym zakresie), a nie czytaniem linia po linii.

Rano zatwierdzasz plan limitowania zapytań per klucz API. Do obiadu Claude Code zmienia 14 plików, po cichu poprawia dwa testy, żeby przechodziły, i zostawia 900-liniowy diff w pull requeście (PR), którego nikt nie chce przeglądać. Plan był dobry; budowanie nie miało punktów kontrolnych.

Te przewodniki budują małymi krokami: każdy krok uruchamia twoje testy, typecheck i lint i musi się obronić, zanim zacznie się następny, a zmiana kończy się raportem z dowodami, który ty i recenzent sprawdzacie zamiast każdej linii.

Którego przewodnika po budowaniu potrzebujesz?

Twoja sytuacja	Zacznij od	Z czym wychodzisz
Zatwierdzony plan obejmuje kilka plików	Od planu do działającego kodu i zmiany w wielu plikach	Małe commity, każdy zielony w CI
Jedna mechaniczna zmiana w setkach plików	Operacje wsadowe (wbudowany skill /batch) i refaktoryzacja na dużą skalę	Niezależne PR-y, każdy z własną bramką
Lepsza struktura, to samo zachowanie	Wzorce refaktoryzacji	Najpierw testy charakteryzujące, potem refaktoryzacja
Nowe endpointy REST lub GraphQL	Budowanie API	Kontrakt i testy, które go sprawdzają
Zmiany schematu, zapytań lub danych	Praca z bazą danych i migracje	Migracje sprawdzone na jednorazowej bazie
Dostawca płatności, e-maili lub OAuth	Integracje z usługami zewnętrznymi	Kod integracji przetestowany w sandboksie
Dokumentacja rozjeżdża się z kodem	Dokumentacja	Dokumentacja wygenerowana na nowo i pilnowana przez bramkę
Repozytorium nie mieści się w kontekście	Duże bazy kodu	Sesje o wąskim zakresie, które czytają tylko to, co ważne
Claude zapomina twoje konwencje między sesjami	System pamięci	CLAUDE.md i reguły, które działają

Reszta sekcji to twoje codzienne środowisko: flagi i sesje w wierszu poleceń, inżynieria promptów, polecenia slash, praca w terminalu, współpraca IDE i CLI, aplikacja desktopowa, optymalizacja przepływu pracy, triki na co dzień i funkcje, których jeszcze nie próbowałeś.

Przeprowadź pętlę budowania dla jednej zmiany

Pętla wymaga planu zapisanego w repozytorium; jeśli go nie masz, zacznij od planowania z Claude Code.

1. Uruchom odizolowaną, nazwaną sesję w nowym git worktree, żeby budowanie nie kolidowało z inną pracą:

   claude --worktree rate-limit -n rate-limit

2. Przekaż Claude’owi plan i tylko pierwszy krok, używając pierwszego promptu poniżej.

3. Po każdym kroku Claude uruchamia polecenia weryfikacyjne i składa raport. Sprawdzasz raport, nie diff.

4. Przed PR-em uruchom w sesji /code-review, popraw to, co znajdzie, a potem drugim promptem przygotuj raport z dowodami.

5. Jeśli krok pójdzie źle, naciśnij dwa razy Esc (albo uruchom /rewind) i wybierz punkt kontrolny sprzed tego kroku. Punkty kontrolne przywracają tylko pliki edytowane narzędziami edycji Claude’a; nie cofają commita ani zmian zrobionych przez Bash. Jeśli krok został już zacommitowany, uruchom też git reset --hard HEAD~1, a potem sformułuj krok od nowa.

Od v2.1.280 (oba kanały wydań na 2026-10-12) Claude Code domyślnie używa Claude Opus 5.5 z wysiłkiem medium; na starszej instalacji sprawdź claude --version. Przy trudnym kroku najpierw podnieś wysiłek (/effort high albo --effort xhigh), a model zmieniaj dopiero wtedy, gdy przemawiają za tym twoje własne wyniki. Zobacz przegląd modeli.

Prompt do skopiowania: wdrażaj plan krok po kroku

Implement docs/plans/rate-limit.md one step at a time. Start with step 1 only.

For each step:
1. Write or update the tests named in the plan's acceptance criteria and
   run them. Show me they fail for the right reason.
2. Make the smallest change that makes them pass. Touch only the files the
   plan lists as in scope.
3. Run the test, typecheck, and lint commands from the plan's
   Verification section, exactly as written.
4. Commit with a message that names the step.
5. Stop and report: files changed, commands run with pass/fail, and
   anything that differs from the plan.

Never edit an existing test to make it pass. If the plan is wrong or a
step needs an out-of-scope file, stop and ask instead of improvising.

Prompt do skopiowania: raport z dowodami przed PR

Compare this branch against main and write an evidence report for the PR:
- Each acceptance criterion from docs/plans/rate-limit.md, the test that
  proves it, and the result of running that test now.
- Output of the full test, typecheck, and lint commands.
- Every changed file, marked in scope or OUT OF SCOPE per the plan.
- Every existing test that was modified or deleted, with the reason.
- Anything you are not sure about, listed as open questions.
Do not fix anything in this step. Report only.

Jak sprawdzić zbudowaną zmianę bez czytania każdej linii?

Akceptujesz dowody, których agent nie podrobi prozą. Zmiana jest gotowa, gdy spełnia pięć warunków:

1. Testy akceptacyjne przeszły z czerwonych na zielone, a ty widziałeś, jak padają.
2. Te same testy, typecheck i lint przechodzą w CI, a nie tylko na laptopie.
3. git diff --stat main pokazuje wyłącznie pliki, które plan uznał za objęte zakresem.
4. Żaden istniejący test nie zmienił się bez powodu, który akceptujesz.
5. /code-review (albo agent recenzujący w CI) nie zgłosił niczego, co wciąż jest otwarte.

Czytasz tylko to, co te warunki wskażą. Żeby łapać błędy typów w trakcie budowania, a nie dopiero w CI, dodaj hook z typecheckiem (automatyzacja hookami). Programista akceptuje zmianę mieszczącą się w zatwierdzonym planie; tech lead akceptuje wszystko, co zmienia zakres planu. Uzasadnienie znajdziesz w tekście dowody zamiast diffów; format PR-a to pakiet dowodów.

Co idzie nie tak przy budowaniu z Claude Code?

Objaw	Prawdopodobna przyczyna	Jak wyjść
Testy przechodzą, ale funkcja nie działa	Claude poprawił testy albo asercje są za słabe	Przywróć każdy zmieniony test poleceniem git restore --source=main -- TEST_PATH, gdzie TEST_PATH to ścieżka zmienionego testu, i powtórz krok z zasadą „never edit an existing test”
Diff dotyka plików spoza planu	Krok był za duży albo plan pominął jakieś wywołanie	Naciśnij dwa razy Esc (albo uruchom /rewind) i wybierz punkt kontrolny sprzed kroku; jeśli krok został już zacommitowany, uruchom też git reset --hard HEAD~1. Zaktualizuj plan, zanim pójdziesz dalej
Jakość spada pod koniec długiej sesji	Kontekst wypełniły wcześniejsze kroki	Zrób commit, otwórz nową sesję i wskaż jej plan oraz następny krok
Dwie sesje nadpisują sobie pliki	Obie pracowały w jednym checkoucie	Daj każdej sesji własny worktree przez --worktree

Dokąd iść po zbudowaniu zmiany

• Testowanie i debugowanie z Claude Code: testy, które coś znaczą, i szukanie przyczyn, dla których padają.
• Code review i wdrożenie z Claude Code: od zielonej gałęzi do zmergowanej i wdrożonej zmiany.
• Przepływy budowania dla wszystkich narzędzi, etap budowania w metodzie oraz ten sam etap w Codexie i Cursorze.