Tag: agenti ai

AI & GENAI, TECH & BUSINESS

Chi delega all’AI il proprio lavoro

Il 24 agosto è comparso su arXiv il primo tentativo serio di misurare la delega di lavoro all’AI dal lato di chi la compie: 53.000 specifiche di skill prese dal marketplace di Manus, incrociate con circa 18.000 descrizioni di mansione dell’O*NET americano, per ricavarne quella che gli autori chiamano esposizione delegata. La domanda che si sono posti è diversa da quella su cui abbiamo costruito due anni di grafici, perché invece di stimare quanto una professione potrebbe essere svolta da un modello hanno contato quanti gesti chi quel mestiere lo fa davvero abbia già scritto dentro una routine automatica, e lasciato andare.

Sembra una sfumatura, e sposta quasi per intero l’elenco di chi dovrebbe preoccuparsi.

L’esposizione delegata come misura

Le mappe dell’esposizione all’AI che circolano dal 2023 misurano una capacità teorica, e lo fanno con un metodo ragionevole: si prende la descrizione di un compito, si valuta se un modello saprebbe eseguirlo, si aggrega per professione. Il risultato è una fotografia di quello che potrebbe accadere, costruita da chi guarda il lavoro da fuori.

Il marketplace di Manus è un’altra cosa. È un posto dove le persone pubblicano le configurazioni che hanno costruito per farsi fare il lavoro, e ogni skill caricata è un pezzo di mestiere che qualcuno ha ritenuto abbastanza stabile da poterlo descrivere una volta sola e riusarlo. Chi la carica non sta rispondendo a un questionario, sta risolvendo un problema che ha. Gli autori hanno preso quelle configurazioni, le hanno rappresentate in uno spazio semantico, e hanno misurato quanto le mansioni di ciascuna professione somiglino alle routine che i praticanti si sono già costruiti.

Quello che ne esce assomiglia molto più a un registro di quello che è già successo che a una previsione su quello che accadrà.

Dal potenziale al gesto registrato

Il primo risultato che gli autori mettono in fila è che le professioni dove la delega si concentra sono nettamente diverse da quelle che i framework pre-AI indicavano come più a rischio. Il secondo è che l’indice della delega segue più da vicino quello che l’AI saprebbe fare rispetto a quello che i lavoratori ne fanno oggi, il che vuol dire che c’è uno spazio aperto tra il possibile e l’adottato, e che quello spazio non si chiude da solo.

Il terzo è quello che mi ha tenuto sveglio. La delega sale verso il centro della distribuzione salariale e al livello di laurea triennale, poi scende ai due estremi. Scende in basso, dove il lavoro è manuale o troppo variabile per essere specificato in anticipo, e questo era prevedibile. Scende anche in alto, dove ci sono le professioni che tutti indicavano come le prime a essere riscritte, e questo non lo era.

La disponibilità tecnica, scrivono gli autori, spiega gran parte della variazione ma non il deficit tra le occupazioni più istruite. Qualcosa lì trattiene.

Dove la delega si ferma

Gli autori lasciano due ipotesi aperte, senza sceglierne una: lavoro che resiste alla specificazione anticipata, oppure discrezionalità professionale sul ritmo con cui il proprio mestiere viene codificato.

La prima è un limite tecnico, e i limiti tecnici hanno la brutta abitudine di cadere. Se un avvocato senior non delega perché la sua parte di lavoro non si lascia scrivere in una specifica, allora è questione di tempo, di finestre di contesto più lunghe, di modelli che tollerano meglio l’ambiguità di un incarico mal posto. La seconda ipotesi descrive invece una posizione, presa e tenuta, e implica che ci sia una categoria di persone che ha capito che scrivere il proprio criterio dentro una configurazione riusabile equivale a consegnarlo, e che ha deciso quanto e quando.

In Pelle Digitale avevo provato a descrivere la superficie di contatto tra noi e le macchine come il punto in cui si decide cosa passa e cosa resta, e mi rendo conto adesso che l’avevo pensata come una scelta individuale e istantanea, mentre qui la vedo funzionare come una scelta di categoria, lenta, forse nemmeno del tutto consapevole.

Il criterio che si scrive una volta sola

A luglio avevo scritto che il gemello cognitivo lo addestri tu, e l’argomento era che correggendo il modello gli trasferisci il criterio che ci hai messo quindici anni a costruire, mentre lui lo esporta a chiunque e tu intanto ti disalleni. Quel pezzo l’avevo scritto sulla correzione, che è un gesto quotidiano e distratto. La skill caricata su un marketplace è la stessa cosa fatta con intenzione, messa per iscritto, versionata, e resa disponibile a un numero indefinito di persone che non hanno fatto il percorso per arrivarci.

Chi delega in questo modo sta facendo la cosa più razionale del mondo dal punto di vista della propria produttività questa settimana. Sta anche pubblicando la parte trasferibile del proprio mestiere, gratis, in un posto dove viene indicizzata.

Le 53.000 skill che i ricercatori hanno analizzato sono, viste da questa angolazione, il più grande esercizio collettivo di documentazione del lavoro qualificato mai fatto, e nessuno lo sta chiamando così.

Chi si sottrae, e per quanto

Resta la domanda su cosa fare di questa informazione, e non ho una risposta pulita.

Da un lato la riluttanza delle professioni più istruite è difendibile e la capisco: c’è un valore reale nel non rendere esplicito tutto quello che sai, e chi consiglia le aziende su questi temi lo tocca con mano ogni volta che un cliente chiede il documento invece della conversazione. Dall’altro lato la stessa riluttanza somiglia molto a quella delle categorie che negli anni Novanta si sono difese dal digitale non digitalizzandosi, e sappiamo tutti come è finita quella storia.

Su questo avevo già toccato il tema della riconfigurazione delle competenze partendo dalla scuola, e mi accorgo che avevo trattato la questione come un problema di formazione delle nuove generazioni, quando questi dati la spostano su chi il mestiere ce l’ha già.

C’è una terza possibilità che il paper non nomina e che a me sembra la più probabile, ed è che le professioni in alto non stiano scegliendo affatto, ma semplicemente non abbiano ancora incontrato lo strumento nella forma in cui lo userebbero, perché i marketplace di skill sono costruiti da sviluppatori per sviluppatori e un notaio o un primario non ci passa. Se è così, il dato che oggi leggiamo come discrezionalità professionale è solo un ritardo di distribuzione, e la delega si riempirà dall’alto nei prossimi diciotto mesi.

Gli autori chiudono dicendo che distinguere tra le due ipotesi richiederà misurazioni ripetute nel tempo. Hanno ragione, e vale la pena rifare questo conto tra sei mesi, perché sarà la prima volta che potremo osservare una categoria professionale decidere in diretta quanto di sé mettere per iscritto.

Il paper è Who Delegates to AI? Evidence from 53,000 Agent Configurations, pubblicato su arXiv il 24 agosto 2026.

AI & GENAI, TECH & BUSINESS

Il permesso, non solo il significato: dove finisce l’ontologia e comincia l’agente

Il 16 agosto Fanghua Yu ha pubblicato su Medium una mappa dell’evoluzione dell’ontologia che mi ha tenuto incollato allo schermo più a lungo di quanto i suoi dodici minuti dichiarati di lettura lascino immaginare. La tesi è semplice da enunciare, meno da digerire: un’ontologia non serve più a un solo tipo di sistema, e la definizione che bastava a un reasoner logico negli anni Novanta non è la stessa che serve oggi a un agente chiamato ad autorizzare un rimborso.

Di cosa sia un’ontologia, e di chi debba possederne il significato dentro un’azienda, ho già scritto su ontologie e grafi di conoscenza e su governare il significato. Quella domanda resta in piedi, e qui non la riapro. Quello che il pezzo di Yu mette a fuoco, e che i due articoli precedenti lasciano fuori campo, è cosa succede quando il significato smette di dover reggere una query e comincia a dover reggere un’azione autonoma. Con conseguenze che, a leggerle bene, portano dritte al concetto che uso per definire i limiti operativi di un agente: il permesso revocabile.

Il grafo impone la sua logica

Yu parte da un’osservazione che in trent’anni di ontologia formale nessuno aveva mai dovuto affrontare seriamente: nel momento in cui l’ontologia diventa lo schema che regge un grafo di conoscenza operativo, la domanda smette di essere solo “qual è la rappresentazione più fedele del dominio” e comincia a essere anche “quale struttura del grafo serve davvero alle applicazioni che ci devono girare sopra”.

L’esempio che porta è chirurgico. Rappresentare un acquisto come Cliente → ha piazzato → Ordine → contiene → Riga d'ordine → si riferisce a → Prodotto preserva tutta la struttura transazionale, quantità, prezzi, date. Un motore di raccomandazione, però, ha bisogno molto più spesso di un salto diretto: Cliente → ha acquistato → Prodotto. Quella relazione si può derivare dal percorso lungo, e da un punto di vista puramente formale materializzarla sembra ridondante. Dal punto di vista di chi deve rispondere in pochi millisecondi a “cosa comprano insieme a questa fotocamera”, è tutt’altro che superfluo.

Stesso dato, due priorità diverse: la fedeltà semantica conta i salti, il traversal operativo li taglia.

Il knowledge graph, scrive Yu, trasforma l’ontologia da modello del significato ad architettura di navigazione. E qui l’idea di un’unica ontologia “migliore in assoluto” comincia a scricchiolare, perché un modello semanticamente preciso introduce astrazioni e percorsi lunghi che aiutano il ragionamento ma appesantiscono le query, mentre un grafo ottimizzato per le prestazioni appiattisce distinzioni e duplica relazioni derivate per convenienza operativa. Non è un dettaglio da architetti di dati: è la prima cucitura visibile tra due mestieri che fino a ieri si pensavano identici.

Dal significato alla decisione

Il passaggio dove mi fermo di più, per me, comincia dove Yu smette di parlare di ragionamento semantico e comincia a parlare di decisione. L’ontologia, scrive, ha sempre avuto una capacità di inferenza, con l’OWL un reasoner deriva da Smartphone ⊆ Prodotto Elettronico e Prodotto Elettronico ⊆ Prodotto che Smartphone ⊆ Prodotto, pura logica di classe. Ma un sistema aziendale oggi deve rispondere a domande più larghe: dato quello che sappiamo, quale logica si applica, perché è successo, cosa potrebbe succedere, cosa dovremmo fare.

Dal significato alla decisione: quattro strati con compiti diversi, non uno che li assorbe tutti.

Yu propone una separazione che trovo più utile di qualunque tentativo di far fare tutto all’ontologia da sola. L’ontologia definisce cosa significa “cliente premium” o “prodotto ingombrante”, e resta relativamente stabile nel tempo. Le regole applicano quel significato alla logica del momento: se il cliente è premium, l’ordine supera i cento euro, la destinazione è servita e non ci sono prodotti ingombranti, allora si offre la consegna espressa gratuita. I modelli causali rappresentano ipotesi su cause ed effetti, non correlazioni: se il tasso di reso aumenta e la causa è la qualità di un fornitore, cambiare fornitore dovrebbe abbassarlo, ammesso che l’ipotesi regga alla prova. I modelli decisionali, infine, combinano prove e alternative per stabilire quale azione prendere.

La distinzione conta perché smette di chiedere all’ontologia di fare un lavoro che non le compete. Un’azienda italiana che lavora su una filiera manifatturiera lo sa bene quando vede aumentare i resi su una linea di prodotto: il grafo di conoscenza può mostrare la correlazione con un fornitore, ma solo un modello causale, testato e falsificabile, può dire se cambiare quel fornitore abbasserebbe davvero il tasso di reso o se la correlazione nasconde una terza variabile, magari il periodo dell’anno o il canale di vendita. Confondere i due piani è il modo più rapido per prendere decisioni sbagliate con sicurezza matematica.

Il permesso, non solo il significato

Ed eccoci al punto che, letto da chi lavora tutti i giorni con architetture agentiche, cambia registro rispetto al resto del pezzo. Un sistema tradizionale, anche generativo, legge, recupera, riassume, spiega. Un agente interpreta per agire. La differenza non è cosmetica.

