Viimeiset kaksi vuotta tekoälyagentteihin liittyvät uraneuvot ovat pääasiassa käsitelleet sitä, miten niitä opitaan kehottamaan (promptaamaan) hyvin. Se ei ole enää harvinainen taito. Harvinainen taito on rakentaa se tukirakenne, jonka sisällä agentti toimii — asia, jota kutsutaan yhä useammin nimellä harness — ja se on niin spesifi ja niin vaikea, että siitä on tulossa oma tehtävänkuvansa sen sijaan, että se olisi tiimin "tekoälyihmisen" sivutehtävä.

Selkein julkinen läpikäynti siitä, mitä tämä käytännössä tarkoittaa, löytyy Lenny's Newsletteristä, joka dokumentoi, miten tuotehallinnan työkalu ChatPRD rakensi harnessin Sentry-bugien automaattista debuggausta varten. Juttu kannattaa lukea kokonaan, jos harkitset erikoistumista tälle alueelle, sillä se tekee huomion, joka on helppo jättää huomaamatta: malli ei koskaan ollut pullonkaula. Tiimi käytti Claude Agent SDK:ta perustana ja käytti sitten suurimman osan insinöörityöstään räätälöityyn pääte-käyttöliittymään ja joukkoon adaptereita, jotka yhdistävät agentin Sentryyn, Lineariin, GitHubiin ja Verceliin. Se on tehtävä pienoiskoossa. Neljä järjestelmää, neljä eri todennustapaa, neljä erilaista datamuotoa ja käyttöliittymä, joka antaa ihmisen katsoa ja puuttua tilanteeseen ilman, että jokaista askelta pitää vahtia.

Mistä "harness" oikeasti koostuu

Jos yrität selvittää, onko tämä taitokokonaisuus, jota kannattaa rakentaa, sen jakaminen osiin auttaa — osiin, joita rekrytoidaan erikseen, tai joita ainakin arvioidaan erikseen haastattelussa:

  • Käyttöoikeuksien suunnittelu. Sen päättäminen, mitä agentti saa tehdä ilman valvontaa (lukea tiketin, luonnostella PR:n) verrattuna siihen, mikä vaatii ihmisen mukaan silmukkaan (yhdistäminen, julkaisu, poistaminen, rahan käyttö) — ja tämän koodaaminen todelliseksi käytännöksi koodissa, ei promptiohjeeksi, jonka malli saattaa jättää huomiotta paineen alla. Tämä on lähempänä pääsynhallinnan insinöörityötä kuin promptien kirjoittamista.
  • Työkaluadapterit. Ohuet, hyvin testatut kääreet jokaisen ulkoisen järjestelmän ympärillä (Sentry, Linear, GitHub, Vercel tai mikä tahansa yrityksesi pinossa onkin), jotka kääntävät agentin aikomuksen turvalliseksi, validoiduksi API-kutsuksi ja kääntävät vastauksen takaisin muotoon, josta malli pystyy päättelemään. Tämä on tavallista ohjelmistokehitystä — virheenkäsittelyä, uudelleenyrityksiä, skeeman validointia — sovellettuna uuteen kuluttajaan.
  • Pääte- tai konsolikäyttöliittymä. Tapa, jolla ihminen näkee, mitä agentti tekee, hyväksyy tai hylkää toimintoja ja puuttuu peliin, kun agentti jää jumiin. ChatPRD rakensi omansa räätälöitynä; monet tiimit käyttävät sen sijaan valmiita agenttikonsoleita, mutta jonkun on silti päätettävä, mitä näytetään, mitä piilotetaan ja mikä vaatii klikkauksen ennen kuin se tapahtuu.
  • Työkalujen valinta suuressa mittakaavassa. Machine Learning Masteryn artikkeli nostaa esiin jotain, joka kannattaa tietää, jos rakennat mitään demoa pidemmälle menevää: agentin tarkkuus työkalukutsuissa alkaa heiketä, kun työkaluluettelo ylittää suunnilleen tusinan vaihtoehtoa — malli alkaa kutsua työkaluja väärin, hallusinoida parametreja tai jumittua huonoihin kutsuihin. Sen listaamat lieventämiskeinot (sen rajaaminen, mitkä työkalut ovat ylipäätään näkyvissä tietyssä kontekstissa, hakupohjainen työkalujen etsintä, reititys erikoistuneille aliagenteille, eksplisiittiset suunnitteluvaiheet, varajärjestelmälogiikka ja vertailutestiharnessit regressioiden kiinniottamiseksi) muodostavat itsessään tarkistuslistan asioista, jotka harness-insinöörin on osattava toteuttaa, ei vain tunnettava.
  • Konteksti- ja muisti-insinöörityö. Sama lähde tekee eron, joka kannattaa sisäistää: kontekstin suunnittelu (mitä menee yhteen päättelykutsuun ja mihin kohtaan) ja muistin suunnittelu (mikä säilyy istuntojen välillä, miten se tallennetaan, miten se haetaan) ovat eri osaamisalueita, joilla on erilaiset epäonnistumistavat. Lähteen väite on, että suurin osa pitkään käynnissä olevien, monta istuntoa kestävien agenttien häiriöistä juontuu näiden kahden sekoittamisesta — istuntomuistin kohtelemisesta ikään kuin se olisi vain lisää kontekstia, tai päinvastoin — erityisesti siinä kohdassa, jossa järjestelmä päättää, mitä se hakee.

