ai for business Archives

3 Ottobre 20265 Ottobre 2026AI & GENAI, TECH & BUSINESS

Company Brain: come si costruisce il “Jarvis” di un’azienda

Progettare uno spazio di lavoro che un LLM sa leggere

In quasi tutte le aziende che incontro la conoscenza di un progetto vive in sette o otto posti diversi: le registrazioni delle riunioni, le caselle di posta, una cartella condivisa su Drive e un’altra su Dropbox, il calendario, il CRM, i canali Slack o Teams, le schede di Jira o di Asana, le note personali di ciascuno. C’è poi un posto nuovo, che fino a due anni fa non esisteva e oggi contiene una parte rilevante del ragionamento di un team: le conversazioni che ogni persona ha con il proprio assistente AI mentre lavora. Ciascuno di questi posti funziona bene da solo, e nessuno sa dell’esistenza degli altri.

La reazione più diffusa è collegare un LLM a tutte queste fonti e aspettarsi che dal collegamento nasca un’intelligenza del progetto. È l’idea del Jarvis aziendale, che in questi mesi circola con nomi diversi, Company Brain, Brain OS, Company OS: un assistente che sa tutto dell’azienda perché vede tutto. Succede il contrario. Più fonti si collegano senza una struttura che le tenga insieme, più il modello produce risposte plausibili costruite su frammenti, e più diventa difficile capire da dove arriva un’affermazione, chi l’ha verificata e se è ancora vera.

Uno spazio di lavoro intelligente si progetta, e la scelta del modello arriva per ultima. Il metodo che propongo lo divide in sei livelli, ciascuno con una domanda a cui rispondere prima di passare al successivo. Come caso concreto uso il Workspace ICONICO, la piattaforma interna di gestione dei progetti che stiamo costruendo in questi mesi: è ancora giovane, ma ogni scelta descritta qui è già in produzione.

La complessità cambia posto

Prima dei livelli conviene chiarire che tipo di trasformazione è questa, perché la si confonde spesso con quella che le aziende hanno attraversato negli ultimi quindici anni. La digital transformation ha portato processi e dati dentro i sistemi: la carta è diventata un modulo, la riunione una videochiamata, l’archivio un drive condiviso, e la complessità stava nell’integrazione tra applicazioni e nell’adozione degli strumenti da parte delle persone. Si misurava in interfacce, licenze, migrazioni, formazione all’uso del software.

La AI transformation sposta la complessità altrove. Gli strumenti in buona parte ci sono già, e i dati anche, solo che sono sparsi e senza significato condiviso. Quando un modello legge, riassume, collega e propone al posto delle persone, il problema smette di essere come si esegue una procedura dentro un’applicazione e diventa cosa significano le informazioni, chi ha titolo per confermarle e cosa succede quando due fonti dicono cose diverse. La complessità passa dal codice alla semantica, dall’interfaccia alla governance, dall’esecuzione delle operazioni alla responsabilità delle decisioni.

Questo ha una conseguenza pratica che molti sottovalutano. Il lavoro di chi usa il sistema cambia natura: meno inserimento di dati, meno ricerca, molte più approvazioni, correzioni e scelte su informazioni preparate da altri. Una persona che prima compilava il verbale di una riunione ora riceve un verbale già scritto, con i task estratti e collegati alle persone giuste, e il suo compito è dire se è corretto. È un lavoro più leggero e più delicato insieme, perché richiede di sapere cosa si sta approvando.

Un posto per ogni informazione

Centralizzare la conoscenza non significa copiare tutto in un unico contenitore. Un archivio dove finiscono i file di tutti è soltanto un altro silo, più grande. Serve un luogo dove un’informazione diventa un oggetto con un’identità, un autore, una data e una posizione nel progetto: una nota di riunione, un task con un assegnatario e una scadenza, un documento con le sue versioni, un referente con il suo ruolo, un’opportunità con il suo stadio, un’ora di lavoro registrata su un’attività.

La regola che evita più problemi è che ogni dato ha un solo sistema proprietario. Nel Workspace ICONICO clienti, contatti e opportunità restano nel CRM aziendale, e la piattaforma non li duplica: tiene un collegamento e una copia del nome per poterlo mostrare, e quando dal progetto nasce un’opportunità è la piattaforma a scriverla nel CRM, con la nota di progetto e l’attività già collegate. Un’anagrafica duplicata produce, dopo pochi mesi, due verità su chi è il decisore di un cliente, e un modello che le legge entrambe sceglie a caso quale citare.

Il vantaggio più sottovalutato della centralizzazione riguarda le informazioni che oggi non arrivano da nessuna parte. Una decisione presa in una call e mai scritta, un dubbio sollevato in un canale Slack e poi dimenticato, un vincolo annotato in una scheda Jira che nessuno del commerciale leggerà, un’email in cui il cliente cambia una priorità rispondendo a un’altra domanda. E poi il ragionamento che una persona fa con il proprio LLM mentre prepara una proposta o analizza un problema, che spesso contiene il passaggio più utile della giornata e svanisce quando si chiude la finestra. Ognuna di queste informazioni, presa da sola, vale poco. Raccolte nel progetto, con la loro origine, diventano la memoria che l’azienda non aveva mai avuto, e smettono di dipendere da chi era presente quel giorno.

Per ottenere questo vantaggio non sempre serve costruire infrastruttura nuova. In molti casi le fonti esistono già, con i loro connettori, e manca soltanto il punto in cui convergono e un criterio per decidere cosa ne entra. Nel Workspace il controllo degli accessi è applicato al livello più basso possibile, con regole a livello di riga su ognuna delle 28 tabelle del database, per cui la stessa domanda posta da due persone con ruoli diversi restituisce risposte diverse: è la condizione per dare a un modello l’accesso a tutto il progetto senza dover filtrare a mano ogni volta.

Il significato viene prima dei dati

È la parte che quasi tutti saltano, e si capisce: parlare di ontologia in una riunione di direzione fa alzare gli occhi al cielo. Eppure un modello collegato a dati senza tipi e senza relazioni dichiarate ricostruisce da solo il significato delle cose, ogni volta in modo leggermente diverso, e due risposte alla stessa domanda a una settimana di distanza non coincidono. L’ontologia è il punto in cui un’azienda decide cosa significano le sue informazioni, prima che lo decida un modello al suo posto.

Si comincia dai tipi di oggetto. Nel Workspace le note sono appunti, verbali di riunione, decisioni, rischi, insight, feedback, opportunità o conoscenza consolidata, e il tipo cambia il trattamento: una decisione pesa più di un appunto, un rischio genera attenzione, una nota di conoscenza è il risultato di una verifica e non di un’impressione. Anche il vocabolario fa parte dell’ontologia. I tag vengono normalizzati, minuscoli e con il trattino al posto degli spazi, e prima di crearne uno nuovo il sistema lo confronta per somiglianza con quelli esistenti: se esiste già “commerciale-b2b”, la variante “commerciale b2b” non nasce e chi la scrive riceve un avviso, perché il tag è il punto in cui la tassonomia di un’azienda si sfalda più in fretta.

Poi viene lo smistamento, cioè la decisione su dove va un’informazione appena raccolta. Ogni progetto ha un profilo leggibile dal modello: i domini email del cliente e dei partner, le parole chiave e le sigle ricorrenti, le cartelle standard, le convenzioni di nome. Con queste poche righe una mail da un certo dominio, o una registrazione in cui ricorre una sigla, viene attribuita al progetto giusto con un livello di confidenza dichiarato. Quando la confidenza è bassa, o l’informazione potrebbe appartenere a due progetti, il modello non sceglie: la proposta finisce in una coda da smistare e la decisione torna a una persona.

Le eccezioni vanno progettate quanto i casi normali. Un’informazione con cifre economiche viene marcata come riservata e resta visibile solo ai responsabili del progetto. Un’informazione dubbia porta il marcatore da verificare. Un contenuto già importato viene riconosciuto dalla sua origine e non entra una seconda volta. Ognuna di queste regole è una piccola decisione organizzativa scritta in anticipo, e ciascuna toglie al modello un’occasione di improvvisare.

Il caso più delicato sono le collisioni, quando due fonti affermano cose diverse sullo stesso punto. Per gestirle le relazioni tra oggetti sono tipizzate: un collegamento tra due note può essere un riferimento, una conferma, un’integrazione, una divergenza o un consolidamento. Nel progetto pilota due note scritte da persone diverse, a pochi giorni di distanza, si contraddicevano su sei punti. Un sistema ingenuo avrebbe tenuto l’ultima, o le avrebbe fuse in un riassunto. Con le relazioni tipizzate la divergenza diventa un collegamento esplicito e apre un task di verifica assegnato a una persona, che si chiude con una nota di conoscenza: cita entrambe le fonti e dichiara per ciascuna se è stata confermata, integrata o superata su quel punto. Le note originali restano intatte e i loro autori ricevono una notifica.

Le conferme hanno lo stesso trattamento, con il segno opposto. Quando una seconda fonte indipendente dice la stessa cosa della prima, il collegamento di conferma alza il valore di quell’informazione, e chi interroga il progetto sa che quel fatto è sostenuto da due origini e non da una. È il modo in cui la conoscenza di un team acquista peso nel tempo, invece di accumularsi tutta allo stesso livello.

Arricchire i dati e renderli percorribili

Un’informazione raccolta e smistata è ancora un oggetto isolato. Diventa conoscenza quando è collegata a ciò che la circonda: le persone che cita, l’opportunità a cui si riferisce, il documento che commenta, il task che ne è nato, le ore spese per produrla.

L’arricchimento avviene su più piani. Il primo è esplicito: nelle note e nei task gli oggetti si citano con le menzioni, scrivendo @ seguito dal nome di una persona, di un documento o di un’opportunità, e ogni menzione diventa un collegamento. Il secondo è automatico: il sistema rianalizza i testi, riconosce nomi di referenti, opportunità e documenti già presenti nel progetto e genera collegamenti suggeriti, che però restano suggerimenti finché qualcuno non li conferma, e se vengono rifiutati non vengono ricreati. Il terzo è operativo: un task porta con sé la nota da cui è nato, un’ora registrata porta con sé il task o la riunione a cui si riferisce, un’opportunità porta con sé la nota che l’ha fatta emergere.

Il risultato è un grafo della conoscenza in cui i nodi sono note, task, documenti, referenti, opportunità, membri del team, cartelle, tag e organizzazioni, e gli archi hanno un’origine dichiarata: strutturale, da menzione, manuale o automatica. Alcuni archi hanno anche un peso, come le ore che una persona ha dedicato a un’attività, così la mappa mostra dove si concentra davvero il lavoro e non solo cosa è collegato a cosa.

Rendere la conoscenza percorribile vuol dire offrire più strade per arrivare alla stessa informazione. Dalla mappa del progetto si parte da un nodo e se ne esplora il vicinato fino a tre passi di distanza. Da ogni oggetto si vedono i collegamenti in uscita e quelli in entrata, cioè chi lo cita. La timeline restituisce la sequenza degli eventi, la ricerca attraversa note, task, documenti, testo estratto e tag di tutti i progetti leggibili. E il modello usa le stesse strade: prima di una riunione con un referente prepara il brief partendo dal suo nodo, raccogliendo le note recenti che lo citano, le opportunità aperte, i task in scadenza e le divergenze ancora da chiudere. Alla domanda “cosa sappiamo di questo cliente” il sistema risponde con un percorso nel grafo che parte dal nodo del cliente.

Quale modello per quali dati

