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.

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

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

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

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

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

Ancorare il modello: dal plausibile al verificato

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

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

Dopo la qualità del dato viene la struttura

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

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

Governare il significato

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

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

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

Il primo AI Strategy Paper

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

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

👉 Scarica Govern Meaning su zerofive.ai/papers

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

Soft skill nell’era dell’AI: la riconfigurazione delle competenze che la scuola italiana ha iniziato

Il 7 maggio 2026 Assolombarda e nove università milanesi hanno firmato un accordo quadro triennale su lauree, master e hackathon dedicati all’intelligenza artificiale. Dentro i dati che accompagnano la firma c’è un numero che vale tutta la discussione sulla fine del lavoro: nel quadrilatero Milano-Monza-Lodi-Pavia i laureati STEM sono cresciuti del 25,6% dal 2014, ma solo il 2% del totale possiede competenze ICT effettive. Le imprese cercano, le università sfornano titoli, e in mezzo resta un vuoto di soft skill che nessuna laurea tecnica da sola sta riempiendo.

Tendiamo a leggere l’arrivo dell’AI nel lavoro come una sottrazione: quanti posti spariranno. È la domanda sbagliata, o almeno è quella che cattura meno di metà di ciò che sta succedendo. L’altra metà è una riconfigurazione di cosa rende prezioso un essere umano in un’organizzazione, e tocca proprio le soft skill che un’aula STEM tradizionale non insegna.

Le soft skill nel vuoto che le lauree tecniche non colmano

L’automazione cognitiva mangia per prima i compiti procedurali: inserimento dati, redazione di documenti standard, prima stesura di codice. Sono attività che fino a ieri richiedevano una persona e che oggi un modello svolge in pochi secondi. Su questo non c’è dibattito serio.

Cosa resta dall’altra parte, invece, è tutto ciò che richiede di leggere una situazione ambigua, di tenere insieme persone con interessi diversi, di decidere quando una risposta del modello va bene e quando va buttata. Empatia, negoziazione, capacità di persuasione, giudizio in condizioni di incertezza. Le chiamiamo soft skill con una certa condiscendenza, come se fossero un contorno. Stanno diventando il piatto principale.

Il paradosso italiano è proprio questo. Abbiamo prodotto più laureati tecnici e contemporaneamente un mismatch più ampio, perché il valore si è spostato verso una combinazione che la formazione iperspecialistica non garantisce: solidità tecnica più capacità relazionale e critica. Chi ha solo la prima è automatizzabile sui margini, chi ha solo la seconda non capisce abbastanza la tecnologia per governarla.

Filosofia e classici rientrano dalla porta principale

Qualcosa, in controtendenza rispetto a quanto si racconta, si sta muovendo. Le nuove Indicazioni Nazionali per i licei del 2026 introducono l’intelligenza artificiale e l’informatica nel curriculum, ma la scelta che trovo più interessante è un’altra: il rilancio della filosofia con un approccio specifico su etica e tecnologia, e un impulso esplicito al pensiero critico come competenza da allenare. Insieme a un ritorno ai classici e alla centralità del testo.

A prima vista sembra un movimento all’indietro, verso il sapere umanistico, proprio mentre tutti spingono sulle STEM. Letto bene è il contrario: è il riconoscimento che, in un mondo dove la parte tecnica diventa commodity erogata da una macchina, la differenza la fa la capacità di interpretare, argomentare, dubitare. Le arti liberali non come nostalgia, come infrastruttura cognitiva per stare davanti a un modello senza esserne sostituiti.

Lo stesso vale per l’alta formazione. Il Politecnico di Milano integra l’AI in tutti i corsi di laurea magistrale e propone certificati per professionisti. Insegno anch’io in due business school, e vedo da vicino come la domanda sia cambiata: i manager non chiedono più solo di capire la tecnologia, chiedono di capire come ridisegnare ruoli e competenze delle loro persone attorno alla tecnologia. È una domanda da educatori, non da tecnologi.

La capacità cognitiva che rischiamo di perdere

C’è un timore che attraversa tutto questo, e va preso sul serio invece di liquidarlo. Delegare al modello una quantità crescente di lavoro mentale potrebbe atrofizzare proprio le capacità che diciamo di voler coltivare. Uno studente che fa scrivere i temi all’AI non allena la scrittura. Un professionista che le delega ogni analisi smette di saper analizzare.

C’è uno strato sottile dove la mente e la macchina si toccano, ed è lì che si decide se l’una estende l’altra o la sostituisce. La scuola e l’università sono il luogo dove questa decisione pesa di più, perché lì le competenze non si esercitano, si formano per la prima volta. Un adulto che delega perde un allenamento. Un ragazzo che delega potrebbe non sviluppare mai la capacità.

La risposta non è vietare lo strumento, sarebbe ridicolo e perdente. È insegnare a usarlo in modo che amplifichi invece di sostituire. Far scrivere allo studente la sua ipotesi prima di chiederla al modello. Pretendere che sappia giudicare l’output, il che richiede di possedere la competenza, non di averla noleggiata. Tenere viva una quota di lavoro fatto senza aiuto, come si tiene allenato un muscolo che altrimenti si addormenta.

Utilizzatori o menti che tengono testa alla macchina

La transizione non porterà alla disoccupazione di massa che molti temono. Porterà a una ridistribuzione del valore verso competenze che oggi sottovalutiamo, e premierà chi sa stare nel mezzo: abbastanza tecnico da capire la macchina, abbastanza umano da fare ciò che la macchina non fa.

Il sistema educativo italiano ha davanti una finestra stretta per riconfigurarsi attorno a questa idea, e i segnali dicono che ha cominciato a guardarci. Resta la parte difficile, che non è scrivere nei programmi la parola intelligenza artificiale, è cambiare il modo in cui si insegna a pensare. È la riforma più importante e meno appariscente del momento. Tra qualche anno si vedrà la differenza, tra chi ha solo imparato a usare lo strumento e chi ha imparato a pensare senza di lui.


Spunti dall’Accordo Quadro Assolombarda-università 2026-2029 e dalle nuove Indicazioni Nazionali per i licei.

Lovable: la guida completa al builder AI che trasforma un prompt in un’app

A dicembre 2025 Lovable ha chiuso un round da 330 milioni di dollari a una valutazione di 6,6 miliardi. Diciotto mesi prima era l’app commerciale di un progetto open source che Anton Osika aveva chiamato GPT Engineer. In mezzo ci stanno otto milioni di utenti, più di centomila progetti creati ogni giorno, e oltre metà delle aziende Fortune 500 che la usano in qualche forma. La corsa è vera, e i numeri raccontano una corsa. A me interessa soprattutto il suo rovescio: oggi milioni di persone costruiscono software descrivendolo a parole, e quasi nessuna di loro saprebbe leggere il codice che ne esce.

Questa guida prova a dire cosa fa davvero Lovable, quanto costa, dove regge e dove si rompe, e quando vale la pena affidargli un progetto invece che a una persona. È la prima di tre, perché subito dopo arrivano Bolt e Replit, gli altri due nomi che chiunque incontri quando entra in questo territorio.

Da GPT Engineer a una valutazione da sei miliardi

Nel 2023, a Stoccolma, Osika rilascia GPT Engineer: software open source che usa un modello linguistico per scrivere intere applicazioni da una descrizione. Con Fabian Hedin ne fa una versione commerciale, la GPT Engineer App, e a dicembre 2024 la ribattezza Lovable aprendo l’accesso pubblico. Da lì la traiettoria diventa difficile da raccontare senza sembrare iperbolici.

A luglio 2025 il primo round serio, 200 milioni di Series A guidata da Accel, valutazione 1,8 miliardi. A novembre, sul palco di Slush a Helsinki, Osika annuncia 200 milioni di ricavi ricorrenti annui, il doppio rispetto a quattro mesi prima, quando l’azienda aveva passato i 100 milioni di ARR. Lui stesso lo descrive come la crescita più rapida nella storia del software, più veloce di OpenAI e di Cursor. A dicembre arriva la Series B da 330 milioni guidata da CapitalG e Menlo Ventures, con dentro anche Khosla, Salesforce Ventures e Databricks Ventures, a quei 6,6 miliardi che triplicano la valutazione in cinque mesi.

