O czym jest ten film
- Dobry wynik uzyskany za pierwszym razem nie dowodzi, że polecenie będzie działało równie dobrze przy kolejnych próbach.
- Jakość pracy Claude’a rośnie, gdy może sprawdzić rezultat według konkretnych kryteriów i go poprawić.
- W projektach programistycznych część wiedzy warto zapisać przy kodzie, żeby dokumentacja nie rozmijała się z działającą aplikacją.
- Przy większych zadaniach opłaca się poprosić Claude’a o pomoc w przygotowaniu polecenia.
- Zbędne narzędzia, długie rozmowy i nieaktualne instrukcje zajmują miejsce w kontekście oraz podnoszą koszt pracy.
- Lepiej określić oczekiwany rezultat i warunki ukończenia zadania, niż szczegółowo dyktować każdą czynność.
- Przed naprawą błędu warto najpierw ustalić, co rzeczywiście wymaga zmiany.
- Po sprawdzeniu pomysłu przez gotowy konektor można zastąpić go w częstych zadaniach rozwiązaniem lepiej dopasowanym do potrzeb.
- Niezależne prace można prowadzić równolegle, a długą sesję przenieść do nowej rozmowy za pomocą notatki przekazującej stan projektu.
- Autor radzi korzystać z tańszych modeli do szerokiego rozpoznania tematu, mieć zapasowe narzędzie i zapisywać sprawdzone sposoby unikania powtarzających się błędów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Sprawdzaj powtarzalność, zanim wdrożysz polecenie
Na czym polega: Ten sam prompt może dać wyniki o różnej jakości. Jedna udana próba nie wystarcza, by uczynić go częścią stałego procesu.
Jak stosować: Przygotuj jasne kryteria sukcesu, uruchom polecenie na przykład dziesięć razy i policz udane próby. Po zmianie promptu powtórz ocenę na podobnych zadaniach.
Na co uważać: Wynik „osiem na dziesięć” ma sens tylko wtedy, gdy z góry wiadomo, co oznacza sukces. Nie oceniaj kolejnych wersji według zmieniających się kryteriów.
2.Daj modelowi sposób sprawdzenia własnej pracy
Na czym polega: Pierwszy rezultat traktuj jak szkic. Model może go poprawić, jeśli ma do czego go porównać.
Jak stosować: Dołącz przykład oczekiwanego efektu, listę wymagań, test automatyczny albo zrzut ekranu. Poproś Claude’a, by sprawdził wynik, wskazał rozbieżności i naniósł poprawki.
Na co uważać: Samo polecenie „sprawdź jeszcze raz” daje niewiele. Kontrola jest użyteczna wtedy, gdy opiera się na konkretnych kryteriach.
3.Trzymaj opis działania blisko kodu
Na czym polega: Gdy kod się zmienia, osobne notatki i specyfikacje mogą pozostać przy starej wersji. Model zaczyna wtedy pracować na sprzecznych informacjach.
Jak stosować: Zapisuj istotne wyjaśnienia przy odpowiednich fragmentach programu i aktualizuj je razem z kodem. Ogólne preferencje dotyczące sposobu pracy trzymaj w pliku CLAUDE.md.
Na co uważać: Komentarz w kodzie też może się zestarzeć. Nie dodawaj obszernych opisów, których nikt nie będzie utrzymywał.
4.Przy większym zadaniu wspólnie przygotuj prompt
Na czym polega: Claude może pomóc ustalić, jakich informacji brakuje, zanim przystąpi do właściwej pracy.
Jak stosować: Opisz cel i odbiorcę, a następnie poproś o pytania potrzebne do ułożenia dobrego polecenia. Pokaż przykład udanego rezultatu. Gotową instrukcję możesz wykorzystać w nowej sesji.
Na co uważać: Przy prostym, dobrze znanym zadaniu dodatkowy etap tylko wydłuży pracę. Sprawdź też, czy wygenerowany prompt rzeczywiście oddaje twoje zamiary.
5.Pilnuj zawartości kontekstu
Na czym polega: Instrukcje, narzędzia, konektory i historia rozmowy zajmują miejsce, z którego model korzysta podczas pracy.
Jak stosować: Sprawdź użycie kontekstu poleceniem /context, wyłącz niepotrzebne integracje i umiejętności. Gdy rozmowa staje się długa, użyj /compact albo przenieś poprawione podsumowanie do nowej sesji.
Na co uważać: Przy przenoszeniu zadania nie zgub podjętych decyzji, ważnych ograniczeń ani nierozwiązanych problemów. Przeczytaj podsumowanie przed dalszą pracą.
6.Określ warunki ukończenia zadania
Na czym polega: Autor przekonuje, że przy wielu zadaniach skuteczniej jest podać cel i kryteria odbioru niż rozpisywać modelowi każdą czynność.
Jak stosować: Wskaż, co ma działać, jakie testy mają przejść i kiedy model powinien zadać pytanie. Pozostaw mu wybór kolejności i sposobu wykonania prac, jeśli nie masz szczególnych wymagań.
Na co uważać: Swoboda nie zastępuje kryteriów jakości. Przy sprawach, w których błąd byłby kosztowny, wyraźnie zaznacz niejasności wymagające konsultacji.
7.Najpierw ustal problem, potem zlecaj poprawki
Na czym polega: Polecenie „napraw aplikację” zostawia modelowi decyzję, co uznać za błąd. Może zmienić także elementy, które ci odpowiadają.
Jak stosować: Poproś najpierw o listę problemów bez wprowadzania zmian. Wybierz z niej te, które mają zostać rozwiązane, i dopiero wtedy zleć poprawki.
Na co uważać: Diagnoza modelu jest propozycją, nie rozstrzygnięciem. Odrzuć punkty, które wynikają z jego upodobań, a nie z twoich wymagań.
8.Używaj konektorów do sprawdzenia pomysłu, potem oceń ich koszt
Na czym polega: Konektor MCP pozwala szybko uruchomić integrację, lecz może zajmować dużo kontekstu i wydłużać start narzędzia.
Jak stosować: Najpierw sprawdź przez gotowy konektor, czy dany proces działa. Jeśli wykonujesz go często, rozważ własną, węższą integrację lub zestaw instrukcji obejmujący tylko potrzebne czynności.
Na co uważać: Nie przebudowuj jednorazowego rozwiązania bez powodu. Porównaj koszt przygotowania własnej wersji z oszczędnością podczas późniejszego używania.
9.Równolegle wykonuj tylko niezależne prace
Na czym polega: Kilku agentów może jednocześnie pracować nad odrębnymi częściami projektu, co skraca czas oczekiwania.
Jak stosować: Wyznacz osobne zakresy, na przykład formularz, nagłówek strony i przycisk wylogowania. Zaplanuj na końcu połączenie zmian i sprawdzenie całości.
Na co uważać: Gdy agenci dotykają tych samych plików lub zależnych od siebie funkcji, rośnie ryzyko konfliktów. Autor sam zaznacza, że zysk czasu okupiony jest nieco większym ryzykiem błędów.
10.Zachowuj wiedzę o rozwiązaniach i przygotuj plan awaryjny
Na czym polega: Powtarzające się pomyłki można ograniczyć, zapisując skuteczne sposoby postępowania. Zapasowe narzędzie pozwala kontynuować pracę podczas awarii głównego.
Jak stosować: Po trudnym zadaniu zapytaj, jak można było wykonać je szybciej i mniejszym kosztem. Przydatne, ogólne zasady dopisz do CLAUDE.md. Przygotuj też drugi model do pracy na tym samym projekcie.
Na co uważać: Usuwaj z instrukcji nieaktualne dane i zasady. Nie zapisuj każdej pojedynczej wpadki jako trwałego zakazu.
Redakcyjne tłumaczenie
Czego nauczyło mnie tysiąc godzin pracy
W ciągu ostatnich kilku miesięcy wydałem na Claude Code ponad 30 tysięcy dolarów. Mam na to rachunki. Spędziłem też ponad tysiąc godzin, pracując z różnymi modelami. Chcę opowiedzieć o rzeczach, które sam chciałbym wiedzieć na początku.
Nie wszystkie wskazówki będą proste. Jeśli jednak chcecie w pełni wykorzystać Claude Code, trzeba przyjrzeć się szczegółom. Ułożyłem je od najłatwiejszych do bardziej zaawansowanych.
Nie ufaj pierwszemu wynikowi
Współpracuję z firmą wartą miliardy dolarów, która, moim zdaniem, zbyt łatwo ufa pierwszym wynikom otrzymanym od modelu. Później pojawiają się przez to poważne problemy.
Claude i inne duże modele językowe nie dają zawsze tej samej odpowiedzi na to samo polecenie. Przy kolejnych uruchomieniach różnice bywają niewielkie, ale zdarza się też, że wyniki są zupełnie inne.
Załóżmy, że przygotowujesz prompt do pisania scenariuszy filmów na YouTube. Pierwsza próba wypada znakomicie. Czy to wystarczy, by zapisać polecenie w firmowej procedurze i kazać całemu zespołowi z niego korzystać? Nie. Gdy uruchomisz je jeszcze kilka razy, możesz dostać zarówno świetne teksty, jak i takie, których nie zechcesz użyć.
Pracując nad procesem opartym na AI, chcesz ograniczyć te wahania. Powinieneś wiedzieć, jakiej jakości możesz się spodziewać przy każdym użyciu, a nie liczyć na szczególnie udaną próbę.
Dlatego przed włączeniem promptu do stałego procesu przeprowadź serię ocen, nazywanych często evalami. Uruchom polecenie dziesięć razy i policz, ile wyników spełnia wymagania. Jeśli siedem, masz siedem udanych prób na dziesięć. Potem zmień prompt i ponów ocenę. Gdy nowa wersja daje osiem udanych wyników, masz podstawę, by ją zachować. To sposób na stopniowe ulepszanie procesu w oparciu o obserwacje.
Pozwól Claude’owi sprawdzić i poprawić pracę
Jeśli prosisz Claude’a o napisanie tekstu i przyjmujesz pierwszą odpowiedź jako gotowy materiał, dostajesz odpowiednik pierwszego szkicu. A pierwszy szkic zwykle wymaga poprawek.
Daj więc modelowi możliwość sprawdzenia rezultatu i ponownego wykonania zadania. Może porównać tekst z przykładem, ocenić wygląd strony na zrzucie ekranu albo uruchomić ustalony test. Przy stronie internetowej takim punktem odniesienia może być choćby wynik narzędzia Lighthouse. Nawet jeśli początkowe polecenie nie jest idealne, konkretna informacja o tym, co wyszło źle, często pozwala znacząco poprawić rezultat.
Niech kod mówi, jak działa aplikacja
Przy pracy programistycznej widzę częsty problem: kod rozwija się, a towarzyszące mu notatki zostają w tyle. Aplikacja przechodzi od wersji pierwszej do czwartej, lecz specyfikacja i dziennik zmian wciąż opisują wersję pierwszą. Claude czyta wtedy informacje, które nie odpowiadają temu, co naprawdę znajduje się w projekcie.
Moim zdaniem opis istotnych rozwiązań powinien być jak najbliżej kodu, którego dotyczy. Model, pracując nad aplikacją, i tak musi ten kod przeczytać. Jeśli znajdzie tam aktualne komentarze i wyjaśnienia, łatwiej mu zrozumieć, co ma zmienić. Gdy poprosisz na przykład o dodanie przycisku wylogowania do paska nawigacyjnego, nie będzie musiał odtwarzać obecnego stanu aplikacji z kilku osobnych dokumentów.
Nie oznacza to, że każda instrukcja ma trafić do plików programu. W CLAUDE.md nadal warto przechowywać preferencje dotyczące współpracy: sposób przedstawiania odpowiedzi, ogólne zasady pracy czy wnioski z wcześniejszych zadań. To jednak inny rodzaj informacji niż opis działania konkretnego fragmentu aplikacji.
Poproś Claude’a o pomoc w napisaniu polecenia
Kiedyś przywiązywałem dużą wagę do własnych umiejętności pisania promptów. Dziś przy większych zadaniach często proszę Claude’a, żeby pomógł mi przygotować instrukcję dla samego siebie.
Zamiast od razu podawać długi zestaw szczegółowych wytycznych, mówię, co chcę osiągnąć i dla kogo powstaje wynik. Proszę model o pytania potrzebne do ułożenia dobrego polecenia. Może zapytać, kim dokładnie są odbiorcy, jak wygląda udany rezultat i czy mam przykład. Odpowiedzi pozwalają przygotować instrukcję lepiej dopasowaną do zadania.
Przy szybkim, codziennym poleceniu nie trzeba tego robić. Jeśli potrzebuję jednej informacji ze strony internetowej, proszę o nią wprost. Dodatkowy etap ma sens przy większych projektach, które pochłoną dużo pracy i tokenów.
Sprawdzaj, co zajmuje miejsce w kontekście
Polecenie /context pokazuje, z czego składa się kontekst bieżącej pracy Claude’a. Zanim wpiszesz pierwszą wiadomość, jego część mogą już zajmować instrukcje systemowe, CLAUDE.md, narzędzia, konektory MCP, pamięć i dodatkowe umiejętności. W pokazanym przeze mnie przykładzie wyglądało to na około 30 procent dostępnego miejsca.
Im dłuższa rozmowa, tym więcej materiału model musi brać pod uwagę. Rośnie koszt kolejnych zapytań, a nadmiar informacji może pogarszać odpowiedzi. Dlatego wyłączam konektory i inne dodatki, których akurat nie używam.
Jeżeli rozmowa jest już długa albo Claude zaczyna odpowiadać gorzej, przenoszę pracę do nowej sesji. Gdy wcześniej wspólnie przygotowaliśmy dobry prompt, kopiuję go i zaczynam od niego nową rozmowę. Warunek jest prosty: musi zawierać wszystkie informacje potrzebne do dalszej pracy.
Można też użyć /compact, które skraca historię sesji. Korzystam z niego zwykle wcześniej, niż Claude zrobiłby to automatycznie. Trzeba jedynie pamiętać, że sposób skracania niektórych informacji o narzędziach nie zawsze działa idealnie.
Podawaj cel i kryteria ukończenia
Kilka lat temu modele wymagały znacznie bardziej szczegółowych instrukcji. Trzeba było prowadzić je krok po kroku i wymieniać wiele rzeczy, których miały unikać. Dziś często można dać Claude’owi więcej swobody.
Traktuję go wtedy podobnie jak doświadczonego wykonawcę: określam zadanie i mówię, po czym poznam, że jest skończone. Na przykład: ta funkcja ma działać, te warunki mają być spełnione, a testów nie wolno pominąć. Jeśli czegoś nie wie, powinien zapytać.
Nie ma potrzeby dopisywania do każdego polecenia długiej listy zakazów odziedziczonej po pracy ze starszymi modelami. Ważniejsze są jasne zasady. Jeśli zadanie jest szczególnie istotne, mówię wprost, że przy niepewności Claude ma zwrócić się do mnie.
Zdiagnozuj problem, zanim zlecisz naprawę
Gdy aplikacja nie działa tak, jak chcesz, nie zaczynaj od ogólnego „napraw wszystko”. Najpierw poproś Claude’a o listę problemów i zaznacz, że na razie nie ma niczego zmieniać.
Model może uznać za wadę coś, co wcale ci nie przeszkadza. W tekście może na przykład wskazać niejasny początek, powtórzenie, zbyt swobodny ton i brak przykładu. Jeśli swobodny ton jest zamierzony, wykreśl ten punkt. Dopiero potem zleć poprawienie pozostałych trzech.
W ten sposób unikasz pracy nad zmianami, które trzeba byłoby później odwracać. Oszczędzasz czas i tokeny, a przede wszystkim zachowujesz kontrolę nad tym, co rzeczywiście ma zostać poprawione.
Konektor MCP jest dobry na początek
Gdy przygotowuję system dla siebie lub klienta, często zaczynam od gotowego konektora. Integracje tego rodzaju pozwalają szybko się zalogować, połączyć usługę i sprawdzić, czy pomysł działa. Wiele takich połączeń korzysta z protokołu MCP, czyli Model Context Protocol.
To wygodny sposób na uruchomienie prototypu. Przy częstej pracy na większą skalę konektor bywa jednak zbyt rozbudowany: udostępnia modelowi opisy wielu funkcji, których dany proces nie potrzebuje, i zajmuje miejsce w kontekście.
Kiedy sprawdzę, że zadanie da się wykonać, często przygotowuję węższe rozwiązanie dopasowane do tego jednego procesu. Model dostaje wtedy tylko potrzebne narzędzia i instrukcje. Usuwam też nieużywane konektory z Claude Code. Przy uruchamianiu program sprawdza ich działanie, więc dłuższa lista oznacza dodatkowe czekanie. U mnie uporządkowanie tej listy potrafi skrócić start o kilka sekund.
Rozdziel niezależne zadania między agentów
Coraz rzadziej pracuję w rytmie: zlecenie, oczekiwanie na wynik, kolejne zlecenie. Jeśli zadania są od siebie niezależne, powierzam je kilku agentom równocześnie.
Przy tworzeniu strony jeden może poprawiać jej główną sekcję, drugi formularz opinii, a trzeci przycisk wylogowania. Można wyraźnie poprosić Claude’a o równoległe wykonanie osobnych, ściśle określonych prac. Na końcu trzeba połączyć zmiany i sprawdzić całość.
Najważniejsze, by agenci nie pracowali jednocześnie nad tym samym fragmentem. Równoległość skraca czas, ale trochę zwiększa ryzyko błędów. Mimo to w wielu projektach uznaję taką wymianę za opłacalną.
Przekazuj stan projektu do nowej sesji
W długiej rozmowie gromadzą się stare ustalenia, późniejsze poprawki i przypadkowe sformułowania. Mogę najpierw powiedzieć „nie rób X”, a kilka wiadomości później poprosić o coś „trochę podobnego do X”. Model próbuje wtedy pogodzić wskazówki, które w praktyce prowadzą w różne strony.
Kiedy wyniki zaczynają odbiegać od oczekiwań, proszę Claude’a o notatkę przekazującą stan prac. Ma w niej wymienić to, co już zostało zrobione, decyzje do podjęcia, następne kroki i nierozwiązane problemy. Czytam notatkę, poprawiam błędy, a następnie wklejam ją do nowej rozmowy.
Nowa sesja dostaje krótszy i bardziej uporządkowany opis projektu. Zwykle oznacza to lepszą jakość pracy i niższy koszt kolejnych wiadomości.
Zadawaj pytania na marginesie przez /btw
Gdy Claude wykonuje duże zadanie, łatwo stracić orientację. Wracasz po kilku minutach i nie pamiętasz już, co oznacza termin użyty w planie albo na jakim etapie jest praca.
W takich sytuacjach używam /btw do zadania pobocznego pytania. Mogę poprosić o wyjaśnienie pojęcia, podczas gdy główne zadanie nadal trwa. Odpowiedź nie dopisuje tej dygresji do zasadniczej rozmowy. Dzięki temu mogę się czegoś dowiedzieć bez czekania na zakończenie całej pracy i bez rozbudowywania jej kontekstu.
Szerokie rozpoznanie zleć tańszym modelom
Jakość decyzji często rośnie, gdy przed jej podjęciem sprawdzisz różne sposoby rozwiązania problemu. Można przejrzeć publikacje, wpisy techniczne, doświadczenia innych osób i własne pomysły. Takie rozpoznanie potrafi jednak dużo kosztować, jeśli od początku do końca wykonuje je najmocniejszy model.
Dlatego proponuję podział pracy. Tańsze modele szukają szeroko: zbierają podejścia, przykłady i argumenty. Następnie mocniejszy model dostaje zebrane informacje, porównuje je i podejmuje decyzję. Proszę też o sprawdzenie pomysłów mniej oczywistych, o ile da się znaleźć coś, co przemawia za ich zastosowaniem.
Ta metoda pozwala objąć więcej możliwych rozwiązań bez płacenia za to, by najdroższy model sam prowadził każde poszukiwanie.
Utrzymuj CLAUDE.md w aktualnym stanie
Warto regularnie przeglądać plik z instrukcjami dla Claude’a. Niedawno odkryłem, że przekazuję mu stare dane o przychodach. Na ich podstawie wyciągał błędne wnioski o tym, ile mogę wydać i jakie ryzyko jestem gotów podjąć.
W moim CLAUDE.md znajduje się krótka informacja o strukturze projektu, kilka preferencji — na przykład prośba o pełne ścieżki plików i używanie Pythona — oraz zasady dotyczące tego, co Claude może robić samodzielnie, a kiedy powinien zapytać. Są tam też informacje o mnie i wnioski z wcześniejszej pracy.
Każda z tych rzeczy powinna być nadal przydatna. Nie ma sensu zużywać miejsca w kontekście na nieaktualne dane lub instrukcje napisane z myślą o dawnych możliwościach modeli. Po aktualizacji modelu również warto ponownie przejrzeć taki plik.
Miej narzędzie zapasowe
Claude Code miewa awarie i okresy, w których jakość pracy się waha. Jeśli cały zespół polega wyłącznie na nim, praca może wtedy stanąć. Widziałem takie sytuacje nawet w dużych firmach.
Dlatego oprócz Claude Code mam przygotowane drugie narzędzie, na przykład Codex, które może pracować w tym samym katalogu projektu. Dbam o to, by dostało potrzebne instrukcje. Jednym ze sposobów jest powiązanie pliku CLAUDE.md z odpowiednikiem używanym przez inne narzędzie, takim jak AGENTS.md, tak aby oba odwoływały się do tych samych aktualnych zasad.
Gdy główne narzędzie jest niedostępne, mogę przekazać zadanie zapasowemu i kontynuować pracę.
Zapisuj skuteczne rozwiązania, nie same zakazy
Jeżeli Claude popełnia ten sam błąd, warto wyciągnąć z tego wniosek i dodać go do stałych instrukcji. Trzeba jednak zapisać sposób postępowania, który rozwiązuje problem.
Jeśli model wielokrotnie próbuje użyć starego API, zdanie „nie próbuj starego API” niewiele mu pomaga. Lepiej wskazać aktualną metodę. Podobnie przy nieefektywnej pracy z plikami: użyteczniejsza będzie wskazówka, by grupować odczyty, niż sama lista nieudanych prób.
Po wykonaniu zadania często pytam Claude’a: „Jak można było zrobić to szybciej i zużyć mniej tokenów?”. Sprawdzone wnioski przenoszę do CLAUDE.md. Według moich szacunków takie zasady oszczędzają mi kilka godzin tygodniowo, bo model nie musi ponownie odkrywać rozwiązania tych samych problemów.
To właśnie polecam wynieść z całego materiału: oceniaj powtarzalność wyników, dawaj modelowi możliwość kontroli, porządkuj informacje, z których korzysta, i utrwalaj sposoby pracy, które rzeczywiście się sprawdziły.
Jeśli interesuje was wykorzystanie AI i automatyzacji w firmie lub pracy z klientami, prowadzę też płatny program Maker School. Szczegóły znajdują się w opisie filmu. Dziękuję za uwagę.