Claude Code - okładka

Claude Code – pierwsze wrażenia

Opublikowano Kategorie AICzas czytania 15min

Od jakiegoś czasu na materiały dotyczące Claude Code trafiałem niemal codziennie. Przez długi czas twardo trzymałem się Cursora, jednak jakiś czas temu postanowiłem w końcu sprawdzić, dlaczego tyle mówi się o Claude Code. Po kilku tygodniach intensywnego testowania nieco bardziej rozumiem, dlaczego o tym narzędziu jest tak głośno.

Zapraszam do lektury moich pierwszych wrażeń z pracy z Claude Code. Swoje doświadczenia opieram na pracy z modelami Sonnet 4.6 i Opus 4.6.

Zdecydowanie nie czuję się ekspertem w pracy z Claude Code. Myślę jednak, że moje spostrzeżenia pomogą Ci podjąć decyzję, czy narzędzie jest warte Twojej uwagi, oraz ułatwić Ci rozpoczęcie pracy z nim. W ramach artykułu będę zamiennie stosował nazwy Claude i Claude Code mając na myśli ten sam produkt.

Czym jest Claude Code

Claude Code to narzędzie CLI działające w terminalu. Nie dostarcza interfejsu graficznego i działa wyłącznie w terminalu. Może działać obok IDE (np. VS Code), ale nie jest edytorem. Osoby preferujące terminal będą zadowolone. Ci, którzy wolą GUI, mogą skorzystać np. z Claude Code for VS Code.

Interfejs mocno przypomina ten z aplikacji czatów zbudowanych na LLM-ach. Uruchamiamy Claude Code w danym katalogu i wpisujemy prompt. Następnie Claude zaczyna pracę, okresowo dopytując, czy może użyć konkretnych poleceń. Podczas działania narzędzia można krok po kroku obserwować wykonywane polecenia. Kroki pośrednie nie są jednak widoczne w końcowym rezultacie. Opisane zachowanie jest domyślne, jednak wiele aspektów pracy z narzędziem można spersonalizować.

By skorzystać z Claude Code, konieczna jest subskrypcja Claude na poziomie Pro lub Max. Można również korzystać z rozliczenia za faktyczne zużycie, jednak ta opcja nie jest zbyt opłacalna, sczególnie jeśli intensywnie korzystamy z narzędzia.

Instalacja i konfiguracja

Instalacja jest banalna i w moim przypadku wymagała jedynie uruchomienia jednego polecenia z dokumentacji i zalogowania się do konta Claude. Po tym można już pracować z narzędziem. Nie ma potrzeby indeksowania kodu projektu, czekania na uruchomienie czy dodatkowej konfiguracji. Claude Code po uruchomieniu po prostu działa. Oczywiście istnieje możliwość dostosowania go pod swoje potrzeby, jednak jest to możliwość, a nie konieczność.

Po uruchomieniu Claude Code do dyspozycji mamy wiersz poleceń, z którego można wywoływać komendy dostępne po naciśnięciu slasha. Każda dostępna komenda ma proste objaśnienie. Oczywiście możemy również przekazywać za jego pomocą prompty.

Pracę możemy rozpocząć, wywołując polecenie /init. Stworzy ono plik CLAUDE.md zawierający dokumentację dla naszego codebase. Claude Code będzie ładował ten plik do kontekstu korzystał z niego w trakcie pracy. Warto w nim umieścić kluczowe zasady w projekcie, code style guide, dobre praktyki itp. Umieszczając go w rootcie projektu, Claude Code automatycznie go zaciągnie przy każdej nowej sesji. Warto upewnić się, że plik nie jest przeładowany informacjami. Zbyt duży kontekst może negatywnie wpływać na jakość otrzymywanych wyników. Nadmiar informacji może prowadzić do ignorowania części instrukcji lub spadku poprawności odpowiedzi.

Jeśli chcemy zaaplikować pewne reguły dla specyficznego katalogu, możemy w nim umieścić dedykowany CLAUDE.md i opisać w nim zasady specyficzne dla danego katalogu. Zagnieżdżone pliki CLAUDE.md są ładowane, jeśli jest taka potrzeba. Dobrym przypadkiem ich użycia są reguły dla testów, które można umieścić w katalogu z testami i ładować je tylko wtedy, gdy agent pracuje z testami.

