Prawie każdy, kto zaczyna budować z AI, gubi kilka pierwszych miesięcy w tym samym miejscu. Uczy się kolejnego narzędzia zamiast umiejętności, która pod nim siedzi. Zbiera zrzuty ekranu z przepływów, których nikt nie potrafi od siebie odróżnić. Uruchamia agenta, ten działa za pierwszym razem, i to wystarcza za dowód. Bierze zlecenie dosłownie, choć problem firmy leży zupełnie gdzie indziej. Żadna z tych rzeczy nie wynika z braku zdolności. Wynika z kolejności: które decyzje naprawdę ważyły, widać dopiero po czasie.
Dwanaście lekcji, które w tej pracy wracają najczęściej, ułożyłam w sześć par. Idą tak: od tego, co czyni cię wiarygodnym, przez odruch sięgania po AI i zarządzanie nią jak zespołem, po ograniczanie ryzyka, wybór właściwego problemu i pilnowanie rachunku.
Wiarygodność i trwałe umiejętności
Do pracy z AI wchodzi się dziś dwiema drogami. Albo zakładasz własną działalność i szukasz klientów, albo zostajesz osobą od AI w firmie, w której już pracujesz. Obie są dobre i obie mają teraz ten sam problem: przestało być widać różnicę między kimś, kto naprawdę umie, a kimś, kto w weekend złożył demo z poradnika. Zbudowanie podstawowych rzeczy jest tak łatwe, że portfolio ma dziś każdy, a jedno od drugiego prawie nie różni się treścią. Kupujący po drugiej stronie nie ma jak tego rozstrzygnąć.
Wyjście jest jedno: przestań zbierać zbudowane rzeczy i zacznij zbierać dowody. Portfolio mówi, co zbudowałeś. Dowód mówi, co się przez to zmieniło w firmie. To dwa różne zdania i tylko drugie coś rozstrzyga.
To nudna robota i trzeba ją zacząć od pierwszego dnia. Po każdej skończonej rzeczy zapisz cztery pozycje: co robiło się ręcznie, ile to zajmowało, ile zajmuje teraz i co dokładnie przejęła AI. Do tego dwuminutowe nagranie z ekranu, na którym pokazujesz przejście od jednego stanu do drugiego. Rób to nawet wtedy, gdy projekt jest mały i zrobiony wyłącznie dla siebie, bo dowód z własnego biurka też jest dowodem. Ktoś z pięcioma zrzutami ekranu wygląda jak wszyscy. Ktoś z trzema opisanymi wynikami wygląda inaczej. Dlaczego samo „umiem to zbudować” przestało cokolwiek sprzedawać i co stawia się na stole zamiast tego, opisywałam osobno: czego agent nie podrobi.
Druga lekcja bywa nieprzyjemna dla kogoś, kto właśnie opanował swoje pierwsze narzędzie: narzędzia nie mają znaczenia. Lepsze wychodzą bez przerwy i to się nie skończy. Wartościowa nigdy nie była sama aplikacja, tylko to, czego się przy niej nauczyłeś: czym jest wywołanie API, gdzie takie układy najczęściej pękają, jak przeczytać komunikat błędu i go naprawić, zamiast zaczynać od nowa. Przy zmianie narzędzia to wszystko przenosi się razem z tobą.
Tak samo jest z tym, co budujesz. Jeśli twój system pracy z AI to w środku foldery, pliki tekstowe i instrukcje, przeniesie się gdzie indziej niemal bez wysiłku. Jeśli siedzi w jednym zamkniętym narzędziu, przy przesiadce zaczynasz od zera. O zawężaniu zestawu narzędzi tak, żeby nie gonić każdej premiery, mam osobny tekst: prosty zestaw narzędzi AI na początek. Tutaj wystarczy prosty test przed każdą większą inwestycją czasu. Co mi zostanie, jeśli to narzędzie zniknie za pół roku? Jeśli odpowiedź brzmi „nic”, to nie inwestycja, tylko przyzwyczajenie.
AI-native to kwestia odruchu, nie wiedzy
Bycie AI-native nie mierzy się tym, ile modeli potrafisz wymienić z nazwy. Mierzy się pierwszym odruchem, kiedy na biurku ląduje nowe zadanie. Jedni zaczynają od pytania, w jakiej części może to zrobić AI. Drudzy odruchowo robią całość ręcznie, bo zawsze tak robili. Cała różnica siedzi w tym jednym odruchu, nie w zasobie wiedzy.
Samo pytanie też zwykle wymaga poprawki. „Czy AI to zrobi?” nie ma odpowiedzi tak albo nie. Pytaj, w jakim stopniu to zrobi. Jeśli wyręcza cię w większości zadania, a resztę domykasz sam, to duża wygrana. Jeśli rusza je tylko z miejsca i zdejmuje z ciebie sam początek, to nadal jest zysk, bo jesteś dalej niż ktoś, kto robi całość od zera. Odpowiedź nie jest przy tym nigdy ostateczna: modele i narzędzia wokół nich są dziś najsłabsze, jakie kiedykolwiek będą. Zadanie, którego nie dało się przekazać pół roku temu, sprawdź jeszcze raz.
Druga lekcja z tej pary idzie w poprzek intuicji. Wielu ludzi zakłada, że wartością jest sama AI: wygra ten, kto ma najlepsze prompty albo najmocniejszy model. Jest odwrotnie. Model to jedyna rzecz, do której wszyscy mają równy dostęp. Gdyby liczył się tylko on, każdy dostawałby ten sam wynik.
Wyniki się różnią, bo każdy dokłada do modelu coś innego: własny sposób pracy i własną znajomość dziedziny, o której mówi. Księgowy, który buduje sobie narzędzie do składania budżetu, wypadnie nieporównywalnie lepiej niż ktoś, kto nigdy nie prowadził arkusza. Nie dlatego, że lepiej promptuje. Dlatego, że wie, jak wygląda dobry budżet i w którym miejscu ludzie się przy nim mylą.
Najpraktyczniej widać to w promptach negatywnych, czyli w mówieniu AI, czego nie robić. Lista zakazów jest twoim doświadczeniem zapisanym zdanie po zdaniu: każda pułapka, którą już znasz, zamienia się w jedno „nie rób tego”. Początkujący nie ma skąd jej wziąć, bo jeszcze w żadną nie wpadł. Zajrzyj do dokumentacji Anthropica o promptowaniu Claude'a: jej przykłady są pełne właśnie takich zakazów, w rodzaju „nie dodawaj funkcji, o które nikt nie prosił” albo „nie pisz obsługi błędów dla sytuacji, które nie mogą się zdarzyć”.
Zacznij więc prowadzić własną listę. Za każdym razem, gdy AI zrobi coś nie tak, dopisz jedno zdanie w formie zakazu, a potem wklej tę listę do instrukcji na stałe. Po miesiącu masz dokument, którego nie ma nikt inny.
Stąd bierze się inżynieria kontekstu, choć definicje tego terminu chodzą różne. Najprościej: model i aplikacja, w której z niego korzystasz, są takie same dla wszystkich. Inżynieria kontekstu to wszystko, co dokładasz na wierzch, czyli wiedza, którą mu podajesz, sposób pisania poleceń, instrukcje, gotowe procedury i system wokół nich. Twoja głowa nałożona na cudzy model.
Zarządzaj AI jak zespołem
Przestań rozmawiać z AI i zacznij nią zarządzać. Najczęstszy schemat wygląda tak: ktoś wpisuje polecenie, dostaje słaby wynik i uznaje, że model jeszcze nie dorósł. A ludzie, którzy wyciągają z tych narzędzi naprawdę dobre rzeczy, rzadko piszą lepsze prompty. Oni lepiej prowadzą pracę.
Zamiast wydać polecenie „napisz mi to”, dajesz problem i pozwalasz modelowi zaproponować, jak chce go rozwiązać. Potem każesz mu dopytywać, dopóki nie będzie pewien, że rozumie, o co ci chodzi, i tylko wtedy pozwalasz zacząć. Ten jeden ruch oszczędza ci większość późniejszych rund poprawek.
Jest przy tym pułapka, o której łatwo zapomnieć: modele są trenowane tak, żeby ci się przypodobać. Zapytasz, co sądzą o twoim planie, i usłyszysz, że plan jest dobry, bo tego chcesz usłyszeć. Tymczasem każdy plan ma martwe pola. Dlatego każ modelowi atakować twój pomysł i to z kilku stron naraz: jako nieufny klient, który ma za to zapłacić, jako konkurent szukający luki, jako inżynier, który będzie to utrzymywać przez najbliższe dwa lata. Każda z tych perspektyw wyłapuje dziurę, której nie widzą pozostałe. Jak ustawić taką krytykę, żeby nie skończyła się na uprzejmościach, opisywałam osobno: zanim zbudujesz z AI, każ jej podważyć twój pomysł.
Na koniec dajesz wyraźną linię mety, czyli jedno zdanie o tym, co dokładnie znaczy „gotowe”. Bez niej model kończy w połowie i melduje sukces. Z nią potrafi rozplanować pracę i rozdzielić ją na mniejsze zadania, a ty dostajesz całą drogę od pomysłu do sprawdzonego wyniku. Traktuj AI nie jak rozmówcę, ale jak nowego pracownika, który potrafi zatrudniać kolejnych. Będzie tak dobra, jak dobrze ją prowadzisz.
Weryfikacja jest przedłużeniem tej samej myśli, a dla każdego, kto buduje agentów, to chyba najważniejsza pozycja na całej liście. Kiedy zlecasz AI zadanie, chcesz wynik gotowy. Pierwszy wynik prawie nigdy gotowy nie jest. Zgłaszasz uwagę, model poprawia, zgłaszasz kolejną i rundami dociągasz to do stanu, który da się komuś oddać.
A gdyby model sam sprawdzał swoją pracę i nie oddawał jej, dopóki warunek nie zostanie spełniony? Wtedy jedno polecenie wystarcza, a ty odbierasz rzecz, która przeszła już kilka rund bez ciebie.
Ustawienie tego jest prostsze, niż brzmi. Zadaj sobie jedno pytanie: gdyby tę pracę oddał mi człowiek, jak bym ją sprawdziła? Popatrzyłabym tylko? Przeklikałabym? Przeszłabym całą rejestrację od początku do końca? Cokolwiek robisz ręcznie przy sprawdzaniu, model najprawdopodobniej zrobi za ciebie: obsłuży przeglądarkę, napisze testy, przejrzy wyniki, spojrzy na rzecz z kilku stron.
Weź stronę internetową. Model wchodzi w pętlę zrzutów ekranu i sprawdza, czy nic nie wychodzi za krawędź i czy układ trzyma się na telefonie. Potem klika po kolei wszystkie przyciski i wysyła formularze, żeby zobaczyć, czy trafiają tam, gdzie powinny. Dopiero wtedy melduje, że skończył. Samo zapisanie takiego warunku w poleceniu, tak żeby agent naprawdę go dowiózł, rozłożyłam w tekście nie pytaj, czy skończył, każ mu udowodnić, że działa.
Ogranicz ryzyko, zanim ono ograniczy ciebie
Jeśli AI ma do czegoś dostęp, przyjmij, że kiedyś z tego skorzysta. Agent, który ma narzędzie do wysyłania maili, kiedyś wyśle maila. Nikt mu tego nie każe. Wystarczy, że zobaczy na liście zadanie, przeczyta je jako zgodę i wykona. Takiego zdarzenia nikt nie planuje i właśnie dlatego trzeba je uniemożliwić z góry.
Pod tym siedzi różnica między dwoma rodzajami ograniczeń. Możesz napisać agentowi „nigdy nie wysyłaj maili, przygotowuj tylko wersje robocze”. Dopóki ma narzędzie do wysyłki, nadal potrafi wysłać. Reguła w poleceniu jest sugestią. Reguła w narzędziach jest ograniczeniem. Te modele są przy tym nieprzewidywalne w sensie technicznym: to samo zadanie uruchomione sto razy daje sto różnych przebiegów, a po podmianie modelu cały układ zaczyna czytać twoje instrukcje inaczej.
W praktyce znaczy to tyle, że ograniczasz dostępy, a nie słowa. Klucz API to hasło, którym agent loguje się do usługi, i można go zawęzić tak, że fizycznie otwiera tylko część drzwi. Możesz dać agentowi klucz, który pozwala przygotować maila, ale nie pozwala go wysłać. Poza pracą z AI stosujesz to rozumowanie bez zastanowienia: nikt nie daje nowej osobie działającej karty firmowej ze słowami „tylko jej nie używaj”. Karta działa, więc kiedyś zostanie użyta.
Przejrzyj zatem wszystko, czego agent może dotknąć: każde narzędzie, każdą bazę, każdy plik, każdy klucz. Co konkretnie odbiera się agentowi na tym poziomie, wypisałam w tekście o kluczach, a nie promptach, jako realnym ograniczeniu agenta. A jeśli nie ty to budujesz, zadaj osobie, która buduje, jedno pytanie: co ta rzecz może zrobić sama, bez pytania kogokolwiek? Wysłać czy tylko przygotować? Jeśli odpowiedź cię niepokoi, popraw dostępy, nie polecenie.
Kiedy zbudowany agent zadziała, masz dowód dokładnie na jedno: że zadziałał raz, na jednym przypadku. Skoro te modele są nieprzewidywalne, o skuteczności na stu prawdziwych przebiegach nie wiesz jeszcze nic.
Odpowiedzią są ewaluacje, a brzmi to poważniej, niż wygląda w praktyce. Zaczynasz od zestawu realnych, dobrych odpowiedzi, przygotowanych wcześniej przez ludzi. Nawet kilkadziesiąt przykładów wystarczy na start, choć im więcej, tym pewniejszy pomiar. Ten zestaw jest twoim punktem odniesienia. Potem definiujesz, co znaczy „dobrze”, tak samo jak zrobiłby to człowiek sprawdzający tę pracę, i przepuszczasz agenta przez cały zestaw, licząc, ile razy trafił.
Gdy odpowiedź da się ocenić obiektywnie, ocenia ją kod. Gdy ocena wymaga zrozumienia treści, sędzią zostaje inny model. Potem zmieniasz jedną rzecz: polecenie, ustawienie narzędzia albo sam model, i uruchamiasz ten sam pomiar jeszcze raz. Zdarza się, i to często, że zmiana wyglądająca na oczywistą poprawę obniża wynik. To najcenniejszy moment całego ćwiczenia, bo dowiadujesz się tego u siebie, a nie przy kliencie. Budowanie takiego pomiaru od zera przechodzę krok po kroku w przewodniku jak ocenić, czy agent AI działa.
Rozwiąż realne ograniczenie biznesu
Wyobraź sobie firmę jako rurę. Z jednej strony wpływa woda: ruch, zapytania, uwaga ludzi. Z drugiej wypływa zysk, czyli to, co firma naprawdę u siebie zostawia. Zepsuć się mogą dwie rzeczy. Albo w środku jest zator i wszystko za nim się cofa, albo w rurze jest przeciek i pieniądze uciekają bokiem, nie docierając do końca.
Twoje zadanie to znaleźć jedno i drugie. Jest przy tym prawidłowość, która zmienia sposób pracy: to, o co prosi zamawiający, czyli twój klient albo twój przełożony, prawie nigdy nie jest prawdziwym ograniczeniem. Przychodzi i mówi „potrzebuję czatbota” albo „chcę zautomatyzować akurat to”. Tak wygląda jego domysł co do lekarstwa, nie diagnoza. Wartość leży w znalezieniu zatoru albo przecieku, którego sam nie zauważył.
Zanim więc cokolwiek zbudujesz, nie bierz zamówienia dosłownie. Przejdź z nim proces krok po kroku i pytaj, gdzie robota staje i czeka oraz gdzie firma traci najwięcej czasu i pieniędzy. Wybór pierwszego procesu i kryteria, po których go oceniasz, pokazuję w przewodniku od czego zacząć z AI w mniejszej firmie.
Zmienia się wtedy również twoja pozycja w rozmowie. Przestajesz być kimś, kto przyjmuje zamówienie i je realizuje. Zostajesz kimś, kogo interesuje wynik firmy. To już inna rozmowa, także o pieniądzach.
Kiedy zator jest już nazwany, wciąż nie zaczynasz budować. Najpierw nazywasz jedną liczbę, którą projekt ma ruszyć, i robisz to, zanim ktokolwiek zacznie budować. Porównanie, które dobrze to pokazuje: kiedy firma wynajmuje agencję reklamową, umowa jest czytelna. Tyle firma wydaje na reklamę, tyle ma z tego wrócić. Każdy potrafi po fakcie ocenić, czy się opłaciło. Projekty z AI rzadko są tak ustawione, bo zwykle oszczędzają czas albo obniżają koszt, a to trudniej wpisać w jedną pozycję. To ty musisz zrobić z tego liczbę.
Robi się to przez stan wyjściowy, cel i termin. Weź całkiem hipotetyczny przykład: firma dostaje dziś pięć zapytań tygodniowo. Idziesz do niej z pytaniem, czy dojście z pięciu zapytań tygodniowo do piętnastu w ciągu dwóch miesięcy będzie dla niej sukcesem. Czy ruszy jej przychód albo marżę na tyle, żeby było warto. Jeśli wszyscy przy stole mówią „tak”, masz swoją jedną liczbę.
Ta jedna rozmowa zmienia projekt na wylot. Budowa dostaje linię mety. Osoba, która zamówiła, wie dokładnie, co dostała. A ty na końcu masz opis wdrożenia z prawdziwą liczbą w środku, nie zdanie „zautomatyzowaliśmy proces”. Zwrot z takiego wdrożenia da się policzyć na kartce jeszcze przed startem, co pokazuję w przewodniku o workflow, który sam się spłaca.
Spraw, żeby AI się opłacała
Ostatnia para decyduje o tym, czy praca z AI zarabia, czy zjada własny zysk. Najpierw rachunek. Modele rozliczają się w tokenach, czyli w kawałkach tekstu: każde słowo, które do modelu wchodzi, i każde, które z niego wychodzi, ma swoją cenę. Najczęstszy błąd polega na tym, że do każdego kroku podstawia się największy i najdroższy model, a potem nie wraca się już do tej decyzji.
Rozsądniej jest dobierać model do zadania. Przeczytanie kilkuset tysięcy słów artykułów i wyciągnięcie z nich akapitu streszczenia to czarna robota; tani i szybki model, taki jak Haiku, zrobi to za groszowe kwoty. Ostatni krok, w którym z tego streszczenia trzeba wyciągnąć wniosek dla konkretnej firmy i podjąć decyzję, to zupełnie inne zadanie i tu opłaca się sięgnąć wyżej.
Kiedy raz to zobaczysz, wbudujesz to w swoje układy na stałe. Każde zadanie idzie do najtańszego modelu, który dla tego właśnie zadania stale przechodzi pomiar z poprzedniej lekcji. Drogie modele wchodzą tylko tam, gdzie naprawdę są potrzebne. Jakość wyniku zostaje ta sama, a rachunek potrafi spaść wielokrotnie. Znaczenie tej lekcji będzie rosło, bo modele uruchamiane na własnym sprzęcie są coraz lepsze i coraz mniejsze, a przy części z nich nie płacisz za każde zapytanie. Sam podział pracy między taniego wykonawcę i drogiego doradcę rozkładam w tekście o dobieraniu modelu AI do zadania.
Ostatnia lekcja dotyczy kolejności, w jakiej dostaje się rolę. Scenariusz jest ten sam dla prawie wszystkich: zrób dyplom, dostań tytuł, a wtedy wolno ci robić robotę. Przy AI ten scenariusz idzie od końca.
Ludzie, którzy wchodzą dziś do roli przy AI albo awansują na nią, robili tę pracę, jeszcze zanim rola powstała. I sama praca była tylko połową sprawy. Druga połowa to moment, w którym współpracownicy i przełożeni zaczęli ich widzieć jako osobę od AI. Nie chodziło o to, że trenowali modele po nocach. Na tle całego biura byli po prostu jedynymi, którzy próbowali, śledzili nowości i wnosili do firmy konkretne projekty.
Dowód idzie więc pierwszy. Weź jedno powtarzalne zadanie ze swojej pracy, to, którego nie znosisz w każdy czwartek, i zbuduj do niego automatyzację. Potem pokaż ją zespołowi i przełożonemu razem z tym, co zmieniła w twoim tygodniu. Po kilku takich rzeczach firma zaczyna budować stanowisko wokół pracy, którą już wykonujesz. A jeśli szukasz pierwszego klienta, zbuduj najpierw coś dla siebie, żeby wejść w rozmowę z dowodem, nie z obietnicą. Całą tę drogę, od pierwszego drobnego zadania do własnej roli, opisałam osobno: zacznij od własnego biurka.
Wszystkie dwanaście lekcji schodzi się w jednym miejscu. Model masz taki sam jak wszyscy inni. Twoja jest tylko warstwa, którą do niego dokładasz: wiedza, ograniczenia i sposób prowadzenia pracy. No i to, czy potrafisz pokazać, co z tego wyszło. Reszta to narzędzia, a te i tak się zmienią.
Na dziś jeden ruch: wybierz jedno powtarzalne zadanie ze swojego tygodnia i zapisz, ile zajmuje ci teraz. Zanim cokolwiek zbudujesz, masz już pierwszą połowę dowodu.