Claude Code to narzędzie firmy Anthropi, które pozawala zamiast kopiować fragmenty kodu między edytorem a oknem czatu, dać agentowi dostęp do całego repozytorium — może czytać pliki, uruchamiać komendy, edytować kod i tworzyć commity. W tym wpisie zbieram najważniejsze rzeczy, które warto wiedzieć, żeby zacząć pracować z Claude Code w sposób przemyślany.

Wpis powstał na podstawie materiału wideo: Claude Code best practices.

Rozmowa o własnym kodzie Link to heading

Najprostszy scenariusz to zadawanie pytań o kod. Po uruchomieniu claude w katalogu projektu można po prostu zapytać, jak działa dany moduł, gdzie znajduje się obsługa konkretnego przypadku albo dlaczego test kończy się błędem. Agent sam przeszuka repozytorium, otworzy odpowiednie pliki i odpowie z odwołaniem do konkretnych lokalizacji w kodzie.

To zmienia sposób wdrażania się w nowy projekt — zamiast godzinami czytać kod, można poprosić Claude Code o oprowadzenie po architekturze i dopiero potem zagłębiać się w szczegóły.

Sterowanie narzędziami Link to heading

Domyślnie Claude Code pyta o zgodę przed wykonaniem akcji, która coś zmienia (edycja pliku, uruchomienie komendy). To dobry punkt wyjścia, ale w praktyce szybko chcemy dostosować ten model uprawnień do swojego stylu pracy. Służą do tego komendy:

  • /permissions — zarządzanie regułami uprawnień (co agent może robić bez pytania, a co wymaga zgody),
  • /allowed-tools — wskazanie, z których narzędzi Claude Code może korzystać,
  • /config — ogólna konfiguracja narzędzia,
  • /theme — zmiana motywu kolorystycznego,
  • /terminal-setup — konfiguracja skrótów klawiszowych w terminalu (np. obsługa Shift+Enter),
  • /install-github-app — instalacja aplikacji GitHub, dzięki której Claude Code może reagować na pull requesty i issues.

Dobrze dobrane uprawnienia to klucz do komfortowej pracy — zbyt restrykcyjne ustawienia powodują, że co chwilę klikamy „yes", a zbyt liberalne odbierają kontrolę nad tym, co się dzieje.

Podłączenie narzędzi zespołu Link to heading

Claude Code nie jest zamkniętym pudełkiem. Przez Model Context Protocol (MCP) można podłączyć narzędzia, z których korzysta zespół — bazy danych, systemy ticketowe, dokumentację czy wewnętrzne API. Dzięki temu agent dostaje kontekst wykraczający poza samo repozytorium.

Typowe przepływy pracy Link to heading

Z czasem wykształcają się powtarzalne schematy współpracy z agentem. Trzy, które sprawdzają się najlepiej:

  1. Eksploracja → plan → potwierdzenie → kod → commit — najpierw pozwalamy Claude Code zrozumieć problem i zaproponować plan, akceptujemy go, dopiero potem agent pisze kod. Dobre przy większych, niejasnych zadaniach.
  2. Testy → commit → kod → iteracja → commit — podejście w duchu TDD: najpierw powstają testy, potem implementacja, którą agent doszlifowuje aż testy przejdą. Świetne, gdy znamy oczekiwany rezultat.
  3. Kod → zrzut ekranu → iteracja — przy pracy nad interfejsem warto pokazać agentowi zrzut ekranu rezultatu, żeby mógł porównać go z oczekiwanym wynikiem i poprawić.

Wspólny mianownik tych przepływów: częste commity i jasne punkty kontrolne. Im mniejszy i lepiej opisany krok, tym łatwiej zweryfikować, czy agent poszedł w dobrą stronę.

Dawanie kontekstu Link to heading

Jakość odpowiedzi agenta zależy wprost od kontekstu, jaki mu damy. Claude Code czerpie go z kilku źródeł:

  • CLAUDE.md — plik z instrukcjami i wiedzą o projekcie, automatycznie wczytywany do kontekstu. Może leżeć w katalogu głównym repozytorium, w katalogu domowym (~/.claude/CLAUDE.md — ustawienia globalne) albo w podfolderach projektu. Wersja CLAUDE.md jest commitowana do repozytorium i współdzielona z zespołem, natomiast CLAUDE.local.md służy do prywatnych notatek i nie trafia do repozytorium.
  • komendy slash — własne, wielokrotnego użytku polecenia,
  • wzmianki o plikach — wskazanie konkretnego pliku przez @nazwa-pliku wstrzykuje jego treść do rozmowy,
  • zasoby MCP — kontekst pobierany z podłączonych serwerów.

Dobry CLAUDE.md to inwestycja, która zwraca się przy każdej kolejnej sesji — opisujemy w nim konwencje, polecenia do budowania i testowania, architekturę oraz rzeczy, o których agent nie dowie się z samego kodu.

Praca w zespole Link to heading

To, co skonfigurujemy dla siebie, można współdzielić z zespołem — uprawnienia, (CLAUDE.md) i serwery MCP commitujemy do repozytorium. Dzięki temu cały zespół pracuje z Claude Code w spójny sposób, korzystając z tych samych narzędzi i konwencji.

Skróty w terminalu Link to heading

Podczas sesji warto znać kilka skrótów, które przyspieszają pracę:

  • ! — przejście w tryb bash, czyli wykonanie polecenia powłoki, którego wynik trafia do kontekstu rozmowy,
  • ? — wyświetlenie listy dostępnych skrótów klawiszowych.

Claude Code jako narzędzie uniksowe Link to heading

Na koniec coś, co otwiera zupełnie nowe możliwości — Claude Code można uruchomić w trybie nieinteraktywnym, jak klasyczne narzędzie uniksowe z potokami wejścia/wyjścia. Flaga -p (od print) pozwala zadać pytanie i dostać odpowiedź na standardowe wyjście:

claude -p "what is this blog about"

Dzięki temu Claude Code można wpleść w skrypty i potoki — przekazać mu dane na wejściu, a wynik przekierować dalej:

cat error.log | claude -p "podsumuj najczęstsze błędy z tego loga"

To podejście, znane jako Claude Code SDK, zamienia agenta w element automatyzacji — od generowania opisów commitów, przez analizę logów, po budowanie własnych narzędzi opartych o model.

Podsumowanie Link to heading

Claude Code najlepiej traktować jak współpracownika, któremu trzeba dać kontekst i jasno zakomunikować oczekiwania. Zainwestowanie czasu w dobry CLAUDE.md, przemyślane uprawnienia i wybór odpowiedniego przepływu pracy szybko się zwraca. A tryb nieinteraktywny sprawia, że ten sam agent, który pomaga nam w terminalu, może też działać w tle jako część automatyzacji.