Con la conoscenza centralizzata, strutturata e collegata, la scelta del modello diventa una decisione molto più semplice e molto meno rischiosa, perché il modello non contiene niente. Il cuore del sistema è il livello di conoscenza con il suo server di accesso: il modello è un lettore e un proponente, e si può sostituire senza perdere nulla. Il mio assistente personale si chiama Gideon, come l’intelligenza artificiale che in The Flash mostra a Barry Allen i giornali del futuro. Il mio si accontenta di sapere cosa abbiamo deciso martedì, e se domani cambiassi il modello che lo fa funzionare continuerebbe a saperlo, perché quella memoria non sta dentro di lui.

Il collegamento passa oggi quasi sempre da un server MCP, il protocollo che i principali assistenti usano per parlare con strumenti esterni. Il server del Workspace gira su un dominio proprio, con autenticazione OAuth, ed espone oltre sessanta strumenti: leggere e scrivere note, aprire task, caricare documenti, registrare il tempo di una riunione, interrogare il grafo di un progetto. Lo stesso server serve qualsiasi client compatibile, e il principio da tenere fermo è che il modello opera sempre con i permessi reali della persona che lo sta usando, mai con un’utenza tecnica onnipotente.

Da qui le strade sono sostanzialmente due, e spesso convivono. La prima sono i client dei prodotti noti, Claude, ChatGPT e gli altri assistenti commerciali: offrono i modelli più capaci, connettori già pronti verso posta, calendari e archivi, e un’esperienza che le persone conoscono. Il prezzo è che i dati letti dal modello transitano sui server del fornitore, con le garanzie contrattuali del piano sottoscritto. La seconda sono i client con AI locale, che eseguono modelli aperti su macchine aziendali o su server interni: i dati non escono dal perimetro dell’azienda, i costi sono prevedibili, e in cambio si accettano modelli meno potenti sui compiti più complessi, più lavoro di manutenzione e un’infrastruttura da gestire.

La scelta si fa per classe di dati, e può cambiare nel tempo. Un modo pratico è classificare le informazioni del progetto su tre livelli: dati che possono uscire (ricerche pubbliche, bozze di contenuti, analisi di mercato), dati interni che possono uscire solo verso fornitori con garanzie contrattuali adeguate, dati che non devono uscire per nessun motivo, come informazioni economiche riservate, dati personali sensibili o segreti industriali. Ai primi due livelli si applica il modello più capace disponibile, al terzo un modello locale, oppure un passaggio di anonimizzazione prima dell’invio. Nel Workspace questa classificazione è già parzialmente scritta nell’ontologia, perché le note e i documenti riservati sono marcati come tali, e quel marcatore diventa il criterio naturale per decidere quali oggetti affidare a un client locale.

Il punto fermo, in entrambi i casi, è che il cuore resta centralizzato. Che il modello giri in un data center americano o su un server nel seminterrato, legge la stessa conoscenza, con gli stessi permessi, attraverso lo stesso server, e propone modifiche che passano dalla stessa approvazione. Cambiare fornitore, o affiancarne due, diventa una decisione di costo e di riservatezza, senza progetti di migrazione.

Skill condivise in un catalogo unico

Una skill è il modo in cui si insegna a un assistente a fare una cosa sempre nello stesso modo: istruzioni in testo, riferimenti da consultare al momento giusto, script che verificano ciò che può essere verificato. Il paragone più vicino è il manuale operativo di un nuovo collaboratore, con la differenza che questo manuale viene letto davvero, ogni volta.

Il loro valore in un team va oltre l’efficienza del singolo. Quando dieci persone usano un LLM senza skill condivise, ciascuno scrive le note a modo suo, chiama le cose con nomi diversi, sceglie tag diversi, struttura le proposte con sezioni diverse, e il modello amplifica queste differenze invece di ridurle. Con le skill condivise il modello di ciascuno parla la stessa lingua: usa gli stessi tipi di nota, propone gli stessi formati, rispetta le stesse regole di stile, chiama un rischio “rischio” e una decisione “decisione”. Le skill sono il veicolo con cui l’ontologia arriva dentro ogni conversazione, senza che nessuno debba ricordarla.

Nel Workspace le skill sono tre e lavorano insieme. La skill di raccolta legge le fonti, smista per progetto, propone note, task, ore, referenti e collegamenti, prepara i brief, gestisce le verifiche. La skill documentale produce i documenti per i clienti da un motore unico: copertina, intestazione, palette e coordinate aziendali sono fisse, cambiano solo contenuti e firma di chi redige, e un controllo di stile automatico intercetta i tic di scrittura prima della consegna. Su questa si appoggia la skill commerciale, che segue una proposta dal brief all’opportunità nel progetto fino al preventivo nel CRM, con uno script che verifica al centesimo che documento e preventivo coincidano.

Conta molto anche il luogo dove le skill vengono scritte. Se vivono nei computer delle persone, dopo tre mesi ne esistono cinque versioni leggermente diverse, ognuna con le sue correzioni locali, e il linguaggio comune si disgrega dalla periferia. Per questo nel Workspace le skill stanno in un catalogo unico, dentro la piattaforma: ogni skill esiste in una sola versione corrente, con le note di rilascio, i connettori di cui ha bisogno, la versione minima del server, le altre skill da cui dipende e uno stato che la rende obbligatoria o consigliata. I sorgenti sono archiviati file per file con la loro impronta crittografica, e il pacchetto che ogni collaboratore scarica viene verificato contro quelle impronte.

Il catalogo rende le skill anche dinamiche nella struttura. Una skill ben scritta separa le regole dai dati: non contiene l’elenco dei tag del progetto né i domini del cliente, li legge dal Workspace nel momento in cui serve, così l’ontologia evolve senza dover riscrivere le procedure. Quando cambia una regola, si pubblica una nuova versione nel catalogo e ogni collaboratore la riceve con le note di rilascio. Il motore documentale è stato riscritto in Python con la sola libreria standard proprio per non legare le skill a un solo assistente: lo stesso pacchetto gira su qualsiasi piattaforma che esegua Python, compresi i client con AI locale.

La lezione tecnica più utile riguarda il confine tra quello che decide il modello e quello che decide il codice. Tutto ciò che si può verificare in modo deterministico va tolto al giudizio del modello. Prima di essere inviato, ogni pacchetto di proposte attraversa un validatore con nove regole. Il preventivo viene ricontrollato da uno script. Il documento passa da una verifica della resa in PDF. Al modello resta il lavoro che sa fare meglio, leggere, collegare e proporre, e il codice garantisce che il risultato rispetti le regole.

Il modello propone, le persone firmano

Il livello che tiene insieme tutti gli altri è una regola di governo molto semplice: niente entra nella memoria del progetto senza che una persona lo approvi. Quando il modello esegue la raccolta settimanale non scrive nulla, prepara un pacchetto di proposte. Ogni proposta dichiara l’operazione (crea una nota, apri un task, registra un’ora, collega due oggetti, apri una verifica), il progetto di destinazione, un estratto della fonte di massimo trecento caratteri con data e autore, un livello di confidenza e, quando serve, un marcatore che la segnala come da verificare o come contenuto economico riservato.

Il responsabile apre il pacchetto, approva, corregge o rifiuta. L’applicazione avviene con i suoi permessi, e se una proposta dipende da un’altra (un collegamento tra due note che nascono nello stesso pacchetto) il sistema le applica nell’ordine giusto. Una proposta rifiutata viene ricordata insieme alla sua origine e non torna alla raccolta successiva, quindi il sistema impara cosa non serve senza bisogno di istruzioni più lunghe.

La ragione di questa rigidità è pratica. Una base di conoscenza inquinata da un modello troppo zelante è peggio di una base vuota, perché nessuno sa più quali informazioni sono state verificate da una persona e quali sono state dedotte. Con le proposte approvate ogni oggetto del progetto ha un’origine e un responsabile, e se tra sei mesi qualcuno chiede perché è stata presa una certa decisione, la risposta porta a una riunione, a una persona, a una data.

Da dove cominciare

Chi parte da zero dovrebbe cominciare dalla carta e lasciare gli strumenti per dopo. Prima l’inventario delle informazioni che il team produce davvero in una settimana normale, comprese quelle che oggi si perdono nelle chat, nelle call e nelle conversazioni con l’LLM, e del sistema che ne è proprietario. Poi l’ontologia minima: quali tipi di oggetti esistono, quali relazioni servono, chi decide sulle divergenze, come si chiamano i tag. Poi la classificazione dei dati, che dice quali modelli possono leggerli. Infine i connettori e le skill, partendo dalle procedure che il team ripete più spesso e che oggi dipendono dalla memoria di una persona.

La parte tecnica, in molti casi, è la più rapida. Le fonti esistono già, hanno i loro connettori, e spesso basta farle convergere in un punto con un criterio di ingresso. Il lavoro più lungo è organizzativo: mettersi d’accordo su cosa conta come decisione, su chi può chiudere una divergenza, su quali dati non devono uscire dall’azienda e su quali tag hanno diritto di esistere è una conversazione che in molte aziende non è mai stata fatta. Scrivere nero su bianco quali sono gli oggetti della conoscenza di un team, e chi ne risponde, è il primo pezzo di uno spazio intelligente, e viene molto prima della scelta del modello da collegare.

3 Ottobre 20265 Ottobre 2026AI & GENAI, TECH & BUSINESS

Il web semantico ha aspettato il lettore giusto

Il web semantico ha una data di nascita precisa. Nel maggio del 2001 Tim Berners-Lee firmò con James Hendler e Ora Lassila un articolo su Scientific American in cui descriveva un web fatto di dati leggibili dalle macchine, con agenti software che prenotavano visite mediche incrociando calendari, coperture assicurative e distanze. L’articolo circolò moltissimo, generò standard veri, e la visita medica non la prenotò nessuno.

La scena d’apertura era quasi domestica. Pete e Lucy devono organizzare un ciclo di fisioterapia per la madre, e l’agente di Pete cerca i centri convenzionati con l’assicurazione entro una certa distanza e incastra gli appuntamenti nelle agende dei due fratelli. Quasi nessuno ricorda che quell’agente non capiva una parola di quello che leggeva: funzionava solo perché ogni pagina del web, dagli orari dello studio medico alle condizioni della polizza, era già stata descritta dai suoi autori in un linguaggio formale. Nel 2001 l’agente poteva essere stupido perché il web doveva essere intelligente.

Venticinque anni dopo è andata al contrario: gli agenti hanno imparato a leggere il testo così com’è, il web non è mai stato descritto, e il vocabolario formale che doveva servire a quei software sta tornando nei progetti aziendali con un nome leggermente diverso.

Perché il web semantico non attecchì

Gli strumenti del web semantico furono costruiti sul serio. RDF per esprimere fatti come triple, OWL per definire classi e relazioni, SPARQL per interrogare. Sono tecnologie solide, sopravvissute nei domini dove la semantica vale abbastanza da giustificare la fatica: biomedicina, beni culturali, dati pubblici, editoria scientifica.

Fuori da quei domini non è successo niente, e la ragione è banale quanto decisiva. Annotare costava lavoro umano immediato, il beneficio era differito e andava a qualcun altro, e non esisteva nessuno disposto a pagare quel lavoro. Chi pubblicava una pagina non aveva motivo di descriverne il contenuto in una forma che serviva a un software di cui non conosceva nemmeno l’esistenza.

I motori di ricerca risolsero il problema per la loro strada, estraendo significato dal testo con la statistica invece di chiederlo agli autori, e quella scorciatoia funzionò così bene da togliere ogni urgenza al resto.

