Rozwiązywanie problemów i najlepsze praktyki: Wskazówki 96-100

Claude Code właśnie przepisał 20-liniowy serwis na fabrykę, rejestr i trzy interfejsy — a ty zaakceptowałeś to, zanim przeczytałeś. Albo jest w połowie błędnej ścieżki, a ty naciskasz Ctrl+C, co zabija całą sesję zamiast zadania. Różnica między frustrującą a szybką sesją to nie model; to posiadanie rutyny ratunkowej: commituj, zanim oddelegujesz, przerywaj czysto i cofaj bez ceregieli.

Co z tego wyniesiesz

Prawdziwą politykę permissions allow/ask/deny, którą możesz wkleić do .claude/settings.json
Nawyk „commituj, zanim oddelegujesz”, który zamienia zły wynik w jednolinijkowe cofnięcie
Właściwy sposób przerywania (Escape, nie Ctrl+C) i kiedy używać którego
Prompty do wklejenia, które odchudzą przeinżynierowane rozwiązanie i pozwolą ci samemu przejrzeć diff
Listę kontrolną ratunkową „Gdy to się zepsuje” na tryby awarii, w które faktycznie wpadniesz

Zarządzanie bezpieczeństwem i uprawnieniami

Wskazówka 96: Zarządzaj uprawnieniami strategicznie

Równoważ bezpieczeństwo z produktywnością poprzez przemyślane zarządzanie uprawnieniami:

Uprawnienia Claude Code żyją w obiekcie permissions w .claude/settings.json, z tablicami allow, ask i deny. Wpisy to reguły narzędzi (Read, Bash(git diff *)), a nie gołe słowa poleceń, a specyfikatory Bash używają globów ze spacjami — nigdy dwukropków.

{
  "permissions": {
    "allow": [
      "Read",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(ls *)",
      "Bash(grep *)"
    ],
    "ask": [
      "Edit",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Read(./.env)"
    ]
  }
}

# --dangerously-skip-permissions usuwa WSZYSTKIE monity o zatwierdzenie.
# Używaj jej wyłącznie w jednorazowym/sandboxowym środowisku (świeży kontener,
# tymczasowy klon) — nigdy na współdzielonej maszynie deweloperskiej ani blisko produkcji.
claude --dangerously-skip-permissions

# Do codziennej pracy preferuj wyselekcjonowaną politykę allow/ask/deny (lewa zakładka)
# plus "defaultMode": "acceptEdits", aby ograniczyć monity bez otwierania wszystkiego na oścież.

# Polityka uprawnień

## Auto-wykonanie (bezpieczne)
- Operacje odczytu (ls, cat, git status)
- Zapytania niedestrukcyjne
- Wykonanie testów

## Wymagane ręczne zatwierdzenie
- Usuwanie plików
- Modyfikacje bazy danych
- Instalacje pakietów
- Operacje Git wpływające na remote

## Nigdy nie zezwalaj
- Force push na main/master
- Rekurencyjne usuwania bez konkretnych ścieżek
- Bezpośredni dostęp do produkcyjnej bazy danych
- Modyfikacje poświadczeń

Najlepsze praktyki bezpieczeństwa

Nigdy auto-zezwalaj na komendy destrukcyjne
Bądź ostrożny z komendami obejmującymi pliki wrażliwe
Przeglądaj komendy uzyskujące dostęp do zmiennych środowiskowych
Używaj serwerów MCP do wrażliwych operacji
Utrzymuj różne polityki dla różnych środowisk

Konkretny powód, by trzymać git add w ask, a nie w allow: zbiorcze git add . może wciągnąć pliki .env z sekretami, node_modules, artefakty budowy albo lokalne notatki. Preferuj konkretne ścieżki (git add src/) lub interaktywne staging (git add -p), a regule ask pozwól wymuszać świadome potwierdzenie za każdym razem.

Częste problemy i rozwiązania

Wskazówka 97: Częściej cofaj niż zwykle

Praca z AI wymaga innego podejścia do kontroli wersji. Tradycyjny nawyk to: wprowadź zmiany, debuguj ekstensywnie, commituj gdy idealne. Z Claude Code odwróć to — najpierw commituj aktualny stan, pozwól Claude spróbować zmiany, a jeśli wynik jest gorszy niż to, co miałeś, cofnij i poproś ponownie, zamiast debugować wynik AI linia po linii.

Mechaniczna pętla wygląda w terminalu tak:

git add . && git commit -m "Checkpoint before Claude refactoring"
# W REPL: "Refactor this module to use dependency injection"
# Jeśli wynik jest nadmiernie złożony:
git reset --hard HEAD
# W REPL: /clear, następnie poproś ponownie z ciaśniejszymi ograniczeniami

Cofanie jest zwykle szybsze niż debugowanie błędu AI, daje czystszą ostateczną implementację i chroni cię przed zakotwiczeniem na złej pierwszej próbie. Traktuj commity jak punkty kontrolne w grze wideo: zapisuj często, aby ponowienie innej strategii kosztowało cię jedną linię, a nie całe popołudnie.