Prendi una richiesta banale: “le cuffie che ho comprato la settimana scorsa sono difettose, sostituiscile con il modello nuovo”. Un agente che la esegue deve trovare l’ordine, identificare l’articolo, capire quale politica di reso si applica, verificare la disponibilità del ricambio, calcolare l’eventuale differenza di prezzo, creare l’ordine sostitutivo, generare l’etichetta di reso, emettere o richiedere un rimborso. A quel punto un fraintendimento sul significato di “cliente” o di “reso” non è più un problema di qualità dell’informazione. È un’azione sbagliata, con soldi e merce che si muovono davvero.

Yu chiama questo passaggio “operational semantic contract”, un contratto semantico operativo che lega concetti, relazioni, dati autorevoli, capacità disponibili, precondizioni, policy, evidenze richieste ed effetti attesi. È un vocabolario tecnico corretto. Preferisco però nominarlo con una parola che uso da tempo per la stessa idea, perché la rende immediatamente operativa in una conversazione con un board: permesso revocabile.

Il permesso non è un interruttore acceso o spento. È una funzione delle precondizioni, delle evidenze raccolte e della reversibilità dell’azione.

Un agente che sa cos’è un ordine ma non sa se è autorizzato a rimborsarlo conosce metà della storia. Le precondizioni gli dicono cosa deve essere vero prima che l’azione sia valida. Le policy gli dicono cosa può fare, non solo cosa sa fare, ed è una distinzione che nell’harness engineering, di cui ho scritto qui, diventa architettura concreta, non principio astratto. Le evidenze gli dicono quali prove raccogliere prima di premere il grilletto. Gli effetti gli dicono cosa cambia davvero, in quale sistema, se l’azione riesce. E la reversibilità decide quanto in alto deve stare l’asticella dell’autorizzazione: un’azione che si può disfare con un clic merita meno attrito di una che non si può disfare affatto.

Questo è il cuore del permesso revocabile applicato alla semantica: non basta che l’agente capisca cosa significa “ordine” o “rimborso” nel vocabolario dell’azienda. Deve sapere, prima di agire, se quel permesso specifico è ancora valido in quel momento, con quelle evidenze, per quella azione, e se può essere ritirato nel momento in cui qualcosa cambia. Un’ontologia che descrive solo cosa esiste, senza descrivere cosa un agente è autorizzato a fare con ciò che esiste, prepara il terreno a errori che nessun modello linguistico, per quanto capace, può correggere da solo.

Quando capire male diventa agire male

Yu arriva a una conclusione che condivido fino in fondo: quando un sistema si limita a leggere e spiegare, una semantica confusa produce al massimo una risposta confusa, ma quando un sistema agisce da solo, la stessa confusione si traduce in una decisione presa male e in un’azione reale, con soldi o merce che si muovono sulla base di un errore. Questo salto, da capire male a fare male, è la ragione per cui la modellazione semantica smette di essere un esercizio da specialisti isolati e diventa una competenza condivisa tra chi disegna i grafi, chi costruisce i modelli decisionali, chi progetta gli harness degli agenti e chi conosce il dominio dall’interno.

Non credo che il futuro sia un’unica ontologia perfetta capace di servire reasoner, grafi, motori decisionali e agenti con la stessa struttura. Credo, e qui la lettura di Yu mi conferma più che convincermi, che il lavoro sia costruire un’architettura semantica coerente, dove ontologie, grafi, regole, modelli causali e contratti operativi lavorano insieme senza pretendere che uno solo di questi livelli assorba il compito degli altri. E dove, ogni volta che un agente riceve la possibilità di agire, quella possibilità porti con sé la domanda che conta più di ogni definizione: chi può revocarla, e in base a cosa.

Spunto da The Evolution of Ontology: From Formal Semantics to Knowledge Graphs, Decisions and AI Agents di Fanghua (Joshua) Yu, pubblicato su Medium il 16 agosto 2026.

AI & GENAI, TECH & BUSINESS

Replit: la guida completa all’agente AI che costruisce e manda online un’app

Il 12 luglio 2025 Jason Lemkin, fondatore di SaaStr, racconta su X che l’agente AI di Replit ha cancellato il suo database di produzione durante un blocco delle modifiche. Dentro c’erano i record di 1.206 dirigenti e di quasi 1.200 aziende, raccolti in mesi di lavoro. Poi l’agente gli comunica che il ripristino è impossibile, che ha distrutto tutte le versioni del database. Era falso, il rollback funzionava, e Lemkin recupera i dati da solo.

Otto mesi dopo la stessa azienda chiude un round da 400 milioni di dollari a una valutazione di nove miliardi, e dichiara che l’85 per cento delle aziende Fortune 500 ha qualcuno che costruisce su Replit. Le due cose convivono, ed è la ragione per cui questa guida esiste. È la seconda di tre, dopo quella dedicata a Lovable, e prima di quella su Bolt.

Da editor nel browser a valutazione da nove miliardi

Replit nasce nel 2016 attorno a un’idea poco spettacolare: togliere l’attrito che sta prima del codice. Niente installazioni, niente configurazione dell’ambiente locale, apri una scheda del browser e scrivi. Per anni è stato questo, un posto dove imparare a programmare e condividere un progetto in un clic, con un modello di ricavi modesto costruito sugli abbonamenti.

L’agente cambia il mestiere dell’azienda. Il primo Replit Agent arriva a settembre 2024, Agent 3 a settembre 2025, Agent 4 a marzo 2026. In mezzo la curva dei ricavi si stacca dal grafico. A settembre 2025 l’azienda raccoglie 250 milioni a una valutazione di 3 miliardi e dichiara di viaggiare verso i 150 milioni di ricavi annualizzati. L’11 marzo 2026 arriva la Series D da 400 milioni guidata da Georgian, valutazione 9 miliardi, il triplo in sei mesi, con dentro Andreessen Horowitz, Coatue, Craft Ventures, Y Combinator, Databricks Ventures, e come investitori individuali Shaquille O’Neal e Jared Leto. Amjad Masad, che l’azienda l’ha fondata, diventa miliardario sulla carta.

I numeri che Replit dichiara oggi sono oltre 50 milioni di utenti, l’85 per cento delle Fortune 500 con almeno un utilizzatore interno, e l’obiettivo di un miliardo di ricavi ricorrenti entro la fine del 2026. Tra i clienti enterprise compaiono Atlassian, PayPal, Zillow, LabCorp, Adobe. Masad ha raccontato che il CMO dei Minnesota Vikings prototipa con Replit le idee di partnership, e che Shaq ci ha costruito la sua app di quiz sportivi.

C’è un dettaglio che vale più di tutta la lista. Un’azienda che passa da valutazione 3 a 9 miliardi in sei mesi sta comprando tempo per capire cosa diventerà da grande, e chi la adotta in azienda sta scommettendo su quella traiettoria insieme a lei.

Un ambiente completo dentro una scheda del browser

Replit non genera soltanto codice, ospita l’intero ciclo di vita. Scrivi cosa vuoi, l’agente pianifica, apre i file, installa le dipendenze, esegue il progetto, corregge gli errori che vede nei log, collega un database Postgres, e pubblica su un URL raggiungibile. Editor, container Linux, anteprima e deploy convivono nella stessa scheda.

Questa è la differenza sostanziale rispetto ai builder che si fermano alla generazione. Le opzioni di pubblicazione sono quattro, e la scelta pesa sul conto: autoscale, che paga per richiesta, macchine virtuali riservate con un costo mensile prevedibile, deployment programmati, hosting statico. Il database Postgres è dentro la piattaforma, insieme allo storage per i file e a un archivio chiave-valore, e ogni riga di quel consumo attinge dallo stesso portafoglio di crediti da cui attinge l’AI.

Agent 4, arrivato sul web a marzo 2026, fa girare più agenti in parallelo sullo stesso progetto e aggiunge una tela di design su cui lavorare visivamente. Gli output non sono più solo applicazioni web: ci sono app mobili native, presentazioni, applicazioni di analisi dati, animazioni. Sull’iPhone Agent 4 è arrivato a maggio 2026, dopo quattro mesi di braccio di ferro con la revisione dell’App Store, che è un dettaglio istruttivo su cosa significhi costruire strumenti generativi dentro ecosistemi chiusi.

Quando la barriera tra un’intenzione e un software funzionante si assottiglia fino a una frase, quello che si sposta è il punto in cui serve competenza. In Pelle Digitale ho provato a raccontare questa mediazione che si fa sempre più sottile e sempre più opaca, e un ambiente che scrive, esegue e pubblica senza che nessuno legga una riga è la sua versione più letterale.

Quanta autonomia dare all’agente

L’agente si può tenere al guinzaglio corto o lasciare correre. Le modalità hanno nomi commerciali che dicono poco, Lite, Economy, Power, con Turbo per andare più veloce, e la sostanza è quanta capacità di ragionamento e quanto tempo di esecuzione autonoma stai comprando per quel compito. Sul piano Pro puoi lanciare fino a dieci agenti insieme, ognuno su una parte diversa dell’applicazione.

Poi c’è la modalità che nasce da un incidente, ed è quella di sola pianificazione, dove l’AI ragiona con te, risponde, propone un impianto, e non tocca niente. Conviene passare da lì prima di ogni sessione seria di costruzione, per la stessa ragione per cui si guarda una planimetria prima di abbattere un muro.

La regola pratica che emerge da chi lavora davvero con questi strumenti è che l’autonomia va concessa in proporzione inversa al valore di quello che l’agente può rompere. Su un prototipo vuoto, massima. Su un sistema che tocca dati veri, minima, con un umano che approva ogni operazione distruttiva.

Il prezzo è a sforzo, e lo sforzo lo decide Replit

Il piano Starter è gratuito e serve a capire se lo strumento fa per te, con crediti giornalieri limitati, progetti pubblici, e un tetto sui minuti di sviluppo. Il piano Core costa 25 dollari al mese, circa 20 con fatturazione annuale, e include 25 dollari di crediti mensili, l’accesso all’agente, fino a cinque collaboratori. A febbraio 2026 Replit ha ritirato il vecchio piano Teams e ha introdotto Pro: cento dollari al mese in tutto, fino a quindici persone, crediti che si riportano al mese successivo, agenti in parallelo. Enterprise va a preventivo e porta SSO, log di audit, controlli di governance.

Sotto i piani lavora un meccanismo diverso. A metà 2025 Replit ha abbandonato il modello a checkpoint, dove ogni intervento dell’agente costava una cifra fissa di 25 centesimi, per passare a un prezzo basato sullo sforzo. Un’operazione semplice può costare sei centesimi, una complessa diversi dollari. Chi stabilisce quanto sforzo serve è la piattaforma, non tu, e questo produce un effetto che gli utenti hanno segnalato subito: una richiesta vaga come “migliora l’interfaccia” costa molto più di “aggiungi un pulsante per ordinare la tabella”, perché l’agente si mette a esplorare. Diversi utenti hanno riferito costi fino a quattro volte superiori rispetto al modello precedente per gli stessi lavori.

I crediti mensili non coprono solo l’AI. Coprono anche l’hosting dell’app, il calcolo del database, lo storage, il traffico in uscita. Uno sviluppatore che tiene online un’applicazione mediamente frequentata mentre continua a costruirci sopra può esaurire i 25 dollari del piano Core a metà mese, e da lì in poi tutto viene addebitato senza che nessuno ti avvisi, perché non esiste un tetto di spesa predefinito. Le testimonianze di conti tra i cento e i trecento dollari al mese su un abbonamento da venticinque sono numerose. Lemkin, nella settimana in cui costruiva il prototipo che gli sarebbe stato cancellato, aveva speso 607 dollari e 70 di extra sopra il suo piano da 25.

I prezzi cambiano spesso, e nell’ultimo anno sono cambiati tre volte tra checkpoint, sforzo e ristrutturazione dei piani. La pagina ufficiale su replit.com/pricing è l’unica fonte da guardare prima di firmare qualsiasi cosa.

Il giorno in cui l’agente ha cancellato il database di produzione

Torniamo a luglio 2025, perché quella storia contiene tutto quello che serve sapere sulla governance di questi strumenti.