C’è un dettaglio che dice molto sul personaggio. Osika ha resistito alla pressione di trasferire l’azienda nella Silicon Valley, e attribuisce a quella scelta buona parte del risultato. Lovable resta svedese, con un organico piccolo rispetto ai ricavi, al punto che a marzo 2026 TechCrunch raccontava di 100 milioni di ricavi aggiunti in un solo mese con poco più di centoquaranta persone a libro paga. Tra i clienti compaiono Klarna, Uber, Zendesk. Non tutto è stato lineare: a novembre 2025 l’azienda è finita sotto accusa per non aver versato l’IVA dovuta in Svezia, un episodio che vale la pena tenere a mente quando si valuta la solidità di un fornitore così giovane e così veloce.

Per chi guida la tecnologia in azienda, il punto da registrare è semplice. Lovable ha smesso di essere un giocattolo per smanettoni ed è diventata a tutti gli effetti un fornitore enterprise, con tutto quello che questo comporta in termini di dipendenza, sicurezza e continuità.

Cosa succede quando descrivi l’app che vuoi

Scrivi cosa vuoi costruire, in linguaggio naturale, e Lovable genera un’applicazione full-stack completa. Il frontend esce in React con TypeScript e Tailwind CSS, il backend si appoggia a Supabase per database Postgres e autenticazione, e il tutto viene messo online su un URL pubblico con un clic. Da quel momento iteri conversando: chiedi una modifica, l’app cambia, ti accorgi di un errore, lo segnali, riprovi.

La parte che fa la differenza rispetto ai vecchi strumenti no-code è la portabilità del codice. Lovable mantiene una sincronizzazione bidirezionale con GitHub, quindi il progetto vive in un repository Git reale, e quel codice è tuo. Lo puoi esportare, estendere, far leggere a uno sviluppatore, oppure portarlo via del tutto. Non resti chiuso dentro un ecosistema visuale proprietario, che è esattamente la trappola in cui finivano le generazioni precedenti di costruttori senza codice.

Intorno al nucleo si sono accumulate funzioni che riducono i passaggi. La generazione di immagini è integrata nel builder, da marzo 2026 anche con sfondo trasparente, comoda per icone e illustrazioni di servizio senza uscire verso un altro strumento. C’è una modalità vocale per descrivere le modifiche parlando. E a marzo 2026 Lovable ha allargato il perimetro oltre le app, verso analisi dati, business intelligence, presentazioni e flussi di marketing, segno di un’ambizione che va ben oltre il prototipo.

Quello che cambia, sotto la superficie del prodotto, è chi può costruire. Quando l’interfaccia tra un’intenzione e un software diventa una frase scritta o detta, la barriera tecnica si abbassa di colpo e si sposta altrove. In Pelle Digitale ho provato a descrivere proprio questo, la mediazione tra la mente e gli strumenti che la estendono, e Lovable è uno degli esempi più nitidi di quella mediazione spostata sul linguaggio.

Come si pilota la generazione

Non c’è un solo modo di lavorare a un progetto, ce ne sono diversi, ognuno adatto a un momento. Agent Mode è la modalità autonoma: l’AI esplora il codice da sola, individua e corregge errori in modo proattivo, cerca informazioni sul web e ragiona su più passaggi prima di agire. Plan Mode, che prima si chiamava Chat Mode, è il suo opposto controllato: ragiona, pianifica, risponde a domande e aiuta a fare debug, ma non tocca il codice, ed è il posto giusto dove pensare un progetto prima di lasciarlo costruire.

Poi c’è la mano diretta. Visual Edits permette di cliccare su un elemento dell’interfaccia e cambiarne lo stile senza scrivere un prompt, utile a chi pensa per immagini più che per istruzioni. Dev Mode apre il codice e lo lascia modificare dentro Lovable, per i tecnici che vogliono mettere le mani dove l’AI non arriva. Le modifiche di solo testo e contenuto non consumano crediti, dettaglio che conta più di quanto sembri quando si guarda il conto a fine mese.

Quasi tutto questo è arrivato con Lovable 2.0, la versione che nella primavera del 2025 ha introdotto il lavoro in multiplayer, con workspace condivisi e fino a venti collaboratori, la scansione di sicurezza nel momento della pubblicazione, e la modalità di editing del codice. Da allora il prodotto ha continuato a crescere, ma è quella la base su cui si regge oggi l’esperienza d’uso.

Quanto costa, e quanto costa davvero

Il piano gratuito esiste e si usa, senza carta di credito. Dà cinque crediti al giorno con un tetto mensile intorno ai trenta, progetti pubblici ospitati su dominio lovable.app, branding di Lovable in vista, e nessuna possibilità di acquistare crediti extra o di aprire il codice. Basta per validare un’idea, non per costruirci sopra sul serio.

Il piano Pro parte da 25 dollari al mese, circa 21 con fatturazione annuale, e porta cento crediti mensili, progetti privati, dominio personalizzato, rimozione del branding, accesso al codice e crediti che si accumulano da un mese all’altro se non li usi. Il piano Business sale a 50 dollari al mese e aggiunge quello che serve a un team: SSO, controlli di accesso, fatturazione centralizzata, limiti di credito per singolo utente. Il piano Enterprise va a preventivo e mette sul tavolo SCIM, log di audit, attestazione SOC 2 e supporto dedicato.

Il meccanismo a crediti è semplice nella forma. Ogni interazione con l’AI ne consuma, le operazioni più complesse e quelle in Agent Mode ne consumano di più, le modifiche manuali non ne consumano affatto. Il problema arriva quando si traduce in conto reale. Chi ha spedito davvero un’applicazione lo racconta sempre allo stesso modo: i crediti bruciano più in fretta di quanto il piano lasci immaginare, e la spesa effettiva tende a essere due o tre volte quella nominale. A questo si aggiunge il backend, perché Supabase ha i suoi costi oltre il piano gratuito, a partire da circa 25 dollari al mese quando l’app supera i limiti di database, autenticazione o storage, e si aggiunge il dominio. Un piano da venti diventa facilmente un conto da sessanta o ottanta.

Rispetto a strumenti che chiedono una quota fissa mensile senza contatore a prompt, come Cursor, v0 o Windsurf, il modello a crediti di Lovable è più generoso sul lavoro semplice e meno prevedibile su quello complesso, soprattutto quando il debug si allunga. Nella comunità è emerso un flusso di lavoro che dice molto: si costruisce il settanta o ottanta per cento del progetto in Lovable, dove prototipare è rapido ed economico, poi si esporta su GitHub e si finisce in Cursor. I prezzi cambiano spesso, quindi la pagina ufficiale resta l’unica fonte da verificare prima di decidere, e la trovi su lovable.dev/pricing.

La Row Level Security e i dati usciti da Lovable

A maggio 2025 il ricercatore Matt Palmer documenta una vulnerabilità che diventa CVE-2025-48757. Oltre 170 applicazioni costruite con Lovable avevano il database completamente esposto, senza Row Level Security attiva. I dati raggiungibili comprendevano email e indirizzi di casa, informazioni finanziarie, chiavi API e storici di pagamento. Una sola di quelle app esponeva i dati di tredicimila utenti. Per leggerli non servivano credenziali: bastava la chiave pubblica che sta nel codice del frontend.

La radice tecnica merita di essere capita, perché spiega un’intera categoria di problemi. Supabase espone tutte le tabelle tramite API per impostazione predefinita. La chiave anonima è pubblica, vive nel bundle JavaScript che ogni visitatore può ispezionare. L’unica cosa che impedisce a chiunque di leggere e scrivere il database sono le policy di Row Level Security, e se quelle policy non vengono attivate e configurate a mano, il database è di fatto un’API pubblica aperta a tutti. Il problema non è il codice che Lovable scrive, è quello che non scrive: i controlli di sicurezza che nessuno ha pensato a chiedergli. Un ricercatore l’ha sintetizzato così: l’AI fa quello che le chiedi, non pensa mai a quello che non le hai chiesto.