Wskazówka 98: Ostrożnie obsługuj złożone rozwiązania

Claude czasami nadmiernie komplikuje rozwiązania. Wypatruj tych wzorców:

Oznaki nadmiernej inżynierii
Strategia upraszczania

// Nadmiernie złożone rozwiązanie Claude'a
class UserServiceFactory {
  private static instance: UserServiceFactory;
  private serviceCache: Map<string, IUserService>;

  static getInstance(): UserServiceFactory {
    if (!this.instance) {
      this.instance = new UserServiceFactory();
    }
    return this.instance;
  }

  createService(type: string): IUserService {
    // 50 więcej linii logiki factory
  }
}

// To czego faktycznie potrzebowałeś
class UserService {
  constructor(private db: Database) {}

  async getUser(id: string) {
    return this.db.users.findOne(id);
  }
}

Gdy Claude nadmiernie komplikuje, masz dwa ruchy: poproś go o zwinięcie abstrakcji na miejscu albo cofnij i poproś ponownie z ciaśniejszą specyfikacją.

git reset --hard HEAD   # wyrzuć przebudowaną wersję
# W REPL: /clear, następnie poproś ponownie z ograniczoną wersją poniżej

Prompt do wklejenia, który odchudzi rozwiązanie właśnie wyprodukowane przez Claude:

This is over-engineered for what we need. Collapse it to a single UserService
class that takes its Database in the constructor and exposes only the methods we
actually call. Remove the factory, the singleton, the registry, and any interface
with one implementer. Keep behavior and tests passing. Show me the diff and a
one-line note on anything you removed that we might miss later.

Częste wzorce nadmiernej inżynierii, na które warto uważać: niepotrzebne warstwy abstrakcji, przedwczesna optymalizacja, nadmierna generalizacja, głębokie hierarchie dziedziczenia oraz wzorce projektowe stosowane tam, gdzie wystarczyłaby funkcja.

Jak zapobiegać:

# Dodaj do CLAUDE.md
## Zasady prostoty
- PREFERUJ proste rozwiązania nad złożonymi
- UNIKAJ przedwczesnej abstrakcji
- UŻYWAJ wzorców projektowych tylko gdy wyraźnie korzystne
- ROZPOCZYNAJ od najprostszego działającego rozwiązania
- REFAKTORYZUJ aby dodać złożoność tylko gdy potrzeba

Wskazówka 99: Używaj klawisza Escape do właściwego przerwania

Opanuj sztukę skutecznego zatrzymywania Claude. Kluczowe rozróżnienie:

Źle: Ctrl+C — to wychodzi z Claude Code całkowicie i tracisz sesję.
Dobrze: Escape — to zatrzymuje bieżącą operację, ale utrzymuje rozmowę, więc możesz natychmiast dodać kontekst i kontynuować.

Sięgaj po Escape w chwili, gdy zauważysz którekolwiek z poniższych:

Claude zmierza w złym kierunku
Zdajesz sobie sprawę, że musisz dostarczyć więcej kontekstu
Chcesz dodać dodatkową instrukcję
Operacja trwa dłużej, niż uzasadnia to zadanie
Wychwytujesz błąd we własnym żądaniu

Odzyskanie sterowania to po prostu Escape, a potem pisz dalej. Na przykład: Claude zaczyna implementować, naciskasz Escape i wpisujesz Wait, I forgot to mention we need to maintain backward compatibility with the v1 API — Claude podchwytuje nowe ograniczenie bez restartu.

Warianty warte zapamiętania: wczesny Escape (zatrzymaj, gdy tylko podejście wygląda źle), pozwól skończyć (czasami szybciej zobaczyć, gdzie wyląduje), Escape + /clear dla pełnej zmiany kierunku oraz Escape + doprecyzowanie, aby dodać ograniczenia w trakcie wykonania.

Wskazówka 100: Przyjmij krzywą uczenia się

Skuteczna praca z Claude Code to umiejętność, a przystosowanie jest realne. Większość programistów przechodzi przez rozpoznawalny łuk:

Tydzień 1-2: Okres przystosowania
- Czuje się niezręcznie i wolno
- Tendencja do nadmiernej weryfikacji wszystkiego
- Niepewność, co bezpiecznie oddelegować
Tydzień 3-4: Znajdowanie rytmu
- Rozwijasz zaufanie w pewnych obszarach
- Uczysz się mocnych stron i trybów awarii Claude
- Zaczynasz grupować powiązane zadania
Miesiąc 2 i dalej: Płynność
- Rozwija się naturalny rytm oddeleguj-zweryfikuj-cofnij
- Wcześniej żmudne zadania stają się rutynowe
- Mierzysz własne użycie za pomocą /cost zamiast zgadywać „X razy szybciej”

Zamiast gonić za mnożnikiem produktywności, śledź coś, co możesz zweryfikować: jak często akceptujesz pierwszą próbę Claude bez edycji i jak często cofasz. Oba wskaźniki poprawiają się, gdy twoje prompty się zacieśniają.

Podsumowanie najlepszych praktyk

Przepływ pracy rozwoju

## Najlepsze praktyki dziennego przepływu pracy

