În ultimii doi ani, sfaturile de carieră legate de agenții AI au fost în mare parte despre cum să înveți să le scrii prompturi bune. Aceasta nu mai este abilitatea rară. Abilitatea rară este construirea eșafodajului în care se așază un agent — lucrul numit din ce în ce mai des harness — și este suficient de specific și de dificil încât devine propria sa fișă de post, nu doar o responsabilitate secundară a „persoanei AI” dintr-o echipă.

Cea mai clară prezentare publică a ceea ce presupune de fapt acest lucru vine de la Lenny's Newsletter, care documentează cum instrumentul de management de produs ChatPRD a construit un harness pentru a depana automat bug-uri din Sentry. Materialul merită citit integral dacă te gândești să te specializezi în acest domeniu, pentru că subliniază un aspect ușor de trecut cu vederea: modelul nu a fost niciodată blocajul. Echipa a folosit Claude Agent SDK ca fundație, apoi a investit cea mai mare parte a efortului de inginerie într-o interfață de terminal personalizată și într-un set de adaptoare care conectează agentul la Sentry, Linear, GitHub și Vercel. Aceasta este, în miniatură, meseria. Patru sisteme, patru scheme diferite de autentificare, patru forme diferite de date și o interfață care îi permite unui om să observe și să intervină fără să supravegheze fiecare pas.

În ce se descompune de fapt „harness”-ul

Dacă încerci să-ți dai seama dacă acesta este un set de competențe care merită construit, ajută să-l separi în bucăți care sunt angajate separat, sau cel puțin evaluate separat la un interviu:

  • Proiectarea permisiunilor. Decizia privind ce îi este permis unui agent să facă nesupravegheat (să citească un tichet, să redacteze un PR) față de ce necesită un om în buclă (fuzionare, deploy, ștergere, cheltuirea banilor) — și codificarea acestui lucru ca politică efectivă în cod, nu ca instrucțiune într-un prompt pe care modelul ar putea să o ignore sub presiune. Aceasta se apropie mai mult de ingineria controlului accesului decât de scrierea de prompturi.
  • Adaptoare pentru instrumente. Wrappere subțiri, bine testate, în jurul fiecărui sistem extern (Sentry, Linear, GitHub, Vercel sau orice altceva ar fi în stack-ul companiei tale) care traduc intenția agentului într-un apel API sigur și validat și traduc răspunsul înapoi în ceva ce modelul poate folosi în raționament. Aceasta este inginerie software obișnuită — gestionarea erorilor, reîncercări, validarea schemelor — aplicată unui consumator nou.
  • Interfață de terminal sau consolă. Un mod prin care un om poate vedea ce face agentul, poate aproba sau respinge acțiuni și poate interveni atunci când acesta se blochează. ChatPRD a construit una personalizată; multe echipe vor folosi în schimb console de agenți gata făcute, dar tot cineva trebuie să decidă ce se afișează, ce se ascunde și ce necesită un clic înainte de a se întâmpla.
  • Selecția instrumentelor la scară. Un material de la Machine Learning Mastery semnalează ceva ce merită știut dacă construiești orice dincolo de un demo: acuratețea agentului la apelurile de instrumente tinde să scadă odată ce catalogul de instrumente depășește aproximativ o duzină de opțiuni — modelul începe să apeleze greșit instrumente, să halucineze parametri sau să se blocheze pe apeluri eșuate. Măsurile de atenuare enumerate (restricționarea instrumentelor vizibile într-un context dat, căutarea instrumentelor bazată pe recuperare, direcționarea către sub-agenți specializați, pași expliciți de planificare, logică de rezervă și harnessuri de benchmark pentru a prinde regresii) sunt ele însele o listă de verificare a lucrurilor pe care un inginer de harness trebuie să știe cum să le implementeze, nu doar să le cunoască.
  • Ingineria contextului și a memoriei. Aceeași sursă trasează o distincție care merită interiorizată: ingineria contextului (ce intră într-un singur apel de inferență și unde) și ingineria memoriei (ce persistă între sesiuni, cum este stocat, cum este recuperat) sunt discipline diferite, cu moduri de eșec diferite. Afirmația sa este că majoritatea disfuncționalităților din agenții cu rulare lungă, multi-sesiune, se trag din confundarea celor două — tratarea memoriei de sesiune ca și cum ar fi doar mai mult context, sau invers — în special în punctul în care sistemul decide ce să recupereze.

