Poslednje dve godine, saveti za karijeru u vezi sa AI agentima uglavnom su se svodili na to kako ih dobro promptovati. To više nije oskudna veština. Oskudna veština danas je izgradnja infrastrukture unutar koje agent funkcioniše — stvar koja se sve češće naziva harness — i to je dovoljno specifično i dovoljno teško da postaje sopstveni opis posla, a ne sporedna odgovornost „AI osobe” u timu.

Najjasniji javno dostupan prikaz onoga što ovo zapravo podrazumeva dolazi iz Lenny's Newsletter-a, koji opisuje kako je alat za upravljanje proizvodom ChatPRD napravio harness koji automatski otklanja Sentry greške. Vredi pročitati ceo tekst ako razmišljate da li da se specijalizujete u ovoj oblasti, jer on ističe nešto što se lako previdi: model nikada nije bio usko grlo. Tim je kao osnovu koristio Claude Agent SDK, a zatim je najveći deo inženjerskog truda uložio u prilagođeni terminalski UI i skup adaptera koji povezuju agenta sa Sentry-jem, Linear-om, GitHub-om i Vercel-om. To je taj posao, u malom. Četiri sistema, četiri različite šeme autentifikacije, četiri različita oblika podataka i UI koji čoveku omogućava da posmatra i interveniše bez potrebe da nadgleda svaki korak.

Na šta se zapravo svodi „harness”

Ako pokušavate da utvrdite da li je ovo skup veština vredan razvijanja, korisno je podeliti ga na delove za koje se posebno zapošljava, ili se bar posebno ocenjuju na razgovoru za posao:

  • Dizajn dozvola. Odlučivanje šta agent sme da radi bez nadzora (pročita tiket, napravi nacrt PR-a) naspram onoga za šta je potreban čovek u petlji (spajanje, deploy, brisanje, trošenje novca) — i kodiranje toga kao stvarne politike u kodu, a ne kao instrukcije u promptu koju model može zanemariti pod pritiskom. Ovo je bliže inženjeringu kontrole pristupa nego pisanju prompta.
  • Adapteri za alate. Tanki, dobro testirani omotači oko svakog eksternog sistema (Sentry, Linear, GitHub, Vercel, ili šta god da je tehnološki stek vaše kompanije) koji prevode nameru agenta u bezbedan, validiran API poziv, a odgovor prevode nazad u nešto o čemu model može da rezonuje. Ovo je obično softversko inženjerstvo — obrada grešaka, ponovni pokušaji, validacija šeme — primenjeno na novog korisnika.
  • Terminalski ili konzolni UI. Način da čovek vidi šta agent radi, odobri ili odbije akcije i umeša se kada agent zapne. ChatPRD je napravio prilagođeno rešenje; mnogi timovi će umesto toga koristiti gotove konzole za agente, ali neko i dalje mora da odluči šta se prikazuje, šta se skriva i šta zahteva klik pre nego što se izvrši.
  • Izbor alata u velikom obimu. Tekst sa Machine Learning Mastery ukazuje na nešto vredno znanja ako gradite bilo šta ozbiljnije od demoa: preciznost agenta pri pozivanju alata teži da opada čim katalog alata pređe otprilike desetak opcija — model počinje pogrešno da poziva alate, izmišlja parametre ili zapinje na lošim pozivima. Mere ublažavanja koje se navode (ograničavanje koji su alati uopšte vidljivi u datom kontekstu, pretraga alata zasnovana na dohvatanju, usmeravanje ka specijalizovanim pod-agentima, eksplicitni koraci planiranja, logika rezervnih rešenja i benchmark harness-i za hvatanje regresija) sami po sebi predstavljaju spisak stvari koje inženjer harness-a mora znati da implementira, a ne samo da zna da postoje.
  • Inženjering konteksta i memorije. Isti izvor pravi razliku koju vredi usvojiti: inženjering konteksta (šta ulazi u jedan poziv za inferenciju i gde) i inženjering memorije (šta se čuva između sesija, kako se skladišti, kako se dohvata) su različite discipline sa različitim načinima na koje mogu da otkažu. Tvrdi se da većina otkazivanja kod dugotrajnih agenata koji rade kroz više sesija potiče od mešanja ova dva pojma — tretiranja memorije sesije kao da je samo dodatni kontekst, ili obrnuto — posebno u trenutku kada sistem odlučuje šta da dohvati.

Dokazi da je ovo stvarna, finansijski isplativa uloga — a ne samo niša za hobiste