Nie warto w nim zamieszczać np. opisu tego, co widać w kodzie, szczegółowego opisu plików, wytłumaczenia powszechnie znanych reguł czy pełnej treści dokumentacji. W przypadku zewnętrznych zasobów warto zostawić link – Claude Code spróbuje je pobrać, gdy będzie ich potrzebował. Rozmiar i zawartość kontekstu można sprawdzić poleceniem /context.

Wspomniałem wcześniej o tym, że Claude Code dopytuje o wywoływanie poleceń. Możemy mu zezwolić jednorazowo lub dodać uprawnienia do konkretnych poleceń, by przyspieszyć pracę i nie odrywać się od innych zadań. Sam tryb uprawnień również można dostosować pod swoje potrzeby. Jeśli chcemy pozwolić Claudowi dowolnie przeglądać i modyfikować pliki, to nic nie stoi na przeszkodzie (choć nie uważam tego za najbezpieczniejszą opcję). Jeśli chcemy traktować go bardziej jako konsultanta niż developera, to również jest taka możliwość.

Narzędzie pozwala również na dostosowanie stylu odpowiedzi:

  1. Default Claude completes coding tasks efficiently and provides concise responses
  2. Explanatory Claude explains its implementation choices and codebase patterns
  3. Learning Claude pauses and asks you to write small pieces of code for hands-on practice

Możemy również dobrać model odpowiedni do naszych potrzeb i budżetu:

  1. Default (recommended) Sonnet 4.6 · Best for everyday tasks
  2. Opus 4.6 · Most capable for complex work
  3. Haiku 4.5 · Fastest for quick answers

Poziom reasoningu również można dopasować, by móc sterować kosztem i czasem odpowiedzi. Do dyspozycji mamy poziomy: low, mediumhigh. Wyższy poziom reasoningu zwiększa koszt i czas odpowiedzi, ale potencjalnie może skutkować lepszymi rezultatami.

Ponieważ jest to narzędzie od Anthropic, dość naturalne jest, że nie ma w nim dostępnych modeli od innych providerów. Możliwe jest uruchomienie Claude Code z innymi modelami, jednak istnieje wtedy spore ryzyko, że nie będzie to działało tak dobrze, jak z modelami z rodziny Claude.

Claude Code działa lepiej, gdy dostarczymy mu precyzyjne instrukcje i ograniczymy niejednoznaczność w promptach. Efektywność zależy od jakości promptów, struktury projektu, zawartości kontekstu oraz jakości samego codebase. W szczególności dotyczy to architektury projektu, modularyzacji i spójności kodu.

Co działa dobrze

Claude Code jest absolutnie świetnym narzędziem, jeśli szukamy uzupełnienia dla projektowej wiki czy dokumentacji. Z łatwością odnajduje wymagane miejsca w kodzie oraz potrafi szczegółowo zinterpretować konkretne rozwiązania. Absolutnie nie powinien jednak zastępować dokumentacji. Poprosiłem go, by przygotował mi np. zestawienie zdarzeń w systemie. W przypadku zdarzeń nie tylko otrzymałem kompletną listę, ale również każde zdarzenie otrzymało krótki opis oraz zostało przypisane do konkretnego typu zdarzenia (Claude podzielił je na techniczne, wewnętrzne i domenowe).

Myślę, że Claude świetnie sprawdziłby się jako narzędzie do onboardingu dla nowych osób dołączających do projektu. Nowa osoba w zespole, zamiast przekopywać się przez często zdezaktualizowane docsy, historyczne commity czy wypytując innych, może po prostu skonstruować odpowiedni prompt.

