I de sidste to år har karriereråd om AI-agenter for det meste handlet om at lære at prompte dem godt. Det er ikke længere den knappe kompetence. Den knappe kompetence er at bygge den stillads-struktur, en agent opererer indenfor — det, der i stigende grad kaldes en harness — og den er specifik og svær nok til, at det er ved at blive sin egen jobbeskrivelse frem for en biopgave for "AI-personen" i et team.

Den klareste offentlige gennemgang af, hvad dette reelt indebærer, kommer fra Lenny's Newsletter, som dokumenterer, hvordan produktledelsesværktøjet ChatPRD byggede en harness til automatisk at fejlfinde Sentry-fejl. Artiklen er værd at læse i sin helhed, hvis du overvejer at specialisere dig inden for dette felt, for den fremhæver en pointe, det er let at overse: modellen var aldrig flaskehalsen. Teamet brugte Claude Agent SDK som fundament og brugte derefter størstedelen af deres udviklingsindsats på en tilpasset terminal-UI og et sæt adaptere, der forbinder agenten til Sentry, Linear, GitHub og Vercel. Det er jobbet i miniature. Fire systemer, fire forskellige autentificeringsordninger, fire forskellige dataformer, og en UI, der lader et menneske følge med og gribe ind uden at skulle overvåge hvert eneste skridt.

Hvad "harness" reelt består af

Hvis du prøver at finde ud af, om dette er et kompetencesæt, det er værd at opbygge, hjælper det at opdele det i dele, der ansættes til separat, eller i det mindste evalueres separat i en jobsamtale:

  • Design af rettigheder. At beslutte, hvad en agent må gøre uden opsyn (læse en sag, udkaste en PR) i modsætning til, hvad der kræver et menneske i loopet (merge, deploy, slette, bruge penge) — og indkode det som en egentlig politik i kode, ikke som en prompt-instruktion, modellen måske ignorerer under pres. Dette ligger tættere på adgangskontrol-ingeniørarbejde end på promptskrivning.
  • Værktøjsadaptere. Tynde, velafprøvede wrappere omkring hvert eksternt system (Sentry, Linear, GitHub, Vercel, eller hvad din virksomheds stak nu er), der oversætter agentens hensigt til et sikkert, valideret API-kald og oversætter svaret tilbage til noget, modellen kan ræsonnere ud fra. Dette er almindeligt softwareudviklingsarbejde — fejlhåndtering, gentagne forsøg, skemavalidering — anvendt på en ny forbruger.
  • Terminal- eller konsol-UI. En måde, hvorpå et menneske kan se, hvad agenten foretager sig, godkende eller afvise handlinger og træde til, når den går i stå. ChatPRD byggede deres egen, og mange teams vil i stedet bruge færdige agent-konsoller, men nogen skal stadig beslutte, hvad der vises, hvad der skjules, og hvad der kræver et klik, før det sker.
  • Værktøjsvalg i stor skala. En gennemgang fra Machine Learning Mastery peger på noget, det er værd at vide, hvis du bygger noget, der går ud over en demo: agenters præcision ved værktøjskald har en tendens til at falde, når værktøjskataloget kommer over cirka et dusin muligheder — modellen begynder at kalde de forkerte værktøjer, hallucinere parametre eller gå i stå på dårlige kald. De modforanstaltninger, den nævner (at afgrænse, hvilke værktøjer der overhovedet er synlige i en given kontekst, retrieval-baseret værktøjsopslag, routing til specialiserede underagenter, eksplicitte planlægningstrin, fallback-logik og benchmark-harnesses til at fange regressioner) er i sig selv en tjekliste over ting, en harness-ingeniør skal kunne implementere, ikke bare kende til.
  • Kontekst- og hukommelsesingeniørarbejde. Samme kilde drager et skel, det er værd at gøre til sit eget: kontekstingeniørarbejde (hvad der indgår i et enkelt inferens-kald, og hvor) og hukommelsesingeniørarbejde (hvad der består på tværs af sessioner, hvordan det gemmes, hvordan det hentes) er forskellige discipliner med forskellige fejltyper. Påstanden er, at de fleste sammenbrud i langvarige agenter med flere sessioner kan spores tilbage til at sammenblande de to — at behandle sessionshukommelse, som var det bare mere kontekst, eller omvendt — især på det punkt, hvor systemet beslutter, hvad der skal hentes.

