Poslední dva roky se kariérní rady ohledně AI agentů točily většinou kolem toho, jak je naučit dobře promptovat. To už dnes není nedostatková dovednost. Nedostatkovou dovedností je stavba scaffoldingu, ve kterém agent funguje – tomu se čím dál víc říká harness – a je natolik specifická a natolik náročná, že se z ní stává samostatná pracovní pozice, nikoli jen vedlejší odpovědnost „AI člověka" v týmu.

Nejjasnější veřejně dostupný popis toho, co to vlastně obnáší, pochází z Lenny's Newsletter, který dokumentuje, jak nástroj pro produktový management ChatPRD postavil harness na automatické ladění chyb ze Sentry. Pokud zvažujete, zda se na tuto oblast specializovat, stojí za to si ten článek přečíst celý, protože obsahuje bod, který se snadno přehlédne: model nikdy nebyl tím, co brzdilo. Tým jako základ použil Claude Agent SDK a většinu inženýrského úsilí pak věnoval vlastnímu terminálovému UI a sadě adaptérů propojujících agenta se Sentry, Linear, GitHub a Vercel. To je ta práce v miniatuře. Čtyři systémy, čtyři různá autentizační schémata, čtyři různé datové struktury a UI, které člověku umožní sledovat dění a zasáhnout, aniž by musel hlídat každý krok.

Co se pod pojmem „harness" ve skutečnosti skrývá

Pokud se snažíte zjistit, jestli je tohle soubor dovedností, který stojí za budování, pomůže rozdělit si ho na části, které se najímají zvlášť – nebo se přinejmenším zvlášť hodnotí u pohovoru:

  • Návrh oprávnění. Rozhodování o tom, co smí agent dělat bez dohledu (přečíst tiket, navrhnout PR) oproti tomu, co vyžaduje člověka v procesu (sloučit, nasadit, smazat, utratit peníze) – a zakódování tohoto rozhodnutí jako skutečné politiky v kódu, nikoli jako promptové instrukce, kterou model může za tlaku ignorovat. Tohle má blíž k inženýrství řízení přístupu než k psaní promptů.
  • Adaptéry nástrojů. Tenké, dobře otestované obálky kolem každého externího systému (Sentry, Linear, GitHub, Vercel nebo cokoliv tvoří stack vaší firmy), které převádějí záměr agenta na bezpečné, ověřené volání API a odpověď zpět převádějí do podoby, se kterou dokáže model pracovat. Jde o běžné softwarové inženýrství – ošetření chyb, opakované pokusy, validace schématu – aplikované na nového konzumenta.
  • Terminálové nebo konzolové UI. Způsob, jak člověk vidí, co agent dělá, může akce schválit nebo zamítnout a zasáhnout, když agent uvízne. ChatPRD si postavil vlastní; spousta týmů místo toho použije hotové agentní konzole, ale i tak musí někdo rozhodnout, co se zobrazí, co se skryje a co vyžaduje kliknutí, než se to stane.
  • Výběr nástrojů ve velkém měřítku. Článek od Machine Learning Mastery upozorňuje na něco, co stojí za to vědět, pokud stavíte cokoliv nad rámec dema: přesnost agenta při volání nástrojů má tendenci klesat, jakmile katalog nástrojů překročí zhruba tucet možností – model pak začíná volat špatné nástroje, halucinovat parametry nebo se zaseknout na chybných voláních. Zmíněná zmírnění (omezení, které nástroje jsou v daném kontextu vůbec vidět, vyhledávání nástrojů založené na retrievalu, směrování na specializované subagenty, explicitní kroky plánování, záložní logika a benchmarkové harnessy pro odhalení regresí) jsou sama o sobě checklistem věcí, které musí inženýr harnessu umět implementovat, ne jen o nich vědět.
  • Context a memory engineering. Tentýž zdroj rozlišuje mezi dvěma věcmi, které stojí za to si osvojit: context engineering (co vstupuje do jednoho volání inference a kam) a memory engineering (co přetrvává napříč sezeními, jak se to ukládá, jak se to znovu vyhledává) jsou odlišné disciplíny s odlišnými způsoby selhání. Tvrdí se v něm, že většina poruch u dlouhodobě běžících, víceseanceových agentů pramení z toho, že se tyto dvě věci pletou dohromady – že se s pamětí sezení zachází, jako by šlo jen o další kontext, nebo naopak – zejména v okamžiku, kdy systém rozhoduje, co má vyhledat.