Adesso il lettore non è umano

La condizione che mancava era un consumatore che traesse vantaggio dalla struttura e che fosse disposto a pagarla. Quel consumatore adesso c’è, ha un costo marginale per richiesta e appartiene all’azienda che lo fa girare.

Il meccanismo si vede bene dentro un’azienda qualsiasi. Un agente che lavora sulla documentazione interna trova «cliente attivo» nel CRM, dove indica chi ha un contratto aperto, e nella reportistica amministrativa, dove indica chi ha pagato almeno una fattura nell’ultimo anno, e ogni volta deve capire quale dei due sensi vale per la domanda che ha davanti. Lo fa leggendo più contesto, a volte chiedendo, a volte sbagliando, e lo rifà alla richiesta successiva perché quella risoluzione non viene scritta da nessuna parte. Ogni ambiguità non dichiarata si paga di nuovo a ogni lettura, in token e in errori.

È un rovesciamento completo dell’economia del web semantico. Prima il beneficio era esterno e diffuso, e per questo nessuno investiva. Adesso è interno e misurabile sulla bolletta di chi costruisce l’ontologia, e chi la costruisce tiene per sé sia il risparmio sia il vocabolario. Il conto che arriva a fine mese misura l’ambiguità che nessuno aveva mai messo per iscritto, ed è la prima volta che quella misura esiste.

Per questo l’ontologia sta rientrando dalla porta dell’efficienza dopo aver fallito da quella della condivisione. Il ritorno è privato, con grafi aziendali chiusi, vocabolari che nessuno pubblica e mappature bilaterali fra chi ha bisogno di parlarsi, che è esattamente la condizione in cui la traduzione fra ontologie private si paga per coppia. Del progetto originale resta la tecnica e si perde l’idea di un bene comune, che era la parte per cui valeva la pena scriverne su una rivista.

L’unico pezzo che ha funzionato

Una parte di quel progetto ha funzionato, e vale la pena guardarla perché spiega il resto. Schema.org, il vocabolario nato nel 2011 per descrivere pagine, prodotti, eventi, ricette e recensioni, è oggi sui milioni di siti, e nessuno lo ha adottato per amore della semantica.

Lo hanno adottato perché i motori di ricerca hanno offerto un vantaggio immediato e visibile a chi marcava le proprie pagine, sotto forma di risultati arricchiti, stelline, prezzi e tempi di cottura sotto il link. Un responsabile marketing che vede il proprio risultato occupare più spazio in pagina firma quel lavoro senza chiedersi cosa sia un’ontologia.

È lo stesso meccanismo che oggi sta riportando in vita il resto. La struttura si adotta quando produce un beneficio che si vede entro il trimestre a chi sostiene il costo, e il beneficio che si vede entro il trimestre adesso si chiama spesa di inferenza.

Qualcosa di simile sta già succedendo, in scala più piccola, dal lato degli agenti. Quando Anthropic ha pubblicato il Model Context Protocol, alla fine del 2024, ha chiesto a chi espone un servizio di descrivere ogni strumento con un nome, una spiegazione in linguaggio naturale e uno schema formale dei parametri, e migliaia di sviluppatori lo hanno fatto senza discutere, per lo stesso motivo delle stelline sotto i link: se la descrizione è scritta bene l’agente usa lo strumento, altrimenti lo ignora o lo usa male. Rispetto a Schema.org questi schemi descrivono quello che si può fare, i verbi, e lasciano scoperti i sostantivi, cioè cosa sono le cose su cui si agisce, che è proprio la parte di cui si occupa un’ontologia.

Il modello che costruisce le proprie regole

C’è un secondo motivo per cui adesso funziona, e riguarda il costo dell’annotazione. Estrarre entità e relazioni da un corpus, che venticinque anni fa era lavoro manuale da specialisti, oggi lo fa un modello linguistico con una qualità che in molti domini basta.

La circolarità è evidente e va guardata in faccia. Si usa un sistema statistico per produrre lo schema formale che dovrebbe disciplinare i sistemi statistici, e se l’estrazione sbaglia una relazione, quella relazione diventa struttura, e la struttura viene creduta più del testo da cui è stata ricavata proprio perché è strutturata.

Un errore in un documento resta un errore in un documento. Un errore nel grafo diventa una regola, e le regole hanno la proprietà di sopravvivere a chi le ha scritte, come accade a ogni schema che nessuno ha più l’autorità di emendare.

La stessa dinamica vale per le omissioni. Un’estrazione automatica trova quello che somiglia a ciò che ha visto in addestramento, e le relazioni idiosincratiche di una singola azienda, quelle nate da un accordo particolare o da una vicenda societaria, sono proprio quelle che il modello tende a normalizzare in categorie più comuni. Il grafo che ne esce descrive bene un’azienda media del settore e descrive male la tua, che è l’unica per cui serviva.

La provenienza era già negli standard

Lo stack del 2001 conteneva già una risposta a questa circolarità, ed è la parte che si è usata meno. Nel 2013 il W3C ha pubblicato PROV-O, un vocabolario per registrare l’origine di un dato, cioè l’attività che lo ha generato e il soggetto che ne risponde, pensato proprio per i grafi in cui fatti di provenienza diversa finiscono mescolati.

Applicato all’estrazione automatica diventa una regola di igiene facile da enunciare e faticosa da rispettare: ogni relazione che entra nel grafo si porta dietro il passaggio del documento da cui è stata ricavata e la versione del modello che l’ha estratta. Quando una relazione si rivela sbagliata, quella traccia permette di tornare al passaggio e capire se l’errore sta nel testo o nell’estrazione. Permette anche di trovare tutte le altre relazioni nate dalla stessa fonte o dallo stesso modello, che con buona probabilità condividono il difetto.

Un grafo estratto senza provenienza è una scatola nera con l’aspetto dell’ordine, e correggerlo vuol dire intervenire su una relazione alla volta senza sapere quante altre ne condividano la causa. Con la provenienza il grafo si può interrogare anche sulla propria affidabilità, ed è questo che permette di concentrare la verifica dove serve invece di distribuirla ovunque.

Chi valida quando nessuno legge

Qui torna la parte che il web semantico non ha mai risolto e che l’automazione non risolve da sola, perché riguarda la fiducia nello schema più che la sua costruzione. Un’ontologia estratta va verificata da qualcuno che conosca il dominio, e quella verifica non si può distribuire su tutto il corpus, va concentrata dove le conseguenze pesano.

Il criterio che userei è banale: si controlla a mano quello su cui un agente prenderà decisioni con effetti verso l’esterno, contratti, pagamenti, obblighi verso clienti e autorità, e si lascia all’estrazione automatica tutto il resto, accettando che lì la qualità sia buona e non certa. Chiunque prometta una validazione completa su un grafo di milioni di relazioni sta descrivendo un progetto che finirà male.

Con questo pezzo chiudo la serie sull’ontologia. Abbiamo passato venticinque anni a spiegare alle aziende che descrivere i propri dati era un investimento, e non ha funzionato perché il beneficio non aveva un destinatario. Adesso il destinatario esiste, costa, e manda una fattura ogni mese. Non è il modo in cui speravo che arrivasse, ed è il modo in cui sta arrivando.

1 Ottobre 20265 Ottobre 2026AI & GENAI, TECH & BUSINESS

La dieta della finestra di contesto

Quando la finestra di contesto era piccola, il mestiere consisteva nel far stare dentro il necessario. Adesso che ci stanno interi archivi, il riflesso di molti è caricare tutto e lasciare che il modello si arrangi, e la spesa cresce senza che la qualità delle risposte cresca in proporzione.

Una finestra di contesto grande ha risolto un vincolo tecnico e ne ha reso visibile un altro, che riguarda l’attenzione del modello più che la sua capienza.

Il riflesso di caricare tutto

L’abitudine viene dai primi sistemi di recupero, quelli in cui si prendevano i venti frammenti più simili alla domanda e si sperava che la risposta fosse in uno di quelli. Con venti frammenti su un milione di documenti conveniva abbondare, perché il costo di perdersi il pezzo giusto era alto e quello di leggerne qualcuno in più era basso.

Il calcolo cambia quando i frammenti diventano duecento. Il contesto irrilevante non è materiale neutro che il modello scarta senza fatica, è materiale che compete con quello rilevante, e in un testo lungo le informazioni che stanno a metà vengono usate peggio di quelle che stanno agli estremi.

L’effetto della posizione è documentato da tempo. Nel 2023 un gruppo di ricercatori di Stanford guidato da Nelson Liu ha pubblicato Lost in the Middle, uno studio in cui lo stesso documento utile veniva spostato in punti diversi di un contesto lungo, e l’accuratezza dei modelli disegnava una curva a U, alta quando il passaggio giusto stava all’inizio o alla fine e più bassa quando finiva in mezzo. I modelli usciti dopo hanno attenuato quella curva e nessuno ha dimostrato di averla eliminata, per cui più materiale si carica, più aumenta la probabilità che il pezzo decisivo cada proprio nella zona letta peggio.

Più contesto non produce più precisione

Il comportamento si osserva facilmente: prendi una domanda a cui il sistema risponde bene con cinque documenti pertinenti, aggiungi quaranta documenti che parlano dello stesso cliente senza contenere la risposta, e la qualità peggiora. Il modello comincia a citare passaggi vicini al tema e lontani dalla domanda, e quando i documenti si contraddicono fra loro sceglie senza dichiarare di aver scelto.

Chi ha lavorato con archivi reali riconosce lo scenario, perché negli archivi reali la contraddizione è la norma: ci sono tre versioni dello stesso contratto, due delle quali sono bozze mai firmate, e nessuna porta scritto in faccia quale sia quella buona, tanto che la persona esperta la riconosce dal nome del file e dalla cartella in cui sta, informazioni che al modello non arrivano.

Riempire la finestra di contesto solo quando serve

La strada alternativa consiste nel dare all’agente poco materiale e molti modi per chiederne altro. Un indice delle entità, una descrizione di cosa c’è in ciascuna fonte, gli strumenti per interrogarla, e la libertà di fare il secondo giro se il primo non basta.

Anthropic ha chiamato questo approccio contesto just in time, nel testo sul context engineering pubblicato nel 2025, e ha un prezzo che conviene conoscere prima di adottarlo. Ogni giro in più è una chiamata in più, con la sua latenza e i suoi token, e un agente che deve chiedere il materiale funziona solo se sa cosa chiedere: quando l’indice è vago o la descrizione delle fonti è scritta in fretta, l’agente non sa che esiste il documento che gli servirebbe e risponde con quello che ha. La qualità si sposta dal recupero alla descrizione delle fonti, che diventa il testo più letto dell’azienda senza che nessuno lo abbia mai curato come tale.

Il grafo funziona bene in questo schema, perché ti permette di portare nella finestra di contesto solo il perimetro rilevante e di tenere tutto il resto raggiungibile senza essere presente. In una richiesta sui contratti in scadenza entrano l’identificativo del cliente, le entità collegate, i contratti agganciati, e non entra la corrispondenza commerciale degli ultimi tre anni, che pure parla di quel cliente in ogni riga. È lo stesso meccanismo per cui quattro collegamenti costano meno di quaranta documenti, guardato dal lato di cosa entra in finestra.

Il middleware che smista le richieste ai modelli sceglie il modello giusto per ogni richiesta, e qui il criterio è lo stesso applicato al materiale invece che al motore.

Il criterio che uso per decidere cosa entra

