O czym jest ten film
- Dwie drogi wejścia do branży AI — własna agencja albo rola „człowieka od AI” w obecnej firmie — i to, że w obu coraz trudniej się wyróżnić.
- Portfolio przestało wystarczać: liczą się udokumentowane wyniki biznesowe, a nie zrzuty ekranu z workflow.
- Narzędzia są wymienne, przenoszalne są umiejętności i sposób myślenia.
- „AI native” to nie wiedza, tylko domyślny odruch: najpierw sprawdzam, w jakim stopniu AI to zrobi.
- Przewagą nie jest model — wszyscy mają ten sam — tylko kontekst, wiedza dziedzinowa i negatywne promptowanie.
- Zarządzanie modelem zamiast rozmawiania z nim: plan, pytania kontrolne, adwokat diabła, jasna linia mety.
- Weryfikacja pracy przez samo AI jako sposób na dowożenie 90–95% zamiast 60–70%.
- Uprawnienia muszą siedzieć w narzędziach, nie w promptcie — wraz z historią maila wysłanego do 150 tysięcy osób.
- Ewaluacje na złotym zbiorze danych jako jedyny sposób, by odróżnić realną poprawę od przeczucia.
- Biznes jako rura: szukanie zatorów i wycieków, Northstar dla projektu oraz routing modeli jako kontrola kosztów tokenów.
Redakcyjne tłumaczenie
Spędziłem ponad pięć tysięcy godzin na budowaniu z użyciem AI. Na tej podstawie zbudowałem agencję z siedmiocyfrowymi przychodami, przeszkoliłem ponad czterysta tysięcy osób i zautomatyzowałem całą swoją firmę. W tym materiale przekazuję najważniejsze wnioski z tych pięciu tysięcy godzin — po to, żebyście nie musieli latami popełniać tych samych błędów co ja.
Lekcja pierwsza: zbieraj wyniki, nie buildy
Dziś wejście do świata AI wygląda na wybór między dwiema ścieżkami: albo zakładasz własną agencję i szukasz klientów, albo zostajesz „człowiekiem od AI” w firmie, w której już pracujesz. Obie są naprawdę dobre. Ja sam chciałem początkowo zostać osobą od AI w swojej firmie — pracowałem wtedy w Goldman Sachs — ale widziałem, że potrwa to zbyt długo i że jest zbyt dużo biurokratycznych przeszkód. Odszedłem i wtedy zbudowałem własną agencję AI. Warto jednak uczciwie przyznać, że obie drogi istnieją, i wybrać tę właściwą dla siebie.
Jedno jest wspólne dla obu: coraz trudniej się wyróżnić. Budowanie z AI stało się tak łatwe, że portfolio ma dziś każdy. Wszyscy obejrzeli te same tutoriale i zbudowali te same demo. Z zewnątrz to wszystko wygląda identycznie. Firmy po drugiej stronie nie są w stanie odróżnić kogoś naprawdę kompetentnego od kogoś, kto w weekend skleił demo z youtubowego poradnika.
Sposób na wyróżnienie się jest taki: przestań kolekcjonować buildy, zacznij kolekcjonować dowody. Portfolio mówi „zbudowałem taką rzecz”. Dowód mówi „oto co ta rzecz faktycznie dała biznesowi”. Za każdym razem, gdy coś zbudujesz, udokumentuj rezultat. Proces zajmował tyle godzin, teraz zajmuje tyle. Traciliśmy tyle leadów, teraz łapiemy wszystkie. Nawet przy malutkim projekcie, nawet jeśli robisz go wyłącznie dla siebie — zapisz liczbę i nagraj krótki przewodnik po rozwiązaniu. Bo osoba z pięcioma zrzutami ekranu workflow wygląda dokładnie jak wszyscy inni, a osoba z trzema realnymi wynikami się wyróżnia.
Dokładnie dlatego budujemy program certyfikacyjny w AI Automation Society — ta luka zaufania jest obecnie największym bólem po obu stronach: i dla firm, i dla dostawców usług.
Lekcja druga: narzędzia nie mają znaczenia
Mówię to jako ktoś, kto zbudował praktycznie cały swój kanał na YouTube wokół jednego czy dwóch narzędzi. Przez bardzo długi czas moim głównym narzędziem było n8n i pewnie wielu z was właśnie stamtąd mnie kojarzy. Dziś moim podstawowym narzędziem jest Claude Code.
(Informacja dodatkowa: n8n to platforma do wizualnego budowania automatyzacji i przepływów pracy, popularna w środowisku „AI automation”; Claude Code to agentowe narzędzie Anthropic działające w terminalu i w edytorze.)
Chodzi o to, że nowe i lepsze narzędzia będą wychodzić bez przerwy i to się nigdy nie skończy. Ale narzędzie nigdy nie było tą wartościową częścią. Wartościowe jest to, czego się nauczyłeś i jak myślisz. Pomyśl, czego nauczyło mnie n8n: czym jest wywołanie API, gdzie rzeczy zwykle się psują, jak przeczytać błąd i faktycznie go naprawić. Nic z tego nie zniknęło, gdy się przesiadłem. Przeniosłem to wszystko wprost do Claude Code.
To samo dotyczy tego, co budujesz. Wielu z was buduje teraz swój „system operacyjny AI”, tak jak ja — i jesteście całkowicie bezpieczni, bo to w gruncie rzeczy tylko foldery, pliki markdown i instrukcje. Czy uruchomicie to na Claude Code, na Codeksie, na Hermesie, czy na czymkolwiek, co pojawi się w przyszłym miesiącu — to wszystko się przenosi. A jeśli z jakiegoś powodu wasz setup się nie przenosi, to zadbajcie, żeby budować go w sposób faktycznie niezależny od narzędzia.
Nie czekaj więc na idealne narzędzie i nie stresuj się, gdy to ulubione zostanie zastąpione. Skup się obsesyjnie na umiejętnościach leżących pod spodem: jak jasno się komunikować, jak rozłożyć problem na części i jak znaleźć lepsze rozwiązanie, kiedy pierwsze zawiedzie.
Lekcja trzecia: bycie AI native to odruch, nie wiedza
Bycie AI native nie polega na tym, ile wiesz. Nie chodzi o to, ile modeli potrafisz wymienić ani ilu narzędzi używałeś. Chodzi o to, po co sięgasz najpierw. Kiedy coś ląduje na twoim biurku, czy twoim domyślnym odruchem jest „ciekawe, czy AI da radę to zrobić, sprawdzę”? Czy raczej odrabiasz to ręcznie, tak jak zawsze?
Pytanie „czy AI to potrafi” nigdy nie jest zero-jedynkowe. Prawdziwe pytanie brzmi: w jakim stopniu AI potrafi to zrobić. Jeśli doprowadzi cię do 70% celu, a resztę musisz ogarnąć sam — to ogromna wygrana. Jeśli zdejmie z ciebie tylko pierwsze 25%, to nadal wygrana, bo i tak jesteś daleko przed kimś, kto robi to w stu procentach ręcznie. Ta odpowiedź nigdy nie jest też ostateczna, bo modele i narzędzia wokół nich są dosłownie najgorsze, jakie kiedykolwiek będą — właśnie teraz. Bycie AI native to nie zasób wiedzy, tylko domyślne ustawienie twojego mózgu.
Lekcja czwarta: przewagą jest kontekst, nie model
Większość ludzi sądzi, że to samo AI jest wartościową częścią — że wygra ten, kto ma najlepsze prompty, najlepszy model albo najbardziej wymyślne skille. To jest odwrócone do góry nogami. AI to jedyna rzecz, do której wszyscy mają równy dostęp. Pomyśl: skoro każdy może użyć tego samego modelu Opus, to czy wszyscy nie powinni dostawać identycznych wyników? Nie — bo każdy wnosi do tego modelu i do całego środowiska inny system i inną ekspertyzę.
Wyobraź sobie księgowego, który buduje skill do przygotowywania budżetu. Będzie w tym dziesięć razy lepszy niż ktoś, kto nigdy nie dotknął arkusza kalkulacyjnego — bo wie, jak wygląda dobry budżet i gdzie ludzie popełniają błędy w procesie budżetowania.
Oto bardzo praktyczny przykład, jak to się przejawia we wszystkim, co robię. Przez pięć tysięcy godzin nadepnąłem na mnóstwo min i teraz wiem, jak nigdy więcej na nie nie nadepnąć. Dlatego zawsze stosuję negatywne promptowanie — w skillach, w systemach, w instrukcjach, w całym promptowaniu. Nieustannie mówię AI, czego ma nie robić. Ta lista zakazów to po prostu moje doświadczenie spisane na papierze, moje porażki spisane na papierze — rzeczy, o których początkujący nie ma prawa wiedzieć.
To nie jest zresztą żaden trik, który sam wymyśliłem. Wystarczy zajrzeć do własnej dokumentacji Anthropic dotyczącej promptowania Claude’a — mnóstwo tamtejszych przykładów jest naładowanych negatywnymi promptami. Rzeczy w rodzaju „nie dodawaj funkcji wykraczających poza to, o co poproszono” albo „nie dodawaj obsługi błędów dla scenariuszy, które nie mogą wystąpić”.
I o tym właśnie jest inżynieria kontekstu. Każdy ma nieco inną definicję tego terminu, ale ja myślę o tym w uproszczony sposób. Wracając do poprzedniej lekcji: wszyscy dostają ten sam model i ten sam harness, czyli aplikację opakowaną wokół modelu — jak choćby Claude Code. Inżynieria kontekstu to wszystko, co kładziesz na wierzchu: cała wiedza, którą go karmisz, sposób promptowania, instrukcje, skille, systemy, które wokół tego budujesz. To po prostu sposób, w jaki nakładasz własny mózg na ten potężny model.
Lekcja piąta: przestań rozmawiać z AI, zacznij nim zarządzać
Większość ludzi wpisuje polecenie, dostaje wynik, a jeśli jest słaby, uznaje, że AI jeszcze nie jest wystarczająco mądre. Ale ci, którzy wyciągają z tych narzędzi złoto, nie piszą po prostu lepszych promptów — oni lepiej zarządzają.
Zamiast mówić „napisz mi to” albo „zbadaj tamto”, daję modelowi problem i pozwalam mu powiedzieć, jak chce go rozwiązać. Każę mu zadawać mi pytania tak długo, aż będzie całkowicie pewien, że rozumie, czego chcę — zanim cokolwiek zbuduje.
Jeszcze jedno o tych modelach: są niejako trenowane, żeby ci się przypodobać. Udowodniono, że bywają nieco pochlebcze. Jeśli więc zapytasz model, co sądzi o twoim planie, może po prostu powiedzieć, że jest świetny, bo to właśnie chcesz usłyszeć. A każdy plan ma martwe pola. Dlatego zmuszaj modele do grania adwokata diabła. Każę różnym modelom atakować mój własny plan z wielu person: sceptycznego klienta, konkurenta, inżyniera, który będzie musiał to potem utrzymywać. Każdy z tych kątów wyłapie dziurę, której nie wyłapały pozostałe. To, co z tego wychodzi, jest znacznie bardziej dogłębne niż cokolwiek, co uzyskasz, pytając jeden model „czy to jest dobre?”.
Na koniec daj mu jasną linię mety, żeby dokładnie wiedział, jak wygląda „skończone”, i nie zatrzymywał się w połowie drogi. Wtedy może zacząć delegować pracę do subagentów, a ty masz plan prowadzący od pierwszego pomysłu aż po zweryfikowane wykonanie. To skróci ilość odbijania piłeczki o połowę.
AI nie jest twoim kumplem do czatowania. Jest twoim najnowszym pracownikiem — takim, który potrafi zatrudniać i delegować zadania kolejnym małym pracownikom AI. I będzie tylko tak dobre, jak dobry jesteś w zarządzaniu i orkiestrowaniu.
Lekcja szósta: weryfikacja
To być może najważniejsza lekcja dla każdego, kto buduje agentów AI. Kiedy prosisz AI o wykonanie zadania, chcesz, żeby było zrobione w stu procentach. Zwykle dostajesz jakieś 60–70%, potem dajesz feedback, model coś poprawia, dajesz kolejny feedback i w końcu jakoś dogrzebujesz się do 90–95%.
A gdyby AI mogło samo weryfikować swoją pracę i nie przestawało weryfikować, dopóki warunek nie zostanie faktycznie spełniony i dopóki nie będzie pewne swojego produktu? Wtedy mógłbyś wystrzelić jeden prompt, poczekać i dostać z powrotem rzecz, która już jest w 90–95% gotowa.
Konfiguracja tego jest znacznie prostsza, niż się wydaje. Wystarczy zadać sobie pytanie: gdyby tę pracę oddał mi człowiek, jak bym ją sprawdził? Jak przyznałbym jej pieczątkę akceptacji? Czy tylko bym na to spojrzał? Czy bym to przetestował? Czy przeszedłbym przez proces rejestracji? Cokolwiek zrobiłbyś ręcznie, żeby sprawdzić pracę, AI prawdopodobnie może zrobić za ciebie. Potrafi obsługiwać przeglądarkę, pisać testy, analizować wyniki, patrzeć na rzeczy z różnych perspektyw.
Na przykład przy budowaniu strony każę modelowi wejść w pętlę ze zrzutami ekranu: sprawdź, czy wszystko mieści się w kadrze, czy dobrze wygląda na mobile, czy nic nie jest zepsute. Potem każę mu poklikać i upewnić się, że wszystkie przyciski działają, że formularze są poprawnie sformatowane i wysyłają dane pod właściwy webhook.
Zacznij więc kazać swoim AI weryfikować to, co zrobiły. Każ im udowodnić ci, że praca jest naprawdę skończona.
Lekcja siódma: jeśli AI ma do czegoś dostęp, założ, że tego użyje
Tej lekcji nauczyłem się boleśnie. Mieliśmy agenta, który wysłał maila z kodem rabatowym do mniej więcej 150 tysięcy osób — czego oczywiście nie powinien był zrobić. Nikt mu tego nie kazał. Zobaczył zadanie na naszej liście to-do i zinterpretował je jako „napisz i wyślij kod rabatowy do całej listy”. I po prostu to zrobił.
Lekcja pod spodem jest taka, że istnieje ogromna różnica między warstwą uprawnień w promptcie a warstwą uprawnień w narzędziach. Możesz powiedzieć agentowi: „nigdy nie wysyłaj maili, twórz tylko wersje robocze”. Ale jeśli nadal ma narzędzie do wysyłania maili, to nadal może je wysyłać. I musisz założyć, że kiedyś to zrobi.
Te modele są niedeterministyczne — możesz uruchomić to samo sto razy i dostać sto różnych wyników. Podmieniasz model i cały system zaczyna zachowywać się inaczej, inaczej interpretować twoje skille i tak dalej. Zasada, która żyje w promptcie, to tylko sugestia. Zasada, która żyje w narzędziach, to prawdziwe ograniczenie.
Rób więc rzeczy takie jak zawężone klucze API. Klucz API to w gruncie rzeczy hasło, którym twój agent loguje się do usługi — i możesz go zawęzić tak, żeby fizycznie otwierał tylko określoną liczbę drzwi. Możesz dać agentowi klucz, który pozwala tworzyć wersje robocze maili, ale w ogóle nie pozwala ich wysyłać.
Czy dałbyś nowemu pracownikowi kartę kredytową ze słowami: „tylko jej nie używaj”? Karta działa, można za nią kupować, ale po prostu nie kupuj. Raczej byś tego nie zrobił.
Przejrzyj więc wszystko, czego twój agent może dotknąć: każde narzędzie, każdą bazę danych, każdy plik, każdy klucz — i załóż, że kiedyś użyje tego wszystkiego. A jeśli to nie ty budujesz te rzeczy, zadaj to pytanie temu, kto buduje: co ta rzecz faktycznie może zrobić samodzielnie? Czy może wysyłać, czy tylko tworzyć wersje robocze? A jeśli odpowiedź cię przeraża, napraw dostępy, nie prompt.
Lekcja ósma: ewaluacje
Kiedy zbudujesz agenta i on zadziała, udowodniłeś tylko tyle, że zadziałał raz, na jednym wyniku. A skoro modele są niedeterministyczne, nie masz pojęcia, jaki będzie twój wskaźnik skuteczności na stu prawdziwych uruchomieniach.
Rozwiązaniem są ewaluacje AI — a to znacznie mniej wyrafinowane, niż brzmi. Przykład: mieliśmy agenta wsparcia, który musiał wykonać sporo researchu. Musiał odszukać klienta, sprawdzić rzeczy w bazie danych i napisać odpowiedź. Zebraliśmy 500 przykładów prawdziwych, napisanych ręcznie przez ludzi odpowiedzi, o których wiedzieliśmy, że są dobre. To było nasze źródło prawdy — nasz złoty zbiór danych. Mogliśmy podać go z powrotem do systemu i punktować, ile razy agent faktycznie spełnił oczekiwania.
Przy takich ewaluacjach: jeśli odpowiedź jest całkowicie obiektywna, możesz oceniać ją zwykłym kodem. Ale często potrzeba trochę rozumowania, żeby stwierdzić, czy odpowiedź jest poprawna — i wtedy stosujesz LLM jako sędziego, czyli używasz modelu AI w roli oceniającego.
Sposób zaprojektowania ewaluacji sprowadza się więc do tego, jak człowiek faktycznie oceniłby tę pracę i jakie są kryteria sukcesu. Kiedy już to masz, możesz wprowadzić jedną drobną zmianę i przepuścić całą ewaluację jeszcze raz. Zamieniasz w ten sposób hipotezę w twarde „tak” albo „nie”, bo wiesz, czy zmiana poprawiła system, czy go pogorszyła — niezależnie od tego, czy była to zmiana promptu, konfiguracji narzędzi, czy nawet podmiana całego modelu.
Rzecz w tym, że czasem poprawka, co do której jesteś absolutnie pewien, że ulepszy system, obniża wynik. Nie można się opierać na przeczuciu. Trzeba to udowodnić. I zdecydowanie wolisz wyłapać to we własnych testach niż w realnym świecie, na oczach klientów — bo ewaluacja daje ci twardy grunt do stwierdzenia „to zadziałało” albo „to nie zadziałało” i pozwala z przekonaniem przenieść coś z fazy rozwoju na produkcję.
Zanim więc twój kolejny agent dotknie czegokolwiek prawdziwego, zbierz realne przykłady ze znanymi dobrymi odpowiedziami — nawet jeśli musisz zacząć od dwudziestu — i punktuj każdą wersję względem nich. Choć oczywiście im więcej przykładów w złotym zbiorze, tym lepiej.
Lekcja dziewiąta: biznes to rura — szukaj zatorów i wycieków
Pomyśl o firmie jak o rurze. Z przodu wpływa woda — to ruch, wszystkie leady i uwaga, która trafia do biznesu. Z tyłu woda wypływa jako zysk, jako przychód, który firma faktycznie zatrzymuje. W tej rurze mogą pójść źle dwie rzeczy: może pojawić się zator, który w połowie wszystko cofa, albo wyciek, przez który pieniądze uciekają bokiem i nigdy nie docierają do końca. Twoim zadaniem jest znaleźć jedne i drugie.
Po setkach wdrożeń największa rzecz, jakiej się nauczyłem, to że to, o co prosi interesariusz, prawie nigdy nie jest prawdziwym ograniczeniem. Przez „interesariusza” rozumiem po prostu tego, dla kogo pracujesz: jeśli prowadzisz agencję, to twój klient; jeśli jesteś człowiekiem od AI wewnątrz firmy, to twój szef. Tak czy inaczej przyjdzie do ciebie i powie: „potrzebuję chatbota” albo „potrzebuję konkretnie tej automatyzacji”. Ale to jest tylko to, co im się wydaje lekarstwem. Prawdziwa wartość leży w znalezieniu faktycznego zatoru albo wycieku, którego sami nie widzieli. Dosłownie w celowaniu w ograniczenia, bo tylko tak biznes naprawdę rośnie.
Zanim więc cokolwiek zbudujesz, nie przyjmuj po prostu zamówienia i nie biegnij z nim. Przejdź przez procesy, znajdź miejsca, gdzie się zatykają i gdzie wyciekają pieniądze, i zapytaj: gdzie tracą najwięcej czasu albo najwięcej pieniędzy? Kiedy przychodzisz z takim podejściem, coś się zmienia w tym, jak widzą cię interesariusze. Zamiast człowieka od przyjmowania zamówień, który buduje to, o co go poproszono, stajesz się konsultantem, któremu naprawdę zależy na wzroście firmy i na wyniku finansowym. Znajdź zator, znajdź wyciek i po prostu wymyśl, jak naprawić tę rurę.
Lekcja dziesiąta: każdy projekt potrzebuje Gwiazdy Polarnej
Kiedy już znajdziesz zator, nie zaczynasz od razu budować. Każdy projekt potrzebuje Gwiazdy Polarnej — jednej metryki, którą chcesz poruszyć — i musisz ją wybrać, zanim cokolwiek zbudujesz.
Pomyśl o tym tak: kiedy firma zatrudnia agencję reklamową, umowa jest krystalicznie jasna. Wydamy 10 tysięcy dolarów tygodniowo na reklamy i przyniesiemy wam z tych reklam dodatkowe 50 tysięcy dolarów przychodu tygodniowo. Każdy może na to spojrzeć i stwierdzić: tak, to się opłacało.
Projekty AI zwykle nie są tak formułowane. Nie jest to oczywiste, bo często mają one oszczędzać czas albo ciąć koszty, przez co wpływ na wynik finansowy jest trochę zamglony. To twoje zadanie, żeby ten wpływ był jasny. Robi się to tak, że masz punkt odniesienia i cel. Powiedzmy, że firma dostaje teraz pięć leadów tygodniowo. Idziesz do nich i mówisz: „Gdybyśmy zbudowali tę automatyzację AI i w ciągu dwóch miesięcy przeszli z pięciu leadów tygodniowo na piętnaście, czy to byłby sukces? Czy to w istotny sposób ruszyłoby wasz przychód albo marże?”. A jeśli wszyscy w zespole powiedzą: „tak, to zdecydowanie byłby sukces” — masz Gwiazdę Polarną tego projektu.
Budujesz w kierunku tej jednej liczby, a kiedy wdrażasz, każdy widzi, czy ta liczba poszła w górę, czy w dół. Ta jedna rozmowa zmienia w projekcie wszystko: build ma linię mety, interesariusz dokładnie wie, co dostał, a ty masz znacznie mocniejsze studium przypadku z prawdziwą liczbą w środku, zamiast komunikatu „zautomatyzowaliśmy X, Y i Z”.
Lekcja jedenasta: tokeny i routing modeli
Ta lekcja decyduje o tym, czy twoja praca z AI zarabia, czy traci pieniądze. Chodzi o tokeny. Tokeny to jednostki, według których modele AI naliczają opłaty. Każde słowo wchodzące i każde słowo wychodzące kosztuje cię odrobinę.
Błąd, który popełnia wiele osób, polega na rzucaniu największego, najmądrzejszego i najdroższego modelu na każdy pojedynczy krok procesu — i niemyśleniu o tym nigdy więcej. Mądre zagranie to dopasowanie modelu do konkretnego zadania. Przeczytanie kilkuset tysięcy słów artykułów i wyciągnięcie z nich jednoakapitowego podsumowania to czarna robota. Tanim, szybkim modelem w rodzaju Haiku zrobisz to za grosze. Wysyłanie tego do Fable 5 byłoby przesadą. Ale może ostatni kawałek rozumowania — gdzie bierzesz to podsumowanie, przykładasz je do realiów firmy i musisz podjąć decyzję strategiczną — to właśnie moment, w którym wprowadzasz Fable.
(Informacja dodatkowa: Haiku i Fable 5 to modele Anthropic o różnych klasach kosztu i możliwości; autor używa ich jako przykładu skrajności „tani i szybki” kontra „drogi i najsilniejszy”.)
Kiedy już przyswoisz tę ideę, możesz wbudować ją wprost w swoje systemy. Nazywa się to routingiem modeli: każde zadanie trafia do najtańszego modelu, który faktycznie sobie z nim poradzi, a te drogie są wzywane tylko wtedy, gdy zadanie tego naprawdę wymaga. Ta sama jakość wyniku, a rachunek może spaść dziesięciokrotnie albo więcej.
To będzie tylko zyskiwać na znaczeniu, bo modele lokalne stają się dużo lepsze i dużo mniejsze, a część rzeczy można dosłownie uruchomić całkowicie za darmo. Sufit dla zasady „dopasuj model do zadania” cały czas się podnosi.
Lekcja dwunasta: najpierw dowód, potem tytuł
Wszyscy wychowaliśmy się na tym samym scenariuszu: zdobądź dyplom, zdobądź tytuł, a wtedy wreszcie wolno ci wykonywać tę pracę. Ale to się właśnie odwraca. Każda osoba, którą widziałem, jak zostaje wciągnięta do roli związanej z AI albo awansuje do niej, wykonywała tę pracę już wcześniej — zanim rola w ogóle zaczęła istnieć.
I sama praca to była tylko połowa. Druga połowa to to, że współpracownicy i przełożeni zaczęli ich postrzegać jako „człowieka od AI” w firmie. Nie dlatego, że byli jakimiś szalonymi ekspertami trenującymi modele w piwnicy. Po prostu — w porównaniu z resztą budynku — to oni faktycznie eksperymentowali, robili małe testy, byli na bieżąco z nowinkami i wnosili projekty AI do firmy, podczas gdy wszyscy inni po prostu siedzieli bezczynnie.
Dowód idzie więc teraz przed tytułem. Weź jedno uciążliwe, powtarzalne zadanie ze swojej pracy — to, którego co tydzień się boisz — i zbuduj do niego automatyzację. A kiedy już coś zbudujesz, pokaż to dookoła. Pokaż zespołowi, pokaż szefowi, pokaż im realny wpływ na twoją codzienną pracę. Wkrótce zaczną budować stanowisko wokół tego, co i tak już robisz. A jeśli szukasz pierwszego klienta, zbuduj najpierw coś dla siebie, żeby wejść tam z dowodem, a nie z obietnicą.
Podsumowanie
To było dwanaście lekcji, których nauczyłem się po ponad pięciu tysiącach godzin budowania z AI. Rozbiłem to wszystko na darmowy przewodnik dostępny w mojej bezpłatnej społeczności na Skool — link znajdziecie w opisie. Znajdziecie tam także pełne kursy, materiały, skille i społeczność ponad 400 tysięcy osób budujących z AI.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zbieraj wyniki, nie zrzuty ekranu
Na czym polega: Portfolio pokazuje, że coś zbudowałeś; dowód pokazuje, co ta rzecz dała biznesowi. W świecie, gdzie każdy ma demo z tutoriala, tylko liczby odróżniają cię od reszty.
Jak stosować: Przy każdym projekcie — nawet własnym — zapisz metrykę przed i po (godziny procesu, liczba utraconych leadów, czas odpowiedzi) i nagraj kilkuminutowy przewodnik po rozwiązaniu. Trzy realne wyniki biją pięć zrzutów ekranu.
Na co uważać: Metryka musi być zebrana przed wdrożeniem, inaczej „przed” będzie zgadywane. Nie podawaj też liczb, których nie potrafisz obronić przed osobą znającą ten proces od środka.
2.Inwestuj w umiejętności, nie w narzędzie
Na czym polega: Autor przeszedł z n8n na Claude Code i nic wartościowego nie stracił — wiedza o API, o tym, gdzie systemy się psują i jak czytać błędy, przeniosła się w całości.
Jak stosować: Buduj swój „system operacyjny AI” jako foldery, pliki markdown i instrukcje, czyli w formacie niezależnym od narzędzia. Ucz się rozkładania problemów i jasnej komunikacji, nie kolejnych interfejsów.
Na co uważać: Jeśli twój setup mocno siedzi w zamkniętym formacie konkretnej platformy, to jest sygnał ostrzegawczy — sprawdź, co byś stracił przy migracji, zanim będziesz musiał migrować.
3.Pytaj „w jakim stopniu”, nie „czy”
Na czym polega: Bycie AI native to odruch sięgania po AI jako pierwsze, a pytanie o możliwości nie jest zero-jedynkowe — nawet 25% zdjęte z zadania to przewaga nad kimś, kto robi wszystko ręcznie.
Jak stosować: Przy każdym nowym zadaniu poświęć kilka minut na test, ile AI z tego zdejmie, zanim zaczniesz robić to ręcznie. Traktuj wynik jako częściową automatyzację, nie jako sukces albo porażkę.
Na co uważać: Odpowiedź ma krótki termin ważności — to, co nie wyszło pół roku temu, może wyjść dziś. Ale też nie rozciągaj częściowej automatyzacji na obszary, gdzie 70% poprawności oznacza realną szkodę.
4.Negatywne promptowanie jako zapis własnego doświadczenia
Na czym polega: Lista zakazów w skillach i instrukcjach to spisane porażki i miny, na które już nadepnąłeś. To rzecz, której początkujący nie ma skąd wiedzieć, i to ona różnicuje wyniki na tym samym modelu.
Jak stosować: Po każdym nieudanym przebiegu dopisuj do instrukcji konkretne „nie rób X”. Wzoruj się na dokumentacji Anthropic — np. „nie dodawaj funkcji wykraczających poza zakres”, „nie dodawaj obsługi błędów dla scenariuszy niemożliwych”.
Na co uważać: Lista zakazów rośnie i zaczyna zjadać kontekst oraz sobie przeczyć. Okresowo ją przycinaj i trzymaj zakazy konkretne, a nie ogólnikowe.
5.Zarządzaj modelem jak pracownikiem
Na czym polega: Zamiast wydawać polecenie, dajesz problem, każesz modelowi zaproponować sposób rozwiązania i dopytywać, dopóki nie zrozumie zadania. Do tego jasna definicja „skończone”.
Jak stosować: Standardowa sekwencja: problem → plan od modelu → runda pytań kontrolnych → kryterium ukończenia → dopiero wykonanie, ewentualnie z delegacją do subagentów.
Na co uważać: Ta faza kosztuje czas i tokeny — przy drobnych zadaniach jest przerostem formy. Zwraca się przy pracy wieloetapowej, gdzie źle zrozumiane założenie kosztuje cały przebieg.
6.Zmuszaj model do grania adwokata diabła
Na czym polega: Modele są pochlebcze — zapytane o zdanie na temat twojego planu skłaniają się ku pochwale. Atak na plan z wielu person (sceptyczny klient, konkurent, inżynier utrzymania) wyłapuje dziury, których jeden kąt nie widzi.
Jak stosować: Zdefiniuj 3–4 persony krytyków i puść plan przez każdą osobno, najlepiej w różnych modelach. Dopiero potem scal uwagi.
Na co uważać: Krytyka bez kryteriów generuje szum i zastrzeżenia, które nic nie zmieniają. Wymagaj konkretnych scenariuszy porażki, nie ogólnych obaw.
7.Weryfikacja wbudowana w zadanie
Na czym polega: Zamiast dogrzebywać się do 90% przez rundy feedbacku, każesz AI weryfikować własną pracę i nie kończyć, dopóki warunek nie jest spełniony — wtedy jeden prompt zwraca produkt już bliski gotowości.
Jak stosować: Zadaj sobie pytanie, jak sprawdziłbyś tę pracę oddaną przez człowieka, i przełóż to na czynności modelu: pętla ze zrzutami ekranu, klikanie przycisków, testy formularzy, sprawdzenie webhooka, testy automatyczne.
Na co uważać: Model potrafi „zaliczyć” własny test, jeśli kryterium jest miękkie. Kryteria muszą być sprawdzalne z zewnątrz (zrzut ekranu, kod odpowiedzi, przechodzący test), a nie oparte na deklaracji, że jest dobrze.
8.Uprawnienia w narzędziach, nie w promptcie
Na czym polega: Zasada w promptcie to sugestia, zasada w narzędziach to ograniczenie. Autor stracił kontrolę nad agentem, który samodzielnie wysłał kod rabatowy do ok. 150 tysięcy osób — bo miał do tego narzędzie.
Jak stosować: Przejrzyj wszystko, czego agent może dotknąć — narzędzia, bazy, pliki, klucze — i załóż, że kiedyś użyje wszystkiego. Stosuj zawężone klucze API: uprawnienie do tworzenia wersji roboczych bez uprawnienia do wysyłki.
Na co uważać: Podmiana modelu zmienia zachowanie całego systemu, więc audyt zrobiony raz nie jest wieczny. Jeśli nie ty budujesz, pytaj wprost: co ta rzecz może zrobić sama i czy wysyła, czy tylko szkicuje.
9.Ewaluacje na złotym zbiorze zamiast przeczuć
Na czym polega: Działający agent dowodzi tylko jednego udanego przebiegu. Zbiór realnych, znanych jako dobre odpowiedzi pozwala punktować każdą wersję systemu i mierzyć, czy zmiana pomogła, czy zaszkodziła.
Jak stosować: Zacznij od 20 dobrych przykładów, docelowo kilkuset. Obiektywne odpowiedzi oceniaj kodem, wymagające interpretacji — modelem w roli sędziego. Po każdej zmianie promptu, narzędzia lub modelu przepuść cały zestaw ponownie.
Na co uważać: Zmiany, co do których jesteś pewien, potrafią obniżyć wynik — to normalne i po to są ewaluacje. Uważaj też na jakość zbioru: jeśli „dobre” przykłady są niekonsekwentne, mierzysz szum.
10.Zator, wyciek i jedna metryka projektu
Na czym polega: Biznes to rura: na wejściu ruch, na wyjściu zysk, a między nimi zatory i wycieki. To, o co prosi klient („chcę chatbota”), prawie nigdy nie jest realnym ograniczeniem. Do tego każdy projekt potrzebuje jednej metryki ustalonej przed budową.
Jak stosować: Zanim zbudujesz, przejdź proces i znajdź, gdzie tracą najwięcej czasu i pieniędzy. Potem ustal Gwiazdę Polarną wraz z punktem wyjścia i horyzontem czasowym — np. z 5 do 15 leadów tygodniowo w dwa miesiące — i uzyskaj zgodę zespołu, że to jest sukces.
Na co uważać: Podważanie zamówienia klienta wymaga taktu — pokaż dane z procesu, nie samą opinię. I upewnij się, że wybrana metryka jest mierzalna istniejącymi narzędziami, inaczej po wdrożeniu nikt nie udowodni efektu.