Důkazy, že jde o skutečnou, financovatelnou roli – ne jen o koníček

Skeptici se rozumně zeptají, jestli je „harness engineer" skutečná práce, nebo jen úkol v rámci něčí jiné pracovní náplně. Dva poznatky z přehledu naznačují, že se to posouvá k tomu prvnímu. Zaprvé, tým Aspire od Microsoftu – deset lidí – použil GitHubovy Agentic Workflows k automatizaci PR s dokumentací napříč repozitáři a za dvě vydání sloučil 82 PR v mediánu 44,8 hodiny po vydání odpovídajícího produktového PR, a to bez nových lidí a bez přeškolování procesů. To je malý tým, který získává neúměrně velkou páku právě proto, že někdo investoval do scaffoldingu (definic workflow, směrování revizí, spouštěcí logiky), místo aby inženýři psali dokumentační PR ručně. Zadruhé, projekt SkillOpt od Microsoft Research přistupuje k souborům „skills" agenta – instrukcím a omezením, které formují chování agenta v jeho harnessu – jako k něčemu, co se má systematicky optimalizovat, ne ručně upravovat, a uvádí, že byl nejlepší nebo srovnatelně nejlepší ve všech 52 buňkách benchmarkové mřížky (šest benchmarků, sedm modelů, tři režimy provádění), přičemž optimalizované skills se přenášely mezi různými modely i různými harnessy. Ať už se z tohoto konkrétního nástroje stane standard, nebo ne, signalizuje to, že odvětví začíná chápat konfiguraci harnessu jako inženýrský artefakt s vlastním tooling a benchmarky – stejná trajektorie, jaká z „DevOps" udělala z hromady ad hoc skriptů samostatnou disciplínu.

Existuje také infrastruktura, která se teď staví přímo pro tuto vrstvu. Nově oznámené schopnosti „Managed Agents" v Gemini API od Googlu – běh na pozadí a asynchronní vykonávání, integrace vzdálených MCP serverů, vlastní volání funkcí, obnovování přihlašovacích údajů napříč interakcemi – jsou v podstatě předpřipravené instalatérství pro přesně ty problémy, které tým ChatPRD řešil ručně. Je to normální vzorec: co si jeden tým letos postaví na míru, to příští rok platforma zabalí do produktu. Roli harness engineera to neruší; zvedá to laťku a posouvá tu práci směrem k integraci a konfiguraci spravovaných primitiv, místo psaní každého adaptéru od nuly – podobně jako cloudová infrastruktura nezrušila provozní inženýry, jen změnila, čemu věnují svůj čas.

Co to znamená, pokud míříte na tuto roli

Pár konkrétních, ověřitelných věcí, které stojí za zařazení do portfolia nebo životopisu, pokud chcete být pro tuto práci důvěryhodní: postavte jeden adaptér od začátku do konce proti reálnému API, které nemáte pod kontrolou (včetně autentizace, ošetření chyb a rate limitů, ne jen demo s ideálním průběhem); navrhněte a zdokumentujte model oprávnění pro agenta, který rozlišuje akce typu přečíst/navrhnout/jednat a ukazuje, proč je každá hranice tam, kde je; a postavte nebo nakonfigurujte revizní rozhraní, kde člověk schvaluje akce agenta předtím, než se provedou, protože na tomhle bude trvat většina firem, než agentovi dovolí sáhnout na produkci. Pokud zvažujete nabídku na pozici harness engineera nebo si vymezujete vlastní odpovědnosti, zeptejte se konkrétně, kdo vlastní model oprávnění, kdo vlastní adaptéry a kdo vlastní rozhraní pro lidskou revizi – u spousty týmů teď tyto tři věci nemají jasného vlastníka, a přesně tuhle mezeru má tato role za úkol zaplnit.

Jedna výhrada, kterou stojí za to říct otevřeně: žádný z výše uvedených zdrojů neuvádí konkrétní číslo z trhu práce pro tento konkrétní titul a „harness engineer" zatím není pracovní titul, který byste viděli v nabídkách – objevuje se uvnitř titulů jako „AI infrastructure engineer", „agent platform engineer" nebo prostě „senior backend engineer, AI systems". Berte to jako soubor dovedností, které se má budovat a přesně popisovat, ne jako titul, který se má hledat na LinkedIn.