O czym jest ten film
- Laboratoria, które obiecują autonomiczną inteligencję, w rekordowym tempie zatrudniają ludzi, żeby siedzieli w firmach klientów i sprawiali, że ta inteligencja naprawdę działa.
- Forward deployed engineer (FDE) to dziś jedna z najgorętszych ról w AI — OpenAI płaci do 280 tys. dolarów podstawy plus udziały, Handshake ogłasza to samo stanowisko za 300 tys.
- Sedno roli to nie pisanie kodu, tylko znalezienie punktu dźwigni: miejsca w procesie, gdzie mała implementacja odblokowuje ogromną ilość zablokowanej pracy.
- Cała mechanika roli zostaje pokazana na jednej historii — Maya z operacji likwidacji szkód w regionalnym ubezpieczycielu.
- Rola ma trzy części: rozumienie biznesu, techniczne dowiezienie rozwiązania i własność wdrożenia po starcie.
- Prawie nikt nie startuje mocny we wszystkich trzech — inżynierowie mają problem z bliskością klienta, ludzie z operacji z głębią techniczną.
- Wiedza branżowa jest realnym atutem, nie ozdobnikiem — badanie ok. 400 tys. sesji Claude Code pokazało, że eksperci w danym zadaniu osiągali zweryfikowany sukces ponad dwa razy częściej niż nowicjusze.
- Ewaluacje (evals) to dziś kluczowa kompetencja techniczna, która nie ma nic wspólnego z pisaniem kodu — i można się jej nauczyć.
- Autor podaje gotowy, czterotygodniowy plan zbudowania dowodu kompetencji, który da się „speedrunować” w trzy–cztery dni.
- Tytułów nie trzeba czekać — droga do roli prowadzi przez rozwiązanie realnego problemu AI tam, gdzie się już pracuje.
Redakcyjne tłumaczenie
Wyznanie, którego laboratoria nie wypowiadają wprost
Każde laboratorium, które obiecuje autonomiczną inteligencję, zatrudnia ludzi tak szybko, jak tylko potrafi — po to, żeby ci ludzie siedzieli w firmach takich jak wasza i sprawiali, że ta inteligencja rzeczywiście działa. To jest wyznanie. Wyznanie laboratoriów, jak bardzo potrzebują ludzi.
Anthropic zapowiedział, że przeszkoli dziesiątki tysięcy inżynierów, którzy pójdą wdrażać AI w bankach, liniach lotniczych i firmach ubezpieczeniowych. Wiecie, ilu faktycznie przeszkolono? Osiemdziesięciu sześciu. Osiemdziesięciu sześciu. I ta luka to cała historia najgorętszej pracy w AI. To także powód, dla którego ta praca płaci tyle, ile płaci.
OpenAI zatrudnia forward deployed engineerów za nawet 280 tysięcy dolarów podstawy plus udziały. I nie są jedyni — Handshake ogłosił to samo stanowisko za 300 tysięcy. Te liczby sprawiają, że wielu z nas próbuje zrozumieć, co taki człowiek właściwie robi i czy istnieje realna droga do tej pracy.
(Informacja dodatkowa: podane widełki to płace amerykańskie w spółkach technologicznych z Doliny Krzemowej — poza rynkiem USA poziomy wynagrodzeń dla tej roli są istotnie niższe.)
Po tym materiale powinniście umieć spojrzeć na swoją obecną pracę i zobaczyć, którą część kompetencji FDE już macie — niezależnie od tego, czy jesteście inżynierami — której wam brakuje i co dałoby się zbudować w ciągu najbliższego miesiąca, żeby uzasadnić zaproszenie na rozmowę.
Powód istnienia tej roli jest prosty: AI to zdolność ogólnego przeznaczenia, a ostatnia mila w AI jest naprawdę trudna. FDE łączą te dwa brzegi. Dlatego mają znaczenie.
Historia Mayi: od hasła prezesa do problemu, który da się zbudować
Powiedzmy, że prowadzicie operacje likwidacji szkód w regionalnej firmie ubezpieczeniowej. Wchodzimy w szczegóły, bo to właśnie ze szczegółów da się wyprowadzić zasady, z których wszyscy skorzystamy. Nazwijmy tę osobę Maya.
Prezes obejrzał wystarczająco dużo prezentacji o AI, żeby wiedzieć, że technologia potrafi czytać dokumenty. Teraz chce, żeby szkody były obsługiwane dwa razy szybciej. Skąd mam tę historię? Rozmawiałem z takimi prezesami i rozmawiałem też z takimi Mayami.
To brzmi jak klarowny cel, ale to nie jest zadanie, które da się zbudować — i powie wam to każdy z inżynierii albo z produktu. Bo szkoda może zawierać polisę, zdjęcia, kosztorysy naprawy, dokumentację medyczną, raporty policyjne, kontrolę pod kątem wyłudzenia, rozmowy z klientem i kilka różnych akceptacji. Jeśli Maya przekaże to wszystko zespołowi technicznemu i powie tylko „przyspieszcie szkody z pomocą AI”, to Maya odwaliła kiepską robotę, a zespół musi podjąć za nią większość decyzji produktowych.
Ale Maya jest świetną PM-ką. Zamiast tego otwiera prawdziwe akta. Bierze jedną szkodę, która przeszła przez przyjęcie w jeden dzień, i drugą, która stała prawie tydzień — jako kontrprzykład. W tej wolniejszej sprawie kosztorys naprawy przyszedł we wtorek, ale brakowało strony z podpisem i nikt tego nie zauważył do piątku. Trzy dni zniknęły, zanim likwidator w ogóle podjął jakąkolwiek decyzję ubezpieczeniową.
W aktach znajduje też problemy dużo trudniejsze. Szkody osobowe potrafią ciągnąć się tygodniami. Kontrola pod kątem wyłudzeń jest bardzo kosztowna. Decyzja, czy wypłacić skomplikowaną szkodę, jest oczywiście warta dużo pieniędzy — ale te przypadki są mocno zróżnicowane. Wymagają dużo doświadczonego osądu, a błędna decyzja wypuszcza pieniądze za drzwi albo tworzy poważną ekspozycję prawną dla całej inicjatywy AI.
Problem brakującego dokumentu ma zupełnie inny kształt. I tu dochodzimy do zasady, którą da się uogólnić. Bo widzicie: brakujący dokument zdarza się cały czas. Siedzi na samym początku procesu, a wszystko, co za nim, czeka na to, żeby to zrobić dobrze.
Jeśli firma dostaje kilka tysięcy szkód miesięcznie, a kilkaset — powiedzmy sześćset, siedemset — przychodzi niekompletnych, i każda traci po kilka dni, zanim ktokolwiek to zauważy i skontaktuje się z klientem, to mamy jakieś 1800–2000 dni szkód stojących w miejscu każdego miesiąca. I oto co mnie w tym dobija: dane potrzebne do podjęcia dobrej decyzji i powiedzenia klientowi „potrzebujemy dodatkowych dokumentów” już są w pakiecie szkodowym. Każdy likwidator sprawdzi to bardzo szybko, a flaga może polecieć, zanim w ogóle powstanie jakiekolwiek opóźnienie.
To dokładnie ten powód, dla którego Maya w naszej historii wybiera przyjęcie szkody. Widziałem, jak ta logika rozgrywa się konkretnie w ubezpieczeniach — ale to jest też podpowiedź, jak FDE chwytają te umiejętności i przenoszą je gdzie indziej.
Dźwignia: zasada, którą przenosi się między branżami
Jeśli szukacie tu szerszej reguły, to brzmi ona tak: Maya znajduje punkt dźwigni dla pracy z AI, którą chce wykonać. Znajdowanie dźwigni to uogólnialna kompetencja FDE.
W tym przypadku Maya szuka miejsca, w którym stosunkowo mała implementacja przesuwa największą ilość pracy — bez dawania modelowi niebezpiecznego zakresu władzy. To jest dźwignia. Dźwignia zastosowana wewnątrz procesu.
Usługa musi tylko zauważyć, że przyszedł niekompletny plik. Wskazuje brakujący element i przygotowuje odpowiednią komunikację. Tyle. Wszystko, co bardziej skomplikowane — decyzje o szkodach osobowych, podejrzenie wyłudzenia — zostaje przy prawdziwych ludziach.
Wybór tego punktu w procesie — niezależnie od tego, czy pracujecie w ubezpieczeniach, czy w dowolnej innej branży — to jest ta kompetencja FDE, której ludzie desperacko szukają. Ten sam miesiąc pracy inżynierskiej może usunąć 1800 dni czekania albo odrobinę poprawić rzadki przypadek brzegowy. Inżynierię wkładacie tak czy siak.
Firma może mieć dwadzieścia, trzydzieści albo setki sensownych miejsc na dołożenie AI. FDE musi rozstrzygnąć, które opóźnienie zdarza się na tyle często, żeby miało znaczenie, który ból jest wystarczająco bolesny i która poprawka uwalnia dużo pracy dalej w procesie — jak odetkać wąskie gardło.
Robiłem to kiedyś bardzo ręcznie, gdy zajmowałem się mapowaniem procesów jako black belt w Kaizen: mapujesz proces i szukasz wąskich gardeł. Dziś bierze się podobne umiejętności poza formalny kontekst Kaizen i wkłada w realny świat, gdzie próbujesz zrozumieć, jak zastosować AI do odetkania prawdziwej pracy.
(Informacja dodatkowa: Kaizen to japońska metodyka ciągłego doskonalenia procesów; „black belt” to najwyższy poziom certyfikacji w pokrewnym systemie Six Sigma.)
Przewaga wybierania pracy w ten sposób jest taka, że Maya ma teraz coś, co da się zmierzyć. Może szybko śledzić, ile czasu zajmuje wykrycie braku, jak często zbudowana usługa podnosi fałszywy alarm albo przeoczy dokument i ile czasu likwidator poświęca potem na sprawdzenie. Projekt można wtedy poprawnie zmierzyć, ocenić jako sukces i przejść do kolejnego wdrożenia AI.
To jest ten rodzaj pracy, który chcę, żebyście sobie wyobrażali, słysząc „forward deployed engineer”. A jeśli słuchacie tego i myślicie „to brzmi bardzo produktowo” — to właśnie o to chodzi. Jedną z ciekawszych cech tej roli jest to, że miesza dużo produktu z solidnym zestawem umiejętności technicznych.
Rola pod wieloma nazwami
Sam tytuł jest ruchomy. W jednej firmie oznacza bardzo mocnego inżyniera oprogramowania, który pracuje bezpośrednio z klientami. Gdzie indziej wygląda bardziej jak applied AI, implementacja albo techniczna rola produktowa. Ale wspólna część jest zawsze ta sama: zostajesz przy problemie od wyboru punktu startowego aż po działający system, bo bierzesz na siebie zobowiązanie, że ta zdolność zadziała wewnątrz złożonego, realnego środowiska.
Za każdym razem, gdy prowadziłem wdrożenia technologii w korporacjach — a prowadziłem ich sporo — trafiały w tę samą ścianę. Kupienie produktu od handlowca to łatwa część. Potem ktoś musi uzyskać dostęp do danych, zrozumieć politykę, której nikt nigdy nie spisał, dopasować narzędzie do tego, jak ludzie faktycznie pracują, i poradzić sobie z pierwszym bólem, który wraca od prawdziwego klienta.
To wszystko znamy z klasycznych wdrożeń narzędzi w przedsiębiorstwie. Ale AI czyni tę pracę jeszcze trudniejszą, bo oprogramowanie nie przesuwa już biernie danych. Może podejmować inteligentne decyzje. Może stwierdzić, czego brakuje w dokumencie. Może napisać odpowiedź. Może wykonać działanie i zapisać coś w innych systemach. Drobne nieporozumienia i drobne bóle potrafią w epoce AI zawędrować znacznie dalej.
Dlatego FDE są tak ważni w oprogramowaniu opartym o AI: Maya musi wybrać miejsce, w którym technologia wykona najwięcej pracy przy najmniejszym potencjale szkody dalej w procesie. Bierze wielkie wyzwanie „skrócić czas obsługi szkody” i musi zdecydować, w którym punkcie zaaplikować AI, żeby to dowieźć. Jeśli zrobi swoją robotę dobrze, to zanim skończy, ona i inżynierowie mogą budować ramię w ramię, a biznes dostaje czysty, mierzalny wynik, który da się zweryfikować.
Innymi słowy: Maya jest tłumaczką. Tłumaczy z mglistych, wielkich deklaracji prezesów i z ogólnych zdolności modeli AI na konkret — konkret jej kodu, jej kontekstu produktowego, jej klientów. Tak, żeby wartość faktycznie się zmaterializowała. To właśnie robi FDE.
Trzy części roli — i skąd startujesz
Rola ma z grubsza trzy części i prawie nikt nie startuje równie mocny we wszystkich trzech. Więc jeśli słuchając tego czujecie, że jesteście w tyle — prawdopodobnie nie jesteście.
FDE musi: po pierwsze, zrozumieć biznes na tyle, żeby znaleźć punkt dźwigni; po drugie, zbudować system i umieć go skontrolować; po trzecie, zostać po starcie wystarczająco długo, żeby dowiedzieć się, czy ludzie tego naprawdę używają i czy wynik jest wart kosztu.
Inżynierowie oprogramowania odkryją zwykle, że budowanie to akurat ta część, o którą martwią się najmniej. Ją mają opanowaną. Trudniejszy ruch to dla nich zbliżyć się do klienta na tyle, żeby zrozumieć, dlaczego konkretny problem z dokumentem ma znaczenie, dlaczego brakujące pole ma znaczenie — a potem połączyć architekturę, którą budują, z pieniędzmi, czasem, ryzykiem i przepustowością.
Jeśli przychodzicie z operacji, z produktu albo z konsultingu, możecie mieć uczucie dokładnie odwrotne. Wiecie, dlaczego czysty diagram procesu nie pasuje do rzeczywistości. Wiecie, które wyjątki mają znaczenie dla klientów. Ale waszą pracą jest teraz zejść wystarczająco głęboko technicznie, żeby faktycznie zbudować rozwiązanie, skontrolować, nad czym pracuje wasze AI, i zrozumieć, gdzie to rozwiązanie może się wywrócić.
Jeśli przychodzicie z solutions engineeringu, z implementacji albo nawet z sales engineeringu, jesteście zwykle gdzieś pośrodku. Już teraz musicie tłumaczyć między klientami a systemami. Pytanie do was brzmi: czy potraficie pozostać odpowiedzialni po tradycyjnym punkcie przekazania — po konfiguracji, po handoffie — kiedy trzeba wziąć na siebie wynik, zaczynają spływać złe przypadki i musicie zmienić własny projekt.
Jak ćwiczyć osąd biznesowy: zejdź do konkretu
Jeśli chcecie ćwiczyć demonstrowanie osądu procesowego i biznesowego, nie zaczynałbym od rozgryzania całego stanowiska. To zresztą typowy tryb porażki, który widuję też u PM-ów. Zejdźcie do konkretu.
Ustaliłbym, jak wyciągnąć ostatnie dziesięć wystąpień problemu, którym się zajmuję — jak zdobyć świeże, konkretne dane. Potem zacząłbym w nie wchodzić i rozumieć bardzo precyzyjnie, co się dzieje i dlaczego, jakie korekty już istnieją, gdzie w tych powtarzalnych sprawach są bóle, które da się zaatakować.
Gdy tylko zaczniecie znajdować świeże przypadki, zaczniecie je klasyfikować, a potem policzycie zgrubną matematykę. Różnice, które widzicie w próbce dziesięciu czy dwudziestu przypadków. Policzcie, ile spraw wpada w dany problem — i już potraficie oszacować na brudno, jak dużo problemu rozwiążecie, jeśli usuniecie konkretne bóle.
Nie potrzebujecie idealnego modelu finansowego, żeby być FDE. Potrzebujecie wystarczających dowodów i wiedzy, jak je zdobyć, żeby móc mówić konkretnie o bólu. Bo w naszej historii Maya może teraz porównać niekompletne przyjęcie szkody z kontrolą wyłudzeń — właśnie dlatego, że policzyła zgrubną matematykę dla obu.
A jeśli zastanawiacie się, czy takie dane da się zdobyć na rozmowie kwalifikacyjnej: gdy dostajecie case do rozwiązania, zwykle właśnie taki typ danych jest wam podawany — po to, żeby zobaczyć, czy po niego sięgniecie.
Kolejny krok, jeśli to możliwe, to usiąść obok osoby wykonującej pracę i patrzeć, jak proces się dzieje. To jedna z najbardziej wartościowych rzeczy, jakie znam z produktu — i bardzo produktowa rzecz do zrobienia. Po prostu siądźcie obok klienta i zobaczcie, jak pracuje. Duża część tego, co robi, może nie występować w oficjalnym procesie, a musicie się tego nauczyć, żeby skutecznie zmapować bóle.
Możecie więc zacząć od sklasyfikowania dziesięciu największych bólów i zgrubnej matematyki, a po posiedzeniu z prawdziwym klientem wrócić i powiedzieć: „Pięć z nich jest fikcyjnych” albo „pięć z nich to bardzo zły opis tego, co się naprawdę dzieje, a oto jak jest naprawdę”. Pozwólcie, żeby rzeczywistość zmieniła waszą ocenę problemu.
Wiedza branżowa jest atutem, a nie balastem
Warto zauważyć jeszcze jedno: wiedza branżowa odgrywa u FDE bardzo praktyczną rolę. Jeśli zastanawiacie się, jak wejść w tę rolę, popatrzcie na wiedzę branżową, którą już macie.
Likwidator szkód po prostu intuicyjnie wie, kiedy kosztorys naprawy jest poprawny, a kiedy nie. Osoba z operacji finansowych po prostu wie, kiedy dwa raporty używają tej samej nazwy, ale mają w środku inne liczby. Lider wsparcia po prostu wie, że jedno zwyczajnie wyglądające zdanie zwykle oznacza, że klient natychmiast potrzebuje człowieka. Takiej wiedzy nie da się niczym zastąpić.
Badacze przeanalizowali około 400 tysięcy sesji Claude Code i osoby oceniane jako eksperci w danym zadaniu osiągały zweryfikowany sukces ponad dwa razy częściej niż nowicjusze. Ekspertyza dziedzinowa ma znaczenie.
Część druga: techniczne dowiezienie
Drugą częścią pracy FDE jest dowiezienie techniczne — i tu chcę, żebyście czytali ogłoszenia bardzo uważnie, bo bywają przerażające.
OpenAI oczekuje od swoich FDE pisania kodu zarówno na froncie, jak i na backendzie. Palantir opisuje ludzi, którzy budują aplikacje, pracują z danymi, podejmują decyzje architektoniczne i prowadzą pracę aż do wdrożenia. To jest zupełnie inny opis stanowiska.
Powiedzmy jasno: jeśli ogłoszenie mówi o produkcyjnej inżynierii oprogramowania, to sama wiedza branżowa absolutnie nie przeprowadzi was przez ten wymóg i nie będę udawał, że jest inaczej. Czy jesteście Mayą i robicie małą wersję techniczną — co jest w pełni prawdziwym FDE — czy próbujecie budować pełne aplikacje frontowe i backendowe, wasz przebieg będzie różny. Musicie czytać opisy, bo ta rola ma naprawdę szeroki rozrzut oczekiwań technicznych.
Dobra wiadomość: jeśli musicie nauczyć się umiejętności technicznych, absolutnie możecie. Są bootcampy, ale powiem też, że dziś można uczyć się inżynierii frontendu i backendu razem z AI — po prostu ćwicząc na małych projektach. Widzę, jak ludzie z mojej społeczności na Substacku robią to bez przerwy. Widziałem osoby, które w dwanaście miesięcy doszły do poziomu technicznego założyciela, robiąc proste projekty: wywołują model, proszą o ustrukturyzowane wyjście, wyświetlają wyniki, uczą się uwierzytelniać użytkowników — przechodzą po prostu przez wszystkie kroki, które się przechodzi w oprogramowaniu, i budują, budują, budują, aż naprawdę rozumieją, co robią z AI.
Dlaczego to działa? Bo dziś inżynieria AI nie polega na osobistym pisaniu linijek kodu. Nie musicie pisać kodu własnoręcznie. Musicie rozumieć, jak działa system, znać pułapki i wiedzieć, jak skłonić AI, żeby poszło tam, gdzie chcecie. To się liczy.
Nie musicie więc zostać ekspertami od każdego elementu technicznego, zanim zaczniecie. Musicie rozumieć system na tyle, żeby mieć pewność, że potraficie poprosić model o odpowiedzialne zbudowanie czegoś. Przykład odpowiedzialnej decyzji z naszej historii: usługa Mayi potrzebuje dokumentów z przyjęcia szkody, czyli małego wycinka rekordu szkodowego — ale oczywiście chcecie odciąć dostęp do płatności i historii medycznej, bo model nie musi tego wiedzieć. O takich rzeczach FDE musi myśleć, projektując systemy.
Ewaluacje: kompetencja techniczna bez kodu
Druga rzecz naprawdę ważna dla FDE, która nie jest tradycyjną umiejętnością inżynierską, ale nią się staje — i z której wszyscy możemy skorzystać — to testowanie i ewaluacje. Skoro każecie modelom coś budować, musicie im powiedzieć, do jakich kryteriów mają budować.
W naszym przykładzie Maya może wziąć pięćdziesiąt poprawnie rozstrzygniętych przypadków — „tu brakuje dokumentów”, „tu nie brakuje” — jako zbiór testowy. Dzięki temu może sprawdzić, czy model potrafi napisać oprogramowanie, które przechodzi te testy.
Evals to kluczowy element budowania procesów agentowych. Konstruowanie ewaluacji jest dziś naprawdę ważną częścią pracy inżynierskiej. I nie ma nic wspólnego z kodem. Uchodzi za kompetencję techniczną, ale kodu w tym nie ma. Możecie się tego nauczyć.
Częściowo po to robię ten materiał: nie chcę, żeby ludzie, którzy mają opisane wyżej umiejętności translacyjne, uciekali od roli FDE tylko dlatego, że boją się słowa „kod”. Nie bójcie się. W tym samym badaniu nad Claude Code użytkownicy nietechniczni, którzy zaczęli programować z jego pomocą, zbliżyli się na kilka punktów do użytkowników technicznych i inżynierów pod względem jakości wytworzonego kodu.
Szersza teza brzmi: możecie sprawić, żeby AI napisało dobry kod, jeśli jesteście gotowi poświęcić czas na zrozumienie systemów i na zbudowanie dobrych ewaluacji.
Część trzecia: własność wdrożenia
Trzecia wielka część roli to własność wdrożenia. Maya może mieć system, który pięknie punktuje na aktach, a mimo to nie zadziała na produkcji. Musi więc umieć puścić przez niego żywą pracę, zauważyć, co się faktycznie dzieje, i wprowadzać korekty, żeby to, co powstało, było naprawdę użyteczne.
Ten cykl — mierz, ucz się z rzeczywistości, wracaj i buduj zdolność dalej — jest dla FDE i dla AI szczególnie ważny. Bo kiedy bierzecie ogólną zdolność AI i wprowadzacie ją w kontakt z konkretnym kodem i konkretnymi procesami, to jest proces iteracyjny. Musicie obrócić kołem zamachowym kilka razy, żeby upewnić się, że celujecie w miejsce, gdzie wartość naprawdę się realizuje. A ten proces ma ogromną, nieliniową wartość.
Innymi słowy: doprowadzenie AI do naprawdę wyjątkowej wartości — do zaoszczędzenia tych 2000 godzin miesięcznie albo cokolwiek to jest w waszym przypadku — to jest wpływ, którego trzeba żądać i oczekiwać. Jeśli jesteście w punkcie, w którym oszczędzacie 20 godzin albo 200 godzin, to nie jesteście tam, gdzie powinniście. Trzeba przyjrzeć się przyczynom i zrozumieć, jak sięgnąć po tę większą wartość, o której wiecie, że da się ją z AI odblokować.
To nie jest umiejętność, która przychodzi intuicyjnie — poza, jak zauważam, PM-ami i inżynierami, którzy mocno indeksują na własności. Te dwie rodziny zawodowe od dawna są tego uczone: musisz brać na siebie kod, który wypuszczasz na produkcję, i musisz brać na siebie wpływ na klienta. Z FDE jest dokładnie ta sama mentalność.
Jak czytać nazwy stanowisk
Dam wam kilka wskazówek co do ogłoszeń, bo — jak mówiłem — jest ich cały wachlarz, a chcę, żebyście wiedzieli, co pasuje do jakiego profilu.
Jeśli w tytule jest „forward deployed engineer” albo „forward deployed software engineer”, oczekiwania kodowe są zwykle najwyższe. „Applied AI engineer”, „customer engineer”, „solutions engineer”, „implementation engineer”, „technical deployment lead”, stanowiska z obszaru AI operations i AI product mogą zawierać dużo tej samej pracy, ale przy innym rozłożeniu wymagań technicznych. Możecie na nie patrzeć jak na kamienie w rzece: da się po nich przeskakiwać i dojść do FDE, biorąc po drodze któryś z tych sąsiednich tytułów.
Trzydzieści dni: plan, który da się wykonać
Zamieńmy to teraz w coś, czego da się użyć. Gdybym miał w ciągu najbliższego miesiąca udowodnić kompetencje FDE, zrobiłbym tak.
Tydzień pierwszy. Wybieram powtarzalny proces, który mogę faktycznie obserwować w szczegółach. Potrzebuję dostępu do kilku osób, które tę pracę wykonują, oraz co najmniej dziesięciu–dwudziestu zakończonych spraw, przez które mogę przejść i zobaczyć, jak praca przebiegła. Wyciągam tyle prawdziwej pracy, ile się da, i rekonstruuję, co się wydarzyło. Rozumiem różnice. Klasyfikuję problemy. Zaczynam szukać punktów dźwigni.
Tydzień drugi. Rozmawiam z osobą, która tę pracę wykonuje. Siadam obok niej. Z tego przeżytego doświadczenia ustalam, które z zmapowanych punktów interwencji są realnie najbardziej wpływowe. Gdzie jest dźwignia — ale naprawdę, w życiu, obok człowieka. Na tej podstawie robię matematykę na serwetce, bo FDE musi mieć wpływ biznesowy. Pod koniec tego tygodnia powinienem umieć powiedzieć bardzo jasno: tyle pracy oszczędzę, to robię, i dlatego to ma znaczenie.
Jeśli myślicie „dwa tygodnie to długo” — widziałem ludzi, którzy speedrunowali to w dwa dni. Doświadczona osoba potrafi wskoczyć w dane, posiedzieć z kimś jeden dzień i skończyć. Ale dla was to może być pierwszy raz, więc dajcie sobie chwilę.
Cokolwiek wyjdzie, skala i bezpieczeństwo interwencji muszą być widoczne, zanim zaczniecie budować. Musicie umieć powiedzieć: oto dlaczego to będzie miało wpływ i oto jak zabezpieczam barierki ochronne. Chodzi o to, żeby nie prosić AI o wymyślenie produktu, zanim zrozumiecie prawdziwego człowieka. AI jest naprawdę dobre w wymyślaniu rzeczy — wy musicie zrozumieć rzeczywisty ból.
Stamtąd zaczynacie budować. Najprostsze możliwe rozwiązanie. I mam na myśli budowanie — naprawdę dojdźcie do kodu. Pracujcie z agentem AI i zbudujcie coś, co rozwiązuje zidentyfikowany punkt dźwigni. Napisałem mnóstwo na Substacku o wdrożeniach korporacyjnych i barierkach ochronnych; poleciłbym tam zajrzeć, jeśli nie wiecie, od czego zacząć. Zrozumcie typowe oczekiwania wokół uprawnień, wokół danych, wokół uwierzytelniania i autoryzacji. Potraktujcie je poważnie, nawet jeśli to tylko ćwiczenie — bo wdrożenia FDE prawie zawsze dzieją się w kontekstach korporacyjnych i musicie rozumieć korporacyjne procesy, korporacyjne logowanie, korporacyjne podejmowanie decyzji i korporacyjne działy IT. To są decyzje, które będziecie musieli wyjaśniać na rozmowach.
Tydzień trzeci. Gdy system stoi, puszczacie przez niego stare sprawy. Próbujecie czyste przypadki, próbujecie brzydkie przypadki — cokolwiek jest prawdziwą pracą. Przepuszczacie to przez zbudowaną pętlę. Patrzycie na porażki, uruchamiacie je ponownie po każdej istotnej zmianie. Siedzicie i doprowadzacie do tego, żeby lokalnie działało na wszystkich przypadkach testowych. Tu wchodzi ten element ewaluacji.
Tydzień czwarty. Pozwalacie dwóm–trzem osobom tego użyć, a sami patrzycie. Uczycie się od nich i poprawiacie pętlę. To jest sedno — ta ostatnia część, część własności. I znowu: widziałem ludzi, którzy speedrunowali cały ten proces w trzy–cztery dni. Może być dużo, dużo szybciej, ale daję wam szansę, żeby wejść głębiej, jeśli to wasze pierwsze podejście.
Na końcu podsumujcie wpływ, który wywarliście. Ile by to nie trwało, powinniście umieć powiedzieć: wszedłem, usiadłem, zobaczyłem, jak pracują prawdziwi ludzie, zmapowałem problemy, zbudowałem to, żeby je naprawić, a kiedy zbudowałem, umiałem wprowadzić to na produkcję i doprowadzić do działania na poziomie korporacyjnym. To jest cała kompetencja FDE.
Skala popytu i droga bez czekania na tytuł
To jest praca, która rośnie wykładniczo. Dziś jest kilka tysięcy FDE, a popyt sięga dziesiątek tysięcy albo nawet setek tysięcy. Anthropic ogłosił niedawno, że DXC przeszkoli dziesiątki tysięcy istniejących inżynierów jako certyfikowanych FDE Claude’a dla banków, linii lotniczych, ubezpieczycieli, producentów i agencji rządowych.
(Informacja dodatkowa: DXC Technology to duża globalna firma usług IT, obsługująca wdrożenia w korporacjach i sektorze publicznym.)
Zwróćcie uwagę na punkt wyjścia. DXC bierze ludzi, którzy już pracują wewnątrz skomplikowanych systemów, i dokłada im szkolenie z AI powiązane z ich branżami. Tego samego podejścia możecie użyć do własnej kariery. Mówiłem, że wiedza dziedzinowa ma znaczenie — bo tło, które przynosicie do stołu, jest jako forward deployed engineer naprawdę ważne. Kontekst branżowy waży bardzo dużo. Jeśli siedzicie głęboko w ochronie zdrowia, nie próbujcie przeskakiwać gdzie indziej. Jeśli siedzicie głęboko w produkcji, nie przeskakujcie. To tam będziecie najskuteczniejszym FDE.
A jeśli jesteście w firmie i zastanawiacie się, jak przejść do tej roli — nie sądzę, żebyście musieli czekać na tytuł. Wystarczy znaleźć ten kawałek pracy, pokazać, że umiecie rozwiązać problem z pomocą AI, i zaczniecie sobie tę drogę wydeptywać.
Skąd to wiem? Ludzie z mojej społeczności zaczepiają mnie na spotkaniach i mówią: „Nate, zobacz, gdzie doszedłem. Dostałem tytuł FDE. Dostałem tytuł AI engineera, bo zrobiłem dokładnie to — wskoczyłem i zacząłem rozwiązywać problemy z AI”. To jest droga naprzód i dlatego mówię o tym z takim przekonaniem. Widziałem, jak to się dzieje raz za razem. Wy też możecie.
FDE będzie niezawodnie gorącą pracą przez najbliższych kilka lat. To nie jest moda. Powód jest bardzo prosty: AI to zdolność ogólnego przeznaczenia, a ostatnia mila w AI jest naprawdę trudna. FDE łączą te dwa brzegi. Dlatego mają znaczenie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Luka między obietnicą autonomii a rekrutacją to sygnał rynkowy
Na czym polega: Laboratoria obiecujące autonomiczną inteligencję jednocześnie masowo rekrutują ludzi do wdrożeń u klientów. Zapowiedź przeszkolenia dziesiątek tysięcy inżynierów zderzyła się z realnymi 86 osobami. Popyt jest ogromny, podaż śladowa.
Jak stosować: Traktujcie tę lukę jako uzasadnienie inwestycji czasu w kompetencje wdrożeniowe — one nie zostaną wchłonięte przez model w najbliższych latach, bo dotyczą ludzi, danych i polityk firmy, a nie generowania tekstu.
Na co uważać: Nie interpretujcie tego jako dowodu, że AI jest słabe. Luka dotyczy ostatniej mili, nie zdolności modeli. Rynek może się nasycić szybciej w krajach, gdzie firmy dopiero zaczynają wdrożenia.
2.Punkt dźwigni ważniejszy niż wybór technologii
Na czym polega: Ten sam miesiąc pracy inżynierskiej może usunąć 1800 dni czekania albo poprawić rzadki przypadek brzegowy. Kompetencją FDE jest wybór miejsca w procesie, gdzie mała implementacja przesuwa najwięcej pracy — przy minimalnym zakresie władzy oddanej modelowi.
Jak stosować: Zanim zaczniecie budować, zróbcie listę wszystkich kandydatów na wdrożenie AI i oceńcie każdy trzema kryteriami: częstotliwość, dotkliwość, ilość pracy odblokowanej dalej w procesie. Wybierzcie ten, który wygrywa na wszystkich trzech.
Na co uważać: Najbardziej spektakularne przypadki (decyzje o wypłacie, wykrywanie wyłudzeń) są zwykle najgorszym pierwszym wyborem — rzadkie, zmienne, obarczone ryzykiem prawnym. Atrakcyjność demonstracyjna to nie to samo co dźwignia.
3.Mgliste hasło prezesa nie jest zadaniem do zbudowania
Na czym polega: „Przyspieszcie szkody z pomocą AI” to nie brief. Jeśli przekażecie to zespołowi technicznemu w tej formie, oddajecie inżynierom wszystkie decyzje produktowe, których sami nie podjęliście.
Jak stosować: Przekładajcie cel zarządu na konkretny, mierzalny wycinek procesu, zanim ktokolwiek napisze linijkę kodu. Dowieźcie briefu z dwoma prawdziwymi przypadkami: jednym szybkim i jednym wolnym, jako kontrprzykładem.
Na co uważać: Zawężenie zakresu trzeba zakomunikować w górę razem z liczbą. Bez „to usuwa 1800 dni czekania miesięcznie” zawężenie brzmi jak wymigiwanie się od ambitnego celu.
4.Zacznij od dziesięciu ostatnich prawdziwych przypadków
Na czym polega: Zamiast analizować całe stanowisko czy proces, wyciąga się ostatnie 10–20 zakończonych spraw, rekonstruuje przebieg, klasyfikuje problemy i robi zgrubną matematykę.
Jak stosować: Zdobądźcie dostęp do surowych, świeżych spraw. Policzcie, ile z nich wpada w każdą kategorię problemu, i przemnóżcie przez utracony czas. Ta liczba wystarczy do porównania kandydatów na wdrożenie — perfekcyjny model finansowy nie jest potrzebny.
Na co uważać: Próbka 10–20 spraw łatwo bywa niereprezentatywna, jeśli wybieracie te, które akurat pamiętacie. Bierzcie ostatnie chronologicznie, nie te ciekawe.
5.Usiądź obok osoby wykonującej pracę
Na czym polega: Znaczna część realnej pracy nie występuje w oficjalnym procesie. Po dniu obserwacji często okazuje się, że połowa zmapowanych bólów jest fikcyjna albo źle opisana.
Jak stosować: Po pierwszej klasyfikacji problemów z danych zaplanujcie obserwację. Wróćcie i świadomie przepiszcie ocenę problemu na podstawie tego, co zobaczyliście — to jest sens ćwiczenia, nie potwierdzenie wstępnej hipotezy.
Na co uważać: Obserwowany może pracować „na pokaz”, jeśli poczuje, że oceniacie jego wydajność albo szukacie okazji do automatyzacji jego stanowiska. Ustawcie ramę rozmowy zawczasu.
6.Wiedza branżowa to twój największy niepodrabialny atut
Na czym polega: Likwidator wie, kiedy kosztorys jest fałszywy. Lider wsparcia wie, że jedno zdanie oznacza natychmiastową eskalację. W badaniu ok. 400 tys. sesji Claude Code eksperci dziedzinowi osiągali zweryfikowany sukces ponad dwa razy częściej niż nowicjusze.
Jak stosować: Celujcie w role FDE w branży, którą już znacie. Ta wiedza jest waszym wejściem do gry i argumentem, którego programista bez tła branżowego nie odtworzy.
Na co uważać: Wiedza branżowa nie przeprowadzi was przez ogłoszenie wymagające produkcyjnej inżynierii oprogramowania. Autor mówi to wprost — nie oszukujcie się w tej kwestii.
7.Ewaluacje to kompetencja techniczna bez kodu
Na czym polega: Skoro modele budują za was, musicie zdefiniować kryteria. Zbiór 50 poprawnie rozstrzygniętych przypadków („brakuje dokumentów” / „nie brakuje”) to podstawowe narzędzie sprawdzania, czy rozwiązanie działa.
Jak stosować: Zbudujcie zbiór testowy z prawdziwych, już rozstrzygniętych spraw, zanim zaczniecie budować. To jednocześnie definicja sukcesu i punkt wyjścia do rozmowy z inżynierami.
Na co uważać: Zbiór testowy zbudowany wyłącznie z czystych przypadków tworzy fałszywe poczucie gotowości. Świadomie dokładajcie brzydkie sprawy — to one wywracają wdrożenie na produkcji.
8.Świetny wynik na plikach nie oznacza działającego wdrożenia
Na czym polega: System może pięknie punktować na archiwalnych aktach i nie zadziałać na żywej pracy. Własność wdrożenia — obserwowanie, korygowanie, kilkukrotne obrócenie koła zamachowego — jest osobną, trzecią częścią roli.
Jak stosować: Zaplanujcie fazę, w której dwie–trzy osoby używają rozwiązania przy was, a wy patrzycie i poprawiacie pętlę. Bez tego etapu portfolio FDE jest niekompletne, a wdrożenie z dużym prawdopodobieństwem umrze.
Na co uważać: Autor stawia wysoką poprzeczkę: jeśli oszczędzacie 20 albo 200 godzin zamiast 2000, uznaje to za sygnał, że nie dotarliście do właściwej dźwigni. To ambitna teza — dla wielu firm 200 godzin miesięcznie to już realny sukces, więc kalibrujcie oczekiwania do skali własnej organizacji.
9.Zaprojektuj minimalny dostęp modelu, zanim zaczniesz budować
Na czym polega: Usługa sprawdzająca kompletność dokumentów potrzebuje wycinka rekordu z przyjęcia szkody. Historia medyczna i dane płatnicze powinny być odcięte, bo model ich nie potrzebuje.
Jak stosować: Przed budową wypiszcie, do jakich danych rozwiązanie faktycznie potrzebuje dostępu, i domyślnie odetnijcie resztę. Ogarnijcie typowe korporacyjne oczekiwania wokół uprawnień, uwierzytelniania i autoryzacji — to są decyzje, które trzeba umieć obronić na rozmowie.
Na co uważać: W epoce AI drobne nieporozumienie wędruje dalej niż kiedyś, bo oprogramowanie nie przesuwa biernie danych — podejmuje decyzje i zapisuje w innych systemach. Traktujcie zakres uprawnień poważnie nawet w ćwiczeniu.
10.Nie czekaj na tytuł — czytaj nazwy stanowisk jak mapę
Na czym polega: „Forward deployed engineer” i „forward deployed software engineer” mają najwyższe wymagania kodowe. „Applied AI engineer”, „customer engineer”, „solutions engineer”, „implementation engineer”, „technical deployment lead” oraz role AI operations i AI product obejmują często tę samą pracę przy innym rozłożeniu wymagań technicznych.
Jak stosować: Traktujcie sąsiednie tytuły jak kamienie w rzece — da się po nich dojść do FDE. Równolegle, wewnątrz obecnej firmy, znajdźcie kawałek pracy i rozwiążcie go z pomocą AI; tytuł zwykle nadchodzi po dowodzie, nie przed nim.
Na co uważać: Czytajcie każde ogłoszenie osobno, bo rozrzut oczekiwań technicznych w tej roli jest bardzo szeroki, a ten sam tytuł w dwóch firmach może oznaczać zupełnie inną pracę. Uwaga też na źródło wielu porad w materiale: autor konsekwentnie kieruje słuchaczy do własnej społeczności i płatnych materiałów.