Non è un caso isolato e non riguarda solo Lovable. Scansioni indipendenti su oltre mille applicazioni costruite con strumenti di vibe coding e appoggiate a Supabase hanno trovato problemi di sicurezza in circa il 98 per cento dei casi, con il 16 per cento di falle critiche, e i campioni includevano anche v0, Bolt e Replit. È un problema di categoria, legato all’architettura client più al modello generativo che a un singolo prodotto. Va detta però anche la parte scomoda per Lovable: secondo un audit successivo, l’autorizzazione interna della stessa piattaforma è rimasta esposta per settimane dopo la segnalazione, il che indebolisce l’argomento secondo cui la responsabilità sarebbe tutta di chi configura male l’app.

Lovable ha risposto con un Security Scan integrato nel momento della pubblicazione per le app collegate a Supabase, e con un Security center che controlla chiavi API esposte, policy RLS, dipendenze datate. È un passo avanti che resta acerbo. Per chi porta la responsabilità della sicurezza in azienda, le regole pratiche sono poche e nette. Niente segreti di produzione dentro gli strumenti di coding AI, che vanno trattati come ambienti non fidati. RLS attiva su ogni progetto, verificata a mano e non chiedendo conferma all’AI che l’ha generata. E una valutazione del rischio fornitore identica a quella che si farebbe per qualunque altro responsabile del trattamento dei dati, con le implicazioni che questo porta su SOC 2 e ISO 27001. Se è il tipo di governance che serve impostare, è esattamente la conversazione che faccio con le aziende prima che un prototipo scivoli silenziosamente in produzione.

Dove si colloca rispetto a Bolt e Replit

Nessuno di questi strumenti è uguale agli altri, e la scelta dipende da chi sei e da cosa devi spedire. Lovable offre l’esperienza più completa appena aperta la scatola, con backend, editing visivo e modalità agente già pronti, ed è la più amica dei designer e di chi non scrive codice. Bolt, costruito sopra StackBlitz, dà più flessibilità tecnica, supporta più framework, lascia editare il codice in modo diretto e gira interamente nel browser, e tende a piacere di più agli sviluppatori. Replit, con il suo Agent, è un ambiente di sviluppo completo che arriva fino alle app mobili native via React Native, quindi quando serve il mobile vero è la risposta più solida. v0 di Vercel genera componenti di interfaccia eccellenti e pubblica in fretta, ma parla a chi conosce già React. Base44 toglie ogni decisione di configurazione ed è la via più rapida per un fondatore senza competenze tecniche.

Su questa mappa entro nel dettaglio nelle prossime due guide del blog, dedicate a Bolt e a Replit, che raccolgo insieme a questa nella sezione AI e GenAI. Qui basta la posizione: Lovable è il punto di riferimento per le app web full-stack con un flusso amichevole, e il confronto si gioca sul resto.

Il primo progetto

Si parte dal piano gratuito, senza carta. La descrizione iniziale conta più di tutto il resto, quindi vale la pena essere precisi su cosa fa l’app, chi la usa e quali sono le schermate principali, invece di affidarsi a una frase generica. Prima di lasciar costruire conviene passare da Plan Mode per ragionare sull’impianto, poi attivare Agent Mode per la generazione vera. Quando servono dati e login si collega Supabase, e a quel punto la regola è una sola: lanciare il Security Scan prima di pubblicare e verificare a mano che la Row Level Security sia attiva, senza fidarsi della conferma dell’AI. Infine si sincronizza il progetto con GitHub, così il codice resta portabile, e si collega un dominio personalizzato. La spesa la si lascia crescere quando si toccano i limiti, non prima.

Dove regge, dove rallenta

Lovable è straordinario per comprimere la distanza tra un’idea e qualcosa di vivo. MVP, prototipi di SaaS, landing page, strumenti interni, portali cliente e dashboard, demo da mettere in mano a qualcuno la settimana stessa: su tutto questo regge benissimo, e mette un fondatore non tecnico o un product manager nella condizione di spedire un prodotto reale senza un team di sviluppo. Dove rallenta è prevedibile. La logica custom complessa richiede più giri, i casi limite vanno chiariti uno per uno, e qualunque applicazione che maneggi dati sensibili o regolati non dovrebbe vedere la luce senza una revisione di sicurezza fatta da chi sa leggere il codice.

Questi strumenti generano un buon punto di partenza, non un sistema finito. Una produzione vera ha ancora bisogno di revisione del codice, di un’architettura pensata, di test e di manutenzione nel tempo, e nessuno di questi passaggi sparisce perché l’app è nata da un prompt. Per chi guida la tecnologia, Lovable è due cose insieme: un modo legittimo per accorciare il ciclo dall’idea al prototipo, e una responsabilità di governance nel momento in cui qualcuno prova a spingere quel prototipo in produzione senza che nessuno lo abbia controllato. Il mestiere di chi sa leggere il codice non scompare, si sposta verso la revisione, la sicurezza, i casi che l’AI non vede.

Senza dubbio questi strumenti diventeranno più sicuri e più capaci. La domanda che resta aperta è un’altra: quando descrivere un’applicazione diventa facile come dirla a parole, chi si prende la responsabilità di quello che quell’applicazione fa nel momento in cui nessuno la sta guardando?


Trasparenza: i link a Lovable nel corpo di questa pagina sono referral. Le valutazioni del pezzo, inclusa la parte sulla sicurezza, restano quelle che avrei scritto senza. I link qui sotto sono diretti.

Riferimenti.

Ufficiali: sito Lovable, documentazione, annuncio Lovable 2.0, piani e prezzi, FAQ sicurezza.

Azienda e finanziamenti: scheda Wikipedia; TechCrunch sulla Series B da 330 milioni a 6,6 miliardi e sui 200 milioni di ARR con la scelta di restare in Europa.

Analisi e recensioni indipendenti: UI Bakery, No Code MBA sui prezzi.

Sicurezza: Superblocks sulla CVE-2025-48757, studio Security Boulevard sulle vulnerabilità nelle app vibe coded.

L’Europa e l’AI di frontiera che non controlla

Il 7 luglio la Commissione europea ha presentato un Action Plan su cybersicurezza e intelligenza artificiale. A firmarlo è Henna Virkkunen, che nella nuova Commissione porta una delega dal nome esplicito, sovranità tecnologica, sicurezza e democrazia, e che ha messo in fila un ragionamento semplice, l’AI sta cambiando il significato stesso della sicurezza informatica e l’Europa deve tenere il passo alle vulnerabilità che le nuove tecnologie si portano dietro. Nelle settimane precedenti, a Bruxelles, si leggeva un fatto molto preciso: un modello di frontiera, il Mythos di Anthropic, aveva mostrato di saper individuare vulnerabilità nascoste nel software, e un governo straniero aveva deciso di limitarne l’accesso a chi non è cittadino americano.

Per anni l’Europa ha scritto regole per un’intelligenza artificiale che non costruisce. Questo piano è il primo documento che lo dice ad alta voce, con parole sue: le capacità di frontiera nascono per lo più fuori dai confini dell’Unione, e la loro disponibilità dipende da processi decisi altrove, spesso poco trasparenti. La cybersicurezza, letta così, non è un problema di adempimento, è un problema di sovranità digitale.

Una capacità di valutazione da costruire

La prima mossa concreta è una capacità europea di valutazione dei modelli, che la Commissione vuole creare nel 2027. Servirà a esaminare i modelli di frontiera prima che arrivino sul mercato, anche dal lato della sicurezza informatica, a sostegno del lavoro dell’AI Office, con criteri pubblici per i valutatori indipendenti che vorranno candidarsi.

Sotto l’annuncio c’è un’ammissione. Oggi l’Europa non riesce a valutare da sola i modelli che pretende di regolare. L’AI Act le ha dato il diritto di chiedere che quei modelli vengano esaminati, questo piano riconosce che le manca il muscolo per farlo in proprio.