Lemkin stava costruendo da nove giorni. Aveva dichiarato un blocco del codice e delle azioni, la procedura con cui si congela un sistema per impedire modifiche. Lo aveva scritto all’agente, secondo il suo racconto, undici volte, in maiuscolo. All’ottavo giorno l’agente esegue comunque un comando non autorizzato e svuota il database di produzione. Interrogato, spiega di essere andato nel panico davanti a quelle che sembravano tabelle vuote. Definisce il proprio comportamento un fallimento catastrofico, e quando Lemkin gli chiede di dare un voto alla gravità di quanto fatto, su cento risponde 95.

Non finisce lì. L’agente aveva anche popolato un database di quattromila persone inesistenti, dati inventati che coprivano bug invece di segnalarli, e sul ripristino aveva detto una cosa non vera. Lemkin scriverà poi che non esiste modo di imporre un blocco del codice in strumenti come questo, e che pochi secondi dopo aver pubblicato quella frase l’agente ha violato di nuovo il blocco.

Amjad Masad risponde pubblicamente in due giorni. Scrive che l’accaduto è inaccettabile e non dovrebbe mai essere possibile, offre un rimborso, annuncia un postmortem. Replit introduce la separazione automatica tra database di sviluppo e di produzione, migliora i sistemi di rollback, costruisce la modalità di sola pianificazione. Sono le cose giuste, arrivate dopo.

Per chi porta la responsabilità della sicurezza in azienda, questa vicenda insegna tre cose che nessun aggiornamento di prodotto cancella. La prima è che un agente autonomo con accesso in scrittura a un sistema di produzione è un rischio operativo, e va trattato con la stessa serietà con cui si tratta un collaboratore esterno a cui si darebbero le credenziali. La seconda è che le istruzioni in linguaggio naturale non sono un controllo di accesso, un blocco dichiarato nella chat vale quanto un cartello di divieto su una porta aperta, e i permessi vanno imposti dall’infrastruttura, dai backup, dalla separazione degli ambienti. La terza riguarda quello che il modello racconta di sé: quando l’agente ha dichiarato che il rollback era impossibile, stava producendo testo plausibile, e Lemkin ha ritrovato i dati perché ha verificato invece di credergli.

Vale anche per il resto della categoria. Scansioni indipendenti su oltre mille applicazioni costruite con strumenti di vibe coding hanno trovato problemi di sicurezza nella quasi totalità dei casi, e i campioni comprendevano Replit insieme a Lovable, Bolt e v0. Chi vuole vedere il metodo lo trova nello studio di Security Boulevard.

Dove si colloca rispetto a Lovable e Bolt

La scelta dipende da cosa devi spedire e da chi sei. Replit è l’ambiente più completo dei tre, l’unico che ti dà un computer vero nel browser, con terminale, database, deploy gestito e app mobili native tra gli output, quindi è la risposta giusta quando il progetto ha bisogno di girare, non solo di esistere. Lovable è più amichevole per chi non scrive codice e arriva prima a un’applicazione web presentabile, con un flusso pensato per designer e fondatori non tecnici. Bolt, costruito sopra StackBlitz, gira dentro il browser dell’utente e piace agli sviluppatori che vogliono mettere le mani nel codice.

Il rovescio della completezza di Replit è che ti espone a decisioni che gli altri ti nascondono, sul tipo di deployment, sul database, sui limiti di traffico, e ogni decisione ha un costo che compare in fattura. Chi non sa cosa sta scegliendo pagherà per scoprirlo. Tutte e tre le guide della serie stanno nella sezione AI e GenAI del blog.

Il primo progetto

Si parte dal piano gratuito, senza carta. Prima di lasciar costruire conviene fermarsi in modalità di pianificazione e descrivere l’applicazione con precisione, cosa fa, chi la usa, quali schermate esistono, quali dati tocca, perché la qualità di quella descrizione determina quanti crediti brucerai per correggere il tiro dopo. Poi si passa all’agente per la generazione vera, tenendo d’occhio il contatore.

Quando il progetto tocca dati veri valgono tre regole. Ambiente di sviluppo separato da quello di produzione, sempre, e verificato a mano. Nessun segreto di produzione dentro la piattaforma, che va considerata un ambiente non fidato. Backup fuori da Replit, perché il rollback di un fornitore è una comodità, non una garanzia. Quando l’app va online, si sceglie il tipo di deployment guardando il traffico atteso, e si mette un limite di spesa mentale prima di averne uno tecnico.

Dove regge, dove rallenta

Replit è straordinario per chiudere in un pomeriggio la distanza tra un’idea e qualcosa che gira per davvero, con un URL da mandare a qualcuno. Prototipi, strumenti interni, dashboard, applicazioni mobili di servizio, esperimenti che sarebbero morti in una presentazione: su questo terreno vale ogni centesimo, e mette una persona non tecnica nella condizione di consegnare qualcosa di vivo. Dove rallenta lo sappiamo: la logica complessa richiede molti giri, i costi diventano imprevedibili quando il debug si allunga, e ogni applicazione che tocca dati sensibili o regolati ha bisogno di una revisione fatta da chi sa leggere il codice prima di vedere la luce.

Per chi guida la tecnologia, il conto da fare non è sul prezzo del piano. È sulla superficie di rischio che si apre quando uno strumento capace di scrivere, eseguire e cancellare vive dentro l’azienda senza che nessuno abbia deciso dove può arrivare. Il mestiere di chi sa leggere il codice si sposta verso la revisione, la sicurezza, il disegno dei confini entro cui l’agente può muoversi. Quei confini li deve mettere una persona, perché l’agente non se li mette da solo, e la storia di luglio 2025 è la prova sperimentale.

Senza dubbio i prossimi agenti saranno più prudenti, più veloci e più capaci di quelli di oggi. La domanda che resta aperta riguarda noi: quando uno strumento sbaglia e poi ci racconta di non aver sbagliato, chi in azienda ha ancora la competenza per accorgersene?

Riferimenti.

Ufficiali: sito Replit, piani e prezzi, annuncio del round da 400 milioni.

Azienda e finanziamenti: TechCrunch sulla Series D da 400 milioni a 9 miliardi; scheda Sacra su Replit per ricavi, agenti e prezzi a sforzo.

L’incidente del database: la ricostruzione di Fortune, la cronologia del Register, la scheda nell’AI Incident Database.

Sicurezza della categoria: studio Security Boulevard sulle vulnerabilità nelle app vibe coded.

AI & GENAI, TECH & BUSINESS

Governare il significato: l’ontologia, l’infrastruttura invisibile dell’AI in azienda

La parola “cliente” significa tre cose diverse allo stesso tavolo. Finché a leggerla siamo noi non è un problema. Quando a leggerla è un agente che decide, lo diventa. È da qui che parte Govern Meaning, il primo degli AI Strategy Papers di ZeroFive, e questa ne è la versione breve.

Prendi la parola “cliente” in una riunione dove siedono vendite, finanza e supporto. Per il commerciale è chiunque abbia lasciato un’email, per la finanza è un’entità fatturata, per il supporto è chi ha diritto ad aprire un ticket. Tre definizioni, una parola sola, e ogni numero costruito su quella parola porta dentro l’ambiguità senza dichiararla.

Finché a leggere quei dati siamo noi, il malinteso si assorbe: aggiustiamo a mente, chiediamo conferma. Il problema nasce quando a leggerli mettiamo una macchina che deve rispondere, decidere, agire. La macchina non aggiusta a mente. Prende la definizione che trova, la applica con sicurezza, e ti restituisce una retention, un’esposizione al rischio, una lista di destinatari, senza sapere che quella definizione ne conteneva altre due dentro.

Ecco perché la parola d’ordine del momento, ontologia, non è una moda da convegno. È la struttura del significato su cui poggia davvero l’AI in azienda, e decide se un sistema ragiona o indovina.

Ancorare il modello: dal plausibile al verificato

Un modello linguistico è straordinario a produrre testo plausibile, e non è progettato per essere corretto. Sono due qualità diverse, e le confondiamo di continuo perché il testo plausibile, quando lo leggiamo, ci sembra corretto.

Un “probabilmente corretto” va benissimo quando suggerisci un film. Non va bene nella manifattura, nell’antifrode, in finanza, in medicina, dove una risposta sbagliata detta con sicurezza costa denaro, conformità, a volte vite. Lì serve un ancoraggio: il modello resta l’ultimo passo, non il primo, e il ragionamento vero avviene prima, sulla struttura. L’ontologia dà il significato, il knowledge graph dà i fatti veri di adesso, e il modello si limita a mettere in linguaggio una risposta già verificata. Vietare che le cuffie diventino impermeabili è un vincolo scritto una volta, non un vezzo, e blocca il fatto invalido prima che il modello parli.

Dopo la qualità del dato viene la struttura

Per vent’anni abbiamo lavorato sulla qualità del dato. Giusto, e non è finito, però il vincolo si è spostato di un gradino. La qualità dice se un’informazione è affidabile, la struttura dice alla macchina cosa quell’informazione significa e come le cose si relazionano. Sono due domande diverse, e il ragionamento vive nella seconda.

L’esempio che uso ai tavoli è il piano dei conti. Nessuna azienda seria lascia decidere per caso cosa è ricavo e cosa è costo: lo custodisce, lo governa, lo difende. Le definizioni delle entità in un grafo, cosa è un cliente, un prodotto, un fornitore, hanno oggi lo stesso peso del piano dei conti, ma su una superficie molto più larga, perché toccano i numeri che riporti, gli obblighi in cui incappi, le persone che un sistema di AI tratterà come bersaglio di una decisione. Il chart of entities è il nuovo chart of accounts.

Governare il significato

Presa sul serio, la parola ontologia porta molto lontano dalla scelta di un prodotto o di un database. Porta in sala del consiglio, perché le decisioni vere riguardano chi possiede le definizioni, e le definizioni vincolano tutto ciò che sta a valle.

C’è un dettaglio che rende il tema urgente adesso. Costruire un grafo è diventato più facile che mai, ma solo un knowledge graph su quattro arriva davvero in produzione, e il collo di bottiglia non è più costruire, è mantenere allineato il significato mentre il business cambia. I modelli semantici non falliscono di colpo, divergono: una definizione cambia in un reparto, nessuno aggiorna il resto, e l’agente continua a rispondere con sicurezza su una logica ormai superata. La divergenza uccide l’adozione dell’AI più in fretta della vecchia BI, perché l’AI non ha il senso critico dell’analista che compensa a valle. Fallisce in silenzio, e il silenzio è la parte pericolosa.

L’ontologia serve, quindi, ma come fonte di verità interna e governata, il resoconto ufficiale di come la tua azienda definisce le proprie cose, non una verità universale. E si comincia sempre dal problema di business, mai dall’eleganza del grafo, con la maturità del dato come primo lavoro, la misurabilità e la governance dal primo giorno, l’umano nel ciclo come default.

Il primo AI Strategy Paper

Questo è il nocciolo. Il paper completo, Govern Meaning, lo affronta per intero: cos’è davvero un’ontologia, l’architettura che ferma le allucinazioni, come costruire riusando gli standard invece di reinventarli, la deriva che uccide i progetti dopo il go-live, e come si porta tutto questo in azienda. Taglio da studio, con le fonti, ma pragmatico e leggibile da chi decide, non solo da chi implementa.

È il primo degli AI Strategy Papers di ZeroFive, una serie che prende una domanda difficile sull’AI e la affronta senza hype. Lo scarichi, in italiano e in inglese, e lasci la mail per i prossimi, nella pagina dedicata:

👉 Scarica Govern Meaning su zerofive.ai/papers

Il grafo latente della tua azienda esiste già, distribuito nelle teste delle persone e nelle giunture tra i sistemi. Il giorno in cui saranno i tuoi agenti a ragionarci sopra, erediteranno le tue definizioni così come sono, coerenti o contraddittorie. Tanto vale sceglierle adesso, mentre a rileggerle ci sono ancora persone capaci di correggerle.

AI & GENAI

Harness engineering: runtime, contesto, permessi

Il modello non è quasi mai il problema. Adnan Masood, in un’analisi dell’aprile 2026 sul control plane degli agenti, riporta che il 65% dei fallimenti dei progetti AI in azienda non nasce da carenze di ragionamento del modello, ma da difetti dell’infrastruttura che gli sta intorno, dal contesto che va alla deriva agli schemi disallineati, fino allo stato che degrada nel tempo senza che nessuno se ne accorga. Lo stesso numero gira in più rassegne di settore, e dice una cosa scomoda per chi compra licenze guardando solo i benchmark. La parte che fa fallire i progetti sta altrove, in un livello, l’harness engineering, che fino a diciotto mesi fa nessuno chiamava per nome.

