Chcę ci pokazać, jak przestać prosić sztuczną inteligencję o pojedyncze przysługi i zamiast tego zbudować dla siebie coś stałego: osobisty system operacyjny AI. To nie system w sensie Windowsa czy macOS. To jeden projekt, który zna twoją firmę, ma dostęp do twoich narzędzi i potrafi powtarzalnie wykonywać twoją pracę — także wtedy, gdy ty śpisz. Budujesz go w narzędziu o nazwie Claude Code, a ja będę dalej nazywać ten system skrótem AIOS (od angielskiego AI operating system).
Uprzedzę od razu: to nie jest gotowy przepis „kliknij tu, potem tam”. Każdy prowadzi swoją pracę inaczej — ma inne narzędzia, inne dane, inne priorytety. Dlatego daję ci sposób myślenia i kilka ram, które wypełnisz po swojemu. Obiecuję jedno: po przeczytaniu tego tekstu będziesz wiedzieć, jak zbudować taki system od zera, nawet jeśli nigdy wcześniej nie otwierałeś Claude Code.
Zacznę od dwóch pojęć, bo wracają w całym tekście. Claude Code to narzędzie, w którym model Claude pracuje na twoim komputerze — czyta pliki, uruchamia kroki, korzysta z innych programów. Działa w terminalu albo w edytorze kodu, ale ja używam go nie do programowania, tylko do prowadzenia codziennej pracy. Agent to po prostu model, który działa samodzielnie: dostaje cel i sam decyduje, jakie kroki wykonać, zamiast czekać na każde kolejne polecenie. Tyle teorii. Plan na dziś jest prosty: najpierw poukładasz głowę, potem opiszę cztery filary dobrego systemu, a na końcu zbudujesz go w praktyce — od pustego projektu po rutyny działające bez ciebie.
Najpierw głowa, dopiero potem narzędzie
Najczęstszy błąd, który widzę, to skok od razu do klikania. Człowiek instaluje narzędzie, próbuje „zautomatyzować wszystko” w jeden wieczór, po dwóch dniach się zniechęca i wraca do starych nawyków. Dlatego pierwszy etap jest czysto mentalny. Lubię go ujmować w trzy słowa: nastawienie, metoda, maszyna (po angielsku trzy razy „M”: mindset, method, machine). Maszyna — czyli samo narzędzie — jest ostatnia, nie pierwsza. To celowe.
Zacznij od nastawienia, bo to fundament. Pytanie nigdy nie brzmi „czy AI zrobi to za mnie?”, bo to pytanie zerojedynkowe i prawie zawsze odpowiedź brzmi „nie do końca”. Właściwe pytanie brzmi: „w jakim stopniu mogę się tu wesprzeć AI?”. Każde zadanie ma jakiś procent, który da się oddać — czasem 30, czasem 60, rzadko zero. Nawet jeśli system zrobi za ciebie połowę nudnej roboty, to wciąż połowa mniej. Z tego nastawienia rodzą się trzy nawyki, które chcę ci wpoić.
Pierwszy nawyk nazywam domyślnym odruchem. Zanim zaczniesz jakiekolwiek zadanie, zadaj sobie pytanie: „jak mógłby to zrobić mój system, choćby w jednej trzeciej?”. Z czasem ten odruch staje się tak silny, że jeśli coś jest nudne albo powtarzalne, pierwsza myśl brzmi „niech zrobi to mój system”, a nie „zrobię to ręcznie”. To nie jest motywacja na hasło — to soczewka, przez którą patrzysz na swój dzień i wyłapujesz te procenty do oddania.
Drugi nawyk to rozkładanie roli na funkcje. Twoja praca to nie jeden wielki blok, tylko zbiór drobnych czynności. „Zautomatyzuj cały proces tworzenia raportu” brzmi jak góra nie do ruszenia. Ale jeśli rozbijesz raport na kawałki — zebranie danych, ułożenie struktury, napisanie wstępu, sprawdzenie liczb — okaże się, że każdy kawałek da się oddać osobno. Automatyzujesz jeden element naraz, a po jakimś czasie patrzysz i widzisz, że osiemdziesiąt procent procesu robi się już bez ciebie. Małe kroki, nie wielki skok.
Trzeci nawyk to zasada ciekawości. Nigdy nie przyjmuj odpowiedzi systemu bez pytania „dlaczego”. Traktuj AI jak mentora, nie jak automat z przekąskami. Automat bierze monetę i wydaje produkt; mentor zadaje pytania, popycha cię, podsuwa pomysły i czasem mówi, że się mylisz. Brzmi to miękko, ale ma twardy powód: jeśli ślepo wklejasz to, co dostajesz, przestajesz rozumieć własną pracę. Nie musisz umieć czytać kodu ani znać się na technologii — musisz tylko rozumieć, co i dlaczego twój system dla ciebie robi.
To tyle o nastawieniu. Metoda — drugie „M” — to osobna umiejętność: jak decydujesz, co w ogóle warto automatyzować i jak głęboko. Wrócę do niej w praktyce, bo najłatwiej ją pokazać na konkretach. Maszynę, czyli narzędzie i jego ustawienia, zostawiam na sam koniec — bo nie ma sensu kręcić śrubek, zanim wiesz, co właściwie budujesz.
Dlaczego warto przejść przez chwilowy spadek
Muszę cię uczciwie ostrzec przed jedną rzeczą, bo bez tego wielu ludzi się poddaje. Na początku twoja produktywność spadnie, zanim wzrośnie. Konfiguracja zajmuje czas, uczysz się nowego sposobu pracy, więc przez pierwsze dni będziesz wolniejszy. To naturalne — i tu kryje się pułapka.
Wyobraź sobie samodzielną osobę, która przez trzydzieści dni buduje swój AIOS. W pierwszych dniach jej wydajność wyraźnie spada, bo dostraja się do nowego sposobu działania — w praktyce o jakąś jedną piątą w dół względem normalnego rytmu. Gdyby patrzyła tylko na ten tydzień, uznałaby cały pomysł za błąd. Ale właściwe pytanie nie brzmi „czy jest spadek”. Brzmi: „czy późniejszy zysk będzie większy niż ten chwilowy dołek?”. Jeśli ten sam system daje potem trwałe przyspieszenie — na przykład o połowę szybszą pracę — to oddanie jednej piątej na starcie wychodzi mocno na plus. Liczby podaję jako rząd wielkości, nie obietnicę; chodzi o sam mechanizm.
Do tego dochodzi krzywa uczenia. Ludziom się wydaje, że uczenie idzie po linii prostej: tyle samo włożysz, tyle samo dostajesz. Tak nie jest. Długo wydaje się, że nic nie drgnęło, a potem nagle przeskakujesz poziom wyżej. To znaczy, że najgorszy moment jest zawsze na początku — dokładnie wtedy, gdy najłatwiej zrezygnować. Mówię ci o tym nie po to, żebyś się zniechęcił, tylko żebyś się nie poddał po pierwszym dniu.
I jeszcze jedno, zanim przejdziesz do budowy. System daje zwrot tylko wtedy, gdy z niego korzystasz. To banał, ale prawdziwy: dostajesz tyle, ile włożysz. Konfiguracja, do której nigdy nie wracasz, nie da ci nic — będzie tylko ładnie wyglądającym folderem. Cały sens jest w codziennym używaniu, nawet niedoskonałym.
Cztery filary dobrego systemu
Skoro głowa poukładana, pokażę ci, z czego dobry system operacyjny AI się składa. Lubię cztery słowa — po angielsku wszystkie na literę „C”, a tu budują się jedno na drugim: kontekst, połączenia, zdolności, rytm. Kolejność nie jest przypadkowa. Idziesz od pierwszego do czwartego i nie da się przeskoczyć — nie ma rytmu bez połączeń, ani zdolności bez kontekstu.
Kontekst to wszystko, co system wie o tobie i o firmie: czym się zajmujesz, co sprzedajesz i komu, jak się komunikujesz, jakie masz priorytety na bieżący kwartał, jak wygląda twój pieniądz. Jest prosty test, czy go masz. Otwórz nową rozmowę z Claude Code i zadaj pytanie o swoją pracę. Jeśli system odpowiada jak ktoś, kto poznał cię pięć sekund temu — kontekstu brak. Jeśli odpowiada jak współpracownik, który zna twoją sytuację — jesteś na dobrej drodze.
Połączenia to dostęp do narzędzi i danych, w których ten kontekst realnie żyje. Samo Claude Code potrafi w zasadzie tylko przeszukiwać internet — a twoich najważniejszych danych nie ma publicznie w sieci. Są w twoim kalendarzu, poczcie, systemie zadań, notatkach ze spotkań. Te połączenia robi się na kilka sposobów, do których jeszcze wrócę: przez MCP (ustandaryzowany sposób, w jaki narzędzie udostępnia swoje dane sztucznej inteligencji), przez API (interfejs, którym programy „rozmawiają” ze sobą) albo przez zwykłe polecenia w terminalu.
Zdolności to konkretne rzeczy, które system potrafi zrobić z tymi danymi. Sam kontekst i połączenia to dopiero biblioteka i klucze do szafek — zdolności są tym, co system faktycznie umie wykonać: napisać post, przygotować zestawienie, podsumować spotkanie. Prawdopodobnie masz już w głowie albo w dokumentach wiele takich procedur. Chodzi o to, żeby je przekazać systemowi, żeby robił je tak samo dobrze jak ty.
Rytm (po angielsku cadence) to czwarty i, moim zdaniem, najciekawszy filar. To moment, w którym system działa sam według harmonogramu — także gdy komputer jest uśpiony — i zaczyna przypominać pracownika dostępnego całą dobę. Ale rytm jest na końcu nie bez powodu: zanim coś będzie działać samo, musi mieć dostęp do danych (połączenia) i umieć daną rzecz zrobić (zdolności), a żeby umiało ją zrobić sensownie — musi cię znać (kontekst).
Te cztery filary to też twoja lista kontrolna. Kiedy system już stoi, możesz zapytać go wprost, w których z czterech obszarów jest mocny, a gdzie ma luki — i tak wyłapać, czego brakuje. Ale po kolei. Najpierw trzeba ten system w ogóle postawić.
Szkielet systemu: mapa, projekt i główna instrukcja
Teraz przechodzisz do działania. Punkt wyjścia jest celowo analogowy: weź kartkę papieru albo otwórz pusty dokument i rozpisz swoje narzędzia. Nie wchodź jeszcze do żadnego programu — najpierw naszkicuj wszystko w głowie, bo inaczej coś pominiesz. A jeśli pominiesz, to żaden dramat, zawsze dołożysz później.
Rozpisz swoją pracę w siedmiu obszarach, których używam jako szkieletu: przychód, klient, kalendarz, komunikacja, zadania, spotkania i wiedza. To siedem „wiader”, do których wpada prawie wszystko, co robisz, a układają się w cztery większe grupy: operacje, komunikacja, dane i planowanie. Przy każdym obszarze dopisz, jakiego narzędzia używasz — gdzie trzymasz zadania, gdzie masz kalendarz, czym nagrywasz spotkania. To twoja mapa tego, co system będzie potem łączył.
Dopiero z tą mapą tworzysz sam projekt w Claude Code. W jego sercu leży plik o nazwie CLAUDE.md — to „główna instrukcja” całego projektu. Opisuje, czym jest twój system, co znajduje się w którym folderze i kiedy ma sięgać po daną umiejętność. Pomyśl o nim jak o przewodniku, który system czyta na starcie, żeby wiedzieć, gdzie co leży. Obok niego porządkujesz kilka folderów: jeden na kontekst (co system wie o tobie i firmie), jeden na decyzje (dziennik ważnych ustaleń, żeby pamiętał, co już postanowiliście), jeden na referencje (materiały do podglądania). Za każdym razem, gdy dokładasz nowy folder albo plik, dbasz, by CLAUDE.md o tym wiedział — inaczej system nie będzie umiał tam trafić.
Wdrożenie przez rozmowę: siedem pytań
Najlepsze jest to, że nie wypełniasz tych folderów ręcznie. Wdrożenie zaczyna się od rozmowy. Uruchamiasz przygotowaną wcześniej procedurę, a system przeprowadza z tobą wywiad z siedmiu pytań i sam zapisuje odpowiedzi jako swój kontekst. To trochę jak pierwszy dzień nowego pracownika, który zadaje ci pytania, żeby się wdrożyć.
Pierwsze pytanie brzmi: „kim jesteś, co sprzedajesz i komu?”. Tu nie skąp słów — im więcej kontekstu dasz, tym lepiej system będzie cię potem rozumiał. Drugie pytanie prosi, żebyś wkleił jedną czy dwie rzeczy, które ostatnio napisałeś, bez poprawiania — system uczy się w ten sposób twojego sposobu pisania i tonu. Trzecie pytanie dotyczy dwóch–trzech najważniejszych priorytetów na najbliższe 90 dni, czyli tego, nad czym realnie teraz pracujesz. Kolejne pytania idą podobnym tropem, schodząc głębiej w to, jak działasz. Odpowiadasz na wszystkie siedem, a system na końcu melduje, że dzień pierwszy gotowy: wie już, kim jesteś, co sprzedajesz, co się liczy w tym kwartale i jak brzmisz.
Od tej chwili możesz go zapytać o coś praktycznego — na przykład „na czym powinienem się skupić w tym tygodniu?” — i dostaniesz odpowiedź osadzoną w twojej sytuacji, a nie ogólnik. To jest dokładnie ten moment, w którym kontekst zaczyna pracować. Masz pierwszy z czterech filarów.
Zdolności: ucz system raz, korzystaj wielokrotnie
Teraz najważniejsze pojęcie całej budowy — umiejętności (po angielsku skills). To wielokrotnego użytku instrukcje zapisane w prostych plikach tekstowych. Najlepsza analogia to przepis kulinarny. Wyobraź sobie, że za każdym razem, gdy chcesz upiec ciasto, musisz komuś od nowa tłumaczyć całą procedurę krok po kroku. Męczące. Zamiast tego spisujesz przepis raz, a potem mówisz tylko „upiecz to ciasto” — i wszystko się dzieje.
Tak samo działa umiejętność. Załóż, że często piszesz posty na LinkedIn, a za każdym razem robisz to samo: szukasz informacji, przygotowujesz grafikę, piszesz tekst, sprawdzasz go i publikujesz. Zamiast tłumaczyć tę sekwencję przy każdym poście, spisujesz ją raz jako umiejętność. Potem mówisz „napisz mi post na LinkedIn”, system czyta swój przepis i wykonuje całą procedurę. Efekt jest bardziej przewidywalny i lepszej jakości, bo system zawsze idzie tą samą, sprawdzoną ścieżką.
Najlepsza część przychodzi, gdy chcesz coś zmienić. Jeśli kolejne ciasto ma być inne, nie zaczynasz od zera — poprawiasz jedno zdanie w przepisie („zamiast jednego jajka daj dwa”) i przy następnym uruchomieniu zmiana po prostu działa. Twoje umiejętności wciąż się rozwijają, tak jak ty. To jest prawdziwa dźwignia tego systemu: opisujesz swoją powtarzalną pracę raz, a potem uruchamiasz ją wielokrotnie, ulepszając po drodze.
Jak zbudowana jest jedna umiejętność
Każda umiejętność to jeden plik tekstowy o przejrzystej budowie. Na górze, w krótkim nagłówku, są dwie kluczowe rzeczy: nazwa i opis — czyli jak umiejętność się nazywa i do czego służy albo kiedy jej użyć. To ważne, bo właśnie po tym system rozpoznaje, której umiejętności użyć. Gdy poprosisz o post na LinkedIn, Claude Code przegląda wszystkie umiejętności, ale czyta tylko te krótkie nagłówki — nazwę i opis — i dobiera pasującą. Dlatego opis musi jasno mówić, kiedy daną umiejętność uruchomić.
Pod nagłówkiem opisujesz resztę: co umiejętność robi, czasem też czego nie robi (żeby system nie wychodził poza zakres), a potem kroki po kolei — krok pierwszy, krok drugi, krok trzeci. To w gruncie rzeczy spisana procedura, twoje firmowe „jak to robimy”, tylko w formie, którą system rozumie i wykonuje. Jeśli żadna z twoich umiejętności nie pasuje do polecenia, system po prostu korzysta z wiedzy ogólnej.
Dobra wiadomość: nie musisz budować wszystkich umiejętności sam. Część zbudujesz naturalnie — zauważasz, że coś robisz w kółko, więc spisujesz to jako przepis. Inne możesz pobrać z gotowych bibliotek umiejętności i dodać do nich własny smak. Jedno zastrzeżenie, które muszę dać: uważaj, skąd je bierzesz, i sprawdzaj, czy ktoś nie podsuwa ci umiejętności ze szkodliwą zawartością. Skoro umiejętność potrafi działać w twoim imieniu, traktuj ją z tą samą ostrożnością co każdy program, który wpuszczasz do swojej pracy.
Połączenia i rytm: system, który działa, gdy śpisz
Masz już kontekst i zdolności. Wracam teraz do połączeń, bo bez nich system zna ciebie, ale nie sięga do twoich danych. Połączysz go po kolei z narzędziami z twojej mapy siedmiu obszarów — kalendarzem, zadaniami, spotkaniami. Tu pojawia się decyzja, którą chcę ci wyjaśnić, bo łatwo ją przegapić, a ma znaczenie.
Gdy prosisz system o podłączenie jakiegoś narzędzia, sam zwykle zaproponuje najszybszą drogę, czyli MCP — jeśli dla danego narzędzia taki gotowy łącznik istnieje. Działa, ale ma wadę: każdy taki łącznik załadowany do projektu zżera trochę „pamięci roboczej” systemu (po angielsku mówi się o zużyciu tokenów — to jednostki, w których model liczy, ile naraz może objąć). Dlatego ja częściej wybieram drogę przez API, bo jest oszczędniejsza. W praktyce mówisz systemowi mniej więcej tak: „chcę połączyć się z tym narzędziem przez jego API, bo to oszczędniejsze niż gotowy łącznik; przejrzyj dokumentację narzędzia i zapisz w projekcie plik referencyjny ze wszystkimi potrzebnymi adresami”. System sam to przygotuje, a ty masz odtąd porządne, lekkie połączenie.
Co ważne, nie każde narzędzie ma gotowy łącznik czy nawet jawną dokumentację — i to też nie problem. Zawsze jest jakaś droga: w ostateczności system może sterować narzędziem przez przeglądarkę, klikając w nim tak, jak zrobiłbyś to ty. Rada praktyczna: nie podłączaj wszystkiego naraz. Zacznij od kilku najważniejszych rzeczy, których używasz najczęściej — choćby zadań i spotkań — a resztę dokładaj z czasem. To znów ta sama zasada: małe kroki zamiast wielkiego skoku.
Rytm: rutyny lokalne i te w chmurze
Na koniec czwarty filar — rytm. Budujesz go za pomocą rutyn: zaplanowanych poleceń, które system wykonuje sam według harmonogramu — codziennie rano, w wybrane dni tygodnia, regularnie. Rutyna to nic skomplikowanego: to po prostu zapisane polecenie, które o ustalonej porze zostaje „wpisane” do systemu tak, jakbyś sam je wpisał i wcisnął enter. System uruchamia wtedy zwykłą rozmowę i wykonuje to, o co prosisz — często odpalając przy okazji którąś z twoich umiejętności.
Tu jest jedno rozróżnienie, które musisz znać, bo łatwo się na nim potknąć. Rutyny bywają lokalne albo w chmurze. Lokalna działa tylko wtedy, gdy aplikacja na twoim komputerze jest otwarta — komputer musi być włączony. Rutyna w chmurze działa nawet wtedy, gdy aplikacja jest zamknięta, a komputer wyłączony, bo wykonuje się na serwerach dostawcy. To właśnie dzięki niej system zaczyna przypominać pracownika dostępnego całą dobę: rano dostajesz gotowe podsumowanie, choć w nocy nikt niczego nie klikał.
Muszę dać tu uczciwe ograniczenie, żebyś nie planował ponad stan. Liczba rutyn działających w chmurze bywa limitowana planem subskrypcji — przykładowo na jednym z droższych planów (rzędu dwustu dolarów miesięcznie) można mieć jednocześnie kilkanaście takich zdalnych rutyn dziennie. To konkretna liczba dla konkretnego planu, a nie reguła ogólna — sprawdź, co daje twój. Dla większości osób kilkanaście dobrze dobranych rutyn to i tak więcej, niż wykorzystają na start.
Warto wiedzieć jeszcze jedno: każda rozmowa z systemem jest osobna. Jeśli rutyna ustawiła jakieś zadanie w jednym oknie, to system w drugim oknie domyślnie o nim nie wie, dopóki sam go nie sprawdzi. To nie wada, tylko cecha — pamiętaj o niej, gdy zaczniesz mieć kilka rzeczy w toku naraz.
Co naprawdę się zmienia i od czego zacząć
Kiedy ten system zaczyna działać na co dzień, zmieniają się trzy rzeczy — i to one są prawdziwą nagrodą, nie sama konfiguracja.
Po pierwsze, wiedza wychodzi z twojej głowy i ląduje w jednym miejscu. Przestajesz nosić wszystko w pamięci, przestajesz oblepiać biurko karteczkami. System pamięta za ciebie, przypomina o terminach, pilnuje, żeby nic nie wypadło. Przestajesz też być wąskim gardłem — bo bywa, że to system ma o danej sprawie więcej zebranego kontekstu niż ty w danej chwili.
Po drugie, przestajesz otwierać dziesiątki kart i aplikacji. Coraz więcej pracy dzieje się w jednym miejscu, więc kończy się ciągłe przeskakiwanie między oknami i gubienie wątku. Po trzecie, dochodzi rytm: część zadań po prostu dzieje się sama, według harmonogramu, bez twojego udziału. To trzy filary z innej strony — kontekst, zdolności i rytm — tym razem widziane jako codzienna zmiana w twoim dniu, a nie jako lista do zbudowania.
I jeszcze jedna rzecz, o której wspomniałam mimochodem, a która zasługuje na własne zdanie. Cały ten system jest opisany w plikach tekstowych — co oznacza, że da się go przenieść. Ten sam układ, który zbudujesz dla siebie, można powielić: dla współpracownika, dla zespołu, docelowo dla klienta, dostrajając go do ich realiów. Stąd bierze się druga połowa pomysłu, ta o „sprzedawaniu” — ale to już osobny temat, do którego dojdziesz dopiero wtedy, gdy system sprawdzi się u ciebie samego.
Najważniejszy wniosek nie jest techniczny. Nie musisz zbudować wszystkiego za pierwszym razem ani osiągnąć perfekcji. Zacznij od małego — od kontekstu i jednej, dwóch umiejętności, których naprawdę użyjesz — i rozbudowuj system w miarę korzystania, bo razem z tobą uczy się i on. Spójrz na swoją powtarzalną pracę jak na coś, co da się raz porządnie opisać, a potem uruchamiać wielokrotnie. Otwórz pustą kartkę i wypisz te siedem obszarów dla siebie. To jest cały pierwszy krok — i jedyny, od którego trzeba dziś zacząć.