AI engineer, ML engineer, product engineer, FDE: czego naprawdę wymagają ogłoszenia o pracę w AI w 2026

TL;DR: We wrześniu 2026 przeczytałem około 520 ogłoszeń o zdalnej pracy dla inżynierów: 274 polskie ogłoszenia zdalne na B2B w całości oraz 246 ogłoszeń zagranicznych firm, które zatrudniają zdalnie. Najczęstszym terminem w obu zbiorach było observability, a za granicą wyprzedzało ono każdy termin z AI z dużym zapasem. W polskich ogłoszeniach słownictwo AI otwierają RAG i agenci AI, MCP pojawia się często, a agenci kodujący występują z nazwy: GitHub Copilot, Claude Code, Cursor. LLM evals pojawiają się tylko cztery razy, zawsze w najlepiej płatnych rolach. "ML engineer" prawie zawsze oznacza pracę nad modelami w Pythonie, "AI engineer" to budowanie produktów na istniejących modelach, "product engineer" sygnalizuje odpowiedzialność za całość i częściej pojawia się za granicą, a Forward Deployed Engineer to rola rzadka, ale prawdziwa. Tylko dwa procesy rekrutacyjne miały etap sprawdzający, jak pracujesz z AI.

Dlaczego przeczytałem 520 ogłoszeń o pracę

Codziennie buduję i prowadzę własne produkty z agentami kodującymi. Przez ostatnie miesiące nazbierało mi się sporo nawyków, których nigdy nie nazwałem: sposób ładowania kontekstu osobno dla każdego projektu, zabezpieczenia wokół autonomicznego agenta, harness ewaluacyjny za funkcją dopasowywania. Rynek ma na te rzeczy nazwy, bo używają ich ogłoszenia i rozmowy rekrutacyjne. Przeczytałem więc ogłoszenia, żeby sprawdzić, gdzie mój sposób pracy pokrywa się z tym, co rynek nazywa, a gdzie nie.

Drugim powodem były tytuły stanowisk. "AI engineer", "ML engineer", "AI solutions engineer", "product engineer", "forward deployed engineer": chciałem wiedzieć, które z nich opisują różne zawody, a które to ta sama praca pod inną etykietą.

Jak liczyłem i czego te liczby nie powiedzą

Miałem trzy możliwości: wyszukiwanie po słowach kluczowych w dużym serwisie z ofertami, ręczne przeczytanie kilkudziesięciu ogłoszeń albo pobranie pełnych treści i policzenie terminów. Wyszukiwanie po słowach kluczowych zawyża to, czego szukasz. Ręczna lektura nie skaluje się powyżej próbki. Wybrałem pełne treści i proste liczenie, a ogłoszenia stojące za ciekawymi liczbami przeczytałem ręcznie.

• Zbiór polski: 274 zdalne ogłoszenia na B2B z kategorii fullstack, frontend, backend i AI z dużego polskiego serwisu, przeczytane w całości (wymagania, zadania, opis).
• Zbiór zagraniczny: 246 ogłoszeń dla inżynierów od firm spoza Polski, które zatrudniają zdalnie.
• Liczenie: liczba oznacza, ile ogłoszeń wspomina termin co najmniej raz, a nie ile razy się on pojawia.
• Wykluczone: niewielki zbiór ogłoszeń, które znalazłem w innym serwisie, szukając bezpośrednio nazw narzędzi. Zawyżyłyby każdą liczbę związaną z AI, więc nie ma ich w tabeli.

Zanim przejdziesz do tabeli, warto znać ograniczenia. Liczenie to dopasowywanie wzorców, więc wzmianka nie jest wymaganiem: ogłoszenie może wymieniać narzędzie w stacku, choć nikt go nie używa. To obraz jednego miesiąca. Surowe dane miały też własne pułapki. Jeden serwis zwraca osobny rekord dla każdego miasta, więc jedno ogłoszenie mogło pojawić się 17 razy przed deduplikacją, a wynagrodzenia przychodziły w czterech walutach i za cztery różne okresy rozliczeniowe. Większość ogłoszeń zagranicznych w ogóle nie podaje wynagrodzenia (widełki miało 41 z 246), więc wszystko, co mówię o stawkach, pochodzi wyłącznie z polskiej strony.

Jakie terminy z AI najczęściej pojawiają się w ogłoszeniach?

Co się wyróżniło:

• Observability to najczęstszy termin ogółem: 65 ogłoszeń w obu zbiorach. Observability to logi, metryki i trace'y, dzięki którym da się odtworzyć, co się stało w działającym systemie. To także jeden z zaledwie trzech terminów, które pojawiają się wyraźnie częściej za granicą, obok embeddings i product mindset.
• RAG i agenci AI otwierają polskie słownictwo AI. RAG, czyli retrieval-augmented generation, oznacza, że model dostaje fragmenty wyszukane w Twoich własnych danych, zamiast odpowiadać z pamięci. Agent AI to program, który sam decyduje o kolejnych krokach i wywołuje narzędzia, w odróżnieniu od pojedynczego wywołania modelu. Agenci AI to jeden z nielicznych terminów z AI, które są podobnie częste po obu stronach.
• MCP to na razie polski fenomen: 14 ogłoszeń wobec 2. MCP to otwarty protokół, przez który agent łączy się z zewnętrznymi narzędziami i danymi. Pięć polskich ogłoszeń idzie dalej i pyta o pisanie własnych serwerów, a nie tylko o korzystanie z nich.
• Agentów kodujących wymienia się z nazwy. W zbiorze polskim prowadzi GitHub Copilot (13 ogłoszeń), tuż za nim są Claude Code (12) i Cursor (10). Za granicą Cursor i Copilot idą łeb w łeb. Windsurf nie pojawił się ani razu po żadnej stronie, podobnie jak Kiro, Devin i Aider.
• Evals są rzadkie i drogie. LLM evals, czyli stały zbiór przykładów z oczekiwanymi odpowiedziami i metrykami, który uruchamiasz ponownie po każdej zmianie, pojawiają się cztery razy w Polsce i ani razu w zbiorze zagranicznym. Wszystkie cztery ogłoszenia były na szczycie widełek.
• Context engineering to wciąż nisza: trzy polskie ogłoszenia. Context engineering to projektowanie tego, co i kiedy trafia do okna kontekstu modelu: co ładuje się zawsze, co na żądanie, a co nigdy. Tam, gdzie się pojawia, prawie zawsze występuje w parze z prompt engineeringiem.

ML engineer, AI engineer, product engineer, FDE: czym się różnią?

Po przeczytaniu ogłoszeń stojących za liczbami wyłaniają się cztery odrębne zawody, a tytuły pasują do nich czyściej, niż się spodziewałem.

ML engineer. "Machine learning" to najczęstszy pojedynczy termin z AI w zbiorze polskim (31 ogłoszeń) i pułapka dla każdego, kto buduje produkty na modelach. Prawie zawsze oznacza rolę w Pythonie przy trenowaniu i serwowaniu modeli. Potwierdza to sąsiednie słownictwo: deep learning, NLP, kwantyzacja i LoRA pojawiają się w 9 polskich ogłoszeniach, a rodzina LangChain występuje w 10 polskich ogłoszeniach niemal wyłącznie w rolach pythonowych.

AI engineer. Buduje produkty na istniejących modelach: RAG, agenci, tool use, MCP, zabezpieczenia, evals. Tool use, czyli function calling, to wzorzec, w którym model zamiast prozy zwraca wywołanie funkcji ze ścisłym schema argumentów; na tym opiera się każdy agent. Wśród 69 ogłoszeń, które wymieniały agenta kodującego AI jako wymaganie albo dodatkowy atut, najczęstsze tytuły to Fullstack Developer (11) i Software Engineer (8), potem AI Engineer (4), AI Solutions Engineer (4), Enterprise AI Architect (3) i Product Engineer (3). Te 69 obejmuje ogłoszenia znalezione celowanym wyszukiwaniem, więc zawyża bazowy odsetek. Najlepiej płatne ogłoszenia w tej grupie opisywały rolę, której cała treść sprowadzała się do budowania umiejętności wielokrotnego użytku dla agenta kodującego, a kilka z nich wyglądało na ten sam projekt wystawiony przez różnych pośredników.

Product engineer. Ten tytuł mniej mówi o stacku, a bardziej o odpowiedzialności za problem od początku do końca. "Product mindset" albo "ownership" pojawia się w 7 ogłoszeniach zagranicznych i 2 polskich, czyli za granicą mniej więcej trzy i pół raza częściej. Sformułowania o "własnym produkcie" albo projektach pobocznych pasowały do 14 polskich ogłoszeń, ale prawie wszystkie odnosiły się do produktu firmy. Dokładnie jedno ogłoszenie mówiło, że własny, wdrożony projekt poboczny to atut.

Forward Deployed Engineer. Inżynier, który pracuje bezpośrednio z klientem i buduje rozwiązanie w jego środowisku, zamiast brać zadania z backlogu. Tytuł wywodzi się z oprogramowania do danych dla dużych firm, a teraz przejmują go firmy budujące na LLM. Pojawił się dwa razy w zbiorze polskim i ani razu w zagranicznym, więc istnieje, ale jest rzadki. Tytuły, których szukałem celowo i nie znalazłem ani razu: "AI Product Engineer" i "AI Product Builder".

