Claude Code Poradnik 4: Jakie są przypadki użycia Claude Code?

Typowe przypadki użycia

Podzieliłem przypadki użycia na cztery kategorie, od najczęstszych do najrzadszych.

Pierwsza kategoria: Zrozumienie kodu

To chyba najczęściej używana. Gdy przejmujesz cudzy projekt, przeglądasz stary moduł lub otwierasz repozytorium bez dokumentacji, po prostu go pytasz.

Konkretne działania:

claude "Do czego służy ten projekt? Gdzie jest punkt wejścia?" – przeanalizuje package.json, strukturę katalogów, kluczowe pliki i poda podsumowanie.
Otwórz funkcję i poproś o wyjaśnienie logiki lub opisanie przepływu (tekstem).
Poproś o prześledzenie pełnej ścieżki żądania API od frontendu do bazy danych.

Tutaj robi to, co można nazwać „brudną robotą czytania kodu”. Nie musisz sam przeszukiwać grepem ani składać puzzli w głowie. On porządkuje ścieżki, Ty podejmujesz decyzje.

Alternatywą dla tego typu zadań jest: ręczne przeszukiwanie kodu, robienie notatek, rysowanie diagramów wywołań.

Druga kategoria: Pisanie i modyfikowanie kodu

To najczęściej omawiana kategoria, ale wcale nie najczęściej używana. Scenariusze pisania kodu zazwyczaj wyglądają tak:

Tworzenie nowej funkcji: „Dodaj interfejs do zmiany e-maila w module user z walidacją formatu e-mail i testami jednostkowymi.”
Refaktoryzacja w wielu plikach: „Zamień wszystkie moment() w tych trzech plikach na dayjs(), nie zmieniając innej logiki.”
Migracja i aktualizacja: „Przepisz ten komponent z Vue 2 na składnię Vue 3 Composition API.”

Wygenerowany kod nie zawsze jest od razu poprawny, ale potrafi od razu wprowadzić zmiany w wielu plikach, a Ty możesz przeglądać diff plik po pliku i akceptować lub odrzucać zmiany.

Alternatywą dla tego typu zadań jest: ręczne pisanie powtarzalnego kodu, ręczne wyszukiwanie i zastępowanie odwołań między plikami.

Trzecia kategoria: Debugowanie i naprawa

Gdy pojawia się błąd, typowy przepływ pracy to: zobacz komunikat błędu, znajdź plik, zgadnij przyczynę, spróbuj poprawić, jeśli nie działa – wróć i sprawdź. Claude Code może bezpośrednio przyjąć cały stack trace i zlokalizować problem w kontekście kodu projektu.

Typowe użycie:

Wrzuć mu nieudane wyjście testu, on przeczyta odpowiedni kod, zaproponuje poprawkę, uruchomi test ponownie i sprawdzi, czy przechodzi.
Gdy CI zgłasza błąd, wklej log, niech go naprawi, a potem uruchom git diff, aby potwierdzić zmiany.

Tutaj działa bardziej jako „pierwszy inspektor”. To Ty poświęcasz czas na myślenie, ale to on przegląda pliki, porównuje różnice i uruchamia polecenia weryfikacyjne.

Alternatywą dla tego typu zadań jest: wielokrotne uruchamianie testów, czytanie logów błędów, ręczne porównywanie różnic w kodzie.

Czwarta kategoria: Różne automatyzacje

Ta kategoria najmniej rzuca się w oczy, ale suma oszczędności czasu jest największa.

Przykłady:

Pisanie wiadomości commit: claude "Na podstawie bieżącego git diff napisz wiadomość commit w formacie Conventional Commits"
Generowanie opisu PR: Niech porówna bieżącą gałąź z main i wygeneruje podsumowanie zmian oraz opis testów.
Pisanie notatek wydania: Poproś Claude Code o odczytanie commitów z ostatniego tygodnia i wygenerowanie CHANGELOG.
Rozwiązywanie problemów środowiskowych: „Instalacja tej zależności się nie udaje, spójrz na wyjście terminala i znajdź przyczynę.”

Wspólną cechą tych zadań jest to, że nie są skomplikowane, ale są nużące. Robienie ich samodzielnie wymaga przełączania okien i dużo pisania. Powierzając je jemu, załatwiasz sprawę w kilka sekund.

Alternatywą dla tego typu zadań jest: ręczne edytowanie tekstu, pisanie sformatowanych dokumentów, szukanie konfiguracji środowiska.

„Mapa”

Umieszczając te cztery kategorie w codziennym przepływie pracy, otrzymujemy mniej więcej taką mapę:

Otrzymujesz nieznany projekt
    │
    ▼
[Zrozumienie kodu] ─── Zorientowanie się w strukturze, punkcie wejścia, kluczowej logice
    │
    ▼
Rozpoczynasz pisanie nowej funkcji lub modyfikację modułu
    │
    ▼
[Pisanie/modyfikowanie kodu] ─── Generowanie implementacji, refaktoryzacja między plikami
    │
    ▼
Uruchamiasz testy, pojawia się błąd
    │
    ▼
[Debugowanie i naprawa] ─── Analiza błędu, lokalizacja, naprawa, ponowne uruchomienie
    │
    ▼
Przygotowanie do wysłania
    │
    ▼
[Różne automatyzacje] ─── Pisanie commita, opisu PR, notatek wydania
    │
    ▼
Wysyłasz, gotowe

Nie musisz używać go we wszystkich czterech obszarach. Niektóre zespoły używają go tylko do zrozumienia kodu, inne tylko do pisania testów i wysyłania PR. Zacznij od obszaru, który sprawia Ci najwięcej trudności.

Dwa przydatne kryteria oceny

Jeśli nie jesteś pewien, czy dane zadanie warto powierzyć Claude Code, zadaj sobie dwa pytania:

1. Czy to zadanie jest bardziej „mechaniczne” niż „twórcze”?

Zmiana setek odwołań, formatowanie wyjścia, generowanie kodu szablonowego – robienie tego samemu sumarycznie zajmuje dużo czasu, ale masz już pomysł. Nadaje się dla niego.

2. Czy „koszt weryfikacji” jest wysoki?

Jeśli zmiana wymaga wielokrotnego przełączania się, uruchamiania testów i przeglądania logów, aby potwierdzić, to ręczne próbowanie jest powolne. Claude Code może sam wykonać cykl „zmień – uruchom – sprawdź – zmień”, co znacznie ułatwi Ci pracę.