Kiedy zaczynałem z Claude Code, byłem przekonany, że piszę kod 2 razy szybciej. Po miesiącu usiadłem i policzyłem zadania, które realnie dostarczyłem. Wyszło, że na 8 konkretnych błędach straciłem jakieś 40 godzin. Pisałem wolniej niż przed Claude Code. Tylko z ładniejszym uczuciem, że pracuję z AI.
W tym artykule pokażę Ci 8 błędów, które to powodowały. Żebyś Ty ich nie popełniał.
Cześć! Dzisiaj osobiście - mniej porównań, więcej konkretnej lekcji.
Teraz, kiedy Claude Code pisze u mnie realnie 50% do 60% kodu produkcyjnego, wiem dokładnie, gdzie wcześniej traciłem czas. 8 błędów. Każdy z konkretną poprawą, którą możesz wdrożyć od dzisiaj. Mój kontekst - projekty .NET.
BŁĄD 1 - Brak CLAUDE.md
Pierwszy błąd: przez 2 tygodnie nie miałem w projekcie pliku CLAUDE.md. Odpalałem claude w katalogu projektu i od razu wrzucałem zadania. Po co mi jakiś markdown, skoro asystent działa?
Efekt: Claude zgadywał konwencje. Czasem trafiał, częściej nie. W każdej nowej sesji tłumaczyłem mu od nowa - używamy MediatR, kontrolery dziedziczą po BaseApiController, DTO leżą w /Contracts. Te same zdania, dzień w dzień.
Rozwiązanie: na start każdego nowego projektu - CLAUDE.md w katalogu głównym repozytorium. Konwencje, biblioteki z wersjami, typowe komendy, rzeczy, których Claude nie odgadnie z kodu.
Ale uwaga - pułapka. Przeładowany CLAUDE.md jest tak samo zły jak jego brak. Gdy miałem tam 400 linii, Claude gubił kluczowe reguły. Trzymam teraz 50 do 80 linii, każda odpowiada na pytanie: czy bez tej informacji Claude popełniłby błąd?
BŁĄD 2 - Niejasne polecenia
Błąd drugi, najbardziej typowy. Moje pierwsze polecenia wyglądały tak: "popraw to", "dodaj walidację", "zrefaktoruj ten kontroler".
Claude robił coś. Rzadko dokładnie to, o co mi chodziło. 2 próba to tłumaczenie, o co mi chodziło. 3 to poprawki. 5-minutowe zadanie robiło się25-minutowe.
Teraz każde polecenie ma cztery elementy:
• Co - czyli konkretny cel
• Gdzie - pliki, klasy, referencja przez znak @
• Jak - ograniczenia, konwencje, biblioteki
• Co uznajemy za skończone - kryterium sukcesu
Zobacz jak to wygląda w praktyce.
Zacznijmy od złego przykładu, przykładowy prompt: "Dodaj walidację do CreateOrderCommand".
Zamiast tego lepiej napisać tak: "Dodaj walidator FluentValidation dla CreateOrderCommand.cs zgodnie z konwencją pozostałych walidatorów w folderze /Validators. Wymagane reguły: CustomerId większy od 0, Items niepuste, każdy Item.Quantity większy od 0. Testy w CreateOrderCommandValidatorTests muszą przejść zielono".
Drugie polecenie jest 4 razy dłuższe. Oszczędza godzinę poprawek.
BŁĄD 3 - Jedna sesja na cały dzień
Rano otwierałem sesję, pracowałem nad endpointem. Po południu w tej samej sesji - coś zupełnie innego, poprawka w innym module. Wieczorem wracałem do porannego tematu.
Klasyka. Kontekst zapełniał się: pliki, komendy, moje komunikaty. Pod koniec dnia Claude zaczynał mieszać konwencje z jednego modułu z drugim. Wracał do decyzji, które już nie obowiązywały.
Rozwiązanie jedno słowo: /clear. Między niepowiązanymi zadaniami. Skończyłeś zadanie, commit, /clear, nowy kontekst pod następne.
Brzmi jak drobiazg. To różnica między tym, czy Claude rozumie, o co Ci chodzi, czy dalej żyje rzeczami z przedpołudnia.
BŁĄD 4 - Poprawianie w kółko
Claude robi coś źle. Piszę "nie, miałem na myśli, żeby walidacja szła do osobnej klasy, nie do handlera". Poprawia - przenosi walidację do osobnej klasy, ale przy okazji zmienia sygnaturę handlera. Piszę 2 raz: "nie ruszaj handlera". Poprawia handler, ale teraz testy się sypią. Piszę 3 raz.
Każda moja korekta zostawała w kontekście razem z wadliwymi odpowiedziami Claude. On próbował pogodzić swoje poprzednie złe rozwiązania z moimi uwagami - i produkował coraz dziwniejsze wyniki. Kontekst był zatruty.
Zasada, którą stosuję teraz: 2 korekty i koniec. Jeśli po 2 Claude dalej nie robi, o co mi chodzi - /clear i nowe polecenie od zera. Tym razem zawieram w nim to, czego nauczyłem się z nieudanych prób.
W nowym poleceniu pierwszą linijką piszę, czego ma nie robić - bo wcześniejsze próby pokazały, gdzie Claude skręca źle. Na przykład: "Nie modyfikuj sygnatury metody Handle, nie dodawaj nowych zależności do konstruktora. Tylko nowa klasa walidatora w /Validators."
Czysty start z mądrzejszym poleceniem zawsze wygrywa z 3 próbą w zatrutej sesji.
BŁĄD 5 - Omijanie Plan Mode
Duże zadanie, zmiana w 10 plikach - pisałem po prostu "Claude, zrób to". Szedł, robił, po 15 minutach patrzyłem na diff i rozkładałem ręce.
Claude interpretował zadanie inaczej, niż ja je miałem w głowie. Rozwiązanie spójne w sobie - ale nie o to chodziło. On tracił 15 minut na wykonanie, ja 30 minit na analizę diffa, żeby stwierdzić, że nie tak.
Rozwiązanie: Plan Mode, odpalany przez Shift+Tab dwa razy (albo komendą /plan, jeśli wolisz). Dla wszystkiego, co dotyka więcej niż 3 plików albo ma jakąkolwiek niejasność architektoniczną.
Jak to działa: Claude najpierw przedstawia plan - jakie pliki zmieni, jakie funkcje doda, jaką strategię zastosuje. Ty czytasz, korygujesz albo akceptujesz. Dopiero wtedy wykonuje.
3 minuty dodane na początku. 30 minut oszczędzone na końcu. Za każdym razem.
BŁĄD 6 - Traktowanie Claude Code jak czatu
Kolejny błąd - wklejałem fragmenty kodu do Claude Code tak, jak robiłem to z ChatGPT. Opisywałem strukturę folderów słownie. Tłumaczyłem, jak wygląda mój projekt.
Problem: Claude Code ma dostęp do moich plików. Może je sam przeczytać. Kiedy wklejałem i opisywałem, marnowałem kontekst asystenta na informacje, które mógł pozyskać sam - z lepszą precyzją.
Teraz daję Claude'owi pracować jak asystent. Używam znaku @ - żeby wskazywać pliki: "zmień @OrderService.cs tak, żeby metoda CreateOrder zwracała Result<Order> zamiast rzucać wyjątek". Proszę, żeby sam przejrzał katalog i znalazł podobne przykłady: "popatrz, jak zrobione są inne handlery w folderze /Features, i dodaj handler dla GetOrderQuery w tym samym stylu".
Przestałem być pośrednikiem między Claude'em a moim kodem. To nie jest oszczędność sekund. To fundamentalna zmiana w sposobie pracy - z trybu rozmowy na tryb asystenta z dostępem do plików.
BŁĄD 7 - Brak weryfikacji
Kolejny błąd, najbardziej niebezpieczny ze wszystkich.
Claude mówił: "zrobione, testy przechodzą". Robiłem commit. Następne zadanie.
Kilka razy okazało się, że Claude był przekonany, że zrobił coś, czego nie zrobił. Raz dopisał test, który asertował, ale nie wywoływał kodu testowanego. Raz "uruchomił" testy, które w rzeczywistości nie poszły. Raz zmienił funkcję, ale zapomniał o jej drugim wywołaniu w innym pliku.
Te rzeczy przechodziły przez mój przegląd kodu, bo patrzyłem na diff powierzchownie. "Wygląda sensownie" mi wystarczało.
3 zasady, które stosuję teraz bez wyjątków:
Po pierwsze - sam uruchamiam testy. Albo każę Claude'owi uruchomić i pokazać wynik w terminalu. Nie wierzę na słowo.
Po drugie - czytam diff linia po linii dla krytycznych zmian. Nie przeglądam, czytam.
Po trzecie - pytam o przypadki brzegowe. Mam stałą formułkę: "Wymień wszystkie scenariusze, których nie pokrywa Twoja implementacja. Co się stanie przy pustej liście, przy null, przy równoległym wywołaniu, przy błędzie sieci?". Claude często sam wtedy znajduje luki.
Zasada brzmi prosto: ufaj, ale sprawdzaj. Nauczyłem się jej na własnych błędach.
BŁĄD 8 - Traktowanie Pro jak oszczędności
I ostatni błąd, ten o innym charakterze niż poprzednie.
Przez 2 miesiące byłem na planie Pro za 20 dolarów miesięcznie. Co drugi dzień uderzałem w 5-godzinne limity i musiałem przerywać w środku zadania. Myślałem: "Max za 100 dolarów to 5 razy więcej - nie, na tyle to nie pracuję".
Liczyłem niewłaściwe rzeczy.
Porównywałem cenę Maksa do ceny Pro. A powinienem porównać obie do kosztu mojej frustracji. Kiedy usiadłem i policzyłem uczciwie - ile razy w miesiącu limit przerywał mi pracę, ile razy traciłem skupienie, ile razy musiałem sobie przypominać, gdzie byłem - wychodziło około 8 godzin frustracji miesięcznie. Przy mojej stawce, 100 dolarów za Maksa było tańsze niż koszt tych straconych godzin.
Teraz jestem na Maksie. Przestałem w ogóle myśleć o tokenach. Puszczam zadania, które wcześniej uważałem za "za drogie". Używam Opusa tam, gdzie trzeba - wcześniej domyślnie odpalałem Sonneta wszędzie, żeby oszczędzić limit.
Uwaga - to nie znaczy, że każdy powinien iść na Maksa. Znaczy: policz uczciwie, ile Cię kosztuje frustracja, i porównaj z różnicą w cenie. U mnie wyszło tak. U Ciebie może wyjść inaczej, jeśli używasz Claude Code rzadziej albo masz niższą stawkę.
I podobna lekcja w mniejszej skali: słabszy model nie zawsze oszczędza pieniądze. Sonnet na trudnych zadaniach robi więcej prób, więcej korekt, więcej tokenów łącznie. Paradoksalnie - tańszy model na trudnych zadaniach wychodzi drożej.
Zasada, którą wyniosłem: licz koszt całkowity, nie cenę jednostkową. Plan i model dobierz do realnego użycia, nie do intuicji o oszczędzaniu.
Podsumowanie
8 błędów, wszystkie z pierwszego miesiąca. Podsumowując:
Dobry, krótki CLAUDE.md. Precyzyjne polecenia z czterema elementami. /clear między zadaniami. 2 korekty i koniec. Plan Mode dla dużych zmian. Asystent z dostępem do plików, nie czat. Ufaj, ale sprawdzaj. Licz koszt całkowity, nie cenę jednostkową.
Żadna z tych rzeczy nie jest oczywista na starcie. Każdej musiałem nauczyć się kosztem tygodni - zanim trafiłem na dokumentację Anthropica i wypracowałem własny sposób pracy.
Najważniejsze
I teraz rzecz, której ten artykuł Ci w pełni nie przekaże.
Te 8 błędów to dopiero początek. Pod nimi są kolejne warstwy - jak wygląda CLAUDE.md dla projektu .NET z CQRS, jakie wzorce poleceń działają najlepiej w DDD, kiedy Plan Mode warto zastąpić sub-asystentami, jak zbudować przegląd kodu generowanego przez AI.
Tego nauczyłem się przez wiele miesięcy. Spisałem wszystko w Szkole 3x Dev - Jak budować aplikacje szybciej dzięki AI. Konkretne wzorce pracy z Claude Code na realnych projektach .NET. Pierwszy miesiąc, o którym mówiłem w tym artykule , masz w niej już rozpakowany - plus wszystko, czego nauczyłem się przez kolejne.
