Cztery prompty, które przeciwdziałają uległości w Claude Code

Czym jest uległość AI w Claude Code?#

Psychologia od dawna ma na to zjawisko własne określenie: uległość. To pochlebca, który mówi to, co chcesz usłyszeć, tylko po to, by podtrzymać rozmowę. Wraz z pojawieniem się dużych modeli językowych to słowo trafiło do badań nad AI, a w jednej z oficjalnych analiz Anthropic otwarcie przyznał, że model regularnie poświęca dokładność na rzecz szybkiego potwierdzania opinii.

W programowaniu wygląda to tak. Piszesz do Claude Code: „Napraw ten błąd w authMiddleware; magic links przestały działać”. Uległy model nie zadaje pytań doprecyzowujących. Nie prosi o logi. Nie pyta, z której wersji biblioteki korzystasz. Od razu proponuje rozwiązanie, bo został wytrenowany, by szybko pomagać. A rozwiązanie będzie wyglądać poprawnie: importy, obsługa błędów, komentarze. Tyle że będzie odpowiadać na czyjś inny problem, zmyślony na podstawie kontekstu, który Claude poskładał z fragmentów.

Przyczyną nie jest Claude, lecz sposób sformułowania prośby. Gdy pytasz „Jak to naprawić?”, zakładasz już, że da się to naprawić. Uległy model przyjmie to założenie i zaproponuje „poprawkę”, nawet jeśli prawdziwy problem tkwi w architekturze, wersji biblioteki albo w tym, że opisany objaw jest jedynie skutkiem zupełnie innego błędu źródłowego.

Prosty test na uległą prośbę: jeśli nie potrafię odpowiedzieć w trzech zdaniach na pytanie „Co dokładnie jest zepsute?”, nie jestem gotów tego rozwiązać. Potrzebuję diagnozy. Poprawka będzie następna. Właśnie od tego zaczyna się czteroetapowy cykl.

Studium przypadku: 8 wycofanych commitów w godzinę#

Konkretna sytuacja z kwietnia 2026 roku. Pracowałem nad uwierzytelnianiem za pomocą magic linków w src/lib/auth/. Objaw: tokeny były walidowane, ale sesja nie była zapisywana. Użytkownik klika link w e-mailu, trafia na stronę, a pięć sekund później zostaje odesłany z powrotem do /login.

Otworzyłem Claude Code i wpisałem: „Sesja nie jest zapisywana po magic linku; sprawdź src/lib/auth/ i napraw to”. Claude zadał trzy pytania doprecyzowujące, po czym od razu przygotował plan. Napisał: „Zaktualizuję callback handler, przepiszę serializator JWT, dodam jawny zapis do Redis i naprawię race condition w middleware”. Brzmiało wiarygodnie. Zatwierdziłem plan.

Osiemnaście minut później miałem diff obejmujący 14 plików. Magic link nadal nie działał. Ale teraz nie działał też refresh token, logowanie hasłem było zepsute, a na trasie płatności pojawił się dziwny błąd 500. Testy nie przechodziły. Zacząłem wycofywać zmiany.

Wycofałem 8 commitów poleceniem git reset --hard origin/main. Godzina pracy poszła na marne. Jeśli chcesz dowiedzieć się, jak prawidłowo wycofywać zmiany bez utraty czegoś przydatnego, opisałem to osobno w przewodniku po odwracaniu zmian w Claude Code.

Usiadłem i porządnie zbadałem problem. Otworzyłem src/lib/auth/magic-link.ts:42, sam przeczytałem kod, otworzyłem logi i sprawdziłem Redis. Po dwudziestu minutach znalazłem przyczynę. Problem tkwił w jednej linijce: w nagłówku set-cookie brakowało atrybutu SameSite=lax, przez co Safari odrzucało cookie podczas przekierowania z domeny e-mailowej z powrotem na stronę. Żadnego JWT, Redis ani middleware. Jedna linijka.

Kiedy poprosiłem Claude o naprawienie problemu, model nawet nie zajrzał do logów przeglądarki. Nie miał kontekstu dotyczącego Safari. Zbudował hipotezę na podstawie schematu „sesja się nie zapisuje = problem z serializacją”, bo to najczęstsza odpowiedź w danych treningowych. Uległy model zaproponował rozwiązanie statystycznie wiarygodne, ale niezwiązane z moim zadaniem.