La domanda che mi pongo davanti a ogni pezzo di contesto è se la risposta cambierebbe senza. Se la risposta resta uguale, quel materiale sta pagando affitto senza produrre niente, e va spostato dietro uno strumento che l’agente può chiamare se gli serve.

La seconda domanda riguarda la durata. Le istruzioni su come comportarsi valgono per tutta la conversazione e conviene tenerle stabili, i dati di un singolo caso valgono per quella richiesta e conviene farli entrare e uscire. Mescolare le due cose produce contesti che crescono a ogni turno e che a un certo punto contengono il residuo di tre richieste fa.

La terza riguarda chi ha scritto quello che sta entrando. Un documento generato da un altro agente e non verificato da nessuno pesa quanto un documento approvato, e il modello non distingue fra i due. Vale la pena incrociarla con il modo in cui il corpus aziendale si gonfia da solo, perché il materiale che compete con quello buono aumenta a ogni riassunto prodotto per riflesso.

Quando il lavoro dura ore

Un agente che porta avanti un compito lungo, fatto di decine di passaggi, incontra il limite della finestra anche quando ogni singolo passaggio è sobrio, perché la storia della sessione si accumula e ogni turno si porta dietro tutti quelli precedenti. Nello stesso testo Anthropic descrive due modi di gestirla: la compattazione, che a un certo punto riassume la conversazione e la fa ripartire con il riassunto al posto del verbale, e le note strutturate, con l’agente che tiene su un file esterno lo stato del lavoro e le decisioni prese, e le rilegge quando servono invece di portarsele dietro a ogni turno.

Entrambe le tecniche spostano una parte del contesto dentro un testo che nessuno ha verificato. Il riassunto della compattazione decide quale parte della conversazione sopravvive, e lo decide il modello con lo stesso criterio statistico che lo porta a preferire il generico allo specifico, mentre le note sono scritte dall’agente su sé stesso. Il terzo criterio torna qui, applicato al materiale che l’agente produce per proprio uso: un riassunto scritto da un modello entra nella finestra successiva con la stessa autorevolezza di un’istruzione scritta da una persona.

Conviene allora separare nel riassunto le decisioni dalle osservazioni, conservare le prime alla lettera e lasciare comprimere solo le seconde, perché una decisione parafrasata due volte finisce per dire qualcosa di diverso da quello che era stato deciso.

Misurare invece di stimare

Il modo per uscire dalle impressioni è tenere due numeri per ogni tipo di richiesta ricorrente: quanti token entrano nella finestra di contesto e quante risposte risultano corrette su un campione che qualcuno ha verificato a mano. Il primo lo dai già per scontato perché arriva in fattura, il secondo richiede un lavoro che quasi nessuno fa e senza il quale il primo non si può ottimizzare, perché tagliare contesto abbassa sempre il costo e a volte abbassa anche la qualità.

Con i due numeri accanto la prova diventa banale: si toglie una fonte per volta e si guarda cosa succede alle risposte corrette. Nelle configurazioni che ho visto ottimizzare così, la metà del materiale caricato non sposta niente, e il quarto che conta davvero è sempre lo stesso in tutte le richieste dello stesso tipo, il che suggerisce di smettere di recuperarlo dinamicamente e di scriverlo una volta nelle istruzioni.

Gli scarti utili

Una parte di quello che resta fuori vale comunque la pena tenerla a portata. Le eccezioni, i casi che l’anno scorso hanno rotto il processo, le decisioni prese in deroga: sono materiale che non serve quasi mai e che quando serve vale molto più di tutto il resto.

È il tipo di conoscenza che in azienda sta nella testa di due o tre persone e che scompare quando quelle persone cambiano ruolo. Un sistema costruito bene non la carica a ogni richiesta, la rende raggiungibile con una chiamata e la mostra quando il caso somiglia a uno di quelli. È anche la parte che più raramente qualcuno si preoccupa di mettere per iscritto, perché non serve a chi già la sa.

25 Settembre 20265 Ottobre 2026AI & GENAI, TECH & BUSINESS

Interoperabilità fra agenti: il vocabolario viene prima del protocollo

L’interoperabilità fra agenti di aziende diverse si rompe in silenzio. Il tuo agente manda un ordine di acquisto, quello del fornitore lo riceve, lo interpreta e conferma, e nessuno dei due ha mai concordato cosa significhi quantità confermata, e per un po’ funziona lo stesso, perché i casi facili sono la maggioranza e le differenze emergono solo sul bordo.

Poi arriva l’ordine in cui la quantità confermata del fornitore include il sovrametraggio di produzione e quella del tuo sistema no, e la differenza viene scoperta in magazzino tre settimane dopo.

L’interoperabilità che funziona per caso

Quando si discute di coordinamento fra agenti si parte quasi sempre dal protocollo, cioè da chi chiama chi, in che ordine, con quale formato di messaggio. È il livello visibile, quello che si disegna sulla lavagna, ed è anche quello che si risolve più in fretta perché esistono standard.

Il livello sotto è il lessico, e non si risolve con un formato. Due sistemi possono scambiarsi JSON perfettamente validi per anni contenendo campi che si chiamano allo stesso modo e significano cose diverse. Dentro una stessa azienda questo accade già, e quando due agenti non sono d’accordo qualcuno deve pur decidere, di solito chi scrive per ultimo il file di orchestrazione.

Fra aziende diverse non c’è nessun file di orchestrazione comune, e nessuno che abbia l’autorità di scriverlo, quindi l’interoperabilità resta appoggiata su assunti impliciti. La ricostruzione del significato che dentro casa si paga in token a ogni chiamata, sul confine fra due aziende si paga in ordini sbagliati.

Il precedente della fattura elettronica

In Italia un esperimento di ontologia imposta lo abbiamo già fatto, e lo abbiamo fatto in grande. La fatturazione elettronica verso la pubblica amministrazione prima, quella fra privati dal 2019, hanno costretto ogni azienda del Paese ad adottare lo stesso tracciato XML, gli stessi codici, le stesse regole di validazione, con un sistema di interscambio al centro che rifiuta quello che non rispetta lo schema.

Il modo in cui è stata vissuta dice molto. Un adempimento da sbrigare, con i costi di consulenza e di aggiornamento dei software che ne sono seguiti, e due anni di mugugni. Nessuno l’ha raccontata come un investimento in semantica condivisa, eppure il risultato è che oggi un dato di fatturazione italiano è leggibile da qualsiasi sistema senza negoziazione preliminare, che è esattamente la condizione che rende economico far lavorare un agente su quei dati.

Quello che lo Stato ha ottenuto con un obbligo, due aziende che vogliono far parlare i propri agenti devono ottenerlo per contratto, e il contratto va scritto prima che i sistemi siano in produzione.

Ogni coppia di sistemi è una traduzione da mantenere

L’alternativa allo standard condiviso è la traduzione, e l’interoperabilità ottenuta così si paga per coppia di interlocutori. Con tre fornitori sono tre mappature da mantenere, con dieci sono dieci, e ciascuna invecchia per conto suo ogni volta che una delle due parti cambia il proprio modello dati senza avvertire.

È il problema che l’EDI ha affrontato negli anni novanta con i tracciati concordati fra grandi committenti e filiera, e che si è risolto solo dove c’era un soggetto abbastanza forte da imporre il proprio formato a tutti gli altri. La grande distribuzione lo ha fatto, l’automotive lo ha fatto, e chi stava a valle si è adeguato perché l’alternativa era uscire dalla fornitura.

Con gli agenti quel soggetto forte esiste ancora, e adesso ha uno strumento in più: chi definisce l’ontologia definisce anche cosa i sistemi degli altri sono in grado di dire.

Chi pubblica il vocabolario e chi lo versiona

Un vocabolario condiviso è un oggetto vivo, e la parte difficile comincia dopo averlo scritto. Qualcuno deve pubblicarlo in un posto raggiungibile, dargli un numero di versione, dichiarare quanto dura la compatibilità all’indietro e avvisare la controparte prima di cambiare il significato di un campo invece che dopo.

Sono pratiche che il mondo del software conosce da vent’anni e che nelle relazioni commerciali fra aziende non esistono quasi mai. Il tracciato di scambio viene concordato all’inizio del rapporto, finisce in un allegato tecnico del contratto, e da quel momento cambia attraverso email fra due persone che si conoscono, fino al giorno in cui una delle due cambia lavoro.

Quella fragilità con gli agenti diventa più cara, perché il sistema che riceve un campo dal significato mutato non si ferma a chiedere. Interpreta, risponde, e procede fino a quando qualcuno a valle nota che i numeri del trimestre non tornano.

Lo standard arriva prima o dopo il danno

Nelle filiere dove il costo di un errore è alto, l’interoperabilità semantica esiste già e sta dentro i capitolati. Nelle altre si scoprirà con il primo incidente serio, un ordine confermato per una quantità che nessuno voleva, una scadenza calcolata su una decorrenza diversa, un pagamento autorizzato su un importo che il sistema di controparte considerava al netto.

Fino a ieri quegli incidenti erano rari perché in mezzo c’era sempre qualcuno che leggeva. Una persona che vede arrivare un numero strano si ferma e telefona, e in quella telefonata avviene la riconciliazione semantica che nessuno ha mai messo per iscritto.

Il lavoro che stiamo togliendo agli agenti umani nella filiera è proprio quello, e non lo stiamo sostituendo con niente. Le aziende che nei prossimi mesi scriveranno il proprio vocabolario lo faranno per risparmiare token, e si troveranno in mano un asset di negoziazione con la filiera che non avevano previsto.

23 Settembre 20265 Ottobre 2026AI & GENAI, TECH & BUSINESS

L’entropia dei tuoi dati si paga a token

L’entropia di un archivio aziendale si vede bene prendendo lo stesso contratto in due forme. Nella prima è un PDF scansionato di quaranta pagine, con il tracciato di firma in fondo e la data di scadenza dentro un periodo che comincia a metà della pagina ventidue. Nella seconda è una riga con tre campi, controparte, data di decorrenza, durata in mesi. Un agente a cui chiedi quando scade risponde in entrambi i casi, e nel primo paga una quantità di lavoro che non serve a nessuno.

Quel lavoro ha un nome preso in prestito dalla teoria dell’informazione, entropia, e in azienda si è sempre potuto ignorare perché a sostenerlo erano le persone. Da quando esiste una bolletta, l’ambiguità organizzativa ha un prezzo leggibile, e il disordine dei documenti è la parte di quel prezzo che si misura più in fretta.

Lo stesso contenuto in due forme diverse

Un modello legge sequenze di token, e non ha modo di sapere in anticipo quali porzioni di quelle sequenze contengano la risposta. Nel PDF scansionato deve attraversare le premesse, le definizioni, le clausole di riservatezza e il foro competente prima di arrivare alla durata, e quelle pagine entrano in finestra tutte quante, pagate a peso.

Nella riga con tre campi la struttura ha già fatto il lavoro di selezione. Il significato è nella posizione del dato, non nella prosa che lo circonda, e la posizione costa pochissimo perché è decisa una volta per tutte le righe della tabella.

La differenza fra le due forme non sta nella quantità di informazione, che è la stessa, sta in quanto lavoro serve per estrarla. Un archivio di documenti scritti bene per un lettore umano è un archivio costoso per un lettore che paga a token.

Entropia bassa, volume alto

Vale la pena ricordare cosa succede a monte. La tokenizzazione spezza il testo in unità statistiche, e quelle unità non corrispondono ai concetti: la stessa clausola espressa in italiano burocratico occupa sensibilmente più token della stessa clausola espressa in forma tabellare, e il modello non sa che sta rileggendo per la terza volta una formula che ha già incontrato in altri ottocento contratti dello stesso tipo.

