# Dlaczego narzędzia AI frustrują: praktyczna mapa nauki

> Autorska metafora czterech etapów nauki, praktyczne oznaki sposobu pracy i eksperyment z trzema filarami dla postępu w jednym projekcie wspieranym przez AI.

Source: https://ailoot.ai/blog/pl/why-you-quit-ai-tools/
Canonical: https://ailoot.ai/blog/pl/why-you-quit-ai-tools/
Language: pl
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-198
Revision: sha256-3810f63cd06a2950aa74295ad5c6c1b905c9f48444c9607a2fd52c67b9913e79


<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Artykuł wykorzystuje popularną czteroetapową krzywą uczenia się jako autorską metaforę pracy z Claude Code lub Cursor. Początkowy entuzjazm może ustąpić frustracji, potem bardziej świadomej praktyce i stabilniejszemu sposobowi pracy. Etapy służą refleksji; nie są potwierdzoną sekwencją dla każdego, prognozą rezygnacji ani testem diagnostycznym. Poniższe listy i trzy filary to praktyczne propozycje do wypróbowania w jednym projekcie.

</div>

Więcej wskazówek dotyczących pracy z Ailoot znajdziesz w [dokumentacji](https://ailoot.ai/docs/).



## Metafora nauki, a nie uniwersalne prawo psychologiczne

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Efekt Dunninga-Krugera dotyczy ograniczeń oceny własnych wyników. Znany obraz szczytu, doliny, zbocza i płaskowyżu jest popularną ilustracją, a nie dowodem, że każdy uczący się przechodzi cztery etapy w tej kolejności. Używam go tu tylko do uporządkowania przykładów oczekiwań, frustracji i praktyki.

</div>

Praktyczne pytanie w tym artykule jest węższe niż diagnoza psychologiczna: czy oczekiwania odpowiadają sprawdzalnym wynikom? Porównaj to, co zamierzałeś ukończyć, z tym, co faktycznie działa, i na tej podstawie dopasuj następne zadanie.

Nie mierz umiejętności samą pewnością siebie; obejrzyj rzeczywisty wynik i sprawdzenia, które go potwierdzają.

Od tamtej pory krzywa Dunninga-Krugera stała się popularną ilustracją obejmującą cztery etapy. Najpierw pewność siebie szybuje ku „Szczytowi Góry Głupoty”. Potem spada do „Doliny Rozpaczy”. Następnie powoli wspina się „Zboczem Oświecenia” w stronę „Płaskowyżu Stabilności”.

Krzywa jest metaforą tego artykułu. Żadne badanie jego czytelników nie ustala odsetka rezygnacji, stałego czasu nauki ani uniwersalnej drogi przez te etykiety.

## 4 etapy vibe codingu — na którym jesteś?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Poniższe cztery etykiety opisują sytuacje, które uczący się może rozpoznać; nie są etapami obowiązkowymi dla każdego użytkownika Claude Code. Szczyt Góry Głupoty: czytasz artykuł o agentach i myślisz, że jesteś specjalistą od vibe codingu. Dolina Rozpaczy: zaczynasz zgłębiać MCP i Skills, po czym orientujesz się, że niczego nie rozumiałeś. Zbocze Oświecenia: zasady działają, a metodologia przynosi rezultaty. Płaskowyż Stabilności: twoja wiedza dorównuje pewności siebie i systematycznie tworzysz produkty. Każdy etap ma charakterystyczne myśli i zewnętrzne zachowania.

</div>

Każdy etap można rozpoznać po typowych myślach i zachowaniach. Oto mapa.

### Etap 1 — Szczyt Góry Głupoty

Czytasz artykuł o Claude Code. Może oglądasz film. Wszystko wydaje się jasne: zainstalować narzędzie, napisać prompt, dostać kod. Autorzy artykułów opisują, jak „zbudowali SaaS w jeden wieczór”. Ty też chcesz zrobić to w jeden wieczór.

Myśli, które chodzą ci po głowie:

- „Chyba rozumiem, o co chodzi”.
- „To po prostu czat, tylko mądrzejszy”.
- „Jestem przedsiębiorcą, nie potrzebuję programistów”.
- „Opanuję to w miesiąc i wyjadę do Dubaju”.

Zachowanie:

- Pobierasz i instalujesz Claude Code.
- Wpisujesz na czacie „Zbuduj mi aplikację do rezerwacji”.
- Dostajesz kod, który nie chce się uruchomić.
- Myślisz, że to wina złego modelu, i kupujesz subskrypcję Max.

Na tym etapie przeceniasz zarówno narzędzie, jak i siebie. To jeden z możliwych punktów startowych. Jeśli oczekiwania pozostają oderwane od działającego wyniku, frustracja może rosnąć; mały projekt i jawne sprawdzenia dają konkretny materiał do nauki.

Do praktycznej samooceny poproś kogoś innego o sprawdzenie tego samego wyniku według jawnych kryteriów. Pewny opis siebie jako „eksperta AI” nie potwierdza jakości wygenerowanego rezultatu.

Początkowe pewne wrażenie traktuj jako hipotezę. Uruchom kod, sprawdź wynik i pozwól, aby zmienił ocenę Twoich możliwości.

### Etap 2 — Dolina Rozpaczy

Zagłębiasz się w temat. Czytasz o MCP i próbujesz podłączyć serwer. Pobierasz gotowy Skill i próbujesz zrozumieć, jak działa. Uruchamiasz Plan Mode — agent pisze plan, a potem zbacza z kursu przy trzecim kroku. Otwierasz `~/.claude/` — widzisz 12 folderów i nie rozumiesz, do czego służy którykolwiek z nich.

Myśli, które chodzą ci po głowie:

- „Nie umiem zrobić absolutnie nic”.
- „Wszyscy w mediach społecznościowych po prostu kłamią”.
- „To, co działa u innych, u mnie nie działa”.
- „Może zabieram się za to za wcześnie”.
- „Wydałem $200 na tokeny — i co z tego mam?”.

Zachowanie:

- Otwierasz jednocześnie 20 kart z dokumentacją.
- Każdy czat zaczynasz od „zapomnij poprzedni kontekst”.
- Przeglądasz fora i czytasz wątki takie jak „X zepsuł mój projekt”.
- Porównujesz Claude z Cursor, Cursor z Codex, Codex z Cline. Myślisz, że masz niewłaściwe narzędzie.
- Rano siadasz do kodowania, ale do pory lunchu już przewijasz aktualności.

Ta sytuacja może frustrować. Artykuł nie podaje zmierzonego odsetka rezygnacji; użyj poniższych oznak do wskazania jednej zmiany wartej wypróbowania.

### Etap 3 — Zbocze Oświecenia

Zatrzymujesz się. Zwolniasz. Przestajesz rzucać się na każdą nowość. Piszesz swój pierwszy plik CLAUDE.md i umieszczasz go w projekcie. Tworzysz folder `business/` i dodajesz do niego opis produktu, ceny oraz odbiorców. Dziesięć razy używasz `/compact` i w końcu rozumiesz, które elementy kontekstu powinien zachować. Tworzysz swój pierwszy Skill — do konkretnego zadania, o długości 30 wierszy.

Myśli, które chodzą ci po głowie:

- „Aha, tak to działa”.
- „Udało mi się dziś zrobić coś, czego nie potrafiłem tydzień temu”.
- „Chyba rozumiem, czym różni się `business/` od `ai-clone/`”.
- „Mam już gotowy prompt do zadania X”.

Zachowanie:

- Przed każdym nowym zadaniem wracasz do Plan Mode.
- Zanim cokolwiek napiszesz do Claude, pytasz siebie: „Czy to jest w moim CLAUDE.md?”.
- Szukasz kolejnej reguły metodologicznej; nowe narzędzie przestaje przyciągać twoją uwagę.
- Pomagasz innym na czatach: „Też się na tym zaciąłem — spróbuj zrobić to tak”.

### Etap 4 — Płaskowyż Stabilności

To nie moment, w którym wszystko staje się łatwe. To moment, w którym twoja wiedza w końcu dorównuje pewności siebie.

Myśli, które chodzą ci po głowie:

- „Wiem, czego nie wiem”.
- „To zadanie zajmie mi trzy godziny; już je robiłem”.
- „Przyda się nowy Skill — zaraz go przygotuję”.
- „Jeśli Claude zboczy z planu, znam trzy możliwe przyczyny”.

Zachowanie:

- Systematycznie tworzysz produkty — jeden w wieczór, kolejny w weekend.
- Masz własny folder Skills, własnych subagentów i własny folder `business/` dla każdego projektu.
- Wybiórczo zatrudniasz wykonawców do zadań, z którymi zasadniczo nie możesz poradzić sobie samodzielnie.
- Rzadko korzystasz z cudzych samouczków wideo — głównie po to, by znaleźć nowe pomysły, a nie uczyć się podstaw.

Lista kontrolna do samooceny — na którym etapie jesteś teraz?

- Jeśli nie próbowałeś jeszcze Claude Code i myślisz „O, zrobię to w jeden wieczór”, jesteś na etapie 1.
- Jeśli już próbowałeś, otworzyłeś MCP, próbowałeś czytać Skills i myślisz „Po co ja się w to pakowałem?”, jesteś na etapie 2.
- Jeśli utworzyłeś CLAUDE.md i widzisz, jak naprawdę zmienia on zachowanie Claude, jesteś na etapie 3.
- Jeśli systematycznie tworzysz produkty i dokładnie wiesz, jakiego narzędzia użyć w danej sytuacji, jesteś na etapie 4.

## 7 oznak, że właśnie jesteś w Dolinie Rozpaczy

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Dolinę Rozpaczy można rozpoznać po siedmiu oznakach zachowania — od nieustannego zmieniania narzędzi po stwierdzenie „to po prostu nie dla mnie”. Używaj siedmiu oznak jako pytań do refleksji, nie punktowej diagnozy. Wybierz tę, która najbardziej przeszkadza w ukończeniu bieżącego zadania, i wypróbuj odpowiadającą zmianę.

</div>

Dolina nie pojawia się nagle. Wkrada się stopniowo. Oto jej oznaki:

**1. Porównujesz narzędzia zamiast coś budować.** Otwierasz kartę „Cursor vs Claude Code”. Kończysz czytać. Otwierasz „Cline vs Cursor”. Potem „Codex vs cała reszta”. Z każdym porównaniem myślisz: „Może szukam w niewłaściwym miejscu”. Pod koniec dnia nie napisałeś ani jednej linijki kodu, a spędziłeś nad tym cztery godziny.

**2. Każdy nowy czat zaczynasz od „zapomnij wszystko, co było wcześniej”.** Nie masz CLAUDE.md, nie opanowałeś `/compact` i nie rozumiesz, czym jest okno kontekstu. Każda sesja zaczyna się od pustej kartki. Tydzień później zauważysz, że po raz piętnasty tłumaczysz Claude to samo.

**3. Zbierasz prompty, ale ich nie używasz.** Utworzyłeś folder „Claude Code Prompts” w Notion. Jest w nim 47 zakładek. Żadnego promptu nie użyłeś dwa razy. Za każdym razem myślisz: „Ten na pewno jest tym, czego potrzebuję”.

**4. Myślisz, że inni „odnoszą sukces, bo mają znajomości”.** Otwierasz media społecznościowe i widzisz, jak ktoś wdraża pierwszą wersję produktu w weekend. Myślisz: „Mają zespół. Mają znajomości. Ja tego nie potrafię”. Nie bierzesz pod uwagę, że oni są na etapie czwartym, a ty na drugim.

**5. Porzucasz projekt trzeciego dnia.** Każdy nowy projekt zaczyna się od ekscytacji („To będzie świetne!”), a kończy trzeciego dnia. Kiedy wyzwanie zmienia się z „powitania na czacie” na „przetworzenie płatności”, odchodzisz. Trudne zadania przerażają.

**6. Szukasz odpowiedzi w ChatGPT, bo Claude sobie nie poradził.** Claude udzielił złej odpowiedzi, więc otwierasz ChatGPT. ChatGPT udzielił złej odpowiedzi, więc otwierasz Gemini. Nie przychodzi ci do głowy, że prośba była źle sformułowana — zawsze winisz narzędzie.

**7. Mówisz sobie: „To po prostu nie dla mnie”.** To najbardziej podstępna oznaka. Brzmi jak obronna puenta, po której człowiek odchodzi. Ta myśl może odzwierciedlać frustrację zamiast niezdolności do nauki. „Dolina” jest tutaj metaforą; nie ma zmierzonego procentu ani stałej osi czasu pokazującej, kto tak się czuje i co nastąpi później.

Jeśli pasuje kilka oznak, wybierz jako następny cel mały działający wynik. Zapisz przeszkodę i zmień jedną część sposobu pracy; lista nie przewiduje czasu do poprawy.



## Dlaczego ludzie rezygnują w dolinie — i dlaczego nie wynika to z lenistwa

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

W tej metaforze dolina nazywa lukę między oczekiwanym i rzeczywistym postępem. Pozornie szybkie zadanie może wymagać nieznanej konfiguracji i debugowania, a przykłady z mediów społecznościowych zniechęcać do porównań. To praktyczny opis frustracji, a nie diagnoza neurologiczna.

</div>

Frustracja narzędziem nie jest miarodajnym wskaźnikiem zdolności. Przed trwałą decyzją o narzędziu przyjrzyj się rozmiarowi zadania, brakującej wiedzy i środowisku wykonania.

Zamiast wnioskować o mechanizmie mózgu z trudnego tygodnia, zapisz obserwowalne fakty: czego próbowałeś, co zadziałało, jaki błąd zatrzymał kolejny krok i ile to trwało. Taki zapis wskazuje konkretne miejsce do poprawy.

W dolinie otrzymujesz dwa ciosy naraz. Po pierwsze, twoje postępy nie spełniają oczekiwań. Po drugie, ludzie wokół ciebie publikują rezultaty, których ty nie masz. Otwierasz media społecznościowe — ktoś wdrożył pierwszą wersję produktu, ktoś stworzył agenta, ktoś zarobił pierwsze sto dolarów dzięki Claude API. Ty od trzech tygodni nie możesz nawet połączyć bazy danych.

Śledź upływ czasu obok wrażenia szybkości. Agent może sprawiać wrażenie produktywnego, dokładając przegląd i poprawki; porównaj reprezentatywne zadanie z wcześniejszym sposobem pracy zamiast uznawać subiektywne wrażenie za zmierzoną korzyść.

Wolny postęp przy nieznanym zadaniu nie dowodzi braku zdolności. Oddziel koszt nauki od wyniku narzędzia i określ mniejszy rezultat, który możesz obejrzeć.

Bez powtarzalnego następnego kroku łatwo zmienić narzędzie lub porzucić zadanie. Poniższe trzy filary są strukturą proponowaną przez autora, nie statystycznie udowodnionym wyjaśnieniem rezygnacji.

## 3 filary — metodologia pozwalająca wydostać się z doliny

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Nowe narzędzie ani prompt nie wyciągną cię z Doliny Rozpaczy. Pomoże ci z niej wyjść dobrze uporządkowany zestaw umiejętności i metodologia pracy, pamięć projektu (CLAUDE.md i folder `business/`) oraz zarządzanie kontekstem (Plan Mode i zarządzanie oknem kontekstu). Każdy z tych elementów osobno łagodzi jeden z objawów doliny. Razem mogą ułatwić ocenę i powtarzanie procesu. Nie eliminują halucynacji ani nie zastępują sprawdzania wyniku.

</div>

Zgodnie z doświadczeniem autora opisanym w tym artykule wydostanie się z doliny zajęło trzy miesiące. W tym czasie wypróbowałem dziesiątki narzędzi. Zrozumiałem jedną rzecz: problemem nie był Claude. Problem polegał na tym, że za każdym razem zaczynałem od pustej kartki. Bez pamięci, bez zasad, bez granic.

Potem opracowałem strukturę. Nazwałem ją „trzema filarami”. Nazwa odnosi się do trzech typów elementów, na których opiera się cały przepływ pracy w Claude Code. Sprawdź na własnym zadaniu, które elementy tej struktury są potrzebne.

### Filar 1 — Umiejętności Clauda i twoja metodologia

Umiejętności to twoja wiedza ekspercka zapisana w formacie, który Claude stosuje automatycznie.

W Dolinie Rozpaczy piszesz do Claude „pomóż mi z tym zadaniem” i za każdym razem od początku wyjaśniasz swoje podejście. Filar 1 rozwiązuje ten problem: twoje metodyki znajdują się w folderze `ai-clone/` jako zestaw plików. Skill opisujący „jak zajmuję się sprawą klienta”. Skill opisujący „jak piszę post na Telegramie”. Subagent o nazwie „architekt produktu”, który myśli tak jak ty na etapie planowania.

Jak w praktyce wygląda filar 1:

- Skills — pliki z instrukcjami do konkretnych zadań (`/build-article`, `/build-reel-script`).
- Subagents — persony o różnych obszarach specjalizacji, między którymi Claude rozdziela podzadania.
- Folder `ai-clone/feedback/` — reguły wyciągnięte z błędów. Każda reguła ma format Rule - Why - How.

Szczegółowo omawiam te zagadnienia w [przewodniku po Skills, Subagents, MCP i Plugins](https://ailoot.ai/blog/pl/skills-subagents-mcp-plugins-claude-code/) — mapie, która podpowiada, czego używać i kiedy.

### Filar 2 — second brain, czyli drugi mózg

Second brain to uporządkowane repozytorium wiedzy o projekcie, do którego Claude ma bezpośredni dostęp.

W Dolinie Rozpaczy podczas każdej sesji wyjaśniasz Claude, czym jest produkt, kto jest odbiorcą i jaki jest model biznesowy. Pod koniec trzeciego tygodnia orientujesz się, że już po raz piętnasty wyjaśniasz to samo. Filar 2 rozwiązuje ten problem: porządkujesz wiedzę o projekcie w plikach obok kodu. Claude sam je odczytuje, gdy są potrzebne.

Jak w praktyce wygląda filar 2:

- `CLAUDE.md` — plik wejściowy agenta. Zawiera zasady zachowania, ścieżki i odnośniki do pozostałych materiałów.
- Folder `business/` — produkt, odbiorcy, ekonomika, cele, plany treści i konkurenci.
- Folder `plans/` — plany techniczne podzielone na etapy wraz ze statusem każdego z nich.
- Folder `retrospectives/` — wnioski z poprzednich sesji, które pozwalają uniknąć powtarzania tych samych błędów.

Pełne omówienie znajdziesz w [przewodniku po konfiguracji CLAUDE.md](https://ailoot.ai/blog/pl/claude-md-template/) i [przewodniku po second brain w Claude Code](https://ailoot.ai/blog/pl/claude-code-second-brain/).

### Filar 3 — context engineering, czyli inżynieria kontekstu

Context engineering polega na zarządzaniu tym, co trafia do okna kontekstu Claude, zanim naciśniesz Enter.

W Dolinie Rozpaczy nie rozumiesz, dlaczego Claude „zapomina” instrukcje po czterdziestu wiadomościach w czacie. Nie wiesz, po co jest `/compact`. Nie uruchamiasz Plan Mode, bo „bez tego jest szybciej”. Filar 3 rozwiązuje ten problem: świadomie wybierasz, co załadować do kontekstu. Daje to Claude bardziej przydatne dane wejściowe; nadal trzeba sprawdzać jego twierdzenia i wyniki.

Jak w praktyce wygląda filar 3:

- Plan Mode — agent najpierw pisze plan zadania, ty go zatwierdzasz, a potem agent go realizuje. Jeśli z niego nie korzystasz, pierwsza próba kończy się chaotycznym wynikiem.
- `/compact` — inteligentna kompresja historii czatu. Gdy kontekst zaczyna się zapełniać, skompresuj go i zachowaj tylko kluczowe ustalenia.
- Ustrukturyzowane prompty — zamiast „pomóż mi” napisz „oto kontekst A, oto zadanie B, zwróć wynik w formacie C”.
- Sub-agents — przekazywanie podzadań do świeżych kontekstów, aby nie przeciążać głównego kontekstu.

Omawiam te zagadnienia w [przewodniku po context engineering](https://ailoot.ai/blog/pl/context-engineering/) oraz [przewodniku po Plan Mode](https://ailoot.ai/blog/pl/claude-code-plan-mode/).

### Dlaczego trzy filary, a nie jeden

Możesz zbudować tylko second brain, a Claude będzie znał twój projekt. Ale będzie działał jak stażysta bez zasad.

Możesz zbudować tylko własne umiejętności i Claude przejmie twoją wiedzę ekspercką. Jednak bez pamięci projektu każda sesja będzie zaczynać się od zera.

Inżynieria kontekstu może poprawić wejście zadania, lecz sama nie gwarantuje płynnego przebiegu ani zachowania wiedzy. Ale wiedza nie będzie gromadzić się między zadaniami.

Dopiero połączenie wszystkich trzech elementów daje to, co nazywam „przewidywalną strukturą”. Claude pamięta twój projekt. Automatycznie stosuje twoją metodologię. Łatwiej wtedy sprawdzić, czy zachowuje wątek zadania.

Właśnie wtedy wydostajesz się z Doliny Rozpaczy.

## 7 antywzorców, które trzymają cię w dolinie

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Poniższe wzorce to przykłady używane przez autora do refleksji nad frustrującym sposobem pracy. Pracują bez CLAUDE.md, prowadzą długie rozmowy bez `/compact`, ufają pierwszej odpowiedzi i ignorują śledzenie kosztów. Każdy antywzorzec wskazuje, że próbujesz używać narzędzia, pomijając metodologię. Wybierz właściwą zmianę i oceń, czy pomaga ukończyć rzeczywiste zadanie; ta lista nie ma potwierdzonego progu zaliczenia.

</div>

Antywzorce warte sprawdzenia we własnej pracy:

**1. „Napisz mi działającą aplikację” bez CLAUDE.md.** Otwierasz nowy czat w Claude Code i od razu opisujesz zadanie. Claude nie ma kontekstu dotyczącego twojego projektu, metodologii ani preferencji. Podaje ci ogólny szablon, a ty czujesz rozczarowanie.

Co zrobić: utwórz CLAUDE.md i umieść w nim podstawowe informacje — swój stack, model biznesowy, grupę docelową i odnośniki do pozostałych plików. Każdy czat zaczyna się od tego kontekstu.

**2. Długa rozmowa bez `/compact`.** Prowadzisz sesję złożoną z 80 wiadomości. Claude już nie pamięta, co ustaliliście w wiadomości 12. Okno kontekstu jest wypchane historią bez żadnych kluczowych decyzji — samymi wahaniami. Jakość odpowiedzi spada.

Co zrobić: używaj `/compact` co 30–40 wiadomości i określaj, co należy zachować. Kontekst staje się bardziej skupiony.

**3. Ufanie pierwszej odpowiedzi.** Claude podaje rozwiązanie, a ty od razu je wdrażasz. Godzinę później odkrywasz, że zepsuło trzy inne pliki. Rezygnujesz, bo „znowu nie działa jak należy”.

Co zrobić: korzystaj z Plan Mode przy złożonych zadaniach. Najpierw plan, potem omówienie planu, a następnie jego realizacja. Dzięki temu wychwytujesz błędy na etapie planowania, a nie po pół dnia pracy.

**4. Nieuporządkowany prompt bez struktury.** Piszesz „zrób to dobrze”, oczekując, że Claude sam zrozumie, o co ci chodzi. Nie rozumie. Nie wie, co dla ciebie oznacza „dobrze”. Zgaduje.

Co zrobić: pisz prompty według struktury „kontekst - zadanie - ograniczenia - format”. To wielokrotnie zwiększa szanse na dobry rezultat już za pierwszym razem.

**5. Ignorowanie śledzenia kosztów.** Nie wiesz, ile tokenów zużywasz. Kończy się miesięczny limit, otwierasz panel i widzisz, że wydałeś $200. Zaskakuje cię to. Rezygnujesz.

Co zrobić: skonfiguruj narzędzia do śledzenia zużycia tokenów. Omówiłem je w przewodniku po licznikach tokenów. Gdy widzisz wydatki w czasie rzeczywistym, przestajesz bezsensownie zużywać tokeny.

**6. Niekończące się poszukiwania „właściwego narzędzia”.** Pojawia się Cursor — przechodzisz na Cursor. Pojawia się Cline — próbujesz Cline. Codex dostaje aktualizację — wracasz do Codex. Co dwa tygodnie używasz nowego narzędzia i za każdym razem zaczynasz od nowa. Nigdy nie osiągasz poziomu, na którym narzędzie zaczyna działać na twoją korzyść.

Co zrobić: wybierz jedno narzędzie. Używaj go przez trzy miesiące. Nie zmieniaj go przy pierwszym pretekście. Porównania sprawdzam tylko wtedy, gdy moje narzędzie zasadniczo czegoś nie potrafi.

**7. „Nie mam czasu na czytanie o metodologii”.** Myślisz, że narzędzie powinno działać bez przygotowania. Że pisanie promptów to wrodzona umiejętność. Że CLAUDE.md to „dodatkowa warstwa”. W rezultacie w drugim miesiącu nadal robisz coś, co z metodologią można było skończyć w tydzień.

Co zrobić: zaakceptuj, że Claude Code wymaga nauki tak jak każde profesjonalne narzędzie. Uczyć się go należy przez metodologię — intuicja tu nie działa.

Powiązany temat: [przewodnik po sycophancy w Claude Code](https://ailoot.ai/blog/pl/claude-code-sycophancy-prompts/) wyjaśnia, jak uniknąć największego nieporozumienia w dolinie — przekonania, że Claude ma rację za każdym razem, gdy zgadza się z twoim pomysłem.

## 5 oznak, że jesteś na Zboczu Oświecenia — jak poznać, że już wyszedłeś z doliny

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Zbocze Oświecenia można rozpoznać po kilku spokojnych zmianach, a nie po euforii. Masz CLAUDE.md dłuższy niż 200 wierszy. Wracasz do Plan Mode bez przypominania. Znasz swoje Skills na pamięć. Tempo pracy się ustabilizowało — wiesz już, ile trwa typowe zadanie. Inni zaczynają prosić cię o pomoc, bo osiągasz rezultaty.

</div>

Oto pięć oznak, że jesteś na etapie trzecim:

**1. Masz CLAUDE.md dłuższy niż 200 wierszy i świadomie go aktualizujesz.** Nie skopiowałeś go z szablonu — samodzielnie go rozbudowałeś. Znasz każdą sekcję i wiesz, dlaczego się tam znajduje. Gdy zauważasz nowy wzorzec, dodajesz regułę.

**2. Przed każdym niestandardowym zadaniem włączasz Plan Mode.** Bez przypominania i nie z obowiązku, lecz dlatego, że rozumiesz, iż bez planu stracisz godzinę i uzyskasz niewłaściwy rezultat. Przestał być „dodatkowym krokiem”, a stał się odruchem.

**3. Masz własny katalog Skills i Subagents.** Nie pobrany z GitHuba — własny, do konkretnych zadań. Kiedy nowe zadanie przypomina wcześniejsze, przypominasz sobie o swoim Skill zamiast pisać prompt od zera.

**4. Twoje tempo się ustabilizowało.** Wiesz już: „Takie zadanie zajmie mi 3 godziny”. Nie myślisz „o, to pójdzie szybko” ani „o, to zajmie wieczność”. Realistycznie szacujesz czas. To praktyczna oznaka lepszego dopasowania szacunków do wyników, a nie diagnoza efektu psychologicznego.

**5. Ludzie zaczynają zwracać się do ciebie po pomoc.** Ktoś na czacie zadaje pytanie o MCP — odpowiadasz konkretnym przykładem: „Mnie przydarzyło się to”. Ktoś pyta o Plan Mode — pokazujesz swój przykład. To skutek uboczny opanowania metodologii: osoby w dolinie rozpoznają w twoim doświadczeniu własne przeżycia i przychodzą do ciebie.

Używaj tych oznak do refleksji nad ostatnim postępem, nie przyznawania sobie wyniku ani prognozy dotarcia na płaskowyż. Ponownie sprawdzaj, czy szacunki i działające wyniki stają się z czasem bardziej spójne.

Na płaskowyżu zmienia się rola człowieka w strukturze agentów.

Taki jest rezultat drogi z doliny: nie „uczysz się już pisać promptów”. Zarządzasz strukturą agentów, projektujesz proces i stoisz na czele.

## Co zrobić TERAZ, jeśli tracisz zapał

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Key takeaways">

Najważniejsze wnioski

Jeśli po przeczytaniu tego artykułu zorientowałeś się, że utknąłeś w dolinie, nie zamykaj karty. Zrób trzy rzeczy: nazwij obecną trudność na głos (refleksja), zwolnij (jeden projekt, na początek jeden filar) i wprowadź strukturę (własną albo cudzą). Wypróbuj uporządkowany sposób pracy, zanim uznasz nowe narzędzie za rozwiązanie. Zachowaj go tylko przy poprawie wyników; ani ta metafora, ani harmonogram nie gwarantują postępu.

</div>

Oto trzy kroki do wypróbowania przy następnym zadaniu.

**Krok 1 — nazwij na głos swój etap.** Powiedz sobie: „Jestem w Dolinie Rozpaczy. To frustrująca część mojego obecnego sposobu pracy. Mogę nazwać konkretną przeszkodę i wybrać mniejszy następny krok”. Gdy nazwiesz etap, przestaje być „moją osobistą katastrofą”, a staje się „moim obecnym położeniem na krzywej”.

**Krok 2 — zwolnij.** Wybierz JEDEN projekt. Nie dwa ani trzy — jeden. Wybierz JEDEN z trzech filarów — ten, który rozwiąże najwięcej problemów w tym projekcie. Jeśli projekt jest nowy i nie ma żadnego kontekstu, wybierz second brain (CLAUDE.md). Jeśli projekt już istnieje, ale Claude nie zachowuje się „jak ty”, wybierz własne umiejętności Claude (Skills). Jeśli zadania są długie, a kontekst się zapełnia, wybierz context engineering (Plan Mode + `/compact`).

Jeden projekt, jeden filar, dwa tygodnie. Nie próbuj zbudować wszystkiego w weekend — to z powrotem zaprowadzi cię do doliny.

**Krok 3 — wprowadź strukturę.** Możesz samodzielnie opracować metodologię. Zgodnie z doświadczeniem autora opisanym w tym artykule zajęło to od trzech do sześciu miesięcy.



<div class="section" role="doc-bibliography" aria-label="Sources">

### Źródła

- [Anthropic Engineering, skuteczne zarządzanie kontekstem agentów AI (2025)](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - dlaczego okno kontekstu ulega degradacji i dlaczego trzeba nim zarządzać.
- [Dokumentacja Claude Code — Memory](https://code.claude.com/docs/en/memory) - oficjalna hierarchia pamięci Claude Code.


</div>





Aby dalej korzystać z modeli, przejdź do [Ailoot](https://ailoot.ai/).

## Pytania i odpowiedzi

### Czy cztery etapy przewidują moją rezygnację po miesiącu?

Nie. Artykuł używa popularnej krzywej jako metafory, bez zmierzonego odsetka rezygnacji ani uniwersalnego czasu. Użyj przykładów do wskazania konkretnej przeszkody, nie do diagnozowania siebie ani przewidywania poprawy.

### Jaki praktyczny krok wykonać, gdy ciągle zmieniam narzędzia AI?

Wybierz jeden projekt i mały sprawdzalny wynik. Popraw najbardziej problematyczny element — instrukcje projektu, powtarzalną procedurę lub zarządzanie kontekstem — i porównaj rzeczywisty wynik oraz czas z poprzednią próbą.


## Ailoot · Firma i jej portfel projektów

Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI.

Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach.

Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.