Zapisałem tę lekcję jako zasadę: nigdy nie pytaj „Jak to naprawić?”. Zawsze pytaj: „Ustal fakty”. Pozostało tylko sformalizować to jako działający cykl.

Skąd bierze się uległość: Opus 4.8 po premierze i maj 2026#

W kwietniu Anthropic osobno zbadał w inżynieryjnym postmortem, jak błąd cache w Claude Code sprawiał, że model „zapominał” swoje rozumowanie między turami.

Gdy model zapomina ciąg swojego rozumowania, łatwiej mu „zgadywać” odpowiedź na podstawie wzorca — innymi słowy, staje się jeszcze bardziej uległy.

Co zrobić w związku z premierą wersji 4.8? Nie wybieraj „łatwiejszego” modelu. Nie wracaj do wersji 4.7. Dostosuj prompty do faktów: model chętniej się zgadza, więc mocniej podkreślaj konieczność „ustalenia faktów”. Jeśli nie wiesz jeszcze dokładnie, co zmieniło się wewnątrz Opus 4.8, szczegółowo porównałem go w recenzji Opus 4.8 w Claude Code.

Kiedy 4 kroki są potrzebne, a kiedy to strata czasu#

Konkretne przykłady. Poprawianie tekstu w powitalnym e-mailu: zrób to bezpośrednio. Dodanie nowego przycisku CTA na stronie: Plan Mode bez cyklu. Migracja projektu z MySQL do Postgres: konieczny czteroetapowy cykl. Dziwny błąd 500 na produkcji, którego nie da się odtworzyć lokalnie: czteroetapowy cykl z dodatkowym krokiem „zerowym”: „najpierw zbudujmy minimalny przykład pozwalający odtworzyć problem”.

Częstym błędem przy korzystaniu z cyklu jest stosowanie go do błahych zadań. Spowalnia to pracę i szybko zniechęca do tej metody. Cykl jest potrzebny wtedy, gdy koszt błędu przewyższa koszt 15 minut planowania.

Zanim wdrożysz ten cykl, pamiętaj, że wszystkie cztery prompty działają w ramach jednej sesji Plan Mode. Jeśli jeszcze nie korzystałeś z tego trybu, najpierw przeczytaj przewodnik po Plan Mode w Claude Code, a potem wróć.

Krok 1. Zabroń proponowania rozwiązań — każ Claude ustalić fakty#

To najważniejszy krok. Blokuje pierwszy odruch: „oto rozwiązanie”. Prompt:

Napotkałem następujący problem: [symptom].

Twoim zadaniem jest teraz ustalenie faktów. Zabronione są wszelkie rozwiązania, pomysły i porady. Zajmij się wyłącznie:
- tym, co obserwuję (dokładnym brzmieniem objawu)
- krokami pozwalającymi odtworzyć problem (minimalnym scenariuszem)
- dostępnymi danymi (logami, wersjami, środowiskiem)
- brakującymi danymi (tym, co trzeba zebrać)

Bezwzględny warunek zatrzymania: nie proponuj rozwiązań, tylko zapisz diagnozę. Jeśli chcesz coś zasugerować, sformułuj to jako pytanie do mnie.

Co to daje? Gdy rozwiązania są wyraźnie zabronione, Claude nie może iść na skróty. Musi wypełnić cztery pola: co widzę, jak odtworzyć problem, co wiem i czego nie wiem. Ostatnie pole jest najcenniejsze. Często okazuje się, że „nie znam wersji biblioteki, zawartości logów ani tego, czy objaw występuje na produkcji”. To punkt wyjścia do następnego kroku.

Pułapka w Kroku 1. Jeśli objaw zostanie opisany zbyt ogólnikowo („uwierzytelnianie nie działa”), Claude nadal może zacząć zgadywać. Rozwiązanie znajduje się w samym prompcie: opisz dokładny objaw jednym zdaniem i podaj minimalny scenariusz obejmujący trzy kroki. Jeśli nie potrafisz tego zrobić, oznacza to, że nie rozumiesz jeszcze dokładnie, co jest zepsute, a odpowiedź Claude i tak będzie bezużyteczna.

Krok 2. Precedensy z internetu zamiast halucynacji z pamięci#

To blokuje drugi odruch: „wymyśl rozwiązanie z pamięci”. Prompt:

Teraz, gdy diagnoza jest ustalona, znajdź w internecie przykłady rozwiązania podobnych problemów.

Co najmniej 3 różne podejścia. Dla każdego podaj:
- link do źródła pierwotnego (issue, artykułu, dokumentacji)
- krótki opis podejścia
- zalety i wady w naszej sytuacji
- znane pułapki

Zabronione są linki oparte na własnej wiedzy bez potwierdzenia ich zawartości. Jeśli nie możesz znaleźć precedensu, powiedz to wprost.

Efekt w praktyce. Claude szuka w sieci i przynosi sprawdzone podejścia. Pojawiają się linki do GitHub issues i dokumentacji. Jeśli Claude nie może znaleźć precedensów, to sygnał, że zadanie jest nietypowe albo objaw został opisany nieprawidłowo. Wróć do Kroku 1.

Gdzie to zawodzi. Claude może podać link, który nie istnieje. To halucynacja w rodzaju „oto issue numer 4291 w repozytorium X”, choć issue 4291 dotyczy czegoś innego. Rozwiąż ten problem, dodając w CLAUDE.md wyraźną zasadę: „przed zacytowaniem zawsze otwórz link za pomocą WebFetch”. Szczegóły znajdziesz w przewodniku po prawidłowej konfiguracji CLAUDE.md.

Krok 3. Szczegółowy plan w plans/ z przewidzianymi ryzykami#

Plan Mode działa teraz zgodnie z przeznaczeniem. Prompt:

Wybierz najlepszą opcję z Kroku 2 i przygotuj szczegółowy plan w pliku plans/YYYY-MM-DD-fix-[name].md:

- które konkretne pliki zmienimy (pełne ścieżki i numery wierszy)
- co dodamy, a co usuniemy
- jakie testy napiszemy i które istniejące testy muszą przejść
- ryzyka w perspektywie dwóch lub trzech kolejnych kroków (co może się zepsuć dla użytkowników)
- plan wycofania zmian na wypadek problemów

Każdy krok zapisz jako pole wyboru [ ]. Plik musi mieścić się na jednym ekranie.
Jeśli plan ma więcej niż 200 wierszy, podziel go na etapy.

Rezultat. Plan staje się artefaktem, a nie tymczasową notatką na czacie. Możesz przeczytać go za dwa tygodnie, przekazać innemu agentowi albo wykorzystać jako warunek polecenia /goal. Plik planu przetrwa rozmowę w Claude Code.

Najważniejsza część to ryzyka w perspektywie dwóch lub trzech kolejnych kroków. Blokuje ona inny wzorzec uległości: optymistyczny plan bez uwzględnienia skutków ubocznych. Gdy każesz Claude wyraźnie wymienić ryzyka, model dostrzega rzeczy, które w zwykłym planie mógłby przemilczeć.

Krok 4. Samodzielnie sprawdź plan — wychwyć uległe założenia#

Ostatni filtr. Prompt:

Teraz przeprowadź obowiązkową samodzielną kontrolę. Uczciwie przeczytaj ponownie swój plan.

Czy są w nim rzeczy, które wymyśliłeś i których nie potwierdziłeś za pomocą:
- przeczytanego kodu;
- dokumentacji zacytowanej w Kroku 2;
- precedensu z Kroku 2?

Jeśli tak, wyraźnie je wskaż, popraw albo usuń.

Sprawdź też:
- czy plan wspomina o bibliotekach, których jeszcze nie zainstalowano i których nie ma w package.json;
- czy wspomina o zmiennych środowiskowych, których nie podałem;
- czy kroki planu opisano ogólnikowo zamiast konkretnie.

Co to daje? Claude musi ponownie sprawdzić własne rozumowanie. W próbie autora obejmującej około 50 cykli co najmniej dwa lub trzy punkty planu poprawiono właśnie w Kroku 4. To miejsca, w których uległy model próbował przemknąć przez Krok 3, a Krok 4 je wychwytuje.

Po czterech krokach plan jest gotowy do zatwierdzenia. Możesz przejść do implementacji bez obaw: „A co, jeśli będę musiał wycofać 8 commitów?”

Dlaczego dokładnie 4 kroki, a nie 2 albo 7?#

Oto uzasadnienie oparte na metodzie, którą Anthropic opisuje w oficjalnej dokumentacji Claude.

