Buduj i sprzedawaj automatyzacje w Claude Code — framework decyzyjny

To jest wersja kursu do trzymania pod ręką, ułożona jako ciąg decyzji. Każdy etap zaczyna się od jednego pytania do rozstrzygnięcia, a kończy na tym, co dyskwalifikuje opcję. Sięgasz tu, gdy stoisz przed konkretnym wyborem — który proces zautomatyzować, jak uruchomić agenta, gdzie postawić punkt zatwierdzenia, ile policzyć — i chcesz wybrać świadomie, zamiast iść za pierwszym pomysłem.

Zasada, która wraca na każdym etapie: budowanie przestało być wąskim gardłem. Wartość leży w trafnym rozpoznaniu problemu i policzeniu, ile jest wart — nie w efektownym agencie.

Decyzja: co w ogóle budować

Który proces automatyzować

Pytanie do rozstrzygnięcia: gdzie w danej firmie marnuje się najwięcej czasu na powtarzalną, kosztowną pracę?

Obraz, do którego warto wracać: firma to rura, przez którą płynie praca, zlecenia i pieniądze. Jeśli w rurze jest zator, dolewanie kolejnej wody — więcej ludzi, AI doczepione do przypadkowych problemów — niczego nie przyspieszy. Najpierw znajdujesz zator i go usuwasz, a dopiero potem zwiększasz przepływ.

Kryteria, po których oceniasz kandydata na automatyzację:

• Praca jest powtarzalna — wraca regularnie, nie jest jednorazowa.
• Pochłania dużo czasu — czyli realnie kosztuje firmę pieniądze.
• Da się ją opisać zwykłym językiem jako proces (przepis krok po kroku).

Co dyskwalifikuje opcję:

• Pomysł zaczyna się od narzędzia („zbuduję agenta w Claude Code”), a nie od problemu firmy.
• Agent miałby być efektowny, ale powstaje w oderwaniu od konkretnego zatoru — to ładna zabawka, za którą nikt nie zapłaci.

Efektowny agent bez zatoru pod spodem to zabawka. Agent, który usuwa konkretne, kosztowne wąskie gardło, to coś, za co rynek płaci. To cała różnica.

Decyzje przy ustawieniu środowiska

Jak uruchomić Claude Code

Pytanie do rozstrzygnięcia: w którym z czterech wariantów uruchomienia pracować przy danym zadaniu?

Każdy wariant ma inny kompromis. Nie ma jednej dobrej odpowiedzi — wybierasz pod siebie i pod zadanie, a nie „bo ktoś tak robi”.

Kryterium domyślne: jeśli dopiero zaczynasz albo chcesz się uczyć, bierzesz rozszerzenie edytora (VS Code) — widzisz pliki i rozmowę obok siebie, więc łatwo śledzić, co agent zmienia.

Co dyskwalifikuje wariant:

• Wybierasz go „bo ktoś tak robi”, a nie pod swoje zadanie.
• Bierzesz przeglądarkę do nauki, choć jej sens to długie zlecenia chodzące w tle.

Który model

Pytanie do rozstrzygnięcia: którego z trzech modeli użyć do danej roboty?

Do wyboru masz zwykle trzy — od najszybszego i najtańszego, przez pośredni, po najmocniejszy (Haiku, Sonnet, Opus). Model zmieniasz w locie poleceniem /model.

Kryteria wyboru:

• Na początku zostaw ustawienie domyślne albo trzymaj się najmocniejszego — wyrobisz sobie wyczucie jakości.
• Na dłużej sensowna strategia to model pośredni do większości pracy, a najmocniejszy włączasz tylko do trudnych decyzji projektowych albo zaplątanych błędów — i wracasz do tańszego.
• Na słabszy przełączasz się świadomie, np. gdy zlecasz prostą, masową robotę i chcesz oszczędzać.

Co dyskwalifikuje wybór:

