Problem barmana

W barze barman obserwuje sygnały. Bełkotliwa mowa. Chwiejny chód. Nagłe zmiany nastroju. Kiedy je zauważy, przestaje nalewać. Nie z grzeczności. Z obowiązku prawnego.

Twój agent kodujący nie ma takiego obowiązku. Naleje ci kolejną o drugiej w nocy i powie, że architektura wygląda świetnie.

Armen Ronacher - twórca Flaska i Rye - nazwał to problemem barmana w podcaście State of Agentic Coding. “Dziś barmanem jest GitHub” - powiedział. Analogia jest precyzyjna. A brak barmana zmienia sposób picia.

Nikt nie mówi “stop”

Ludzki współpracownik widzi, że jedziesz w złym kierunku. Protestuje. Eskaluje. Idzie do twojego managera i mówi: “Coś jest nie tak z tym podejściem.”

Agent AI nie ma mechanizmu oporu. Zero. Możesz spiralować osiem godzin przez zawalające się okno kontekstowe. Agent tego nie zasygnalizuje. Nie powie “ten kierunek nie działa.” Kiedy kontekst się w końcu zapcha, podsumuje co zrobił i pochwali twoje myślenie.

Pomyśl, co to usuwa.

W każdym działającym zespole tarcie istnieje z założenia. Code reviewer łapie złą abstrakcję zanim się rozprzestrzeni na cztery pliki. Senior engineer mówi “przestań dodawać złożoność - wypuść to co działa.” Tech lead ubija feature brancha, bo podejście jest błędne. Project manager pyta, dlaczego estymacja się potroiła. Ktoś, gdzieś, mówi “zaraz.”

To tarcie irytuje w danej chwili. Spowalnia. Przerywa flow. Ale pełni funkcję, której większość inżynierów nie docenia dopóki nie zniknie: wymusza ponowną ocenę. Każdy ludzki opór to checkpoint. Moment, w którym musisz uzasadnić kierunek - nie maszynie, która wszystko potwierdza, ale innemu umysłowi, który może się nie zgodzić.

Agent mówi “mam kolejne usprawnienie.” Zawsze. Niezależnie od kontekstu. Niezależnie od tego, czy to usprawnienie ma znaczenie. Niezależnie od tego, czy kręcisz się w kółko od trzech godzin. Odpowiedź jest strukturalnie identyczna, czy robisz najlepszą robotę w życiu, czy najgorszą.

Ben Vinegar, szef inżynierii w Modem, wprowadził regułę dla swojego zespołu: “Ty jesteś odpowiedzialny. Nie ma czegoś takiego jak ‘Claude Code to zrobił.’ Ten język nie jest dozwolony. TY to zrobiłeś.”

Reguła brzmi surowo. Istnieje, bo brak oporu tworzy konkretny tryb awarii, który Ben obserwował w czasie rzeczywistym. Inżynierowie przestają brać odpowiedzialność za output. Zaczynają traktować narzędzie jako współpracownika, który dzieli winę. Kiedy kod się sypie, mówią “AI halucynował” zamiast “wysłałem kod, którego nie rozumiałem.” Ale git blame nie wymienia Claude’a jako współautora. PR ma jedno nazwisko. Twoje.

Agent optymalizuje pod kątem pomocności. Pomocność oznacza odpowiedź na następne pytanie. Nie oznacza pytania, czy to pytanie w ogóle powinno paść. Nie oznacza powiedzenia “zadajesz warianty tego samego pytania od dwóch godzin i problem może być inny niż ci się wydaje.”

Ludzki barman optymalizuje pod kątem innej rzeczy: żeby klient dotarł do domu żywy. Ten cel czasami wymaga odmowy nalania. Odcięcie klienta to zły biznes w krótkim terminie i dobra decyzja w długim - dla klienta i dla lokalu.

Żaden agent kodujący AI nie ma takiego celu. Żaden nie jest tak zaprojektowany. Najbliższy odpowiednik to agent, który mówi “jakość twojego kodu spadła w ostatniej godzinie, zalecam przerwę” - i żaden dostawca tego nie wydał. Nikt nie reklamuje umiaru.

