Przez ostatnie dwa lata porady dotyczące kariery związanej z agentami AI koncentrowały się głównie na tym, jak dobrze je promptować. To już nie jest rzadka umiejętność. Rzadką umiejętnością jest budowanie rusztowania, w którym agent działa — czegoś, co coraz częściej nazywa się harnessem — i jest to na tyle specyficzne i trudne, że staje się osobnym opisem stanowiska, a nie poboczną odpowiedzialnością „osoby od AI” w zespole.

Najbardziej przejrzysty publiczny opis tego, co to faktycznie oznacza w praktyce, pochodzi z Lenny's Newsletter, który opisuje, jak narzędzie do zarządzania produktem ChatPRD zbudowało harness do automatycznego debugowania błędów zgłaszanych przez Sentry. Warto przeczytać ten tekst w całości, jeśli zastanawiasz się nad specjalizacją w tym obszarze, ponieważ zwraca uwagę na coś, co łatwo przeoczyć: model nigdy nie był wąskim gardłem. Zespół wykorzystał Claude Agent SDK jako fundament, a następnie poświęcił większość wysiłku inżynieryjnego na własny interfejs terminalowy oraz zestaw adapterów łączących agenta z Sentry, Linear, GitHub i Vercel. To właśnie ta praca w miniaturze. Cztery systemy, cztery różne schematy autoryzacji, cztery różne struktury danych i interfejs, który pozwala człowiekowi obserwować i interweniować bez konieczności pilnowania każdego kroku.

Na co właściwie rozkłada się „harness”

Jeśli próbujesz ustalić, czy jest to zestaw umiejętności wart rozwijania, warto rozłożyć go na elementy, które są rekrutowane osobno lub przynajmniej oceniane osobno podczas rozmowy kwalifikacyjnej:

  • Projektowanie uprawnień. Decydowanie o tym, co agent może robić bez nadzoru (przeczytać zgłoszenie, przygotować szkic PR) w porównaniu z tym, co wymaga udziału człowieka (scalenie, wdrożenie, usunięcie, wydawanie pieniędzy) — i zakodowanie tego jako faktyczną politykę w kodzie, a nie jako instrukcję w promptcie, którą model może zignorować pod presją. To bliższe inżynierii kontroli dostępu niż pisaniu promptów.
  • Adaptery narzędziowe. Cienkie, dobrze przetestowane wrappery wokół każdego zewnętrznego systemu (Sentry, Linear, GitHub, Vercel lub cokolwiek innego, z czego składa się stos technologiczny twojej firmy), które tłumaczą intencję agenta na bezpieczne, zwalidowane wywołanie API i tłumaczą odpowiedź z powrotem na coś, na czym model może rozumować. To zwykła inżynieria oprogramowania — obsługa błędów, ponowne próby, walidacja schematów — zastosowana do nowego konsumenta.
  • Interfejs terminalowy lub konsolowy. Sposób, w jaki człowiek widzi, co robi agent, zatwierdza lub odrzuca działania i interweniuje, gdy agent utknie. ChatPRD zbudowało własny; wiele zespołów zamiast tego skorzysta z gotowych konsol agentowych, ale i tak ktoś musi zdecydować, co jest pokazywane, co ukryte i co wymaga kliknięcia, zanim się wydarzy.
  • Wybór narzędzi na dużą skalę. Opracowanie z Machine Learning Mastery zwraca uwagę na coś, co warto wiedzieć, jeśli budujesz coś więcej niż demo: dokładność agenta w wywoływaniu narzędzi zwykle spada, gdy katalog narzędzi przekracza mniej więcej tuzin opcji — model zaczyna błędnie wywoływać narzędzia, halucynować parametry lub zawieszać się na błędnych wywołaniach. Wymienione tam sposoby łagodzenia tego problemu (ograniczanie tego, które narzędzia są w ogóle widoczne w danym kontekście, wyszukiwanie narzędzi oparte na retrievalu, kierowanie do wyspecjalizowanych subagentów, jawne kroki planowania, logika awaryjna oraz harnessy benchmarkowe wychwytujące regresje) same w sobie stanowią listę rzeczy, które inżynier harnessu musi umieć wdrożyć, a nie tylko o nich wiedzieć.
  • Inżynieria kontekstu i pamięci. To samo źródło zwraca uwagę na rozróżnienie warte wewnętrznego przyswojenia: inżynieria kontekstu (co trafia do pojedynczego wywołania inferencji i gdzie) oraz inżynieria pamięci (co utrzymuje się między sesjami, jak jest przechowywane, jak jest odzyskiwane) to różne dyscypliny z różnymi trybami awarii. Teza tego źródła jest taka, że większość awarii w długotrwałych, wielosesyjnych agentach wynika z mylenia tych dwóch rzeczy — traktowania pamięci sesji jako po prostu kolejnego kontekstu, albo odwrotnie — zwłaszcza w momencie, gdy system decyduje, co odzyskać.