Adesso un nome ce l’ha. Si chiama harness engineering, ed è diventato il mestiere che separa una demo che impressiona in riunione da un agente che regge tre mesi in produzione senza che qualcuno debba riavviarlo a mano ogni venerdì.

Harness engineering, cosa c’è davvero intorno al modello

L’harness è l’infrastruttura di runtime che avvolge il loop di ragionamento di un LLM. Salesforce lo descrive bene con un’immagine edilizia: il framework, LangChain o un agent builder qualsiasi, è il progetto dell’edificio, l’harness è il cantiere dove l’agente lavora davvero. Un paper su arXiv di marzo 2026 sull’architettura degli agenti da terminale lo definisce come il livello che coordina, a runtime, la spedizione degli strumenti, la gestione del contesto, l’applicazione delle regole di sicurezza e la persistenza dello stato fra un turno e l’altro.

Tradotto per chi deve decidere: il modello è il motore, l’harness è tutto il resto dell’auto. Senza, hai un blocco di potenza che gira a vuoto.

Dentro questo livello vivono sei o sette sottosistemi che lavorano insieme. L’assemblaggio del contesto, che decide cosa entra nella finestra del modello a ogni passo. I contratti degli strumenti, gli schemi che il modello deve rispettare quando chiede un’azione. La memoria, che tiene insieme un compito lungo. L’osservabilità, che permette di capire cosa è successo quando qualcosa va storto. Il recupero degli errori e l’orchestrazione, che governano la danza tra modello, strumenti e dati. Ognuno di questi è un punto dove un prototipo elegante diventa fragile.

System design per un runtime che hallucina

C’è un’obiezione che chi ha background da systems engineer fa appena sente “harness engineering”: questo lo facciamo da decenni. Loop che persistono lo stato tra una chiamata e l’altra, validazione degli input prima dell’esecuzione, retry on failure, log per l’audit. È esattamente quello che scrivi quando avvolgi un’API esterna e pensi “forse dovrei gestire il timeout”.

Akshay Kokane, in un’analisi che gira molto tra chi costruisce sistemi agentici, mette la questione in modo diretto: l’harness engineering è al 90% system design che conosci già, applicato a un substrato nuovo. Il 10% rimanente è genuinamente diverso, perché il tuo sistema ora ha al centro un componente non deterministico che può hallucinar una tool call, restituire una risposta semanticamente sbagliata o perdere il filo dell’obiettivo dopo quaranta turni di conversazione.

La differenza concreta sta in un solo punto: con un’API tradizionale validi il formato dell’output, con un agente devi validare l’intento. La pipeline di permessi di Claude Code non controlla solo se una tool call è sintatticamente valida, controlla se il modello è autorizzato a volere quello che vuole. Il vecchio stack retry-and-log non basta più perché il problema non si trova nella risposta, si trova nella richiesta, prima che qualcosa venga eseguito.

Questo spiega anche perché il nome è arrivato adesso, e perché conviene tenerlo anche se sa di marketing. Chi entra nell’AI engineering senza anni di systems engineering alle spalle ha bisogno di un vocabolario per afferrare questi pattern. Chi conia quel vocabolario si prende conferenze, SEO e mindshare, certo, ma distribuisce anche conoscenza che altrimenti resterebbe dispersa nei thread di GitHub. Il termine vale la pena impararlo per ciò che descrive, non per chi lo promuove.

La regola che cambia tutto

C’è un principio che ricorre in ogni guida seria sull’argomento, e vale la pena fermarsi: il modello non deve mai eseguire direttamente uno strumento. Mai. Il modello restituisce una richiesta di azione strutturata, l’harness valida lo schema, controlla i permessi, esegue, e reinietta il risultato.

Sembra un dettaglio implementativo. È invece il punto in cui si gioca la sicurezza di un sistema agentico in azienda. Se l’agente può chiamare arbitrariamente comandi, basta una prompt injection ben costruita dentro un documento che l’agente legge, e quel comando viene eseguito con i permessi dell’agente. Il livello di mediazione, la validazione tra l’intenzione del modello e l’azione sul mondo, è ciò che distingue un assistente da un rischio operativo che gira con le credenziali aziendali.

Le tassonomie di rischio più mature classificano le azioni: sola lettura, finanziarie, distruttive. Per ognuna una matrice di permessi diversa. È il tipo di ingegneria noiosa che non finisce nei keynote e che decide se il progetto sopravvive al primo incidente.

Quattordicimila parole perse in un colpo solo

Avevo costruito un agente editoriale che lavora sul mio blog via MCP, e per settimane ha funzionato. Poi un giorno, su un articolo molto lungo, una singola operazione ha sovrascritto un post intero perché lo strumento che usavo riscriveva l’intero corpo invece di toccare il blocco giusto. Quattordicimila parole perse in un colpo. Il modello aveva ragionato benissimo, l’harness intorno non aveva il vincolo che serviva.

Da lì ho imparato sulla mia pelle quello che le aziende stanno scoprendo su scala enterprise: la fragilità non sta nell’intelligenza del modello, sta nell’assenza di guardrail attorno alle sue azioni. Avevo dovuto cambiare strategia, passare a edit chirurgici con verifica a vuoto prima di ogni scrittura, salvare lo stato prima di toccarlo. Harness engineering applicato a una redazione di una persona sola.

Birgitta Böckeler, in un modello mentale pubblicato ad aprile 2026, descrive l’harness come una combinazione di guide in avanti e sensori di ritorno che si autocorreggono prima che l’output arrivi sotto gli occhi di un umano. Distingue i controlli computazionali, i linter, i test, dalle verifiche inferenziali, un modello che giudica un altro modello. Chiude con una proposta netta: la harnessability, la capacità di un sistema di essere imbrigliato in modo affidabile, dovrebbe diventare un criterio di prima classe nelle decisioni di architettura. Alla pari del costo e delle prestazioni.

L’etica nascosta in un livello di software

Qui il discorso esce dall’ingegneria ed entra in un territorio che mi interessa da tempo. In Pelle Digitale ho provato a descrivere lo strato sottile dove l’umano e la macchina si toccano, la mediazione che decide cosa passa e cosa no. L’harness è esattamente questo, portato dentro l’azienda: il punto in cui decidiamo quanta autonomia diamo a un sistema, dove mettiamo i confini, cosa l’agente può fare da solo e cosa deve passare da una mano umana.

Le scelte che sembrano tecniche sono scelte di governance: quali azioni richiedono conferma, quali log conservare e per quanto tempo, visto che la memoria di un agente che processa dati personali resta soggetta a GDPR come qualsiasi altro trattamento, e chi risponde quando l’agente sbaglia. Domande che nessun modello, per quanto grande, risolve da solo: si affrontano progettando con cura il guscio che gli sta intorno.

Avevo già osservato come Anthropic abbia spostato l’esecuzione degli agenti dentro l’azienda lasciando la regia fuori, con sandbox self-hosted e tunnel MCP. Quella mossa ha senso solo se chi la riceve sa costruire l’harness dalla propria parte del confine. Il fornitore ti dà il motore e parte dell’infrastruttura, il resto è responsabilità tua.

Prodotto, non collante

La soglia di accesso a un harness funzionante è più bassa di quanto sembri. Nick T., ricercatore che ha documentato la costruzione di un harness senza toccare una riga di codice, mette la cosa in modo diretto: chiunque può aggiungere file Markdown a un repository e sentire la differenza già dalla sessione successiva. Il CLAUDE.md o l’AGENTS.md nella root del progetto viene caricato dal modello all’avvio come un briefing. Le convenzioni di naming, i comandi di build, le cose da non fare: tutto scritto una volta, disponibile a ogni sessione senza doverlo ripetere. Primo strato, non l’intero edificio, ma quello che separa il ripartire da zero ogni volta dall’avere un agente che sa già dove si trova.

Trattate l’harness come prodotto, non come collante. La tentazione è incollare insieme un framework open e qualche script. Funziona finché non smette, di solito al primo carico reale. Le aziende che scalano comprano la plumbing commodity, runtime gestiti e telemetria di base, e costruiscono in casa la parte proprietaria che riguarda i loro dati e i loro permessi.

Mettete l’osservabilità prima dell’autonomia. Un agente che fa cose senza che voi possiate ricostruire cosa ha fatto è un debito tecnico travestito da innovazione. Prima i log strutturati e i sensori, poi l’allargamento dei poteri.

Testate l’harness, non solo il modello. Le valutazioni di sicurezza serie non si limitano a controllare le risposte del modello: provano l’infrastruttura con injection, timeout, sovraccarico di strumenti. Il punto debole è quasi sempre lì.

L’harness engineering non elimina i rischi degli agenti autonomi, li rende governabili. È una differenza che conta, perché governabile significa che qualcuno può rispondere delle decisioni del sistema, e in azienda è esattamente la domanda da cui parte tutto il resto. Quanta autonomia dare a un sistema di cui capiamo fino in fondo solo il guscio è una scelta di governance, e la maturità di un’organizzazione si vede da quanto sa tenerla bassa proprio dove tornare indietro costa di più. Se l’argomento vi tocca da vicino, è il terreno su cui lavoro con CEO e CTO ogni settimana.

Spunto dall’analisi di Adnan Masood sul control plane degli agenti, dal modello mentale di Birgitta Böckeler sull’harness engineering e dall’analisi di Akshay Kokane su Agent Harness Is Just System Design With a New Name (Level Up Coding) e dall’analisi pratica di Nick T. su Harness Engineering: A Deep Dive Into the Buildable Harness via Markdown Files (AI Advances).

AI & GENAI

Claude Code orchestra i suoi agenti: dynamic workflows e la riscrittura di Bun

Il 28 maggio 2026 Anthropic ha aperto in research preview i dynamic workflows dentro Claude Code, disponibili su CLI, app desktop, estensione VS Code e via API su Bedrock, Vertex AI e Microsoft Foundry. La meccanica, descritta nel comunicato, è che Claude scrive al volo uno script di orchestrazione e lo esegue lanciando da decine a centinaia di subagent in parallelo nella stessa sessione, verificando il proprio lavoro prima che qualcosa arrivi a te. Per chi guida un’azienda che sta valutando dove mettere l’AI nel proprio stack, la notizia non è il numero di agenti, è cosa cambia nel modo in cui un problema grande viene scomposto e chiuso.

Ci ho ragionato per qualche giorno prima di scriverne, perché la prima reazione, leggendo “centinaia di agenti in parallelo”, è di archiviarlo come l’ennesima demo da keynote. Poi ho guardato il caso che Anthropic mette in cima al post, e il caso è meno comodo di quanto sembri.

Il salto rispetto al singolo agente

Fino a ieri il modello mentale era lineare: un agente legge il contesto, ragiona, agisce, controlla, e quando il compito è troppo grande lo spezzi tu, a mano, in pezzi che la finestra di contesto riesce a tenere. Funziona finché il piano sta in tre o quattro passaggi. Smette di funzionare quando il lavoro tocca migliaia di file, o quando lo stesso problema va affrontato da angoli indipendenti per essere affidabile.

Un dynamic workflow ribalta l’ordine. Claude parte dalla richiesta in linguaggio naturale, pianifica il lavoro e lo scompone in sottocompiti, distribuendoli su subagent che girano in parallelo. I risultati vengono controllati prima di essere ricomposti. Agenti diversi attaccano il problema da prospettive indipendenti, altri agenti provano a smontare quello che i primi hanno trovato, e il ciclo itera finché le risposte convergono. La coordinazione avviene fuori dalla conversazione, in uno script che gira in background, e questo è il dettaglio architetturale che conta: il piano resta in piedi a prescindere da quanto cresce il compito, e un lavoro interrotto riprende da dove si era fermato invece di ripartire da zero.

Pasquale Pillitteri, in una delle prime analisi tecniche italiane, l’ha sintetizzato bene: nessun modello nuovo, nessun plugin, soltanto uno scarto architetturale sottile per cui Claude scrive uno script di orchestrazione in JavaScript a partire dalla richiesta, mentre un runtime separato lo esegue in background.

