Negli ultimi due anni, i consigli di carriera riguardo agli agenti IA hanno riguardato principalmente l'imparare a scrivere buoni prompt per loro. Questa non è più la competenza rara. La competenza rara è costruire l'impalcatura all'interno della quale un agente opera — la cosa che viene sempre più spesso chiamata harness — ed è abbastanza specifica, e abbastanza difficile, da diventare una vera e propria mansione a sé stante, anziché una responsabilità secondaria del "tecnico IA" del team.

La descrizione pubblica più chiara di cosa comporti davvero questo lavoro arriva da Lenny's Newsletter, che documenta come lo strumento di product management ChatPRD abbia costruito un harness per correggere automaticamente i bug di Sentry. L'articolo merita di essere letto per intero se state valutando se specializzarvi in questo ambito, perché fa notare un punto facile da trascurare: il modello non è mai stato il collo di bottiglia. Il team ha usato il Claude Agent SDK come base, per poi dedicare la maggior parte dello sforzo ingegneristico a una UI da terminale personalizzata e a una serie di adattatori che collegano l'agente a Sentry, Linear, GitHub e Vercel. Questo è il lavoro, in miniatura. Quattro sistemi, quattro schemi di autenticazione diversi, quattro formati di dati diversi, e una UI che permette a un essere umano di osservare e intervenire senza dover sorvegliare ogni singolo passaggio.

In cosa si scompone davvero l'"harness"

