Najczęstsze pytanie, jakie słyszę od osób bez technicznego zaplecza, brzmi tak: „skoro w nazwie jest »kod«, to czy ja się do tego w ogóle nadaję?”. Odpowiadam krótko — tak, i to bardziej, niż myślisz. Cała zmiana, o której tu opowiem, polega na tym, że przestajesz pisać cokolwiek w kodzie, a zaczynasz opisywać zwykłym językiem, co ma się wydarzyć. Resztę wykonuje za ciebie wykonawca po drugiej stronie. Umiejętność, którą naprawdę trenujesz, to nie programowanie — to jasne mówienie o tym, czego chcesz.
To jest kurs pisany przy założeniu, że zaczynasz od zera. Mapa drogi wygląda tak: najpierw zrozumiesz, czym właściwie jest to narzędzie i jak z nim rozmawiać, potem ustawisz je u siebie i poznasz kilka pojęć, bez których łatwo o frustrację. Dalej pokażę ci, jak podłączyć własne dane, jak wybrać dobry problem do rozwiązania i jak dzielić pracę między wyspecjalizowanych pomocników. Na końcu zbudujesz coś realnego, nauczysz się puszczać automatyzacje w tle i panować nad limitami, żeby nie utknąć w połowie. Czytasz, próbujesz u siebie, wracasz do trudniejszych fragmentów. To materiał na kilka podejść, nie na jedno popołudnie.
Posłuchaj
Dwoje prowadzących omawia cały kurs — od pierwszego ustawienia i rozmowy zwykłym językiem po klucze API, podagentów i rutyny w tle. Około 23 minuty do odsłuchania w drodze.
Wygenerowane przez NotebookLM, sprawdzone przez AURA.
Czym jest Claude Code i dlaczego „bez kodu”
Zacznę od nazwy, bo to ona odstrasza najbardziej. Claude Code to narzędzie, w którym model Claude wykonuje realną pracę na twoim komputerze — czyta i pisze pliki, przeszukuje sieć, uruchamia kolejne kroki. To nie jest czat, w którym tylko wymieniasz wiadomości; to wykonawca, który buduje rzeczy i sięga do twoich danych. Słowo „kod” w nazwie nie oznacza, że musisz kodować. Oznacza tylko, że to narzędzie ma więcej mocy niż zwykłe okno rozmowy — i że tę moc obsługujesz zwykłym językiem.
Drugie pojęcie, które wraca na każdym kroku, to agent. Agent to wykonawca, który dostaje cel i sam dobiera kroki, zamiast czekać na każde pojedyncze polecenie. Mówisz mu, co ma powstać, a on decyduje, jak to zrobić — czyta pliki, szuka, sprawdza, poprawia. Różnica między czatem a agentem jest mniej więcej taka jak między poradą a pracownikiem: pierwszy odpowiada na pytanie, drugi wykonuje zadanie od początku do końca.
Warto też wiedzieć, że to samo studio, które tworzy modele Claude, daje kilka narzędzi obok siebie. Jest zwykły czat, w którym po prostu rozmawiasz i dostajesz odpowiedź. Jest prostszy interfejs dla osób, które chcą lekkich automatyzacji bez wchodzenia w szczegóły. I jest Claude Code — najmocniejsze z nich, bo pracuje na twoich plikach i sięga dalej niż samo okno rozmowy. Dobra wiadomość jest taka, że pod spodem to te same modele; jeśli nauczysz się jednego narzędzia porządnie, przeniesiesz tę wprawę wszędzie.
Warto od razu ułożyć sobie w głowie prosty obraz. Wyobraź sobie samochód. Silnik to model — surowa inteligencja, sam w sobie do niczego, dopóki nie jest w nic wpięty. Nadwozie to narzędzie, które ten silnik obudowuje i pozwala nim jechać. A za kierownicą siedzisz ty. Najważniejszym elementem tego obrazu nie jest ani silnik, ani samochód, tylko kierowca. Jeśli nie podasz agentowi właściwego kontekstu i celu, nawet najmocniejszy model nie dowiezie cię tam, gdzie chcesz. To dobra wiadomość dla osoby nietechnicznej: liczy się twoja głowa, nie twój kod.
Jest jeszcze jedna rzecz, która odróżnia to narzędzie od zwykłego czatu. Claude Code widzi twoje pliki na dysku i potrafi sięgnąć do usług, których używasz — skrzynki pocztowej, kalendarza, dokumentów. Weź prosty przykład: gdzieś w folderze pobranych masz logo firmy, ale nie pamiętasz nazwy pliku. Mówisz zwykłym językiem, żeby je odnalazło — a ono przeszukuje dysk, rozpoznaje właściwy obraz i pokazuje, gdzie leży. Równie dobrze zbuduje od zera arkusz z analizą albo gotowy dokument. Dzięki temu przestaje przypominać anonimowego asystenta, a zaczyna zachowywać się jak ktoś, kto zna twoją firmę i nie każe ci tłumaczyć wszystkiego od nowa. Dokładnie po to jest ten kurs: żebyś krok po kroku zbudował sobie takiego wykonawcę.
Pierwsze ustawienie i jak z nim rozmawiać
Konkrety. Żeby zacząć, potrzebujesz płatnej subskrypcji Claude — bez niej agent nie ruszy. Potem instalujesz aplikację; masz kilka sposobów, jak z niej korzystać, i żaden nie jest „tym jedynym słusznym”. Możesz pracować w osobnej aplikacji na komputer, w oknie poleceń (terminalu), jako rozszerzenie edytora kodu albo w przeglądarce, gdy chcesz, żeby zadanie chodziło w chmurze. Pod spodem wszystkie robią to samo, a twoje projekty i rozmowy są dostępne niezależnie od tego, który wybierzesz. Jeśli dopiero zaczynasz, weź samodzielną aplikację — jest najczytelniejsza — i nie zamartwiaj się resztą.
Jedną decyzję warto podjąć od razu: którym modelem pracować. Do wyboru masz zwykle kilka — od najszybszego i najtańszego, przez wyważony, po najmocniejszy. Na początku zostaw ustawienie domyślne albo trzymaj się mocniejszego, żeby wyrobić sobie wyczucie, jak wygląda dobra jakość. Na tańszy przełączysz się później, świadomie — na przykład gdy zlecasz prostą, masową robotę i chcesz oszczędzać. Modelu nie wybierasz raz na zawsze; zmieniasz go w locie, zależnie od tego, czy dane zadanie wymaga myślenia, czy tylko mechanicznej pracy. To jeden z tych drobiazgów, które z czasem realnie wpływają na koszt.
Jest jeszcze ustawienie, które daje ci spokój na starcie: tryb pozwoleń. Możesz kazać agentowi pytać przed każdą zmianą, pozwolić mu zmieniać pliki samodzielnie albo — na drugim biegunie — puścić go bez pytania. Jest też tryb planowania, w którym agent może myśleć, czytać i szukać, ale niczego nie zbuduje, dopóki nie zatwierdzisz planu. Na początku trzymaj się właśnie planowania albo trybu, który pyta o zgodę. Dają ci moment na sprawdzenie, czy agent dobrze zrozumiał, zanim cokolwiek ruszy — to najtańsza polisa, jaką masz. I nie martw się zapamiętywaniem specjalnych komend; o niemal wszystko, co narzędzie potrafi, poprosisz zwykłym językiem.
Gdy już rozmawiasz z agentem, cała gra toczy się o jedno: jak jasno formułujesz polecenia. Pod spodem wciąż działa model językowy, więc jakość tego, co dostajesz, jest wprost pochodną jakości tego, co mówisz. Mgliste polecenie daje mglisty efekt. Mam cztery nawyki, które zamieniają przypadkowy wynik w przewidywalny.
Po pierwsze, nadaj agentowi rolę i tło. Zamiast „napisz maila do szefa” powiedz: „jesteś moim asystentem; napisz ostrożnego maila z prośbą o dodatkowy czas, bo temat jest delikatny”. Po drugie, dawaj konkretny kontekst — nie „przeanalizuj wyniki”, tylko czego dotyczą, co jest w nich ważne, do czego ci to potrzebne. Po trzecie, mów też, czego robić nie wolno. To brzmi banalnie, ale działa jak z ciekawym dzieckiem: jeśli nie powiesz „nie dotykaj gorącej patelni”, ono sprawdzi. Granice trzymają agenta na właściwym torze. I po czwarte, każ mu udowodnić swoją pracę. Jeśli budujesz formularz, poproś, żeby sam przetestował go wielokrotnie i sprawdził, czy przepuszcza błędne dane — a potem pokazał ci, co uruchomił i dlaczego jest pewny wyniku. Ta prosta prośba potrafi znacząco podnieść jakość pierwszej wersji.
Jeszcze jedna praktyczna rada: nie musisz wszystkiego wystukiwać na klawiaturze. Mowa jest szybsza niż pisanie, a proste narzędzia do dyktowania — zamiany mowy na tekst — pozwalają opisać zadanie na głos i dopiero potem je dopracować. Dla osoby, która myśli szybciej, niż pisze, to realna oszczędność czasu przy każdym poleceniu.
Model zawsze obecnego asystenta
Chcę, żebyś od początku myślał o tym narzędziu nie jak o wyszukiwarce, do której zaglądasz, gdy masz pytanie, ale jak o asystencie, który jest obecny cały czas. Dobry asystent nie czeka bezczynnie — zna kontekst, zauważa rzeczy w tle i sam zaczyna zadania, zanim o nie poprosisz. Właśnie do tego cię prowadzę.
Żeby agent tak działał, musi wiedzieć to, co ty wiesz. Nazywam to karmieniem właściwym kontekstem, a fachowo mówi się o inżynierii kontekstu — czyli o sztuce podawania modelowi dokładnie tych informacji, których potrzebuje do zadania: co dzieje się w twojej firmie, jakie masz priorytety, co jest w twojej głowie, a czego nie ma w publicznym internecie. To właśnie ten prywatny kontekst — twoja wiedza, twoje materiały — sprawia, że wynik jest twój, a nie generyczny. Gdyby wszyscy pytali ten sam model o to samo bez kontekstu, wszyscy dostawaliby identyczne odpowiedzi.
Oto konkret. Kiedy rano witasz się z dobrze nakarmionym agentem, nie odpowiada ci pustym „w czym pomóc?”. Mówi, co jest na radarze: że w piątek wypada wydarzenie, że jutro mija termin, że wisi nierozstrzygnięta decyzja. Wie to, bo przeczytał stałe instrukcje projektu i materiały o twojej firmie. Ta różnica — między asystentem, który zgaduje, a takim, który zna kontekst — jest sednem tego kursu.
Najprostsze porównanie, do którego wracam, to nowy stażysta. Kiedy ktoś przychodzi pierwszego dnia, siadasz z nim i wprowadzasz go: czym zajmuje się firma, kto za co odpowiada, co jest teraz najważniejsze. Dopiero z tym kontekstem stażysta potrafi coś sensownie wnieść. Bez niego jest tylko bystrą osobą, która zgaduje. Z agentem jest tak samo. Stąd zasada, którą warto zapamiętać na całe życie z tymi narzędziami: śmieci na wejściu, śmieci na wyjściu.
W praktyce oznacza to jeden nawyk: przestań otwierać puste okno rozmowy za każdym razem od nowa. Zamiast tego zakładasz projekt i wrzucasz do niego realne materiały — opis produktu, kalendarz działań, przykłady tego, co kiedyś zadziałało, i tego, co poległo. Przyjmij, że prowadzisz kampanię wokół premiery produktu — zamiast opisywać ją od nowa w każdej rozmowie, raz wrzucasz te materiały do projektu i wracasz do nich, ilekroć potrzebujesz pomysłu. Od tej chwili agent pracuje na twoim kontekście, a nie na ogólnych dobrych praktykach z internetu. To jedna z tych zmian, które nic nie kosztują, a widać je od pierwszego dnia.
Nie ufaj na ślepo: weryfikacja i odpowiedzialność
Im lepsze stają się te narzędzia, tym większa pokusa, żeby brać pierwszy wynik i machnąć ręką: „wystarczy”. To najgroźniejszy moment w całej tej pracy. Na początku sprawdzasz wszystko — czytasz każde zdanie, weryfikujesz każdą liczbę. Potem wyniki robią się dobre, tracisz czujność i zaczynasz ufać na ślepo. Właśnie tam czai się kłopot.
Trzymam się prostej roli: jesteś menedżerem, który zarządza agentem. Menedżer nie przyjmuje pracy bez spojrzenia. Odbierasz to, co agent zrobił, oceniasz własnym rozsądkiem i smakiem, a potem mówisz, co jest dobrze, a co do poprawki — i każesz poprawić. Nie chodzi o to, żeby pierwsza wersja była idealna. Chodzi o to, że każda oddana praca to okazja, żeby ulepszyć system. Twoje nazwisko i tak jest pod tym, co wychodzi. Jeśli wynik jest świetny, zbierasz zasługi; jeśli jest błędny, bierzesz na siebie odpowiedzialność. To, że napisała to maszyna, nikogo nie obchodzi.
Jak wyrobić w sobie ten smak? Podglądaj najlepsze rzeczy w swojej dziedzinie i zbieraj bibliotekę tego, co brzmi jak ty. A gdy poprawiasz wynik, oddawaj tę poprawkę z powrotem: „zmieniłem pięć rzeczy, oto dlaczego, zapisz to sobie na przyszłość”. To nie jest jednorazowa ocena, tylko pętla, która z każdym obiegiem uczy agenta twojego gustu. Warto też z góry ustalić, na co pozwalasz: część drobiazgów agent może wysłać sam, ale większość niech tylko przygotuje do twojej akceptacji. Sam decydujesz, gdzie kończy się wygoda, a zaczyna twoja reputacja.
Powiem to szczerze, bo rzadko się to mówi: gdy efekt jest słaby, najczęściej nie jest to wina modelu, tylko twoja. Niedoprecyzowane polecenie, brakujący dostęp, zbyt mało kontekstu. Weź część odpowiedzialności na siebie, popraw wejście — a wynik podskoczy. Ta postawa odróżnia osoby, które dowożą działające rozwiązania, od tych, które po pierwszym potknięciu mówią „AI nie działa”.
Jest też subtelniejszy powód, żeby czytać uważnie. Ludzie coraz częściej rozpoznają tekst pisany przez model — po nadużywanych myślnikach, po sztucznym rytmie. Sam w sobie fakt użycia AI nie jest problemem; problemem jest chwila, w której odbiorca zaczyna się zastanawiać: „czy ta osoba to w ogóle przeczytała? czy to jest prawda?”. Wtedy traci zaufanie nie do tekstu, lecz do ciebie. Dlatego twoja rola przesunęła się z autora na recenzenta. Można oddać komuś pisanie, ale nie można oddać rozumienia — a to twoje zrozumienie decyduje, czy coś zasługuje na twój podpis.
Z tym łączy się nawyk, który moim zdaniem najszybciej robi z laika kogoś sprawnego: bądź szczerze ciekawy. Kiedy nie rozumiesz, co agent zrobił, po prostu go zapytaj — „co tu zrobiłeś?”, „dlaczego tak?”, „co by się stało, gdybyś zrobił inaczej?”. Traktuj to narzędzie trochę jak mentora, który wszystko cierpliwie wyjaśni. Ludzie, którzy dopytują, łapią resztę zaskakująco szybko. Ci, którzy klikają na ślepo, zatrzymują się na pierwszej niespodziance.
Podłączanie narzędzi i danych — i klucze API bez stresu
Sama rozmowa to dopiero początek. Prawdziwa moc pojawia się, gdy dajesz agentowi ręce — czyli dostęp do narzędzi i danych, których używasz na co dzień. Wbudowane wyszukiwanie w sieci masz od ręki: prosisz o research, a agent sam sięga do internetu. Ale najciekawiej robi się, gdy podłączasz własne konta — pocztę, kalendarz, dokumenty.
Tu pojawia się pojęcie, które brzmi groźnie, a jest proste. Klucz API to nic innego jak hasło, które pozwala jednemu programowi sięgnąć do drugiego w twoim imieniu. Wyobraź sobie, że prosisz agenta: „pobierz dane z mojego konta”. Bez klucza może zobaczyć tylko to, co publiczne. Gdy dasz mu klucz, wchodzi tam, gdzie ty — do twoich prywatnych danych. Dlatego klucz traktujesz jak hasło: nie wklejasz go publicznie i nie rozdajesz bez potrzeby. W projekcie trzyma się go w osobnym, ukrytym pliku, który nigdy nie trafia tam, gdzie inni mogliby go podejrzeć. Co miłe, samo wklejenie klucza często wystarczy — mówisz „połączyłem cię z tym narzędziem, sprawdź, czy działa”, a agent sam znajduje właściwy sposób połączenia i wykonuje próbne zapytanie, żeby potwierdzić, że wszystko gra.
Najważniejszy nawyk wokół kluczy to nadawanie im wąskich uprawnień. Kiedy tworzysz klucz do jakiejś usługi, zwykle możesz z góry ograniczyć, co wolno mu robić i ile wolno mu wydać. Jeśli agent ma tylko czytać twój system, nie dawaj mu prawa do kasowania czy zmieniania danych. Zapytaj sam siebie: czy dałbyś nowemu pracownikowi kartę firmową bez żadnego limitu? Nie. Klucz z wąskim zakresem to dokładnie taki limit. Głośne wpadki, o których się słyszy — skasowana baza danych, wiadomość ze zniżką wysłana do ponad stu tysięcy osób — brały się nie z tego, że agent był zły, tylko z tego, że miał dostęp do narzędzi, których nigdy nie powinien dotknąć. Odbierz mu narzędzie, a nie tylko każ mu obiecać, że go nie użyje.
Usłyszysz przy okazji kilka skrótów — API, MCP, CLI. Nie daj się nimi przytłoczyć. To po prostu różne sposoby, na jakie agent łączy się z zewnętrznym narzędziem; każdy ma swoje drobne plusy i minusy, ale cel jest jeden i ten sam: sięgnąć do usługi, której używasz, żebyś ty nie musiał przeklikiwać jej ręcznie. W praktyce najwięcej zyskasz, podłączając to, co masz otwarte cały dzień. Jeśli pracujesz w ekosystemie Google Workspace, jednym podłączeniem dajesz agentowi dostęp do poczty, kalendarza, dokumentów, arkuszy i prezentacji naraz. Nie musisz znać szczegółów technicznych — pokazujesz agentowi dokumentację danego narzędzia i prosisz: „przeczytaj to i pomóż mi się połączyć”. On sam się w tym rozeznaje i prowadzi cię za rękę.
Zwrócę ci uwagę na jedną decyzję, bo łatwo tu pójść na skróty. Wiele narzędzi oferuje połączenie „na jedno kliknięcie”, wbudowane w daną aplikację. Jest wygodne, ale przywiązuje cię do niej — gdy zechcesz przesiąść się na coś innego, wszystko trzeba łączyć od nowa. Dlatego wolę robić to trochę bardziej ręcznie: klucze w osobnym pliku, połączenia opisane w projekcie. Pod spodem cała ta praca to zwykłe pliki i foldery, a na takich plikach usiądzie dowolny agent, dziś i za rok. Niezależność od jednego narzędzia jest dziś warta więcej niż kilka zaoszczędzonych kliknięć.
Zacznij od problemu, nie od narzędzia
Teraz najważniejsza zmiana w głowie, bo bez niej reszta jest zabawą. Najczęstszy błąd, jaki widzę, jest taki: ludzie budują efektownego agenta, którego nikt nie potrzebuje. Budowanie przestało być trudne. Trafne wskazanie, co warto zbudować, to dziś cała gra.
Posłużę się obrazem, do którego będę wracać. Wyobraź sobie firmę jako rurę, przez którą płynie woda — czyli zlecenia, praca, pieniądze. Z jednej strony wpływa, z drugiej wypływa to, co zostaje. Większość firm próbuje wlewać do rury coraz więcej wody: dorzuca ludzi, dokłada AI do przypadkowych miejsc. Ale jeśli w rurze jest zator, woda i tak nie popłynie szybciej. Twoja wartość polega na tym, żeby najpierw znaleźć ten zator i go usunąć. To jedyne miejsce, w którym praca się kumuluje — wszędzie indziej tylko przybywa ci zajęcia, a nie efektów. Automatyzując zepsuty proces, nie naprawiasz go, tylko skalujesz.
Zatorów zwykle jest kilka, w różnych miejscach i różnej wielkości. Lubię pytać właściciela firmy prosto: gdyby jutro przyszło pięć razy więcej klientów, co pękłoby pierwsze? To zmusza do przejścia w myślach przez cały tydzień pracy i pokazuje palcem, gdzie woda się zatrzymuje. Kiedy usuniesz pierwszy zator, cała woda dopłynie do następnego — i tak w kółko. Ale zaczynasz od tego pierwszego.
Przy okazji rozróżnienie, które oszczędza pieniędzy i nerwów: nie każdy proces potrzebuje AI. Automat z napojami jest przewidywalny — wrzucasz monetę, wciskasz przycisk, dostajesz to samo za każdym razem. Automat do gry nie: pociągasz za dźwignię i nie wiesz, co wypadnie. Agent bywa jak ten drugi, i to jego zaleta, gdy trzeba pomyśleć i poradzić sobie z bałaganem na wejściu — ale to też znaczy, że jest droższy i mniej pewny. Jeśli twój proces to proste „jeśli to, zrób tamto”, nie pakuj w niego AI; zwykły, przewidywalny mechanizm zrobi to taniej i nie zawiedzie. Osoba, która potrafi powiedzieć „tu AI nie jest potrzebne”, wyróżnia się bardziej niż ta, która wpycha je wszędzie.
Zanim cokolwiek zbudujesz, wybierz jedną liczbę, którą chcesz poruszyć. Nazywam ją gwiazdą polarną: to metryka ustalona z góry, która powie ci, czy budowa była warta zachodu. Przy obsłudze zgłoszeń będzie to liczba zamkniętych spraw dziennie. Przy sprzedaży — umówione, wartościowe rozmowy w tygodniu. Jeśli problemem jest to, że wpada za mało zapytań, gwiazdą polarną może być przejście z pięciu na piętnaście zapytań tygodniowo. Bez tej liczby po miesiącu nikt nie wie, czy było warto, bo efekty pracy w tle rzadko widać tak wyraźnie jak przy reklamie. Z góry ustalasz też, co znaczy „gotowe” — inaczej sam sobie rozdmuchasz zakres bez końca.
A jeśli dopiero zaczynasz i nie masz jeszcze luksusu takich decyzji, zrób prostą rzecz. Weź kartkę i wypisz swój tydzień: jakie zdarzenia coś w tobie uruchamiają — nowy lead, zgłoszenie, poniedziałkowy raport — i co wtedy robisz. Wyjdzie ci pięć czy dziesięć powtarzalnych procesów. Wybierz ten, który zdarza się najczęściej, i to pod niego zbuduj pierwszą automatyzację. Obowiązuje jeszcze jedna zasada: nie zautomatyzujesz czegoś, czego nie potrafisz opisać. Jeśli sam nie rozumiesz procesu na tyle, żeby rozpisać go krok po kroku, agent też go nie ogarnie. Dobre przygotowanie to połowa roboty — jak w powiedzeniu o rąbaniu drzewa: mając sześć godzin, cztery poświęć na naostrzenie siekiery.
Podagenci i skille: mądry podział pracy
Gdy umiesz już wybrać problem, czas na elementy, które wynoszą pracę wyżej niż pojedyncza rozmowa. Potraktuj to jak skrzynkę z narzędziami — sięgasz po to, czego akurat wymaga zadanie.
Zacznę od skilla (po polsku: umiejętności), bo używam go najczęściej. Skill to przepis wielokrotnego użytku. Wyobraź sobie, że pierwszy raz robisz naleśniki — otwierasz przepis i idziesz krok po kroku, bo nie znasz proporcji na pamięć. Potem coś w nim poprawiasz, aż jest twój, i od tej pory każdy, kto poprosi cię o naleśniki, dostaje je równie dobre. Agent działa tak samo: uczysz go raz, jak zrobić coś dobrze — na przykład jak segregować twoją skrzynkę albo jak wygląda twój post — a on zapisuje to jako skill i sięga po niego, ilekroć poprosisz. Zbudujesz go na dwa sposoby: albo z góry rozpisujesz kroki („zrób to tak: krok pierwszy, drugi, trzeci”), albo najpierw robisz coś razem z agentem, a potem mówisz „zamień to, co przed chwilą powstało, w skill”. I znów — pierwsza wersja nie musi być idealna; poprawiasz ją po każdym użyciu. Skąd agent wie, po który przepis sięgnąć? Nie czyta wszystkich naraz — przegląda tylko ich krótkie opisy i dopiero właściwy otwiera w całości. Dlatego opis skilla ma znaczenie: im precyzyjniej napiszesz, kiedy go użyć, tym rzadziej agent go pominie albo odpali nie w porę. Gdy trafi źle, poprawiasz opis — i z czasem sam sięga po właściwy przepis.
Drugi element to podagent (po angielsku sub-agent) — wyspecjalizowany pomocnik, którego główny agent powołuje do osobnego kawałka roboty. Ma własną, czystą pamięć roboczą, więc nie zaśmieca głównej sesji, a na koniec odsyła gotowy wynik. Możesz mieć ich kilku pracujących równolegle, każdego od czegoś innego: jeden robi research, drugi sprawdza jakość, trzeci pisze dokumentację. Co ważne, podagentowi możesz przydzielić tańszy, szybszy model do prostszej roboty, a najmocniejszy zostawić głównemu koordynatorowi. To jak zespół specjalistów zamiast jednego przemęczonego omnibusa. Kilku podagentów może pracować równolegle, każdy na swoim kawałku i na swoich plikach, żeby nie deptali sobie po palcach. To mocne przy zadaniach złożonych z niezależnych części, ale wolniejsze i droższe — więc sięgasz po to, gdy pracę naprawdę da się rozbić na osobne wątki, a nie dla samej sztuki.
Zanim jednak cokolwiek zbudujesz, polecam sesję odkrywczą, którą nazywam „przepytaj mnie”. Prosisz agenta, żeby bezlitośnie zadawał ci pytania o to, co chcesz zrobić — o cel, o proces, o wyjątki — i zapisywał odpowiedzi do jednego pliku. On nie odpuszcza, dopóki nie wyciągnie z twojej głowy wszystkiego, co istotne. Wygląda to niepozornie, a jest jednym z najlepszych sposobów, żeby zamienić mgliste „chciałbym coś zautomatyzować” w konkretny plan, na którym da się budować. W praktyce mówisz „przepytaj mnie o obsługę zgłoszeń”, a agent dopytuje po kolei — skąd przychodzą zgłoszenia, co robisz z pilnym, a co z resztą, gdzie zapisujesz ustalenia. Z twoich odpowiedzi rodzi się dokument, który potem staje się szkieletem skilla albo podagenta. Dopiero z takim planem sięgasz po skille i podagentów.
Zbuduj coś realnego: strona i druga pamięć
Teoria wsiąka najlepiej na czymś prawdziwym, więc zbudujesz dwie rzeczy. Pierwsza to strona internetowa. Zaczynasz od opisania, co ma na niej być, i oglądasz efekt na podglądzie na swoim komputerze. Potem iterujesz w najprostszy możliwy sposób: robisz zrzut ekranu, pokazujesz agentowi, mówisz „ten przycisk ma delikatnie świecić, a ta sekcja jest za ciasna”, a on poprawia. Możesz wskazać stronę, która ci się podoba, jako inspirację. Kiedy wygląda dobrze lokalnie, publikujesz ją w sieci — zwykle przez połączenie miejsca, które przechowuje twój projekt i pilnuje historii zmian (najpopularniejsze to GitHub), z usługą, która automatycznie wystawia stronę na żywo. W praktyce trzymasz dwie wersje: tę na swoim komputerze, na której eksperymentujesz, i tę na żywo, którą widzą inni. Zmiany trafiają na żywo dopiero wtedy, gdy powiesz „opublikuj” — więc możesz spokojnie próbować, cofać i poprawiać, nie psując tego, co już działa.
I tu pojawia się plik, który uważam za najważniejszy w całej tej pracy: CLAUDE.md. To stała instrukcja projektu, którą agent czyta przy każdej rozmowie — coś jak opis stanowiska dla nowego pracownika. Trzymasz w nim to, co model ma wiedzieć zawsze: czym jest projekt, jak ułożone są foldery, jakich zasad się trzyma, gdzie czego szukać. W przykładzie ze stroną wpiszesz do niego prostą regułę: „testuj wszystko lokalnie, dopóki wprost nie każę ci opublikować zmian”. Dzięki temu twoja niedokończona wersja nigdy nie wyjdzie w świat przypadkiem. Ten plik zakładasz jako pierwszą rzecz w każdym nowym projekcie i odświeżasz na bieżąco — ilekroć agent odkryje jakąś konwencję albo pułapkę, prosisz: „zapisz to w CLAUDE.md”. Z czasem plik staje się coraz mądrzejszy, a agent przestaje popełniać te same błędy.
Warto wiedzieć, że taki plik bywa w dwóch miejscach. Jeden jest wspólny dla wszystkiego, co robisz na swoim komputerze — trzymasz w nim ogólne rzeczy, na przykład zwroty, których nie znosisz w tekstach pisanych w twoim imieniu. Drugi żyje tylko w danym projekcie i opisuje właśnie jego. Reguła jest prosta: to, co ma obowiązywać zawsze, ląduje we wspólnym; to, co dotyczy jednej pracy — w projektowym.
Druga rzecz do zbudowania to „druga pamięć” — przeszukiwalna baza wiedzy o tobie i twojej firmie. Pomysł jest zaskakująco prosty i nie wymaga żadnej skomplikowanej infrastruktury. Zakładasz dwa foldery: do jednego wrzucasz surowe materiały (notatki, transkrypcje spotkań, artykuły), a drugi agent buduje sam — czyta to, co wrzuciłeś, rozbija na powiązane ze sobą strony i sam tworzy między nimi odnośniki. Dodatkowo prowadzi spis treści i dziennik zmian. Kiedy potem pytasz go o coś, nie zgaduje z pamięci — otwiera spis treści i idzie po odnośnikach do właściwej strony. Twoją przewagą jest twoja wiedza; wartość bierze się z wyjęcia jej z głowy i ułożenia tak, żeby agent umiał ją odnaleźć. Dlatego układając materiały, myśl od końca — o pytaniu, które kiedyś zadasz. Piłka do kosza jest okrągła, bo obręcz jest okrągła; gdybyś projektował ją w oderwaniu od tego, jak ma być użyta, nie trafiłaby do celu. Tak samo z wiedzą: to sposób, w jaki będziesz ją wyciągał, decyduje o tym, jak ją włożyć. Zwykły sprawdzian, czy zrobiłeś to dobrze: czy zarówno ty, jak i agent potraficie znaleźć daną rzecz ponownie? Jeśli nie — brakuje ci porządnego opisu, gdzie co leży.
Nie komplikuj tego ponad potrzebę. Zaczynasz od pliku CLAUDE.md i kilku folderów z jasnym opisem, gdzie co leży. Gdy materiałów przybywa, przechodzisz do tej powiązanej odnośnikami bazy. Po bardziej zaawansowane techniki wyszukiwania sięgasz dopiero wtedy, gdy naprawdę poczujesz ból — gdy prosty układ przestaje wystarczać. Jeśli nie ma bólu, nie ma po co budować. Znakiem, że pora na wyższy poziom, jest konkret: agent gubi rzeczy, choć są w projekcie, albo szukasz czegoś innymi słowami, niż je zapisałeś. Póki tego nie czujesz, prostszy układ w zupełności wystarcza.
Rutyny w chmurze: system, który pracuje w tle
Do tej pory wszystko uruchamiałeś ręcznie. Prawdziwa dźwignia pojawia się, gdy system działa, kiedy ciebie nie ma — gdy śpisz, jesteś na spotkaniu albo na spacerze. Służą do tego rutyny — polecenia ustawione raz, które uruchamiają się same. Możesz je odpalać według harmonogramu (na przykład codziennie o szóstej rano), na żądanie z zewnątrz albo w reakcji na zdarzenie.
To ostatnie to wyzwalacz zdarzeniem (po angielsku web hook). Najprościej wyjaśnić go na dzwonku do drzwi. Możesz co dziesięć minut wychodzić i sprawdzać, czy ktoś stoi pod drzwiami — to męczące i marnuje czas. Albo powieszasz dzwonek, a wtedy sam dowiesz się o gościu w chwili, gdy się pojawi. Tak samo działa wyzwalacz: zamiast bez końca odpytywać „czy przyszedł nowy formularz?”, ustawiasz, że nowy formularz sam uruchomi twój proces.
Zasadnicza różnica jest taka, że rutyny w chmurze działają na serwerach dostawcy, więc twój komputer może być wyłączony. Rutyny uruchamiane lokalnie wymagają, żeby maszyna była włączona. Warto pamiętać o dwóch rzeczach. Po pierwsze, taka rutyna to polecenie „na jeden strzał” — ustawiasz ją tak precyzyjnie, żeby nie musiała cię o nic dopytywać, bo przecież nie ma cię przy tym. Po drugie, bywają limity, ile takich uruchomień dziennie masz w swoim planie, więc rezerwuj je na rzeczy, które naprawdę tego wymagają.
Konkretny przykład: codzienny przegląd wiadomości z twojej branży. O szóstej rano rutyna przegląda kilka źródeł, składa z nich zwięzły, przejrzysty brief i wysyła ci go na wybrany kanał. Zanim jednak ją zostawisz, uruchamiasz ją kilka razy przy sobie i patrzysz, jak pracuje — poprawiasz format, doprecyzowujesz polecenie, aż masz pewność, że poradzi sobie sama.
Dwie rzeczy warto tu wiedzieć. Taka rutyna czyta stałe instrukcje twojego projektu dokładnie tak jak agent, z którym rozmawiasz na żywo — jeśli więc wcześniej porządnie opisałeś, jak projekt działa, ona to odziedziczy. I działa „jako ty”, z twoimi uprawnieniami, na tym, co udostępnisz jej w chmurze. Dlatego kilka spokojnych prób na żądanie, zanim puścisz ją na harmonogram, to nie przesada, tylko rozsądek.
Zanim jednak rzucisz się na rutynę, zadaj sobie jedno pytanie: czy to zadanie w ogóle potrzebuje pełnego agenta? Weź ten poranny przegląd. Jeśli krok po kroku wygląda zawsze tak samo — zbierz źródła, streść, wyślij — to prosty, przewidywalny skrypt zrobi to taniej i pewniej niż agent, który za każdym razem od nowa decyduje, co zrobić. Regułę mam prostą: przy rzeczach, które odpalają się bez ciebie, nuda jest zaletą. Cel wpisujesz na sztywno tam, gdzie się da — na przykład jeden, konkretny adres odbiorcy — żeby automatyzacja nie miała nawet możliwości wysłać czegoś w niewłaściwe miejsce.
I tu muszę być uczciwy, bo to ważna lekcja. Kiedy wyjmujesz siebie z procesu, ryzyko rośnie, bo nikt nie łapie błędu, zanim dotrze on na zewnątrz. Zdarza się, że automatyzacja chodzi po cichu tygodniami, człowiek zapomina, że w ogóle istnieje — a ona zaczyna działać nie tak, jak trzeba, bo w międzyczasie zmieniły się warunki. Zapamiętaj jedno zdanie: polecenie to nie jest twarda bariera. Jeśli powiesz agentowi „nigdy nie wysyłaj wiadomości na wspólny kanał”, to prośba, nie mur. Prawdziwą barierę stawiasz, odbierając agentowi samo narzędzie do wysyłki — jeśli fizycznie nie ma czym wysłać, nie wyśle, choćby „chciał”. Przy rzeczach, które działają bez twojego nadzoru, to jedyna bariera, której naprawdę można zaufać.
Tokeny i limity: jak nie utknąć
Na koniec rzecz, która ratuje przed frustracją w dłuższej pracy. Wszystko, co robi model, mierzy się w tokenach. Token to porcja tekstu — z grubsza trzy czwarte słowa. To jednostka, w której liczy się zużycie. Modele różnią się ceną i charakterem: jedne są szybkie i tanie, inne wyważone, a najmocniejsze — najdroższe. Płacisz przy tym osobno za to, co wsypujesz do modelu, i za to, co on wypisuje — a wypisywanie kosztuje więcej, więc długie, rozgadane odpowiedzi potrafią zaskoczyć rachunkiem. Na subskrypcji zwykle nie płacisz za pojedynczy token, tylko masz limity: bieżącej sesji (w ruchomym oknie kilku godzin) oraz tygodniowy. To korzystny układ, więc na start po prostu miej te dwa limity na oku.
Drugie pojęcie jest ważniejsze: okno kontekstu, czyli robocza pamięć modelu. Wyobraź sobie, że agent ma notes i zapisuje w nim wszystko — twoje polecenia, wczytane pliki, całą dotychczasową rozmowę. Ten notes ma skończoną pojemność. Gdy się zapełnia, model wchodzi w to, co nazywam „strefą otępienia”: zaczyna gubić wątek, myli fakty, jakość spada. To jak z kierowcą, który jedzie zbyt długo bez przerwy — refleks siada. Duża część twojej roli jako menedżera polega właśnie na pilnowaniu, żeby ta pamięć nie zamieniła się w śmietnik.
Masz na to proste ruchy. Krótkim poleceniem czyścisz rozmowę i zaczynasz ze świeżą głową, gdy przechodzisz do nowego zadania. Innym skracasz wątek do najważniejszych punktów, gdy chcesz zachować sens, ale zrobić miejsce. Bardzo lubię trzeci sposób: proszę agenta o krótkie „przekazanie zmiany” — podsumowanie tego, co zostało zrobione, jakie pliki są w grze i gdzie wrócić — potem czyszczę pamięć i wklejam to podsumowanie na starcie nowej sesji. Praca płynie dalej tak, jakbym niczego nie stracił. To jak zmiana warty: schodzący pracownik zostawia notatkę, a następny zaczyna na tej samej stronie. Nie czekaj z tym za długo — reset rób raczej z zapasem, zanim jakość zacznie siadać. Nie zdziw się też, że świeża sesja nie startuje od zera — część pamięci zajmują od razu twoje stałe instrukcje, opisy narzędzi i skille. To normalne; rzecz w tym, żeby nie dokładać do tego bałaganu.
Przy dłuższych zadaniach nie odchodź od ekranu na godzinę. Patrz, jak agent pracuje — odhacza kolejne kroki, sięga po narzędzia, czasem skręca nie tam, gdzie trzeba. To najlepszy moment, żeby go poprawić: przerywasz, mówisz „nie tędy, zrób to inaczej” i puszczasz dalej. Im wcześniej złapiesz zły kierunek, tym mniej tokenów i czasu zmarnujesz na odkręcanie. Ta obecność przy pracy to nie brak zaufania — to sposób, w jaki uczysz się, co ten agent naprawdę potrafi.
Jest jeszcze powód, dla którego wcześniej mówiłem o precyzji. Im mniej niepotrzebnych rzeczy wrzucasz w kontekst, tym dłużej model jest bystry i tym mniej tokenów zużywasz. Dlatego dobrze zbudowane skille nie ładują się w całości od razu — agent czyta tylko ich krótkie opisy i sięga po pełną treść wtedy, gdy naprawdę jej potrzebuje. Warto też po prostu obserwować, ile zużywasz; przydaje się prosty lokalny podgląd zużycia albo choćby regularne zerkanie na limity sesji i tygodnia. I korzystaj z ciekawości: jeśli czegoś w działaniu narzędzia nie rozumiesz, poproś, żeby samo sięgnęło do swojej dokumentacji i ci to wytłumaczyło.
Zacznij od jednego procesu
Jeśli mam zostawić cię z jedną myślą, to z tą: wartość nie leży w zbudowaniu efektownego agenta, bo budowanie jest dziś łatwe i z każdym miesiącem łatwiejsze. Leży w trafnym rozpoznaniu, gdzie w twojej pracy jest zator, i w usunięciu go tak, żeby było to widać. To, co jeszcze dziś wygląda jak przewaga, jutro będzie normą — jeden człowiek potrafi już wykonać pracę, która kiedyś wymagała zespołu, i tego nie da się odwrócić.
Następny krok jest spokojny. Wróć do tej kartki z tygodniem, wybierz jeden powtarzalny proces — własny albo znajomej firmy — policz, ile czasu pochłania, i zbuduj pod niego jedną automatyzację od początku do końca. Jedno takie przejście nauczy cię więcej niż kolejne godziny czytania o tym.