Il boilerplate contrattuale è il caso limite di entropia bassa che costa cara. Ripetitivo fino alla noia, quindi povero di informazione nuova, e allo stesso tempo voluminoso, quindi costoso. L’informazione che cambia da contratto a contratto sta in poche decine di parole sparse in mezzo a decine di migliaia.

Ogni schema è una perdita decisa in anticipo

Qui arriva la parte che mi interessa di più, perché è dove la questione smette di essere tecnica. Modellare significa scegliere quali campi esistono, e un campo che non esiste nello schema diventa invisibile a chiunque interroghi il sistema attraverso quello schema.

Se il modello dati prevede controparte, decorrenza e durata, ma non prevede il rinnovo tacito, l’agente risponderà con sicurezza che il contratto scade il trentuno dicembre, e quel contratto si rinnoverà da solo per altri dodici mesi mentre tutti guardano la data sbagliata. Lo stesso vale per la penale di recesso, per il preavviso differenziato a seconda della parte che recede, per le proroghe negoziate a voce e messe per iscritto in uno scambio di email che nel grafo non entra.

La compressione è la ragione per cui l’ontologia fa risparmiare, e la perdita è il prezzo di quel risparmio. Il problema non è che ci sia una perdita, è che venga decisa da chi disegna lo schema senza che nessun altro se ne accorga. Vale la pena tenerlo accanto alla questione che avevo sollevato su dove finisce l’ontologia e comincia l’agente, perché uno schema definisce insieme cosa si può capire e cosa si può fare.

Il corpus cresce da solo

C’è un fattore nuovo che peggiora il conto, e riguarda chi quei documenti li produce. Da quando in azienda si generano testi con l’AI, il volume di prosa interna aumenta senza che aumenti la quantità di decisioni prese, e quei testi entrano nei repository insieme agli altri.

Ne ho scritto parlando di quella broda di testi che nessuno ha deciso di scrivere, e il collegamento con la bolletta è diretto: ogni verbale generato, ogni riassunto prodotto per riflesso, ogni versione alternativa di un documento salvata perché non si sa mai, aumenta l’entropia del corpus che gli agenti dovranno attraversare. Ti stai facendo pagare due volte lo stesso disordine, una quando lo produci e una quando lo interroghi.

Da dove si comincia a misurare

Il modo pratico per capire quanto stai pagando è partire dalle domande invece che dai dati. Prendi le dieci richieste che in un mese arrivano più spesso a un ufficio, quelle a cui qualcuno risponde aprendo sempre gli stessi tre posti, e per ciascuna conta quanti documenti bisogna attraversare per arrivare alla risposta e quante di quelle pagine contengono davvero il dato.

Il rapporto fra le due quantità è la misura di entropia che serve, e nelle aziende dove ho fatto questo esercizio il risultato oscilla fra il ridicolo e l’imbarazzante, con decine di pagine lette per estrarre un numero, una data e un nome. Un essere umano quel rapporto lo migliora da solo, perché impara dove guardare e salta il resto. Un agente senza struttura ricomincia ogni volta dalla prima pagina.

Da lì la decisione diventa gestibile, perché riguarda un numero finito di campi. Non serve modellare l’azienda, serve modellare le venti entità e le trenta relazioni che stanno dietro a quelle dieci domande, e tutto il resto può aspettare il giorno in cui qualcuno lo chiederà davvero.

Chi sostiene il costo della struttura

Strutturare è lavoro, lo fa qualcuno, e quel qualcuno di solito è lontano da chi riceve il beneficio. L’ufficio che deve compilare tre campi in più al momento della firma non vedrà mai il risparmio sulla spesa di inferenza del trimestre successivo, e nelle organizzazioni dove il costo e il beneficio stanno in due linee di budget diverse questa asimmetria basta a fermare tutto.

Il modo che ho visto funzionare è agganciare la struttura a un momento in cui qualcuno sta già lavorando su quel dato. La data di scadenza la si estrae quando il contratto si firma, non in un progetto di bonifica sei mesi dopo, perché in fase di bonifica costa il doppio e la qualità è peggiore.

Un archivio disordinato ha sempre avuto un costo, pagato in ore di ricerca, in scadenze mancate, in due persone che cercano lo stesso documento senza sapere l’una dell’altra. La differenza di adesso è che quel costo arriva in una forma che la funzione finanza sa leggere, e le cose che la funzione finanza sa leggere prima o poi finiscono in un piano.

14 Settembre 20265 Ottobre 2026AI & GENAI, TECH & BUSINESS

Progettare il loop invece di scrivere il prompt successivo

Chiedi a Claude di aggiungere un pulsante di like e parte un loop agentico. Legge il codice, fa la modifica, lancia i test e ti restituisce qualcosa che crede funzioni. Poi tocca a te: apri la pagina, clicchi, guardi la console del browser, e scrivi il prompt successivo. Il collo di bottiglia sei tu, per come è fatto il ciclo: l’agente produce, l’umano controlla, un turno alla volta.

Delba de Oliveira e Michael Segner, del team di Claude Code, hanno messo per iscritto a fine giugno la definizione di loop agentico che usano internamente: «agents repeating cycles of work until a stop condition is met». Agenti che ripetono cicli di lavoro finché non scatta una condizione di stop. È una definizione povera di aggettivi e piena di conseguenze, perché tutto il peso si sposta su una domanda sola, chi scrive quella condizione.

Il ciclo di base: raccoglie contesto, agisce, verifica, e riparte finché la condizione di stop non è soddisfatta.

Quattro modi di far girare un agente

Il turn-based è il loop agentico che usiamo tutti senza chiamarlo così. Parte da un tuo prompt, Claude raccoglie il contesto, agisce, controlla il proprio lavoro e risponde, e si ferma quando giudica il compito chiuso oppure quando gli serve qualcosa che non ha. Quello che deleghi, se lo deleghi, è il controllo del risultato.

Il goal-based nasce quando un turno solo non basta. Con /goal dichiari che cosa significa fatto, e Claude continua a lavorare senza che tu debba rilanciarlo a ogni giro. Ogni volta che prova a fermarsi, un modello valutatore rilegge la conversazione e decide se la condizione regge, e se non regge lo rimanda al lavoro con una motivazione che diventa la guida del turno successivo. Qui deleghi la condizione di uscita, ed è la ragione per cui i criteri deterministici funzionano molto meglio delle formule generiche.

Il time-based serve al lavoro che torna, quello in cui il compito resta identico e cambiano solo gli ingressi: il riassunto dei messaggi del mattino, la pull request che riceve commenti di review e fa fallire la CI. Deleghi l’innesco.

Il proattivo è quello in cui davanti allo schermo non c’è nessuno. Un evento o una pianificazione fanno partire il lavoro, ogni task esce quando raggiunge il proprio obiettivo, la routine continua a girare finché non la spegni. Deleghi il prompt, cioè la parte che fino a ieri consideravamo il mestiere.

I comandi che Anthropic ha rilasciato

/goal imposta una condizione di completamento valida per la sessione, lunga fino a quattromila caratteri. A ogni fine turno un modello piccolo e veloce, Haiku per impostazione predefinita sull’API di Claude, restituisce uno di tre verdetti: soddisfatta, non ancora, impossibile. Il valutatore non esegue comandi e non legge file per conto suo, giudica soltanto quello che Claude ha già portato in conversazione, quindi la condizione va scritta come qualcosa che l’output può dimostrare. Dentro la condizione conviene mettere anche un tetto, «oppure fermati dopo venti turni», altrimenti il loop si allunga oltre quello che ti aspetti. Funziona anche in modalità non interattiva, con claude -p.

/loop rilancia lo stesso prompt a intervalli regolari e gira sul tuo computer, quindi si spegne quando spegni la macchina. /schedule sposta la stessa idea nel cloud e la trasforma in una routine, che continua a lavorare a portatile chiuso. Una routine può partire da una pianificazione oraria, giornaliera, feriale o settimanale, da una chiamata HTTP autenticata a un endpoint dedicato, oppure da un evento GitHub come l’apertura di una pull request o la pubblicazione di una release, con filtri su autore, titolo, branch, etichette. L’intervallo minimo è un’ora. Le routine sono disponibili sui piani a pagamento di Claude, si gestiscono da claude.ai/code/routines e hanno un tetto giornaliero di esecuzioni oltre al consumo ordinario dell’abbonamento.

Intorno a questi due comandi girano altri pezzi. La modalità auto approva le chiamate agli strumenti dentro un turno, e si combina bene con /goal, che invece toglie di mezzo la conferma tra un turno e l’altro. I dynamic workflows, in research preview, permettono a Claude di orchestrare sottoagenti in parallelo. Le skill descrivono i controlli da ripetere. Per chi non apre mai un terminale ci sono gli scheduled task di Cowork, che si configurano dall’interfaccia, girano da remoto anche a computer spento e usano i connettori e le skill già attive.

Il criterio d’uscita vale più del prompt

La qualità di un loop dipende dal sistema che gli sta intorno, e il pezzo che pesa di più è la verifica. Il consiglio di Anthropic è codificare in un file di skill i passaggi che oggi fai a mano, così che l’agente possa controllare il proprio lavoro dall’inizio alla fine invece di dichiararlo finito appena la modifica è andata a buon fine: avviare il server, aprire la pagina, cliccare il controllo nuovo, fare uno screenshot prima e dopo, guardare che in console non compaiano errori, misurare le metriche di performance. Più i controlli sono quantitativi, più l’autoverifica diventa semplice.

Nel mio flusso editoriale la condizione di uscita è un exit code. Uno script passa il testo al setaccio cercando i tic di scrittura che non voglio, e finché non esce zero il pezzo non si consegna. È un criterio grezzo, e misurabile, e chiude il loop in molti meno giri di qualunque descrizione a parole di che cosa sia un buon articolo.

Più il criterio d’uscita è misurabile, meno turni servono al loop per chiudersi da solo.

Due accorgimenti da rubare. Il primo è affidare la revisione a un secondo agente con contesto pulito, perché chi non ha seguito il ragionamento del primo è meno incline a confermarlo. Il secondo riguarda cosa fare quando un risultato non è all’altezza: correggere il singolo errore serve una volta sola, mentre spostare la correzione dentro la skill la rende valida per tutti i giri successivi. È la differenza tra un loop che migliora e uno che ti fa rimettere a posto la stessa cosa per la terza volta.

Sei loop da accendere questa settimana

La rassegna delle sette è il più facile da accendere: uno scheduled task che legge messaggi, posta e calendario delle ultime ventiquattro ore e consegna un brief prima che tu apra il computer. «Ogni mattina alle 7:00 riassumi Slack, email e calendario delle ultime 24 ore e scrivimi trecento parole con le tre cose che oggi richiedono una mia decisione».

Quando le richieste arrivano su un canale condiviso, la coda si accumula da sola e qualcuno passa la giornata a smistarla. Una routine oraria con un obiettivo esplicito la tiene bassa: «ogni ora controlla il canale delle richieste, e non fermarti finché ogni segnalazione trovata in questo giro non ha un responsabile, una priorità e una risposta».

C’è poi il documento che non esce finché non passa l’audit, il caso in cui il criterio esiste già da qualche parte e nessuno lo aveva mai dato in pasto all’agente: «l’articolo passa lo script di audit con exit code 0 e resta sopra le 1.400 parole, fermati dopo sei tentativi».