Testowałem go jak dotąd w większości na prostych zadaniach, które spokojnie wykonałby początkujący programista. W takich przypadkach radzi sobie świetnie. Kilkoma promptami byłem w stanie przygotować kod pod proste funkcjonalności. Przy bardziej ambitnych zadaniach traktowałem go raczej jako konsultanta, a nie developera. Jednak nawet w takim podejściu, patrząc na zwracane odpowiedzi, niekiedy podchodziłem do rekomendacji Claude Code z pewną dozą sceptycyzmu. Oczywiście można podnieść stwierdzenie, że Claude bez problemu radzi sobie z bardziej złożonymi problemami, tylko wymaga bardziej precyzyjnych promptów. Świetnie podsumował to Oskar z Architecture Weekly:

You’re not necessarily saving time – you’re programming in Markdown instead of code.

Jednym z głównych celów wykorzystania narzędzi AI jest oszczędność czasu. Jeśli obsługa narzędzia zajmuje więcej niż wykonanie zadania, to wykorzystanie go traci sens. W przypadku zadań wymagających tony promptów czasami łatwiej jest mi zrobić zadanie w tradycyjny sposób. Podobnie sytuacja ma się, gdy dokładnie wiem, co i gdzie należy zrobić.

Claude Code implementuje runtime dla tzw. agent loop (plan–act–observe), w którym model planuje działania, wykonuje je przy użyciu narzędzi (np. bash, filesystem, web search, web scraping) i na podstawie wyników podejmuje kolejne kroki. Claude udostępnia zestaw narzędzi, takich jak web search, web scraping oraz sandbox do wykonywania kodu. Możemy również jednocześnie delegować pracę do wielu agentów i równolegle realizować różne zadania.

Następujący przykład pozwolił mi przetestować podejście agentowe w praktyce. Przygotowałem prompt: “Use three parallel agents to identify bottlenecks in tests. Focus on performance, stability, and execution time”. Claude faktycznie uruchomił trzech agentów i każdemu przypisał konkretne zadania, co pozytywnie mnie zaskoczyło. Spodziewałem się raczej, że każdy agent będzie próbował przeanalizować problem holistycznie.


⏺ Running 3 Explore agents… (ctrl+o to expand)
├─ Analyze test performance bottlenecks · 21 tool uses · 49.5k tokens
│ ⎿ Searching for 9 patterns, reading 12 files…
├─ Analyze test stability issues · 34 tool uses · 94.6k tokens
│ ⎿ Searching for 17 patterns, reading 17 files…
└─ Analyze test execution time · 15 tool uses · 61.7k tokens
⎿ Bash: ctrl+b to run in background

Przy każdym agencie widać informację o wywołanych toolach. Możemy dodawać również własne toole, np. narzędzia bashowe, z których korzystamy na co dzień, czy aplikacje korzystające z MCP (Model Context Protocol).

Korzystając z MCP, można rozszerzyć wiedzę i umiejętności Claude Code. Dużą wartość dała mi integracja z GitHubem, dzięki której mogę szybko przeszukiwać issuesy i pull requesty, przygotowywać podsumowania czy analizować historię zgłaszanych problemów. Integracja z GitHub MCP jest bardzo prosta.


claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'

Sposoby pracy z Claude Code

Boris Cherny, autor Claude Code, w swojej prezentacji pokazał kilka rekomendowanych sposobów pracy z omawianym narzędziem. Szczególnie dwa w mojej opinii wyglądają interesująco:

  • Explore > plan > confirm > code > commit – Osobiście najczęściej korzystam z tego trybu. Na etapie planowania można również podzielić sobie większe zadania na kilka mniejszych i zrównoleglić proces dla np. kilku miejsc w kodzie dotkniętych zmianą czy obszarów danego zadania. Osobiście nie lubię, gdy AI tworzy za mnie commity, więc po zakończeniu prac zwykle ręcznie przeglądam zmiany przed utworzeniem commita. Będąc na etapie przygotowania prac, warto jawnie wskazać agentowi, by w razie wątpliwości pytał o brakujące informacje. Dzięki temu istnieje mniejsza szansa, że agent podejmie założenia inne niż te, które my mamy i zapomnieliśmy ich przekazać w prompcie.
  • Write tests > commit > code > iterate > commit – jest to klasyczne Test-Driven Development. Na co dzień rzadko korzystam z TDD, więc w przypadku AI również nie czuję takiej potrzeby. Jednak miałem okazję poeksperymentować z tym podejściem i daje równie dobre rezultaty, jak poprzednie.