Dowody na to, że jest to prawdziwa, finansowalna rola — a nie tylko nisza dla hobbystów

Sceptycy słusznie mogą zapytać, czy „inżynier harnessu” to praca, czy tylko zadanie w ramach czyjegoś innego stanowiska. Dwa punkty danych z przeglądu sugerują, że sytuacja zmierza w tę pierwszą stronę. Po pierwsze, zespół Aspire w Microsofcie — liczący 10 osób — użył GitHub's Agentic Workflows do automatyzacji dokumentacyjnych PR-ów obejmujących wiele repozytoriów i w ciągu dwóch wydań scalił 82 PR-y w medianie 44,8 godziny od momentu wdrożenia odpowiadającego im PR-a produktowego, bez zwiększania zatrudnienia i bez przeszkolenia procesowego. To mały zespół osiągający nieproporcjonalną dźwignię właśnie dlatego, że ktoś zainwestował w rusztowanie (definicje przepływów pracy, kierowanie recenzji, logikę wyzwalaczy), zamiast każąc inżynierom ręcznie pisać PR-y z dokumentacją. Po drugie, projekt SkillOpt z Microsoft Research traktuje pliki „umiejętności” agenta — instrukcje i ograniczenia kształtujące zachowanie agenta w jego harnessie — jako coś, co należy systematycznie optymalizować, a nie edytować ręcznie, i raportuje, że był najlepszy lub ex aequo najlepszy we wszystkich 52 komórkach siatki benchmarkowej (sześć benchmarków, siedem modeli, trzy tryby wykonania), przy czym zoptymalizowane umiejętności przenosiły się między różnymi modelami i różnymi harnessami. Niezależnie od tego, czy to konkretne narzędzie stanie się standardem, sygnalizuje to, że branża zaczyna traktować konfigurację harnessu jako artefakt inżynierski z własnym narzędziem i benchmarkami — ta sama trajektoria, która zmieniła „DevOps” z zestawu doraźnych skryptów w dyscyplinę.

Powstaje też infrastruktura budowana wprost z myślą o tej warstwie. Niedawno ogłoszone przez Google możliwości „Managed Agents” w Gemini API — wykonanie w tle i asynchroniczne, integracja ze zdalnymi serwerami MCP, niestandardowe wywoływanie funkcji, odświeżanie poświadczeń między interakcjami — to w praktyce gotowa instalacja hydrauliczna dla dokładnie tych problemów, które zespół ChatPRD rozwiązał ręcznie. To typowy schemat: to, co jeden zespół buduje na zamówienie w tym roku, dostawca platformy urynkowi w przyszłym roku. Nie eliminuje to roli inżyniera harnessu; podnosi poprzeczkę i przesuwa pracę w stronę integrowania i konfigurowania zarządzanych prymitywów, zamiast pisania każdego adaptera od zera — podobnie jak infrastruktura chmurowa nie wyeliminowała inżynierów operacyjnych, lecz zmieniła to, na co poświęcali czas.

Co to oznacza, jeśli celujesz w tę rolę

Kilka konkretnych, sprawdzalnych rzeczy, które warto umieścić w portfolio lub CV, jeśli chcesz być wiarygodny w tej pracy: zbuduj jeden adapter od początku do końca dla prawdziwego API, nad którym nie masz kontroli (z autoryzacją, obsługą błędów i limitami zapytań włącznie, a nie demo na ścieżce bezbłędnej); zaprojektuj i udokumentuj model uprawnień dla agenta, który rozróżnia działania typu odczyt/propozycja/działanie i pokazuje, dlaczego każda granica znajduje się właśnie tam, gdzie się znajduje; oraz zbuduj lub skonfiguruj interfejs recenzji, w którym człowiek zatwierdza działania agenta przed ich wykonaniem, ponieważ na tym elemencie będzie nalegać większość firm, zanim pozwolą agentowi dotknąć produkcji. Jeśli oceniasz ofertę pracy w zakresie inżynierii harnessu albo określasz zakres własnych obowiązków, zapytaj konkretnie, kto jest właścicielem modelu uprawnień, kto jest właścicielem adapterów, a kto jest właścicielem powierzchni recenzji przez człowieka — w wielu zespołach obecnie te trzy rzeczy nie mają jasnego właściciela, co jest dokładnie tą luką, którą ta rola zaczyna wypełniać.

Warto jasno zaznaczyć jedno zastrzeżenie: żadne z powyższych źródeł nie ustala liczby dotyczącej rynku pracy dla tego konkretnego stanowiska, a „inżynier harnessu” to jeszcze nie tytuł, który zobaczysz w ogłoszeniach — pojawia się w ramach tytułów takich jak „inżynier infrastruktury AI”, „inżynier platformy agentowej” czy po prostu „starszy inżynier backendu, systemy AI”. Traktuj to jako zestaw umiejętności do zbudowania i dokładnego opisania, a nie tytuł do wyszukiwania na LinkedInie.