Dovada că acesta este un rol real, finanțabil — nu doar o nișă de hobbyiști

Scepticii vor întreba, pe bună dreptate, dacă „inginer de harness” este o meserie sau doar o sarcină în cadrul postului altcuiva. Două date din digest sugerează că lucrurile se îndreaptă spre prima variantă. În primul rând, echipa Aspire de la Microsoft — un grup de 10 persoane — a folosit Agentic Workflows de la GitHub pentru a automatiza PR-uri de documentație cross-repo și, pe parcursul a două lansări, a fuzionat 82 de PR-uri la o mediană de 44,8 ore după lansarea PR-ului de produs corespunzător, fără angajări noi și fără reinstruire de proces. Aceasta este o echipă mică ce obține un efect de pârghie disproporționat tocmai pentru că cineva a investit în eșafodaj (definițiile fluxurilor de lucru, direcționarea recenziilor, logica declanșatoare) în loc să pună inginerii să scrie manual PR-uri de documentație. În al doilea rând, proiectul SkillOpt al Microsoft Research tratează fișierele de „skill” ale agenților — instrucțiunile și constrângerile care modelează comportamentul unui agent în harness-ul său — ca pe ceva ce trebuie optimizat sistematic, nu editat manual, și raportează că a fost cel mai bun sau la egalitate cu cel mai bun în toate cele 52 de celule ale unei grile de benchmark (șase benchmarkuri, șapte modele, trei moduri de execuție), skill-urile optimizate transferându-se între modele diferite și harnessuri diferite. Indiferent dacă acest instrument anume va deveni sau nu standard, el semnalează că industria începe să trateze configurarea harness-ului ca pe un artefact de inginerie cu propriile instrumente și benchmarkuri — aceeași traiectorie care a transformat „DevOps” dintr-un set de scripturi ad hoc într-o disciplină.

Există acum și infrastructură construită explicit pentru acest strat. Capacitățile nou anunțate „Managed Agents” din Gemini API ale Google — execuție în fundal și asincronă, integrare cu servere MCP la distanță, apeluri de funcții personalizate, reînnoirea acreditărilor între interacțiuni — reprezintă practic instalații pre-construite pentru exact problemele pe care echipa ChatPRD le-a rezolvat manual. Acesta este un tipar obișnuit: ce construiește o echipă la comandă anul acesta, un furnizor de platformă transformă în produs anul viitor. Asta nu elimină rolul de inginerie de harness; ridică nivelul minim și mută meseria spre integrarea și configurarea primitivelor gestionate, mai degrabă decât scrierea fiecărui adaptor de la zero, similar cu modul în care infrastructura cloud nu a eliminat inginerii de operațiuni, ci a schimbat pe ce își petreceau timpul.

Ce înseamnă asta dacă țintești acest rol

Câteva lucruri concrete, verificabile, de pus într-un portofoliu sau CV dacă vrei să fii credibil pentru această muncă: construiește un adaptor de la un capăt la altul față de un API real pe care nu îl controlezi (autentificare, gestionarea erorilor, limite de rată incluse, nu un demo pe calea fericită); proiectează și documentează un model de permisiuni pentru un agent care distinge acțiunile de citire/propunere/acțiune și arată de ce fiecare graniță este acolo unde este; și construiește sau configurează o interfață de recenzie în care un om aprobă acțiunile agentului înainte ca acestea să se execute, întrucât aceasta este piesa pe care majoritatea companiilor o vor cere înainte de a lăsa un agent să atingă producția. Dacă evaluezi o ofertă de job de inginerie de harness sau îți delimitezi propriile responsabilități, întreabă concret cine deține modelul de permisiuni, cine deține adaptoarele și cine deține suprafața de recenzie umană — în multe echipe, chiar acum, aceste trei lucruri nu au un proprietar clar, ceea ce este exact golul pe care acest rol se formează să îl umple.

O rezervă care merită formulată clar: niciuna dintre sursele de mai sus nu stabilește o cifră de piață a angajărilor pentru acest titlu specific, iar „inginer de harness” nu este încă un titlu de post pe care îl vei vedea în anunțuri — apare în interiorul unor titluri precum „inginer de infrastructură AI”, „inginer de platformă pentru agenți” sau pur și simplu „inginer backend senior, sisteme AI”. Tratează asta ca pe un set de competențe de construit și de descris cu acuratețe, nu ca pe un titlu de căutat pe LinkedIn.