O czym jest ten film
- Czym dokładnie jest forward deployed engineer (FDE) i dlaczego to obecnie najgorętsza rola w technologii.
- Dlaczego inteligencja modeli się utowarowiła i przewaga przeniosła się z „kto ma model” na „jak i gdzie go wdrażasz”.
- Skąd wziął się ten termin — rola Palantira i porównanie FDE do konsultingu w wersji software’owej.
- Trzy etapy pracy FDE: zrozumienie realiów biznesu, decyzja gdzie inteligencja pasuje, i budowa oraz wdrożenie systemu.
- Dlaczego udokumentowany proces prawie nigdy nie odpowiada rzeczywistemu i po co FDE siedzi z ludźmi na miejscu.
- Ile można na tym zarobić — od ok. 150 tys. dolarów bazy z opcjami po nawet milion dolarów rocznie.
- Dlaczego FDE to rzadkie połączenie silnego inżyniera i dobrego komunikatora („sztuka i nauka w jednej osobie”).
- Jak podejść do klienta: audyt jako punkt wejścia, budowa na istniejących systemach zamiast wymuszania migracji, i de-ryzykowanie oferty.
- Rola evaluacji (evals) i człowieka w pętli przy zadaniach niedeterministycznych.
- Konkretny 30-dniowy plan wejścia w rolę FDE od zera — tydzień po tygodniu.
Redakcyjne tłumaczenie
Wprowadzenie
Greg: Wiem, że brzmi to szalenie, ale są ludzie zarabiający milion dolarów rocznie jako forward deployed engineers. Tylko czym właściwie jest FDE? Pewnie natknąłeś się już na ten termin, ale mam wrażenie, że dla wielu osób wciąż nie jest jasne, co to takiego i jak samemu nim zostać. W tym odcinku zaprosiłem mojego znajomego Vossa. Voss to jeden z czołowych ekspertów od FDE, ze swoją firmą Veric Agents. Przedstawi tu cały swój playbook — jak zostać FDE w 30 dni. Ten odcinek jest dla osób, które chcą zostać FDE, ale też dla tych, które po prostu chcą zrozumieć, o co chodzi i jak wykorzystać FDE we własnym biznesie, żeby zarabiać więcej i działać wydajniej. Uważam, że to najjaśniejszy materiał na ten temat w sieci. Miłego oglądania.
(Informacja dodatkowa: „forward deployed engineer”, czyli dosłownie „inżynier wysunięty do przodu / wdrożony u klienta”, to termin spopularyzowany przez firmę Palantir na określenie inżyniera pracującego bezpośrednio po stronie klienta.)
Greg: Voss jest z nami. Czego ludzie nauczą się do końca tego odcinka?
Voss: Nauczą się dokładnie, jak wejść w forward deployed engineering albo jak stać się lepszym FDE w 30 dni. Cała mapa drogowa dla AI forward deployed engineeringu.
Greg: Mam wrażenie, że nikt tego jeszcze nigdzie porządnie nie wyłożył. Termin „forward deployed engineer” jest wszędzie na moim feedzie na X, ale nikt go tak naprawdę nie tłumaczy. Liczę na to, że jasno wyjaśnisz, co to znaczy, i rozłożysz wszystkie pojęcia na czynniki pierwsze — tak, żebym ja mógł się z tego nauczyć, ale żeby inni też mogli.
Voss: Jasne. Krąży wiele definicji, każdy ma własną. Dam ci tę, którą uważam za najjaśniejszą.
Inteligencję da się dziś po prostu kupić
Voss: Zacznijmy od tego, jak wygląda dzisiejsza rzeczywistość. Każda firma może dziś kupić inteligencję. Model frontier wychodzi praktycznie codziennie — wczoraj Kimi 3, w zeszłym tygodniu Fable 5 czy GPT-5.6 Soul. Inteligencja się utowarawia: ta sama fundamentalna zdolność jest dostępna dla każdego, kto może za nią zapłacić, a to dziś większość firm.
Skoro każdy ma do niej dostęp, inteligencja nie może już być fosą obronną. Istniała ta wielka teoria, że ludzie zostaną „wycenowani” z dostępu do inteligencji. Może kiedyś tak będzie, ale dziś wszyscy korzystają z tych samych narzędzi. Idź porozmawiać z 50 klientami korporacyjnymi — wszyscy używają tego samego stacku: Claude, Codex, Cursor dla niezależności od modelu, GitHub Copilot. To wszystko to samo.
Gdzie więc przenosi się przewaga? Do wdrożenia. Przewaga to już nie jest to, kto ma inteligencję, tylko gdzie, jak i po co jej używa. I to jest właśnie rola AI forward deployed engineera. Chodzi o to, by firma wykorzystała inteligencję AI najlepiej we własnym, specyficznym kontekście. Każda firma jest inna — inna struktura, inne procesy, inny sposób działania. Zadanie FDE polega na tym, by ogólną inteligencję zastosować konkretnie w tej firmie w sposób, który przyniesie jej najwięcej korzyści. Przewaga zacznie należeć do tego, kto ma najlepszy most między własnymi procesami a dostępnym stackiem inteligencji.
Skąd wziął się ten termin — lekcja Palantira
Greg: Ten termin — popraw mnie, jeśli się mylę — spopularyzował zespół Palantira, prawda? Dla wielu ludzi Palantir to czarna skrzynka. Możesz opowiedzieć trochę więcej?
Voss: Tak. Zabawne, bo mieszkałem parę lat w Nowym Jorku i miałem sporo znajomych, którzy byli forward deployed engineerami w Palantirze, więc mam trochę wglądu. Bez zdradzania tego, co uważam za tajemnicę firmy — Palantir ma ontologię, czyli stack software’owy, na którym pracuje, pełen konektorów do różnych systemów i łączy danych, które pozwalają przedsiębiorstwom wpompować swoje dane do jednego, ujednoliconego interfejsu. FDE Palantira są następnie wdrażani na miejscu — u klientów korporacyjnych albo w wojsku czy administracji — uczą się ich przepływów pracy, a potem stawiają workflowy, dashboardy i agentów, którzy rozwiązują problem danej firmy.
Palantir spopularyzował właściwie ideę, która była konsultingiem, ale dla świata software’u — ukuli termin „forward deployment engineer”. Piękno ich platformy nie polegało na tym, jak bardzo była zaawansowana technicznie, tylko jak bardzo była konfigurowalna. Inżynierowie szli na miejsce, dostosowywali ją pod konkretnego klienta i to rozwiązywało jego bolączki znacznie lepiej niż ogólny, uniwersalny produkt.
Greg: Teza jest więc taka, że skoro to działa dla Palantira, może zadziałać dla wszystkich?
Voss: Mniej więcej tak. Palantir rozwiązał to w erze danych, gdy chodziło o ujednolicenie źródeł i unikalną wizualizację. Uważam, że era AI będzie tego wymagać stukrotnie bardziej — każda firma będzie potrzebować dostosowanych agentów. To zresztą jest to, co rozwiązujemy naszym systemem operacyjnym. Wszyscy dochodzą do tego samego wniosku: forward deployed engineerowie to jeden z głównych powodów, dla których AI stanie się potężne dla biznesu.
Trzy etapy pracy FDE — etap pierwszy: zrozumieć realia biznesu
Voss: Ktoś musi zdecydować, gdzie inteligencja przynależy — nie tylko gdzie jest stosowana. Tym kimś też jest forward deployed engineer. Są trzy etapy zaangażowania FDE w firmie.
Pierwszy to zrozumienie realiów biznesu, czyli jak praca faktycznie się dziś odbywa. To jest ta część, którą ludzie głęboko zanurzeni w technologii często ignorują. W Dolinie Krzemowej panuje myślenie: „piękno jest w oprogramowaniu, nie ma znaczenia, jak wyglądają procesy biznesowe”. Ale mówię ci z pierwszej ręki — każdy biznes jest inny, nawet ten sam proces w różnych firmach. Weźmy rozliczenia z dostawcami albo sprzedaż w dwóch różnych firmach. Sposób ich realizacji będzie krańcowo różny. W jednej to proces dziesięciokrokowy, w drugiej trzydziestokrokowy. Jedna używa Salesforce, Gong i Chili Piper, druga HubSpota, Apollo i Clay. Są różnice w narzędziach, różnice w procesach i różnice w tym, co dla danego biznesu najważniejsze. Kiedy coś idzie nie tak — obsługa wyjątków — to też trzeba udokumentować.
Forward deployed engineerowie idą więc na miejsce, przeprowadzają wywiady, obserwują ludzi przy pracy albo dostają dostęp do systemów — ERP-ów, CRM-ów — żeby to wszystko rozgryźć. I tu, moim zdaniem, idzie większość czasu. Nie da się przecenić, jak to jest ważne — zarówno by zrozumieć biznes, jak i by wprowadzić go w tę zmianę. To tutaj kluczowa jest umiejętność komunikacji i analityczne myślenie. FDE to najlepsze połączenie kogoś bardzo technicznego, kto to rozumie, i kogoś z fantastyczną umiejętnością komunikacji oraz wyciągania z ludzi potrzebnych informacji.
Greg: Mówisz, że FDE idzie „na miejsce”. Dosłownie wchodzi do biura i zaczyna rozmawiać z ludźmi? Czy da się to zrobić zdalnie?
Voss: Da się to zrobić zdalnie, a czasem trzeba — bo firma jest zdalna albo ludzie z danego działu nie siedzą w jednym biurze. Ale powiem, że w zdecydowanej większości przypadków dzieje się to na miejscu. Palantir robi to bardzo intensywnie, my też. I nie chodzi o to, że nie da się zdobyć informacji zdalnie — chodzi o relację, którą budujesz z człowiekiem. Jesteś na miejscu, jesteś częścią zespołu, i tak odkryjesz znacznie więcej. Jeśli umówisz godzinne spotkanie, ktoś ci opowie, co jego zdaniem jest jego pracą. Ale jeśli siedzisz z nim przez pełne osiem czy dziesięć godzin, faktycznie doświadczasz tej pracy — widzisz, jak coś idzie nie tak, choć nigdzie nie ma tego w procedurze ani w dokumencie. Nawet konsultanci McKinseya idą na miejsce, do kopalni, siadają z górnikami i patrzą, jak pracują, bo to o wiele mocniejsze — zbudować relację i tak zdobyć informacje.
Etap drugi: osąd FDE — gdzie inteligencja pasuje, a gdzie nie
Voss: Drugi etap to osąd FDE: gdzie inteligencja przynależy, a gdzie nie. Kiedy fala AI dopiero ruszyła, widzieliśmy mnóstwo podejścia „wciśnijmy AI wszędzie, dajmy wszystko modelowi i niech sobie radzi”. To doprowadziło do „token maxingu” i halucynacji. Potem pojawił się ten statystyk MIT, że 95% pilotaży generatywnego AI kończy się porażką. Teraz branża zmienia bieg i uświadamia sobie, że trzeba być bardzo selektywnym co do tego, gdzie stosujemy inteligencję i jak projektujemy pod nią nowy stack.
(Informacja dodatkowa: „token maxing” to potoczne określenie strategii polegającej na maksymalnym rzucaniu wszystkiego na model językowy — w domyśle bez selekcji i bez projektowania procesu.)
Na przykład masz dziesięciokrokowy workflow — może się okazać, że w ogóle nie powinien być ruszany przez AI. Może jest zbyt ryzykowny, może ma za niski zwrot, może jest już mocno zautomatyzowany. Może z tych dziesięciu kroków tylko trzy naprawdę wymagają osądu — na przykład kategoryzacja leada w CRM jest trochę bardziej niedeterministyczna, więc tam wprowadzamy LLM. A resztę da się rozwiązać instrukcjami warunkowymi i wywołaniami API. Ten osąd jest w rzeczywistości znacznie bardziej złożony, niż to przedstawiam, ale należy do FDE. FDE ma i realia biznesowe — podejście w stylu konsultingu, komunikacji — i osąd techniczny, dzięki któremu potrafi ocenić: „ten projekt będzie ryzykowny, będziemy mieli 80% dokładności, nie warto”, kontra „ten inny workflow da znacznie wyższy zwrot, zbudujemy go szybciej, niższe ryzyko”. To ważenie racji między biznesem a technologią jest tym, w czym FDE naprawdę błyszczy.
Greg: Z ciekawości — gdyby ktoś słuchający tego chciał zostać forward deployed engineerem w Nowym Jorku i robić takie rzeczy, ile mógłby zarobić?
Voss: Dużo pieniędzy. Nie masz pojęcia, jak drogo się to zrobiło — i z perspektywy tego, ile my płacimy przy rekrutacji, i tego, czego żąda rynek. To najgorętsza rola w technologii teraz. Można zarobić od jakichś 150 tysięcy dolarów bazy ze sporym pakietem udziałów, aż po role, które widziałem sięgające miliona dolarów rocznie. I nie żartuję. To wyjątkowo dobrze wynagradzane role, jeśli jesteś najlepszym połączeniem konsultingu i technologii.
Etap trzeci: zbudować i wdrożyć system
Voss: Ostatni etap to faktyczne wyjście i zbudowanie samego oprogramowania. Tu jest ogromna różnica między firmami. W Palantirze są FDE, którzy nie piszą kodu — głównie stawiają workflowy, rozmawiając z oprogramowaniem ontologii Palantira, tworzą dashboardy, a o ile w ogóle piszą kod, to SQL. Ale są inne firmy, gdzie piszesz w pełni produkcyjny kod, na miejscu u klienta albo po powrocie. W niektórych rolach FDE trzeba pisać kod produkcyjny — potrzebujesz zaplecza inżynierii oprogramowania i pewności co do swoich umiejętności. W innych jest znacznie lżej technicznie i możesz budować „przez rozmowę”, na istniejącej platformie. Ale tak czy inaczej musisz bardzo dobrze rozumieć oprogramowanie, bo gdy klient zgłosi, że coś nie działa albo jest problem na produkcji, to twoja skóra jest na szali — musisz wiedzieć, do kogo zadzwonić, co zrobić i jak to naprawić.
Voss: Podsumowując: FDE są rozchwytywani, bo kontrolują, jak inteligencja wchodzi do biznesu i jak jest wykorzystywana — a to tu leży dziś cała wartość w erze AI. Do tego to rola nowa. Pięć lat temu nie było superinteligencji „z kranu”. Nie dość, że sama idea superinteligencji na żądanie jest absurdalna, a przez najbliższe lata zmienią właściciela biliony dolarów, to jeszcze ludzie uświadamiają sobie, że potrzebny jest człowiek z osądem, myślący systemowo, i że token maxing nie jest najlepszą strategią. Był moment, gdy zgadzano się, że token maxing to strategia — „te modele są tak dobre, po prostu pozwólmy im działać”.
Greg: Zabawny okres. Powiedziałbym, że wciąż nie do końca z niego wyszliśmy. Ale masz rację, to nowy, odważny świat dla wszystkich. Mam historie grozy o dyrektorach C-level, którzy przepalili cały budżet 10 milionów dolarów na modele w jakieś trzy miesiące. Miał wystarczyć na rok, ale dali go wszystkim, każdy odpalał, co chciał — token maxing — i smutna prawda jest taka, że biznesowi to niewiele dało. Bo firma nie zainwestowała porządnie w forward deployment.
Dwa strumienie osądu — dlaczego to tak rzadka rola
Voss: Chcę mocno podkreślić jeden punkt: wymagane są dwa strumienie osądu, a to bardzo rzadkie w jednej osobie. Niestety dzieje się — i już się zaczyna — to, że przeszliśmy od „wchodźmy w token maxing na całość” do „zatrudniajmy masę FDE”. Chcę jasno powiedzieć, czego ta rola naprawdę wymaga. Jest sporo FDE, którzy nie są ani najlepszymi komunikatorami, ani najlepszymi inżynierami. Zdecydowanie zachęcam ich do wzmacniania obu tych umiejętności.
Z jednej strony to rozumienie przepływów pracy, kosztów, zachęt, ryzyka, adopcji, wartości biznesowej i wewnętrznej polityki firmy — tu konsultanci są bardzo mocni. Porozmawiaj z engagement managerami z McKinseya, BCG czy Baina, będą w tym świetni. Z drugiej strony są modele, systemy, API, dane, niezawodność kodu, evale, guardraile, harnessy, post-training, fine-tuning — to bardziej techniczna strona, w której zwykle świetni są inżynierowie oprogramowania, ale muszą przesunąć się też ku stronie biznesowej. FDE to najlepsze połączenie obu — nie średnie, nie najgorsze, gdzie ani nie umiesz komunikować, ani kodować. To naprawdę najlepsze z obu światów, i to jest ten pracownik za milion dolarów, który potrafi zamienić rozumienie biznesu w działające oprogramowanie od początku do końca.
Greg: Inaczej mówiąc: jeśli rozumiesz sztukę i rozumiesz naukę, i potrafisz mówić obydwoma językami — masz to, czego trzeba, by zostać FDE za milion dolarów. Trudność w tym, że ludzie dobrzy w nauce są zwykle dobrzy tylko w nauce, a dobrzy w sztuce tylko w sztuce. Ale jest jakiś obszar nakładania się.
Voss: Dokładnie, i dlatego to tak rzadka rola. Ale głęboko wierzę — i o tym jest cała ta prezentacja — że możesz się tym stać. Można stać się znacznie lepszym w obu tych rzeczach. Potrzeba tylko, żeby to było czysto rozłożone. Potrzeba mapy drogowej — i to chcę dać do końca tej rozmowy.
Jak naprawdę odbywa się praca — udokumentowany proces to nie proces prawdziwy
Voss: Pierwsza rzecz: zrozum, jak praca naprawdę jest wykonywana. Udokumentowany proces bardzo rzadko jest procesem prawdziwym. Weźmy prosty przykład: „przychodzi e-mail”. Brzmi jak czysty sygnał wyzwalający, ale rzeczywistość jest znacznie bardziej skomplikowana. E-mail przychodzi od ponad 40 różnych nadawców, żaden nie jest sformatowany tak samo, dane są różne — coś w PDF, coś na zrzucie ekranu, coś w arkuszu Excela, coś zagrzebane w przekazanym wątku. Gdybyś nie był FDE i po prostu zapytał człowieka: „jaki jest pierwszy krok?”, odpowie: „przychodzi e-mail”. I nagle budujesz system, który nie odpowiada rzeczywistości.
A rzeczywistość jest tak złożona, że połowa przypadków to wyjątki. „To to samo co ostatnio”, „zignoruj drugi załącznik”, „Sarah już to zatwierdziła”. Nie ma spójnego tematu wiadomości, więc nie da się routować bez zajrzenia do środka. I zwykle wiedza o tym, jak to rozegrać, siedzi w głowie jednej osoby. Ktoś wie: „gdy widzę taki e-mail od tej osoby, przekazuję go temu dostawcy albo tej części działu zakupów”. Ale to nigdzie nie jest zapisane. Jeśli nie usiądziesz z tą osobą i tego z niej nie wyciągniesz, sama z siebie nawet o tym nie wspomni. Zapytajcie sami siebie: jak łatwo byłoby wam spisać każdy pojedynczy wyjątek, który może się w waszej pracy zdarzyć?
Byłem inżynierem oprogramowania w Meta i gdyby mnie ktoś zapytał o moją pracę, powiedziałbym: „no, koduję cały dzień, dostaję zadanie i nad nim pracuję”. Ale to nie jest rzeczywistość. Rzeczywistość to spotkania, coś się psuje na produkcji, muszę to naprawić. O to właśnie chodzi. I podobnie kolejny krok — „skopiowane do arkusza” — jeden przypadek jest realny, dwa to nieaktualne dane, przepisywane ręcznie, kolumny się rozjeżdżają. Każdy krok jest krańcowo skomplikowany. Na tym polega prawdziwe zrozumienie pracy — wymaga czasu i wysiłku, by usiąść z osobą odpowiedzialną, a często z wieloma osobami. Bardzo często jest to wiele osób — jeśli firma ma 5–10 tysięcy ludzi, prawdopodobnie sporo z nich pracuje nad tym samym.
Projektowanie: software deterministyczny, agent i człowiek w pętli
Voss: Następnie decydujesz, jak praca powinna działać, gdy wbudujesz w nią inteligencję. Gdzie żyje oprogramowanie deterministyczne? Gdzie działa agent? Gdzie zatwierdza człowiek? Gdzie aktualizowany jest rekord? Najlepsze rozwiązanie AI dla większości firm to bardzo dobra kombinacja oprogramowania deterministycznego — prawdopodobnie to większość — plus osąd, który dają wywołania API do LLM-a, i wreszcie człowiek w pętli.
Agenta wdrażamy w istniejące systemy. Robi on pierwszą połowę: przyjęcie danych, walidację, przygotowanie propozycji przez agenta, a potem człowiek w pętli zatwierdza. To coś, co mocno zalecam moim FDE, by forsowali przy wdrożeniach agentów. Gdy naciśniesz „zatwierdź”, agent przechodzi przez drugą połowę kroków — i to właśnie budujesz.
Praca FDE przy budowie ma trzy części. Audyt, potem tworzenie zestawów evaluacyjnych, które upewniają, że system zachowuje się poprawnie — to niezwykle ważne w erze AI — i wreszcie wdrożenie. Wdrożenie to zarówno prowadzenie klienta za rękę, by system adoptował i by działał, jak i strona software’owa: pilnowanie, żeby nic się nie psuło, monitorowanie wszystkich istotnych metryk, KPI, SLA. Wszystko musi być na najwyższym poziomie, żeby ktoś ci naprawdę zaufał jako FDE. Każdy etap jest warunkiem koniecznym następnego.
Greg: Przy evaluacji — w scenariuszu, gdzie wynik jest niedeterministyczny, czyli trudno powiedzieć, jak wygląda sukces — jak stworzyć eval dla zadania bardziej kreatywnego albo takiego, gdzie trudno ocenić, czy się udało?
Voss: Dla zadań niedeterministycznych jest znacznie trudniej. Łatwo powiedzieć, czy e-mail skategoryzowano poprawnie, bo mamy 10 tysięcy wcześniejszych e-maili jako podstawę zbioru. Ale nawet dla zadań niedeterministycznych — na przykład tworzenie prezentacji — jest milion sposobów, by to zrobić, i piękno jest w oku patrzącego: co dla mnie wygląda dobrze, tobie może się nie podobać. Tu bardzo pomaga mieć jak najwięcej wcześniejszych danych. Jeśli masz 5 tysięcy poprzednich prezentacji, znacznie łatwiej stworzyć „złoty zbiór” tego, co uważamy za istotne — logo zawsze w lewym górnym rogu, większa czcionka w takim stylu itd. Ale samymi evalami nigdy nie dojdziesz do idealnego wyniku. Potrzebujesz sprzężenia zwrotnego od człowieka w pętli, żeby mieć mechanizm, który stale ulepsza twój harness, a jeśli nie — post-trenuje albo fine-tunuje model. Z jednej strony: zbierz jak najwięcej danych i ustal, co wygląda dobrze, a co źle. Z drugiej: zawsze wbuduj feedback od człowieka, bo nawet z dobrym zbiorem i dobrymi evalami trzeba je stale poprawiać.
Który model wybrać — model-agnostycyzm kontra opanowanie jednego ekosystemu
Greg: Zauważyłem, że w całej tej rozmowie w ogóle nie mówiliśmy o tym, którego LLM-a używać. Jesteś w zasadzie agnostyczny co do Anthropica, OpenAI czy Google? Jak FDE powinien myśleć o wyborze modelu?
Voss: Świetne pytanie. Jako firma jesteśmy skrajnie model-agnostyczni. Uważamy, że nasza wartość leży w umiejętności przełączania się z jednego modelu na drugi tak, by dokładność tylko rosła, a koszt tylko spadał, i żeby nie wiązać się z jednym dostawcą inteligencji. Nie chcesz monopolizować swojej warstwy inferencji. Ale — gdybym dziś był FDE albo chciał zostać najlepszym FDE, trzymałbym się jednego modelu i jednej platformy do budowy agentów. OpenAI ma swoją, Claude ma swoją — agent SDK — każdy dostawca ma jakąś. Bądź bardzo, bardzo dobry w jednej z nich, bo to będzie fundament. Skoro jestem już dobry w platformie OpenAI, to jutro spróbuję Claude’a, potem Kimi 3 albo GLM 5.2, zobaczę, co potrafią modele open source, zbuduję własny harness. Ale na starcie nie martwiłbym się model-agnostycyzmem, bo nie tam leży twoja wartość. Twoja wartość to to, jak dobrze rozumiesz obie strony barykady — bo to przekłada się na dowolny model.
Greg: Zgadzam się. Dochodzimy do momentu, gdy modele są pod wieloma względami bardzo podobne. Duzi gracze mają model frontier i model open source. Wybierz ekosystem, w który wierzysz z jakiegoś powodu, bądź w nim najlepszy. A gdy już jesteś najlepszy i pracujesz z klientem, u którego z jakiegoś powodu inny model ma większy sens — świetnie, możesz go zarekomendować.
Voss: Dokładnie. I żeby domknąć: twoja zdolność do oceny, który model jest najlepszy do danego zadania, opiera się na rozumieniu różnych modeli — benchmarkujesz je po drodze. Ale nie stawiaj wozu przed koniem: naprawdę opanuj jeden, zanim wyruszysz na tę wyprawę.
Greg: Nie chcesz walić w konkretny model, nie rozumiejąc, jaki jest system i zestaw zadań. To jak kelner, który podaje ci kieliszek pinot noir, a ty mówisz: „nie prosiłem o to”. Dobra restauracja ma sommeliera, a jego zadaniem jest zrozumieć twoje podniebienie — czy lubisz wina wytrawne, z południowej czy północnej Francji. Nie jestem wielkim znawcą win, więc analogia może się posypać, ale idea rozumienia najpierw tego, czego ludzie chcą, a dopiero potem wdrażania — ma dużo sensu.
Voss: To było niezłe. Znajomość agentów jako FDE polega właśnie na tym: wchodzisz, ustalasz, czego chcą, i dopiero potem im to dajesz. Możesz wszystkim podać pinot noir — dla części zadziała, ale dla większości nie. I dlatego znowu większość pilotaży AI kończy się porażką.
Znajdź workflow wart przebudowy — i wejdź przez audyt
Voss: To znowu to samo: znajdź workflow wart przebudowy. Poproszę Grega, żeby podlinkował ten dokument na kanale, jeśli chcecie zejść głębiej. Idea jest ta sama: zbierz kontekst, prześledź ustalenia FDE, znajdź wąskie gardła, powtarzalną pracę, punkty wymagające osądu, a potem stwórz mapę operacyjną. Ta wymiana zdań między biznesem a techniką jest właśnie dlatego tak ważna.
Greg: À propos audytu — mieliśmy niedawno odcinek z Coreyem Ganimem, który mówił o sprzedawaniu audytów jako sposobie na poznanie czyjegoś biznesu, żeby potem wdrożyć AI. Możesz pobrać opłatę za audyt, a za wdrożenie brać miesięczny abonament albo jednorazową stawkę. Jak ludzie powinni o tym myśleć?
Voss: Jesteśmy dokładnie w tym biznesie — wdrażamy AI w największych firmach świata — i wymagamy, by każde zaangażowanie zaczynało się od audytu, który oczywiście kosztuje. To niezwykle wartościowe. Panuje nieporozumienie, że można po prostu „rzucić AI na firmę”. Audyt jest dla biznesu wart mnóstwo pieniędzy — mieliśmy firmy, które mówiły, że audyt był wart dziesięć razy tyle, ile zapłaciły. Jest lepszy niż McKinsey, bo tak wiele ujawnia. AI jest tak nowe, że nikt nie rozumie, jak przeprowadzić audyt. Ale jeśli potrafisz powiedzieć: „w waszym dziale oto wszystkie workflowy, rozrysowaliśmy je czysto — pełne kroki, wymiana zdań, obsługa wyjątków — i powiemy wam, co naszym zdaniem warto zautomatyzować, a czego nie”, i dasz im tę mapę priorytetów, tę macierz ROI, a potem pokażesz, jak byś to zbudował i jaki przypadek użycia jest wart pieniędzy — to jest dla firmy warte ogromnych pieniędzy. Większość firm konsultingowych nawet tego nie potrafi rozgryźć, i to tu masz przewagę, jeśli naprawdę żyjesz AI na bieżąco.
Greg: To też szansa, by zbudować z nimi zaufanie, pokazać, jak pracujesz, obiecywać mniej i dostarczać więcej. Pobudza to ich kreatywność — produkujesz mapę operacyjną, więc mówią: „nie pomyślałem o tym przypadku użycia, może warto w to zainwestować”.
Voss: Zabawne — gdy zaczynaliśmy firmę, to było w zeszłym roku, zanim FDE stało się modne, nazywaliśmy audyt „lekarstwem, którego żadna ze stron nie chce brać”. Firmy pytały: „muszę robić audyt? Nie możecie po prostu odpalić token maxingu i zacząć budować?”. Ale on jest tak wartościowy, że sami się o tym przekonują w trakcie.
Greg: My mamy też agencję LCA, znaną z pracy z największymi firmami świata — bierzemy ich produkty i przenosimy je w erę AI. Jak wyglądałby Dropbox „AI first”, jak Slack „AI first”? Zaczęliśmy robić audyty: „przeaudytujmy najpierw wasz produkt”. Zauważyliśmy, że słowo „audyt” było trudne do przełknięcia. Przebrandowaliśmy więc audyt na „sprint” — design sprint — a samą koncepcję audytu wnieśliśmy do środka. To działało lepiej. Taka mała wskazówka.
Voss: Bardzo pomocne. Z jakiegoś powodu ludzie mają alergiczną reakcję na słowo „audyt”.
Greg: Kojarzy im się z kontrolą skarbową.
Voss: Fair. „Audyt AI” faktycznie nie brzmi najlepiej.
Wdrożenie: buduj na tym, co już istnieje, i de-ryzykuj
Voss: Znów: oprogramowanie deterministyczne kontra agent kontra człowiek u sterów. Nie będę bił martwego konia. Musisz priorytetyzować workflowy o dużym wolumenie, gdzie poprawa jest na tyle znacząca, że ma znaczenie. To twoje zadanie jako FDE — ustalić to z pierwszej ręki.
Evaluacja zamienia niedeterminizm w dowód. Upewnij się, że masz właściwe dane, wymagane kroki, że wynik zgadza się z ekspertem i że można na nim bezpiecznie działać. Zbuduj macierz — tam, gdzie nie jest bezpiecznie, routujesz do człowieka. Tworzysz raport ewaluacyjny: masz 50 przebiegów, 41 zaliczyło. Z tych dziewięciu, które nie — sprawdźmy dlaczego. Pięć miało brakujące dane, cztery wyciągnęły zły rekord. Tego używasz, by ulepszyć system. Pomaga mieć drzewo decyzyjne, macierz — bo wszystko jest tak nowe, że można pójść w milion stron. To nasze podejście, na wysokim poziomie, a szczegóły zależą od przypadku.
Trzeci etap to wdrożenie. Bardzo mocno głosimy integrację z tym, co już istnieje. Wielu ludzi od AI wymusza migracje na nowe oprogramowanie. A masz przewagę, jeśli potrafisz budować na wierzchu ich systemów. Jeden z naszych klientów wydał parę lat i parę milionów dolarów na przejście na NetSuite — system ERP. Jeśli twoje rozwiązanie AI mówi: „musimy was z NetSuite zdjąć”, każą ci się wynosić. Ale jeśli mówisz — i to robimy — „zbudujemy na wierzchu NetSuite, uczynimy go znacznie lepszym, zintegrujemy z Salesforce, SAP, Concur, Expensify, Gong, Workday” — to jest znacznie potężniejszy system i tam leży cała wartość.
(Informacja dodatkowa: NetSuite, SAP, Concur, Workday itd. to popularne systemy klasy ERP / oprogramowanie korporacyjne do zarządzania finansami, wydatkami i zasobami.)
Potem testujesz w kontrolowanym środowisku i skalujesz — od wdrożenia, przez tryb obserwacyjny (shadow mode), rosnącą autonomię, aż po produkcję. To też twoja przewaga: nie wymuszasz gwałtownej zmiany, tylko przeprowadzasz ich przez tę drogę. I dlatego spotykasz się z nimi osobiście — łatwiej poprowadzić kogoś przez tę podróż, gdy poznaliście się twarzą w twarz, niż gdy jesteś facetem zza ekranu mówiącym: „teraz pstrykniemy przełącznik i AI poprowadzi wasz biznes”. To znacznie bardziej polaryzujące podejście.
Greg: Ma to sens. Zrobiłeś audyt, a jeśli potem pitchujesz: „pracowaliście na tym stacku 20 lat, a teraz nagle przejdźcie na to coś, będzie kosztować mnóstwo i jest pełno niewiadomych” — to trudny pitch. Chcesz pitchować coś, co jest jak łowienie ryb dynamitem: „macie ten system i stack, działa wam, ja go tylko ulepszę, pomogę wam być wydajniejszymi, szybciej docierać do klientów, zwiększyć przychody”. Wtedy to no-brainer.
Trzeba też pamiętać, że pitchujesz ludziom w firmie. A ludzie w firmie — powiem to, czego się nie mówi — nie chcą zostać zwolnieni. Chcą awansować. Więc twoim zadaniem jest pomóc im awansować. A nie pomożesz im awansem przez przejście z jednego ERP na inny, marginalnie lepszy. Pomożesz przez dostarczanie wartości efektywnie kosztowo. Gdy przychodzi ocena okresowa, pracownik czy dyrektor może wskazać: „pracowałem nad tym projektem — tak, z zewnętrzną agencją jak LCA czy Veric Agents albo z niezależnym FDE — ale to ja to zrobiłem”. Dopóki im w tym pomagasz, to właśnie im pomaga awansować.
Voss: Totalnie. I żeby to podkreślić: oni widzą cię jako ryzyko. Mogą siedzieć bezczynnie i utrzymać status quo — będzie w porządku. Ale jeśli sprowadzą FDE, który coś namiesza i może się nie uda, martwią się: „jeśli to padnie, źle to o mnie świadczy”. Zapomnij o migracji ERP — samo to, że w ogóle się angażujesz, jest dla nich ryzykiem. Musisz to jak najbardziej de-ryzykować. Mocno zalecam: zrób audyt za darmo, wsadź stopę w drzwi, udowodnij wartość, przygotuj plan, i bierz zapłatę dopiero, gdy naprawdę udowodnisz mierzalną wartość. To de-ryzykuje całość. Twoi pierwsi klienci nauczą cię tak wiele, że są naprawdę więcej warci dla ciebie niż ty dla nich. Ale po jednym, dwóch, trzech możesz zacząć pobierać opłaty, bo będziesz o lata świetlne przed resztą. Naprawdę wciąż jest bardzo wcześnie. Wiem to też z naszej firmy — jest ogromny popyt na ludzi, którzy naprawdę umieją to robić, a takich, szczerze mówiąc, jest niewielu. Zacznij, umocz stopy w wodzie i udowodnij, że wiesz, co robisz.
Greg: To też da ci pewność siebie, co jest ważne.
Voss: Tak. I będziesz wiedzieć, co jest dla nich ważne, gdy sprzedajesz — potrafisz trafiać w różne aspekty przemawiające do danej osoby na danym stanowisku.
Pętla: audyt → eval → wdrożenie, i od nowa
Voss: Gdybym miał wypalić jedną stronę w mózgu każdego, to tę: idziesz od audytu, przez eval, po wdrożenie. Po drodze budujesz, obserwujesz i ulepszasz — i pętla rusza od nowa. Bo gdy ulepszysz jeden system, następny staje się skrajnie oczywisty. Zawsze są powiązane wąskie gardła — jeden workflow zależy od czegoś powyżej i uwalnia coś poniżej. Dlatego AI jest w organizacji tak wszechobecne: gdy masz je w jednym miejscu, będziesz go potrzebować wszędzie, żeby nie „10x-ować” pojedynczego workflowu, tylko „100x-ować” cały biznes. To twoja praca jako FDE: audyt → eval → wdrożenie, w kółko.
30-dniowy plan wejścia od zera
Greg: Ty sam to zrobiłeś, prawda? Byłeś inżynierem w Meta i nauczyłeś się tego. Mówisz z doświadczenia.
Voss: Tak. Byłem inżynierem w Meta przez kilka lat, przy paru różnych produktach, ale nigdy nie byłem konsultantem — nie rozumiałem, co naprawdę ma znaczenie dla biznesu, tak głęboko jak teraz. Zaczęliśmy po prostu robiąc. Mieliśmy tezę, że AI trzeba stosować i że to pozwala wyprzedzić krzywą. Ale nigdy nie uczysz się przez czytanie — uczysz się przez działanie. Celem tego planu jest skondensować to, co robiłem przez rok, w 30 dni.
Tydzień pierwszy — zbuduj agenta, który domyka realną pętlę. Zbuduj agenta, który jest naprawdę użyteczny jako workflow. Zapytaj ChatGPT o jeden realny korporacyjny workflow w jakiejś funkcji back-office — finanse, HR, zakupy, logistyka, IT, sprzedaż, cokolwiek. Zdobądź go w jak najbardziej granularnych szczegółach i zbuduj dla niego agenta. Nawet dziś budowa agentów jest trudna — myślimy, że to rozwiązana nauka, a nie jest. Moja definicja: jeśli dam ci zadanie, czy potrafisz je rozwiązać w jak największym szczególe i z wystarczająco wysoką dokładnością? To coś innego niż samo poproszenie Claude’a, by to zrobił. Agent działa bardziej w tle, ma powtarzalny ruch, gdzie nie polegam na tym, że ktoś idealnie sformułuje prompt. Mogę promptować jak idiota, a to i tak zadziała — to mój wymóg.
Jeśli masz 7 dni, dasz radę to opanować: pętla agenta, potem użycie narzędzi, potem guardraile, potem kontekst i pamięć, i wreszcie ślad audytowy (audit trail), który jest niesamowicie ważny. Jeśli nie potrafisz pokazać klientowi, co agent robi, nigdy ci nie zaufa. Istnieje wielki strach, że agent „pójdzie sobie i zrobi coś strasznego” — i sporo siania paniki, nie powiem od kogo, ale wszyscy wiedzą. Musisz pokazać, że ślady agenta są logowane. To problem inżynierii oprogramowania — jeśli to potrafisz, jesteś o krok przed innymi. Każdy z tych elementów to pełny dzień. Jeśli pracujesz 12 godzin dziennie, nie oczekuję, że opanujesz to idealnie każdego dnia — plan można rozłożyć w czasie, nie musisz zamknąć się w 30 dniach. Punkt kontrolny ostatniego dnia: masz działającego agenta z narzędziami, guardrailami, przemyślaną pamięcią i pełnym śladem audytowym dla jednego zadania. Możesz nawet nie rozumieć tego zadania najlepiej — chodzi o to, byś biegle budował agentów.
Tydzień drugi — zamień demo w system, który potrafi się podnieść. Bardzo mocno po stronie inżynierii. Zdefiniowany schemat JSON, nie dowolny tekst. Walidujesz schemat. Masz tryby awarii — i celowo mówię „tryby awarii”, obsługa wyjątków — obsługa awarii jest skrajnie ważna. Tu liczy się głębokie wejście w klienta: jeśli rozumiesz, jak coś idzie nie tak, i budujesz agenta wokół tego, jest to znacznie skuteczniejsze niż agent rozwiązujący tylko „ścieżkę szczęśliwą” (happy path). Jest tylko jeden sposób, by coś poszło dobrze, ale tysiąc sposobów, by poszło źle. Jeśli budujesz tylko pod dobry przebieg, jesteś nic nie wart. Jeśli rozwiązujesz wszystkie wyjątki — tam jesteś jako agent coś wart.
Tydzień trzeci — uczyń go mierzalnym i opłacalnym. Logika ponawiania (retry). Złoty zbiór danych do evali. Pilnujesz, by poprawiał się w czasie. Ale też zaczynasz rozumieć ekonomię: patrzysz na tańsze modele do podzadań, mniej flagowe, mniej frontier. Czy da się zrobić robotę na Gemini Flash? Na Muse Spark? Pewnie nie na Llama 4, ale są inne modele, które mogą pasować. Masz agenta — teraz go optymalizuj i mierz: o ile faktycznie przesuwa wskaźnik? Ile czasu zaoszczędzę na produkcji? Ile ryzyka złagodzę? Jaki wzrost przychodów? Są tylko trzy kubełki pomiaru, które liczą się dla biznesu: wzrost przychodów, ograniczenie ryzyka i oszczędność kosztów. Zmierz agenta we wszystkich trzech. Punkt kontrolny: masz ocenionego agenta ze znanymi trybami awarii, zmierzonymi kosztami i złotym zbiorem danych.
Tydzień czwarty — broń systemu jak FDE. To cały biznes wokół: bolączki, dlaczego AI tu pasuje, architektura, iteracje. Na początku agent to mylił, potem się poprawił — dokładność z 70% do 95%. I ekonomia: ile czasu zaoszczędziłeś, o ile zmniejszyłeś błędy, ryzyko, przychody, koszty. Powtarzasz to jako inżynier: jaka była architektura, jakie decyzje. I powtarzasz to jako VP: jaki problem rozwiązałeś, jaki był wynik, dowód, ryzyko. Ten tydzień pokaże, czy system, który zbudowałeś, był wart zachodu i ile mógłbyś za niego zażądać u klienta. Mocno zalecam, byś w tym tygodniu pitchował swojego agenta firmom — powiedzą ci wprost: „nie, dobrze to ująłeś?”, „dobrze policzyłeś ekonomię?”, „myślisz o tym właściwie?”. Powiedzą bez ogródek „nie” albo „chcę to zbudowane inaczej”. I zaczniesz widzieć, jak przy kolejnym zaangażowaniu FDE, gdy będziesz już osadzony u klienta, nauczysz się jeszcze więcej. Te 30 dni to okres, gdy nie jesteś jeszcze osadzony u klienta — bo nie możesz, najpierw musisz zostać FDE. Dopiero wtedy zaczynasz się pitchować i angażować w firmie.
Gdybym miał to spłaszczyć: te 30 dni to wykonywanie pracy, zanim masz tytuł. W dniu 30. rozumiesz forward deployed engineering, ale masz też dowód, że potrafisz to robić. A gdy zapitchujesz to firmie, dużo chętniej da ci szansę. To mój cel.
Zakończenie — tego nie uczą w szkole
Greg: Voss, to jest idealne — dokładnie to bym polecił. Byłoby super, gdybyś faktycznie nauczył ludzi, jak to robić, spędził z nimi 30 dni. Może zrobimy to razem — taki pomysł. Jeśli ludzie są zainteresowani, wrzucę link w przypiętym komentarzu na YouTube. Nic nie obiecuję, jestem po prostu ciekaw — czy ludzie chcieliby jakiegoś programu do tego? Bo samodzielnie może się to wydawać przytłaczające, choć wciąż uważam, że da się zrobić w pojedynkę. Tego nie uczą w szkole.
Voss: Nie uczą. Powinni. Pewnie niedługo będą kursy uniwersyteckie o FDE. Ale to trwa tak długo. Byłem na informatyce w 2009 roku, gdy właśnie ruszył App Store. Było oczywiste, że aplikacje mobilne to następna fala — tak samo jak dziś oczywiste jest, że AI to nie tyle następna fala, co po prostu fala. A podręczniki wtedy uczyły budowania starego oprogramowania. Poszedłem do znanego profesora i zapytałem: „czemu nie uczycie nas Objective-C i budowania na App Store?”. Odpowiedział: „bo tego nie ma w podręczniku”. Wtedy uznałem, że rzucam studia — nie chcę uczyć się rzeczy wczorajszych, chcę uczyć się jutrzejszych. Zawsze jest argument, że potrzebujesz podstaw — i faktycznie nauczyłem się na studiach fundamentów matematyki i fizyki, które pomogły mi w myśleniu. Ale tej taktycznej, praktycznej wiedzy tam nie zdobyłem.
Voss: Ten raz jest inny, bo AI jest tak potężne. Mam nadzieję, że uczelnie podchwycą to prędzej niż później, ale czuję, że masz rację — raczej nie stanie się to szybko.
Greg: No i macie to, ludzie — czym są FDE i jak nim zostać, plus 30-dniowy plan. Voss, chcesz coś jeszcze dodać?
Voss: Może nie znajdziesz tego na uniwersytecie, ale absolutnie znajdziesz na YouTube. Greg uczy wszystkiego, co trzeba wiedzieć — i na Twitterze też. Te dwa źródła to miejsca, gdzie wszystko się pojawia. Nawet Mark Zuckerberg wrócił na Twitter, żeby ogłosić najnowszy model Meta. Tam się dzieje. Studiuj grę tam. Masz świetnego trenera przed sobą — Grega. Jest znacząca przewaga („alpha”) w tym, żeby wyjść, uczyć się i robić samemu, kombinować, zamiast czekać, aż uczelnia cię tego nauczy — bo to się szybko nie zdarzy.
Greg: I to jest za darmo. Możesz tego posłuchać i zastosować. Voss, dzięki, że byłeś hojny z tym, co na kanale nazywamy „sosem” — z taktykami — i że wyłożyłeś to tak jasno. Śledzę cię prawie od dwóch lat, jesteś kimś, kogo trzeba obserwować. Wrzucę linki, gdzie można śledzić Vossa z Veric Agents, w opisie. Komentujcie, co myślicie o tym odcinku — czytam każdy komentarz. Voss, ostatnie słowa?
Voss: Greg, jesteś legendą, dzięki za zaproszenie. A do ludzi: wierzę w was. Naprawdę uważam, że to fundamentalna zmiana w tym, jak wykonuje się pracę. Jeśli słuchasz Grega i to oglądasz, jesteś już o krok przed innymi. Też będę czytał każdy komentarz — jeśli macie pytania, dajcie znać. Ale powiem tak: wyjdź i to zdobądź. Wykorzystaj maksymalnie swoją zdolność rozumienia AI. Wciąż jest bardzo wcześnie, więc wyprzedź to, póki możesz.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przewaga w AI przeniosła się z modelu na wdrożenie
Na czym polega: Skoro każda firma może kupić dostęp do tych samych modeli frontier, sama inteligencja przestała być przewagą konkurencyjną. Wartość leży w tym, gdzie, jak i po co ją zastosujesz w konkretnym kontekście firmy.
Jak stosować: Nie sprzedawaj „AI” ani konkretnego modelu. Sprzedawaj dopasowanie inteligencji do specyficznych procesów danej firmy — to twój produkt. Pozycjonuj się jako most między procesami klienta a jego stackiem AI.
Na co uważać: Nie wpadaj w pułapkę „mamy lepszy model”. Klient najpewniej ma dostęp do tego samego. Twoja rozmowa handlowa musi dotyczyć procesu i wyniku biznesowego, nie technologii.
2.FDE to rzadkie połączenie inżyniera i konsultanta
Na czym polega: Milionowa rola wymaga jednocześnie głębokiej biegłości technicznej (modele, API, evale, guardraile, kod) i umiejętności miękkich (komunikacja, wyciąganie wiedzy z ludzi, rozumienie polityki firmy). To najlepsze z obu światów, nie średnia.
Jak stosować: Zdiagnozuj, z której strony przychodzisz, i celowo wzmacniaj słabszą. Inżynier: ucz się rozumienia procesów, kosztów, zachęt i ROI. Konsultant: ucz się realnie budować agentów i systemy.
Na co uważać: Nie zostań „przeciętny w obu”. Rynek nie płaci za kogoś, kto ani dobrze nie koduje, ani dobrze nie komunikuje. Musisz być mocny w obu, nie letni.
3.Udokumentowany proces prawie nigdy nie jest procesem prawdziwym
Na czym polega: Ludzie opisują „ścieżkę szczęśliwą” („przychodzi e-mail”), ale połowa realnej pracy to wyjątki i wiedza ukryta w głowie jednej osoby, której nikt nie spisał.
Jak stosować: Siadaj z ludźmi na miejscu przez pełne godziny, obserwuj pracę, wyciągaj wyjątki pytaniami. Buduj system pod rzeczywisty przebieg, a nie pod czysty diagram, który dostaniesz na godzinnym spotkaniu.
Na co uważać: Godzinny wywiad da ci zafałszowany obraz. Jeśli zaprojektujesz system na jego podstawie, zbudujesz coś, co nie odpowiada rzeczywistości — jedna z głównych przyczyn porażki pilotaży.
4.Selektywność zamiast „token maxingu”
Na czym polega: Wrzucanie wszystkiego do modelu prowadzi do halucynacji, przepalonych budżetów i braku efektu (statystyka MIT: 95% pilotaży generatywnego AI zawodzi). Trzeba świadomie wybierać, gdzie AI ma sens.
Jak stosować: Rozłóż workflow na kroki. Większość rozwiąż deterministycznie (instrukcje warunkowe, wywołania API), LLM wprowadzaj tylko tam, gdzie naprawdę potrzebny jest osąd. Człowieka w pętli zostaw dla decyzji ryzykownych.
Na co uważać: Nie automatyzuj kroków o niskim ROI, wysokim ryzyku albo już zautomatyzowanych. „AI wszędzie” to antywzorzec — kosztuje, a nie rusza wskaźnika.
5.Wejdź przez audyt — i przemianuj go, jeśli trzeba
Na czym polega: Audyt (mapa operacyjna workflowów, obsługi wyjątków i macierz ROI, co warto automatyzować) jest sam w sobie wart ogromnych pieniędzy i buduje zaufanie przed jakąkolwiek budową.
Jak stosować: Zawsze zaczynaj zaangażowanie od audytu. Dostarcz czytelną mapę procesów i macierz ROI, a potem pokaż konkretny, wartościowy przypadek użycia. Na starcie kariery rozważ audyt za darmo, by wejść.
Na co uważać: Słowo „audyt” budzi opór (kojarzy się z kontrolą skarbową). Przebranduj je na „sprint” czy „mapowanie”. I nie proponuj budowy, zanim nie zrozumiesz biznesu przez audyt.
6.Buduj na istniejących systemach, nie wymuszaj migracji
Na czym polega: Firmy zainwestowały lata i miliony w swoje ERP/CRM. Rozwiązanie żądające migracji zostanie odrzucone. Przewagę daje budowanie na wierzchu i integrowanie tego, co już mają.
Jak stosować: Projektuj agentów jako warstwę nad NetSuite, Salesforce, SAP itd. Skaluj stopniowo: wdrożenie → tryb obserwacyjny (shadow) → rosnąca autonomia → produkcja. Prowadź klienta przez zmianę, najlepiej osobiście.
Na co uważać: „Pstryknięcie przełącznika, teraz AI prowadzi wasz biznes” to podejście polaryzujące, które zabija sprzedaż. Zmiana skokowa = ryzyko, którego decydent nie weźmie na siebie.
7.De-ryzykuj ofertę — decydent boi się o swoją skórę
Na czym polega: Osoba w firmie nie chce zostać zwolniona, chce awansować. Twoje zaangażowanie samo w sobie jest dla niej ryzykiem. Musisz to ryzyko zdjąć.
Jak stosować: Formułuj wartość jako „pomogę ci dostarczyć wynik efektywnie kosztowo, na który wskażesz przy ocenie okresowej”. Bierz zapłatę po udowodnieniu mierzalnej wartości. Pierwszych kilku klientów potraktuj jako naukę.
Na co uważać: Jeśli sprzedajesz „lepszą technologię” zamiast „twojego awansu i bezpieczeństwa”, przegrywasz z inercją — status quo jest dla decydenta bezpieczniejszy niż nieudany projekt z tobą.
8.Mierz tylko trzy rzeczy, które liczą się dla biznesu
Na czym polega: Dla firmy istotne są wyłącznie trzy kubełki: wzrost przychodów, ograniczenie ryzyka i oszczędność kosztów. Wszystko inne to szum.
Jak stosować: Każdego agenta oceniaj we wszystkich trzech wymiarach: ile czasu oszczędza, ile ryzyka łagodzi, ile przychodu podnosi. Przygotuj dwie narracje — techniczną (dla inżynierów) i biznesową (dla VP).
Na co uważać: Metryki techniczne (dokładność, liczba tokenów) nie przekonają decydenta. Zawsze przekładaj je na jeden z trzech kubełków, inaczej twój wynik zostanie zignorowany.
9.Buduj pod porażki, nie pod „ścieżkę szczęśliwą”
Na czym polega: Jest jeden sposób, by coś poszło dobrze, i tysiąc sposobów, by poszło źle. Agent rozwiązujący tylko happy path jest bezwartościowy; wartość powstaje w obsłudze wyjątków.
Jak stosować: Używaj zdefiniowanego schematu JSON i walidacji zamiast dowolnego tekstu. Zbadaj u klienta, jak konkretnie sprawy idą nie tak, i zbuduj wokół tego obsługę awarii, logikę ponawiania i routing do człowieka. Prowadź złoty zbiór i evale, które poprawiają się w czasie.
Na co uważać: Demo działające na happy path daje fałszywe poczucie gotowości. Bez trybów awarii i śladu audytowego (logowanie tego, co agent robi) klient ci nie zaufa — a brak zaufania to koniec wdrożenia.
10.Opanuj jeden ekosystem, potem bądź agnostyczny — i ucz się przez robienie
Na czym polega: Na starcie twoja wartość nie leży w model-agnostycyzmie, tylko w rozumieniu obu stron barykady. Najpierw stań się bardzo dobry w jednej platformie do budowy agentów, dopiero potem poszerzaj. A całej roli uczysz się działając, nie czytając.
Jak stosować: Wybierz jeden ekosystem (OpenAI, Claude/agent SDK itp.), opanuj go do fundamentu, potem eksperymentuj z innymi i benchmarkuj. Przejdź 30-dniowy plan: agent domykający pętlę → odporność na awarie → mierzalność i ekonomia → obrona systemu jak FDE. Pod koniec pitchuj firmom po feedback.
Na co uważać: Nie stawiaj wozu przed koniem — rozpraszanie się na wiele modeli, zanim opanujesz jeden, osłabia cię. I nie licz na to, że nauczysz się tego z podręczników czy uczelni; przewaga jest w byciu wczesnym i praktykiem, a nie teoretykiem.