Claude Code to narzędzie terminalowe stworzone przez Anthropic, które pozwala programistom pracować z kodem przy pomocy języka naturalnego. Nie jest to zwykły czat, ale coś w rodzaju asystenta z własnym zdaniem – rozumie strukturę projektu, potrafi analizować repozytoria, edytować pliki, pisać testy, robić commity i generować dokumentację.

W praktyce można mu powiedzieć: „zrefaktoryzuj ten moduł”, „napisz testy do klasy UserService” albo „wytłumacz mi, co ja tu w ogóle zrobiłem tydzień temu”. Claude nie wzdycha i nie przewraca oczami jak spierdzieliłeś kod – a przynajmniej jeszcze tego nie robi.

Ostatnio testuję Claude Code przy pracy nad własnym kodem. Wnioski są proste: narzędzie jest potężne, ale trzeba go pilnować. Jak każdego „juniora”, który za bardzo ufa sobie i Stack Overflow.

Zarządzanie kontekstem

Claude działa w oparciu o kontekst – czyli wszystko, co pamięta z rozmowy. Każdy wiersz kodu, komentarz czy półprzypadkowa uwaga ma znaczenie. A im więcej informacji mu wrzucisz, tym bardziej zaczyna przypominać developera po piątej kawie – niby coś robi, ale już nie wiadomo co.

Zasady:

1. Ogranicz kontekst tylko do rzeczy istotnych. Nie ma sensu podawać mu wszystkiego, co masz w projekcie. Claude nie potrzebuje znać treści README z 2017 roku, żeby dodać test jednostkowy. Im mniej śmieci, tym mniej zgadywania i mniej filozoficznych odpowiedzi o naturze frameworka.

2. Zaczynaj nowe sesje przy każdej zmianie tematu. Jeśli kontekst, zacznij nową rozmowę. Claude nie ma zdolności odcinania się od przeszłości – trochę jak niektórzy współpracownicy, którzy wciąż wracają do bugów sprzed trzech sprintów.

3. Po zakończeniu fazy projektu czyść kontekst. Nie ma sensu ciągnąć starych danych, bo wtedy Claude zaczyna wymyślać własne historie. A jeśli zacznie pisać kod na podstawie poprzednich założeń – sam się poplączesz, próbując to potem debugować.

4. Używaj pliku task-....-impl.md. Zanim zrobisz „/clear”, poproś Claude’a o zapisanie istotnych informacji. W ten sposób możesz wrócić do tematu bez udawania, że pamiętasz, co ustalaliście tydzień temu.

5. Nie ufaj historii czatu. Claude potrafi zapomnieć kluczowe rzeczy szybciej niż system logowania po deployu. Zapisuj wszystko w plikach markdown – wtedy przynajmniej ktoś w tym projekcie będzie pamiętał, o co chodziło.

Planowanie i organizacja

Claude działa najlepiej, gdy ma plan. Bez planu zaczyna improwizować, a to zwykle kończy się kodem, który „działa u niego”.

Zasady:

1. Pracuj w oparciu o pliki plan.md, tasks.md i notes.md. To Twoje centrum dowodzenia. Bez nich Claude jest jak stażysta bez opisu zadania – zrobi coś, ale raczej nie to, o co Ci chodziło.

2. Zawsze zaczynaj od /init. Inicjalizacja projektu pozwala ustalić kontekst. Bez tego Claude zacznie działać „na czuja”, czyli dokładnie tak, jak nie chcesz.

3. Pracuj faza po fazie. Dziel projekt na etapy i nie skacz między nimi. Claude pamięta wszystko w jednym wątku, więc jeśli dasz mu trzy różne zadania naraz, przygotuj się na chaos godny merge’a z trzema konfliktami.

4. Twórz plan z pomocą innych modeli, ale daj Claude’owi do weryfikacji. Nie zaszkodzi, jak drugi AI spojrzy na to, co robisz. W najgorszym wypadku będą się nie zgadzać – ale to i tak mniej stresujące niż code review w poniedziałek rano.

5. Nie zrzucaj całego projektu naraz. Claude nie jest architektem z NASA. Jak dostanie 200 plików w jednym promptcie, prawdopodobnie się podda i zacznie pisać poezję o klasach w Pythonie.

6. Po każdej fazie rób code review. Claude nie obraża się za feedback, więc warto mu go dawać. Lepsze to niż tłumaczenie, czemu testy padły, bo AI „pomyślało, że tak będzie lepiej”.

Kontrola wersji (Git)

Git to najlepszy przyjaciel Claude’a – i Twój też, jeśli chcesz spać spokojnie.

Zasady:

1. Zawsze używaj Gita. Bez Gita każde eksperymentowanie z AI to proszenie się o katastrofę. Historia commitów to jedyny sposób, żebyś mógł potem udowodnić, że to nie Ty napisałeś ten dziwny kod.

2. Na początku sesji przypomnij Claude’owi ostatnie commity. Claude nie zna pojęcia „aktualnego stanu repo”. Jeśli mu nie powiesz, że coś się zmieniło, może nadpisać pół projektu. A potem tylko zostaje pytanie: kto to zmergował?

