Najczęstszy błąd, jaki widzę u osób zaczynających z automatyzacją, jest taki: zachłystują się tym, jak łatwo dziś zbudować efektownego agenta, i zupełnie pomijają pytanie, czy ten agent w ogóle rozwiązuje czyjś realny problem. Budowanie przestało być wąskim gardłem. Trafne rozpoznanie problemu — i umiejętność policzenia, ile jest wart — to dziś cała gra.
Pokażę ci tu całą drogę, od zera do pierwszego płatnego zlecenia. Najpierw dwa pojęcia, bo wracają na każdym kroku. Claude Code to narzędzie, w którym model Claude wykonuje konkretną pracę — czyta pliki, pisze kod, uruchamia kolejne kroki — działając w terminalu (oknie poleceń) albo jako rozszerzenie edytora kodu. To nie czat, w którym tylko wymieniasz wiadomości; to wykonawca, który realnie buduje rzeczy na twoim komputerze. Agent to taki właśnie wykonawca: dostaje cel i sam dobiera kroki, zamiast czekać na każde pojedyncze polecenie.
Mapa drogi jest prosta. Najpierw mindset i jedno ćwiczenie, które ustawia całą resztę. Potem ustawienie środowiska i pojęcia, bez których łatwo o frustrację. Dalej zbudujesz dwie automatyzacje od początku do końca. Potem wejdziesz w mocniejsze elementy — skille, zespoły agentów, podłączanie narzędzi. A na końcu to, co odróżnia rzemiosło od dochodu: jak to wycenić, dostarczyć i sprzedać. Czytasz, próbujesz, wracasz do trudniejszych fragmentów. To materiał na kilka podejść, nie na jedno popołudnie.
Zanim cokolwiek zbudujesz: znajdź zator
Zacznę od obrazu, do którego będę wracać. Wyobraź sobie firmę jako rurę, przez którą płynie woda — czyli praca, zlecenia, pieniądze. Większość firm próbuje wlewać do tej rury jak najwięcej wody naraz: zatrudniają kolejnych ludzi, dorzucają AI do przypadkowych problemów. A jeśli w rurze jest zator, woda i tak nie popłynie szybciej, choćbyś dolewał bez końca. Twoja realna wartość polega na tym, żeby najpierw znaleźć ten zator i go usunąć — a dopiero potem zwiększać przepływ.
To dlatego nie zaczynasz od narzędzia. Zaczynasz od pytania, gdzie w danej firmie marnuje się najwięcej czasu na powtarzalną pracę. Efektowny agent zbudowany w oderwaniu od takiego zatoru to ładna zabawka, za którą nikt nie zapłaci. Agent, który usuwa konkretne, kosztowne wąskie gardło, to coś, za co rynek płaci naprawdę — i to jest cała różnica.
Jest jeszcze jeden nawyk, który moim zdaniem decyduje o tym, jak szybko to opanujesz: bądź szczerze ciekawy. Gdy czegoś nie rozumiesz w tym, co robi agent, po prostu go o to pytasz — „co tu zrobiłeś?”, „dlaczego tak?”, „czy da się inaczej?”. Nie musisz znać kodu. Musisz chcieć rozumieć, co się dzieje. Ludzie, którzy czytają to, co robi agent, i dopytują, łapią całą resztę zaskakująco szybko. Ci, którzy klikają na ślepo, zatrzymują się na pierwszej niespodziance.
Uczciwie: w sieci krąży sporo przesady. Usłyszysz, że takie systemy „naprawiają się same na zawsze” i że wystarczy je raz uruchomić. Tak nie jest. Utrzymanie nadal kosztuje czas, a dobry system buduje się tak, żeby ten czas był jak najmniejszy — nie tak, żeby udawać, że go nie ma.
Ustawienie środowiska i sposoby pracy
Teraz konkrety. Zaczynasz od pobrania darmowego edytora kodu — najpopularniejszy to VS Code — i dodajesz do niego rozszerzenie Claude Code. Do tego potrzebujesz płatnej subskrypcji Claude; bez niej agent nie ruszy. Gdy wszystko jest na miejscu, widzisz dwie rzeczy obok siebie: po jednej stronie pliki twojego projektu, po drugiej okno rozmowy z agentem. To w tym oknie zlecasz pracę zwykłym językiem.
Drobna decyzja, którą warto podjąć od razu: który model. Do wyboru masz zwykle trzy — od najszybszego i najtańszego, przez pośredni, po najmocniejszy (w nazwach: Haiku, Sonnet, Opus). Na początku zostaw ustawienie domyślne albo trzymaj się najmocniejszego, żeby wyrobić sobie wyczucie jakości. Na słabszy przełączysz się później, świadomie — na przykład gdy zlecasz prostą, masową robotę i chcesz oszczędzać.
Sensowna strategia na dłużej wygląda tak: model pośredni do jakichś 80% pracy, a najmocniejszy włączasz tylko do trudnych decyzji projektowych albo zaplątanych błędów, po czym wracasz do tańszego. Model zmieniasz w locie krótkim poleceniem — wpisujesz /model i wybierasz. To jedna z wielu tak zwanych komend ze znakiem ukośnika (krótkich poleceń zaczynających się od /); listę wszystkich zobaczysz, wpisując znak zapytania. Nie musisz ich pamiętać — zawsze możesz poprosić o to samo zwykłym językiem.
Jest też kilka sposobów, na które Claude Code można uruchomić, i każdy ma inny kompromis. Wymienię cztery, które realnie się przydają, żebyś wybrał pod siebie, a nie „bo ktoś tak robi”.
Cztery warianty i ich kompromisy
- W terminalu. Najbliżej „surowego” narzędzia, najwięcej kontroli, najmniej rozpraszaczy. Próg wejścia trochę wyższy, jeśli okno poleceń jest dla ciebie nowe.
- W aplikacji na komputer. Wygodne, samodzielne okno; dobry punkt startu, gdy nie chcesz pracować w edytorze kodu.
- Jako rozszerzenie edytora (VS Code). Mój domyślny wybór do nauki: widzisz pliki i rozmowę naraz, łatwo śledzić, co agent zmienia. To wariant, którego będę się tu trzymać.
- W przeglądarce. Zadanie działa w chmurze, więc nie przerywa się, gdy zamkniesz komputer. Dobre do dłuższych zleceń, które mają „chodzić w tle”.
Nie ma tu jednej dobrej odpowiedzi. Jeśli dopiero zaczynasz, weź rozszerzenie edytora — reszta tekstu zakłada właśnie ten widok.
Trzy pojęcia, bez których przyjdzie frustracja
Zanim zaczniesz większe budowy, opanuj trzy rzeczy. Pomijanie ich to najczęstsza przyczyna tego, że ludziom „agent nie działa”, choć tak naprawdę nie działa sposób pracy.
Token to porcja tekstu, którą model przetwarza — z grubsza kawałek słowa. Tokeny kosztują, bo to one są jednostką rozliczeń. Druga rzecz to okno kontekstu, czyli robocza pamięć modelu. Wyobraź sobie, że Claude ma notes i zapisuje w nim wszystko: twoje polecenia, pliki, które mu podałeś, całą dotychczasową rozmowę. Ten notes ma skończoną pojemność — zwykle rzędu dwustu tysięcy tokenów. Gdy się zapełnia, model zaczyna gubić wątek albo musi „streścić sam siebie”, żeby zrobić miejsce. Wtedy jakość spada — i, jak mówiłam, zwykle nie jest to wina modelu, tylko tego, że pozwoliłeś zaśmiecić mu pamięć.
W praktyce masz na to dwa proste polecenia. Wpisujesz /clear, żeby wyczyścić rozmowę i zacząć ze świeżą głową, gdy przechodzisz do nowego zadania. Wpisujesz /compact, gdy chcesz zachować wątek, ale skrócić go do najważniejszych punktów — robię to zwykle, gdy kontekst zapełni się mniej więcej w 60%. Na samym początku nie musisz tym żyć: pamięć i tak streszcza się automatycznie, gdy dojdzie do granicy. Ale warto rozumieć, co się dzieje, bo to klucz do utrzymania jakości w dłuższej pracy.
Trzecie pojęcie jest najważniejsze: plik CLAUDE.md. To stała instrukcja, którą agent czyta przy każdej rozmowie — coś jak opis stanowiska dla nowego pracownika. Trzymasz w nim to, co model ma wiedzieć zawsze: jak ułożone są foldery, jakich zasad się trzyma, jak ma się zachowywać. Bez tego pliku jest jak ekspert posadzony do pracy bez żadnego wprowadzenia. Zakładasz go jako pierwszą rzecz w każdym nowym projekcie — możesz utworzyć pusty plik o nazwie CLAUDE.md i pozwolić, żeby agent sam go uzupełnił, opisując mu, czym jest projekt (jest na to nawet krótka komenda /init, ale równie dobrze działa zwykła prośba: „założyłem ci plik CLAUDE.md, opisz w nim ten projekt”).
Jeden nawyk wokół tego pliku jest bezcenny: odświeżaj go na bieżąco. Ilekroć agent odkryje w twoim projekcie coś nowego — jakiś wzorzec, pułapkę, konwencję — albo gdy zbudujesz nowy skill, dopisz to do CLAUDE.md. Dzięki temu plik z czasem staje się coraz mądrzejszy, a agent przestaje popełniać te same błędy. Możesz wprost prosić: „zapisz to, czego się właśnie nauczyłeś o projekcie, w CLAUDE.md”.
Warto tu też powiedzieć rzecz, która wraca w całej tej pracy: jakość polecenia przekłada się wprost na jakość wyniku. Pod spodem to wciąż model językowy — im precyzyjniej opiszesz, czego chcesz, na jaki efekt liczysz i czego nie robić, tym lepiej trafi. Mgliste polecenie daje mglisty efekt. To dobra wiadomość dla osoby nietechnicznej: twoją główną umiejętnością nie jest kod, tylko jasne formułowanie tego, o co ci chodzi.
Schemat, który porządkuje całą pracę: workflow, agent, narzędzia
W CLAUDE.md zwykle zapisujesz też jeden prosty schemat, na którym opiera się reszta. Po angielsku skrót brzmi WAT, od trzech warstw: workflow, agent, tools — czyli workflow, agent i narzędzia. Workflow to proces opisany zwykłym językiem, jak przepis: „zbierz dane z pięciu źródeł, przeanalizuj je, złóż raport PDF”. Narzędzia to konkretne, przewidywalne czynności, których agent używa po drodze — na przykład fragment kodu, który zawsze tak samo wyciąga dane albo składa plik. Agent to ty w tej układance, a właściwie model w roli decydenta: czyta workflow, sięga po narzędzia, radzi sobie z wyjątkami.
Sens tego podziału jest praktyczny. Tam, gdzie zadanie jest powtarzalne i da się je policzyć z góry, oddajesz robotę przewidywalnemu kodowi (narzędzia). Tam, gdzie trzeba pomyśleć i podjąć decyzję, pracuje model (agent). Dzięki temu nie każesz modelowi za każdym razem wymyślać od nowa rzeczy, które powinny działać tak samo — a to i taniej, i pewniej. Ten sam fragment instrukcji możesz kopiować między projektami; to twój stały punkt wyjścia.
Pierwsza automatyzacja: badanie konkurencji z markowym raportem PDF
Czas zbudować coś od początku do końca. Pierwszy przykład to automatyzacja, która bada konkurencję i na koniec składa gotowy, markowy raport PDF. Zwróć uwagę nie tyle na sam efekt, ile na sposób pracy — bo to on przenosi się na każde kolejne zlecenie.
Zaczynasz od otwarcia pustego folderu jako nowego projektu. Zanim cokolwiek powiesz o szczegółach, przełączasz agenta w tryb planowania. To ważne ustawienie: w trybie planowania agent może myśleć, czytać i przeszukiwać sieć, ale nie zacznie nic budować, dopóki nie zatwierdzisz planu. Masz też inne tryby pozwoleń — od „pytaj przed każdą zmianą”, przez „zmieniaj pliki automatycznie”, po tryb, w którym agent działa bez pytania o zgodę. Na początku trzymaj się trybu planowania; daje ci moment na sprawdzenie, czy agent dobrze zrozumiał, zanim zacznie działać.
Teraz opisujesz cel zwykłym językiem: chcesz system, który raz w miesiącu sam znajduje konkurentów, sprawdza ich ofertę i składa z tego branżowy raport PDF z konkretnymi wnioskami. Agent zaczyna myśleć, czyta strukturę projektu i przechodzi w fazę pytań — bo dobry plan wymaga decyzji, których nie podjąłeś za niego z góry.
Faza pytań: agent dopytuje, ty decydujesz
To moment, którego nie warto przeskakiwać. Agent zadaje konkretne pytania — na przykład: jak mają być znajdowani konkurenci? Możesz podać gotową listę, pozwolić mu wykryć ich samodzielnie na podstawie opisu twojej firmy albo połączyć jedno z drugim. Pyta też o dane o twoim biznesie, o zakres analizy, o format wyniku, o to, jak często ma to działać. Odpowiadasz po kolei i właśnie z tych odpowiedzi rodzi się sensowny plan, a nie ze zgadywania.
Gdy odpowiesz, agent wraca z gotowym planem — na przykład: „comiesięczny system, który sam wykrywa konkurentów, bada ich ofertę i generuje markowy raport PDF z konkretnymi wnioskami”. I tu jest sedno trybu planowania: czytasz ten plan i sprawdzasz, czy to dokładnie to, czego chcesz, zanim klikniesz „działaj”. Lepiej poprawić jedno zdanie w planie niż rozkręcać gotową, źle pomyślaną budowę.
Jak wstrzyknąć markę
Sam raport ma wyglądać jak twój, nie jak generyczny dokument. Dlatego przeciągasz do projektu dwie rzeczy: logo i wytyczne marki (kolory, typografia, ton). Gdy agent buduje dokument, sięga po te materiały i formatuje wynik tak, żeby był spójny z marką. To drobiazg, który robi ogromną różnicę w odbiorze — i jednocześnie pokazuje regułę ogólną: jeśli chcesz, żeby efekt wyglądał konkretnie, dostarcz agentowi konkret, a nie ogólnik.
Gdy plan jest zatwierdzony, agent przechodzi do działania. Tworzy sobie listę zadań i odhacza ją na twoich oczach — widzisz, jak po kolei znajduje konkurentów, zbiera dane, składa dokument. Twoja rola w tym momencie to nadzór: czytasz, co robi, i reagujesz, gdy coś idzie nie tak. Skoro nie piszesz kodu ręcznie, twoją pracą staje się jasne komunikowanie celu i pilnowanie jakości.
Druga automatyzacja: newsletter z punktem zatwierdzenia
Drugi przykład dokłada element, który jest kluczowy w pracy dla klienta: moment, w którym do gry wraca człowiek. Budujesz automatyzację newslettera. Otwierasz świeży, pusty projekt i znów zaczynasz od opisania celu: chcesz móc podać temat, a agent zrobi research, ułoży treść, sformatuje ją w HTML (czyli w formacie, w jakim wyświetlają się strony i wiadomości e-mail), zadba o spójny wygląd i przygotuje całość do wysyłki.
Tu też przeciągasz do projektu logo i wytyczne marki, żeby każdy numer wyglądał tak samo i „czuł się” jak twój. Ciekawe jest to, że materiały możesz wskazać wprost w poleceniu — pokazujesz agentowi: użyj tego logo, trzymaj się tych zasad. Agent wraca z planem, ty go czytasz i zatwierdzasz.
Najważniejszy szczegół jest na końcu procesu. Newsletter nie wychodzi sam w świat: workflow dochodzi do punktu, w którym to ty zatwierdzasz tytuł i całość przed wysyłką. To celowe. Wszędzie tam, gdzie liczy się reputacja i gdzie pomyłka jest kosztowna, zostawiasz sobie ostatnie słowo. Automatyzacja ma odciążyć z powtarzalnej roboty, a nie odebrać ci kontrolę nad tym, co wychodzi pod twoim nazwiskiem. Tę zasadę — automatyzuj nudne kroki, zostaw człowiekowi decyzje wagi ciężkiej — przeniesiesz na praktycznie każde zlecenie.
Co robić, gdy coś nie zadziała (a zadziała źle)
I tu uczciwa uwaga, bo to nieuniknione: za pierwszym razem coś się posypie. Przy takiej budowie typowo wychodzi na jaw, że testowa wiadomość przyszła z zepsutym formatowaniem albo że agent dostał błędny adres arkusza, do którego miał coś zapisać, i nie miał do niego dostępu. To nie jest powód do paniki — to normalny etap. Pokazujesz agentowi, co konkretnie jest nie tak („wiadomość przyszła z rozjechanym tłem i układem, popraw to”; „podałem zły identyfikator arkusza, oto właściwy”), a on poprawia. Im konkretniej nazwiesz usterkę, tym szybciej ją usunie.
To jest praktyczne oblicze szczerej zasady, która mi towarzyszy: gdy efekt jest słaby, najczęściej nie jest to wina modelu, tylko niedoprecyzowanego polecenia albo brakującego dostępu. Weź część odpowiedzialności na siebie, popraw wejście — a wynik podskoczy. Ta postawa odróżnia osoby, które dowożą działające systemy, od tych, które po pierwszym błędzie odpuszczają.
Mocniejsze elementy: skille, podagenci i zespoły
Gdy masz już za sobą dwie budowy, czas na elementy, które wynoszą pracę dalej niż pojedyncza automatyzacja. Nie musisz używać wszystkich naraz — potraktuj to jako skrzynkę z narzędziami, z której sięgasz po to, czego akurat wymaga zadanie.
Skill to wielokrotnego użytku przepis. Wyobraź sobie, że uczysz agenta raz, jak zrobić coś dobrze — na przykład jak ma wyglądać twój post na LinkedIn — i zapisujesz to jako skill. Od tej pory, ilekroć poprosisz o taki post, agent sięga po ten przepis i robi go za każdym razem tak samo dobrze, bez tłumaczenia od zera. Pierwszy skill, który warto zbudować, to zwykle podłączenie agenta do narzędzia, którego naprawdę używasz na co dzień — na przykład do systemu, w którym prowadzisz zadania czy projekty.
Podagent (po angielsku sub-agent) to pomocnik, którego główny agent powołuje do osobnego kawałka roboty. Ma własne okno kontekstu, więc nie zaśmieca pamięci głównej sesji, i na koniec odsyła wynik. Krok dalej są zespoły agentów: kilku wykonawców pracujących równolegle, każdy w swoim obszarze i — co ważne — na swoich plikach, żeby nie nadpisywali sobie nawzajem pracy. To mocne narzędzie przy zadaniach z kilkoma niezależnymi częściami, ale wolniejsze i droższe; jeśli chcesz to zgłębić, rozpisałam je osobno w tekście o zespołach agentów w Claude Code.
Podłączanie świata: narzędzia, MCP i RAG
Trzy pojęcia, które pozwalają agentowi sięgnąć poza własną głowę. Pierwsze to automatyzacja przeglądarki — agent może sterować stronami internetowymi, klikać, wypełniać, pobierać. Drugie to MCP (po angielsku model context protocol), czyli ustandaryzowany sposób, w jaki narzędzia i źródła danych podłączają się do modelu. Najprościej myśleć o tym jak o zestawie gotowych czynności, które dana usługa udostępnia — tak jak skrzynka e-mail udostępnia „wyślij wiadomość”, „utwórz szkic”, „pobierz wiadomość”. MCP to wspólny standard, dzięki któremu agent potrafi z takich czynności korzystać, zamiast za każdym razem uczyć się obsługi od nowa.
Trzecie pojęcie to RAG (retrieval augmented generation). Model wie tylko tyle, ile było w jego danych treningowych. Jeśli zapytasz go o coś, czego tam nie było — twoje wewnętrzne dokumenty, najnowsze ustalenia — musi to skądś wziąć. RAG to właśnie technika, w której agent najpierw sięga do dostarczonych mu dokumentów, a potem odpowiada na ich podstawie, zamiast zgadywać z pamięci. Dla pracy z klientem to bardzo praktyczne: tak budujesz asystenta, który zna firmowe materiały, a nie tylko ogólną wiedzę.
Praca z kodem na GitHubie i work trees
Dwa pojęcia z obszaru porządkowania pracy, oba da się ogarnąć zwykłym językiem. Git to system kontroli wersji — narzędzie, które zapisuje każdą zmianę w projekcie, więc zawsze możesz cofnąć się do wcześniejszego stanu. GitHub to miejsce w sieci, gdzie taki projekt trzymasz i synchronizujesz między urządzeniami albo udostępniasz innym. Work trees (równoległe kopie projektu) pozwalają pracować nad kilkoma rzeczami naraz, nie psując sobie wersji głównej. Brzmi technicznie, ale w praktyce nie musisz pamiętać poleceń: opisujesz agentowi zwykłym językiem, co chcesz osiągnąć — „zapisz to na GitHubie”, „przygotuj osobną kopię do eksperymentu” — a on to zrobi. To znów ta sama postawa: bądź ciekawy, dopytuj, a narzędzie ci pomoże.
Jak sprawić, żeby to chodziło samo
Dotąd uruchamiałeś wszystko ręcznie. Krok dalej to sprawienie, żeby automatyzacja działała bez ciebie. Masz dwa typowe sposoby. Pierwszy to harmonogram — ustawiasz, że coś ma się dziać raz dziennie, raz w tygodniu albo co kilkadziesiąt minut (Claude Code ma nawet wbudowane zadania uruchamiane, gdy aplikacja jest otwarta). Drugi to wyzwalacz zdarzeniem (po angielsku web hook): coś dzieje się na zewnątrz — przychodzi formularz, pojawia się nowy rekord — i to samo uruchamia twój proces. W jednym i drugim przypadku nie musisz znać szczegółów technicznych; opisujesz zamiar zwykłym językiem: „uruchamiaj ten proces co rano o ósmej” albo „odpal go, gdy przyjdzie nowe zgłoszenie”.
Tu wraca rozróżnienie, które poznałeś przy testowaniu: na harmonogram albo wyzwalacz wystawiasz workflow i narzędzia, a nie agenta z edytora. To one pracują w tle. Agent zostaje po twojej stronie, do budowania i poprawiania. Dobrze to wiedzieć, zanim obiecasz klientowi „system, który działa sam”.
Złożenie tego w asystenta
Wszystkie te klocki można spiąć w jeden większy przykład — osobistego asystenta wykonawczego. Zaczynasz od solidnego CLAUDE.md, który opowiada mu o tobie i o twoich celach. Potem „dajesz mu ręce”: budujesz pierwszy skill — zwykle podłączenie do narzędzia, w którym naprawdę prowadzisz zadania czy projekty — żeby przestał tylko myśleć, a zaczął coś za ciebie robić. Dokładasz kolejne skille i podagentów, aż asystent potrafi na przykład sam zlecić research, a potem przygotować z niego gotowy materiał. Warto też przy okazji zajrzeć do alternatyw, choćby do narzędzia wiersza poleceń od Google, żeby mieć porównanie — ale konsekwentnie pamiętaj: cudzy zestaw to nie twój zestaw. Mocniejsza funkcja nie znaczy automatycznie lepsza dla tego, co akurat robisz.
Sprawdź i wdróż, zanim oddasz klientowi
Zanim cokolwiek trafi do klienta, system trzeba przetestować — i to jest moment, który wielu początkujących pomija. Posłużę się obrazem toru kolejowego. Zanim dopuścisz pociągi na nowy tor, puszczasz po nim różne składy: lekkie, ciężkie, na różnych kołach — żeby mieć pewność, że tor wytrzyma każdy z nich. Tak samo testujesz automatyzację: podajesz jej różne, także trudne i nietypowe dane wejściowe, i sprawdzasz, czy radzi sobie z każdym przypadkiem, zanim wpuścisz ją „na produkcję”, czyli do realnej pracy.
Jedno rozróżnienie, które oszczędza nieporozumień: gdy wdrażasz taki system, oddajesz do działania jego workflow i narzędzia, a nie samego agenta z twojego edytora. To narzędzia i opisany proces idą na serwer i tam pracują. Agent — model w Claude Code — zostaje po twojej stronie i służy do budowania oraz poprawiania systemu. Brzmi jak techniczny detal, ale ma znaczenie, gdy rozmawiasz z klientem o tym, co konkretnie u niego stanie.
Jak właściwie testować
W praktyce wygląda to tak: zanim wystawisz proces na harmonogram albo wyzwalacz, przepuszczasz przez niego serię różnych wejść — typowe, ale też skrajne i nietypowe. Pusty dokument, niekompletne dane, dziwny format, dwa zgłoszenia naraz. Patrzysz, czy każdy taki przypadek kończy się sensownym wynikiem albo czytelnym komunikatem, a nie cichą awarią. Gdy coś się sypie, poprawiasz — i przepuszczasz jeszcze raz. Dopiero gdy system przejdzie przez te trudne przypadki, masz prawo powiedzieć, że jest gotowy.
Powód, dla którego to wszystko w ogóle ma dziś sens, jest prozaiczny: technologia wreszcie dojrzała. Modele są na tyle przewidywalne, że da się ich używać w realnej pracy, a nie tylko do zabawy w czacie. Ale „na tyle przewidywalne” to nie „bezobsługowe” — stąd ten nacisk na testowanie. System, który przeszedł przez wiele różnych przypadków, zanim ruszył, to system, któremu możesz spojrzeć klientowi w oczy i powiedzieć: to działa.
Jak sprzedawać: nie pokazuj narzędzia, pytaj o problem
Tu kończy się część techniczna, a zaczyna ta o pieniądzach — i to jest część, którą najczęściej się pomija, a która decyduje o tym, czy z umiejętności robi się dochód. Pierwsza zasada brzmi: nie wchodź do rozmowy od strony „buduję automatyzacje w Claude Code”. Klienta to nie obchodzi. Młotek nie jest ważny — ważny jest efekt.
Dlatego na rozmowie nie zaczynasz od „pokażę ci mój workflow”. Zaczynasz od pytań: gdzie tracisz najwięcej czasu w swoim biznesie? które procesy chciałbyś, żeby robiły się same? Diagnoza zawsze prowadzi do rozwiązania, a rozwiązanie zawsze da się przeliczyć na mierzalną wartość dla firmy. Gdy to opanujesz, przestajesz być „kolejnym od automatyzacji”, a stajesz się osobą, która potrafi spojrzeć na biznes, wskazać, gdzie ucieka czas i pieniądze, i zaprojektować coś, co to naprawia. To przejście od sprzedawcy narzędzia do sprzedawcy rozwiązania.
Jest tu jeszcze jedna pułapka, o której uczciwie warto powiedzieć. Umieć kazać agentowi coś zbudować to nie to samo, co umieć ocenić, czy to, co powstało, jest dobre. Osoba, która nigdy nie zrozumiała, co dzieje się pod spodem, nie wyłapie momentu, w którym agent podjął złą decyzję. Nie znaczy to, że musisz być programistą — znaczy, że wraca tu ta sama postawa z początku: bądź ciekawy, czytaj, co agent robi, dopytuj „dlaczego tak?”. To właśnie ta ciekawość, a nie znajomość kodu, pozwala ci stanąć przed klientem i odpowiadać za jakość tego, co dostarczasz.
Najważniejsza zmiana jest w głowie i nazywa się wycena oparta na wartości. Nie liczysz, ile godzin zajmie ci budowa — liczysz, ile dana automatyzacja jest warta dla firmy. Posłużę się obrazem, który dobrze to oddaje: szklanka wody ma inną wartość dla kogoś, kto właśnie przebiegł kilka kilometrów w upale, niż dla kogoś, kto cały dzień siedzi w klimatyzowanym biurze. To ten sam produkt — ale inna wartość. Ceny nie ustawiasz od kosztu wytworzenia, tylko od tego, ile rozwiązanie znaczy dla tego konkretnego klienta.
Jak policzyć wartość na konkretnym przykładzie
Pokażę to na typowej sytuacji, bo abstrakcja tu nie wystarcza. Wyobraź sobie proces, w którym pracownicy ręcznie umawiają spotkania dla zespołu sprzedaży. Przyjmij, że godzina pracy takiej osoby jest warta jakieś 40 dolarów. Jeśli ten proces pochłania na tyle dużo czasu, że tygodniowo kosztuje firmę około 800 dolarów, to w skali miesiąca robi się z tego jakieś 3 200 dolarów, a w skali roku — rzędu 38 000 dolarów. I to jest twój punkt odniesienia przy wycenie: nie „ile godzin spędzę nad budową”, tylko „ile firma przestanie tracić, gdy to ruszy”. Liczby traktuj jako mechanizm liczenia, nie jako obietnicę — w realnym projekcie podstawiasz dane konkretnego klienta.
Pięć kroków wyceny i co dalej z relacją
Żeby z wyceny zdjąć przypadkowość, używaj prostego, pięciostopniowego schematu. Po angielsku układa się on w słowo PRICE — i dobrze, bo to po prostu „cena”. Przejdę przez wszystkie pięć liter, bo każda to osobny krok rozmowy z klientem.
- P — przygotuj się (prepare). Zanim w ogóle pomyślisz o kwocie, ustaw sobie w głowie wycenę opartą na wartości. Nie liczysz godzin — liczysz efekt: oszczędzony czas, pieniądze, mniej błędów.
- R — zbadaj (research). To etap odkrywania. Rozmawiasz, mapujesz proces, ustalasz, gdzie naprawdę jest zator i ile on kosztuje. Stąd biorą się liczby do wyceny.
- I — wdrożenie i wycena (implement). Projektujesz rozwiązanie i odnosisz jego cenę do policzonej wartości — na przykład do tego, ile firma odzyska w pierwszym roku.
- C — zakomunikuj (communicate). Mając cenę, musisz ją przedstawić tak, żeby miała sens. Malujesz obraz tego, jak firma będzie wyglądać, gdy system już działa. Tłumaczysz, co wchodzi w zakres i jak wygląda kontrola jakości. Cena bez tego obrazu to tylko liczba.
- E — rozwijaj (expand). Po wdrożeniu robota się nie kończy. Szukasz, co dalej: utrzymanie, monitorowanie, optymalizacja, kolejne automatyzacje, wersja druga, stała opieka. Najlepsze zlecenia często rosną z już wykonanych.
Zaufanie przychodzi przed stałą umową
Tu popełnia się drugi częsty błąd: ludzie za wcześnie obsesyjnie myślą o stałych, miesięcznych umowach i o jakiejś wymarzonej kwocie „na miesiąc”. Zapamiętaj prostą zasadę: zaufanie przychodzi przed stałą umową. Prosić kogoś o miesięczny abonament, zanim cokolwiek dla niego zrobiłeś, to jak prosić o rekomendację, zanim w ogóle zacząłeś współpracę. Najpierw dostarcz jeden, dwa projekty, rozwiąż realny problem i pokaż wartość, którą wniosłeś. Wtedy rozmowa o stałej opiece staje się naturalna — sama się o nią poprosi. Ta sama logika dotyczy referencji i poleceń: nie da się ich uzyskać przed dostarczeniem czegokolwiek.
Z tym wiąże się naturalna ścieżka rozwoju: od freelancera, przez konsultanta, po zaufanego partnera, na którym firma polega przy ulepszaniu działania. Na początku rozliczenie godzinowe bywa w porządku — budujesz zaufanie i pierwsze wyniki, a zależy ci wtedy na doświadczeniu i dowodach, nie na maksymalnej stawce. Później przesuwasz się w stronę stałej współpracy rozliczanej za etapy (kamienie milowe), a nie za godziny. Godziny pozycjonują cię jak freelancera; etapy — jak partnera. W praktyce zakres takich zleceń bywa bardzo szeroki: od drobnych, niskobudżetowych prac po duże kontrakty rzędu kilkudziesięciu tysięcy — zależnie od tego, ile wartości realnie wnosisz i jak głęboko firma ci ufa. Nie ma tu jednego słusznego modelu rozliczeń; rynek znosi i stałą cenę za konkretny efekt, i pakiety godzin, i abonament z określonym zakresem. Na początku ważniejsze od wyciśnięcia maksymalnej stawki jest zebranie doświadczenia i dowodów.
Na koniec dostarczania jest jeszcze jeden krok, który buduje zaufanie bardziej niż cokolwiek innego: pokaż, że to działa. Gdy system jest wdrożony i już tylko dostrajasz drobiazgi, nagraj krótkie podsumowanie albo przejdź z klientem przez jeden czy dwa pełne przebiegi — od danych wejściowych, przez proces, po wynik — i pokaż, jak system poradził sobie z realnymi przypadkami. To zamienia abstrakcyjne „zautomatyzowaliśmy proces” w namacalny dowód, który widać na własne oczy.
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 danej firmie jest zator, w policzeniu, ile on kosztuje, i w usunięciu go tak, żeby było to widać. Narzędzie ogarniesz w tydzień. Następny krok jest spokojny: weź jeden realny, 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 przejście tej drogi nauczy cię więcej niż kolejne godziny czytania o niej.