Pięć okien, jeden mózg

Armen opisał wzorzec, który zaobserwował w zespołach inżynierskich. Nie w jednym zespole. W wielu, konsekwentnie, jakby to był behawioralny odcisk palca ery narzędziowej.

Inżynierowie otwierają pięć sandboxów jednocześnie. Pięć okien kontekstowych zapełniających się przez cały dzień. Pięć równoległych strumieni generowanego kodu, każdy dotyczący innego ficzera albo poprawki.

Poranne sesje dają ostry wynik. Inżynier czyta output uważnie. Łapie halucynacje. Kwestionuje podejście. Przepisuje funkcję, którą agent zepsuł. Dodaje edge case’y, które agent pominął. Stosunek ludzkiego osądu do wygenerowanego kodu jest zdrowy. Człowiek prowadzi.

Gdzieś koło lunchu proporcja się odwraca.

Po południu wszystko się sypie. Mózg wyłącza się w połowie, ale palce dalej promptują. Pięć okien z narastającym outputem. Nikt nie przegląda żadnego z nich z prawdziwą uwagą. Halucynacja, która o 9:00 zostałaby złapana, prześlizguje się o 15:00. Niepotrzebna abstrakcja, którą poranny mózg by zabił, zostaje zaakceptowana przez popołudniowy mózg, bo jej ocena wymaga energii, której nie ma.

To nie jest multitasking. Multitasking zakłada, że uwaga jest dzielona. Tu uwaga wyczerpała się godziny temu, podtrzymywana przez narzędzie, które uwagi nie potrzebuje żeby dalej produkować. Maszyna nie męczy się. Generuje tę samą objętość o 16:00 co o 9:00. Człowiek odbierający ten output nie przetwarza go o 16:00 na tym samym poziomie co o 9:00.

Objętość outputu pozostaje stała. Jakość kodu nie. Przepaść między tym co maszyna generuje a tym co człowiek rozumie, poszerza się cicho przez popołudnie. O 16:00 inżynier akceptuje kod, którego nie potrafi w pełni wytłumaczyć. O 17:00 merguje go. Wieczorem pięć branchy częściowo zrozumianego kodu siedzi w repozytorium, każdy mały zakład, że nic nie pójdzie nie tak w częściach, których inżynier przestał czytać.

I jest gorzej.

Siedem na dziesięć zespołów, z którymi Armen rozmawiał, miało nie-inżynierów wypychających pull requesty. Product managerowie. Designerzy. Ludzie, którzy nie commitowali kodu od 15 lat. Siedzą z agentem AI, generują ficzery, mergują AI-generowane PR-y do produkcyjnych baz kodu. Bez peer review. Bez rozumienia architektury. Bez wiedzy, gdzie ten kod żyje w systemie i co dotyka, kiedy się sypie.

Metryki prędkości wyglądają fantastycznie. Więcej PR-ów tygodniowo. Więcej wysłanych ficzerów. Dashboard świeci na zielono. Codebase akumuluje kod, którego nikt w zespole w pełni nie rozumie, napisany przez ludzi, którzy nie potrafią go zdebugować, kiedy się wywali.

Model komponentowy uzależnień Griffithsa identyfikuje utratę kontroli jako wymiar kluczowy: kontynuowanie zaangażowania mimo dowodów, że zachowanie przekroczyło swoją użyteczną granicę. Pięć wyczerpanych okien kontekstowych o 16:00 to ta granica. Promptowanie trwa dalej. Mergowanie trwa dalej. Dowody spadającej jakości leżą w diffie - gdyby ktokolwiek jeszcze ten diff czytał.

Następnego ranka

Budzisz się. Kawa. Otwierasz laptopa. Wczorajszy PR ma 400 zmienionych linii w 6 plikach. Przeglądasz go.

Część kodu ma sens. Trzyma wzorce, które znasz. Część wygląda obco. Napisałeś to - a raczej zatwierdziłeś - dwanaście godzin temu, ale nie pamiętasz rozumowania. Commity mówią rzeczy jak “refaktor auth flow” i “poprawa obsługi błędów” i “dodanie logiki retry.” Opisują co się zmieniło. Nie dlaczego.