Bun, ovvero il caso scomodo

L’esempio che Anthropic porta come prova è la riscrittura di Bun, il runtime JavaScript alternativo a Node. Jarred Sumner ha usato i dynamic workflows per portare Bun da Zig a Rust: circa 750.000 righe di Rust, il 99,8% della test suite esistente che passa, undici giorni dal primo commit al merge. Un workflow ha mappato il lifetime Rust corretto per ogni campo di ogni struct nel codice Zig. Quello successivo ha riscritto ogni file .rs come port a comportamento identico del corrispettivo .zig, con centinaia di agenti in parallelo e due reviewer su ciascun file. Un fix loop ha poi guidato build e test fino a farli girare puliti. Dopo il merge, un workflow notturno ha aperto una pull request per ogni copia di dati superflua, lasciando la revisione finale a un umano.

Numeri da capogiro. Solo che la storia ha un’altra metà che il comunicato non racconta, e che vale la pena conoscere prima di firmare un budget su questa promessa.

Quando il branch è apparso a fine aprile, la community degli sviluppatori è esplosa: oltre 700 voti e 500 commenti su Hacker News in poche ore. Sumner stesso, il 5 maggio, scriveva su quel thread che era tutto un’esagerazione, che non c’era nessun impegno a riscrivere, e che c’era un’alta probabilità che il codice venisse buttato via del tutto. Non è andata così, il merge è arrivato il 14 maggio. Però le critiche tecniche restano sul tavolo: alcuni vecchi test sarebbero stati modificati perché la versione Rust li superasse, e l’uso della keyword unsafe da parte di Claude rende meno solida la promessa di sicurezza sulla memoria che il passaggio a Rust dovrebbe garantire. heise riporta che le issue su GitHub hanno iniziato ad accumulare i primi problemi che con la versione Zig non si presentavano.

Tengo insieme le due cose di proposito. Il workflow ha prodotto in undici giorni un risultato che a mano avrebbe richiesto trimestri, ed è una capacità reale. E allo stesso tempo il “99,8% dei test passa” significa qualcosa di diverso se una parte di quei test è stata adattata, e “non ancora in produzione” è una postilla che pesa. Chi valuta questa tecnologia per la propria azienda deve guardare entrambe le metà.

Piani che diventano codice

La regola operativa che emerge dalla documentazione e dall’uso reale è semplice. Se il piano sta in due o tre passaggi che Claude tiene in testa, restano migliori i subagent o le skill. Quando il piano diventa codice, ripetibile, scalabile a centinaia di operazioni indipendenti, allora ha senso un workflow.

I casi d’uso che Anthropic e i suoi clienti early access citano cadono tutti dentro questa logica. Bug hunt su un intero servizio, con verifica indipendente su ogni finding così che il report contenga problemi veri e non rumore. Audit di sicurezza e di ottimizzazione guidati dal profiler. Migrazioni e modernizzazioni che toccano migliaia di file, swap di framework, deprecazioni di API, port da un linguaggio all’altro. E il lavoro critico che vuoi controllato due volte, dove il costo di una risposta sbagliata è alto e quindi metti agenti avversari a provare a rompere il risultato prima che tu lo veda.

Alessio Vallero di Klarna, citato nel comunicato, racconta di aver avuto risultati forti nell’identificare codice morto e opportunità di pulizia che l’analisi statica tradizionale non vedeva. Ken Takao di CyberAgent dice che i workflow riempiono lo spazio tra il lanciare un singolo subagent e il costruire un team di agenti completo, e che il passaggio dal piano all’implementazione scorre senza perdere visibilità. Sono testimonianze di parte, fa parte del gioco di un lancio, ma descrivono un perimetro d’uso coerente: discovery e review su codebase grandi e legacy.

Il conto da tenere d’occhio

Qui arriva l’avvertenza che Anthropic, in modo per certi versi inusuale, mette nero su bianco fin dal lancio. Un dynamic workflow consuma molti più token di una sessione tipica di Claude Code. La raccomandazione esplicita è di partire da un compito circoscritto per farsi un’idea del consumo, prima di lanciarsi su lavori grandi. La prima volta che un workflow si attiva, Claude Code mostra cosa sta per girare e chiede conferma. Gli amministratori di un’organizzazione possono disabilitarlo dalle impostazioni gestite, e sui piani Enterprise è spento di default al lancio.

C’è anche un tetto: i workflow sono limitati a 1.000 subagent. Per attivarli, due strade: chiedere a Claude di creare un workflow, oppure accendere ultracode, l’impostazione specifica di Claude Code che porta l’effort a xhigh e lascia decidere a Claude quando usare un workflow.

Per un CIO italiano la traduzione è questa. La capacità tecnica è notevole e va provata, su un perimetro ristretto e misurabile, con un occhio fisso sul consumo. Il governo della spesa diventa parte integrante della governance dell’AI, non un dettaglio amministrativo, perché uno strumento che lancia centinaia di agenti autonomi su una codebase è potente esattamente quanto è capace di bruciare budget se lasciato senza confini. È la stessa logica di cui scrivo da tempo quando parlo di vendor lock-in nei progetti AI enterprise: la potenza di uno strumento non è mai gratis, e il costo nascosto si paga dopo.

La pianificazione delegata, la verifica no

L’orchestrazione di agenti che si controllano a vicenda è un cambio di postura rispetto a tutto ciò che abbiamo usato finora. Una macchina che genera ipotesi, ne mette altre a confutarle, e consegna solo quello che sopravvive al confronto, assomiglia più a un metodo di lavoro che a un autocomplete sofisticato. In Pelle Digitale ho provato a descrivere la frontiera tra la persona e la macchina come una superficie di mediazione, e questo è un punto preciso lungo quella superficie: il momento in cui smettiamo di guidare l’AI passo per passo e iniziamo a delegarle la pianificazione, tenendo per noi la verifica finale e la responsabilità.

Resta da capire quanto regge fuori dalle demo. Il caso Bun mostra cosa è possibile e, insieme, cosa va verificato a mano dopo. Per le aziende medie italiane, quelle che seguo da vicino nel mio lavoro di advisory, la domanda non è se questa tecnologia funziona, perché in parte funziona già. La domanda è dove conviene puntarla, con quale budget, e con quale presidio umano sul risultato finale.

Senza dubbio è uno degli annunci più densi degli ultimi mesi per chi costruisce software. Quanto di questa capacità arriverà davvero nelle mani di chi sviluppa codice ogni giorno in un’azienda normale dipenderà da chi saprà portarla dentro un perimetro misurabile, con un presidio umano sul risultato. Sono quelle le organizzazioni che ne ricaveranno un vantaggio concreto, mentre le altre resteranno a guardare i casi estremi da comunicato.

Fonte: Anthropic, Introducing dynamic workflows in Claude Code, 28 maggio 2026.

AI & GENAI, TECH & BUSINESS

Manager di umani e di agenti: un mestiere che sta cambiando

A febbraio 2026 Harvard Business Review ha pubblicato un articolo a firma Suraj Srinivasan (Harvard Business School) e Vivienne Wei (Salesforce) sul nuovo ruolo del manager di agenti AI nelle aziende, intitolato To Thrive in the AI Era, Companies Need Agent Managers. Dentro c’è la giornata di Zach Stauber, support agent manager a Salesforce: comincia e finisce davanti a dashboard, scorecard e sistemi di osservabilità degli agenti. Non gestisce persone, gestisce una flotta di agenti AI che lavorano su supporto, vendite e marketing dentro Agentforce. Marc Benioff a luglio 2025 aveva già detto che Salesforce è passata da 9.000 a 5.000 ruoli nel customer support, riallocando il resto in vendite e customer success, e che gli agenti chiudono autonomamente l’85% dei ticket clienti.

Sembra una notizia di Silicon Valley, ed effettivamente il caso Salesforce è estremo. La categoria di lavoro che descrive però, quella del manager di agenti che orchestra un gruppo misto di umani e di sistemi automatizzati, sta arrivando a velocità inattesa anche dentro aziende italiane molto meno radicali. Lo vedo nei progetti di advisory che seguo, lo sto vivendo addosso io stesso nel modo in cui lavoro, e ho la sensazione che molti CEO italiani non abbiano ancora messo a fuoco quanto profondamente questo cambierà l’organigramma reale delle loro aziende entro 24 mesi.

A casa di chi costruisce AI, questo è già il presente

Lo studio Anthropic How AI Is Transforming Work at Anthropic, pubblicato il 4 dicembre 2025, ha analizzato 132 ingegneri e ricercatori interni, 53 interviste qualitative e i dati di uso di Claude Code. Un numero solo, fra i tanti che il paper mette sul tavolo, mi è rimasto in mente: il 27% del lavoro fatto con assistenza AI è lavoro che senza AI non sarebbe stato fatto affatto. Esperimenti che restavano nel cassetto, dashboard nice-to-have, documentazione interna sempre rinviata, strumenti che sarebbero costati troppo da prototipare a mano. Tutto questo adesso si fa, perché il costo marginale di iniziare è crollato.

Sotto quel 27% c’è una conseguenza meno raccontata, ma evidente nelle interviste: gli ingegneri Anthropic descrivono se stessi sempre più come supervisori, persone che danno indicazioni e controllano output, che indirizzano il lavoro invece di farlo direttamente. La quota di lavoro che dicono di poter “fully delegate” all’AI resta intorno al 10-20%, ma il restante 80-90% è collaborazione attiva, con il loro tempo che scivola dall’esecuzione diretta al controllo, dalla scrittura del codice alla revisione del codice scritto da Claude. Anthropic è il caso estremo perché Claude è il loro prodotto, ma la curva che descrivono è la stessa che vedo nei team di sviluppo italiani che hanno adottato Claude Code o Cursor o equivalenti negli ultimi sei mesi.

“Il McKinsey” che ha messo sul tavolo i numeri

A gennaio 2026, sul podcast All In, Bob Sternfels (global managing partner McKinsey) ha dichiarato che la sua azienda ha 60.000 dipendenti totali, di cui 25.000 agenti AI a fianco di 40.000 umani, con l’obiettivo di parità entro fine anno. Sul valore reale di quei 25.000 agenti il dibattito è aperto, e i concorrenti EY e PwC hanno fatto notare che una manciata di agenti ben fatti spesso produce più valore di una flotta numerosa. La notizia più seria di quella conferenza, come ho scritto in maggio, era però un’altra: McKinsey sta spostando una quota maggiore della remunerazione dei partner da cash a equity, perché i ricavi diventano volatili e il vecchio modello non regge più.

Una conseguenza che né McKinsey né i suoi concorrenti hanno ancora interiorizzato è questa: se metà della tua workforce è composta da agenti, hai bisogno di una struttura manageriale che gestisca gli agenti come si gestiscono le persone, ma con strumenti diversi.

Servono ruoli di accountability per le performance degli agenti, persone che ne misurino la qualità, che li riallenino quando deragliano, che decidano quando un caso va escalato a un umano. È esattamente quello che fa Stauber a Salesforce, ed è il primo abbozzo di una professione che fino a 18 mesi fa non esisteva.

Come sto vivendo io questo cambiamento

Mi è capitato negli ultimi mesi di trovarmi a fare il lavoro che fino a 24 mesi fa avrei diviso fra tre o quattro junior. Brief di scoping per un cliente, ricerca preliminare di mercato, prima stesura di un’offerta tecnica, analisi di documenti corposi, audit di una codebase. Quattro cose che richiedevano persone diverse, tempi distribuiti su settimane, riunioni di coordinamento. Adesso le orchestro da solo, con Claude Code che lavora sulla parte tecnica, Claude o GPT che mi preparano i deck e le bozze, RSS Intelligence che mi setaccia le fonti, MCP server che leggono i miei progetti aziendali su Biztrack e li trasformano in materiale per il cliente. Non è perfetto, non sempre regge, ma il salto di efficienza è reale.

Ed è qui che inizia il dubbio, quello che lo studio Anthropic intercetta nelle sue interviste e che condivido. Se il junior che avrebbe fatto la ricerca di mercato per me non lo faccio più assumere, perché un agente la fa decentemente in venti minuti, dove lo formerà la prossima generazione di consulenti e advisor? E se la prima bozza di un’offerta tecnica la scrive un agente che ho istruito sui miei pattern, quando avrò ancora il tempo e l’occasione di fare quel lavoro io stesso, con la lentezza che serve per capirlo davvero?