Anche il debito accumulato su un sito si può assegnare a un lunedì mattina: «ogni lunedì alle 6:00 controlla i post pubblicati nell’ultimo mese, segnala meta description mancanti, immagini senza testo alternativo e link interni rotti, e prepara le correzioni in bozza».

Sulle pull request funziona meglio l’intervallo, perché quello che cambia sta fuori dal tuo progetto e arriva quando arriva: /loop 10m controlla la mia PR, rispondi ai commenti di review, sistema la CI che fallisce.

L’ultimo parte da un evento invece che da un orario. La pipeline di deploy chiama via HTTP l’endpoint della routine appena il rilascio è in produzione, la routine esegue gli smoke test, cerca regressioni nei log e scrive go o no-go nel canale di release prima che la finestra si chiuda. Lo stesso schema regge sugli alert: il sistema di monitoraggio passa il corpo dell’allarme, l’agente correla lo stack trace con i commit recenti e apre una bozza di pull request con una proposta di correzione, così chi è di turno trova qualcosa su cui lavorare invece di un terminale vuoto.

Per scegliere quale accendere per primo, Anthropic propone un criterio pratico: guarda il lavoro che già fai, prendi un compito in cui sei tu a rallentare tutto, e chiediti quale pezzo puoi passare alla macchina, se sai scrivere il controllo di verifica, se l’obiettivo è già abbastanza chiaro da poter essere giudicato da un altro modello, oppure se il lavoro arriva comunque a scadenze regolari.

Quanto costa tenere acceso un loop

Un loop senza confini è un modo elegante di bruciare token. Il primo controllo è la scelta del pezzo giusto: un compito piccolo non ha bisogno di più agenti, e parecchio lavoro gira benissimo su modelli più economici, tenendo quello più capace per le decisioni di giudizio. Il secondo è la precisione del criterio di uscita, che deve essere specifico abbastanza da far arrivare Claude alla soluzione presto, senza però farlo fermare troppo presto.

Poi ci sono due regole che sembrano banali e non lo sono. Quando una parte del lavoro è deterministica, conviene che sia uno script a farla, perché eseguire uno script costa meno che ragionare ogni volta sugli stessi passaggi. E l’intervallo di una routine va tarato su quanto spesso cambia davvero la cosa che stai guardando, non su quanto ti piacerebbe essere aggiornato. Prima di lanciare un workflow su tutto il perimetro conviene provarlo su una fetta piccola, visto che l’orchestrazione dinamica può generare centinaia di agenti.

Per misurare c’è /usage, che scompone il consumo recente per skill, sottoagenti e connettori, /goal senza argomenti, che mostra turni e token spesi finora, e /workflows, da cui si vede quanto sta consumando ogni agente e si può fermarne uno al volo.

Una routine firma con la tua identità

Qui arriva la parte che in azienda pesa più del risparmio di tempo. Una routine gira come sessione autonoma: durante l’esecuzione non ci sono richieste di permesso, e Claude può usare tutti gli strumenti dei connettori inclusi, comprese le scritture. Quando crei una routine i connettori attivi vengono inclusi tutti per impostazione predefinita, e toglierli è un gesto che conviene fare subito.

Quello che la routine fa attraverso la tua identità appare come fatto da te. I commit e le pull request portano il tuo utente GitHub, i messaggi su Slack e i ticket su Linear passano dai tuoi account collegati. L’ambiente cloud definisce a quali domini la sessione può arrivare, e il testo che accompagna un’attivazione via API viene consegnato all’agente dentro un blocco marcato come dato non affidabile, così il prompt della routine deve dichiarare esplicitamente di volerlo usare prima che quel testo possa orientare il lavoro.

Sono dettagli di configurazione, e insieme disegnano una superficie di responsabilità nuova. Permesso revocabile è la formula che uso da tempo per questa condizione, in cui l’autonomia di un sistema è sempre concessa e sempre ritirabile. Con le routine la domanda operativa diventa chi ha aperto il permesso, quali strumenti ha lasciato dentro, e in quanto tempo qualcuno se ne accorge.

Il livello che stavamo saltando

Per due anni abbiamo lavorato quasi solo sul primo livello, la formulazione del singolo turno, e poi sul secondo, il contesto da mettere davanti al modello. Sopra c’è l’harness, il guscio che decide che cosa l’agente può toccare e con quali permessi. In mezzo sta il livello che stavamo saltando: quante volte l’agente ci riprova, e a quali condizioni ha il diritto di dire che ha finito.

Il loop sta sopra il contesto e sotto l’harness: un guasto si attribuisce al livello che lo ha prodotto.

Chi progetta il loop agentico decide dove finisce il lavoro della macchina e dove comincia la responsabilità di una persona. Nei prossimi mesi credo che nelle organizzazioni comparirà un ruolo che oggi non ha ancora un nome: qualcuno che scrive le condizioni di stop, le rivede quando cambia il contesto, e risponde di tutto quello che quelle condizioni lasciano passare.

20 Luglio 202623 Luglio 2026AI & GENAI, TECH & BUSINESS

Baseten a 13 miliardi e il paradosso dell’inferenza a basso costo

Il 18 giugno il Wall Street Journal ha scritto che Baseten sta chiudendo un round da 1,5 miliardi di dollari, con una valutazione che arriva fino a 13. Quattro giorni dopo l’azienda lo ha confermato: Series F, guidato da Altimeter, Conviction e Spark Capital. A gennaio la stessa Baseten valeva 5 miliardi, a settembre 2025 ne valeva poco più di due. Sei volte tanto in nove mesi, per una società che non costruisce modelli e non vende intelligenza propria, ma si occupa di farli girare bene una volta che qualcun altro li ha addestrati.

Ecco quello che mi ha fermato, e non è la cifra. Il capitale si sta spostando dalla parte spettacolare dell’AI, l’addestramento dei modelli, a quella operativa, l’inferenza: il lavoro ripetitivo e poco fotogenico di rispondere, milioni di volte al giorno, a chi fa una domanda. La scommessa di Baseten è che lì, sul costo di quel lavoro, ci sia il margine. La domanda che mi porto dietro è un’altra: una valutazione da 13 miliardi su un’infrastruttura che vende risparmio è il segno che il mercato sta maturando, o l’ennesima curva troppo ripida di una corsa all’oro?

L’inferenza è il livello meno glamour dello stack

Nessuno apre una demo vantandosi della latenza. L’addestramento ha preso quasi tutta l’attenzione degli ultimi anni perché era spettacolare, cluster enormi, GPU introvabili, miliardi bruciati per tirare su un modello più grande del precedente. Poi il modello esce, arriva il primo cliente vero, e la bolletta comincia a contare. L’inferenza è quel momento lì, quando il modello smette di essere una promessa e deve produrre una risposta utile, in fretta, a un costo che regga. È lo strato in cui l’intelligenza tocca davvero la persona, ed è lo stesso strato in cui un’azienda scopre se i conti tornano. In Pelle Digitale ho provato a raccontare proprio questa frontiera, la pellicola sottile dove la tecnologia diventa esperienza per chi la usa. Baseten vive lì, prende modelli, spesso open source, e li serve su una rete multi-cloud che oggi processa più di un miliardo di chiamate al giorno, distribuite su 87 cluster e 18 cloud diversi.

Da 2,15 a 13 miliardi in nove mesi

La cadenza degli aumenti è da capogiro. Series D a settembre 2025, valutazione 2,15 miliardi. Series E a gennaio, 5 miliardi, con dentro anche Nvidia. A maggio si parlava già di un round vicino al miliardo a una pre-money di 11. A giugno il round si gonfia a 1,5 miliardi fino a 13. Il fatturato segue una traiettoria altrettanto verticale, dal run-rate annualizzato di circa 200 milioni a 600 nell’arco di un trimestre, una crescita che molti raccontano come ventiplicata anno su anno. Tra gli investitori storici ci sono Greylock, IVP, CapitalG e la stessa Nvidia, che a gennaio aveva messo 150 milioni. Resta che a 13 miliardi parliamo di un multiplo sui ricavi vicino a 22 volte, e un multiplo del genere racconta molto più le aspettative sul futuro che i conti di oggi.

Il prezzo per task conta più del prezzo per token

La tesi di chi mette i soldi è abbastanza diretta. I modelli open source sono diventati buoni abbastanza da rendere superfluo, per molti casi d’uso, pagare il sovrapprezzo di un modello proprietario. Alcuni clienti di Baseten, da Cursor a Mercor a OpenEvidence, dichiarano di spendere circa un terzo di quanto costerebbe loro un’API chiusa. Se quel dato regge, l’unità della competizione cambia: non è più il modello migliore a fare la differenza, è la capacità di consegnarlo veloce e a basso costo. Ne avevo scritto la settimana scorsa a proposito della guerra dei prezzi dell’AI certificata dal Wall Street Journal, dove i volumi corrono verso il basso costo mentre la spesa resta alla frontiera. Baseten è l’altra faccia di quella dinamica, il venditore di pale e picconi per chi non vuole restare incastrato dentro un solo fornitore. Together AI, Fireworks, Modal Labs giocano la stessa partita, e Fireworks starebbe trattando un round a 15 miliardi. Il fondatore Tuhin Srivastava la riassume così: se il cloud è stato la base della generazione precedente di grandi aziende tecnologiche, l’inferenza è la base della prossima. Intanto Baseten ha firmato un accordo di collaborazione con AWS e ha comprato Parsed, una startup di post-training, segno che vuole presidiare tutto il ciclo di vita del modello, non solo il momento della risposta.

Due prezzi nello stesso round

C’è un dettaglio nella struttura del round che dice più della cifra. È diviso in due fasce, alcuni investitori entrano a una valutazione di 11 miliardi, altri pagano 13. È un meccanismo diventato comune nei mega-round del 2026, serve a sbandierare il numero più alto tenendo dentro chi vuole un prezzo d’ingresso più cauto. Lo si può leggere in due modi. Come ingegneria finanziaria che gonfia il titolo, oppure come fotografia fedele di quanto sia diventato difficile mettere d’accordo investitori con appetiti di rischio diversi sullo stesso asset. Tra i nomi del round c’è Wellington Management, un gestore di lungo periodo, non esattamente la firma che ti aspetti quando si parla di schiuma speculativa. La sua presenza è la texture che complica la storia comoda della bolla. A 13 miliardi Baseten viene prezzata come un pezzo della macchina che i team di AI non possono permettersi di sbagliare, più che come un fornitore qualsiasi seduto tra i cloud e i modelli.

Una corsa all’oro è sempre una bolla?

Quindici anni fa scrivevo di un’altra ondata di valutazioni che sembravano slegate dai fondamentali, quella dei social network e delle prime startup mobile, e mi chiedevo se i numeri avessero senso. Molti di quei numeri non lo avevano, alcune di quelle aziende sono sparite, altre sono diventate l’infrastruttura su cui viviamo adesso. La storia della tecnologia raramente sceglie tra bolla e rivoluzione, di solito fa le due cose insieme, gonfia troppo e nello stesso movimento costruisce qualcosa che resta. L’inferenza ha però una caratteristica che la distingue dalla speculazione pura, assomiglia più a una bolletta che a una puntata, torna ogni volta che un utente fa una domanda, a prescindere dall’umore del mercato. Questo non mette al riparo Baseten dal rischio che gli iperscalari, Amazon su tutti, decidano di tirare l’inferenza dentro le proprie piattaforme e schiaccino i margini dello specialista. Spiega però perché un asset manager prudente sceglie di entrare adesso.