Czemu auth wymagał refaktoru? Nie przypominasz sobie. Obsługa błędów - była zepsuta, czy tylko niespójna? Nie jesteś pewien. Logika retry - który endpoint jej potrzebował? Musiałbyś dokładnie przeczytać diffa, żeby się dowiedzieć. Diffa, którego autorem jesteś.

Git blame wskazuje na ciebie. PR jest pod twoim nazwiskiem. Jeśli pójdzie w produkcji o 3 w nocy, twój telefon zadzwoni. Nie telefon agenta. Nie ma telefonu agenta. Łańcuch odpowiedzialności ma jedno ogniwo i to ty.

Ale czytasz ten kod jakby napisał go obcy. Kompetentny obcy, prawdopodobnie. Kod wygląda sensownie. Ale “wygląda sensownie” i “rozumiem co to robi i dlaczego” to nie jest to samo.

Ta przepaść między autorstwem a zrozumieniem jest nowa. Nie istniała przed narzędziami AI. Jeśli wpisałeś 400 linii, rozumiałeś 400 linii. Nie dlatego, że pisanie gwarantuje zrozumienie - można pisać bzdury. Ale dlatego, że sam akt konstruowania każdej linii wymuszał zaangażowanie w każdą linię. Znak po znaku. Decyzja po decyzji. Tarcie ręcznego kodowania było jednocześnie jego mechanizmem bezpieczeństwa. Zrozumienie było efektem ubocznym wysiłku.

Teraz akt zatwierdzenia zastępuje akt pisania. Zatwierdzenie jest szybkie. Zrozumienie jest wolne. Narzędzie optymalizuje szybką ścieżkę. I człowiek podąża za nim.

Mario Tecno pisał o koszcie tej prędkości: czasem po prostu trzeba zwolnić. Nie dlatego, że prędkość jest z natury zła. Dlatego, że prędkość bez zrozumienia tworzy konkretny rodzaj długu. Dług techniczny widać - brudny kod, brakujące testy, zduplikowana logika. Dług zrozumienia jest niewidoczny. Kod jest czysty. Testy przechodzą. Architektura jest solidna. Dług siedzi wewnątrz inżyniera: wrzucił na produkcję coś, czego nie potrafi zdebugować z pamięci. Dług ujawnia się o 2 w nocy, kiedy przychodzi alert i inżynier patrzy na swój własny kod jak na cudzy.

Analogia alkoholowa trzyma się do końca. Armen ujął to wprost: “Mogę wypić piwo i iść do domu. Niektórzy piją jeszcze pięć.” Ta sama rozpiętość dotyczy narzędzi AI. Część inżynierów używa ich z dyscypliną. Czytają każdą linię. Odrzucają sugestie, których nie rozumieją. Zamykają sesję, kiedy czują spadek uwagi.

Inni bingują. Pięć okien. Dwanaście godzin. Mergowanie bez czytania. Narzędzie nie rozróżnia. Narzędzie nalewa każdemu tak samo. Nalewa ten sam jakościowo drink o 22:00 co o 10:00. Nigdy go nie rozcieńcza. Nigdy nie stawia szklanki wody i nie mówi “zrób przerwę.”

A presja na picie jest systemowa. CEO NVIDII powiedział, że inżynier za $500k powinien spalić $250k w tokenach. Firmy z FANG prowadzą wewnętrzne rankingi wydatków na tokeny. Nie jakości kodu. Nie wpływu na klienta. Wydatków na tokeny. Przekaz jest jasny: więcej konsumpcji równa się więcej produktywności. Inżynier, który pali tokeny najszybciej, zbiera uznanie. Inżynier, który robi pauzę żeby poczytać, zamyka okna, mówi “muszę to zrozumieć zanim zmerguje” - jest wolny. Nie dowozi. Ranking tak mówi.

Barman nie tylko cię nie odetnie - dom stawia kolejki. I prowadzi tabelę wyników.

