Autonomia, o której piszę w tym tekście, nie była celem – była skutkiem ubocznym. Każdy mój dzień zaczynał się od odpowiadania na pytania własnego systemu. „Czy zatwierdzasz?”, „Czy przesunąć?”, „Czy wykonać?”. 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. Pewnego miesiąca ten sam system przestał pytać o rzeczy, o które wcześniej pytał. Poniżej opisuję, jak do tego doszło i dlaczego nie było to takie proste, jak się wydaje.
Punkt wyjścia: pytania były wszędzie
Mój system już wcześniej potrafił 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 intensywnego treningu na regenerację. Każda z tych rzeczy była sensowna. Każda kosztowała mnie jednak interakcję, a interakcje sumowały się w coś, co zjadało mi więcej energii niż same decyzje.
Zrozumiałem wtedy pewną rzecz: nie chodziło o to, że system pyta za dużo. Chodziło o to, ż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ą.
Pierwszy krok: system, który się uczy z moich odpowiedzi
Zaufanie jako miara, a nie deklaracja
Zamiast od razu dawać 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ę zgadzam, a potem zanotował wynik. Jeśli przez kolejne razy zgadzałem się – krytyczne pięć razy z rzędu dla danego typu działania – system uznawał, że dobrze zna moje intencje w tej konkretnej sprawie, i sam zmieniał tę jedną operację z trybu „zapytaj” na tryb „wykonaj i pokaż mi wynik”.
To był bardzo ostrożny projekt i bardzo celowy. Nie dałem systemowi władzy nad wszystkim naraz, tylko nad pojedynczymi decyzjami, jedna po drugiej. Każda z nich awansowała osobno, po własnych dowodach. Nikt nie musiał mi tłumaczyć, dlaczego coś działa – mogłem po prostu zobaczyć, że po pięciu zgodach na jedną rzecz system przestał pytać właśnie o tę rzecz.
I to przyniosło coś, czego nie planowałem: raporty, które zastąpiły pytania. Zamiast „czy wykonać?”, dostawałem po fakcie informację „wykonałem, oto wynik, oto dlaczego”. Różnica jest ogromna. Pytanie wymaga mojej uwagi w momencie, kiedy jestem najmniej nią dysponowany. Raport po fakcie mogę przejrzeć, kiedy mi pasuje.
Drugi krok: to, czego nie chciałem, system musiał nadal pytać
Granice, których nie oddałem nigdy
Równolegle z awansowaniem zaufania zacząłem świadomie zamykać drzwi na niektóre rzeczy, których nie zamierzałem oddawać maszynie. Lista była krótka i wynikała z zasady, którą przyjąłem: 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ć przesunięcia, ale tam, gdzie decyzja jest ostateczna, nadal pyta.
- Zdrowie – system może zdecydować o zamianie treningu na regenerację, bo to cofnąć łatwo. Ale nie zdecyduje za mnie o czymś, czego nie odwrócę jednym kliknięciem.
- Wszystko, co wychodzi pod moim nazwiskiem publicznie – nigdy nie awansuje powyżej propozycji. Wizerunek i reputacja to coś, czego żaden algorytm nie powinien dotykać samodzielnie.
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żda ze swoim progiem.
Miesiąc, w którym przestał pytać
Jeden miesiąc bez ani jednego pytania
W pewnym miesiącu zauważyłem, że nie pamiętam dnia, w którym odpowiedziałem systemowi na pytanie. Zamiast tego zacząłem zauważać rzeczy inne: moje spotkania przesuwały się zanim je zobaczyłem, trening zamieniał się w regenerację zanim poczułem zmęczenie, budżet w kategoriach pilnował się sam, a ja dostawałem podsumowanie, nie pytanie.
To było dokładnie to, o co chodziło. Ale nie było to „magicznie zrobiłem system, który działa sam”. W tle działo się coś mniej efektownego, ale ważniejszego:
- pełna władza tylko na to, co przeszło własne testy, a nie na wszystko naraz,
- granice, których nie ruszam, nawet jeśli system mógłby tam wejść,
- każde wykonane działanie zapisane z wynikiem i powodem, żebym mógł to później zweryfikować lub cofnąć,
- tryb wycofania, który testowałem zanim coś włączyłem na stałe.
I jedna rzecz, którą zrozumiałem dopiero w tym miesiącu: prawdziwa autonomia nie oznacza, że system decyduje lepiej ode mnie. Oznacza, że przejmuje to, co i tak musiałbym zrobić, i nie robi tego wtedy, kiedy akurat jestem zajęty albo rozdrażniony.
Lekcja z tego samego miesiąca: kiedy przestaje się pytać, zaczyna się obserwacja
Autonomia wymaga obserwacji, a nie zaufania
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 od razu, że przestał pytać, bo nie pytał. A kiedy przestał działać – zupełnie po cichu – nie byłem w stanie zareagować, bo nie miałem żadnego sygnału, że coś się zatrzymało.
Wtedy zbudowałem coś, czego wcześniej nie miałem: dodatkowy nadzorca, działający z innej maszyny, sprawdzający, czy mój system w ogóle odpowiada. Powód był konkretny. W pewnym momencie mój system po prostu zawiesił się na 65 minut – ostatni zapis na dysku był o 17:11:38, po czym cisza, aż do ręcznego restartu o 18:16. Komputer odpowiadał na pingi, widać było, że działa, ale żadne z moich wewnętrznych zabezpieczeń nie zadziałał, bo wszystkie działają w obrębie tej samej maszyny. Zawiesiły się razem z nią, dokładnie w tej samej sekundzie.
To była dla mnie najważniejsza lekcja tego miesiąca: zabezpieczenie, które działa wewnątrz chronionej maszyny, nie jest zabezpieczeniem. Po tym incydencie dodałem drugiego obserwatora, uruchamiany na innej maszynie, który sprawdza, czy mój system w ogóle odpowiada – ostrzega po trzech kolejnych niepowodzeniach, alarmuje po dziesiątym. System, który działa w milczeniu, okazał się tak samo niebezpieczny jak system, który krzyczy, tyle że ten drugi przynajmniej o sobie mówi.
Dodatkowo nauczyłem się dwóch rzeczy o awariach, o których wcześniej nie myślałem:
- System, który „nie działa”, nie zawsze znaczy, że jest zepsuty. Kilka tygodni wcześniej miałem podobny przypadek: obciążenie skoczyło do około 12 na czterech rdzeniach przy prawie 98% zajętości procesora, po czym CPU spadł do zera na mniej więcej sto minut. Komputer wyglądał na włączonego, ale nic się nie działo. System nie był zepsuty – był zakleszczony. To zupełnie inna awaria, która wymaga zupełnie innej reakcji, niż padnięty skrypt.
- Autonomia nie znaczy, że nie potrzebuję awaryjnego hamulca. Znaczy, że hamulec musi działać niezależnie od tego, czy system działa, czy nie. Dopiero wtedy mój system przestał być eksperymentem.
Gdybym miał zacząć jeszcze raz, zrobiłbym to inaczej
Podsumowując to, co zrozumiałem w tym miesiącu – i co jest dla mnie teraz oczywiste. Autonomia jest efektem ubocznym porządku, nie celem dojścia:
- Buduj autonomię pojedynczymi decyzjami, nie globalnym przełącznikiem. Kolejne operacje awansują niezależnie, po swoich dowodach.
- Najpierw ustal, czego nigdy nie oddajesz. Granice, które raz wyznaczyłeś, są warte więcej niż nieograniczona władza.
- Zamień pytania na raporty po fakcie. Pytanie odbija uwagę w złym momencie; raport ją oszczędza.
- Przetestuj tryb wycofania, zanim coś włączysz na stałe – Home Assistant daje do tego gotowe narzędzia. Automatyzacja bez odwrotu to nie autonomia, tylko ryzyko. W hardware u mnie robi to Arduino z fizycznym wyłącznikiem.
- Daj systemowi sposób na zgłaszanie, że sam nie działa. Cicha awaria jest gorsza od głośnej, bo jej nie zauważasz w porę.
- Autonomia to nie brak pytań, tylko brak pytań tam, gdzie naprawdę nie są potrzebne. Jeśli Twój system nigdy nie pyta, to prawdopodobnie nie jest autonomiczny – jest po prostu wyłączony, albo awaria, której nie widzisz.
Miesiąc, w którym mój system przestał pytać, nie był momentem „włączyłem AI i zadziałało”. To był miesiąc, w którym zdefiniowałem granice, wykazałem, że system ich nie przekracza, i dopiero wtedy przekazałem mu władzę, na którą zasłużył. Pełną architekturę trzymam na GitHubie. Tak wygląda dla mnie dojrzała autonomia: nie pełna swoboda, tylko pewność, że maszyna zrobi dokładnie to, na co się zgodziłeś, i zatrzyma się tam, gdzie powiedziałeś „nie”.
Materiały powiązane: Automation-First Living na Substack · eBook Automation-First Living · Projekt w wersji publicznej (MIT) · wcześniej na tym blogu: Od automatyzacji do autonomii · Mój cyfrowy bliźniak · 10 automatyzacji, które faktycznie działają · Siedem lat z Home Assistant