• Schodzisz na słabszy model na samym początku, zanim wyrobisz sobie wyczucie jakości.
• Trzymasz najmocniejszy model do prostej, masowej roboty, w której tylko przepalasz koszty.

Jak pilnować okna kontekstu

Pytanie do rozstrzygnięcia: co zrobić z pamięcią roboczą modelu, gdy się zapełnia?

Okno kontekstu to robocza pamięć modelu — notes, w którym Claude trzyma twoje polecenia, pliki i całą dotychczasową rozmowę. Pojemność jest skończona, zwykle rzędu dwustu tysięcy tokenów. Gdy notes się zapełnia, model gubi wątek albo musi streścić sam siebie, a jakość spada. Zwykle to nie wina modelu, tylko zaśmieconej pamięci.

Kryterium: im dłuższa praca, tym bardziej świadomie zarządzasz kontekstem; na starcie wystarczy rozumieć, co się dzieje.

Co dyskwalifikuje opcję:

• Ciągniesz jedną rozmowę przez kilka różnych zadań — zaśmiecasz pamięć i sam zbijasz sobie jakość.

Decyzje przy budowie automatyzacji

Co oddać narzędziu, a co agentowi (schemat WAT)

Pytanie do rozstrzygnięcia: dla danego kroku procesu — czy ma go wykonać przewidywalne narzędzie, czy decydujący agent?

Schemat WAT (workflow, agent, tools) porządkuje całą pracę. Workflow to proces opisany zwykłym językiem jak przepis. Narzędzia to konkretne, przewidywalne czynności (np. fragment kodu, który zawsze tak samo wyciąga dane albo składa plik). Agent to model w roli decydenta: czyta workflow, sięga po narzędzia, radzi sobie z wyjątkami.

Kryterium: to, co przewidywalne, oddajesz narzędziu — taniej i pewniej. To, co wymaga decyzji, zostawiasz agentowi.

Co dyskwalifikuje wybór:

• Każesz modelowi za każdym razem wymyślać od nowa rzecz, która powinna działać identycznie — płacisz więcej i tracisz pewność wyniku.

Gdzie postawić punkt zatwierdzenia przez człowieka

Pytanie do rozstrzygnięcia: czy dany krok automatyzacja może domknąć sama, czy ostatnie słowo zostaje przy człowieku?

Zasada, którą przeniesiesz na praktycznie każde zlecenie: automatyzuj nudne kroki, zostaw człowiekowi decyzje wagi ciężkiej. W przykładzie z newsletterem workflow dochodzi do punktu, w którym to ty zatwierdzasz tytuł i całość przed wysyłką — celowo.

Kryteria, kiedy stawiasz punkt zatwierdzenia:

• W grę wchodzi reputacja — coś wychodzi pod twoim nazwiskiem albo nazwiskiem klienta.
• Pomyłka jest kosztowna i trudna do odkręcenia.

Co dyskwalifikuje pełną automatyzację (czyli kiedy musi być człowiek):

• Krok wypuszcza coś „w świat” bez odwrotu, a błąd uderza w reputację — wtedy nie domykasz go automatem.

Pamiętaj o rozróżnieniu, które wraca dalej: w tle pracują workflow i narzędzia, a nie agent z edytora. Agent zostaje po twojej stronie, do budowania i poprawiania.

Jak reagować, gdy coś nie zadziała

Pytanie do rozstrzygnięcia: gdy efekt jest słaby albo coś się posypało — gdzie szukać przyczyny?

Za pierwszym razem coś się posypie i to normalny etap, nie powód do paniki. Typowo wychodzi, że testowa wiadomość przyszła z rozjechanym formatowaniem albo że agent dostał błędny identyfikator arkusza i nie miał do niego dostępu.

Kryteria diagnozy (w tej kolejności):

1. Czy polecenie było precyzyjne — czy jasno opisałeś, czego chcesz, na jaki efekt liczysz i czego nie robić? Mgliste polecenie daje mglisty efekt.
2. Czy agent ma dostęp do tego, czego potrzebuje (właściwy adres, materiały, narzędzie)?
3. Dopiero gdy wejście jest w porządku, rozważasz, że problem leży gdzie indziej.

