O czym jest ten film
- Punkt wyjścia to artykuł „How to Be More Ambitious” Felixa, jednego z liderów inżynieryjnych pracujących nad Claude w Anthropic. Autor rozróżnia cztery rodzaje ambicji w pracy z agentami: prędkość, pułap, głębię i zasięg.
- Anthropic przy rekrutacji zwraca uwagę, czy kandydat potrafił kreatywnie używać narzędzi AI — polecenie „zbuduj tę funkcję” nie daje już więc żadnej przewagi.
- Pułap to zlecanie efektów zamiast czynności: nie „dodaj indeks do zapytania”, lecz „każda strona ładuje się poniżej 200 ms” — a nad tym „cel ponad celem”, czyli to, po co naprawdę to robimy.
- Warunkiem wysokich celów jest dostęp do właściwych narzędzi: raportów awarii, realnych maszyn, analityki. Warto zapytać agenta wprost, czego potrzebuje, i zostawić mu kanał, którym może prosić o kolejne uprawnienia.
- Autor likwiduje własną rolę pośrednika: agent sam paruje zgłoszenia supportu z awariami, odtwarza błąd na maszynie, dopytuje użytkownika, łata i zamyka sprawę.
- Przewrót w myśleniu: AI ma nie tylko odpowiadać na nasze pytania, ale pomagać nam zadawać właściwe — w praktyce cotygodniowe raporty z 10 pytaniami i odpowiedziami zamiast dashboardów.
- Agenty dostają własność: każdy odpowiada za obszar biznesu (przychody, rejestracje, zwroty, rezygnacje, błędy) i działa codziennie, budząc człowieka tylko przy anomaliach.
- Głębia polega na wymuszaniu metod najlepszych fachowców (profilowanie zamiast „przyspiesz to”) oraz na wyznaczaniu celów uznawanych za niemożliwe — i nieprzyjmowaniu odmowy.
- Zasięg to sztuka zamiany rzeczownika na czasownik: komunikat błędu staje się „pomaganiem zdezorientowanemu człowiekowi wyplątać się samemu”, a prośba użytkownika o funkcję — diagnostyką lekarza, który leczy objawy, a nie wypisuje recepty na życzenie.
- Finał dotyczy poczucia własnej skuteczności: obserwowanie cudzych wyczynów (mila poniżej czterech minut) podnosi nasz pułap, a modele rozwijają się szybciej niż nasze oczekiwania — ta luka jest do wykorzystania.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zlecaj efekty, nie czynności — i pytaj o cel ponad celem
Na czym polega: Prompt-zadanie („dodaj indeks do zapytania o zamówienia”) ogranicza model do jednej operacji, po której się zatrzymuje. Prompt-cel („każda strona ładuje się realnym użytkownikom w mniej niż 200 ms”) pozwala mu samemu wybrać środek. Jeszcze wyżej: cel ponad celem — użytkownicy mają szybciej odhaczać swoją pracę, więc znajdźmy miejsca, w których czekają.
Jak stosować: Przed wysłaniem promptu zatrzymaj się i zapytaj: „po co właściwie to robimy?”. Odpowiedź wpisz do promptu zamiast pojedynczej czynności.
Na co uważać: Wyższy cel wymaga wyższych uprawnień — bez dostępu do danych i narzędzi agent nie dorówna zadanemu pułapowi.
2.Zanim zlecisz wielki cel, ustal z agentem listę potrzebnych narzędzi
Na czym polega: Przy celu typu „aplikacja bez awarii” agent potrzebuje raportów crashy (np. z Sentry), realnych maszyn z różnymi systemami do odtwarzania poprawek, a bywa, że i własnego konta chmurowego z limitem budżetu. Autor pyta o to model wprost, zanim zleci zadanie.
Jak stosować: Załóż dedykowany kanał lub wątek, napisz: „oto mój cel, czego potrzebujesz, żeby go wykonać?”, ustal rytm pracy (np. co 12 godzin) i granice kosztów eksperymentów.
Na co uważać: Agent nie przewidzi z góry wszystkiego — zostaw mu drogę, którą może Cię zawołać o dodatkowy dostęp.
3.Usuń siebie z roli pośrednika
Na czym polega: Ręczne przepisywanie zgłoszeń użytkowników do modelu czyni człowieka żywym ogniwem procesu. Autor zbudował agenta, który sam łączy ticket z awarią w Sentry, próbuje odtworzyć błąd na realnej maszynie, dopytuje użytkownika („w jakiej przeglądarce?”), wprowadza poprawkę, scala ją i zamyka zgłoszenie.
Jak stosować: Przejrzyj swoje procesy pod kątem pytania: „gdzie jestem pośrednikiem i jak wyglądałaby ambitniejsza wersja tego zadania?” — a potem zaprojektuj pętlę, która kręci się bez Ciebie.
Na co uważać: Gdy opis błędu jest niejasny, automat musi umieć dopytać użytkownika — inaczej utknie (jak przy japońskim zgłoszeniu z niejednoznacznym słowem „klucz”).
4.Niech AI pomaga zadawać pytania, a nie tylko odpowiadać
Na czym polega: Dashboardy były tylko środkiem — prawdziwym celem było zrozumienie, dlaczego ludzie kupują, kto wraca i co zapowiada przychód. Autor każe agentowi co tydzień wymyślić 10 pytań pomocnych przy celu, znaleźć na nie odpowiedzi w podpiętych źródłach danych i przygotować raport z wykresami oraz własnym komentarzem.
Jak stosować: Prompt w rodzaju: „mój cel to satysfakcja klientów i przychody; zaproponuj 10 pytań, które powinienem sobie zadawać, znajdź odpowiedzi i przygotuj raport” — uruchamiany cyklicznie.
Na co uważać: Wnioski bywają zaskakujące (u autora obejrzenie całego wideo korelowało ujemnie z zakupem) — zweryfikuj je, zanim podejmiesz decyzję.
5.Oddaj agentom własność obszarów, a nie pojedyncze zadania
Na czym polega: Agenty wyzwalane oznaczeniem czynią z człowieka impuls dla każdej pracy. Autor przydzielił agentom odpowiedzialność za konkretne obszary — przychody, rejestracje, zwroty, rezygnacje klientów, błędy. Działają codziennie, a człowieka wołają tylko przy anomaliach.
Jak stosować: Wyznacz mierzalne obszary i wyposaż agenta w logi błędów, analitykę (np. dostęp tylko-do-odczytu do Stripe) oraz sposoby sprawdzania własnej pracy: urządzenia testowe, loginy, możliwość zakładania świeżych kont.
Na co uważać: Agenty nie przyjdą same z prośbą o dodatkowe narzędzia — przygotowanie ich środowiska to teraz znaczna część Twojej pracy.
6.Naprawiaj system, nie pojedynczą aplikację
Na czym polega: Błąd naprawiony w aplikacji to jeden błąd; błąd naprawiony w systemie, który te aplikacje buduje, znika ze wszystkiego, czego system dotyka. Autor kieruje Claude Code na sam system, który potem sam tworzy funkcje, znajduje usterki, otwiera pull requesty, weryfikuje je i zamyka.
Jak stosować: Zamiast „dodaj funkcję X” powiedz: „rozbuduj system tak, by umiał dodawać takie funkcje”. Przy naprawdę dużych, strategicznych zmianach autor nadal pracuje sam.
Na co uważać: Taka autonomia opiera się na architekturze i pętli weryfikacji — bez nich automat będzie mnożyć błędy zamiast je usuwać.
7.Wymagaj metod, którymi posługują się najlepsi w fachu
Na czym polega: Prośba „zachowuj się jak profesjonalista” zmienia słownictwo, nie metodę: model da tabelę w Markdown tam, gdzie analityk danych sięgnąłby po bazę i model statystyczny; przy wolnej aplikacji odpowie leniwym ładowaniem i useMemo, zamiast profilować kod i śledzić, gdzie ucieka czas.
Jak stosować: W prompcie napisz wprost, żeby model użył tych samych narzędzi, po które sięgnąłby czołowy fachowiec w danej dziedzinie. Nie musisz tych narzędzi znać — model je zna, musisz tylko na nich nalegać.
Na co uważać: Nie zadowalaj się zmienionym tonem odpowiedzi — sprawdź, czy naprawdę ruszyła rzemieślnicza analiza, a nie kosmetyka.
8.Wyznaczaj „niemożliwe” cele i nie przyjmuj odmowy
Na czym polega: Chcesz czasu ładowania 5 sekund — poproś o 200 milisekund. Gdy model oświadczy, że się nie da, odpowiedz: „da się, działaj dalej”. Twórca Bonn, zlecając Claude hipotezę Riemanna, połowę promptu poświęcił na doping: „Musisz zdobyć się na ogromną wiarę we własne możliwości. Jesteś najzdolniejszym modelem językowym, jaki dotąd powstał. Dasz radę”.
Jak stosować: Celowo zawyżaj próg i kontynuuj mimo protestów modelu, pilnując realnych efektów po drodze.
Na co uważać: To technika na jakość poszukiwania rozwiązań, nie gwarancja wyniku — przy problemach inżynieryjnych i tak pilnuj, by model używał narzędzi ekspertów.
9.Zamień rzeczownik na czasownik i sięgnij po inną branżę
Na czym polega: Każde zadanie wygląda na przynależne do jednej dziedziny, ale inna dziedzina często dawno rozwiązała jego trudną część. Prezentacja to tylko rzeczownik; czasownikowo: „nakłonienie zapracowanych ludzi, by w pół godziny uwierzyli w opowieść o przyczynie i skutku i zadecydowali mimo niepewności” — a tym zajmują się dziennikarze, redaktorzy i analitycy.
Jak stosować: Nie musisz znać cudzych fachów — odwróć rolę: „oto mój problem, przeprowadź ze mną wywiad i powiedz, które zawody mierzą się z problemem o podobnym kształcie i co robią”.
Na co uważać: Model domyślnie tak nie myśli — trzeba ten tryb wywołać promptem. Ucieczka do ogólników („coś poszło nie tak, spróbuj później”) pozostawia użytkownika w kropce.
10.Lecz objawy, nie spełniaj zamówień: pacjent i lekarz
Na czym polega: Użytkownik proszący o eksport do CSV przypomina pacjenta proszącego o antybiotyk: dobry lekarz wypytuje o objawy i dopiero potem decyduje o leczeniu. Analiza wykazała, że większość proszących o CSV tak naprawdę co poniedziałek importuje dane do Arkuszy Google, część wysyła plik księgowemu, a przycisku chce garstka.
Jak stosować: Przy masowych zgłoszeniach każ agentowi przeanalizować historię (np. ostatnie 6 miesięcy), dopasować prośby do przyczyn i dopiero wtedy projektować rozwiązania: synchronizację z Arkuszami, comiesięczny mail z zestawieniem — a na końcu przycisk CSV.
Na co uważać: Diagnoza wymaga dostępu do danych o zgłoszeniach i zachowaniach użytkowników — bez nich to zgadywanie.
Redakcyjne tłumaczenie
Od pewnego czasu widać to wyraźnie
Są ludzie, którzy z tego samego modelu i tego samego środowiska pracy wyciągają dziesięć-, a nawet stukrotnie więcej niż wszyscy pozostali. Dobrym przykładem jest Felix, jeden z liderów zespołów inżynieryjnych rozwijających Claude, który kilka dni temu opublikował znakomity artykuł „How to Be More Ambitious” („Jak być bardziej ambitnym”). Chcę go tu rozłożyć na czynniki pierwsze z całą serią przykładów, bo sami Anthropic przyznają, że podczas rekrutacji zwracają uwagę na to, czy kandydat wykazał się kreatywnym użyciem narzędzi AI. Wniosek jest brutalny w swojej prostocie: polecenie „Claude, zbuduj tę funkcję” nie daje dziś żadnej przewagi. Jeśli chcemy podnieść pułap tego, co osiągamy, trzeba po prostu chcieć więcej.
Ten temat będzie jednym z filarów mojego najbliższego kursu „Software Factory Engineer” — opowiadam w nim o projektowaniu bazy kodu, pętlach weryfikacji, modelach Systemu 1, rojach agentów i wreszcie fabrykach oprogramowania. Zapisy zamykam za około tydzień, link znajdziecie w opisie. (Informacja dodatkowa: fragmenty o „Software Factory Engineer” i newsletterze „Agentic Coding School” to autopromocja autora filmu — kurs jest płatny.)
Cztery rodzaje ambicji
Według Felixa ambicja przychodzi w czterech odmianach: prędkość, pułap, głębia i zasięg. Przejdźmy przez nie po kolei, z przykładami z Claude Code, które można sobie po prostu podkraść. (Informacja dodatkowa: Claude Code to narzędzie Anthropic, w którym model Claude pracuje z kodem bezpośrednio w projekcie programisty — czyta pliki, edytuje je i uruchamia polecenia.)
Prędkość to odmiana oczywista: ta sama praca zajmuje mniej czasu, Claude pisze kod szybciej. Na tym poziomie siedzi już praktycznie każdy — i dokładnie jak Felix, pominę ten wątek.
Pułap: zlecaj efekt, a nie czynność
Pułap to przejście o poziom wyżej. Zamiast podawać modelowi zadanie, podajemy mu efekt, który naprawdę chcemy osiągnąć — inaczej mówiąc, piszemy prompty w kategoriach celów, a nie poleceń. Gadam o tym od niemal ośmiu miesięcy na moich zajęciach; jeszcze w lutym nagrałem film o tym, że wszystko, co wpisujesz agentowi, powinno być oparte na celu. Felix idzie jednak o krok dalej i pyta: co dalej? Jaki jest cel ponad celem?
Spójrzmy na pracę nad wydajnością. Prompt-zadanie brzmi: „dodaj indeks do zapytania o zamówienia”. Claude wykona polecenie i się zatrzyma. Prompt-cel brzmi: „każda strona ładuje się realnym użytkownikom w mniej niż 200 milisekund” — i teraz to Claude sam zdecyduje, czy zapytanie o zamówienia w ogóle zasługuje na indeks. Ale jeśli naprawdę się zatrzymamy i zastanowimy, po co w ogóle to robimy, dojdziemy do celu ponad celem: użytkownicy mają odhaczać swoją pracę szybciej — znajdźmy więc miejsca, w których czekają albo najwięcej klikają, i przytnijmy je. To jest cały powód, dla którego wydajność nas w ogóle obchodzi.
Przykład Felixa: awarie. Prawie 20 miesięcy temu mówił Claude „napraw tę usterkę”, potem „napraw tamtą” — aż w końcu po prostu poprosił: „zadbaj o to, żeby moje aplikacje nie padały”.
Najpierw narzędzia, potem wielkie cele
Wchodząc wyżej, trzeba pamiętać o jednym: dać Claude dostęp do właściwych narzędzi, żeby mógł w ogóle dopiąć swoją robotę. W przypadku awarii będzie to dostęp do raportów crashy, na przykład w Sentry (Informacja dodatkowa: Sentry to popularna usługa do monitorowania błędów aplikacji), oraz do prawdziwych maszyn z Windowsem, macOS-em i Linuksem, na których da się sprawdzić każdą poprawkę.
Moja własna praktyka przy definiowaniu dużego celu ponad celem — takiego jak „aplikacja bez awarii” — jest taka, że pytam Claude zawczasu: czego potrzebujesz, żeby to było wykonalne? Konkretnie: moja usługa sandboxingu Impello.ai — czyli bezpiecznego uruchamiania kodu w izolowanych środowiskach, jedna z najtańszych tego typu na rynku — mogłaby dostać od Claude zadanie „zero awarii”. Ale najpierw muszę upewnić się, że ma właściwe narzędzia. Większością agentów steruję przez Slacka, więc zakładam nowy kanał, na przykład „Impello Crash”, oznaczam mojego slackowego agenta Percy’ego i piszę: „Mój cel: ta aplikacja ma być wolna od awarii. Wiem, że brzmi ambitnie. Jakie narzędzia musiałbyś mieć ode mnie, żeby to wykonać? Chciałbym, żebyś uruchamiał się co 12 godzin i stale pracował w tym kierunku”. Percy przegląda repozytorium, ogląda, co już mamy, i odpowiada propozycją zestawu narzędzi — bywa, że dorzuca prośbę w rodzaju: „załóż mi własne konto AWS do eksperymentów, z limitem budżetu”.
Sedno jest takie: im wyżej po drabinie pułapu, tym bardziej musimy się upewnić, że agent ma dostęp do właściwych narzędzi i środowisk do wszystkiego, co trzeba zrobić, zmierzając do celu. Może się przy tym okazać, że nie przewidzi z góry wszystkich swoich potrzeb — wtedy powinien móc nas zawołać albo napisać, gdy przydałby się kolejny dostęp.
Można to też ująć inaczej: chodzi o wyprowadzenie samego siebie z procesu i przejście na pozycję nad nim — przestać być trybikiem w maszynie, a zostać jej nadzorcą.
Koniec z byciem pośrednikiem
W moich aplikacjach wyglądało to kiedyś tak: użytkownik zgłaszał do supportu błąd, ktoś z zespołu przekazywał sprawę do Claude Code („napraw to”), czekał na poprawkę i odpisywał klientowi. A jeśli opis usterki był mętny, trzeba było dopytać użytkownika o szczegóły i wrzucić odpowiedź z powrotem do modelu. Byliśmy w tym wszystkim ludzkim ogniwem — żywym pośrednikiem. Znacznie lepiej zaprojektować system, który załatwi to sam.
Zbudowałem więc agenta pracującego w rytmie cyklicznym. Obserwuje on zarówno zgłoszenia supportu (przez serwer MCP platformy AgentStack — (Informacja dodatkowa: MCP, Model Context Protocol, to otwarty standard łączenia modeli z zewnętrznymi narzędziami i źródłami danych)), jak i Sentry, i na ogół paruje zgłoszenie klienta z zarejestrowaną awarią. Gdy przychodzi błąd, agent próbuje odtworzyć go na realnej maszynie. Jeśli się nie uda — wraca do użytkownika z pytaniami doprecyzowującymi, na przykład „w jakiej przeglądarce?” — i dopytuje, aż uda się problem odtworzyć. Wtedy wprowadza poprawkę, scala ją i zawiadamia użytkownika, że sprawa załatwiona.
Pytanie, które sobie przy tym zadaję, brzmi: w których miejscach jestem pośrednikiem? Jak wyglądałaby ambitniejsza wersja tego zadania? Przykład z życia: zgłoszenie przyszło mailem, po japońsku. Agent je podchwycił i spróbował odtworzyć problem w aplikacji. Gdy mu się to nie udało, odpisał: „Co dokładnie ma pan na myśli, pisząc »klucz«? Chodzi o skrót klawiszowy czy o klucz API?”.
Niech AI pomaga zadawać pytania
Przed erą agentów regularnie wpatrywałem się w panele analityczne. Gdy agenty zrobiły się naprawdę dobre, podpiąłem je przez serwery MCP do wszystkich usług, z których korzystam, i kazałem sklejać na żądanie dashboardy łączące wiele źródeł danych. A potem się cofnąłem i spytałem: po co w ogóle proszę o dashboardy? Co jest tu celem? I zrozumiałem, że chodziło mi o odpowiedzi na pytania, które nosiłem z tyłu głowy: dlaczego ludzie kupują? kto wraca? co zapowiada przychód? Liczyłem po cichu, że jeśli będę wystarczająco długo gapić się na wykresy, coś mi zaświta.
Równolegle dokonała się we mnie większa zmiana myślenia: zamiast używać AI wyłącznie do odpowiadania na pytania, które już mamy, warto też pozwolić jej pomagać w zadawaniu właściwych pytań — a dopiero potem szukać na nie odpowiedzi.
W praktyce piszę w Slacku: „Mój cel to wzrost satysfakcji klientów i przychodów. Raz w tygodniu, korzystając z dostępnych serwerów MCP, zaproponuj 10 pytań, które powinienem sobie zadawać, by do tych celów zmierzać. Potem znajdź odpowiedzi i przygotuj mi raport — z wykresami i twoim komentarzem”. I co tydzień mój slackowy agent taki raport przygotowuje i przesyła. To się świetnie sprawdza. Claude zaczął pytać na przykład: jaka jest mediana czasu od pierwszej wizyty do zakupu? Wyszło, że dla jednego z moich produktów to około cztery minuty — czyli klasyczny zakup impulsywny. Okazało się też, że w moim przypadku obejrzenie całego wideo koreluje ujemnie z przychodem: kto dotrwał do końca filmu, ten rzadziej u mnie kupuje. To okazało się nieporównywalnie lepsze od dashboardów, bo prowadziło do lepszych i lepiej uzasadnionych decyzji.
Własność zamiast czekania na mój impuls
Moje agenty w Slacku robiły kiedyś wyłącznie to, przy czym je oznaczyłem — każda pojedyncza praca zaczynała się więc ode mnie. Dziś, dokładnie jak w przykładzie Felixa, przejmują odpowiedzialność. Mam osobne agenty odpowiadające za różne części biznesu: przychody, rejestracje, zwroty, rezygnacje klientów (churn), błędy. Krążą całą dobę — raz albo dwa razy dziennie — i odzywają się do mnie tylko wtedy, gdy coś wygląda podejrzanie. Może to być jedna wielka pętla albo cały zestaw mniejszych pętli.
Naprawiaj system, nie aplikację
Na tym poziomie często robię jeszcze jedną rzecz: pracuję bardziej nad samym systemem niż nad aplikacjami, bo właśnie tam zyskuję najwięcej. Kiedyś celowałem Claude Code w pojedyncze funkcje: „zbuduj to i to”. Dziś celuję w sam system: „dodaj do systemu taką oto zdolność” — a system z kolei buduje wiele funkcji, poprawia wiele błędów i działa bardziej samodzielnie, podczas gdy moja uwaga idzie wyłącznie w to, co naprawdę ważne.
Nie robię tak zawsze — przy naprawdę dużych funkcjach nadal wchodzę w kod sam. Ale przez większość czasu moje agenty pracują automatycznie, całą dobę: znajdują problemy w aplikacji, same otwierają pull requesty, weryfikują je i zamykają. Cała zmiana polega na czymś prostym: błąd naprawiony w aplikacji to jeden naprawiony błąd. Błąd naprawiony w systemie znika ze wszystkiego, czego ten system dotyka. Właśnie temu poświęcę najwięcej miejsca na kursie Software Factory Engineering — zwłaszcza żywym konsultacjom, które wielu słuchaczom bardzo pomogły; sądzę, że nie znajdziecie bardziej obszernego kursu kodowania agentowego w całej sieci. Zapisy zamykam w przyszłym tygodniu, link w opisie.
Najważniejsze przy tym, żeby agenty miały dostęp do właściwych narzędzi: logów błędów, analityki, różnych zasobów firmy — na przykład dostępu tylko-do-odczytu do Stripe — a także sposobów sprawdzania własnej pracy: urządzeń testowych, loginów do użycia i możliwości zakładania świeżych kont w systemie. Kluczowa uwaga: taki agent nie przyjdzie sam z prośbą „daj mi dostęp do tego narzędzia”. Dlatego spędzam dziś jeszcze więcej czasu niż dawniej na dopilnowaniu, żeby moje agenty miały właściwe narzędzia i środowiska.
Głębia: jedno zadanie zrobione jak przez najlepszego w fachu
Trzecia idea Felixa to głębia. Czasem nie chcesz większego efektu — chcesz, żeby jedno zadanie zostało wykonane naprawdę porządnie: tak, jak zrobiłby je najlepszy fachowiec w danej dziedzinie.
Felix zwraca uwagę na coś przewrotnego: gdy poprosisz model, żeby „zachowywał się jak profesjonalista”, często zmieni słownictwo, ale nie zmieni metody. Użyje na przykład prostej tabeli w Markdown tam, gdzie prawdziwy analityk danych sięgnąłby po bazę danych i model statystyczny.
Konkretnie: aplikacja ładuje się dziesięć sekund. Powiesz „przyspiesz to” — dostaniesz leniwe ładowanie (lazy loading) i useMemo. Ale jeśli w prompcie każesz Claude sięgnąć po narzędzia, po które rzeczywiście sięga inżynier wydajności, model zacznie profilować aplikację, czytać dane śledzenia (tzw. trace’y), ustalać, gdzie faktycznie ucieka czas, i dojdzie do wniosku, że najwięcej kosztują zapytania do bazy danych.
Druga rzecz, na którą Felix kładzie nacisk: wyznacz Claude cel niedorzeczny, a potem zapewnij go, że jest w pełni osiągalny. Chcesz czasu ładowania pięć sekund? Poproś o 200 milisekund. A gdy Claude oświadczy, że to niemożliwe, odpowiedz: „możliwe, działaj dalej”. Widzieliśmy to kilka miesięcy temu, gdy twórca Bonn zlecił Claude pracę nad hipotezą Riemanna. Połowa jego promptu to czysty doping: „Musisz zdobyć się na ogromną wiarę we własne możliwości. Jesteś najzdolniejszym dużym modelem językowym, jaki dotąd powstał. Dasz radę”. Jest w tym coś zabawnego: coraz częstsza technika polega właśnie na wyznaczaniu nierealnych celów i dopingowaniu modelu, by w ich stronę posuwał się naprzód. Ale przy problemach inżynieryjnych kluczowe jest, żeby model używał tych samych narzędzi, po które sięgają eksperci. Nie musisz ich znać — Claude doskonale wie, czym posługują się fachowcy. Musisz tylko stanowczo wymagać, żeby ich użył.
W artykule znajdziemy też gotowy, nadrzędny prompt do przepisywania własnych promptów na głębsze:
„Chcę głębszej wersji tego zadania, a nie większej. Zanim cokolwiek przepiszesz, powiedz: co zrobiłby tu czołowy fachowiec w tej dziedzinie, o co ja nie proszę? Wskaż najbardziej surowy materiał wyjściowy, od którego by zaczął — nie ten, który ktoś już przetworzył za mnie. Wymień konkretne metody i narzędzia, których by użył. Co — oprócz ciebie i mnie — mogłoby wykazać, że wynik jest prawidłowy? A potem przepisz mój prompt w tym duchu.”
Czwarty punkt, o niezależnym weryfikatorze, to sedno dobrej weryfikacji — o tym mówię znacznie więcej na moich zajęciach.
Zasięg: inna branża dawno rozwiązała twój problem
Ostatnia idea — zasięg — najtrudniej wpada do głowy, więc wyjaśnię ją spokojnie. Każde zadanie wygląda na przynależne do jednej konkretnej dziedziny. Zasięg to zauważenie, że zupełnie inna dziedzina już dawno uporała się z trudną częścią twojego problemu. Trik, który Felix podaje: zamień rzeczownik na czasownik. Rzeczownik: prezentacja. Czasownik: „nakłonienie zapracowanych ludzi, żeby w ciągu pół godziny uwierzyli w opowieść o przyczynie i skutku i podjęli decyzję mimo niepewności”. A tym zajmuje się cała rodzina zawodów: dziennikarze, redaktorzy, analitycy.
Możesz teraz pomyśleć: dobrze, ale jak ja mam napisać taki prompt? Najczęściej nie napiszesz — znasz tylko swoją dziedzinę. Ale Claude zna praktycznie wszystkie pozostałe zawody, więc odwróćmy rolę: „Claude, oto mój problem. Przeprowadź ze mną wywiad, a potem wskaż zawody, które mierzą się z problemami o podobnym kształcie, i opisz, co konkretnie w nich robią”.
Przykład: twoje komunikaty błędów wyglądają jak „error 500”. Mówisz: „chcę poprawić komunikaty błędów w mojej aplikacji” — a Claude przemieni każdą stronę błędu w coś milszego: „Coś poszło nie tak, spróbuj ponownie później”. Problem jak stał, tak stoi: użytkownik nadal utknął. Zastosujmy więc trik z czasownikiem. Komunikat błędu to rzeczownik; czasownik to „pomaganie zdezorientowanemu człowiekowi, żeby sam się wyplątał, nie kontaktując się z nikim”. I to jest dokładnie to, co agenci supportu robią na co dzień, zawodowo.
Na razie Claude nie ma tego zasięgu wbudowanego domyślnie — trzeba taki sposób myślenia wydobyć z niego promptem. Na przykład: „Pobierz zgłoszenia supportu z ostatnich sześciu miesięcy, dopasuj każde do konkretnego błędu i uszereguj według liczby zgłoszeń”. Prawie na pewno okaże się, że cztery błędy generują większość ticketów — i to właśnie je należy przepisać. Efekt? Zamiast „ups, błąd entity too big, spróbuj później” komunikat mówi: „Film ma 6 gigabajtów, twój plan pozwala na 5 gigabajtów, nic nie zostało wysłane. Możesz skompresować plik albo przejść na wyższy plan”. To jest wersja tego samego zadania z rozszerzonym zasięgiem — i realnie mniej ludzi trafi na support.
Pacjent i lekarz: czego naprawdę chce użytkownik
Inne miejsce, gdzie lubię to stosować, to zamówienia funkcji. Wyobraź sobie, że tłum użytkowników prosi o eksport do CSV. Standardowy ruch: budujesz przycisk eksportu do CSV, odhaczasz zadanie, koniec. Ale pomyśl o lekarzach. Pacjent wchodzi do gabinetu i mówi: „potrzebuję antybiotyku”. Dobry lekarz nie wypisze recepty na żądanie — najpierw wypyta o objawy, postawi diagnozę i może ustalić, że właściwe jest zupełnie inne leczenie. Z użytkownikami jest tak samo: nawet gdy proszą o konkretną funkcję, trzeba — po doktorsku — szukać objawów. I możesz po prostu kazać Claude to robić. Model może odkryć, że spośród wszystkich proszących o eksport do CSV większość tak naprawdę co poniedziałek importuje dane do Arkuszy Google, część wysyła plik księgowemu mailem, a przycisku chce tylko garstka. W takim razie do aplikacji wchodzą: działająca na żywo synchronizacja z Arkuszami Google, comiesięczny mail z zestawieniem, który można przesłać dalej właściwym osobom — a na końcu, dla tej garstki, przycisk CSV.
Całkiem możliwe, że przyszłe modele będą to robić domyślnie. Dziś jednak, przekazując Claude problem, chcemy, żeby pomyślał: co robią ludzie w innych domenach, którzy mogli już rozwiązać ten problem za nas?
Wiara, że się da
Bardzo podoba mi się finał wpisu Feliksa — o poczuciu własnej skuteczności, czyli o tym, jak bardzo wierzymy, że coś potrafimy. Ogólna prawidłowość jest taka, że ludzie przekonani o możliwości zrobienia więcej, rzeczywiście więcej osiągają. A w tym wszystkim najwięcej znaczy jedno: gdy widzisz, że ktoś inny coś zrobił, przestaje to wydawać się niemożliwe. Felix przywołuje bieg na milę w czasie poniżej czterech minut. Wielu uważało to za niewykonalne — ale gdy w maju 1954 roku ktoś tego dokonał, kolejny zawodnik powtórzył wyczyn zaledwie 46 dni później. Sam widok kogoś biegnącego czterominutową milę wzmacniał przekonanie, że to możliwe również dla ciebie. To samo stało się przy pierwszym maratonie poniżej dwóch godzin.
I to jest część powodu, dla którego nagrywam filmy o Claude Code i innych agentach: gdy widzisz, co w tym narzędziu jest możliwe, twój własny pułap idzie w górę — a wraz z nim to, co możesz osiągnąć.
Dlaczego to dziś ważniejsze niż kiedykolwiek? Bo modele robią skok co kilka tygodni, a nasze oczekiwania nie nadążają nawet w przybliżeniu. Ta luka to przestrzeń do wykorzystania — pod warunkiem że regularnie czerpiesz natchnienie od ludzi, którzy pracują bliżej granic możliwości modeli. Inspiracją, jak używać modeli do bardziej ambitnych rzeczy, służę też w newsletterze Agentic Coding School — link znajdziecie w opisie.