3. Jeśli coś pójdzie nie tak – usuń branch i zacznij od nowa. Nie próbuj ratować błędnych zmian. To jak próba naprawy bazy danych przez „Find and Replace” w notatniku.

Praca z promptami

Claude nie czyta w Twoich myślach – choć czasem wygląda, jakby próbował. W rzeczywistości im bardziej precyzyjnie opiszesz, czego chcesz, tym mniej kodu będziesz musiał potem naprawiać.

Zasady:

1. Określ dokładnie rolę Claude’a. Powiedz mu, czy ma być backend developerem, testerem, czy dokumentalistą. Bez tego zacznie działać jak wszystko naraz – i efekt będzie podobny do kodu pisanego przez zespół bez stand-upów.

2. Zdefiniuj dokładnie input i output. Claude lubi, gdy wszystko jest jasne. Jeśli tego nie zrobisz, sam wymyśli, co miałeś na myśli – a Ty będziesz się zastanawiać, czemu zwrócił JSON w YAML-u.

3. Rozbijaj duże zadania na mniejsze. Lepsze dziesięć małych promptów niż jeden gigant, po którym Claude dostaje egzystencjalnego kryzysu i zaczyna tłumaczyć, czym jest kod w sensie filozoficznym.

4. Jeśli coś jest niezrozumiałe – cofnij prompt i napisz inaczej. Nie próbuj tłumaczyć AI, że się myli. Po prostu sformułuj to od nowa. To nie rozmowa z szefem – tu masz prawo kliknąć „ESC” i zacząć od zera.

5. Używaj @ do wskazywania plików. Nie każ mu zgadywać, gdzie coś ma poprawić. Claude jest inteligentny, ale nie aż tak – a jeśli zgadnie, to raczej nie w tym pliku, co trzeba.

Jakość kodu

Claude potrafi pisać kod szybciej niż człowiek, ale czasem widać, że też ma „gorszy dzień”. Dlatego nie warto ufać mu bez weryfikacji. Czasami jak każdy agent generuje kod szybciej niż ty zdąrzysz przeczytać.

Zasady:

1. Wymuszaj linting i type checking. Nie licz, że AI samo tego przypilnuje. Czasami pisze kod, który działa tylko w teorii, podobnie jak większość „szybkich poprawek na produkcji”.

2. Testuj każde zadanie osobno. Jeden test to nic, ale brak testów to problem. Lepiej wychwycić błąd od razu niż tłumaczyć później, że „to AI tak zrobiło”.

3. Po zakończeniu projektu wykonaj audyt kodu. AI ma tendencję do „twórczej interpretacji” Twoich intencji. Audyt pozwoli sprawdzić, czy naprawdę zrobiło to, o co prosiłeś, czy tylko coś, co „wydawało mu się sensowne”.

Architektura agentów

Claude Code można traktować jak koordynatora zespołu złożonego z kilku agentów AI. Każdy ma robić swoje, a Claude pilnuje, żeby się nie pozabijali nawzajem.

Zasady:

1. Traktuj Claude’a jako organizatora, nie wykonawcę. Niech zarządza, ale nie pisze wszystkiego sam. W przeciwnym razie skończy się jak w wielu firmach – szef wszystko zrobi sam, tylko gorzej.

2. Twórz persony agentów. Określ, kto za co odpowiada. Dzięki temu nie będziesz mieć testera, który przypadkiem deployuje produkcję.

3. Utrzymuj oddzielne konteksty dla agentów. Każdy agent ma swój zakres pracy. Mieszanie im kontekstów kończy się tak samo, jak gdy frontendowiec zacznie poprawiać SQL-e.

4. Wprowadź subagenta-architekta. Powinien pilnować całej struktury projektu. To taki AI, który mówi „nie rób tego” zanim jeszcze uruchomisz builda.

5. Używaj pamięci projektu. Zapisuj w memory.md zasady, np. „nie optymalizuj przed testami”. Claude tego potrzebuje – inaczej sam uzna, że szybciej znaczy lepiej, a Ty będziesz sprzątał po nim przez resztę tygodnia.

Na koniec

Claude Code to dobre narzędzie, o ile nie traktujesz go jak magii. Działa świetnie, gdy ma porządek, plan i ograniczenia. Gubi się, gdy dasz mu za dużo wolności – czyli dokładnie jak większość programistów.

AI może pisać kod szybciej, ale odpowiedzialność i zdrowy rozsądek nadal muszą leżeć po Twojej stronie. W końcu to Ty podpisujesz commity, nie on.

I pamiętaj – w dzisiejszych czasach nikt już nie używa AI do pisania tekstów. Wszystko, co czytasz w internecie, powstaje oczywiście ręcznie, z pasją, kawą i bez żadnej pomocy maszyn. Tak samo jak kod w firmach, które „nie korzystają z ChatGPT”, bo mają własne standardy.

Jeśli więc ten artykuł wygląda na zbyt dobrze sformatowany, zbyt spójny i nie ma literówek – to na pewno czysty przypadek.