Non scriviamo più prompt, costruiamo ambienti

# Ovvero: cos'è l'harness engineering e perché riguarda anche chi non scrive codice.

Immaginate di montare un motore da 500 cavalli sul telaio di una Fiat Panda 30 dell'83. Non andreste più veloci. Andreste a sbattere. Il motore sarebbe fantastico, ma il risultato un disastro.

Ecco: i modelli AI di oggi sono quel motore. Potentissimi! Come scrivevo nella newsletter di dicembre, il problema non è la potenza. È tutto ciò che ci costruite intorno.

E non lo dico solo io. Quando tre delle voci più influenti del settore arrivano alla stessa conclusione indipendentemente, credo siamo davanti a un segnale forte. OpenAI, Anthropic e Mitchell Hashimoto (il creatore di Terraform, uno degli strumenti più usati al mondo per gestire infrastrutture cloud) stanno tutti dicendo la stessa cosa: non investite sul modello. Investite su ciò che gli costruite intorno. Lo chiamano harness engineering.

Ho già scritto di come l'AI stia evolvendo dai chatbot agli agenti autonomi, e di come il lavoro stia cambiando passando dalla chat all'outcome. La direzione è chiara. Ma quello che è cambiato dallo scorso autunno non è la direzione: è il collo di bottiglia.

Cosa sta succedendo

Greg Brockman, presidente di OpenAI, ha scritto recentemente di come i migliori ingegneri dell'azienda gli abbiano detto che il loro lavoro è cambiato radicalmente da dicembre. Prima usavano l'AI per scrivere test. Ora l'AI scrive praticamente tutto il codice, fa debugging e gestisce operazioni. Non tutti hanno fatto quel salto, dice Brockman, "ma di solito non è per limiti del modello."

E qui viene il punto che mi interessa: Brockman dice ai suoi team create ambienti migliori. Nello specifico raccomanda di creare istruzioni permanenti per gli agenti e di aggiornarle ogni volta che sbagliano. Di fare l'inventario di tutti gli strumenti usati dal team e renderli accessibili agli agenti. Di strutturare il lavoro perché sia "agent-first". E di mantenere standard alti sull'output: mai abbassare la barra solo perché l'AI produce velocemente.

Tutto questo è il mondo dell'ingegneria software. Ma il pattern è universale. Se sostituite "codice" con "documenti", "test" con "controlli qualità", e "repository" con "cartelle di progetto", state descrivendo qualsiasi lavoro strutturato.

Il sistema di guida

Il termine harness engineering è stato introdotto da Mitchell Hashimoto e poi adottato sia da OpenAI che da Anthropic. "Harness" in inglese è l'imbracatura, il sistema di guida. A me piace pensarlo come il telaio, le sospensioni, lo sterzo e i freni della nostra Panda potenziata.

L'idea è semplice ma potente: ogni volta che un agente AI fa un errore, non gli urlate contro (non serve, lo so per esperienza). Prendete quel momento per ingegnerizzare una soluzione che impedisca a quell'errore di ripetersi. Mai più!

Nella pratica, l'harness è fatto di quattro componenti, e vi prometto che non c'è nulla di informatico in quello che sto per dire:

Documentazione viva

Non un manuale che scrivete una volta e dimenticate nel cassetto. Un documento che si aggiorna ogni volta che l'agente sbaglia. Brockman lo dice chiaramente: "Aggiornate le istruzioni ogni volta che l'agente fa qualcosa di sbagliato o fatica con un compito." È l'opposto del documento statico: è un organismo che cresce con l'esperienza. Nel mio sistema ho un file di istruzioni che oggi conta decine di regole: ciascuna è nata da un errore reale. Una volta il mio agente doveva inviare un'email a un contatto e, non trovando l'indirizzo in rubrica, ne ha generato uno di fantasia. Credibile, ma falso. Da quel giorno c'è una regola ferrea: verifica sempre il destinatario prima di inviare. Quell'errore non è più successo.

Strumenti accessibili

Non basta avere gli strumenti: devono essere usabili dall'agente. Pensate a un nuovo collega: se gli date accesso all'ERP ma nessuno gli spiega dove trovare i report mensili, quell'accesso è inutile. Brockman dice: "Fate l'inventario degli strumenti del team e assicuratevi che qualcuno li renda accessibili all'agente." Io nel mio ambiente ho collegato email, calendario, file su OneDrive, note su Obsidian, il mio blog, il CRM. Il mio agente sa dove cercare le informazioni e come usarle senza che io debba spiegarglielo ogni volta.

Vincoli che guidano

OpenAI ha fatto una cosa molto interessante: i loro strumenti di controllo automatico, quando trovano un errore, non si limitano a segnalarlo. Spiegano all'agente come correggerlo. Lo strumento insegna all'agente mentre lavora. È come avere un sistema che non dice solo "hai sbagliato" ma "hai sbagliato, e la prossima volta fai così." Nel mio caso ho un agente che si chiama QuCì: il suo unico compito è controllare la qualità di ciò che producono gli altri agenti prima che arrivi a me. Un collega senior che dà l'occhiata finale.

Feedback continuo

