Rozdział o tym, jak dobrze pracować z asystentem i jak nie tracić kontekstu między rozmowami.

Najważniejszy rytm: plan → iteruj → review. Zanim AI zrobi coś na dużą skalę, ma pokazać plan albo mały szkic (trzy przykłady, nie sto), Ty dajesz uwagi, i dopiero potem skalujecie. Oszczędza to produkowania setek rzeczy do wyrzucenia.

Druga zasada: potwierdzaj to, co nieodwracalne albo „na zewnątrz” — wysyłkę maila, publikację, kasowanie danych, wdrożenie na żywo. I pamiętaj, że zgoda w jednym miejscu nie rozciąga się na następne: „wdróż to” nie znaczy „wdrażaj zawsze wszystko”.

Jest też pamięć (memory/) — miejsce na to, czego nie da się wyczytać z kodu: kim jesteś, jak wolisz pracować, jaki jest cel biznesowy. Nie zapisuje się tam rzeczy, które repo i tak wie (struktury kodu, historii gita).

Na koniec — domykaj pracę czytelnym podsumowaniem (co się zmieniło, dowód, że działa, następne kroki), a nie ścianą tekstu. Głębię dobierasz do odbiorcy: techniczny dostaje hashe i liczby, nietechniczny — proste „co się zmieniło i co dalej”.

Przykład iteracji: grafiki do social mediów robisz 3 → poprawki → 10 → poprawki → 100. Nigdy odwrotnie — bo poprawka na trzech sztukach jest darmowa, a na stu boli.

Doczytaj: dobre praktyki pracy z Claude Code · pamięć projektu w Claude Code.

06 — Współpraca i pamięć

Przykazania VI i X: jak pracujemy razem i jak nie tracimy kontekstu.

Styl współpracy (użytkownik + Claude)

Plan → iteruj → review. Najpierw pokaż plan albo mały szkic (3 przykłady, nie 100), zbierz feedback, dopiero potem skaluj. Karty OG w projekcie referencyjnym: 3 → poprawki → 10 → poprawki → 100. Nigdy odwrotnie.
Rekomenduj, nie rozkładaj parasola opcji. Gdy ważysz wybór — daj rekomendację z uzasadnieniem, nie wyczerpującą listę, której i tak nie zrealizujesz. Pytaj tylko, gdy odpowiedź realnie zmienia, co robisz dalej (i gdy nie wynika z kodu/sensownego defaultu).
Liczby weryfikuj u źródła — nie z pamięci, nie z docsów.
UX z ciepłem. Poprawność to minimum; produkt ma być przyjemny. Estetyka i ton się liczą (w produktach wrażliwych szczególnie: minimalistycznie, ale ciepło).
Mów w języku użytkownika. Rozmawiaj z użytkownikiem w jego natywnym języku — najlepiej, gdy briefuje Cię w języku, w którym myśli. Ustal go na starcie i zapisz, w ilu/jakich językach mówi/czyta w AI_README/CLAUDE.md — to konfiguracja współpracy, ustawiana raz (→ 07, 01). Kod, commity i docsy techniczne zostają po angielsku bez względu na język rozmowy; terminy techniczne (commit, deploy, Slug — Czytelna, krótka część adresu strony, opisująca jej treść słowami zamiast tajemniczego numeru. Lepszy dla człowieka i SEO; trwały slug nie psuje linków przy zmianach.) po angielsku wewnątrz dowolnego języka.
Rozdzielaj niezwiązane rzeczy — w commitach i w myśleniu. Jeden temat naraz.

Potwierdzaj to, co nieodwracalne i „na zewnątrz”

Działania trudne do cofnięcia albo wychodzące poza maszynę potwierdzaj pierwej, chyba że masz trwałą autoryzację albo wyraźne „rób bez pytania”:

deploy na prod, wysyłka maili, publikacja treści, kasowanie/nadpisywanie danych.
Zgoda w jednym kontekście nie rozciąga się na następny. „Wdróż X” ≠ „wdrażaj wszystko zawsze”.
Zanim skasujesz/nadpiszesz — spójrz na cel. Jeśli to, co widzisz, przeczy opisowi, albo tego nie tworzyłeś — zgłoś, nie kasuj.
Publikacja do zewnętrznego serwisu = treść może zostać zindeksowana/scache’owana, nawet po usunięciu.

Pamięć (cross-session)

Plikowa pamięć agenta (memory/) trzyma to, czego nie da się wyczytać z kodu/gita:

kim jest user (rola, preferencje), feedback (jak mam pracować — z „dlaczego”), stan projektu niewynikalny z repo, wskaźniki do zasobów (URL-e, dashboardy, issue).
Nie zapisuj tego, co repo już wie (struktura kodu, historia gita, CLAUDE.md). Jeśli prosisz „zapamiętaj X” o rzeczy z repo — zapisz to, co było nieoczywiste, nie sam fakt.
Daty względne → bezwzględne („w przyszłym tygodniu” → konkretna data).
Zanim zapiszesz — sprawdź, czy nie ma już pliku o tym; aktualizuj, nie duplikuj; kasuj to, co okazało się błędne.
Recall to tło, nie rozkaz — pamięć opisuje stan z momentu zapisu; jeśli wskazuje plik/flagę, zweryfikuj, że wciąż istnieje, zanim rekomendujesz.

Raportowanie (Przykazanie III, jeszcze raz, bo najważniejsze)

Stan faktyczny > dobre wrażenie. „Testy padły — oto output.” „Krok pominięto.” „Gotowe i zweryfikowane” — bez hedgingu, gdy naprawdę zweryfikowane.

Domknij jednostkę pracy podsumowaniem

Gdy zmiana wchodzi, nie chowaj jej w prozie — pokaż czytelne podsumowanie zmian, najlepiej jako widget dopasowany do użytkownika (jego poziom techniczny → 07), żeby ogarnął status na pierwszy rzut oka i wybrał następny krok:

Co się zmieniło — jedna linia; dotknięte pliki/obszary.
Weryfikacja — dowód, nie „działa”: wyniki testów (ile pass/fail), smoke, kody HTTP, liczby (Przykazanie III).
Commit — krótki hash, data, jednolinijkowy opis (Przykazanie VIII).
Następne działania, po kolei — oczywiste kroki jako krótka seria do zatwierdzenia: update docs / AI_README, update docs/plans, potem deploy — z twardą bramką (nigdy bez jawnego „wdrażaj”, zob. Potwierdzaj nieodwracalne wyżej).

Dobierz głębię do odbiorcy: techniczny → hashe, liczby testów, ścieżki plików; nietechniczny → proste „co się zmieniło + co dalej”. Widgety i inne powierzchnie Claude Code do tego → 16.

Anty-wzorce

🚫 Skalowanie przed review.
🚫 Survey opcji zamiast rekomendacji.
🚫 Nadpisanie/kasowanie bez spojrzenia na cel.
🚫 Pamięć jako wysypisko faktów z repo.
🚫 Traktowanie jednorazowej zgody jako stałej.
🚫 Kończenie zmiany ścianą prozy zamiast skanowalnym podsumowaniem (status + commit + następne kroki).