Il test vero arriva dopo, quando i soldi saranno atterrati e i clienti dovranno decidere, bolletta alla mano, se affidarsi a Baseten costa davvero meno che cavarsela da soli. A quel punto sapremo se quei 13 miliardi erano la misura di un’infrastruttura diventata essenziale o il prezzo di una puntata fatta nel momento più caldo del ciclo. Per adesso l’unica cosa certa è dove il mercato sta mettendo i soldi veri.

Fonti: TechCrunch, AI inference startup Baseten reportedly raising $1.5B; Baseten, Raises $1.5 Billion to Power the Next Era of AI Inference (comunicato ufficiale). Dati sul round riportati in origine dal Wall Street Journal.

16 Luglio 202610 Luglio 2026AI & GENAI, TECH & BUSINESS

Bolt: la guida completa al builder AI che gira dentro il tuo browser

Il 3 ottobre 2024 Eric Simons pubblica un tweet. Nessun budget di marketing, nessuna campagna, un link a un prodotto chiamato bolt.new costruito da una società che l’anno prima faceva ottantamila dollari di ricavi ricorrenti e stava per chiudere. Il primo giorno il prodotto aggiunge 60.000 dollari di ARR. Il secondo giorno altri 80.000, più di quanto StackBlitz avesse raccolto in sette anni di lavoro. In quattro settimane sono quattro milioni, a marzo 2025 quaranta.

Dentro quella storia c’è una lezione che riguarda poco l’AI e molto la pazienza industriale, e c’è la ragione tecnica per cui Bolt resta diverso dai suoi concorrenti. Questa è la terza e ultima guida della serie, dopo Lovable e Replit.

Sette anni di infrastruttura prima del successo improvviso

Simons e Albert Pai fondano StackBlitz nel 2017 per costruire un ambiente di sviluppo dentro il browser. Passano quattro anni su una tecnologia chiamata WebContainers: un kernel scritto in Rust, compilato in WebAssembly, che fa girare Node.js dentro la scheda del browser, senza server remoti. Funziona benissimo. Lo usano Google, Cloudflare, Uber per condividere ambienti di debug, e SvelteKit per i tutorial interattivi. I ricavi restano sotto il milione.

A febbraio 2024 i due prototipano l’idea di generare applicazioni con l’AI dentro quell’ambiente, e la mettono via perché i modelli disponibili non reggono. A giugno ottengono l’accesso anticipato a Claude 3.5 Sonnet di Anthropic, il primo modello capace di sostenere l’esperienza. Ci lavorano da luglio, pubblicano a ottobre. La crescita è tale da saturare temporaneamente la capacità di calcolo di Anthropic, e Dario Amodei la descrive come la più rapida mai vista in un cliente.

A gennaio 2025 StackBlitz raccoglie una Series B guidata da Emergence Capital e GV, con Greylock, Madrona e Conviction, per un totale di 135 milioni raccolti e una valutazione intorno ai 700 milioni. Simons ha definito il lancio un successo improvviso costruito in sette anni.

La cosa che mi interessa di questa vicenda è il rovescio di ciò che si racconta di solito sull’AI. Il modello ha reso possibile il prodotto, e il prodotto è stato possibile perché qualcuno aveva speso quattro anni su un problema che sembrava senza mercato.

Un computer intero dentro la scheda

Quando digiti un prompt su Bolt e premi invio, non parte una macchina virtuale su un cloud da qualche parte. Parte un ambiente Node.js dentro il tuo browser. L’agente scrive il codice, installa i pacchetti, esegue il server di sviluppo, e tu vedi l’anteprima girare mentre le modifiche arrivano. Il codice è editabile direttamente, con un editor derivato da VS Code, e questo rende Bolt il più tecnico dei tre strumenti della serie.

L’architettura ha una conseguenza economica che i concorrenti non hanno. Simons l’ha spiegata a Sacra: quando l’utente lancia un progetto, l’ambiente costa zero all’azienda, perché gira sul computer dell’utente. Bolt dichiara margini lordi intorno al settanta per cento, vicini a quelli di un SaaS tradizionale, ed è profittevole, mentre gli altri accendono container su infrastrutture a noleggio per ogni sessione. In un mercato dove tutti bruciano capitale sull’inferenza, questa è una posizione diversa, e per chi valuta la durabilità di un fornitore conta più di una demo.

Intorno al nucleo l’azienda ha costruito il resto. Bolt Cloud, arrivato ad agosto 2025, aggiunge hosting, database, autenticazione e funzioni serverless. Da allora ogni progetto include database interni illimitati, creati quando servono, con gestione utenti, funzioni edge, storage dei file, e l’integrazione con Supabase resta disponibile per chi la preferisce. C’è l’integrazione con Stripe per incassare pagamenti dalle app costruite, ci sono i domini acquistabili dalla piattaforma, e le analitiche del sito pubblicato.

Bolt ha smesso di inseguire i curiosi

Dopo il lancio, centinaia di migliaia di utenti consumer arrivano a costruire progetti personali, e se ne vanno con la stessa velocità. Simons ha raccontato che quel segmento aveva tassi di abbandono altissimi e costi di uscita prossimi allo zero, quindi l’azienda ha girato il timone verso i team di prodotto e ingegneria dentro le aziende, dove la retention somiglia a quella di un SaaS classico.

Oggi l’enterprise vale circa un quarto dei ricavi, il B2B nel suo complesso sta superando la metà, e Bolt dichiara che il 75 per cento delle Fortune 500 usa la piattaforma. A maggio 2026 è arrivata la partnership con Microsoft Azure e Microsoft 365, che aggiunge il Marketplace Microsoft ai canali di acquisto accanto a quello AWS, il deployment nativo su Azure, e l’integrazione con Teams e Microsoft 365 Copilot.

Questa traiettoria dice qualcosa a chi decide gli acquisti. Uno strumento che nasce per i curiosi e si sposta verso l’impresa smette di ottimizzare per la meraviglia dei primi quindici minuti e comincia a ottimizzare per il rinnovo del contratto, che è il momento in cui la sicurezza e la governance diventano argomenti di vendita invece che note a piè di pagina.

Sono i file a consumare i token

Il piano gratuito dà un milione di token al mese, con un tetto di trecentomila al giorno, progetti pubblici e privati, hosting con il marchio Bolt in vista, e un limite di dieci megabyte sui file caricati. Il piano Pro parte da 25 dollari al mese per dieci milioni di token, toglie il tetto giornaliero, il marchio, e aggiunge dominio personalizzato e condivisione privata. Il piano Teams costa 30 dollari per membro, con fatturazione centralizzata e controlli di accesso. Enterprise va a preventivo. Dal luglio 2025 i token non consumati si riportano al mese successivo, per un massimo di due mesi, e servono un abbonamento attivo per essere usati.

La particolarità sta in cosa mangia i token. Bolt sincronizza l’intero albero dei file del progetto con il modello a ogni messaggio, quindi il consumo non dipende dalla lunghezza della tua domanda, ma dalla dimensione di quello che hai costruito fino a quel momento. Una landing page da cinque file costa poco per prompt. Un’applicazione da cinquanta file costa molto, e continua a costare di più mano a mano che cresce. Gli utenti che spingono un progetto oltre una certa complessità riferiscono singoli prompt da un milione di token, cioè l’intero piano gratuito mensile in una richiesta.

L’effetto pratico è che i primi giorni sembrano economici e gli ultimi sembrano una rapina, quando invece il prezzo unitario non è mai cambiato. Chi lavora bene con Bolt tiene i progetti modulari, usa le modalità di discussione e pianificazione per ragionare senza generare, e parte dai template. I prezzi si verificano su bolt.new/pricing prima di ogni decisione.

La sandbox protegge finché il codice non esce

La sicurezza di Bolt va guardata in due tempi, perché la piattaforma e le applicazioni che produce hanno posture opposte.

Durante la costruzione l’isolamento è buono, forse il migliore della categoria. Il WebContainer è una sandbox del browser, il codice generato non ha un filesystem vero, non ha rete privilegiata, e qualunque server tu avvii è raggiungibile soltanto dalla tua scheda. Finché resti lì dentro, il danno che puoi fare a te stesso è limitato.

Il problema comincia quando quel codice esce. Il deploy va su un host reale, l’app si collega a un progetto Supabase reale, a chiavi Stripe reali, a utenti reali, e a quel punto ogni scelta predefinita che l’agente ha preso durante il prototipo diventa una superficie di attacco. Le forme ricorrenti sono sempre le stesse: tabelle pubblicate senza Row Level Security attiva, quindi leggibili da chiunque possieda la chiave anonima che sta nel bundle JavaScript, chiavi API scritte dentro il codice del frontend e trovate dagli scanner automatici nelle prime ore dopo la pubblicazione, endpoint generati per fare operazioni sui dati senza un controllo su chi possiede quel dato, funzioni serverless senza limiti di frequenza sulle chiamate.

Bolt genera frontend, backend, schema del database e collante tra i servizi nella stessa sessione, e ogni strato è un posto dove un controllo di sicurezza viene saltato perché nessuno lo aveva chiesto nel prompt. Questo lo rende più esposto di uno strumento che genera solo interfacce, come v0. Scansioni indipendenti su oltre mille applicazioni costruite con questi strumenti hanno trovato problemi nella quasi totalità dei casi, con una quota rilevante di falle critiche, e i campioni includevano Bolt insieme a Lovable, Replit e v0, come documenta lo studio di Security Boulevard.

C’è un rischio più recente che vale la pena conoscere. I modelli suggeriscono a volte pacchetti npm che non esistono, e gli attaccanti registrano in anticipo quei nomi con dentro codice malevolo, aspettando che qualcuno installi la dipendenza allucinata. Un controllo delle dipendenze dopo ogni aggiunta smette di essere pignoleria.

Le regole per chi porta la responsabilità in azienda sono poche. Ogni file generato va trattato come se fosse pubblico. Ogni chiave passata dalla piattaforma va considerata compromessa e ruotata. La Row Level Security va attivata e verificata a mano, senza chiedere conferma all’AI che ha scritto il codice, perché il modello vede il file che gli mostri, non il controllo che hai dimenticato altrove. E la verifica va fatta sull’applicazione pubblicata, non sull’anteprima nella sandbox.

Il vecchio agente ha una data di spegnimento

Ad aprile 2026 Bolt ha ritirato il suo agente storico. Dal 13 aprile non è più selezionabile per i nuovi progetti, e dal 3 agosto 2026 i progetti costruiti con la vecchia versione, e i siti che ne derivano, smetteranno di essere accessibili: vengono commutati automaticamente su Claude Agent, che nel frattempo è diventato il motore predefinito della piattaforma. Chi passa a mano perde la cronologia della chat, mentre file e codice restano.

Il modello predefinito oggi è Claude Sonnet 4.6, con Haiku 4.5 per le modifiche rapide e Opus 4.6 per il ragionamento complesso. Si può guidare il contesto del progetto con un file claude.md, la stessa convenzione che chi lavora con Claude Code conosce bene.

Vale la pena fermarsi su questa scadenza, perché è il tipo di evento che nessuna demo racconta. Un fornitore giovane può decidere che una parte della tua storia di lavoro non è più supportata, fissare una data, e migrarti d’ufficio. Il codice resta tuo, ed è la ragione per cui la portabilità va verificata prima di costruirci sopra, non dopo aver ricevuto la mail.

Dove si colloca rispetto a Lovable e Replit