Anthropic ha scoperto che senza verifica esplicita gli agenti tendono a dichiarare vittoria prematuramente, segnando compiti come "completati" senza aver verificato davvero che funzionassero. Il feedback non deve essere solo umano (anche se quello resta fondamentale). Deve essere anche automatico, integrato nel sistema. Nel mio caso, il sistema tiene un diario: ogni mattina mi presenta cosa è successo, cosa è rimasto aperto e cosa richiede la mia attenzione. È il passaggio di consegne tra un turno e l'altro.

Pensateci: è esattamente come l'onboarding di un nuovo assunto. Buttatelo in azienda senza documenti, senza accesso agli strumenti, senza regole e senza nessuno che gli dia feedback: fallirà. Dategli tutto questo: sarà produttivo dal primo giorno!

Costruire e governare, contemporaneamente

C'è un aspetto che in molti sottovalutano. Non potete prima costruire l'ambiente perfetto e poi iniziare a governare gli agenti. Le due cose vanno fatte insieme, perché si alimentano a vicenda.

Gli errori dell'agente vi dicono cosa manca nell'ambiente. Un ambiente migliore vi libera tempo per concentrarvi sul governo.

Vi faccio un esempio che mi è successo scrivendo questo post. Nelle istruzioni del mio sistema c'era un riferimento a un controllo di sicurezza: un controllo automatico che verificava, prima di ogni operazione, che l'agente avesse l'autorizzazione per farla. Come un badge aziendale che apre solo certe porte. A un certo punto quel controllo è stato rimosso, sostituito da un'evoluzione del sistema in cui lavoro.

Ma nelle istruzioni la traccia era rimasta. Per settimane, nel mezzo di migliaia di operazioni, il sistema cercava di usare quello script fantasma. Non lo trovava, provava a risolvere autonomamente il problema, non ci riusciva, e andava avanti senza avvisarmi. Più lento. Più costoso. In silenzio.

Ed è stato il sistema stesso, mentre lo usavo per scrivere questo articolo, a farmi scoprire il problema: cercava ancora quello strumento che non esisteva più.

Qualcuno lo chiama context rot: le istruzioni che "marciscono" quando non vengono mantenute. È l'equivalente digitale di quel manuale aziendale del 2019 che nessuno ha più aggiornato ma che i nuovi assunti leggono ancora come se fosse vangelo.

Serve manutenzione. Costante. Evolutiva. Non è un progetto con una fine: è un processo.

Il fattore umano che manca

C'è un aspetto che Brockman, Hashimoto e più o meno chiunque parli dalla Silicon Valley sta sottovalutando.

Il fattore umano.

Un anno fa scrivevo dei pastori di agenti AI e dei nuovi mestieri che sarebbero emersi. Oggi quel concetto si è fatto più concreto: servono persone che costruiscano i recinti (l'harness) e che guidino il gregge (il governo degli agenti). Ma per farlo serve qualcosa che in Silicon Valley danno per scontato e che nel resto del mondo non lo è affatto: AI Fluency.

Se non siete "fluenti" nell'uso dell'AI, se non capite come funziona, cosa aspettarvi e dove può fallire, non potrete mai costruire i vostri ambienti e poi governarli. È come avere la macchina più potente del mondo senza patente.

Il fattore umano rallenta tutto? Sì, l'ho detto e lo penso. Ma deve essere coinvolto. Perché se non definiamo noi lo scopo, se non diamo senso a tutto questo, se non costruiamo noi il sistema di guida, diventiamo spettatori.

E ci troveremo a guardare un mondo che accelera capendone sempre meno.

Ho costruito una rappresentazione interattiva 3D, perché la nostra è una dimensione importante! Prova a raccontare meglio come funziona un sistema agentico: i cinque componenti, il piano umano e quello dell'agente con il ciclo di feedback a collegarli. Esploratela qui (e ditemi se vi convince).

Quindi?

Il motore c'è già. È potente. Funziona. Il problema non è mai stato il motore.

Molti di voi saranno chiamati, in questa fase, a costruire i propri sistemi di guida e poi a governarli. Non potrete aspettare di avere l'ambiente perfetto prima di iniziare, perché sarà l'uso stesso a dirvi cosa manca. E non potrete delegare questa responsabilità a chi vi vende l'AI, perché il contesto in cui lavorate lo conoscete solo voi.

Nel mio post precedente vi ho raccontato come sono passato dalla chat all'outcome. Questo è il passo successivo: costruire l'ambiente che rende l'outcome possibile.

Io il mio lo chiamo miniMe: è il mio sistema di guida personale. Lo uso ogni giorno per scrivere, analizzare, gestire progetti e comunicare con clienti. Non è un prodotto: è un ambiente che ho costruito e che continuo a costruire.

Negli ultimi mesi ho lavorato per rendere questo approccio replicabile. Un gruppo di persone ha già costruito il proprio "miniMe" partendo da zero, senza scrivere codice, e i risultati sono stati convincenti. Sto preparando qualcosa di nuovo, con l'aiuto di un team misto di agenti AI e collaboratori umani, per permettere a chiunque di fare lo stesso. Se vi interessa, scrivetemi.

Nella vostra azienda, chi sta costruendo l'ambiente in cui far lavorare l'AI?

Se la risposta è "nessuno", il motore più potente del mondo non vi porterà da nessuna parte.

Massimiliano

Enjoy AI Responsibly!