Twoje AI nie ukradło ci flow state — sam go oddałeś

Dwóch programistów. Ten sam feature. Ten sam codebase.

Programista A używa Claude Code przez cztery godziny non-stop. Prompty lecą. Kod streamuje się. Testy przechodzą za trzecim razem. Czuje się świetnie. Pełna energia. Produktywność. Feature shipuje.

Programista B otwiera pusty plik. Dwie godziny ręcznego kodowania. Zero sugestii. Zero streaming outputu. Wolniej. Ten sam feature shipuje.

Kto był bardziej produktywny? Programista B — połowa czasu, ten sam wynik.

Kto czuł się bardziej produktywny? Programista A — i to o rzędy wielkości.

Ta luka między poczuciem produktywności a byciem produktywnym to miejsce, gdzie mieszka problem.

Czym tak naprawdę jest flow

Mihaly Csikszentmihalyi spędził dekady na badaniu tego, co nazwał “optymalnym doświadczeniem”. Flow state. Stan, w którym praca przestaje czuć się jak praca i staje się absorbująca, nagradzająca, pozornie bezwysiłkowa.

Zidentyfikował konkretne kryteria. Jasne cele. Natychmiastowy feedback. Równowaga między wyzwaniem a poziomem umiejętności. Utrata samoświadomości. Zniekształcenie czasu — godziny czują się jak minuty. I jeszcze jedno: poczucie kontroli. Nie kontroli nad wynikami. Kontroli nad działaniami. To ty decydujesz, co dzieje się dalej.

Narzędzia AI do kodowania spełniają większość tych kryteriów zaskakująco dobrze.

Jasne cele? Masz prompt. Natychmiastowy feedback? Kod streamuje się w sekundy. Równowaga wyzwanie-umiejętności? AI dostosowuje się do twojego poziomu — junior dostaje scaffolding, senior dostaje detale implementacji. Utrata samoświadomości? Jak najbardziej. Zniekształcenie czasu? Zapytaj kogokolwiek, kto miał czterogodzinną sesję kodowania z AI, która wydawała się trwać czterdzieści minut.

Ale to ostatnie kryterium — poczucie kontroli — to miejsce, gdzie iluzja pęka.

Dark flow

Badacze hazardu ukuli termin “dark flow”, żeby opisać konkretny stan. Gracze przy automatach wchodzą w coś, co wygląda jak flow Csikszentmihalyiego. Są pochłonięci. Tracą poczucie czasu. Czują się zaangażowani. Ale nie podejmują znaczących decyzji. Maszyna prowadzi. Oni tylko jadą.

Kluczowa różnica: w prawdziwym flow sam wybierasz swoją następną akcję. W dark flow reagujesz na to, co ci się prezentuje.

Obserwuj siebie podczas sesji kodowania z AI. Narzędzie sugeruje funkcję. Czytasz ją. Akceptujesz, modyfikujesz lub odrzucasz. Narzędzie sugeruje następny fragment. Oceniasz. Akceptujesz, modyfikujesz, odrzucasz. Narzędzie sugeruje znowu.

Jesteś zaangażowany. Stymulowany. Tracisz poczucie czasu. Ale przewiń taśmę. Policz momenty, w których ty zainicjowałeś akcję, kontra te, w których na nią reagowałeś. Policz momenty, w których zdecydowałeś, co budować, kontra te, w których oceniałeś, co zbudowano za ciebie.

Ta proporcja mówi ci, kto prowadził.

To jest wzorzec, który nasz quiz autorefleksji mierzy jako “Dark Flow / Immersja” — jeden z sześciu wymiarów. Nie dlatego, że immersja jest z natury zła. Bo immersja bez sprawczości to konsumpcja przebrana za tworzenie.

Test sprawczości

Oto konkretny eksperyment. Spróbuj podczas następnej sesji kodowania z AI.

Zanim AI wygeneruje następną sugestię, zatrzymaj się. Zakryj output. Zapisz — na papierze, nie w głowie — co zrobiłbyś dalej. Jaką funkcję byś napisał. Jakie podejście byś zastosował. Jakie powinny być trzy następne linie kodu.