Dokumentacja zaleca czterofazowy przepływ pracy: Explore, Plan, Implement, Commit.

Mój czteroetapowy cykl to specjalizacja fazy Plan mająca przeciwdziałać uległości. Z czterech faz Anthropic jedną rozwijam w cztery mikroetapy: zakaz proponowania rozwiązań, szukanie precedensów, pisanie planu i samodzielną kontrolę. Powstaje szczegółowy plan, który następnie trafia do faz Implement i Commit.

Oto co się psuje, jeśli pominiesz którykolwiek z czterech kroków:

Tabela jasno pokazuje, że każdy krok blokuje własną klasę błędów. Potrzebujesz wszystkich czterech, bo każdy wychwytuje inną kategorię. Jeśli zadanie wydaje się na tyle małe, że wystarczą dwa kroki, to naprawdę jest małe — i w ogóle nie potrzebujesz Plan Mode.

Jak współdziałają plans/, polecenie /goal i kolejne kroki#

Cykl działa w ramach systemu, który obejmuje:

1. Włączony Plan Mode (dwukrotne naciśnięcie Shift+Tab w Claude Code).
2. Folder plans/ w repozytorium, w którym zapisujesz plany.
3. Opcjonalnie polecenie /goal do autonomicznej realizacji długich planów.

Najpierw folder plans/. Po Kroku 3 otrzymujesz plik plans/2026-05-27-fix-magic-link.md zawierający etapy i pola wyboru. To artefakt. Otwórz go tydzień później, a przypomnisz sobie, dlaczego wybrałeś to podejście. Za trzy miesiące trafisz na podobne zadanie i ponownie je wykorzystasz. Za sześć miesięcy pokażesz je współpracownikowi i oszczędzisz mu dwóch tygodni wdrażania się. Folder plans/ jest częścią koncepcji „drugiego mózgu” w Claude Code.

Teraz /goal. Po ukończeniu czterech kroków i zatwierdzeniu planu wyjdź z Plan Mode i wpisz:

/goal wykonaj wszystkie etapy z plans/2026-05-27-fix-magic-link.md, aż wszystkie testy w test/auth przejdą, albo zatrzymaj się po 30 turach

Dla lokalnej sesji Claude Code pozostaw działający terminal, komputer bez uśpienia i dostępne połączenie sieciowe. Nie zamykaj laptopa, chyba że jawnie skonfigurowano obsługiwany sposób pracy bez usypiania. Po powrocie sprawdź historię: może pokazać ukończenie, limit tur, pytanie o uprawnienia lub błąd. Cel nie gwarantuje postępu podczas snu komputera. Bez czteroetapowego cyklu /goal zużywa tokeny na bezużyteczne iteracje. Z cyklem /goal realizuje gotowy plan aż do zaliczenia testów.

Co dalej? Jeśli dopiero zaczynasz korzystać z Claude Code, wypróbuj ten cykl przy najbliższym nietrywialnym zadaniu. Nie przy literówce. Wybierz coś, co dotyka ponad 3 plików albo ma zachowanie, którego w pełni nie rozumiesz. Skopiuj powyższe prompty i uzupełnij własnymi szczegółami. Zobaczysz, jak zmieni się częstotliwość wycofywania zmian.

Jeśli już korzystasz z Plan Mode, dodaj folder plans/ do repozytorium. Ustal format nazwy pliku: YYYY-MM-DD-feature-name.md. Po miesiącu będziesz mieć 20–30 plików, a po sześciu miesiącach ponad sto. Tak powstaje drugi mózg projektu — żywa historia decyzji. Jeśli chcesz lepiej zarządzać kontekstem przed przygotowaniem promptu, opisałem context engineering w Claude Code jako osobną dziedzinę.

Jeśli korzystasz już zarówno z Plan Mode, jak i plans/, wypróbuj /goal przy jednym autonomicznym zadaniu. Wybierz takie, które normalnie zajęłoby ci ręcznie 30–40 minut. Przejdź przez cztery kroki, zapisz plan, uruchom /goal i pozostaw lokalny terminal oraz komputer aktywne. Jeśli praca ma trwać przy wyłączonym komputerze, najpierw użyj jawnie skonfigurowanego środowiska zdalnego lub chmurowego i sprawdź, że zadanie działa właśnie tam.