Beviset for, at dette er en reel, finansierbar rolle — ikke bare en hobbynicheposition

Skeptikere vil med rette spørge, om "harness-ingeniør" er et job eller blot en opgave inden for en andens job. To datapunkter fra digestet tyder på, at det bevæger sig mod det førstnævnte. For det første brugte Microsofts Aspire-team — en gruppe på 10 personer — GitHubs Agentic Workflows til at automatisere dokumentations-PR'er på tværs af repos, og over to udgivelser merge'de de 82 PR'er med en median på 44,8 timer efter, at den tilsvarende produkt-PR blev udgivet, uden ny bemanding og uden omtræning af processer. Det er et lille team, der opnår uforholdsmæssig stor gennemslagskraft, netop fordi nogen investerede i stilladset (workflow-definitionerne, review-routingen, trigger-logikken) i stedet for at lade ingeniører skrive dokumentations-PR'er i hånden. For det andet behandler Microsoft Researchs SkillOpt-projekt agenters "skill"-filer — instruktionerne og begrænsningerne, der former, hvordan en agent opfører sig inden for sin harness — som noget, der skal optimeres systematisk fremfor redigeres i hånden, og rapporterer, at det var bedst eller lige så godt i alle 52 celler i et benchmark-gitter (seks benchmarks, syv modeller, tre eksekveringstilstande), hvor de optimerede skills overførtes på tværs af forskellige modeller og forskellige harnesses. Uanset om netop dette værktøj bliver standard eller ej, signalerer det, at branchen er begyndt at behandle harness-konfiguration som et ingeniørartefakt med sine egne værktøjer og benchmarks — samme udvikling, der gjorde "DevOps" til en disciplin i stedet for et sæt ad hoc-scripts.

Der bliver også nu bygget infrastruktur specifikt til dette lag. Googles nyligt annoncerede "Managed Agents"-funktioner i Gemini API'en — baggrunds- og asynkron eksekvering, integration med fjern-MCP-servere, tilpasset funktionskald, legitimationsopdatering på tværs af interaktioner — er reelt færdigbygget VVS til præcis de problemer, ChatPRD-teamet løste i hånden. Det er et normalt mønster: det, ét team bygger skræddersyet i år, produktgør en platformsudbyder næste år. Det udrydder ikke rollen som harness-ingeniør; det hæver bundniveauet og flytter jobbet i retning af at integrere og konfigurere managed byggeklodser fremfor at skrive hver eneste adapter fra bunden, ligesom cloud-infrastruktur ikke udryddede driftsingeniører, men ændrede, hvad de brugte deres tid på.

Hvad dette betyder, hvis du sigter efter denne rolle

Nogle konkrete, verificerbare ting at have i en portefølje eller på et CV, hvis du vil være troværdig inden for dette arbejde: byg én adapter fra ende til anden mod et rigtigt API, du ikke selv kontrollerer (inklusive autentificering, fejlhåndtering, rate limits — ikke en happy-path-demo); design og dokumentér en rettighedsmodel for en agent, der skelner mellem læse/foreslå/handle-handlinger og viser, hvorfor hver grænse ligger, hvor den gør; og byg eller konfigurér en review-grænseflade, hvor et menneske godkender agenthandlinger, før de udføres, for det er den del, de fleste virksomheder vil insistere på, før de lader en agent røre ved produktion. Hvis du overvejer et jobtilbud som harness-ingeniør eller afgrænser dine egne ansvarsområder, så spørg specifikt, hvem der ejer rettighedsmodellen, hvem der ejer adapterne, og hvem der ejer den menneskelige review-flade — i mange teams lige nu har disse tre ting ingen klar ejer, hvilket er præcis det hul, denne rolle er ved at opstå for at udfylde.

Et forbehold, det er værd at nævne klart og tydeligt: ingen af kilderne ovenfor fastslår et konkret ansættelsesmarkedstal for denne specifikke titel, og "harness-ingeniør" er ikke en jobtitel, du vil se på opslag endnu — den optræder inden i titler som "AI-infrastrukturingeniør", "agent-platformsingeniør", eller bare "senior backend-ingeniør, AI-systemer". Betragt dette som et kompetencesæt, der skal opbygges og beskrives præcist, ikke en titel, der skal søges efter på LinkedIn.