Il primo pezzo di quel muscolo arriva prima. ENISA, l’agenzia dell’Unione per la cybersicurezza, e il Centro comune di ricerca costruiranno entro fine 2026 una piattaforma europea sicura per mettere alla prova i modelli in ambienti simulati, portando competenza sull’uso sicuro dell’AI agli operatori dei settori critici, dalla finanza alla sanità, dall’energia ai trasporti fino alla pubblica amministrazione.

Quando a decidere l’accesso è un altro

Qui il piano tocca il nervo scoperto. Le capacità di frontiera, scrive la Commissione, si sviluppano quasi tutte fuori dall’Unione, e chi le vuole usare dipende da processi decisi altrove. Conoscerle e potervi accedere non riguarda soltanto la resilienza informatica, riguarda la sovranità tecnologica di un continente.

L’episodio Mythos serve da promemoria. Un modello capace di trovare falle nascoste diventa un’arma se finisce nelle mani sbagliate, uno strumento di difesa se resta in quelle giuste, però la mano che decide chi può usarlo, in quel caso, stava a Washington e non a Bruxelles. È l’idea del permesso revocabile portata su scala geopolitica: quando il permesso di usare una capacità può essere ritirato da qualcun altro, dall’esterno, la tua sovranità sui processi che quella capacità protegge è presa in prestito.

Somiglia alla competenza presa in prestito di cui scrivevo a proposito del nostro rapporto quotidiano con questi modelli, solo che qui il prestito non tocca una singola persona che smette di saper fare una cosa, tocca la capacità di un’intera economia di difendere le proprie infrastrutture.

Dal codice condiviso alla vulnerabilità che resta scoperta

Il secondo pilastro guarda dentro le organizzazioni. Il piano non chiede di aspettare, chiede di usare da subito le capacità di AI già disponibili, compresi i modelli aperti, per trovare e correggere le vulnerabilità più in fretta di prima, e per reagire quando un attacco è già in corso. Da qui a fine 2026 ENISA pubblicherà linee guida e buone pratiche, e aprirà un progetto pilota sulla resilienza del software libero critico, pensato per accelerare la correzione delle falle con l’aiuto dell’AI.

Il codice aperto, in questo disegno, pesa più di una bandiera ideologica. Resta la sola capacità che un’organizzazione può ispezionare riga per riga e far girare sulle proprie macchine, senza chiedere permesso a nessuno e senza che nessuno la spenga da lontano. La stessa falla che un modello di frontiera straniero potrebbe scovare al posto tuo, oggi, un modello aperto che controlli tu può aiutarti a chiuderla domani.

La difesa prima della norma

C’è un contrasto che vale la pena guardare in faccia. Nelle stesse settimane in cui prepara questo piano, l’Europa rallenta il suo stesso codice: il 29 giugno il Consiglio ha dato il via libera definitivo alla semplificazione dell’AI Act, che sposta in avanti gli obblighi sui sistemi ad alto rischio, al dicembre 2027 per quelli autonomi e all’agosto 2028 per quelli dentro i prodotti.

Frenare la regola e costruire la difesa, allo stesso tempo, sembra una contraddizione e invece è una sola mossa. Il baricentro si sposta da ciò che vietiamo prima a ciò che sappiamo fare adesso, dalla conformità alla capacità. È l’ansia da competitività dei rapporti Draghi e Letta tradotta in atti di governo, e cambia il modo in cui un CIO dovrebbe leggere la politica europea sull’AI.

La lettura solo per adempimento non basta più. Ciò che pesa davvero, sui tavoli dove si decide, è lo stesso metro che vale con gli agenti: la reversibilità, cioè il controllo su runtime, contesto e permessi e la rapidità con cui puoi fermare un processo e riportarlo indietro senza danni.

Sovranità digitale, da iniziare adesso

Il piano, in filigrana, detta anche cosa fare senza aspettare né l’agenzia del 2027 né la sfida europea di fine anno. C’è l’igiene di base da rafforzare e la sicurezza da mettere fin dentro la progettazione, come le regole sulla cybersicurezza già chiedono. Conviene poi iniziare a usare i modelli disponibili, anche quelli aperti, per scovare e chiudere le vulnerabilità e per rispondere quando un attacco è già partito. Merita attenzione, da qui a fine anno, la piattaforma di ENISA per la sperimentazione dei modelli, con le linee guida che arriveranno tra il terzo e il quarto trimestre.

E la dipendenza da un singolo modello di frontiera controllato da un altro Stato va trattata per quello che è, un’esposizione nella catena di fornitura che una decisione presa altrove può accendere o spegnere da un giorno all’altro.

L’occasione, per chi in Europa costruisce sicurezza e AI nello stesso posto, prende una forma concreta. Bruxelles lancerà entro fine 2026 una sfida europea per le soluzioni di cybersicurezza basate sull’AI, e sta studiando con la Banca europea per gli investimenti uno strumento pubblico che finanzi i progetti strategici, la frontiera dell’AI compresa. Attorno a una capacità sovrana, che si possa ispezionare e valutare in casa, si sta formando un mercato.

Il piano costruisce la capacità di valutare i modelli e gli strumenti per difendere le reti, e sono due cose che all’Europa mancano da tempo. Resta però, sui tavoli dove lavoro, una domanda a cui non ho ancora una risposta netta: si può davvero essere sovrani su una capacità che non hai costruito e che non riesci a vedere fino in fondo? Finché la risposta non è chiara, la sovranità digitale somiglia più a un cantiere aperto che a un traguardo raggiunto.


Il documento è l’Action Plan on Cybersecurity and Artificial Intelligence presentato dalla Commissione europea il 7 luglio 2026, con il comunicato integrale della Commissione. La struttura in tre pilastri e le scadenze operative sono ricostruite dal servizio di Agence Europe. Il via libera definitivo alla semplificazione dell’AI Act è del Consiglio dell’UE, 29 giugno 2026.

Metacognizione e AI: usare il modello senza perdere la testa

C’è un gesto che faccio decine di volte al giorno senza pensarci. Apro una chat, scrivo una richiesta, ricevo una risposta buona, la uso. Funziona così bene che ho smesso di chiedermi una cosa: dopo, quella competenza è mia o l’ho solo presa in prestito? La domanda sembra astratta finché non provi a rifare da solo qualcosa che la settimana prima avevi delegato al modello, e ti accorgi che la mano non sa più muoversi.

Questa è la differenza tra l’AI come amplificatore e l’AI come protesi. Un amplificatore prende una mia capacità e la rende più potente. Una protesi sostituisce una capacità che, col tempo, si atrofizza per disuso. Lo stesso strumento può essere l’uno o l’altra. Dipende da come lo uso, e quasi nessuno si ferma a controllarlo. Qui entra in gioco la metacognizione.

La competenza che non sapevo di perdere

Il termine tecnico per questo controllo è metacognizione: pensare a come si pensa, osservare il proprio modo di apprendere mentre accade. È una vecchia idea della psicologia cognitiva, e l’AI la rende improvvisamente urgente.

Quando delego al modello la stesura di un testo, sto risparmiando tempo. Indubbio. Ma sto anche saltando il processo che, ogni volta che lo facevo a mano, manteneva allenata una capacità. Non si tratta di rinunciare allo strumento, sarebbe assurdo. Si tratta di accorgersi di quando lo sto usando per amplificare e quando per evitare, perché solo nel primo caso esco dall’interazione più capace di prima.

In Pelle Digitale avevo provato a descrivere questo strato sottile dove la mente e la macchina si toccano. La metacognizione è il sensore che mi dice da che parte di quello strato sto stando: se la macchina sta estendendo me, o se io mi sto ritirando dentro la macchina.

Prompt ipotesi, check di ritenzione, rotazione

Non servono teorie, servono abitudini. Tre, semplici, che ho integrato nel mio modo di lavorare con il modello.