### Poranna rutyna
1. Wyczyść poprzedni kontekst: `/clear`
2. Przejrzyj wczorajszą pracę
3. Zaplanuj dzisiejsze zadania
4. Kolejkuj poranną pracę
5. Przeglądaj i commituj ukończone zadania

### Podczas rozwoju
- Commituj przed każdym zadaniem Claude
- Czyść między niepowiązaną pracą
- Używaj konkretnych, szczegółowych żądań
- Weryfikuj wynik przed kontynuacją
- Aktualizuj CLAUDE.md z naukami

### Koniec dnia
- Przeglądaj wszystkie zmiany
- Aktualizuj dokumentację
- Sprawdź `/cost` do optymalizacji
- Planuj jutrzejszą pracę
- Commituj i pushuj

Zapewnienie jakości

Dwa prompty pokrywają większość twojego codziennego QA: samo-przegląd tego, co właśnie zmieniłeś, oraz przejście pisania testów wykraczające poza ścieżkę szczęśliwą.

Prompt do wklejenia dla samo-przeglądu na koniec sesji (uruchom po dodaniu zmian do staging):

Review the staged diff (git diff --staged) for logic errors, security issues
(injection, authz gaps, leaked secrets), performance problems on hot paths, and
behavior that ships without a test. For each finding give file:line, the risk in
one sentence, and the fix. Ignore style — linting owns that. End with the single
highest-priority item to fix before merge.

Prompt do wklejenia dla testów, które faktycznie sprawdzają przypadki brzegowe:

Write tests for the code we just changed. Cover the happy path, the error cases
(bad input, downstream failure, timeout), and the boundary conditions (empty,
null, max size, off-by-one). Match the existing test framework and file layout in
this repo. Do not test private internals — test observable behavior. Show the new
test files and tell me which branch is still uncovered.

Wzorce długoterminowego sukcesu

Zrównoważone praktyki

Ciągłe uczenie się
- Regularne retrospektywy
- Dzielenie się odkryciami z zespołem
- Aktualizacja przepływów pracy na podstawie doświadczenia
Zarządzanie kosztami
- Codzienne przeglądy użycia
- Optymalizacja wyboru modelu
- Dyscyplina zarządzania kontekstem
Skupienie na jakości
- Nigdy nie kompromisuj weryfikacji
- Utrzymuj wysokie standardy testowe
- Regularne audyty bezpieczeństwa
Zgodność zespołu
- Wspólne standardy i praktyki
- Regularne dzielenie się wiedzą
- Skoordynowane ulepszenia

Gdy to się zepsuje

Gdy sesja zbacza z kursu, potrzebujesz rutyny ratunkowej, a nie spirali debugowania. Przejdź przez te kroki po kolei.

Claude poszedł złą ścieżką i wciąż działa. Naciśnij Escape (nie Ctrl+C, które zabija sesję). Dodaj brakujące ograniczenie prostym językiem i pozwól mu kontynuować od tego miejsca.
Wynik jest gorszy niż to, co miałeś. Nie debuguj wyniku AI. Uruchom git reset --hard HEAD, aby wrócić do swojego punktu kontrolnego, następnie /clear i poproś ponownie z ciaśniejszą specyfikacją. Właśnie dlatego commitujesz przed oddelegowaniem.
Claude przeinżynierował rozwiązanie. Użyj promptu odchudzającego ze Wskazówki 98, aby zwinąć abstrakcję na miejscu, albo zresetuj i poproś ponownie o „najprostszą rzecz, która przechodzi testy”.
Kontekst jest zanieczyszczony, a odpowiedzi dryfują. Uruchom /clear, aby porzucić historię rozmowy przed rozpoczęciem niepowiązanej pracy. Nieświeży kontekst jest najczęstszą przyczyną odpowiedzi mijających się z celem.
Koszty rosną szybciej niż oczekiwano. Sprawdź /cost w REPL, następnie kieruj rutynową pracę do Sonnet 4.6, a Opus 4.8 rezerwuj na naprawdę trudne zadania. Długie, nieprzerwane sesje są zwykle winowajcą — /clear między zadaniami również przycina zużycie tokenów.
Reguła uprawnień nie zaczyna obowiązywać. Pamiętaj, że reguły są oceniane deny, potem ask, potem allow, a specyfikatory Bash to globy ze spacjami (Bash(npm run *)), nie dwukropki. Gołe słowo polecenia w starym kształcie autoAllow/blocked jest bezskuteczne — przejdź na obiekt permissions ze Wskazówki 96.

Co dalej

Dotarłeś do końca 100 wskazówek. Myśl przewodnia: szybkość bez weryfikacji jest bezwartościowa, a ciasna pętla oddeleguj-zweryfikuj-cofnij bije zaufanie do jakiegokolwiek pojedynczego wyniku. Aby pójść głębiej:

Wróć do Współpracy zespołowej, aby zamienić te nawyki we współdzielone, wersjonowane domyślne ustawienia zespołu.
Utrzymuj swoją politykę uprawnień w ryzach dzięki oficjalnej dokumentacji ustawień.