Otwierasz Claude Code pierwszy raz i widzisz... pustą linię, w którą można coś wpisać. Żadnych przycisków, żadnego kreatora, żadnej podpowiedzi „kliknij tutaj”. I to właśnie zniechęca najwięcej osób — bo skoro narzędzie potrafi wszystko, to od czego w ogóle zacząć?
Pokażę ci, jak ja do tego podchodzę: od najprostszego ruchu, który nic nie psuje, aż po nawyki, którymi posługują się ludzie wyciskający z tego narzędzia naprawdę dużo. Po kolei: pytania o projekt, edycja kodu, planowanie, pętla sprzężenia zwrotnego, kontekst i na końcu praca w kilku sesjach naraz.
Najpierw zrozum, czym to jest
Claude Code to asystent zupełnie innego rodzaju niż te, które mogłeś znać. Wcześniejsze pomocniki do programowania podpowiadały kolejną linijkę albo dwie — jak autouzupełnianie w wyszukiwarce. To nie o to tu chodzi. Claude Code jest agentowy, czyli działa samodzielnie: dostaje cel i sam dobiera kroki, żeby go osiągnąć. Potrafi napisać całą funkcję, cały plik, naprawić cały błąd — nie pojedynczą linijkę.
Druga ważna rzecz: mieszka w terminalu. Terminal to to czarne okno, w którym wpisuje się polecenia tekstem, zamiast klikać. Brzmi staromodnie, ale to akurat jego siła — działa wszędzie. Cokolwiek masz na ekranie jako edytor kodu (programiści nazywają go IDE — środowisko, w którym pisze się i uruchamia program), Claude Code współpracuje z tym bez zmiany twoich nawyków. Nie musisz przesiadać się na nowe narzędzie ani przebudowywać sposobu pracy. Po prostu dokładasz go do tego, co już masz.
I właśnie dlatego wita cię pusta linia. To nie jest niedopracowanie — to celowy wybór. Narzędzie jest na tyle uniwersalne, że nie chce cię wpychać w jeden gotowy sposób pracy. Daje ci wolną rękę. Tyle że z wolną ręką trzeba umieć coś zrobić — i o tym jest reszta tego tekstu.
Zacznij tu: zadawaj pytania o swój projekt
To moja jedyna rada, którą stawiam ponad wszystkimi innymi: zanim cokolwiek zmienisz, najpierw zadawaj pytania. Nie edytuj kodu, nie sięgaj po zaawansowane sztuczki. Po prostu pytaj o swój własny projekt.
To częsty błąd, który widzę — ludzie od razu rzucają narzędziu wielkie zadanie i są rozczarowani. A najlepsza droga do wprawy wiedzie przez rozmowę. Pytasz: „jak ten fragment kodu jest używany?”, „dlaczego to działa akurat tak?”, „co właściwie wdrożyłem w tym tygodniu?”. Claude Code nie odpowiada zwykłym wyszukaniem słowa po tekście. Schodzi głębiej — szuka prawdziwych przykładów użycia, składa je w całość i daje ci odpowiedź na poziomie dobrej dokumentacji, a nie listy trafień.
Świetnym pytaniem jest też historia projektu. Programiści przechowują kod w repozytorium Git — to coś jak dziennik, który zapamiętuje każdą zmianę: kto, kiedy i co zmienił. Możesz po prostu powiedzieć „przejrzyj historię i wytłumacz mi, skąd się wzięła ta dziwna funkcja” — a narzędzie samo przekopie się przez ten dziennik, znajdzie moment, w którym coś dodano, i streści ci całą historię. Nie musisz mu tłumaczyć, jak to zrobić. Wie, bo model, na którym działa, jest naprawdę dobry — nikt nie kazał mu „grzebać w historii Gita”, on po prostu to potrafi.
Dwie rzeczy, które warto tu podkreślić, bo uspokajają. Po pierwsze: nic się nigdzie nie wysyła. Kod nie ląduje na żadnym serwerze, zostaje u ciebie na komputerze. Po drugie: nie ma żadnej konfiguracji ani indeksowania — nie czekasz, aż narzędzie „przetrawi” projekt. Pobierasz, uruchamiasz, pytasz. I właśnie te pytania uczą cię granicy: co narzędzie zrobi od ręki, a co wymaga, żebyś poprowadził je za rękę.
Edycja: opisujesz cel, nie kroki
Kiedy poczujesz się pewnie z pytaniami, możesz przejść do zmieniania kodu. I tu działa ta sama logika.
Claude Code ma do dyspozycji bardzo mały zestaw narzędzi: potrafi edytować pliki, uruchamiać polecenia (bash to po prostu język, w którym wydaje się komputerowi komendy w terminalu) i przeszukiwać projekt. To wszystko. Magia polega na tym, że sam łączy te narzędzia w odpowiedniej kolejności. Ty mówisz, co ma powstać — a on decyduje, że najpierw przeszuka, potem przeczyta, potem zmieni. Nie wskazujesz mu „użyj teraz tego, a potem tamtego”. Opisujesz cel, nie kroki.
Planowanie: najwyżej opłacalny nawyk
Jeśli mam wskazać jeden nawyk, który daje najwięcej przy najmniejszym wysiłku — to ten: przy każdym nietrywialnym zadaniu poproś o plan, zanim narzędzie zacznie pisać.
Widuję, jak ktoś rzuca polecenie „zbuduj mi tę ogromną funkcję na trzy tysiące linii” i czasem to nawet wychodzi za pierwszym razem. Ale czasem powstaje coś zupełnie innego, niż się chciało — i wtedy zaczyna się frustracja. Najprostsze rozwiązanie: każ mu najpierw pomyśleć. Wystarczy napisać coś w stylu „przemyśl pomysły, ułóż plan, pokaż mi go i poczekaj na moją zgodę, zanim napiszesz kod”.
Nie potrzebujesz do tego żadnego specjalnego trybu ani ustawień. Po prostu o to prosisz — i narzędzie wie, co zrobić. Pięć minut na zatwierdzenie planu oszczędza godzinę poprawiania czegoś, co poszło nie tam.
Wielka idea: daj mu sposób, by sam sprawdził swoją pracę
To jest, moim zdaniem, najważniejsza rzecz w całym tym tekście. Jeśli zapamiętasz tylko jedno zdanie, niech to będzie to: kiedy narzędzie ma jak sprawdzić własną robotę, samo doprowadza ją do znacznie lepszego stanu.
Wyobraź sobie, że dajesz mu szkic interfejsu strony i mówisz „zbuduj to”. Za pierwszym razem wyjdzie nieźle. Ale jeśli dasz mu sposób, żeby zobaczył efekt — na przykład zrzut ekranu gotowej strony albo zestaw automatycznych sprawdzeń (programiści nazywają je testami — to małe kontrole, które mówią, czy coś działa zgodnie z założeniem) — wtedy narzędzie porówna wynik z celem, samo poprawi, sprawdzi jeszcze raz i po dwóch–trzech podejściach trafi niemal idealnie.
To jest pętla sprzężenia zwrotnego. Sztuczka jest zawsze ta sama, niezależnie od dziedziny: daj mu jakikolwiek sposób, żeby zobaczył efekt swojej pracy, a sam się dostroi. Zrzut ekranu, test, podgląd — cokolwiek pozwala mu samodzielnie ocenić, czy zrobił dobrze.
Daj mu kontekst, a stanie się mądrzejszy
Im więcej narzędzie wie o twoim projekcie, tym lepsze decyzje podejmuje. Ty masz w głowie mnóstwo kontekstu — historię, ustalenia, wiedzę „dlaczego tu robimy tak, a nie inaczej”. Tego nie zgadnie. Trzeba mu to podać — i jest na to kilka sposobów, od najprostszego.
Plik CLAUDE.md. To krótki plik z notatkami, który narzędzie czyta automatycznie na początku każdej rozmowy. Wpisujesz w niego to, co chciałbyś przekazać komuś nowemu w projekcie: najczęstsze polecenia, kilka kluczowych plików, ważne ustalenia. Jedna zasada: trzymaj go krótko. Jeśli rozrośnie się za bardzo, zacznie zajmować miejsce i przestanie pomagać. Plik możesz współdzielić z zespołem — wtedy piszesz go raz, a korzystają wszyscy — albo trzymać prywatną, lokalną wersję tylko dla siebie.
Zapisane polecenia (komendy ukośnikowe). Jeśli jakąś czynność powtarzasz co tydzień, możesz zapisać ją jako gotową komendę — nazywa się je ukośnikowymi, bo wywołuje się je znakiem ukośnika /. Zapisujesz raz, używasz jednym poleceniem. Też da się je współdzielić z zespołem.
Podłączenie narzędzi, których już używacie. Jeśli twój zespół ma własne programy obsługiwane z terminala albo system o nazwie MCP (to wspólny standard, dzięki któremu Claude Code potrafi rozmawiać z zewnętrznymi narzędziami — twoim systemem zgłoszeń, bazą, czymkolwiek), wystarczy mu o nich powiedzieć i pokazać, jak ich użyć. Od tej chwili będzie z nich korzystał w twoim imieniu. Załóżmy, że masz w firmie własny program uruchamiany komendą w terminalu — mówisz narzędziu „użyj go, sprawdź sam jego instrukcję” i ono daje radę. To bardzo wygodne, gdy wchodzisz w nowy projekt: dajesz mu od razu cały zestaw narzędzi zespołu.
Ustawienia na poziomie firmy. Na większą skalę można rozłożyć kontekst i reguły warstwami: osobno dla projektu (zapisane w repozytorium i współdzielone), osobno globalnie dla wszystkich twoich projektów, a osobno na poziomie całej firmy. Ta najwyższa warstwa to silne narzędzie do bezpieczeństwa: bezpieczne polecenia można z góry zatwierdzić, żeby nikt nie musiał ich za każdym razem klikać, a niebezpieczne — zablokować tak, że nikt ich nie obejdzie.
Jeśli nie wiesz, od czego zacząć w tym całym gąszczu możliwości, zacznij od współdzielonego kontekstu projektu. Piszesz raz, dzielisz się z całym zespołem — i pojawia się efekt sieci: jedna osoba wykonuje trochę pracy, a korzystają wszyscy.
Kilka przydatnych ruchów i praca równoległa
Na koniec garść drobiazgów, które ułatwiają codzienne używanie:
- Tryb automatycznej akceptacji zmian — gdy widzisz, że narzędzie jest na dobrej drodze (na przykład poprawia testy w kółko), możesz przestać zatwierdzać każdą zmianę osobno. Polecenia w terminalu nadal wymagają twojej zgody, a wszystko zawsze da się cofnąć.
- Znak
#, żeby coś zapamiętać — jeśli narzędzie czegoś nie robi tak, jak chcesz, wpisujesz#i mówisz, o co chodzi. Zapamięta to na przyszłość, dopisując sobie do notatek. - Escape, żeby bezpiecznie przerwać — w dowolnym momencie możesz nacisnąć Escape i zatrzymać to, co narzędzie robi. Nic się nie zepsuje, sesja nie ucierpi. Przerywasz, mówisz, co zmienić, i ruszacie dalej.
- Wznowienie sesji — kiedy skończysz, możesz później wrócić do tej samej rozmowy i kontynuować, zamiast zaczynać od zera.
A jeśli chodzi o naprawdę zaawansowane użycie — osoby, które wyciskają z tego najwięcej, prowadzą kilka sesji naraz. Mają wiele osobnych kopii tego samego projektu albo używają tak zwanych „roboczych odgałęzień” Gita (sposób na trzymanie kilku równoległych wersji obok siebie), żeby każda sesja pracowała w izolacji. To pozwala robić wiele rzeczy w tym samym czasie. Sam zwykle prowadzę jedną — to nie jest punkt obowiązkowy, raczej kierunek, w którym możesz pójść, gdy poczujesz się swobodnie.
Warto też wiedzieć, że Claude Code da się prowadzić nie tylko ręcznie, ale i ze skryptów — jak inteligentne narzędzie wiersza poleceń, które dostaje zadanie i zwraca wynik. Podajesz mu polecenie, on oddaje gotowy rezultat, a ty wpinasz to w większy automatyczny przepływ. Nie musisz tego ruszać na start — ale dobrze wiedzieć, że ta droga istnieje.
Co z tego zapamiętać
Cała ta progresja sprowadza się do jednej zasady: nie szukaj sekretnych zaklęć — daj narzędziu kontekst i sposób, żeby samo sprawdziło swoją pracę. Reszta to model robiący to, w czym jest dobry.
Najmniejszy ruch na dziś: otwórz swój projekt i zadaj jedno pytanie o coś, czego nigdy do końca nie rozumiałeś. To wystarczy, żeby zacząć.