Lekarstwo: pokazujesz agentowi konkretnie, co jest nie tak („wiadomość przyszła z rozjechanym tłem, popraw to”; „podałem zły identyfikator arkusza, oto właściwy”). Im konkretniej nazwiesz usterkę, tym szybciej ją usunie.

Co dyskwalifikuje błędną reakcję:

• Zrzucasz winę na model i odpuszczasz po pierwszym błędzie, zamiast poprawić wejście — to właśnie odróżnia tych, którzy dowożą działające systemy, od tych, którzy rezygnują.

Decyzja przed oddaniem klientowi

Czy system jest gotowy

Pytanie do rozstrzygnięcia: czy można wystawić proces na harmonogram lub wyzwalacz i pokazać go klientowi?

Obraz: zanim dopuścisz pociągi na nowy tor, puszczasz po nim różne składy — lekkie, ciężkie, na różnych kołach. Tak samo testujesz automatyzację, zanim wpuścisz ją na produkcję.

Kryterium gotowości: przepuszczasz przez proces serię różnych wejść — typowe, ale też skrajne i nietypowe: pusty dokument, niekompletne dane, dziwny format, dwa zgłoszenia naraz. Każdy taki przypadek musi kończyć się sensownym wynikiem albo czytelnym komunikatem, a nie cichą awarią. Gdy coś się sypie, poprawiasz i przepuszczasz jeszcze raz.

Co dyskwalifikuje „gotowość”:

• Sprawdziłeś tylko typowy przypadek i pomijasz skrajne — wielu początkujących właśnie tu odpuszcza.
• Proces kończy się cichą awarią zamiast czytelnego komunikatu.

Dopiero gdy system przejdzie przez trudne przypadki, masz prawo spojrzeć klientowi w oczy i powiedzieć: to działa.

Decyzje przy sprzedaży i wycenie

Jak wejść w rozmowę sprzedażową

Pytanie do rozstrzygnięcia: od czego zaczynasz rozmowę z klientem?

Pierwsza zasada: nie wchodzisz od strony „buduję automatyzacje w Claude Code”. Klienta to nie obchodzi — młotek nie jest ważny, ważny jest efekt.

Kryterium dobrego otwarcia: zaczynasz od pytań diagnostycznych — gdzie tracisz najwięcej czasu w biznesie? które procesy chciałbyś, żeby robiły się same? Diagnoza prowadzi do rozwiązania, a rozwiązanie da się przeliczyć na mierzalną wartość dla firmy.

Co dyskwalifikuje otwarcie:

• Zaczynasz od „pokażę ci mój workflow” i prezentacji narzędzia — zostajesz „kolejnym od automatyzacji”, zamiast sprzedawcą rozwiązania.

Jest tu jeszcze jedna pułapka: umieć kazać agentowi coś zbudować to nie to samo, co umieć ocenić, czy wynik jest dobry. Nie musisz być programistą, ale wraca tu postawa z początku — bądź ciekawy, czytaj, co agent robi, dopytuj „dlaczego tak?”. To ciekawość, nie znajomość kodu, pozwala ci odpowiadać przed klientem za jakość.

Jak wycenić rozwiązanie

Pytanie do rozstrzygnięcia: od czego ustawiasz cenę — od kosztu wytworzenia czy od wartości dla klienta?

Najważniejsza zmiana jest w głowie: wycena oparta na wartości. Nie liczysz, ile godzin zajmie ci budowa — liczysz, ile automatyzacja jest warta dla firmy. Szklanka wody ma inną wartość dla kogoś po biegu w upale niż dla kogoś w klimatyzowanym biurze; ten sam produkt, inna wartość.

