Kiedy budowniczy się łamie: zmęczenie AI od środka
Kiedy budowniczy się łamie
Siddhant Khare buduje infrastrukturę agentów AI na co dzień. Utrzymuje OpenFGA w CNCF, dostarcza serwery MCP, stworzył narzędzia do autoryzacji agentów i deduplikacji kontekstu. Nie jest przypadkowym użytkownikiem. On buduje rury, przez które to wszystko płynie.
Wyprodukował więcej kodu niż kiedykolwiek. Czuł się bardziej wyczerpany niż kiedykolwiek.
W lutym 2026 opisał to publicznie. Tytuł: „AI Fatigue Is Real and Nobody Talks About It.” Szesnaście minut inżyniera infrastruktury, który precyzyjnie opisuje, jak narzędzia, które sam buduje, go złamały.
Miesiąc później deweloper o nicku aziz_sunderji napisał na Hacker News: „Myślę, że jestem uzależniony od Claude Code. Jedyne co chcę robić cały dzień to eksplorować pomysły z danymi. Martwię się, że za dziesięć lat spojrzę wstecz i zakwestionuję, jak spędziłem ten czas.”
Trzydzieści osób odpowiedziało. Większość rozpoznała wzorzec.
Paradoks produktywności
Kluczowa obserwacja Khare’a jest nieintuicyjna. Zadania przyspieszyły. Problemy, które zabierały trzy godziny, zajmowały teraz 45 minut. Ale nie zyskał więcej odpoczynku. Zyskał więcej problemów.
„AI redukuje koszt produkcji, ale zwiększa koszt koordynacji, przeglądu i podejmowania decyzji. I te koszty spadają w całości na człowieka.”
Przed AI spędzał całe dni nad pojedynczymi problemami projektowymi z głębokim skupieniem. Po AI — sześć problemów dziennie w ciągłym przeskakiwaniu kontekstów. Wąskie gardło się przesunęło. Nie zmalało.
Gorzej: zmienił się typ pracy. Tworzenie zamieniło się w ewaluację. A te dwa rodzaje aktywności czują się zupełnie inaczej od wewnątrz. Generowanie daje flow. Ewaluacja daje zmęczenie decyzyjne. Możesz generować godzinami i czuć się naładowany. Możesz ewaluować godzinami i czuć pustkę.
Khare mówi wprost: kod generowany przez AI wymaga dokładniejszego przeglądu niż kod ludzki, bo wzorce są nieprzewidywalne. Nie możesz go przeskanować tak, jak skanujesz kod kolegi, którego nawyki znasz. Każdy review wymaga pełnej uwagi.
Sześć problemów dziennie. Każdy wymagający pełnej uwagi. To nie produktywność. To przepis na to, co badacze z BCG nazwali „AI brain fry”.
„Nie jestem pewien, czy chcę wrócić”
Na Hacker News odpowiedzi podzieliły się na dwa obozy. Żaden nie uspokaja.
Obóz pierwszy: normalizacja.
„Może uzależnienie nie jest od Claude’a, tylko od produktywności, a Claude jest tylko enablerem. (I może ta produktywność jest iluzją, czas pokaże.)”
— saulpw
„Żałuję, że moje inne uzależnienia nie kosztują tylko 200 dolarów miesięcznie.”
— schmookeeg
Obóz drugi: rozpoznanie.
„Jestem deweloperem z ponad 15-letnim stażem i nie jestem pewien, czy chciałbym wrócić do starego sposobu pracy, gdyby Claude Code nagle zniknął.”
— erdemo
Przeczytaj to jeszcze raz. Deweloper z piętnastoletnim doświadczeniem nie jest pewien, czy potrafiłby wrócić do pracy bez narzędzia AI. To nie jest entuzjazm. To zależność — ta cicha odmiana, która brzmi jak preferencja.
Inny komentujący opisał rozlewanie się narzędzia:
„Mam Claude Code zarządzającego moim Obsidian Vault, konfiguracją Home Assistanta przez SSH, pomagającego kupić ubezpieczenie na życie i rozliczać podatki…”
— dimitri-vs
Narzędzie przekroczyło granicę kodu i weszło w zarządzanie życiem. Kolejna osoba opisała kolegę na wyjazdowym spotkaniu firmowym — w autobusie jadącym na kolację, telefon w ręku, sesja Claude Code na ekranie.
A potem komentarz, który przeciął wszystko:
„Ta społeczność jest obsesyjnie pro-AI. Pytanie tutaj to odpowiednik pytania faceta, który siedzi przy automacie obok ciebie od trzech godzin, czy uważa, że masz problem z hazardem.”
— lowsong
Sześć wymiarów, dwa źródła
Artykuł Khare’a i wątek na HN opisują te same wzorce przez różne soczewki. Jeden to introspekcyjna analiza. Drugi to grupowe wyznanie w czasie rzeczywistym. Razem mapują się na framework OnTilt.
Utrata kontroli. Pułapka „jeszcze jednego prompta” u Khare’a — iteracyjne poprawianie z malejącymi zwrotami. OP wątku HN spędzający cały dzień na eksploracji pomysłów bez konkretnego wyniku. Przepaść między zamierzonym a faktycznym użyciem.
Eskalacja sesji. Khare opisuje problem niedeterminizmu: te same prompty dają różne wyniki, tworząc „stały, niskopoziomowy stres”, który napędza chęć próbowania dalej. Near-missy, które wydają się wystarczająco bliskie, żeby uzasadnić jeszcze jedną próbę.
Dark flow. Maraton przełączania kontekstów. Sześć problemów dziennie, każdy absorbujący, żaden nie dochodzi do końca. sshine na HN opisuje to od środka: „Claude Code daje mi odwagę wyobrażenia sobie, że będę miał rzeczywisty postęp w dużych rzeczach, bo pomaga mi utrzymać przegląd i nie utknąć w detalach.” Pochłonięcie jest prawdziwe. Czy produkuje proporcjonalny wynik — to pytanie, które nikt nie zadaje aż do później.
Zależność operacyjna. Wyznanie erdemo: niezdolność wyobrażenia sobie pracy po staremu. Atrofia myślenia u Khare’a — miesiące outsourcowania first-draft reasoning do AI zdegradowały jego zdolność do rozumowania od zera. Na przeglądzie projektowym przy tablicy, bez AI, miał trudności z problemami współbieżności, które koncepcyjnie rozumiał.
Jego analogia jest precyzyjna:
„To jak z GPS i nawigacją. Przed GPS budowałeś mapy mentalne… Po latach z GPS nie potrafisz nawigować bez niego.”
Przesunięcie antycypacji. Bieżnia FOMO. Khare spędzał weekendy na ewaluacji nowych narzędzi — Claude Code, Codex CLI, GPT-5.3, Gemini CLI, CrewAI, AutoGen, LangGraph — goniąc za 5% poprawami, tracąc głębszą ekspertyzę. Ekscytacja nowym narzędziem stała się nagrodą. Wynik zszedł na dalszy plan.
Negatywne konsekwencje. Khare wypalił się pod koniec 2025. Stał się obojętny na jakość. OP wątku HN martwi się, że za dziesięć lat znajdzie po sobie tylko wykresy. Kolega opuszcza kolację zespołową dla sesji Claude Code.
Co radzą
Interwencje Khare’a są konkretne i przetestowane na sobie. Wątek HN dodaje kilka więcej z tłumu. Żadna nie wymaga rezygnacji z czegokolwiek.
Zasada trzech promptów. Jeśli AI nie daje 70% użyteczności w trzech promptach — pisz rozwiązanie sam. Khare nazywa to jedną zasadą, która zaoszczędziła mu najwięcej czasu. Łamie spiralę near-miss-retry narzucając twardy punkt odcięcia.
Oddziel czas myślenia od czasu z AI. Poranki na manualne rozumowanie — szkicowanie, whiteboarding, pisanie podejść ręcznie. Popołudnia na wykonanie z AI. Pierwsza godzina dnia bez AI jest nienegocjowalna. To bezpośrednio zwalcza atrofię myślenia.
Ustaw timer na sesje. Khare używa 30-minutowych timerów. Checklist OnTilt rekomenduje 90 minut w oparciu o badania rytmów ultradialnych. Wybierz liczbę. Liczba ma mniejsze znaczenie niż granica.
Loguj efektywność AI przez dwa tygodnie. Khare znalazł wyraźny podział: AI oszczędza czas na boilerplate’ach, dokumentacji i generowaniu testów. AI kosztuje czas na decyzjach architektonicznych, złożonym debugowaniu i pracy specyficznej dla codebase’u. Wiedza, co jest czym, zmienia sposób sięgania po narzędzie.
Akceptuj 70%. Przestań gonić za idealnym outputem. Weź 70%, które AI ci daje, i resztę dopisz sam. Perfekcjonizm plus probabilistyczny output równa się nieskończona pętla poprawek. Zasada 70% ją łamie.
Naucz się jednego narzędzia głęboko. Przestań ewaluować nowe platformy w każdy weekend. Wybierz jednego asystenta kodowania AI i naucz się go porządnie. kylecazar na HN ujmuje to trafnie: „Prawdopodobnie nie jesteś uzależniony od CC — podejrzewam, że po prostu przeskakujesz między pomysłami za szybko, bo nowe narzędzia na to pozwalają.”
Wyznacz ambitny, ograniczony cel. lopatin na HN: „Postaw ambitny cel osiągalny z Claude Code i skup się na jego dostarczeniu.” Otwarta eksploracja czuje się produktywnie, ale nie produkuje niczego do wysłania. Cel tworzy linię mety. Dark flow potrzebuje linii mety.
Skupiony review, nie totalny review. Nie możesz skrupulatnie przejrzeć każdej linii kodu generowanego przez AI na dużą skalę. Rozwiązanie Khare’a: skupiony review na bezpieczeństwie, obsłudze danych i ścieżkach błędów. Automatyczne testy na wszystko inne. To pragmatyzm, nie brawura — to triage.
Paradoks budowniczego
Historia Khare’a ma ironiczny zwrot. Okres wypalenia — koniec 2025, kiedy stał się obojętny na jakość — wyprodukował jego najlepszą pracę. Wyczerpanie zmusiło go do wyraźnego zobaczenia zepsutych problemów. Zbudował Distill do deterministycznej deduplikacji kontekstu. Stworzył agentic-authz do autoryzacji agentów. Zaczął AgentTrace do obserwowalności.
Złamanie się wyklarowało, co trzeba zbudować.
Simon Willison, który obserwował ten wzorzec u dziesiątek deweloperów, oferuje najlepiej skalibrowaną perspektywę w wątku HN:
„Nie martwiłbym się na razie — to jest nowe i jest dużo ekscytacji związanej z odkrywaniem, co to potrafi. Gdybyś nadal był uzależniony za trzy miesiące, zacząłbym się martwić. Na chwilę obecną budujesz wartościowy model mentalny.”
Trzy miesiące. To rozsądne okno. Pytanie, czy zauważysz, kiedy się zamknie.
Analogia GPS się sprawdza. Używanie GPS na trasę jest praktyczne. Używanie GPS żeby dojść do sklepu za rogiem to sygnał. Narzędzie nie zepsuło twojego zmysłu orientacji. Przestałeś go ćwiczyć. Różnicę trudno zobaczyć od środka.
Konkluzja Khare’a: „Prawdziwy skill to nie prompt engineering, wybór modelu czy optymalizacja workflow. To wiedzieć, kiedy przestać.”
Deweloperzy, którzy będą dobrze pracować z AI, to nie ci, którzy będą go używać najwięcej. To ci, którzy zachowają zdolność pracy bez niego — i będą świadomie wybierać, kiedy po niego sięgnąć.
Gdzie koncentrują się twoje wzorce? Zrób autorefleksję OnTilt — 14 pytań, 3 minuty, anonimowo. Pokaże ci to, czego możesz nie śledzić.
Źródła:
- Khare, S. (2026, 8 lutego). „AI Fatigue Is Real and Nobody Talks About It.” siddhantkhare.com
- aziz_sunderji. (2026, lipiec). „Addicted to Claude Code–Help.” Hacker News. Wątek dyskusji. Cytowani użytkownicy: saulpw, schmookeeg, erdemo, dimitri-vs, jdorfman, lowsong, sshine, kylecazar, lopatin, simonw.
- Kellerman, G.R. & Kropp, M. (2026). Badanie „AI Brain Fry”. Harvard Business Review / Boston Consulting Group.
- Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row.
- Schüll, N.D. (2012). Addiction by Design: Machine Gambling in Las Vegas. Princeton University Press.
OnTilt to projekt badawczy analizujący wzorce behawioralne w pracy z AI. Quiz to narzędzie autorefleksji, nie instrument diagnostyczny. Więcej na stronie O projekcie.