Eksplorując możliwości, miałem okazję poznać kilka dodatkowych flow, które również warto rozważyć:

  • Boilerplate > plan > confirm > code – w tym workflow agent nie startuje od zera. Programista definiuje strukturę rozwiązania (klasy, interfejsy, zależności), a następnie zleca agentowi przygotowanie implementacji. W analogiczny sposób możemy pracować w podejściu opartym na TDD. Programista może przygotować zestaw opisów przypadków testowych, a następnie poprosić agenta o kontynuowanie pracy. To podejście daje nieco więcej kontroli programiście.
  • Explore > plan > confirm > code > question – jest to kolejna wariacja podejścia klasycznego. Dodatkowym krokiem przed wypchnięciem zmian jest etap kwestionowania zmian i szukania luk w rozwiązaniu i logice. Mając zakodowane rozwiązania, zaczynamy drążyć potencjalne problemy i opisywać scenariusze produkcyjne, prosząc o szczegółowe objaśnienie, jak zachowa się kod po zmianach.

Niezależnie od obranego sposobu pracy mam bardzo istotną rekomendację – commituj często! W przypadku jednego zadania miałem już działające, niezacommitowane rozwiązanie pokrywające happy path. Postanowiłem zacząć pokrywać bardziej egzotyczne scenariusze i w tym przypadku Claude Code nie tylko niepoprawnie je obsłużył, ale zepsuł już działające rozwiązanie. Próby dalszych napraw tylko pogłębiały ten problem. Nawet próba jawnego wskazania, by Claude Code wycofał ostatnie zmiany, nie sprawiła, że rozwiązanie się naprawiło.

Co mi nie odpowiada

Jedną z funkcji, które moim zdaniem niemal nigdzie nie działają dobrze, a bardzo chciałbym, by działały dobrze, jest text-to-speech. Niestety, Claude Code wpisuje się w ten trend.

Każdorazowo, gdy text-to-speech zaczyna wypluwać mi głupoty, zaczynam testować, czy może coś z moim mikrofonem jest nie tak i za każdym razem wychodzi, że to jednak wina narzędzia. Text-to-speech działa co najwyżej akceptowalnie tylko przy bardzo wolnym i wyraźnym dyktowaniu. W praktyce taki sposób pracy jest mało wygodny i całkowicie nieefektywny. Wymaga to również unikania homofonów czy nienaturalnego akcentowania sylab i końcówek.

Z innych mniej przyjemnych doświadczeń kilkukrotnie zdarzyło się Claudowi zawiesić w procesie myślenia nad fixem. Pracował sobie kilkanaście minut bez widocznego progresu. Podobne zachowanie sporadycznie obserwuję również w Cursorze (gdzie także korzystam głównie z modeli od Anthropica), więc możliwe, że po prostu taka już ich natura. Sporadycznie zdarzają się również drobne błędy UI, takie jak uciekający scroll czy nieczytelne formatowanie odpowiedzi.

Jednoznaczna ocena jakości dostarczanych rozwiązań przez Claude Code jest bardzo trudna. Należy pamiętać, że efekty działania będą drastycznie różne w zależności od tego, jak przygotujemy prompta. Warto też mieć na uwadze, że Claude działa niedeterministycznie. Ten sam prompt może prowadzić do różnych rezultatów, szczególnie w przypadku dłuższych sesji czy wykorzystania dużego kontekstu. Gdy kontekst się zapełnia, Claude może przestać uwzględniać część informacji lub robić błędy. Jeśli przeskakujemy między taskami lub Claude zaczyna robić błędy, warto wyczyścić kontekst poleceniem /clear.

Przykładowo, poprosiłem Claude Code o przygotowanie changeloga zmian dla danej gałęzi. Pierwszym rezultatem było ogólnikowe wylistowanie tego, co było zmienione i w jakich plikach. Widząc rezultat, doprecyzowałem format oraz zawartość changeloga. Opisałem cechy dobrego changeloga oraz oczekiwaną strukturę. Niestety kolejny changelog ujął również zmiany z merge commitów. Za trzecim razem rezultat był niemal idealny. Poprosiłem go o skrócenie ostatecznej zawartości. Może się wydawać, że to sporo dodatkowej pracy, jednak wina faktycznie tkwiła w kiepskich i nieprecyzyjnych promptach.