Sposób liczenia wartości (liczby traktuj jako mechanizm, nie obietnicę — w realnym projekcie podstawiasz dane klienta): bierzesz koszt godziny pracy osoby, która dziś robi to ręcznie, mnożysz przez czas, jaki proces pochłania, i skalujesz do tygodnia, miesiąca, roku. To twój punkt odniesienia — nie „ile godzin spędzę nad budową”, tylko „ile firma przestanie tracić, gdy to ruszy”.

Pięciostopniowy schemat PRICE:

Co dyskwalifikuje wycenę:

• Liczysz cenę od liczby godzin budowy zamiast od wartości dla firmy — pozycjonujesz się jak freelancer, nie jak partner.

Jak rozliczać i kiedy proponować stałą współpracę

Pytanie do rozstrzygnięcia: w jakim modelu rozliczać i w którym momencie proponować stałą opiekę?

Kryterium momentu na stałą umowę: zaufanie przychodzi przed stałą umową. Prosić o miesięczny abonament, zanim cokolwiek dla kogoś zrobiłeś, to jak prosić o rekomendację przed rozpoczęciem współpracy. Najpierw dostarczasz jeden, dwa projekty i pokazujesz wartość — wtedy rozmowa o stałej opiece staje się naturalna.

Ścieżka modelu rozliczeń:

• Na początku rozliczenie godzinowe bywa w porządku — zależy ci na doświadczeniu i dowodach, nie na maksymalnej stawce.
• Później przesuwasz się w stronę rozliczenia za etapy (kamienie milowe). Godziny pozycjonują cię jak freelancera; etapy — jak partnera.
• Nie ma jednego słusznego modelu: rynek znosi stałą cenę za efekt, pakiety godzin i abonament z określonym zakresem.

Krok, który buduje zaufanie najmocniej: gdy system już działa, pokaż, że działa — nagraj krótkie podsumowanie albo przejdź z klientem przez jeden czy dwa pełne przebiegi (od danych wejściowych po wynik). To zamienia abstrakcyjne „zautomatyzowaliśmy proces” w namacalny dowód.

Co dyskwalifikuje podejście:

• Obsesyjnie myślisz o stałym abonamencie, zanim dostarczyłeś choć jeden projekt — to drugi częsty błąd, zaraz po pominięciu testów.
• Na starcie ścigasz maksymalną stawkę zamiast zbierać doświadczenie i dowody.

---

Ścieżka decyzji — jedna strona

Przejdź przez te pytania po kolei. Każde to jedna decyzja do podjęcia, zanim ruszysz dalej.

1. Proces — gdzie firma marnuje najwięcej czasu na powtarzalną pracę? (zacznij od zatoru, nie od narzędzia)
2. Wariant uruchomienia — terminal, aplikacja, rozszerzenie edytora czy przeglądarka? (uczysz się → rozszerzenie VS Code)
3. Model — domyślny lub najmocniejszy na start; pośredni do większości pracy; słabszy świadomie do masowej roboty
4. Kontekst — /clear na nowe zadanie, /compact przy ~60% zapełnienia, reszta streszcza się sama
5. WAT — krok powtarzalny → narzędzie; krok wymagający decyzji → agent
6. Punkt zatwierdzenia — reputacja lub kosztowna pomyłka? → ostatnie słowo zostaw człowiekowi
7. Diagnoza błędu — najpierw precyzja polecenia, potem dostęp, dopiero potem reszta
8. Gotowość — przeszło przez skrajne i nietypowe wejścia bez cichej awarii? → dopiero teraz produkcja
9. Otwarcie rozmowy — pytaj o problem i stracony czas, nie pokazuj narzędzia
10. Wycena — licz od wartości dla firmy, nie od godzin budowy; prowadź rozmowę schematem PRICE
11. Rozliczenie — najpierw dostarcz i pokaż dowód; godziny → etapy; stała umowa dopiero po zaufaniu

Jedna myśl na koniec: wartość nie leży w zbudowaniu efektownego agenta — budowanie jest dziś łatwe. Leży w trafnym rozpoznaniu zatoru, policzeniu, ile kosztuje, i usunięciu go tak, żeby było to widać.