Harness designer: progettare il brodo di coltura
Il ruolo dell'AI designer si sta spostando sull'ambiente attorno al modello.
Nessuno di quei dodici problemi nasceva da un'allucinazione del modello. Il codice generato era coerente al suo interno e si rompeva nei punti in cui un sistema passava la mano a un altro, dove vive un contratto che nessuno aveva scritto nel prompt. Da quel giorno la domanda su quale modello usare mi interessa molto meno di quella su cosa gli metto intorno, e su chi lo decide.
Che cos'è un harness, e perché riguarda chi fa design
Nel gergo di chi costruisce agenti, l'harness è tutto quello che sta attorno al modello: le istruzioni di sistema, gli strumenti a cui può accedere, la memoria che si porta dietro, i permessi, i controlli che ne verificano l'output, il ciclo che decide quando fermarsi. A febbraio OpenAI ha raccontato un esperimento interno durato cinque mesi, in cui un piccolo gruppo di persone ha guidato degli agenti fino a un prodotto in beta di circa un milione di righe di codice, nessuna scritta a mano. Il lavoro umano si è spostato tutto sull'impalcatura: cicli di feedback, documentazione, vincoli architetturali scritti in modo che una macchina possa leggerli (InfoQ). A settembre Tomasz Tunguz citava uno studio di Berkeley secondo cui, a parità di accuratezza, l'harness giusto abbassa del 71% il costo dello stesso risultato (post su X).
Quando leggo queste cose riconosco il mio mestiere. Decidere cosa un agente può vedere è architettura dell'informazione, e ci lavoro da vent'anni con altri nomi. Anche stabilire con quali permessi agisce, e in quale momento deve fermarsi a chiedere a una persona, sono scelte che ho sempre fatto su service blueprint e flussi di interazione, con la differenza che adesso tra gli attori in scena c'è un modello statistico che non si stanca e non dubita mai di sé.
Per questo uso l'espressione harness designer. Indica chi progetta l'ambiente in cui un'intelligenza artificiale lavora, prima ancora delle schermate con cui le persone la incontrano. L'harness engineering è nato tra chi scrive codice, e metà delle domande che pone sono domande di design che oggi, nella maggior parte dei team, vengono decise senza nessuna persona con quel background nella stanza. Il ruolo di AI designer, per come lo vivo, sta diventando in buona parte questo.
Il brodo di coltura
L'immagine che uso più spesso viene dal laboratorio di microbiologia. Una coltura cresce in base a quello che metti nella piastra, alla temperatura, al tempo che le concedi e a quello che lasci fuori. Le intelligenze artificiali con cui lavoro ogni giorno si comportano in modo simile: lo stesso modello di base produce risultati lontanissimi a seconda del contesto in cui lo immergo.
Il mio brodo di coltura personale è un vault di note in markdown, organizzato come una wiki, da cui gli agenti leggono decisioni, vocabolario, progetti chiusi e aperti. Dentro c'è una regola che ho scritto dopo l'ennesima conferma compiacente: prima di darmi ragione, trova i buchi nel mio ragionamento e ordinali per gravità. Prima di quella regola ricevevo elogi travestiti da feedback; adesso ricevo liste di problemi che a volte mi irritano parecchio, e ho imparato a leggere quell'irritazione come il segno che la regola sta facendo il suo lavoro.
Progettare un harness, in pratica, vuol dire lavorare su quattro verbi.
Seguire. Tracciare cosa l'agente ha letto, quali strumenti ha chiamato, su quali basi ha deciso. Senza log leggibili, quando qualcosa va storto nessuno sa rispondere alla domanda "perché fa così?", e capita molto prima di quanto si immagini.
Controllare. Mettere punti di verifica dove il sistema passa la mano, i bordi della demo vocale. L'AI scrive bene il novanta per cento del codice; il dieci che manca si concentra quasi sempre nei passaggi tra un sistema e l'altro.
Perimetrare. Decidere cosa l'agente non può toccare. In Ekitai le modifiche al design system restano bozze finché una persona non ne conferma la pubblicazione, e la conferma va chiesta ogni volta, anche quando sembra una formalità.
Amplificare. Dare all'agente memoria e strumenti dove una persona da sola non arriverebbe, per esempio tenere coerenti tono di voce e scelte strategiche su dieci touch point dello stesso prodotto.
L'ordine conta. Amplificare un sistema che non hai ancora perimetrato significa moltiplicare i suoi errori alla stessa velocità con cui moltiplichi i suoi risultati, e la seconda cosa si vede in demo mentre la prima si vede in produzione.
Ethical AI is a lie, e quindi?
Il 12 novembre torna WUDRome, e il tema di quest'anno l'abbiamo scelto con l'intenzione di dare un po' fastidio: "Ethical AI is a lie". Il World Usability Day 2026 parla di compassione, cura del pianeta e tecnologia per tutte le comunità, parole che arrivano da un'industria che prosciuga falde acquifere per raffreddare i data center, paga due dollari l'ora chi modera contenuti traumatici e vende sorveglianza chiamandola sicurezza. L'AI etica dei manifesti senza conseguenze e dei comitati senza potere, per come la vediamo noi di Sensemaking Design Italia, è una bugia.
La provocazione però ha un secondo tempo, ed è quello che mi riguarda come harness designer. Se l'etica non abita nei proclami deve abitare in un posto verificabile, e l'harness è uno dei pochi luoghi dove si può scrivere in forma eseguibile. Una regola che obbliga l'agente a fermarsi prima di incrociare dati che le persone non hanno concesso è una scelta etica con un indirizzo preciso: qualcuno l'ha scritta, si può leggere, si può contestare e si può cambiare, cosa che di un paragrafo in una carta dei valori non si può dire.
Questo sposta la responsabilità su chi progetta il brodo, e lo costringe a fare i conti con quattro famiglie di problemi.
Conseguenze. Il sito di WUDRome chiude con una domanda che uso come test su ogni harness: in quale futuro è stato testato? Un agente che risponde bene oggi, con i dati di oggi, può comportarsi in modo molto diverso quando cambiano gli utenti, i volumi o il modello sottostante.
Esclusioni. Chi resta fuori dal perimetro? Le persone che usano uno screen reader, chi scrive in un italiano che il modello considera "errato", chi non ha mai dato il consenso a finire in un dataset. Un harness che non le nomina esplicitamente le esclude per default.
Bias. Il mio vault riflette le mie letture, i miei clienti, il mio modo di ragionare. Un agente che pensa con le mie note eredita i miei punti ciechi e li applica più in fretta di me, con un tono più sicuro del mio.
Effetti collaterali. Quando la velocità di generazione supera la velocità di revisione si arriva ad approvare senza leggere. Lo chiamo il problema del direttore d'orchestra solitario, e lo conosco bene perché ci cado anch'io.
La call di WUDRome cercava proprio questo: progetti rifiutati, interrotti o ripensati per ragioni etiche, metodi per rendere i sistemi contestabili da chi li usa, voci dalla filiera dell'AI come moderazione ed etichettatura dati, fallimenti da cui si è imparato qualcosa. Tutte cose che succedono dentro un harness, molto più spesso che dentro un modello.
Quello che non ho ancora risolto
La parte che non so fare bene è la revisione. Più l'harness funziona, più produce, e io resto una persona sola che deve leggere tutto. Mi è capitato di cliccare "ok" su cose che non avevo letto davvero, e di accorgermene settimane dopo. La risposta che mi do, cioè reintrodurre di proposito altre persone nella revisione e mettere un tetto di tempo alla produzione, rallenta proprio la cosa che rende l'orchestrazione attraente, e un equilibrio stabile non l'ho trovato.
A volte ho il sospetto che, dopo la Gen X e la Gen Z, siamo diventati tutti Gen -y. Chi usa il terminale conosce quel flag: apt-get install -y, npm init -y, il "sì" dato in anticipo a qualunque domanda il comando stia per farti. Era nato per non bloccare gli script che girano di notte, e si è trasformato in un modo di stare al mondo. Gli agenti che lavorano da riga di comando hanno modalità che saltano tutte le richieste di permesso, e una di queste si chiama, con una sincerità quasi commovente, --dangerously-skip-permissions: il pericolo è scritto nel nome e la attiviamo lo stesso, perché confermare ogni passaggio annoia.
Ogni harness che progetto deve fare i conti con questa abitudine, a partire dalla mia, perché un perimetro che si scavalca con due caratteri esiste solo sulla carta.
C'è poi una domanda di governance che rimando da mesi. Quando un harness è condiviso tra più persone e più agenti, chi ha l'autorità di cambiare una regola? Chi versiona i prompt, chi rilegge i log? Nel mio vault la risposta è facile perché sono solo io. In un'organizzazione di cinquanta persone non lo è affatto, e la maggior parte di quelle che ho visto non se l'è ancora posta.
Non so se harness designer diventerà un titolo che vedremo sui profili LinkedIn. Mi basta che chi progetta prodotti con l'AI cominci a considerare l'ambiente attorno al modello come materia di progetto, con la stessa cura che mettiamo in un flusso di onboarding. Se queste domande ti riguardano, il 12 novembre siamo a Roma, al MAM Media Art Museum in Corso Italia 37D: programma e modalità di partecipazione sono su wudrome.it. Porta i tuoi casi, e soprattutto quelli andati male.
Fonti