Teraz odkryj output AI. Porównaj.

Jeśli sugestia AI cię zaskakuje — jeśli zastosowała podejście, o którym nie pomyślałeś, rozwiązała problem, którego nie zidentyfikowałeś, lub ustrukturyzowała kod w sposób, w jaki ty byś tego nie zrobił — to AI prowadziło. Byłeś pasażerem, który czuł się jak pilot.

Jeśli sugestia AI pasuje do twojego planu — to samo podejście, ta sama struktura, może inna składnia — to ty prowadziłeś. AI było narzędziem w twoich rękach.

Zrób to dziesięć razy w sesji. Policz rozbieżności.

Większość programistów, którzy tego próbują, jest niezadowolona z wyników. Nie dlatego, że sugestie AI są złe. Bo proporcja zaskoczeń do trafień ujawnia, ile sesji było ich myśleniem, a ile patrzeniem, jak ktoś inny myśli.

Wysoki współczynnik zaskoczeń to nie porażka AI. To informacja o tym, kto wykonuje pracę poznawczą.

Deep work kontra praca z AI

Cal Newport definiuje deep work jako “profesjonalną aktywność wykonywaną w stanie wolnej od rozpraszaczy koncentracji, która przesuwa twoje zdolności poznawcze do ich granic”. Output tworzy nową wartość. Aktywność jest trudna do powtórzenia. Rozwija twoje umiejętności.

Ten ostatni punkt ma znaczenie. Deep work czyni cię lepszym w tym, co robisz. Buduje ekspertyzę przez celową praktykę. Kumuluje się.

Praca wspomagana AI fragmentaryzuje koncentrację na mikro-decyzje. Zaakceptuj tę sugestię. Odrzuć tamtą. Zmodyfikuj tę sygnaturę funkcji. Zatwierdź ten test. Każda decyzja zajmuje sekundy. Każda jest za mała, żeby wymagać głębokiej koncentracji. Rytm: bodziec, ocena, odpowiedź. Bodziec, ocena, odpowiedź.

Rytm analogiczny do triażu maili. Scrollowania social mediów. Automatów do gier.

Możesz być naprawdę produktywny w tym trybie. Kod shipuje. Feature’y działają. Testy przechodzą. Ale mięsień poznawczy, który ćwiczysz, to ocena, nie generowanie. Stajesz się lepszy w ocenianiu kodu, nie w pisaniu go. Trenujesz smak, nie rzemiosło.

Newport nazwałby to shallow work ubranym w ubrania deep work. Bloki czasowe wyglądają tak samo w kalendarzu. Zmęczenie czuje się podobnie — czasem gorzej, bo ciągłe mikro-decyzje są wyczerpujące na swój sposób. Ale krzywa rozwoju umiejętności jest płaska.

Sześć miesięcy kodowania z AI czyni cię lepszym w promptowaniu. Sześć miesięcy ręcznego kodowania czyni cię lepszym w kodowaniu. Obie to umiejętności. Nie są tą samą umiejętnością.

Gradient zależności

To nie jest binarne. Nikt nie musi wybierać między “tylko AI” a “zero AI”. Pytanie brzmi, gdzie stawiasz granicę i czy robisz to świadomie.

Decyzje architektoniczne — wielkoformatowe “co budujemy i dlaczego” — wymagają ciągłego, oryginalnego myślenia. To tu flow state ma największe znaczenie. To tu twój mózg musi jednocześnie trzymać wiele abstrakcji, testować je przeciwko sobie i syntetyzować coś nowego. Narzędzia AI fragmentaryzują ten proces. Każda sugestia to przerwanie. Każde przerwanie burzy model mentalny, który budowałeś.

Implementacja — przekładanie jasnego projektu na działający kod — ogromnie korzysta ze wsparcia AI. Decyzje projektowe są podjęte. Architektura ustalona. Teraz potrzebujesz składni, wywołań API, boilerplate’u i obsługi edge case’ów. Tu narzędzia AI świecą bez wyciągania kosztu utraconej sprawczości.