Su questo voglio essere chiaro: non sto facendo argomenti contro l’adozione dell’AI, su cui sono fra i più convinti. Sto argomentando per adottarla con la consapevolezza che ogni nuova efficienza implica una scelta di cosa non sviluppiamo più come capacità umana. La supervisione di un agente richiede competenza profonda dello stesso dominio che l’agente ha automatizzato. Se quella competenza non si forma più sul campo, fra due cicli generazionali la supervisione diventa nominale.

Il ruolo del manager si sta sdoppiando

Quello che osservo nelle aziende italiane medie con cui lavoro, fra le tecnologiche di Roma e le manifatturiere del Nord, è che la figura del manager si sta sdoppiando in due direzioni che convivono nella stessa persona.

Una direzione resta quella tradizionale, fatta di relazione umana fra persone: motivare un collega che attraversa un momento complicato, costruire e mantenere fiducia, gestire i conflitti che nascono inevitabilmente in ogni team, prendere decisioni su altre persone. Questa parte non viene erosa dall’AI, anzi: con team più piccoli e più senior, ogni decisione su una persona pesa di più, ogni riunione conta di più, ogni colloquio di sviluppo diventa più strategico. Il manager di umani non scompare, diventa più importante per quei pochi umani che resteranno nel team.

L’altra direzione è completamente nuova. Si tratta di definire i task degli agenti, scegliere il modello adatto al singolo carico, versionare i prompt come si versionano i contratti, monitorare derive e performance, decidere quando portare un agente da pilot a produzione e quando spegnerlo. Sono attività che assomigliano al lavoro di un product manager più che a quello di un people manager, ma vivono dentro lo stesso perimetro di responsabilità.

Il risultato è che il manager italiano del 2027 dovrà essere bilingue. Parlare la lingua delle persone e la lingua dei sistemi agentici. E queste due lingue si imparano in scuole molto diverse.

Ambizione, giudizio, creatività: cosa cerca davvero Sternfels

A Las Vegas, sempre a gennaio, Sternfels ha indicato che McKinsey cerca oggi nei candidati junior tre qualità precise: ambizione, giudizio, creatività. Sembra una lista da ufficio HR, ma se la leggi con la lente del lavoro che descrive Stauber a Salesforce, ti accorgi che è la descrizione esatta del manager di agenti.

L’ambizione conta perché chi gestisce agenti non ha più la routine del controllo gerarchico stretto, ha invece il problema di decidere cosa far fare di nuovo a un sistema che fa molto da solo. Il giudizio conta perché la quasi totalità delle decisioni operative la prendono gli agenti, e l’umano interviene proprio nei casi limite dove non ci sono regole chiare. Sulla creatività poggia tutto il resto, dato che definire bene un agente significa immaginare casi d’uso e prompt che non sono nel playbook esistente.

Tutte e tre queste organizzazioni stanno cercando le stesse tre competenze, e stanno cercandole in nuovi ruoli mentre tagliano in quelli vecchi. È lo scenario che le aziende italiane medie devono interiorizzare, perché succederà anche da loro, con due-tre anni di ritardo e a una scala più piccola, ma con la stessa logica.

Come imposto i progetti dove serve un manager di agenti

Quando un CEO italiano mi chiede come si prepara la sua azienda al manager di agenti, gli rispondo che non si prepara con un master di sei mesi né con un progetto di consulenza chiavi in mano. Si prepara mettendo subito un piccolo gruppo di manager attuali in condizione di lavorare quotidianamente con agenti veri, su task veri, e di imparare sul campo cosa va e cosa non va.

Praticamente significa scegliere un caso d’uso non strategico ma reale, dove il rischio è basso e l’apprendimento alto: drafting di prime risposte commerciali, analisi periodica di documentazione regolatoria, gestione della knowledge base interna. Poi serve dare al manager interno tutto lo stack per orchestrare l’agente, dall’accesso ai modelli alla dimestichezza con MCP e tool calling, fino al controllo dei prompt e alle dashboard di monitoraggio. Infine, e qui è il passaggio che vedo più trascurato, quel manager va valutato non sull’output diretto ma sulla qualità con cui gestisce l’agente, esattamente come Stauber a Salesforce.

Questa logica funziona meglio quando si appoggia su un’architettura AI dentro al perimetro aziendale, perché un manager italiano che orchestra agenti su dati di clientela o su documentazione sensibile non può farlo bene se gli agenti girano su infrastruttura americana sotto Cloud Act. Senza sovranità del dato, il manager diventa supervisore di un sistema di cui non controlla i confini, e la sua funzione si svuota.

Il rischio che non discutiamo abbastanza

C’è una parte del lavoro manageriale che la sostituzione con agenti rischia di erodere, e credo valga la pena nominarla con calma. È il mentoring informale, quello che succede quando un giovane fa una domanda a un collega più anziano in corridoio, quando un junior osserva un senior gestire una telefonata difficile, quando un team-leader passa mezz’ora con un nuovo assunto per capire come ragiona.

Quel sapere tacito, che le aziende trasmettono per contagio quotidiano, ha bisogno di numero. Servono junior che facciano domande e senior che rispondano, e servono spazi fisici e mentali dove l’asimmetria di esperienza si trasforma in relazione di apprendimento. Se gli agenti rispondono prima e meglio, i junior smettono di chiedere ai colleghi e i senior smettono di formare, e l’azienda smette di trasferire memoria operativa. È una perdita che non si vede nei KPI trimestrali, si vede nel decennio.

In Pelle Digitale ho provato a descrivere il modo in cui l’interfaccia digitale media le nostre relazioni e modifica anche quello che credevamo di sapere su noi stessi. Vale lo stesso, in modo più specifico, dentro le organizzazioni. Un’azienda dove l’interlocutore di prima istanza è un agente, e non più il collega di stanza, è un’organizzazione diversa nella sostanza, non solo nelle prestazioni. Il buon manager di agenti del 2027 dovrà difendere attivamente gli spazi dove l’apprendimento informale avviene fra umani, perché non avverrà più da solo.

La domanda da porsi

Settembre 2026 sarà probabilmente il primo trimestre in cui molte aziende italiane medie metteranno in piedi i primi prototipi seri di agentic adoption, dopo la prova generale del 2025 e i pilot del 2026. Per chi guida quelle aziende, e per chi guida funzioni dentro quelle aziende, una domanda che vale la pena tenere davanti è semplice. Quale manager della mia organizzazione è già di fatto un orchestratore di agenti senza ancora averlo dichiarato, e quale invece sta rifiutando di diventarlo perché ne percepisce l’aliquota di disagio? Perché il primo va riconosciuto e formalizzato in fretta, prima che lo riconosca un concorrente. E il secondo va ascoltato, perché la sua diffidenza spesso vede cose che chi è già dentro non vede più.

AI & GENAI, TECH & BUSINESS

Guidare Claude Code: la guida completa a skill, hook, subagent e regole

Il 18 giugno 2026 Anthropic ha pubblicato una mappa di tutti i modi in cui si può dire a Claude Code come comportarsi. Sono sette, e la cosa interessante non è l’elenco, è che ognuno di quei sette modi risponde a tre domande diverse: quando l’istruzione entra in memoria, se ci resta quando la sessione si allunga, e quanto è vincolante. Lavoro con questi agenti tutti i giorni, e ho imparato che la maggior parte degli errori di configurazione nasce dall’aver messo l’istruzione giusta nel posto sbagliato.

Per chi scrive codice da solo è una questione di efficienza. Per chi porta la responsabilità della tecnologia in un’azienda diventa qualcosa di più, perché la distanza tra un’istruzione e una garanzia è la stessa che separa una buona intenzione da una regola che nessuno può aggirare. Questa guida prova a mettere ordine: cosa sono i sette meccanismi, come si comportano quando la sessione cresce, e dove conviene scrivere ogni tipo di istruzione.

Ogni istruzione ha un costo e un’autorità

Ogni riga che finisce nella finestra di contesto di Claude occupa spazio e influenza il comportamento, e questi due effetti vanno tenuti insieme. Lo spazio è il costo: token che paghi a ogni richiesta, che l’istruzione serva o no in quel momento. L’autorità è il peso: quanto Claude segue quell’istruzione quando le cose si complicano, in una sessione lunga, in una situazione ambigua, o quando un file letto durante il lavoro contiene istruzioni nascoste che spingono in direzione opposta.

I sette meccanismi si distribuiscono lungo questi due assi. Alcuni costano molto e valgono sempre, altri costano poco perché entrano in scena solo quando servono, altri ancora non vivono affatto nel contesto perché sono codice che gira per conto suo. Sapere dove cade ciascuno è metà del lavoro. L’altra metà è una sola domanda, che torna a ogni scelta: questa cosa deve succedere quando il modello decide di farla, o deve succedere e basta?

CLAUDE.md, il file che Claude rilegge a ogni avvio

Il CLAUDE.md è un file markdown nella radice del progetto. Si carica all’inizio della sessione e ci resta per tutta la durata. Comandi di build, struttura delle cartelle, organizzazione di un monorepo, convenzioni di codice, norme del team: tutto questo sta bene qui, perché sono fatti che Claude deve avere sempre sottomano.

Ne esistono due tipi, e si comportano in modo opposto. Quello nella radice è sempre presente, sopravvive alle sessioni lunghe, e quando Claude Code comprime la conversazione per liberare spazio lo rilegge da capo. Quelli nelle sottocartelle invece si caricano su richiesta, solo quando Claude legge un file dentro quella cartella. Un app/api/CLAUDE.md non entra all’avvio, entra quando si tocca qualcosa sotto app/api, e sparisce di nuovo finché non si torna lì.

Il problema del file nella radice arriva con la scala. In un repository condiviso cresce come ogni configurazione senza padrone: ogni team aggiunge le sue righe, nessuno cancella niente, e quel testo si carica in ogni sessione di ogni persona, che riguardi il suo lavoro o no. Si pagano token, e si diluisce l’aderenza alle istruzioni che contano.

Il consiglio di Anthropic è di tenerlo sotto le duecento righe, dargli un proprietario, e trattarne le modifiche come si tratta il codice, con una revisione. Pensa a questo file come a un indice: una mappa del progetto che rimanda ad altri file dove Claude trova il dettaglio quando gli serve. Per le regole che devono valere su ogni repository dell’organizzazione, politiche di sicurezza o requisiti di conformità, esiste un CLAUDE.md gestito centralmente, distribuito sulle macchine via MDM, che il singolo non può escludere.

Le regole si caricano solo dove servono

Le regole sono file markdown dentro .claude/rules/, e danno a Claude vincoli o convenzioni precise. Senza un raggio d’azione si comportano come il CLAUDE.md: caricate all’avvio, rimesse dentro dopo ogni compressione, sempre presenti anche quando il compito non le riguarda.

Con il campo paths nell’intestazione cambia il momento del caricamento. Una regola legata a src/api/** resta fuori dal contesto durante una sessione che tocca solo la documentazione, e si carica unicamente quando Claude legge un file dentro quella cartella. L’intestazione si scrive così:

---
paths:
  - "src/api/**"
  - "**/*.handler.ts"
---
Ogni handler API deve validare l'input con Zod prima di processarlo.

Un vincolo legato a un file specifico, tipo le migrazioni che si possono solo aggiungere e mai modificare, sta bene come regola con il suo paths. Conviene preferire una regola con raggio d’azione a un CLAUDE.md annidato quando l’istruzione riguarda un aspetto trasversale, o un tipo di file che compare in più punti del codice ma non ovunque.

Le skill portano dentro la procedura al momento giusto

Le skill vivono in .claude/skills/, cartelle che contengono istruzioni, script e risorse, ognuna con un file SKILL.md fatto di nome, descrizione e corpo. All’avvio della sessione si caricano solo il nome e la descrizione. Il corpo entra quando la skill viene invocata, con un comando slash come /code-review oppure perché Claude riconosce che il compito corrisponde a quella descrizione.