Jak firmy sprawdzają umiejętności AI w rekrutacji?

Siedem z ogłoszeń, które czytałem dokładnie, opisywało proces rekrutacji. Większość miała znajomy kształt: rozmowa z rekruterem, od jednej do trzech rozmów technicznych, rozmowa z managerem albo klientem. Dwa się wyróżniały, bo zawierały osobny etap sprawdzający, jak pracujesz z AI:

• Case biznesowy z AI, który prezentujesz. Dostajesz problem biznesowy, rozwiązujesz go z pomocą narzędzi AI, a potem prezentujesz wynik i o nim dyskutujesz. To pokaz tego, jak prowadzisz agenta, a nie zagadka algorytmiczna.
• Osobna runda sprawdzająca umiejętności AI, umieszczona zaraz po rozmowie z HR, przed jakąkolwiek rozmową z managerem.

Jeden proces poszedł w przeciwną stronę i wprost zapowiadał, że AI nie jest używane do selekcji kandydatów, prowadzenia rozmów ani komunikacji z nimi. To samo w sobie przydatna informacja.

Gdzie moja praca się pokryła, a gdzie nie

Najbardziej przydatne okazało się przejście termin po terminie przez mój własny setup. Kilka rzeczy, które robię codziennie, miało nazwy, których nie używałem: agent harness (uprawnienia, hooki i blokady, w których działa agent; opisałem zabezpieczenia, których używam), context engineering (to, co nazywałem ładowaniem kontekstu per projekt, opisane tutaj), spec-driven development (spisana specyfikacja w repo, którą agent wykonuje i która przechodzi przegląd), tool use i orkiestracja wielu agentów.

Najmocniejsze pokrycie dotyczyło najrzadszego terminu. Funkcja dopasowywania w jednym z moich produktów ma harness ewaluacyjny: golden set (zbiór wzorcowy) zbudowany z decyzji administratorów i opinii użytkowników, pulę do ręcznego etykietowania oraz metryki wyszukiwania informacji, takie jak precision at 10, NDCG, MRR i recall, wersjonowane tak, żeby dało się porównywać zmiany w pipeline. Część pracy nad progami opisałem w tekście o strojeniu progów w pgvector. Cztery ogłoszenia prosiły dokładnie o to, a ja nigdy nie nazwałem tego eval harnessem.

Luki były równie wyraźne. Nie używam LangChaina ani jego krewnych; orkiestracja w mojej pracy odbywa się na poziomie agentów i MCP. A w observability, najczęstszym terminie ze wszystkich, moje produkty miały analitykę produktową i logi platformy, ale nie stronę inżynierską: ustrukturyzowane logi z request ID, śledzenie błędów, tracing. Tę lukę zamknąłbym jako pierwszą.

Jeszcze jedno spostrzeżenie, które idzie pod prąd hype'u: w zbiorze polskim najlepiej płatne ogłoszenia frontendowe nie miały żadnego wymagania związanego z AI. Role zbudowane wokół agentów kodujących płaciły dobrze, a czyste role reactowe w finansach płaciły więcej.

Co to oznacza dla inżynierów i dla osób zatrudniających

Dla inżynierów:

• Nazwij to, co już robisz. Agent harness, context engineering, spec-driven development, tool use, evals. To słownictwo decyduje, czy Twoje doświadczenie zostanie dopasowane do ogłoszenia.
• Traktuj observability jako oczywistość, zwłaszcza w firmach zagranicznych. Pojawia się częściej niż jakikolwiek termin z AI.
• Evals to wyróżnik. Rzadkie w ogłoszeniach, zawsze na szczycie widełek i trudne do udawania na rozmowie.
• Nie myl ról ML z rolami produktowymi w AI. Jeśli budujesz na modelach, a nie je trenujesz, "machine learning" w tytule zwykle oznacza inną pracę.
• Bądź gotów prowadzić agenta na żywo. Dwa procesy już to sprawdzają, a formatem jest case, który prezentujesz.

Dla osób zatrudniających:

• "AI-assisted development" mówi bardzo mało. To najczęstsze sformułowanie i zarazem najbardziej mgliste. Nazwij konkretną pracę: budowanie serwerów MCP, prowadzenie evals, projektowanie kontekstu.
• Sprawdź umiejętność w procesie, tak jak robią to dwa opisane wyżej procesy, zamiast o nią pytać.
• Napisz "ownership", jeśli naprawdę o to chodzi. Product engineerowie tego szukają, a większość polskich ogłoszeń to pomija.
• Opublikuj widełki. Pięć na sześć ogłoszeń zagranicznych w moim zbiorze tego nie zrobiło, przez co trudno je z czymkolwiek porównać.