Bolt è lo strumento più vicino allo sviluppatore dei tre. Ti lascia le mani nel codice, supporta più framework, gira interamente nel browser, e il suo modello di costo premia i progetti piccoli e modulari. Lovable arriva prima a un’applicazione web presentabile ed è la più amichevole con chi non scrive codice. Replit è l’ambiente più completo, con terminale, database gestito, deployment sofisticati e app mobili native, ed è la risposta quando il progetto deve girare in produzione da qualche parte.

Chi sceglie Bolt di solito è una persona che sa cosa sta guardando quando apre un file, e vuole che l’AI faccia la parte noiosa. Chi sceglie gli altri due sta comprando qualcosa che assomiglia di più a un servizio completo. Le tre guide stanno insieme nella sezione AI e GenAI.

Il primo progetto

Si parte dal piano gratuito, senza carta di credito, con un milione di token che bastano per capire il meccanismo e costruire qualcosa di piccolo. La prima cosa da fare è restare in modalità discussione o pianificazione finché l’impianto non è chiaro, perché ogni giro di generazione su un progetto già grande costa più del precedente.

Poi si costruisce, tenendo i moduli separati e i file corti, che qui è una scelta economica prima che architetturale. Quando servono dati e autenticazione si usa il database integrato oppure Supabase, e si attiva la Row Level Security prima di mettere qualunque cosa online. Prima di pubblicare si cerca nel bundle compilato ogni traccia di chiavi segrete, si sposta il codice che chiama servizi a pagamento dentro una funzione lato server, e si prova l’applicazione pubblicata come se fosse di qualcun altro.

Dove regge, dove rallenta

Bolt è eccellente per portare in mezz’ora un’idea allo stato di prototipo funzionante, dentro una scheda del browser, senza installare niente. Landing page, strumenti interni, MVP, applicazioni che devono esistere in fretta per essere mostrate a qualcuno: su questo terreno è veloce come pochi, e la portabilità del codice ti lascia una via d’uscita. Dove rallenta è dove rallentano tutti, con l’aggravante del suo modello di costo: quando il progetto cresce, ogni prompt costa di più e l’agente perde il filo del contesto, e la tentazione di continuare a chiedere invece di mettere le mani nel codice diventa la voce più cara della fattura.

Per chi guida la tecnologia in azienda, Bolt è un caso di studio su due livelli. Sul primo è uno strumento che accorcia il ciclo dall’idea al prototipo mantenendo il codice leggibile e trasportabile, e questa è una virtù rara. Sul secondo è la dimostrazione che un’architettura scelta bene sette anni prima decide chi resta in piedi quando il costo dell’inferenza schiaccia i margini di tutti. Il mestiere di chi sa leggere il codice non scompare, si sposta verso la revisione, la sicurezza, e la scelta di quale fornitore meriti la propria dipendenza.

Senza dubbio tra un anno questi strumenti saranno più capaci e i loro margini più chiari. La domanda che resta aperta riguarda la data del 3 agosto: quando un fornitore decide che una parte del tuo lavoro non esiste più, quanto del tuo lavoro sei ancora in grado di portare via?

Riferimenti.

Ufficiali: sito Bolt, piani e prezzi, note di rilascio con il calendario del ritiro del vecchio agente.

Azienda e crescita: la scheda di Contrary Research su Bolt; l’intervista di Sacra a Eric Simons su margini, WebContainers e virata verso il B2B; la scheda Sacra su Bolt.new per finanziamenti e migrazione dell’agente.

La storia del lancio, raccontata da Simons: la puntata di Lenny’s Newsletter.

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

15 Luglio 202613 Luglio 2026AI & GENAI, TECH & BUSINESS

Model router: come funziona il middleware che smista le richieste AI

Tra l’applicazione e i modelli è comparsa una casella che diciotto mesi fa non esisteva. Si chiama model router, intercetta ogni richiesta e decide quale modello deve rispondere prima che la richiesta parta, e nel giro di pochi mesi ha sviluppato un mercato suo, con prodotti commerciali, progetti open source e paper accademici che se la contendono.

Il 2 luglio scrivevo che il router viene prima del modello, riprendendo un’osservazione di Tomasz Tunguz: la logica di instradamento, non il modello scelto per ultimo, determina costi, latenza e chi resta padrone dell’infrastruttura. Quel pezzo era la tesi. Questo è la mappa: come quella casella si costruisce dentro, chi la vende già pronta, e il vincolo che quasi nessuno disegna nel diagramma.

Regole scritte a mano, regole imparate

Le architetture di model router in circolazione si riducono a quattro famiglie, e conoscerle serve perché ognuna sposta il compromesso tra costo, latenza e qualità in un punto diverso.

La più semplice è quella euristica: regole fisse, parole chiave, lunghezza del prompt. Se la richiesta contiene una query SQL, va dritta a un modello da codice, senza che nessun classificatore si accenda. Costa niente e si spiega in una riga, e si rompe appena il traffico esce dai casi previsti da chi ha scritto le regole.

Il gradino successivo è il router appreso, un classificatore leggero, di solito su embedding, che predice quale modello renderà meglio su quella richiesta in base a valutazioni storiche. Qui la qualità del model router dipende interamente dalla qualità dei dati di valutazione con cui è stato addestrato, e questa dipendenza pesa più di qualunque scelta di algoritmo.

Poi ci sono le cascate, che rovesciano la logica: si prova prima il modello economico, un validatore controlla la risposta, e solo se il controllo fallisce la richiesta sale al modello più potente. E infine gli ensemble, dove più modelli lavorano in parallelo sulla stessa richiesta e un giudice algoritmico sintetizza o sceglie. La cascata ottimizza il costo accettando qualche giro in più di latenza, l’ensemble ottimizza la qualità accettando di pagare ogni risposta tre o quattro volte.

Il model router diventa un prodotto da scaffale

Fino a poco fa questa casella la scrivevi in casa. Adesso la compri. OpenRouter ha portato in produzione a giugno Fusion, la versione a scaffale dell’ensemble: la tua richiesta va a un pannello di modelli in parallelo e un giudice fonde le risposte. Sul benchmark di deep research DRACO di Perplexity, un pannello economico composto da Gemini 3 Flash, Kimi K2.6 e DeepSeek V4 Pro ha segnato 64,7%, sopra GPT-5.5 da solo (60,0%) e Opus 4.8 da solo (58,8%), a circa metà del costo della configurazione di punta. Il dato che trovo più istruttivo è un altro, sepolto nello stesso annuncio: fondere Opus 4.8 con sé stesso alza il punteggio da 58,8 a 65,5. È la sintesi a produrre valore, non solo la diversità dei modelli.

Sul versante dei router appresi, Not Diamond vende l’addestramento su misura: carichi i tuoi prompt, i modelli provati e i punteggi delle tue valutazioni, e ne esce un router calibrato sui tuoi criteri, comprese le regole di formattazione o le convenzioni di codice che nessun benchmark pubblico misura. Il prodotto, in pratica, è la trasformazione dei tuoi dati di valutazione in una politica di instradamento.

La via che resta in casa

Chi non vuole un intermediario tra sé e i modelli, per latenza o per riservatezza dei dati, ha alternative open source che nell’ultimo semestre sono maturate in fretta.

NadirClaw è un proxy locale compatibile con l’API OpenAI che parte da un’osservazione empirica: nelle sessioni di sviluppo assistito, il 60-70% dei prompt sono operazioni semplici, letture di file, formattazioni, domande brevi, e non hanno bisogno di un modello premium. Un classificatore su embedding decide in una decina di millisecondi, un motore di ottimizzazione sfronda schemi di strumenti gonfi e array ridondanti prima dell’invio, tagliando il peso in token dal 30 al 70%, e sui benchmark RouterArena il profilo a cascata predefinito segna 0,7358 riducendo la spesa API fino al 70%. Gira sulla tua macchina, con le tue chiavi, e nessuna piattaforma di mezzo può cambiarti le condizioni.

Il fronte accademico spinge un passo oltre. Agent-as-a-Router, il paper dietro il framework ACRouter, parte da una diagnosi precisa: i router statici falliscono per deficit di informazione, decidono una volta e non imparano mai dal risultato. La risposta è un ciclo continuo in cui un orchestratore leggero instrada la richiesta usando lo storico di prestazioni conservato in una memoria interna, e un verificatore valuta l’esito con metriche oggettive, i test unitari sul codice generato per esempio, riscrivendo il risultato nella memoria come esperienza. Il router accumula esperienza fondata sull’esecuzione reale, ed è la stessa architettura del ciclo notturno che descrivevo nel pezzo di luglio, formalizzata e messa alla prova contro modelli di frontiera.

Per chi lavora con l’inferenza dentro il perimetro aziendale, ed è il terreno su cui costruiamo LocalAI, questa famiglia di strumenti è quella che conta: il routing self-hosted è ciò che rende sostenibile l’ibrido, i modelli locali per la maggioranza del traffico, il cloud per ciò che lo giustifica davvero.

Funziona dove il risultato si può misurare

Tutte queste architetture, dalla cascata al ciclo di ACRouter, si reggono su un presupposto che i diagrammi non mostrano: che esista un segnale oggettivo per dire se una risposta è buona. Il codice passa i test o non li passa, il JSON rispetta lo schema o non lo rispetta, la stringa si estrae o no. Dove il segnale è binario, il validatore della cascata sa quando scalare, il verificatore sa cosa scrivere in memoria, e il router impara.

Dove il segnale non c’è, tutto l’impianto si affloscia. Valutare un testo di marketing, un brainstorming aperto, una sintesi il cui pregio è il taglio e non la correttezza: su questi compiti la verifica automatica è debole, e un model router che non sa distinguere una risposta buona da una mediocre instrada alla cieca, con in più il pedaggio di latenza che le catene a cascata e i cicli di validazione si portano dietro per costruzione. Il router aggiunge un premio di complessità allo stack, e non ripara la logica applicativa rotta o il prompting fatto male: sposta i compiti giusti sui modelli giusti, a condizione che qualcuno gli abbia insegnato a riconoscerli.

Il registro dei prompt vale più del modello

Resta la parte che riguarda chi decide, non chi implementa. Il panorama dei modelli cambia ogni settimana, i prezzi per token continuano a scendere, e qualunque scelta di modello fatta oggi sarà rivedibile tra un trimestre. Le due cose che invece restano, e si apprezzano nel tempo, sono i dataset di valutazione interni e lo storico dei prompt con i loro esiti. Sono il carburante di ogni model router appreso, di ogni cascata calibrata, di ogni memoria alla ACRouter, e nessun fornitore può venderteli perché descrivono il tuo lavoro, non il suo.

L’avevo scritto parlando del vantaggio che si accumula in memoria, e il routing ne è la dimostrazione infrastrutturale: un’organizzazione che non registra cosa ha chiesto ai modelli e come è andata non potrà mai instradare bene, con nessuno strumento, comprato o costruito. Il processo di valutazione viene prima del router, come il router viene prima del modello. E mentre l’AI bill shock spinge tutti a cercare la casella magica che abbatte il conto, i dati che servirebbero ad addestrare il vostro model router si stanno raccogliendo adesso, oppure non si stanno raccogliendo affatto. Chi li registra oggi, tra un anno instraderà sulla propria esperienza. Gli altri affitteranno quella di qualcun altro.

Riferimenti: OpenRouter, Surpassing Frontier Performance with Fusion; Zhou et al., Agent-as-a-Router: Agentic Model Routing for Coding Tasks (arXiv); NadirClaw su GitHub; Not Diamond.

13 Luglio 202610 Luglio 2026AI & 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.