Autonomia nie była u mnie celem, była skutkiem ubocznym. Najpierw musiałem przestać być operatorem własnego systemu.
Problem: system pytał o wszystko, a ja odpowiadałem
Mój system potrafił już wtedy dużo: łączyć dane z kilkunastu źródeł, prognozować, przygotowywać rekomendacje. Ale prawie każda istotna operacja kończyła się tym samym pytaniem: „czy mam to wykonać?”. Blokada kalendarza pod niską gotowość, przesunięcie spotkania, przelew między kategoriami budżetu, zamiana treningu na regenerację. Każda z tych rzeczy była sensowna i każda kosztowała mnie interakcję.
Interakcje sumowały się w coś, co zjadało mi więcej energii niż same decyzje. Wyglądało to normalnie, ale w pewnym momencie zrozumiałem, że to nie jest kontrola — to jest praca. Czułem się operatorem własnego życia, a powinienem być jego właścicielem.
Problem nie polegał na tym, że system pytał za dużo. Polegał na tym, że nie umiał sam rozstrzygnąć, kiedy pytanie ma sens, a kiedy jest tylko formalnością. Pytanie o przesunięcie spotkania ma sens. Pytanie o potwierdzenie czegoś, co i tak postanowiłbym zrobić, jest stratą — i to stratą w najgorszym momencie, bo pytanie odbija uwagę wtedy, kiedy najmniej nią dysponuję.
Co zbudowałem: licznik zaufania i raport zamiast pytania
Zamiast dać systemowi więcej władzy, zbudowałem coś prostszego: licznik zaufania do każdej pojedynczej operacji. Za każdym razem, gdy podejmowałem decyzję, system sprawdzał, czy się z nim zgadzam, i notował wynik. Jeśli zgadzałem się pięć razy z rzędu dla danego typu działania, system uznawał, że zna moje intencje w tej konkretnej sprawie, i sam przestawiał tę jedną operację z trybu „zapytaj” na tryb „wykonaj i pokaż mi wynik”.
To był projekt celowo ostrożny. Nie dałem systemowi władzy nad wszystkim naraz, tylko nad pojedynczymi decyzjami, jedna po drugiej, każda po własnych dowodach. Nikt nie musiał mi tłumaczyć, dlaczego to działa — widziałem po prostu, że po pięciu zgodach na jedną rzecz system przestał pytać właśnie o tę rzecz.
Przyniosło to coś, czego nie planowałem: raporty, które zastąpiły pytania. Zamiast „czy wykonać?” dostawałem po fakcie „wykonałem, oto wynik, oto dlaczego”. Różnica jest ogromna, bo raport mogę przejrzeć, kiedy mi pasuje.
Na tym samym założeniu stoi kilka pętli, które zostały u mnie na stałe:
- Poranny brief jako jedno wejście. Zamiast pięciu powiadomień w ciągu dnia dostaję jeden komunikat: jak spałem, co mnie czeka, co najważniejsze. Składam go z kilku źródeł, ale dla mnie to jedno źródło. Wartość jest w redukcji liczby decyzji, nie w samej treści.
- Poranny raport pogody technicznej: co zepsute, co wolne, co czeka. Przegląd stanu usług, zasobów i błędów, zanim wypiję kawę, składany z liczb z Prometheusa. Raport, który mówi „wszystko gra”, jest równie ważny jak ten, który mówi „padło”. Wariant, w którym dostaję alert dopiero wtedy, gdy coś przestaje działać, jest zbyt późny.
- Podsumowanie dnia w jednej notatce. Wieczorem sen, trening, finanse, zadania i decyzje lądują w jednym miejscu. Nie służy to refleksji — służy temu, że patrząc na dzień w całości, widzę wzorce, których nie widzę z perspektywy pojedynczej godziny.
- Przypomnienia o rzeczach, o których nie myślę na co dzień. Urodziny, rocznice, przeterminowane rzeczy, leki, coroczny przegląd. Nie „inteligentne” rzeczy, tylko te, które wypadają mi z głowy. Tu nie ma magii, jest tylko ulga.
- Ciche raporty zamiast alarmów. Wszystko trafia do jednego panelu w Grafanie. Jeśli wszystko działa, system do mnie nie pisze; pisze tylko wtedy, gdy coś wymaga decyzji.
Reguła, którą z tego wyniosłem i wdrożyłem wszędzie: powiadomienie musi nieść decyzję, nie informację. Jeśli po przeczytaniu nie mam czego wybrać, to nie powinno przychodzić.
Co wyłączyłem, bo kosztowało więcej, niż dawało
Ta część jest dla mnie cenniejsza od poprzedniej, bo każda z tych rzeczy kosztowała mnie realny czas i uwagę, zanim ją wyłączyłem.
Automatyczne usuwanie starych zadań. Reguła kasowała zadania „zbyt stare” i „nieważne”. W pierwszym tygodniu usunęła kilka rzeczy, o których rzeczywiście zapomniałem. W drugim — trzy rzeczy, które były odłożone celowo i których wykonanie było priorytetem, tylko nie w tym tygodniu. Udało mi się to zauważyć, ale zaufanie do automatycznego usuwania zginęło. Zostawiłem to jako czynność ręczną i nie zamierzam wracać.
Podsumowanie każdego wykonanego zadania. Każda zautomatyzowana operacja wysyłała notyfikację „zrobione”. Po kilku dniach zacząłem wyłączać je hurtem, bo nie czytałem żadnej — a wyłączanie hurtem wyłączało też te, które były naprawdę ważne.
Nadmiar powiadomień informacyjnych. Ten sam mechanizm w większej skali: skończyło się tym, że ignorowałem wszystkie, także krytyczne.
Filtr, przez który przechodzi dziś każda nowa pętla, ma trzy warunki: powtarzalna, tania w utrzymaniu, tania w odwróceniu. Ostatni jest najważniejszy i najczęściej lekceważony. Do tego dochodzi warunek, który brzmi biurokratycznie, a ratuje sytuację: pisana instrukcja dla każdej automatyzacji jest częścią automatyzacji. Jeśli nie umiem jednym zdaniem powiedzieć, co ona robi i kiedy ją wyłączyć, to nie jest gotowa do pracy. I nie awansuję poziomu autonomii, dopóki coś poprawiam „na bieżąco” — wtedy to jeszcze nie jest autonomia, tylko asystent, który potrzebuje nadzoru.
Granice, cisza i czego nie zmierzyłem
Równolegle z awansowaniem zaufania zamykałem drzwi na rzeczy, których nie zamierzałem oddawać. Lista jest krótka i wynika z jednej zasady: szkoda w domenie, w której da się ją cofnąć, jest inna niż w domenie, w której nie ma odwrotu. Pieniądze — system może proponować, ale tam, gdzie decyzja jest ostateczna, nadal pyta. Zdrowie — może zamienić trening na regenerację, bo to cofnę jednym kliknięciem, ale nie zdecyduje o czymś, czego nie odwrócę. I wszystko, co wychodzi pod moim nazwiskiem publicznie — to nigdy nie awansuje powyżej propozycji.
Ustalenie tych granic okazało się ważniejsze niż samo nadanie władzy, bo dopiero wtedy wiedziałem, co właściwie oddaję: nie „autonomię” jako taką, tylko konkretne, zamknięte zestawy operacji, każdy ze swoim progiem.
W miesiącu, w którym system przestał pytać, zdarzyło się coś, czego nie przewidziałem: straciłem kontrolę nad tym, czy on w ogóle działa. Nie zauważyłem, że przestał pytać, bo nie pytał. Mój system zawiesił się na 65 minut — ostatni zapis o 17:11:38, potem cisza, aż do ręcznego restartu o 18:16. Komputer odpowiadał na pingi, a żadne z wewnętrznych zabezpieczeń nie zadziałało, bo wszystkie działają w obrębie tej samej maszyny i zawiesiły się razem z nią. Dlatego mam dziś osobnego nadzorcę na innej maszynie, który sprawdza tylko jedno: czy system odpowiada. Zabezpieczenie, które działa wewnątrz chronionej maszyny, nie jest zabezpieczeniem.
Stąd wniosek, który brzmi odwrotnie do intuicji: jeśli system nigdy nie pyta, to prawdopodobnie nie jest autonomiczny — jest po prostu wyłączony albo ma awarię, której nie widać. Autonomia to nie brak pytań, tylko brak pytań tam, gdzie naprawdę nie są potrzebne.
Czego nie zmierzyłem i nie będę szacował: ile czasu to wszystko mi zwraca. Nie mam tej liczby dla żadnej z ośmiu dziedzin i opisałem osobno, dlaczego czterokrotnie nie udało mi się jej policzyć. Jedna z przeszkód jest nieusuwalna: dla pętli zbudowanych przed rozpoczęciem pomiarów nie mam punktu odniesienia — ActivityWatch zna u mnie stan „po”, nie zna stanu „przed”. Szacunek własnego dzieła jest najsłabszym rodzajem dowodu, jaki istnieje, a liczba, której nikt nie weryfikuje, zawsze rośnie w kierunku wygodnym dla osoby, która ją podaje.