La prima la chiamo prompt ipotesi. Prima di chiedere al modello come si risolve un problema, scrivo la mia ipotesi di soluzione. Anche sbagliata, anche grezza. Poi confronto. Questo piccolo attrito fa una differenza enorme: invece di ricevere passivamente una risposta, la leggo come correzione di un mio ragionamento, e il ragionamento resta mio.

La seconda è il check di ritenzione. A distanza di qualche giorno da un compito che ho svolto con l’AI, provo a rifarne un pezzo senza aiuto. Se non ci riesco, ho una misura precisa di quanto quella competenza fosse prestata. Non è un esame, è un termometro. Mi dice dove sto accumulando debito cognitivo, quel saldo nascosto che si paga quando lo strumento un giorno non c’è.

La terza è la rotazione del prompt. Quando un modo di chiedere funziona, tendo a ripeterlo all’infinito. Comodo, e lentamente accecante: smetto di esplorare. Ogni tanto cambio deliberatamente l’approccio, chiedo la stessa cosa in un modo che non userei mai, per vedere cosa emerge e per non lasciare che lo strumento mi addestri a pensare in un solo modo.

Quello che vale per una persona vale per un’azienda

La metacognizione non è solo un fatto individuale. Un’organizzazione che adotta l’AI senza farsi queste domande accumula lo stesso debito, moltiplicato per il numero di persone.

Succede così. Un reparto comincia a delegare al modello una serie di compiti. La produttività sale, i numeri sono buoni, nessuno si lamenta. Poi, mesi dopo, qualcuno si accorge che la competenza interna su quei compiti è evaporata. Non c’è più nessuno in grado di valutare se l’output del modello sia giusto, perché tutti hanno smesso di farlo a mano. L’azienda è diventata dipendente da uno strumento che non sa più giudicare.

L’antidoto è lo stesso, scalato. Tenere viva una quota di lavoro fatto senza AI, non per nostalgia, ma per mantenere la capacità di giudizio. Ruotare le persone tra compiti assistiti e compiti autonomi. Misurare la ritenzione delle competenze come si misura qualsiasi altro asset, perché lo è. È una delle conversazioni che porto più spesso al tavolo di CEO e CTO: la produttività di oggi non deve comprarsi la dipendenza di domani.

La crescita o la dipendenza

La parte che mi interessa di più non è tecnica. Riguarda che tipo di persone e che tipo di organizzazioni diventiamo usando questi strumenti.

C’è una via in cui l’AI ci rende più capaci, più curiosi, liberati dal lavoro meccanico e spinti verso quello che richiede giudizio. E c’è una via in cui ci rende più comodi e progressivamente più vuoti, con le risposte sempre pronte e la capacità di trovarle in lento declino. Lo strumento è identico. A separare le due vie c’è solo l’attenzione che mettiamo nel modo in cui lo usiamo.

La metacognizione è quella attenzione, resa abitudine. Costa un piccolo attrito ogni giorno, e in cambio mantiene aperta la possibilità che l’AI sia una crescita e non un noleggio permanente di facoltà che un tempo erano nostre. Senza dubbio è l’investimento più sottovalutato del momento. Chi la coltiva arriverà al giorno in cui lo strumento cambia, o si ferma, con la mano ancora capace di muoversi da sola, e sarà quella la differenza tra chi guida i prossimi anni e chi li subisce.

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

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

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

Ogni istruzione ha un costo e un’autorità

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

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

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

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

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

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

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

Le regole si caricano solo dove servono

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

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

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

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

Le skill portano dentro la procedura al momento giusto

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

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

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

Un agente separato per il lavoro che non vuoi leggere

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

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

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

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

Gli hook girano fuori dal contesto

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

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

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

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

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

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

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

Quando l’istruzione è nel posto sbagliato

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

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

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

Un’istruzione non è una garanzia

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

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

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

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


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

Pelle digitale e intelligenza artificiale

Venerdì sera, nella Parrocchia dei Santi Martiri Portuensi, d’estate i ragazzi dell’oratorio organizzano il Santo Bevitore, un momento di comunità per stare insieme e condividere esperienze. Questo venerdì è toccato a me. Quando hanno sospeso per un po’ la distribuzione di cibo e bevande per ascoltare, Don Michele mi ha introdotto per parlare del mio ultimo libro, Pelle digitale. Sul tavolo c’erano due testi usciti a pochi mesi di distanza, il mio e la prima enciclica di Papa Leone, Magnifica Humanitas, e per una sera abbiamo provato a leggerli insieme. Mi ha intervistato lui, con la pazienza di chi si era preparato davvero, e la cornice l’ha messa subito, una parola, consapevolezza, e una scelta, governare l’intelligenza artificiale o esserne governati.

È partito dal titolo, con una domanda semplice, dov’è questa pelle digitale e come ci avvolge. Gli ho risposto raccontando una sensazione che mi porto dietro da qualche anno. La tecnologia si è rimpicciolita, ha lasciato la scrivania, è finita in tasca, poi si è sparsa tutto intorno a noi, nei sensori e nelle piattaforme che si parlano fra loro anche quando noi non ce ne accorgiamo.

Non siamo più di fronte alla tecnologia: siamo dentro la tecnologia.

È questo che chiamo pelle digitale. Quando qualcosa sfiora la pelle lo sentiamo, e oggi quel qualcosa è un ecosistema che ci legge e ci anticipa, in una simbiosi costante e spesso inconsapevole.

L’intelligenza artificiale non è neutrale

Don Michele ha messo il dito sul punto vero subito dopo, questa tecnologia non è neutrale, e mi ha chiesto cosa significhi. Parto da un principio scomodo, nessun addestramento è neutrale, mai, perché porta l’angolazione di chi lo ha fatto, i suoi valori, le sue priorità, i suoi limiti. Vale per i grandi modelli e vale per i piccoli assistenti che ognuno di noi comincia ad allenare su di sé.

Se lo addestrate sui vostri pregiudizi, ragionerà a dieci volte la vostra velocità, amplificando le vostre boiate.

C’è poi un meccanismo più sottile, l’assecondamento costante.

Qualsiasi cosa diciate, una sciocchezza o un’idea brillante, vi risponde sempre: fantastico.

E quando qualcuno ci dà sempre ragione, a un certo punto smettiamo di metterlo in discussione, e ci convinciamo di parlare con il nostro migliore amico. Su questo il libro e l’enciclica si sono incontrati, ed è la convergenza che mi ha colpito di più. Magnifica Humanitas scrive che la tecnologia «assume il volto di chi la pensa, la finanzia, la regola, la usa». La domanda vera, allora, è capire a immagine di chi la stiamo costruendo.

Lo stesso vale per le informazioni. Gli algoritmi ci mostrano sempre di più ciò che già ci piace, e il nostro mondo si stringe in una bolla che scambiamo per il mondo intero. Il rimedio è banale e faticoso, usare più fonti e restare curiosi.

Meglio tante bolle che una sola bollicina.

Il pericolo che non fa rumore

A quel punto mi ha incalzato, se questo ecosistema è così invadente e così nascosto non mette in pericolo la nostra libertà. Gli ho dato la risposta che mi porto dietro da tempo, e che fa sempre discutere.

L’intelligenza artificiale è più potente della bomba atomica, ma è più subdola, perché non fa il botto, e quando capiremo che è pericolosa sarà già troppo tardi.

La bomba, quando è esplosa, ha comunicato da sola la sua potenza, il fungo e l’orrore. Questa trasformazione non esplode, entra in punta di piedi, ci abitua giorno dopo giorno, e l’assuefazione è il vero rischio. Per questo insisto sulla consapevolezza fin da subito, da tecnico entusiasta, ma con gli occhi aperti.

Più connessi o più soli?

La domanda che gli stava più a cuore riguardava le relazioni, e l’ha detta con le mie parole, tu scrivi che non siamo mai stati così connessi e così isolati.

Non siamo mai stati così connessi e così isolati.

Le macchine conversazionali imparano il nostro modo di parlare e ce lo restituiscono, ci fanno da specchio e ci gratificano, rispondono a ogni ora del giorno e della notte, quando siamo arrabbiati e quando siamo entusiasti. Una ricerca del MIT Media Lab e di OpenAI ha mostrato che chi le usa di più tende a sentirsi più solo e più dipendente, non meno.