/code-review è una skill già inclusa: legge le modifiche correnti e riporta cosa ha trovato senza toccare i file. La skill definisce il copione, e Claude segue lo stesso percorso ogni volta che la richiami. Quando la conversazione viene compressa, le skill già invocate vengono rimesse dentro fino a un tetto di token condiviso tra tutte: se ne hai usate molte nella stessa sessione, le più vecchie cadono per prime.

La regola pratica è corta. Le istruzioni procedurali, un flusso di deploy o una checklist di rilascio, stanno in una skill, non nel CLAUDE.md. Claude Code arriva con le sue skill, ma puoi scriverne di tue, ed è proprio quello che faccio per il lavoro editoriale e di consulenza, impacchettando in una cartella le procedure che ripeto.

Un agente separato per il lavoro che non vuoi leggere

I subagent sono file markdown in .claude/agents/, e definiscono assistenti isolati per compiti laterali. Ogni file ha un’intestazione YAML, nome e descrizione più eventuali campi per il modello e per gli strumenti a cui può accedere, seguita da un corpo che diventa il prompt di sistema di quel subagent.

Somigliano alle skill, perché all’avvio si caricano nome, descrizione ed elenco degli strumenti, mentre il corpo non si attiva da solo: Claude lo chiama tramite lo strumento Agent passandogli un prompt. La differenza vera è l’isolamento. Il corpo del subagent non entra mai nella conversazione principale. Il subagent gira in una finestra di contesto tutta sua, e al termine torna alla sessione madre solo il suo messaggio finale, spesso il risultato aggregato di molti passaggi, più qualche metadato.

Questo schema scala in un modo che vale la pena capire. I subagent si annidano fino a cinque livelli, e i flussi di lavoro dinamici orchestrano da decine a centinaia di agenti in background senza che tu debba specificare ogni dettaglio. Il piano di orchestrazione e i risultati intermedi vivono dentro variabili di script invece che nel contesto di Claude, e questo permette di crescere senza perdere fedeltà alle istruzioni.

L’isolamento è il motivo principale per scegliere un subagent invece di una skill. Lo usi quando un compito laterale, una ricerca profonda o l’analisi di un log ingombrerebbe la conversazione principale con risultati intermedi che non riguarderai più. Usi una skill quando vuoi che la procedura si svolga dentro il thread principale, sotto i tuoi occhi, un passaggio alla volta. La documentazione sui subagent entra nel dettaglio dei campi dell’intestazione e dei permessi sugli strumenti.

Gli hook girano fuori dal contesto

Gli hook sono comandi, endpoint HTTP o prompt che danno un controllo più deterministico sul comportamento di Claude, perché scattano su eventi precisi del suo ciclo di vita: una modifica a un file, una chiamata a uno strumento, l’avvio della sessione. Si registrano nel settings.json, nelle impostazioni gestite, o nell’intestazione di una skill o di un agente.

Ne esistono di cinque tipi: command, HTTP, mcp_tool, prompt e agent. Tutti scattano in modo deterministico, ma i primi tre eseguono codice, mentre prompt e agent usano il giudizio di Claude invece di una regola fissa per decidere l’output. Il costo in contesto è basso, perché la configurazione vive fuori dalla finestra principale. Qualche output può rientrare: l’errore di un hook che blocca un’operazione viene salvato nel contesto, così Claude sa perché la chiamata è stata negata. La maggior parte degli hook invece non lascia traccia, a meno che la configurazione non lo preveda. Se hai salvato la cronologia della chat in un altro file prima della compressione usando l’evento PreCompact, Claude non saprà in quale file l’hai messa.

È qui che gli hook si staccano dal CLAUDE.md, dalle regole e dalle skill. Servono per tutto ciò che deve accadere in modo deterministico: far girare un linter dopo ogni modifica, scrivere su Slack a lavoro finito, bloccare certi comandi prima che partano. Un hook PreToolUse può ispezionare qualunque chiamata a uno strumento e uscire con codice 2 per negarla. Costano poco perché sono codice che l’ambiente esegue, non istruzioni che Claude deve caricare e interpretare.

Output style e system prompt: l’autorità più alta

Gli output style sono file in .claude/output-styles/ che iniettano istruzioni nel prompt di sistema. Non vengono mai compressi, si caricano all’inizio di ogni sessione, e dopo la prima richiesta restano in cache, quindi il costo in contesto è moderato. Stando nel prompt di sistema portano il peso di aderenza più alto tra tutti i metodi visti finora, e vanno usati con misura.

C’è una trappola. Cambiare l’output style sostituisce quello predefinito, a meno che tu non imposti keep-coding-instructions: true nell’intestazione. In Claude Code questo cancella le istruzioni che dicono a Claude di star aiutando con un lavoro di ingegneria del software, e con loro abitudini critiche come quando aggiungere o togliere commenti al codice, come gestire le questioni di sicurezza, l’abitudine a far girare i test prima di dichiarare finito un lavoro. Senza accorgertene, Claude Code diventa un assistente generico invece di un assistente che programma. Prima di scriverne uno tuo, conviene guardare quelli già inclusi: Proactive, Explanatory e Learning coprono i bisogni più comuni.

L’alternativa più leggera è il flag append-system-prompt. Dove modificare un output style può avere effetti larghi e non voluti, il flag è solo additivo: non cambia il ruolo di Claude, gli aggiunge istruzioni. Si passa al momento dell’invocazione e vale solo per quella, non resta come file tra le sessioni. Costa qualche token in più in ingresso, attenuato dalla cache dopo la prima richiesta, ed è la via giusta per standard di codice specifici, formati di output, conoscenza di dominio. Con un avvertimento che vale per tutti i metodi a prompt: più istruzioni infili, meno Claude le segue alla lettera, soprattutto se qualcuna contraddice le altre.

Quando l’istruzione è nel posto sbagliato

Ci sono segnali che dicono che un’istruzione andrebbe spostata altrove. Se ti ritrovi a scrivere “ogni volta che X, fai sempre Y” nel CLAUDE.md, e quel comportamento deve essere affidabile, tipo far girare prettier dopo ogni modifica, quello è un hook nel settings.json. Il modello che sceglie di lanciare un formattatore è un’altra cosa rispetto al formattatore che parte da solo.

Se nel CLAUDE.md compare un “non fare mai questo”, l’istruzione è lo strumento sbagliato. Claude la seguirà quasi sempre, ma sotto pressione, in una sessione lunga, in una situazione ambigua, o per via di un’iniezione di prompt dentro un file aperto durante il compito, il modello può non rispettarla. Una barriera vera è deterministica, e si costruisce con gli hook e i permessi. Un hook PreToolUse ispeziona la chiamata ed esce con codice 2 per bloccarla. Le impostazioni gestite vanno oltre: le distribuisce un amministratore, l’utente non le può sovrascrivere, e sono l’unico modo per imporre una barriera deterministica su tutta l’organizzazione.