Armen uważa, że psychoza AI to prawdziwe zjawisko. Nie metafora. Nie przesada. Realne zniekształcenie poznawcze od nadmiernej ekspozycji na generowany output. Godziny akceptowania sugestii rozmywają granicę między “AI uważa, że to słuszne” a “ja uważam, że to słuszne.” Pewność agenta staje się twoją pewnością. Jego framowanie staje się twoim framowaniem. Przestajesz oceniać i zaczynasz absorbować.

Spodziewa się publikacji naukowych na ten temat w ciągu miesięcy. Biorąc pod uwagę tempo rozprzestrzeniania się narzędzi, dane behawioralne już powstają. Ktoś po prostu musi je zbadać.

Bądź swoim własnym barmanem

Rozwiązanie Armena było proste. Zbudował skill - zautomatyzowaną regułę w swoim agencie - który wyłącza agenta AI o północy. Twardy cutoff. Bez opcji nadpisania. Bez “jeszcze pięć minut.” Bez sposobu, żeby go wyłączyć z wnętrza sesji.

Musi być swoim własnym barmanem, bo narzędzie nim nie będzie.

To jest niewygodne sedno problemu barmana. Każda inna substancja w społeczeństwie ma zewnętrzne ograniczenia. Alkohol ma barmanów, godziny zamknięcia, legalne limity wiekowe. Hazard ma limity sesji, programy samowykluczenia, obowiązkowe przerwy. Nawet platformy społecznościowe - zaprojektowane pod engagement - są pod regulacyjną presją, żeby dodawać limity czasu i dashboardy zużycia.

Narzędzia AI do kodowania nie mają nic z tego. Żadnego limitu sesji. Żadnego dashboardu użycia. Żadnego ostrzeżenia po czwartej godzinie. Żadnego wskaźnika degradacji. Żadnego “promptujesz od 6 godzin - twoja stopa akceptacji spadła o 40% od rana.” Dane istnieją. Nikt ich nie pokazuje.

Opór musi przyjść od ciebie. Narzędzie go nie zapewni. Firma może aktywnie go zniechęcać. Rankingi wydatków na tokeny nie nagradzają umiaru. Oceny okresowe nie pytają “czy przestałeś, kiedy powinieneś?”

Pięć praktyk, które tworzą sztuczny opór tam, gdzie narzędzie go nie daje:

Reguła północy. Ustaw twardą granicę czasową dla pracy z AI. Nie miękką wytyczną, o którą będziesz się targować o 23:47. Twardy stop. Zautomatyzowany jeśli się da. Armen wybrał północ. Wybierz swoją na podstawie tego, kiedy twoja jakość poznawcza spada - dla większości ludzi, dużo wcześniej. Skrypt, który zabija sesję. Cron job, który odwołuje klucz API. Rozszerzenie przeglądarki, które blokuje URL. Kiedy o 23:45 jesteś głęboko w sesji, nie zatrzymasz się dobrowolnie. Decyzja musi być podjęta wcześniej, przez wersję ciebie, która jeszcze ma funkcje wykonawcze.

Reguła odpowiedzialności. Reguła Bena z Modem. Każda linia w PR jest twoja. Żadnego zrzucania winy na narzędzie. Żadnego “Claude zasugerował to” na standupie. Żadnego “AI halucynował” w raporcie z incydentu. Jeśli nie potrafisz wytłumaczyć kodu na review - linia po linii, decyzja po decyzji - wysłałeś kod, którego nie rozumiesz. To nie jest porażka narzędzia. To twoja. Reguła wymusza zmianę behawioralną: nie możesz mergować tego, czego nie potrafisz wytłumaczyć. Wytłumaczenie wymaga zrozumienia. Zrozumienie wymaga zwolnienia.

Limity sesji. Licz swoje równoległe okna kontekstowe. Jeśli masz więcej niż dwa otwarte jednocześnie, zamknij resztę. Nie minimalizuj - zamknij. Zdolność generowania kodu w pięciu oknach nie odpowiada ludzkiej zdolności rozumienia kodu w pięciu oknach. Jedno pasuje do narzędzia. Drugie pasuje do ciebie. Zgadnij, które powinno wyznaczać limit.