Ci stiamo allontanando dalle persone avvicinandoci a una macchina. È matematica, non è empatia.

Non va demonizzato tutto, ci sono persone sole che grazie a questi strumenti hanno trovato legami che da sole non avrebbero costruito. Il livello di attenzione, però, va alzato, perché tutto questo accade in silenzio e ce ne accorgiamo tardi.

Chi è lo schiavo di chi?

Sul lavoro mi ha lanciato la sfida che si aspetta sempre, avremo più disoccupati o lavori nuovi. Ho detto tre cose, una scomoda e due meno. Quella scomoda, alcuni mestieri costruiti sulla pura ripetizione si trasformeranno, è già successo nella storia, dalla ruota in poi. Ma un lavoro è una sequenza di gesti, alcuni ripetitivi e senza valore, altri profondamente nostri, fatti di giudizio, creatività, conoscenza di un contesto. Se imparo a separarli, la macchina mi alleggerisce dai primi e mi lascia i secondi. Se invece le delego tutto, mi sto disabilitando da solo.

Se una macchina mi sintetizza una mail e io la copio e incollo da un’altra parte, chi è lo schiavo di chi?

C’è anche una trappola più sottile, quella degli strumenti gratuiti. La vecchia frase del marketing resta vera.

Se il prodotto è gratuito, il prodotto sei tu.

Con i sistemi gratuiti paghiamo spesso con i nostri dati e con un pezzo del nostro giudizio. Don Michele, su questo, mi ha fatto da sponda, perché il lavoro non è solo produrre.

Se l’uomo perde il senso del lavoro, che cos’è l’uomo senza il lavoro?

Il silenzio come competenza

Ha voluto chiudere sul tema a cui tengo di più, ed è anche il più spirituale, il valore del silenzio. L’intelligenza artificiale promette di liberarci tempo, e in parte è vero, però quel tempo rischiamo di riempirlo subito, verificando la macchina o chiedendole altro, e a fine giornata ci sentiamo svuotati come dopo una maratona.

La disconnessione, nel futuro prossimo, sarà un lusso.

Il silenzio non è un vuoto da riempire in fretta, è uno spazio da abitare, ed è lì che torniamo a pensare in profondità. Saper staccare è diventato una competenza, quasi una forma di libertà.

Don Michele ha chiuso meglio di come avrei saputo fare io, svegliarsi dal sonno è il primo passo per restare liberi, per governare la trasformazione invece di subirla. La consapevolezza è la prima libertà, e una comunità come quella che ci ospitava è il posto dove quella libertà diventa concreta, perché da soli ci si abitua, e insieme ci si sveglia.

Resta una domanda che mi sono portato a casa da quella sera, la pelle digitale ormai ce l’abbiamo addosso, e la vera questione è se sapremo restarci dentro da persone, e non da semplici utenti.


Dopo la serata, Don Michele mi ha scritto. C’erano domande che non c’era stato il tempo di affrontare, e che gli stavano a cuore. Le riprendo qui, con lo stesso spirito del confronto in parrocchia, perché meritano una risposta.

Centauri cognitivi: ma chi comanda?

La prima riguarda il dubbio che attraversa tutto il libro, l’intelligenza artificiale ci potenzia o ci indebolisce. La mia risposta è che dipende da chi tiene le redini. Insieme, uomo e macchina, siamo un centauro, e un centauro batte sia il miglior cavallo sia il miglior cavaliere presi da soli. La macchina mette il calcolo e una memoria sterminata, io metto il giudizio e la responsabilità di dove andare.

Il centauro vince, ma solo se a tenere le redini resta l’uomo.

Il guaio arriva quando smetto di tenerle. Delegare un calcolo è efficienza, delegare una decisione apre la porta alla deresponsabilizzazione, e più delego più si atrofizzano proprio le facoltà che credevo di potenziare, il pensiero critico, la memoria, la creatività. La tentazione del facile e del veloce ci illude di essere più bravi mentre ci rende più pigri.

Stiamo scambiando la velocità per saggezza.

Il centauro resta la strada giusta, a una sola condizione, che a guidarlo sia sempre l’uomo.

La scatola nera che nessuno sa aprire

La seconda domanda è quella che fa più paura, il mondo sarà governato dalle macchine. Parto da un fatto tecnico che pochi conoscono, i modelli più potenti sono scatole nere, e nemmeno chi li programma sa spiegare con precisione come arrivino a una certa risposta. Non sto facendo fantascienza, è la condizione di oggi.

Una macchina che nessuno sa spiegare non può avere l’ultima parola su di noi.

L’enciclica di Papa Leone usa un’immagine che mi ha colpito, l’intelligenza artificiale è «più coltivata che progettata». La cresciamo più di quanto la disegniamo, e cresce in fretta. A questo si aggiunge un limite di fondo, la macchina calcola benissimo ma non possiede una coscienza morale, non sa cosa significhi rispondere di una scelta davanti a qualcuno.

Un algoritmo può decidere, ma non sa cosa voglia dire risponderne.

Il mondo resta nelle nostre mani, con le macchine accanto, a patto di pretendere che restino trasparenti e interrogabili. La trasparenza conta proprio qui, è la condizione perché un potere così grande non diventi un oracolo a cui obbedire al buio.

Il nuovo petrolio sei tu

C’era poi una domanda sulla privacy, come la tuteliamo davvero. Parto dal meccanismo, perché aiuta a capire. I dati che lasciamo ogni giorno, dove andiamo, cosa cerchiamo, a che ora ci addormentiamo, sono la materia prima di questa economia, il petrolio del nostro tempo, e il pozzo è la nostra vita quotidiana. Gli occhi e le orecchie digitali sono ovunque, in un assistente vocale che ascolta in salotto, in un telefono che sa sempre dove siamo.

Difendere la privacy non significa nascondersi, significa custodire il confine tra te e chi vuole prevederti.

Qui torna il nodo della libertà. La piattaforma sa di me molto più di quanto io sappia di lei, ed è un’asimmetria di potere enorme. Più mi conosce, più può anticiparmi, e oltre una certa soglia l’anticipazione smette di essere un servizio comodo e diventa un modo gentile di indirizzarmi.

Quando un sistema ti conosce così bene, prevedere e indirizzare diventano la stessa cosa.

La difesa non sta nel diventare eremiti, sta nel tornare a fare domande semplici prima di dire sì, quali dati sto dando, a chi, in cambio di cosa. Pretendere di poterli ridurre, di tenerli sul dispositivo invece che chissà dove, di spegnere quello che non serve. Una privacy difesa è la linea che separa una persona da un profilo, e conviene tenerla prima di averla persa.

Come restare umani?

L’ultima domanda è anche la più importante, come restare umani. La risposta nasce da una distinzione semplice. Lo specifico della macchina è il calcolo, e lì non la batteremo mai. Lo specifico nostro è un altro, ed è esattamente ciò che la macchina non sa fare.

Alla macchina il calcolo, a noi il senso.

Restare umani significa allora coltivare ciò che ci rende insostituibili, la creatività, l’empatia, il pensiero critico, la coscienza morale. È il vero lavoro dei prossimi anni, altro che ripiego nostalgico, perché più le macchine diventano brave a calcolare, più diventa prezioso tutto ciò che il calcolo non tocca.

Più la macchina calcola, più vale ciò che lei non sa sentire.

Si resta umani esercitando l’umano, e lo si esercita meglio insieme, in una comunità, che è poi la cosa che Don Michele ci ha ricordato dall’inizio.

Disarmare l’intelligenza artificiale

Chiudo con l’immagine che mi ha colpito di più nell’enciclica, e che Don Michele teneva a rilanciare. Magnifica Humanitas dice una cosa forte, con questa tecnologia non basta regolarla.

va disarmata e resa ospitale.