Skeptici će opravdano pitati da li je „inženjer harness-a” posao ili samo zadatak unutar nečijeg drugog posla. Dva podatka iz zbirke sugerišu da se stvari kreću ka prvom. Prvo, Microsoft-ov Aspire tim — grupa od 10 ljudi — koristio je GitHub-ove Agentic Workflows da automatizuje PR-ove za dokumentaciju koji obuhvataju više repozitorijuma, i tokom dva izdanja spojio je 82 PR-a sa medijanom od 44,8 sati nakon što je odgovarajući PR proizvoda objavljen, bez novog zapošljavanja i bez preobuke procesa. To je mali tim koji ostvaruje nesrazmerno veliki uticaj upravo zato što je neko uložio u infrastrukturu (definicije workflow-a, usmeravanje pregleda, logiku okidača) umesto da inženjeri ručno pišu PR-ove za dokumentaciju. Drugo, projekat SkillOpt iz Microsoft Research-a tretira „skill” fajlove agenata — instrukcije i ograničenja koji oblikuju kako se agent ponaša unutar svog harness-a — kao nešto što treba sistematski optimizovati, a ne ručno menjati, i izveštava da je bio najbolji ili izjednačeno najbolji u svih 52 ćelije mreže benchmark-a (šest benchmarkova, sedam modela, tri režima izvršavanja), pri čemu su optimizovani skill-ovi prenosivi na različite modele i različite harness-e. Bez obzira na to da li će taj konkretan alat postati standard, on ukazuje da industrija počinje da tretira konfiguraciju harness-a kao inženjerski artefakt sa sopstvenim alatima i benchmark-ovima — istu putanju koja je „DevOps” pretvorila iz skupa improvizovanih skripti u disciplinu.

Sada se gradi i infrastruktura namenjena izričito ovom sloju. Google-ove novoobjavljene mogućnosti „Managed Agents” u Gemini API-ju — izvršavanje u pozadini i asinhrono izvršavanje, integracija sa udaljenim MCP serverima, prilagođeno pozivanje funkcija, obnavljanje kredencijala tokom interakcija — praktično predstavljaju unapred izgrađenu instalaciju za tačno one probleme koje je tim ChatPRD-a rešio ručno. To je uobičajen obrazac: ono što jedan tim ove godine gradi po meri, dobavljač platforme sledeće godine pretvara u proizvod. To ne ukida ulogu inženjera harness-a; podiže minimum i pomera posao ka integrisanju i konfigurisanju upravljanih primitiva umesto pisanja svakog adaptera od nule, slično kao što cloud infrastruktura nije ukinula ops inženjere, već je promenila na šta troše svoje vreme.

Šta ovo znači ako ciljate na ovu ulogu

Nekoliko konkretnih, proverljivih stvari koje treba staviti u portfolio ili biografiju ako želite da budete verodostojni za ovaj posao: izgradite jedan adapter od početka do kraja naspram stvarnog API-ja koji ne kontrolišete (uključujući autentifikaciju, obradu grešaka, ograničenja broja zahteva, a ne demo koji prikazuje samo idealan scenario); osmislite i dokumentujte model dozvola za agenta koji razlikuje akcije čitanja/predlaganja/izvršavanja i objašnjava zašto se svaka granica nalazi baš tamo gde jeste; i izgradite ili konfigurišite interfejs za pregled u kome čovek odobrava akcije agenta pre nego što se one izvrše, jer je to deo na kome će većina kompanija insistirati pre nego što dozvole agentu da dodirne produkciju. Ako procenjujete ponudu za posao inženjera harness-a ili definišete sopstvene odgovornosti, konkretno pitajte ko je vlasnik modela dozvola, ko je vlasnik adaptera, a ko je vlasnik površine za ljudski pregled — u mnogim timovima trenutno te tri stvari nemaju jasnog vlasnika, a to je upravo praznina koju ova uloga nastaje da popuni.

Jedna napomena vredna jasnog isticanja: nijedan od gore navedenih izvora ne utvrđuje konkretan broj na tržištu zapošljavanja za ovu tačno određenu titulu, a „inženjer harness-a” još uvek nije naziv posla koji ćete videti u oglasima — on se pojavljuje unutar titula poput „AI infrastructure engineer”, „agent platform engineer”, ili prosto „senior backend engineer, AI systems”. Ovo tretirajte kao skup veština koje treba razviti i tačno opisati, a ne kao titulu koju treba tražiti na LinkedIn-u.