Proporcja, która działa u większości programistów, którzy poważnie się nad tym zastanowili: projektuj 20% czasu bez AI. Implementuj 80% z AI.

Nie dlatego, że AI nie może pomóc z projektem. Bo twój mózg nie może robić głębokiej pracy projektowej, kiedy coś ciągle podaje ci odpowiedzi, zanim skończysz formułować pytanie.

Odzyskiwanie prawdziwego flow

Cztery praktyki. Wszystkie proste. Żadna nie wymaga rzucania czegokolwiek.

Bloki architektoniczne bez AI. Kiedy projektujesz system — wybierasz wzorce, definiujesz interfejsy, mapujesz przepływ danych — zamknij narzędzie AI. Otwórz pusty dokument albo tablicę. Myśl. Dyskomfort, który czujesz przez pierwsze pięć minut, to odstawienie od ciągłej stymulacji. Mija. To, co przychodzi potem, to prawdziwy flow.

Projektuj przed implementacją. Zapisz swoje podejście zanim zaczniesz promptować. Wystarczy akapit. “Ten komponent przyjmie X na wejściu, przetworzy przez Y i zwróci Z. Trudna część to obsługa edge case’u, w którym…” Teraz otwórz narzędzie AI. Teraz ty prowadzisz.

Codzienny dziennik sprawczości. Pod koniec każdego dnia pracy odpowiedz na jedno pytanie: “Co tak naprawdę zdecydowałem dzisiaj?” Nie “co shipnąłem” albo “co zbudowałem”. Jakie decyzje podjąłeś? Jeśli odpowiedź to głównie “akceptowałem lub odrzucałem sugestie AI” — to był dzień oceniania, nie tworzenia.

Świadome naprzemienne tryby. Niektóre zadania z AI. Niektóre bez. Nie jako kara. Jako trening. Muzyk, który gra tylko z akompaniamentem, nigdy nie nauczy się sam utrzymywać tempa. Programista, który koduje tylko z AI, nigdy nie nauczy się sam utrzymywać architektury. AI to akompaniament. Musisz umieć grać solo.

Niewygodna prawda

Nikt nie ukradł ci twojego flow state. Żadne narzędzie ci tego nie robi. Dokonujesz wymiany, i warto przyjrzeć się jej warunkom.

Wymieniasz sprawczość na szybkość. Wymieniasz rozwój umiejętności na natychmiastowy output. Wymieniasz dyskomfort niewiedzy na komfort sugestii. Każda wymiana jest racjonalna w danym momencie. Skumulowane przez miesiące, kształtują na nowo to, jakim programistą jesteś.

Pytanie nie brzmi, czy narzędzia AI są dobre czy złe. Pytanie brzmi, czy dokonujesz tych wymian świadomie, czy przestałeś zauważać, że w ogóle je robisz.

Dark flow czuje się jak produktywność. Wygląda jak produktywność. Produkuje artefakty przypominające output produktywności. Ale kiedy narzędzie padnie — a narzędzia zawsze w końcu padają — odkrywasz, jakie umiejętności zachowałeś, a jakie oddałeś w zamian.

Sprawdź swój wzorzec

Dark Flow to jeden z sześciu wymiarów w naszym quizie autorefleksji. Pozostałe mierzą utratę kontroli, eskalację sesji, zależność operacyjną, negatywne konsekwencje i przesunięcie antycypacji. Razem tworzą profil behawioralny — nie diagnozę, ale lustro.

Zrób test autorefleksji. Zajmie ci trzy minuty. Wyniki mogą potwierdzić to, co już podejrzewasz. Albo mogą cię zaskoczyć.

Tak czy inaczej — masz teraz dane zamiast przeczucia.

---

OnTilt to projekt badawczy badający wzorce behawioralne w narzędziach AI do kodowania, które mogą wykazywać paralele z mechanizmami opisanymi w badaniach nad uzależnieniami. Quiz jest narzędziem autorefleksji, nie instrumentem diagnostycznym. Więcej na stronie O projekcie.