Todisteet siitä, että tämä on todellinen, rahoituskelpoinen rooli — ei vain harrastelijoiden markkinarako

Skeptikot kysyvät aiheellisesti, onko "harness-insinööri" oma työnsä vai vain tehtävä jonkun toisen työn sisällä. Kaksi tietopoimintaa koosteesta viittaavat siihen, että kehitys on menossa ensimmäiseen suuntaan. Ensinnäkin Microsoftin Aspire-tiimi — kymmenen hengen ryhmä — käytti GitHubin Agentic Workflows -työkalua automatisoidakseen repositorioiden välisiä dokumentaatio-PR:iä, ja kahden julkaisun aikana he yhdistivät 82 PR:ää mediaanina 44,8 tuntia sen jälkeen, kun vastaava tuote-PR oli julkaistu, ilman uutta henkilöstöä ja ilman prosessien uudelleenkoulutusta. Se on pieni tiimi, joka saa suhteettoman suuren vaikutuksen nimenomaan siksi, että joku investoi tukirakenteeseen (työnkulkujen määrittelyihin, katselmusten reititykseen, laukaisulogiikkaan) sen sijaan, että insinöörit olisivat kirjoittaneet dokumentaatio-PR:t käsin. Toiseksi Microsoft Researchin SkillOpt-projekti kohtelee agentin "skill"-tiedostoja — ohjeita ja rajoituksia, jotka muovaavat sitä, miten agentti käyttäytyy harnessissaan — asioina, joita optimoidaan systemaattisesti sen sijaan, että niitä muokattaisiin käsin, ja se raportoi olleensa paras tai jaetusti paras kaikissa 52 solussa vertailutestiruudukossa (kuusi vertailutestiä, seitsemän mallia, kolme suoritustilaa), ja optimoidut skillit siirtyivät eri mallien ja eri harnessien välillä. Riippumatta siitä, muodostuuko juuri tästä työkalusta standardi, se viestii, että ala on alkamassa kohdella harness-konfiguraatiota insinööriartefaktina, jolla on omat työkalunsa ja vertailutestinsä — samaa kehityskulkua, joka muutti "DevOpsin" joukosta ad hoc -skriptejä omaksi tieteenalaksi.

Tälle kerrokselle rakennetaan nyt myös infrastruktuuria eksplisiittisesti. Googlen juuri julkistamat "Managed Agents" -ominaisuudet Gemini API:ssa — taustalla ja asynkronisesti suoritettavat tehtävät, etäisten MCP-palvelinten integrointi, mukautettu funktiokutsujen käyttö, tunnistetietojen päivitys vuorovaikutusten välillä — ovat käytännössä valmiiksi rakennettua putkistoa juuri niihin ongelmiin, jotka ChatPRD-tiimi ratkaisi käsin. Se on tavanomainen kaava: mitä yksi tiimi rakentaa räätälöitynä tänä vuonna, alustatoimittaja tuotteistaa ensi vuonna. Se ei poista harness-insinöörin roolia; se nostaa lattiaa ja siirtää työn painopistettä hallittujen primitiivien integrointiin ja konfigurointiin sen sijaan, että jokainen adapteri kirjoitettaisiin alusta asti, samaan tapaan kuin pilvi-infrastruktuuri ei poistanut ylläpitoinsinöörejä, vaan muutti sitä, mihin he käyttivät aikansa.

Mitä tämä tarkoittaa, jos tähtäät tähän rooliin

Muutama konkreettinen, tarkistettavissa oleva asia, joita kannattaa laittaa portfolioon tai ansioluetteloon, jos haluat olla uskottava tässä työssä: rakenna yksi adapteri päästä päähän oikeaa API:a vasten, jota et itse hallitse (mukaan lukien todennus, virheenkäsittely, käyttörajoitukset — ei pelkkää onnistuneen polun demoa); suunnittele ja dokumentoi agentille käyttöoikeusmalli, joka erottaa lukemis-, ehdotus- ja toimintatoiminnot toisistaan ja osoittaa, miksi kukin raja on siinä, missä se on; ja rakenna tai konfiguroi katselmusliittymä, jossa ihminen hyväksyy agentin toiminnot ennen niiden suorittamista, koska se on osa, jota useimmat yritykset vaativat ennen kuin päästävät agentin käsiksi tuotantoon. Jos arvioit harness-insinöörin työtarjousta tai rajaat omia vastuualueitasi, kysy nimenomaisesti, kuka omistaa käyttöoikeusmallin, kuka omistaa adapterit ja kuka omistaa ihmiskatselmuksen käyttöliittymän — monissa tiimeissä juuri nyt näillä kolmella asialla ei ole selkeää omistajaa, ja juuri tämä aukko on se, jota tämä rooli on muodostumassa täyttämään.

Yksi varaus kannattaa sanoa suoraan: mikään yllä olevista lähteistä ei osoita rekrytointimarkkinoiden lukuja juuri tälle nimikkeelle, eikä "harness-insinööri" ole vielä työnimike, jonka näkee työpaikkailmoituksissa — se ilmenee sen sijaan nimikkeiden kuten "AI-infrastruktuuri-insinööri", "agenttialustainsinööri" tai pelkästään "senior backend-insinööri, tekoälyjärjestelmät" sisällä. Kohtele tätä taitokokonaisuutena, joka rakennetaan ja kuvataan tarkasti, ei nimikkeenä, jota etsit LinkedInistä.