Podsumowanie

Claude Code bardzo pozytywnie mnie zaskoczył zarówno możliwościami, jak i komfortem pracy. Po przyzwyczajeniu się do Cursora dość niechętnie zapatrywałem się na testowanie nowych rozwiązań. Jednak po spróbowaniu absolutnie nie żałuję. Obecnie więcej niż połowę rozwiązań dostarczam z wykorzystaniem Claude Code. Jeśli nie miałeś/aś jeszcze okazji sprawdzić Claude w praktyce, to gorąco zachęcam.

Z wielką mocą idzie jednak wielka odpowiedzialność. Decydując się na narzędzie, które bazuje na wzorcach i schematach oraz ma dostęp do całości kodu w projekcie, jeszcze bardziej należy pilnować jakości kodu. Szczególnie mam tu na myśli aspekty związane z jego utrzymaniem, modularyzacją, odpowiednim wyznaczaniem granic, testowaniem i czytelnością. Jeśli te aspekty u nas kuleją, to istnieje ryzyko, że Claude Code zacznie powielać te problemy, co tylko spotęguje problem. Generowany kod zawsze powinien przejść review, szczególnie w kontekście bezpieczeństwa i poprawności implementacji.

Narzędzie jest również polecane do zadań niekoniecznie związanych z kodowaniem. Dzięki dostępowi do systemu plików jesteśmy w stanie realizować zadania szybciej niż przy użyciu webowych narzędzi typu ChatGPT.

Jeśli temat Cię zainteresował, w źródłach znajdziesz sporo materiałów pogłębiających temat. Będę również bardzo wdzięczny, jeśli podzielisz się w komentarzu swoimi obserwacjami i sposobem pracy.

Źródła i materiały dodatkowe

Dominik Szczepaniak

Zawodowo Senior Software Engineer w CKSource. Prywatnie bloger, fan włoskiej kuchni, dobrej kawy i miłośnik jazdy na rowerze.

Inne wpisy, które mogą Cię zainteresować

Kolejna książka o Gicie — naucz się korzystać z Gita jak profesjonalista

Okładka e-booka - Kolejna książka o Gicie

"Kolejna książka o Gicie" to kompleksowy e-book, który pozwoli Ci poznać Gita od A do Z, a także liczne narzędzia dedykowane pracy z Gitem!

Dlaczego warto?

  • 👉 Git od podstaw do poziomu PRO. E-book przeprowadzi Cię krok po kroku, niezależnie od poziomu doświadczenia.
  • 👉 Zdobędziesz praktyczne umiejętności, które natychmiast wykorzystasz w prawdziwych projektach.
  • 👉 Wiedza połączona z praktyką! Oprócz masy teorii w e-booku znajdziesz też zadania praktyczne.

Okładka e-booka - Kolejna książka o Gicie

Przygotuj się lepiej do rozmowy o pracę!

Odbierz darmowy egzemplarz e-booka 106 Pytań Rekrutacyjnych Junior JavaScript Developer i realnie zwiększ swoje szanse na rozmowie rekrutacyjnej! Będziesz też otrzymywać wartościowe treści i powiadomienia o nowych wpisach na skrzynkę e-mail.

Dlaczego warto?

  • 👉 Ponad 1000 pobrań e-booka!
  • 👉 60 stron pełnych pytań i zadań praktycznych. Pytania i zadania pochodzą z faktycznych procesów rekrutacyjnych.

E-booka odbierzesz korzystając z formularza poniżej 👇

Okładka e-booka - Kolejna książka o Gicie

guest

2 komentarzy
Najwięcej głosów
Najnowsze Najstarsze
Bogumił
Bogumił
2 miesiące temu

Odnośnie speech-to-text (bo chyba o to chodziło, jeśli dyktujesz?), to polecam narzędzie SuperWhisper, działa bardzo dobrze.