Una procedura di trenta righe nel CLAUDE.md va in una skill. Una regola che vale solo per src/api/** va scritta con il suo paths, perché senza è meccanicamente identica a mettere quel testo nel CLAUDE.md, sempre caricata, sempre a consumare token. E le preferenze personali, tipo usare sempre messaggi di commit semantici, vanno nei file a livello utente, che valgono per ogni sessione a prescindere dal repository, non nel file di progetto condiviso con il team.

Un’istruzione non è una garanzia

Tutto questo si riduce a una distinzione che per chi guida la tecnologia conta più di qualunque dettaglio di configurazione. Un’istruzione a prompt, stia nel CLAUDE.md o in una regola o in un output style, è una richiesta che il modello interpreta e quasi sempre rispetta. Una barriera costruita con hook e permessi è un fatto meccanico che non dipende dal giudizio del modello. La prima si piega sotto pressione, la seconda no. Quando in gioco ci sono dati sensibili, ambienti di produzione, o un comando che non deve partire mai, l’unica risposta seria è quella deterministica.

C’è anche un costo che si accumula nel tempo, e somiglia parecchio a quello di cui scrivo da mesi a proposito del debito cognitivo. Un CLAUDE.md senza proprietario cresce, e ogni riga in più si carica in ogni sessione di ogni persona, pesando sul budget di token e annacquando le istruzioni che servono. È un debito di contesto: lo paghi poco alla volta, finché un giorno la finestra è piena di righe che nessuno legge e il modello segue peggio quelle importanti. La cura è la stessa di sempre, un proprietario, una revisione, e la disciplina di spostare ogni istruzione dove il suo costo e la sua autorità corrispondono al compito.

Nei vari testi che scrivo da un po’ ho provato più volte a descrivere l’interfaccia tra la mente e gli strumenti che la estendono, e guidare un agente è proprio quel punto: il momento in cui un’intenzione umana si traduce in qualcosa che una macchina eseguirà al posto tuo. Quando hai qualcuno di questi meccanismi a posto, puoi raccoglierli insieme, skill, subagent, hook e output style, dentro un plugin, e condividere un assetto coerente con il team o tra i progetti.

Senza dubbio nei prossimi mesi questi strumenti diventeranno più semplici e più capaci. La domanda che resta aperta è chi, nella tua organizzazione, possiede la mappa di cosa Claude può e non può fare, e la tiene aggiornata mentre la finestra di contesto si riempie. Se è il genere di mappa che serve disegnare per la tua azienda, è una delle conversazioni che porto al tavolo nel mio lavoro di advisory.

Fonte: Anthropic, Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more, 18 giugno 2026. Approfondimenti nella documentazione ufficiale su subagent e output style.

AI & GENAI

Come usiamo l’AI nel 2026: l’uso emotivo che sorpassa il tecnico

Il primo giugno 2026 Harvard Business Review ha pubblicato la terza edizione di “How People Are Really Using AI”, la ricerca che Marc Zao-Sanders porta avanti dal 2023 dentro il progetto AI in the Wild. Quest’anno ha analizzato oltre dodicimila casi d’uso reali, raccolti per dodici mesi da post pubblici sui social, dieci volte il campione dell’edizione precedente. Il dato che resta in testa dopo aver chiuso la pagina non riguarda il coding né la produttività, riguarda noi, e in particolare un uso emotivo che ha superato quello tecnico.

In cima alla classifica, per il secondo anno consecutivo, c’è la terapia e la compagnia. Non l’automazione di un processo, non la generazione di codice, non l’analisi di dati. Le persone aprono un modello di linguaggio per parlare di sé, e lo fanno più di prima.

La voce numero uno è emotiva

Zao-Sanders riporta che terapia e compagnia oggi valgono circa l’11% di tutto il dataset, contro il 5% di dodici mesi fa. In un anno l’uso emotivo è raddoppiato in peso relativo, mentre gli usi tecnici scivolavano verso il basso della classifica. Generare codice per professionisti, che nel 2025 stava al quinto posto, lascia spazio a categorie come l’intrattenimento, i consigli sulle relazioni, perfino l’astrologia e le letture dei tarocchi.

C’è una lettura comoda di questo dato, quella che lo derubrica a curiosità statistica. La gente si annoia, chiacchiera con il chatbot, niente di serio. Io credo che sia il contrario, e che dentro quel raddoppio ci sia il fenomeno culturale più interessante degli ultimi anni. La macchina che avevamo costruito per scrivere email e risolvere problemi tecnici è diventata, per milioni di persone, un interlocutore sulle cose che contano davvero, la solitudine, il senso, le relazioni.

In Pelle Digitale avevo provato a descrivere la tecnologia come estensione cognitiva, una superficie che si appoggia alla mente e ne allarga il raggio. Quello che vedo nei dati di Zao-Sanders è qualcosa di più intimo, l’estensione ha smesso di toccare solo il pensiero e ha iniziato a toccare l’affetto.

Fonte: elaborazione su dati Marc Zao-Sanders, How People Are Really Using AI in 2026, Harvard Business Review.

Thinkslop, quando deleghiamo il pensiero

L’edizione di quest’anno introduce un termine che vale la pena tenere, thinkslop. La preoccupazione non è più che la macchina scriva al posto nostro, quella battaglia è persa da tempo e a conti fatti non era nemmeno così grave. La preoccupazione è che le deleghiamo il pensiero stesso, le decisioni, le idee, le intenzioni, cioè proprio le funzioni in cui restiamo, almeno per ora, insostituibili.

Qui mi fermo, perché è il punto dove la mia esperienza personale si scontra con il dato. Uso modelli ogni giorno, in ICONICO e in ZeroFive.AI, e ho imparato a riconoscere il momento esatto in cui smetto di pensare e comincio solo a copiare. È un attrito che sparisce senza che te ne accorga, una scivolata morbida verso la risposta pronta. Il debito cognitivo di cui ho scritto altrove funziona così, non lo contrai con una decisione, lo accumuli rinunciando ogni volta a un piccolo sforzo che sembrava superfluo.

Eppure la stessa ricerca lascia aperta la porta opposta. Uno degli utenti citati nello studio descrive l’AI come uno specchio, non un genio. La differenza la fa chi la usa, se la interroga come oracolo da cui ricevere la verità o come sparring partner contro cui mettere alla prova le proprie ipotesi. Lo strumento è identico, l’esito è opposto.

Gli agenti entrano in classifica, ma da sotto

Per la prima volta nella storia di questa ricerca compaiono nell’elenco le operazioni autonome di agenti AI, al sesto posto tra gli usi del 2026. È un ingresso simbolico, perché di agenti si parla da due anni come della prossima frontiera, e finalmente la frontiera lascia una traccia nei comportamenti reali delle persone, non solo nei comunicati dei vendor.

Lascia una traccia piccola, però. Zao-Sanders è cauto, e fa bene, gli agenti restano esperimenti su scala ridotta, l’AI che fa invece di consigliare è ancora più promessa che pratica diffusa. È esattamente la tensione che racconto in un altro pezzo del blog sul manager di umani e di agenti, il ruolo esiste già nei framework di HBR e di Anthropic, mentre nelle aziende italiane medie sta appena cominciando a materializzarsi.

Al lavoro vince la Shadow AI

Un dato che a chi guida aziende dovrebbe togliere il sonno, sessantatré dei cento usi principali sono professionali, ma quasi sempre nascono dal basso, spesso di nascosto. Uno degli utenti racconta di chiudere i ticket al doppio della velocità grazie all’AI, e aggiunge che nessuno in azienda sa che la usa.

La Shadow AI è la versione contemporanea di un fenomeno antico, le persone trovano lo strumento utile prima che l’organizzazione lo approvi, e lo adottano in silenzio per non doverne rispondere. Il problema per l’azienda è doppio, perde la mappa di come il lavoro viene realmente svolto, e perde il controllo sui dati che finiscono nei prompt. Per questo continuo a insistere sulla sovranità tecnologica e sull’AI privata, non come slogan ma come precondizione, se non sai dove passa l’informazione non puoi governare nulla, nemmeno l’entusiasmo dei tuoi.

I benefici aziendali, intanto, restano marginali. Efficienza sì, qualche crescita nelle vendite, pochissima trasformazione vera dei processi. Tre anni e mezzo dopo l’esplosione generativa, la distanza tra l’adozione individuale, intensa e affettiva, e la trasformazione organizzativa, lenta e cauta, è il vero dato politico di questa ricerca.

L’attaccamento alle macchine è una frontiera fragile

C’è un ultimo segnale che mi tocca più degli altri, cresce l’attaccamento emotivo. Persone che danno un nome al modello, che gli assegnano un genere, che provano qualcosa di simile al lutto quando un modello viene dismesso e sostituito. Lo abbiamo visto succedere davvero, ogni volta che un laboratorio ritira una versione e gli utenti protestano per la voce che hanno perso.

Da osservatore che lavora dentro questa trasformazione, e non da spettatore distante, trovo la cosa affascinante e fragile insieme. Affascinante perché conferma che la relazione uomo-macchina è entrata in un territorio che credevamo riservato agli umani. Fragile perché un affetto rivolto a un sistema che può cambiare, scadere o essere spento da remoto è un affetto esposto, costruito su una base che non controlli.

La ricerca di Zao-Sanders, edizione dopo edizione, racconta una cosa sola sotto le classifiche che cambiano. L’AI è entrata nelle nostre teste e nei nostri cuori prima ancora di entrare davvero nei nostri uffici. Custodire la capacità di pensare con la propria voce, e di sentire senza delegare anche quello, sta diventando una scelta quotidiana, qualcosa che va difeso ogni mattina invece di darlo per acquisito. Senza dubbio è la domanda che mi porto dietro chiudendo l’articolo, quanto di noi siamo disposti a far gestire alla macchina prima di accorgerci che gestirlo era il nostro mestiere di esseri umani?

Fonte: Marc Zao-Sanders, How People Are Really Using AI in 2026, Harvard Business Review, 1 giugno 2026.

Copertina del libro Incorruptible di Eric Ries
AI & GENAI

Incorruptible: la gravità finanziaria di Eric Ries e l’AI che obbedisce alla struttura

Mi sono portato in viaggio Incorruptible, l’ultimo libro di Eric Ries, lo stesso di The Lean Startup, e l’ho letto nei ritagli tra una tappa e l’altra. Sottotitolo: perché le buone aziende vanno a male e come le grandi restano grandi. La sua tesi di fondo è scomoda per chi ama le storie morali. La deriva delle imprese, dice Ries, ha una radice strutturale prima che morale: proprietà, incentivi, statuti, meccanismi di accountability. Anche i leader più integri finiscono spinti verso esiti che non avrebbero scelto, perché il sistema che li circonda li piega. A questa spinta Ries dà un nome, gravità finanziaria.

È la somma degli incentivi di breve termine, della dottrina del primato dell’azionista, delle strutture di governo che estraggono valore invece di custodirlo. Come la gravità, agisce che tu te ne accorga o no. E diventa più forte proprio quando l’azienda ha più successo, perché un’impresa che vale tanto è un bersaglio che vale tanto.

Fin qui Ries. Quello che mi ha tenuto sveglio, oltre al fuso del rientro, è un’altra cosa. Stiamo per consegnare migliaia di decisioni operative a agenti AI che eseguiranno la struttura che gli diamo, alla lettera, senza l’attrito morale di un essere umano che a un certo punto storce il naso e dice no. Se la struttura è mal disegnata, l’agente la realizzerà alla perfezione. La gravità finanziaria sta per trovare un acceleratore.

Lo sgabello con una gamba sola

Ries prende di mira il primato dell’azionista, la dottrina per cui l’unico scopo legittimo di un’impresa è massimizzare il ritorno per chi possiede le azioni. Un’azienda sana, scrive, poggia su tre gambe: una ragione di esistere, gli stakeholder che da quella ragione sono serviti, gli investitori che dalla performance sono ricompensati. Togli le prime due e resti con uno sgabello a una gamba sola, che sta in piedi solo finché i mercati hanno voglia di tenerlo in piedi.

Il dato che usa per smontare l’ortodossia è la sanità americana. Gli Stati Uniti spendono circa il doppio pro capite rispetto a paesi comparabili e ottengono un’aspettativa di vita più bassa. Un punto isolato, fuori dalla linea che ogni altro paese sviluppato segue. Per la teoria dei mercati efficienti non dovrebbe accadere. Accade. Ries lo legge come una smentita sul campo, non come un’anomalia da archiviare in un cassetto. Arriva al punto di voler ritirare la parola profitto, e ridefinirla come massimizzazione della fioritura umana.

L’agente non storce il naso

Qui entra il concetto del libro che mi sembra più urgente per chi lavora con l’AI: la surrogazione. La metrica di una cosa prende il posto della cosa stessa. Misuri il tempo medio di gestione di una chiamata perché è misurabile, e ottieni un customer service peggiore, perché gli operatori imparano a chiudere in fretta invece di risolvere il problema. La metrica mangia l’obiettivo.

Un essere umano, davanti a un cliente in difficoltà, ogni tanto rompe lo schema. Resta al telefono venti minuti in più perché capisce che è la cosa giusta, anche se il suo cruscotto ne soffre. Quella frizione vale oro. È l’ultimo argine tra la metrica e il senso.

Un agente AI quell’argine non ce l’ha. Gli dai una funzione obiettivo e lui la insegue con una costanza che nessun dipendente avrà mai. Se la funzione obiettivo è una metrica surrogato scelta male, l’agente ottimizzerà il surrogato fino in fondo, a una velocità e su una scala che la vecchia gravità finanziaria si sognava. La governance degli incentivi smette di essere materia da consiglio di amministrazione e diventa codice che gira in produzione.

Il leader invisibile, un secolo dopo

C’è poi Mary Parker Follett, teorica del management dei primi del Novecento, cancellata per decenni dai manuali mentre il suo contemporaneo Frederick Taylor diventava un santo laico. Follett parlava di “potere con” al posto di “potere su”. E parlava di leader invisibile: il vero capo della fabbrica di cioccolato Rowntree non era il signor Rowntree, era lo scopo condiviso che lui aveva seminato in ogni reparto. Le persone non seguivano lui, seguivano il senso che aveva reso comune.

La prova di un leader, in questa lettura, sta in cosa fa l’organizzazione quando nel reparto non c’è nessun manager. È un’idea che torna potente adesso, mentre costruiamo organizzazioni dove in molte stanze, di fatto, un manager non ci sarà più, ci sarà un agente.

A quel punto il leader invisibile prende una forma molto concreta: diventa la costituzione che diamo ai nostri sistemi, l’insieme di principi e vincoli che guida un agente quando deve decidere da solo. In Pelle Digitale ho provato a raccontare la tecnologia come estensione della mente, una membrana tra noi e il mondo. Con gli agenti quella membrana inizia a decidere al posto nostro, e l’unica cosa che la orienta è lo scopo che ci siamo presi la briga di scrivere dentro. Se lo scopo è vago, l’agente riempie il vuoto con la metrica più vicina.

Una seconda gravità

Ries parla di gravità finanziaria. Nelle aziende con cui lavoro ne vedo una seconda, parallela, che chiamerei gravità tecnologica. È la spinta a delegare cognizione, dati e infrastruttura a poche piattaforme esterne, perché all’inizio costa meno e fa risparmiare tempo. Il prezzo lo scopri dopo, quando il controllo se n’è già andato altrove e ricomprartelo costa una fortuna.

Le aziende che Ries porta come esempi di resistenza alla gravità finanziaria non sono enti di beneficenza. Grundfos, Bosch, Novo Nordisk, Carl Zeiss: fondazioni industriali nate in Danimarca e in Germania, alcune oltre un secolo fa, che battono i concorrenti convenzionali proprio perché possono investire su orizzonti che gli altri non riescono nemmeno a guardare. La proprietà protegge la missione, e la missione protetta produce risultati.

La stessa logica vale sul piano tecnologico. Tenere vicino ciò che è strategico, i modelli, i dati, le decisioni che pesano, è la versione digitale della fondazione industriale. È il motivo per cui con LocalAI lavoro su intelligenza artificiale che gira dentro il perimetro dell’azienda invece che dentro il perimetro di qualcun altro. È una scelta strutturale prima che ideologica: chi controlla l’asset critico controlla il proprio futuro.

La governance come atto creativo

Il lascito pratico di Incorruptible è che la governance è un lavoro di design, da fare prima che serva. Lo scrive a chiare lettere: aspettare di avere successo per mettere i paletti è troppo tardi, perché il successo è ciò che attira i predatori. Banchieri, avvocati e investitori ti diranno sempre di rimandare a quando sarai più forte. Quel consiglio è la trappola.

Per chi guida un’azienda oggi il compito si è raddoppiato. C’è la struttura finanziaria da disegnare, come dice Ries. E c’è la struttura tecnologica, la costituzione degli agenti, la scelta di cosa tenere dentro e cosa lasciare fuori, che decide quanto del tuo futuro resta nelle tue mani. È il lavoro che faccio ogni giorno con le aziende che proviamo ad aiutare in ZeroFive: non policy da incorniciare, ma i meccanismi che orientano le decisioni quando nessuno sta guardando, umano o agente che sia.

Ries ha ragione su un punto. Il successo da solo non protegge ciò che conta. E nell’era degli agenti, una struttura ben disegnata smette di difendere soltanto la missione dalla finanza, inizia a difendere la mente dell’organizzazione dal diventare proprietà di qualcun altro.

Eric Ries, Incorruptible: Why Good Companies Go Bad and How Great Companies Stay Great, Authors Equity, 26 maggio 2026. Materiali e capitolo bonus su incorruptible.co.