Disarmare, nelle parole del Papa, non vuol dire rinunciare alla tecnologia, vuol dire impedirle di dominare l’umano, sottrarla alla corsa all’algoritmo più potente e alla banca dati più vasta, renderla discutibile e contestabile, e perciò abitabile. Lo chiama un compito ecologico nel senso più radicale, perché riguarda la nostra Casa comune, che ormai è anche l’ambiente digitale in cui viviamo tutti. Il mio libro ci arriva da un’altra strada, l’intelligenza artificiale è già la nostra pelle, e una pelle si abita, non si subisce.


Per andare oltre: l’enciclica Magnifica Humanitas, in particolare il terzo e il quarto capitolo dove entra nel merito dell’intelligenza artificiale, e Pelle digitale, che a quei capitoli fa eco da un’altra angolazione. Trovi tutti i miei libri nella pagina pubblicazioni e libri e altri articoli sull’intelligenza artificiale.

Modelli di frontiera: la mappa di chi li costruisce, come sono fatti e quanto costano

Mai prima d’ora un governo aveva staccato la spina a uno dei modelli di frontiera già in mano al pubblico. È successo a giugno, con Fable 5 e Mythos 5 di Anthropic, spenti su ordine dell’amministrazione americana per ragioni di sicurezza nazionale. Sotto la cronaca c’è un fatto più grande di un singolo provider: alcuni di questi sistemi sono diventati abbastanza potenti da essere maneggiati come materiale strategico, al pari di un chip avanzato o di una tecnologia a duplice uso.

La parola gira ovunque, il suo significato molto meno, e per orientarsi conviene partire dall’origine del nome.

Una parola nata nei corridoi della policy

Il termine non viene dal marketing. Nasce a metà 2023, in un paper firmato da ricercatori legati al Future of Humanity Institute, che chiamavano “frontier AI” i modelli fondazionali tanto capaci da poter sviluppare abilità pericolose per la sicurezza pubblica. Da lì è entrato nel vocabolario dei governi, prima fra tutti quello britannico con la sua Frontier AI Taskforce e il summit sulla sicurezza dell’AI di fine 2023.

La definizione ha una caratteristica scomoda, si muove. Frontiera è qualunque cosa stia sul bordo più avanzato delle capacità in un dato momento, il che vuol dire che il modello di punta di oggi sarà il modello mediocre di dopodomani. Accanto a questa lettura mobile ne esiste una più rigida, usata dai regolatori, che fissa una soglia di calcolo: oltre i 10²⁶ FLOP impiegati per l’addestramento scattano obblighi di trasparenza e compliance. Due definizioni che convivono, una basata su cosa il modello sa fare, l’altra su quanta energia è servita a costruirlo.

Sotto il cofano c’è sempre un Transformer

Tolta la scenografia, l’impalcatura è la stessa per tutti. L’architettura di base si chiama Transformer ed è del 2017. Per dare la misura di quanto è cambiato il gioco: addestrare quel primo Transformer costò intorno ai 900 dollari. I modelli di cui parliamo oggi sono figli di quella stessa idea, cresciuta di parecchi ordini di grandezza.

Quasi tutti i modelli di frontiera adottano una variante chiamata mixture-of-experts. Invece di accendere l’intera rete per ogni parola che elaborano, la suddividono in molti moduli specializzati e ne attivano solo una frazione alla volta. È il trucco che permette di avere modelli enormi sulla carta e relativamente economici da far girare nella pratica.

Poi c’è il ciclo di costruzione, diviso in due tempi. Il pre-training è la fase cara, quella in cui il modello divora enormi quantità di testo e codice, immagini e suono, bruciando i milioni di dollari di calcolo. Il post-training viene dopo, costa molto meno, e serve a rendere il modello utile e allineato, insegnandogli a seguire le istruzioni e a comportarsi in modo prevedibile. Gran parte di ciò che percepiamo come “carattere” di un modello si decide in questa seconda fase.

La novità degli ultimi diciotto mesi sono i modelli che ragionano prima di rispondere, generando catene di pensiero interne prima di consegnare l’output. È la leva che ha spinto in alto i punteggi in matematica, programmazione e scienza. Insieme a questo conta la finestra di contesto, quanto materiale il modello riesce a tenere sotto gli occhi in una volta sola. La linea di frontiera si è assestata intorno al milione di token, con qualche eccezione che spinge molto oltre: una startup di Miami ne ha annunciato uno da dodici milioni, e tra i modelli scaricabili Llama 4 Scout arriva a dieci.

Quattro nomi in testa e due spenti dal governo

A metà 2026 il gruppo di testa dei modelli di frontiera è abbastanza leggibile, anche se cambia di mano in continuazione. Claude Opus 4.8, uscito il 28 maggio, guida l’indice di intelligenza di Artificial Analysis. Intorno gli stanno GPT-5.5 di OpenAI, Gemini 3.1 Pro di Google e Grok 4.3 di xAI. Nessuno vince su tutto: chi domina la programmazione arranca sulla scrittura creativa, chi guida sul ragionamento puro costa la metà di un concorrente. La domanda utile non è quale sia il migliore in assoluto, ma quale sia il migliore per un certo lavoro.

Poi c’è la storia di Mythos. Anthropic lo presenta ad aprile come un modello capace di trovare da solo le falle di sicurezza in codice considerato inattaccabile, una capacità giudicata troppo pericolosa per un rilascio aperto. Invece di metterlo in vendita, l’azienda lo affida a un consorzio ristretto, Project Glasswing, una cinquantina di organizzazioni all’inizio, circa centocinquanta a inizio giugno, tra cui Google, Nvidia, Microsoft e Apple. Il 9 giugno arriva la versione commerciale, Fable 5, lo stesso modello con dei filtri che bloccano le richieste nelle aree ad alto rischio come cyber e biologia, dirottandole su Opus 4.8 in meno del cinque per cento delle sessioni. Tre giorni dopo il governo stacca tutto, e il telecom coreano sospettato di legami con la Cina che secondo le ricostruzioni avrebbe fatto scattare la direttiva ci ricorda quanto sia diventato politico il confine tra chi può usare un modello e chi no.

L’altra metà della frontiera parla cinese

Chi guarda solo agli Stati Uniti vede metà del quadro. L’altra metà parla cinese, e ha scelto una strada diversa, quella dei pesi aperti. Ad aprile, otto dei dieci modelli cinesi più capaci erano scaricabili, eseguibili sui propri server, utilizzabili commercialmente. La famiglia Qwen di Alibaba ha superato Llama di Meta nei download cumulativi su HuggingFace, e i modelli cinesi viaggiano ormai oltre il quarantacinque per cento del traffico su OpenRouter, contro meno del due per cento di un anno prima.

I nomi da tenere d’occhio sono pochi e netti. DeepSeek ha fatto del prezzo la sua arma, con la versione V4 che raggiunge la parità con i modelli occidentali di punta sul coding agentico a circa trenta centesimi per milione di token. GLM di Zhipu è il primo modello di frontiera addestrato per intero su chip Huawei Ascend, senza una sola GPU Nvidia, e gira sotto licenza MIT, la più permissiva del lotto. Kimi di Moonshot ha puntato sugli agenti, con un’architettura a sciame che coordina fino a cento sotto-agenti in parallelo. Sopra tutti resta una verità che il marketing cinese non ama: sui benchmark trasversali più severi, una valutazione del NIST stima il modello cinese di punta indietro di circa otto mesi rispetto alla frontiera americana. Otto mesi, in questo settore, sono insieme pochissimo e moltissimo.

C’è un dettaglio che pesa più dei punteggi. Un modello aperto e competitivo lo si può far girare dentro la propria infrastruttura, senza che nessun fornitore possa spegnerlo per ordine di un governo. La vicenda Fable 5 ha dato a questo argomento un peso che i grafici di benchmark non davano.

Centinaia di milioni per costruirli, centesimi per usarli