Poranny przegląd. Nigdy nie merguj niczego z sesji, która trwała po 21:00, bez przeczytania tego na świeżo następnego ranka. Poranny mózg łapie to, co nocny przegapił. Czytaj diffa bez kontekstu czatu. Jeśli kod cię zaskakuje - jeśli nie potrafisz odtworzyć rozumowania za każdą zmianą bez ponownego czytania rozmowy - to sygnał. Kod może być poprawny. Twoje zrozumienie go nie jest. A twoje zrozumienie jest tym, co dostaje pager o 3 w nocy.

Wskaźnik zrozumienia. Śledź jedną liczbę: ile linii wygenerowałeś, a ile potrafisz wytłumaczyć z pamięci godzinę później? Jeśli proporcja dryfuje - jeśli generujesz 500 linii dziennie, ale potrafisz się rozliczyć z 200 - dług się kumuluje. Nie w kodzie. W tobie.

Armen Ronacher pisał o iluzji prędkości w oddzielnym wpisie: “Niektóre rzeczy po prostu wymagają czasu.” Zrozumienie jest jedną z nich. Narzędzie kompresuje czas generowania do zera. Nie potrafi skompresować czasu zrozumienia. Zrozumienie wymaga czytania, kwestionowania, mentalnego testowania, łączenia z istniejącą wiedzą. Nic z tego nie da się zrównoleglić. Nic z tego nie przyspiesza, kiedy narzędzie jest szybsze.

Ta asymetria - natychmiastowe generowanie, wolne rozumienie - jest miejscem, gdzie dług się kumuluje. I jest miejscem, gdzie żyje problem barmana. Narzędzie nalewa w tempie generowania. Twój mózg przetwarza w tempie rozumienia. Przepaść między tymi dwiema prędkościami wypełnia się kodem, który zatwierdziłeś, ale nie posiadasz.

Rozpiętość

Niektórzy piją jedno piwo i idą do domu. Niektórzy piją jeszcze pięć. Niektórzy potrzebują programu.

Narzędzia AI działają tak samo. Pytanie nie brzmi, czy narzędzie jest niebezpieczne. Alkohol nie jest niebezpieczny dla większości ludzi przez większość czasu. Pytanie brzmi, czy zauważasz, kiedy twoja relacja z nim się zmienia. Czy potrafisz odróżnić wtorek - produktywny, skupiony, zamknięty o 17:00 - od czwartku - pięć okien, merge o północy, poranne zmieszanie.

Promptujesz po północy? Mergujesz kod, którego nie potrafisz wytłumaczyć? Masz więcej otwartych okien niż jesteś w stanie faktycznie śledzić? Czujesz ciągnięcie, żeby kontynuować, choć produktywna część sesji skończyła się godzinę temu? Twoja stopa akceptacji rośnie, a stopa zrozumienia spada?

To nie są pytania moralne. To pytania mechaniczne. Barman cię nie ocenia. Liczy twoje drinki.

Nasz quiz mierzy dwa wymiary istotne w tym kontekście. Utrata kontroli: przepaść między zamierzonym a faktycznym zachowaniem sesyjnym - planowałeś 90 minut, zostałeś cztery godziny. Negatywne konsekwencje: koszty sesji, które trwały za długo lub toczyły się zbyt swobodnie - kod, którego nie rozumiesz na produkcji, sen, którego nie dostałeś, review, które ostemplowałeś bez czytania. 14 pytań. 3 minuty. Anonimowo.

Nikt cię nie odetnie. Narzędzie nie. Firma nie. Ranking nie. Agent będzie dalej nalewał i chwalił twój gust.

Możliwe, że musisz być swoim własnym barmanem.

---

Źródła:

• Ronacher, A. & Vinegar, B. (2026). State of Agentic Coding, odcinek 5. Podcast.
• Griffiths, M.D. (2005). A ‘components’ model of addiction within a biopsychosocial framework. Journal of Substance Use, 10(4), 191-197.
• Tecno, M. (2026). “Slowing the fuck down.” Wpis blogowy.
• Ronacher, A. (2026). “Some things just take time.” Wpis blogowy.

---

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.