Se state cercando di capire se vale la pena costruire questo insieme di competenze, è utile scomporlo nelle parti per cui si viene assunti separatamente, o quantomeno valutati separatamente in un colloquio:

  • Progettazione dei permessi. Decidere cosa un agente può fare senza supervisione (leggere un ticket, redigere una PR) rispetto a cosa richiede un essere umano nel ciclo (fare merge, deployare, eliminare, spendere denaro) — e codificarlo come una vera e propria policy nel codice, non come un'istruzione nel prompt che il modello potrebbe ignorare sotto pressione. Questo si avvicina più all'ingegneria del controllo degli accessi che alla scrittura di prompt.
  • Adattatori per gli strumenti. Wrapper snelli e ben testati intorno a ciascun sistema esterno (Sentry, Linear, GitHub, Vercel, o qualunque sia lo stack della vostra azienda) che traducono l'intento dell'agente in una chiamata API sicura e validata, e traducono la risposta in qualcosa su cui il modello possa ragionare. Si tratta di normale ingegneria del software — gestione degli errori, retry, validazione degli schemi — applicata a un nuovo tipo di consumatore.
  • UI da terminale o console. Un modo per far vedere a un essere umano cosa sta facendo l'agente, approvare o rifiutare le azioni, e intervenire quando si blocca. ChatPRD ne ha costruita una personalizzata; molti team useranno invece console per agenti già pronte all'uso, ma qualcuno deve comunque decidere cosa viene mostrato, cosa viene nascosto, e cosa richiede un clic prima che possa avvenire.
  • Selezione degli strumenti su larga scala. Un articolo di Machine Learning Mastery segnala qualcosa che vale la pena sapere se state costruendo qualcosa che va oltre una demo: l'accuratezza dell'agente nelle chiamate agli strumenti tende a peggiorare una volta che il catalogo degli strumenti supera all'incirca una dozzina di opzioni — il modello inizia a chiamare gli strumenti sbagliati, ad allucinare parametri, o a bloccarsi su chiamate errate. Le mitigazioni elencate (limitare quali strumenti sono anche solo visibili in un dato contesto, la ricerca degli strumenti basata su retrieval, l'instradamento verso sub-agenti specializzati, passaggi espliciti di pianificazione, logica di fallback, e harness di benchmark per individuare le regressioni) sono a loro volta una checklist di cose che un harness engineer deve saper implementare, non solo conoscere.
  • Ingegneria del contesto e della memoria. La stessa fonte traccia una distinzione che vale la pena interiorizzare: l'ingegneria del contesto (cosa entra in una singola chiamata di inferenza, e dove) e l'ingegneria della memoria (cosa persiste tra una sessione e l'altra, come viene memorizzato, come viene recuperato) sono discipline diverse, con modalità di fallimento diverse. La sua tesi è che la maggior parte dei malfunzionamenti negli agenti a lunga durata e multi-sessione derivi dal confondere le due cose — trattare la memoria di sessione come se fosse semplicemente altro contesto, o viceversa — in particolare nel punto in cui il sistema decide cosa recuperare.

Le prove che si tratta di un ruolo reale e finanziabile — non solo una nicchia per appassionati

Gli scettici chiederanno, ragionevolmente, se "harness engineer" sia un lavoro vero o solo un compito all'interno del lavoro di qualcun altro. Due dati emersi dalla rassegna suggeriscono che la situazione si stia spostando verso la prima ipotesi. Primo, il team Aspire di Microsoft — un gruppo di 10 persone — ha usato gli Agentic Workflows di GitHub per automatizzare le PR di documentazione cross-repo, e nell'arco di due release ha unito 82 PR con una mediana di 44,8 ore dopo l'uscita della corrispondente PR di prodotto, senza assumere nuovo personale e senza riqualificare i processi. Si tratta di un piccolo team che ottiene una leva sproporzionata proprio perché qualcuno ha investito nell'impalcatura (le definizioni dei workflow, l'instradamento delle revisioni, la logica dei trigger) invece di far scrivere le PR di documentazione a mano dagli ingegneri. Secondo, il progetto SkillOpt di Microsoft Research tratta i file "skill" degli agenti — le istruzioni e i vincoli che definiscono il comportamento di un agente all'interno del suo harness — come qualcosa da ottimizzare sistematicamente anziché modificare a mano, e riporta di essere risultato il migliore, o alla pari del migliore, in tutte le 52 celle di una griglia di benchmark (sei benchmark, sette modelli, tre modalità di esecuzione), con le skill ottimizzate che si trasferiscono tra modelli e harness diversi. Che quello specifico strumento diventi o meno uno standard, il segnale è che il settore sta iniziando a trattare la configurazione dell'harness come un artefatto ingegneristico dotato di propri strumenti e benchmark — la stessa traiettoria che ha trasformato il "DevOps" da un insieme di script improvvisati in una disciplina.

Ci sono anche infrastrutture che vengono ormai costruite esplicitamente per questo livello. Le funzionalità "Managed Agents" appena annunciate da Google nella Gemini API — esecuzione in background e asincrona, integrazione con server MCP remoti, chiamate a funzioni personalizzate, rinnovo delle credenziali tra un'interazione e l'altra — sono di fatto un impianto idraulico già pronto per gli stessi identici problemi che il team di ChatPRD ha risolto a mano. È uno schema normale: ciò che un team costruisce su misura quest'anno, un fornitore di piattaforme lo trasforma in prodotto l'anno prossimo. Questo non elimina il ruolo dell'harness engineer; alza l'asticella minima e sposta il lavoro verso l'integrazione e la configurazione di primitive gestite, anziché scrivere ogni adattatore da zero, in modo simile a come l'infrastruttura cloud non ha eliminato gli ingegneri operativi, ma ha cambiato in cosa investivano il loro tempo.

Cosa significa questo se puntate a questo ruolo

Alcune cose concrete e verificabili da inserire in un portfolio o in un curriculum se volete essere credibili per questo lavoro: costruite un adattatore end-to-end contro un'API reale che non controllate (autenticazione, gestione degli errori, rate limit inclusi, non una demo del solo percorso felice); progettate e documentate un modello di permessi per un agente che distingua le azioni di lettura/proposta/azione e mostri perché ciascun confine si trova dove si trova; e costruite o configurate un'interfaccia di revisione in cui un essere umano approva le azioni dell'agente prima che vengano eseguite, dato che è la componente su cui la maggior parte delle aziende insisterà prima di lasciare che un agente tocchi la produzione. Se state valutando un'offerta di lavoro da harness engineer o state definendo i confini delle vostre responsabilità, chiedete specificamente chi possiede il modello di permessi, chi possiede gli adattatori, e chi possiede la superficie di revisione umana — in molti team, in questo momento, queste tre cose non hanno un proprietario chiaro, ed è esattamente il vuoto che questo ruolo si sta formando per colmare.

Un avvertimento che vale la pena esprimere chiaramente: nessuna delle fonti citate sopra stabilisce un dato numerico sul mercato delle assunzioni per questo titolo specifico, e "harness engineer" non è ancora un titolo di lavoro che troverete negli annunci — sta emergendo all'interno di titoli come "AI infrastructure engineer", "agent platform engineer", o semplicemente "senior backend engineer, AI systems". Consideratelo un insieme di competenze da costruire e descrivere in modo accurato, non un titolo da cercare su LinkedIn.