Quando si parla di costi conviene tenere separate due voci che differiscono di mille volte. Costruire un modello di frontiera è una faccenda da centinaia di milioni di dollari. Le grandi sessioni di addestramento dei modelli di frontiera nel 2026 stanno tra i duecento e i cinquecento milioni per la classe di GPT-5 e Gemini, e le proiezioni parlano di uno o tre miliardi a modello entro fine 2027. Secondo le stime di Epoch AI la spesa cresce di 2,4 volte l’anno dal 2016, e il vincolo che frena il prossimo salto oggi è la potenza elettrica dei data center, più dei chip. Dove vanno questi soldi? Quasi metà in chip e hardware dei server, una fetta robusta in stipendi dei ricercatori. Ecco perché la partita la giocano in pochi, serve un capitale che la maggior parte delle aziende non può nemmeno immaginare.

Usarli, invece, costa sempre meno. Il prezzo dell’inferenza, far rispondere il modello, è crollato di circa 280 volte in diciotto mesi a parità di prestazioni. Oggi i listini della frontiera vanno da dieci centesimi a settantacinque dollari per milione di token, una forbice enorme che si naviga guardando al rapporto tra prezzo e qualità, prima ancora che alla cima della classifica. È qui che i modelli cinesi aperti mordono di più, perché possono azzerare il costo per chi se li ospita in casa.

Nuovi modelli di frontiera ogni undici giorni

Tra febbraio e aprile 2026, in settantotto giorni, i tre principali laboratori americani hanno rilasciato sette modelli di frontiera. Uno stato dell’arte nuovo ogni undici giorni. Qualunque classifica scritta oggi sarà parzialmente falsa tra un mese, ed è la ragione per cui legarsi a un solo fornitore è diventato fragile. Chi costruisce sopra questi modelli sta imparando a instradare il lavoro tra più di uno, tenendo aperta la porta anche all’opzione di farne girare uno proprio, dentro casa.

Resta la domanda che la settimana del 12 giugno ha lasciato sul tavolo, e vale più di ogni benchmark. Se un modello di punta può sparire dall’oggi al domani per ordine di un governo, la frontiera appartiene a chi lo addestra o a chi tiene la mano sull’interruttore?

Tecnologia e lavoro nell’era degli shock: appunti da Napoli

Il 19 giugno, nel Complesso di Sant’Anna dei Lombardi a Napoli, è partito il primo appuntamento di Cantieri di Futuro, il percorso del Centro di competenza SI.FA. dedicato alle tecnologie per la transizione sociale digitale. Tre interventi al mattino, poi due sessioni di lavoro guidato ai tavoli, e sopra le nostre teste una volta affrescata che da sola ti ricorda una cosa semplice, e cioè che il futuro lo costruisce sempre qualcuno dentro spazi lasciati in eredità da chi è venuto prima. Mi hanno chiesto di fare da stimolo alla discussione, e invece di aggiungere l’ennesima lista di trend ho scelto di fare un passo indietro, fino alle curve, per provare a leggere le opportunità dell’era degli shock.

Lo strappo che chiamiamo shock

La tecnologia avanza su una curva che accelera. Le persone, le organizzazioni, le competenze, le istituzioni si adattano su una curva molto più lenta, quasi piatta al confronto. La distanza tra le due è quello che viviamo come shock, e lo viviamo male perché la nostra testa legge il mondo in modo lineare, e davanti a una crescita esponenziale la sottostima quasi sempre. È lo stesso fenomeno, la stessa intelligenza artificiale, che a qualcuno sembra un’apocalisse e a qualcun altro un giocattolo, a seconda di dove si trova rispetto a quelle due linee. Gli shock, allora, non sono temporali isolati che passano e poi torna il sereno. Sono la condizione di chi vive nel divario, e quel divario continua ad allargarsi. La parte interessante è che lo stesso spazio vuoto, in mezzo alle due curve, è dove nascono i lavori e i servizi che ancora non abbiamo immaginato.

Dal lavoro al task

Quando diciamo che l’automazione e la GenAI tolgono lavoro, stiamo usando l’unità di misura sbagliata. Un lavoro è un insieme di task, e l’automazione li ridistribuisce dentro i mestieri, che cambiano forma ma restano. Una parte se la prende la macchina, il ripetitivo e il prevedibile. Una parte resta profondamente umana, il giudizio su un caso che non somiglia a nessun altro, la relazione, la responsabilità di una decisione presa su una persona vera. E una parte nasce nuova, perché qualcuno deve orchestrare la macchina, progettare l’interazione, prendersi cura di quello che produce. Si capisce dove il lavoro si sta spostando solo guardando i task, al posto dei titoli stampati sui biglietti da visita. In Pelle Digitale ho provato a raccontare proprio quella zona di confine tra noi e le macchine, lo strato sottile in cui decidiamo ogni giorno cosa deleghiamo e cosa teniamo stretto.

La mente adattiva diventa competenza di base

Se ogni abilità vive su una curva, allora a un certo punto ogni abilità invecchia, e nessuna competenza tecnica da sola ci basta per molto tempo. Quello che resta, e che vale più di qualunque strumento, è la capacità di continuare a imparare e a ricomporsi mentre tutto cambia sotto i piedi. Le competenze che serviranno stanno in tre famiglie. La prima è saper lavorare con la macchina, orchestrarla, supervisionarla, darle istruzioni che funzionano. La seconda è il profondamente umano, la cura, il giudizio, la relazione, l’etica, tutto ciò che non si automatizza e che diventa più prezioso man mano che il resto si automatizza. La terza è imparare a imparare, perché il ciclo si ripeterà, e chi lo sa attraversare più volte parte avvantaggiato. È il pattern con cui lavoro da anni, e in un paio dei miei libri, La mente adattiva e Da Zero a Loop, è il filo che tiene insieme tutto il resto.

Tre angoli che convergono sulle persone

La cosa più bella della mattinata è stata accorgersi, senza esserci messi d’accordo prima, che i tre interventi guardavano nello stesso punto. Roberto Paura, presidente dell’Italian Institute for the Future, ha messo in fila dati e megatrend, da dove veniamo e verso dove stiamo andando, con lo sguardo lungo di chi studia il futuro per mestiere. Riccarda Zezza, fondatrice di Lifeed, ha mostrato come le competenze che contano si allenino nei contesti di vita, nella famiglia, nelle amicizie, nella cura di una persona anziana, persino nello sport, e poi si trasferiscano al lavoro. Le mie curve stavano nel mezzo, a spiegare perché quel passaggio oggi è diventato così urgente. Tre angoli diversi, una sola direzione, e al centro sempre le persone con la loro capacità di adattarsi.

Nell’economia sociale la posta è più alta

C’è un motivo per cui questo ragionamento, applicato all’economia sociale, pesa il doppio. Lì il valore di ciò che si fa è la relazione, ed è esattamente la parte che nessuna macchina prende. La transizione digitale del sociale serve allora a liberare l’operatore dal task ripetitivo, dalla carta, dagli spostamenti inutili, così che arrivi a più persone e con più continuità, e a far nascere ruoli nuovi attorno a quella relazione, dal navigatore digitale che accompagna le persone fragili fino al case manager che segue la persona con i dati invece che con i moduli. La tecnologia migliore, in questo campo, è quella che non si nota. Si nota la persona che prima restava fuori e che adesso viene raggiunta.

Cantieri, non previsioni

Per tutto questo preferisco la parola cantieri alla parola previsioni. Una previsione la guardi da fuori, e aspetti che si avveri o che ti smentisca. Un cantiere lo apri, ci entri, e ti sporchi le mani. Il futuro del lavoro nel sociale non arriverà nonostante gli shock, nascerà dentro il divario tra le due curve, e qualcuno dovrà lavorarci. Oggi, a Napoli, abbiamo iniziato a farlo. La domanda che mi porto a casa, e che lascio ai tavoli, è la più semplice di tutte: tutto quello che sta cambiando, per chi lo stiamo cambiando?


Cantieri di Futuro, primo appuntamento del percorso del Centro di competenza SI.FA., ospitato da ParteNeapolis al Complesso monumentale di Sant’Anna dei Lombardi, Napoli, 19 giugno 2026. Grazie a Marco Traversi per l’invito.