Tag: ai for business

AI & GENAI, TECH & BUSINESS

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

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

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

Sette anni di infrastruttura prima del successo improvviso

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

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

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

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

Un computer intero dentro la scheda

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

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

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

Bolt ha smesso di inseguire i curiosi

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

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

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

Sono i file a consumare i token

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

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

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

La sandbox protegge finché il codice non esce

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

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

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

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

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

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

Il vecchio agente ha una data di spegnimento

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

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

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

Dove si colloca rispetto a Lovable e Replit

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

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

Il primo progetto

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

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

Dove regge, dove rallenta

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

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

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

Riferimenti.

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

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

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

Regole scritte a mano, regole imparate

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

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

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

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

Il model router diventa un prodotto da scaffale

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

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

La via che resta in casa

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

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

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

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

Funziona dove il risultato si può misurare

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

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

Il registro dei prompt vale più del modello

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

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

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

AI & GENAI, TECH & BUSINESS

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

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

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

Da editor nel browser a valutazione da nove miliardi

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

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

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

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

Un ambiente completo dentro una scheda del browser

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

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

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

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

Quanta autonomia dare all’agente

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dove si colloca rispetto a Lovable e Bolt

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

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

Il primo progetto

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

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

Dove regge, dove rallenta

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

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

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

Riferimenti.

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

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

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

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

AI & GENAI, TECH & BUSINESS

AI bill shock: la bolletta dei token è arrivata, come previsto

Il conto è arrivato, e ha pure un nome. Da mesi, tra le chiamate con i clienti e i pezzi che scrivo, ripeto la stessa cosa: il costo dei token non è un dettaglio da smanettoni, è la prossima voce che finisce sul tavolo del CFO. A marzo lo scrivevo su AI4Business, parlando di governo economico dei token come disciplina ancora da costruire. A maggio, qui sul blog, mettevo per iscritto che sarebbe arrivato sotto forma di budget esplosi a fine mese.

Questa settimana CorCom lo ha chiamato AI bill shock, riprendendo un’analisi di Analysys Mason: la spesa a consumo per modelli generativi, Api e agenti autonomi rende i budget aziendali sempre meno prevedibili, al punto da riportare sul tavolo di molti CIO l’idea di possedere un pezzo della propria infrastruttura invece di affittarla sempre. I numeri sotto contano più del titolo. Il budget è solo la parte più visibile: sotto ci sono i dati, la compliance, il controllo dell’infrastruttura su cui gira la tua azienda.

300 aziende, un balzo del 500%

Tra aprile e maggio circa 300 aziende hanno sollevato la questione dei costi legati ai token durante le chiamate agli investitori sui risultati trimestrali, contro le 93 dello stesso periodo dell’anno precedente. Lo racconta AI4Business citando Paul Roetzer e Mike Kaput del Marketing AI Institute. La Royal Bank of Canada ha visto il proprio consumo di token salire del 500% in sei mesi. Cisco descrive i propri volumi come fuori da ogni norma conosciuta.

Amazon, Walmart, Uber, Cisco e Meta, secondo quanto riportato dal Financial Times e ripreso sempre da AI4Business, hanno già introdotto tetti di spesa o indicazioni più severe su quando vale davvero la pena accendere un modello. Uber ha fissato un tetto di 1.500 dollari al mese per dipendente dopo aver esaurito, già ad aprile, l’intero budget AI previsto per il 2026. Amazon ha spento la classifica interna che misurava quanto i dipendenti usassero l’AI, dopo aver scoperto che alcuni ingegneri facevano girare bot autonomi solo per scalare la graduatoria: è il fenomeno che va sotto il nome di tokenmaxxing, la corsa alla vanità mascherata da adozione.

A Workato, azienda da 1.300 dipendenti, la spesa è aumentata di sette volte in un solo giorno quando Anthropic ha spostato l’azienda su un pricing basato sui token, a maggio. Goldman Sachs Research stima che l’uso degli agenti possa moltiplicare per 24 il consumo di token entro il 2030. E sul mercato aperto dei modelli, secondo i dati di OpenRouter ripresi dal Financial Times, i modelli cinesi hanno già superato quelli americani per consumo di token: quando il prezzo diventa il primo criterio di scelta, a vincere è chi costa meno, non chi segna il punteggio più alto sui benchmark.

Il token non misura il lavoro fatto

Più del volume, a ingannare è la natura della metrica. I fornitori fanno pagare i token di output da due a cinque volte più di quelli di input, perché generare una risposta costa computazionalmente più che leggerla: il modello prevede una parola alla volta, in sequenza, mentre l’input lo processa in un solo passaggio. Due flussi di lavoro che sembrano identici per volume possono avere costi molto diversi a seconda di quanto testo producono rispetto a quanto ne ricevono, e quasi nessuna azienda, quando firma il contratto, ci pensa davvero. Un prompt di 1.500 parole, quasi 2mila token, che produce una sintesi di 600 parole, circa 800 token, costa già un paio di centesimi con un modello come Claude 3.5 Sonnet: sembra nulla, finché non lo moltiplichi per centinaia di richieste al giorno e per ogni team che nel frattempo ha acceso un proprio agente senza dirlo a nessuno.

Gli agenti aggravano la cosa, perché a ogni passaggio ritrasmettono l’intero contesto della conversazione: alla decima fase di un compito, il modello rilegge integralmente le prime nove. AI4Business fa un esempio concreto, quello di un assistente per il servizio clienti che accede a una base di conoscenza di 20mila token: per mille richieste al giorno, genera 20 milioni di token quotidiani solo per rileggere sempre gli stessi dati, circa 60 dollari al giorno spesi prima ancora di rispondere a un cliente vero. Se l’agente si blocca in un loop, o richiama più volte lo stesso strumento, il conto sale prima che qualcuno se ne accorga.

L’AI bill shock non è un problema di cassa

Affidare l’inferenza a un fornitore esterno porta con sé più di un conto a consumo: la sua politica dei prezzi, i suoi limiti di utilizzo, le sue scelte su dove vivono i tuoi dati, la sua libertà di cambiare le regole senza preavviso. Il pricing può cambiare le regole da un mese all’altro, come è successo a Workato quando Anthropic l’ha spostata su un modello a consumo. Un fornitore può introdurre un tetto di utilizzo che scopri solo quando lo tocchi, a metà di una sessione di lavoro, come raccontano diversi utenti citati da AI4Business. Un governo può spegnere l’accesso a un modello, come abbiamo visto succedere quest’anno. E quando arriva un audit di conformità, la domanda su dove sia passato un dato aziendale durante l’inferenza, su quale server, sotto quale giurisdizione, spesso non ha una risposta scritta da nessuna parte.

Bain, in un sondaggio su 951 aziende pubblicato a giugno, trova che quasi il 40% di chi ha misurato i risparmi da AI è rimasto sotto il 10%, contro un obiettivo dichiarato dell’11-20%. Michael Heric, uno degli autori della ricerca, spiega che per molte aziende il business case si ferma alla spesa in token e non arriva mai a contare i costi di data engineering, di governance, di conformità che le girano intorno. Il 90%, nonostante tutto, aumenta comunque il budget per l’anno prossimo, prova che nessuno ha ancora imparato a misurare il ritorno dell’AI con lo stesso rigore con cui ne misura il costo.

LocalAI lavora esattamente in questa direzione: porta l’inferenza dentro il perimetro dell’azienda invece di affittarla ogni mese da qualcun altro. I costi non spariscono: cambia chi li governa. Sai dove vivono i dati, sai quanto costa davvero un carico di lavoro perché lo possiedi, e nessuno può cambiarti il prezzo o il tetto di utilizzo a metà mese.

Dall’opex che non controlli al capex che scegli

Analysys Mason legge lo spostamento come l’ennesimo giro di un ciclo che l’informatica ha già visto: dal mainframe centralizzato ai minicomputer distribuiti, dal PC in rete al cloud che ricentralizza tutto, e ora l’AI che riapre la stessa domanda. Comprare calcolo come servizio o possederne una parte? Per chi ha volumi di inferenza stabili, la risposta pratica passa quasi sempre dall’ibrido: hardware proprio per i compiti che non hanno bisogno di un modello di frontiera, server dedicati o cloud privato per il resto, il cloud pubblico riservato a ciò che lo giustifica davvero.

Il TCO a tre anni tra cloud e on-premise, calcolato sui prezzi reali di Claude, GPT, Gemini e DeepSeek, conferma la stessa cosa: nella maggior parte degli scenari aziendali italiani l’on-premise vince con margine quando i volumi sono prevedibili, mentre il cloud resta la scelta giusta per i picchi occasionali e per chi parte da zero. La maggior parte del traffico di un’azienda, del resto, non ha bisogno del modello più caro: ha bisogno di un sistema che decida bene dove instradarlo. Quella logica di instradamento, non il modello scelto per ultimo, è ciò che decide chi resta padrone della propria infrastruttura.

Decide il board, non il reparto IT

Il sondaggio di Bain lo conferma da un altro lato: le aziende che centrano i risparmi attesi sono quelle che hanno trattato l’accesso ai dati, la governance e il ridisegno dei processi come materia da consiglio di amministrazione, non da reparto IT. Vale lo stesso per il bill shock. Un alert di budget o un tetto di spesa imposto dall’alto sposta il sintomo, non la causa.

La prima domanda, in questi casi, non riguarda mai il modello. Riguarda dove vivono i dati, chi decide quanto vale un’ora di inferenza, cosa succede se domani il fornitore cambia le regole: non cambia molto se l’azienda ha cinquanta o cinquemila dipendenti, cambia solo quanto in fretta un budget fuori controllo diventa un problema di tutti, non solo di chi ha acceso l’ultimo agente.

La bolletta continuerà a salire, per tutti. La differenza, da qui in avanti, la fa chi ha già deciso come governarla e chi la scoprirà solo a budget già bruciato.

Fonti: CorCom su Analysys Mason; AI4Business, “La crisi dei token che spaventa i budget aziendali”; AI4Business, “AI, le aziende frenano”; Bain & Company, Automation and AI Pathfinder Survey 2026.

AI & GENAI, TECH & BUSINESS

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.

AI & GENAI

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

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

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

Il salto rispetto al singolo agente

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

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

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

Bun, ovvero il caso scomodo

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

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

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

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

Piani che diventano codice

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

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

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

Il conto da tenere d’occhio

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

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

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

La pianificazione delegata, la verifica no

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

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

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

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

AI & GENAI, TECH & BUSINESS

Il router prima del modello

Il 1° luglio Tomasz Tunguz di Theory Ventures ha scritto una cosa semplice che quasi nessuno applica: la maggior parte dei team che costruisce agenti sceglie il modello per primo. Sbaglia ordine, e lo sbaglia sistematicamente, perché il modello è la decisione più visibile e quindi quella su cui si concentra tutta l’attenzione, mentre il pezzo che davvero determina costo e latenza resta invisibile: il router, cioè il codice che decide chi risponde a ogni singola richiesta.

Tunguz lo racconta riferendosi al modo in cui Coinbase ha dimezzato la spesa in AI mentre il consumo di token cresceva, non frenando gli ingegneri con alert di budget ma cambiando i default di instradamento. È un’osservazione operativa, non una teoria, e tocca qualcosa che seguo da mesi lavorando con LocalAI: la sovranità computazionale si gioca sull’architettura, molto più che sulla scelta del modello.

Tre problemi diversi, non uno

Classificatore, router e selettore vengono trattati come sinonimi, e non lo sono. Il classificatore riconosce l’intento: trasforma una richiesta grezza dell’utente in un’operazione concreta, riassumere un repository, scrivere una risposta, lanciare una migrazione. Il router legge quell’etichetta insieme a poche feature, complessità, dimensione del contesto, storico di successo, e decide su quale livello far girare l’operazione. Il selettore, infine, sceglie il modello più economico dentro quel livello che rispetta una soglia di confidenza.

Confonderli è comodo mentre si scrive il primo prototipo, e costa caro dopo: la scelta del modello finisce sepolta dentro il prompt, e diventa impossibile testare due modelli diversi sulla stessa operazione senza riscrivere mezzo sistema. È lo stesso errore di livello che ho descritto parlando dello stack verticale dell’AI: confondere i piani porta a decisioni prese al piano sbagliato.

Il locale è gratis, l’asincrono è economico, il tempo reale costa

E infatti è questa la parte che mi ha fatto fermare a rileggere. Il calcolo locale ha un costo marginale prossimo allo zero, il batch asincrono costa due ordini di grandezza meno dell’inferenza in tempo reale, e la parte di lavoro che ha davvero bisogno di una risposta immediata è sorprendentemente piccola, una volta che il sistema può accodare.

Una bozza di risposta, un riassunto di repository, un memo di due diligence, la valutazione notturna di un batch di tracce: nessuno di questi compiti pretende un secondo di risposta. Pretende di essere fatto bene, non subito.

Ho visto questa stessa dinamica dentro LocalAI, dove la maggioranza del traffico non tecnico regge tranquillamente su modelli piccoli fatti girare in locale, con il cloud che entra in scena solo quando il compito lo richiede davvero. Non è un compromesso al ribasso, è disegno.

Un ciclo che impara mentre dorme

Ecco, e qui il design descritto da Tunguz aggiunge un doppio ritmo di feedback che vale la pena isolare. Un predittore sincrono annota ogni richiesta in ingresso con cinque segnali di rischio, dal contesto di repository mancante alle catene di dipendenze troppo lunghe, fino alle scritture che possono avere conseguenze pesanti se sbagliate, e intercetta così i compiti già noti come difficili prima che falliscano.

Poi, ogni notte, un valutatore batch rilegge le tracce del giorno e aggiorna i pesi del router, mentre il costo di quella valutazione resta vicino allo zero perché gira anch’esso in modalità asincrona. Ed è lì che il sistema scopre i modi di fallire che il predittore non aveva ancora imparato a riconoscere.

Mi sembra la versione infrastrutturale di qualcosa che scrivo da tempo a proposito del vantaggio che un’organizzazione accumula in memoria, non in modello: un sistema che non ha un meccanismo per far rientrare l’esperienza di ieri nelle decisioni di oggi accumula lo stesso tipo di debito, che si parli di persone o di router. L’ho scritto anche a proposito del tokenmaxxing: quel che resta dopo la spesa pesa più del numero speso, che si tratti di token o di traffico instradato.

Da dove si comincia davvero

Nei progetti dove entro a lavorare sull’adozione dell’AI, il primo intervento quasi mai tocca il modello. Tocca l’inventario dei segnali di fallimento: quali richieste arrivano senza contesto sufficiente, quali toccano dati sensibili, quali scritture, se sbagliate, costano care da correggere. Prima si rende visibile quel rischio, poi si decide dove instradarlo.

È un lavoro lento e poco fotogenico rispetto a scegliere l’ultimo modello uscito, e proprio per questo tende a restare indietro nella lista delle priorità. Ma un router costruito senza quella mappa dei rischi impara a fatica, perché non sa cosa sta effettivamente evitando di rompere. Il ciclo notturno di cui scrive Tunguz funziona solo se qualcuno, all’inizio, ha scritto a mano la prima versione grezza di quella mappa.

Chi possiede la logica di instradamento

Se il novanta per cento del traffico può girare su modelli piccoli e locali, la dipendenza da un singolo fornitore cloud smette di essere un fatto tecnico e diventa una scelta di governance, quasi sempre presa per default e non per decisione consapevole.

Progettare intorno al routing, non intorno al modello, sposta il controllo esattamente lì: chi scrive la logica che manda il traffico da una parte o dall’altra decide, di fatto, chi resta padrone dell’infrastruttura. Nella maggior parte delle aziende che conosco quella logica non la possiede nessuno davvero: cresce dentro il notebook di un ingegnere, non dentro un comitato di governance. Ed è lì, non nel modello scelto per ultimo, che si decide chi dipende da chi.

Spunto: Tomasz Tunguz, General Partner at Theory Ventures.

Confronto tra tokenmaxxing di vanità e tokenmaxxing strategico
AI & GENAI, TECH & BUSINESS

Tokenmaxxing: cosa serve oltre a bruciare token

Ottantacinquemila dipendenti di Meta compaiono in una classifica interna dedicata al tokenmaxxing. Si chiama Claudeonomics, l’hanno costruita loro stessi incrociando i dati di utilizzo aziendale, e misura una cosa sola: quanti token ciascuno consuma lavorando con l’AI. In cima ci sono i “Token Legend”, vince chi ne brucia di più. A fine aprile Business Insider ha raccontato la lista, a fine maggio Amazon ha spento la sua versione interna dello stesso gioco, e a giugno Fortune titolava che il tokenmaxxing era già finito.

Finito nella forma che fa notizia, forse. Nella forma che sposta budget vero dalle assunzioni al motore agentico, il tokenmaxxing è appena cominciato, e le due cose vengono continuamente confuse.

Amazon ha spento la classifica interna sui token

La dinamica descritta da chi l’ha vissuta è semplice. Un dashboard aziendale mette in fila i dipendenti per numero di token consumati, il numero diventa visibile ai manager, e da lì in poi la classifica smette di misurare qualcosa e comincia a determinarlo. È il meccanismo che gli economisti chiamano legge di Goodhart: una misura, appena diventa un obiettivo dichiarato, smette di essere una buona misura. Al Financial Times alcuni dipendenti Amazon hanno raccontato di aver fatto girare agenti su compiti inutili solo per restare in classifica, mentre Uber, secondo Fortune, ha esaurito l’intero budget AI del 2026 in quattro mesi.

Il paradosso è che nessuno, in questa versione del fenomeno, sta ridisegnando un solo processo. Si sta solo alzando un contatore. Ridisegnare i flussi di lavoro attorno all’AI è lavoro lento, spendere token per apparire “AI-native” è immediato, e la seconda cosa continua a travestirsi da prova della prima.

Il bilancio AI di Uber esaurito in quattro mesi

Nello stesso periodo, però, circola un’idea quasi opposta con lo stesso nome. Y Combinator la spiega ai suoi fondatori così: tokenmaxx, non headcountmaxx. Diana Hu, partner del fondo, lo dice senza troppi giri: una persona con gli strumenti giusti oggi può valere quello che prima valeva un intero team di ingegneria, e un budget API “scomodamente alto” è spesso più economico di un organico gonfiato.

Qui il token non è un trofeo da esibire su una classifica interna, è una voce di bilancio che sostituisce uno stipendio. Una startup che nasce nel 2026 non deve disimparare trent’anni di processi legacy per diventare AI-native, li costruisce così fin dal primo giorno: meno persone, più agenti, decisioni che si prendono dentro un flusso continuo invece che in una riunione settimanale.

Due aziende possono dichiararsi entrambe “tokenmaxxing” e fare l’esatto contrario: una infila numeri in un dashboard per sembrare avanti, l’altra riscrive l’organigramma attorno a quei numeri.

Cosa distingue un token che produce conoscenza da uno sprecato

Confronto tra tokenmaxxing di vanità e tokenmaxxing strategico

Il test operativo che circola tra chi studia il tokenmaxxing si riduce a una domanda: quando il volume di token sale, cosa cambia nel lavoro che viene effettivamente accettato? Se la risposta è “niente”, si sta guardando la versione di vanità. Se la risposta è “un ciclo di revisione in meno, una decisione presa prima, un cliente servito senza aspettare”, si è dentro qualcosa che vale la pena misurare.

Un sistema che moltiplica le interazioni con l’AI senza lasciare che quelle interazioni si accumulino in qualcosa di riusabile genera un debito. Non lo vedi nella fattura del mese, lo vedi tre mesi dopo, quando ogni nuovo agente riparte da zero perché nessuno ha organizzato ciò che il primo aveva già imparato. Il vantaggio, in questo genere di sistemi, smette di stare nel modello e finisce nella memoria che un’azienda accumula, e lo stesso principio vale per il conto dei token: quel che resta dopo la spesa pesa più del numero speso.

Il ciclo che rende utile il tokenmaxxing

L’azienda che tokenmaxxa in modo utile non brucia token in sessioni isolate, li fa girare in un ciclo che si autoalimenta. Un ticket di supporto genera una sintesi, la sintesi aggiorna la base di conoscenza condivisa, la base di conoscenza informa il prossimo agente che risponde a un cliente simile, e ogni giro rende il giro successivo più preciso e più economico. Satya Nadella lo scorso mese ha messo lo stesso meccanismo al centro della sua visione d’impresa, chiamandolo learning loop, e il punto che aggiungo io è che il ciclo regge solo se qualcuno possiede l’infrastruttura che lo fa girare, non solo il modello che lo alimenta.

Schema del loop aziendale: strumenti aziendali, agente AI, verifica umana, base di conoscenza condivisa

La meccanica del ciclo: trigger, non riunioni

Il loop non si costruisce con più call di allineamento, si costruisce con eventi che si attivano da soli. Un ticket chiuso genera un webhook, il webhook passa il testo a un agente con accesso al contesto storico del cliente, l’agente produce una sintesi strutturata e la scrive in un repository condiviso, e quella sintesi diventa automaticamente parte del contesto disponibile per il prossimo ticket simile. Nessun passaggio richiede che un umano apra una chat e formuli una domanda: il trigger sostituisce la richiesta.

Nel tokenmaxxing che funziona, la differenza tecnica che conta è tra un agente che risponde quando qualcuno lo interpella e un agente che si attiva quando cambia lo stato di un sistema: un CRM aggiornato, un documento modificato, una trascrizione caricata. Il secondo tipo tiene il ciclo vivo anche quando in azienda nessuno sta guardando, ed è quello che separa un assistente da un processo.

I loop cambiano forma da reparto a reparto

In assistenza clienti il loop più maturo parte da un ticket risolto: il caso alimenta una base di risposte pronte, e il prossimo cliente con lo stesso problema riceve una soluzione prima ancora che un operatore la legga. In ingegneria il ciclo passa dai code review, ogni commento di un revisore diventa una regola che l’agente applica al pull request successivo invece di essere ripetuto una volta di più. Nelle vendite il loop nasce dalla trascrizione delle chiamate: l’agente estrae le obiezioni ricorrenti e le carica nel CRM come suggerimenti per la trattativa dopo, senza aspettare il report trimestrale. Nella finanza aziendale il ciclo si chiude sulle policy di spesa, ogni eccezione approvata aggiorna la regola scritta e la richiesta successiva non arriva più a un umano se rientra nel nuovo perimetro. Nelle risorse umane il loop gira attorno alle domande sui benefit: la prima risposta corretta diventa voce di una base consultabile, la centesima non richiede più nessuno.

Il segnale che il ciclo funziona si misura sul tempo, non sui reparti coinvolti: quanto passa tra un’interazione e il momento in cui quell’interazione aggiorna qualcosa di consultabile per la prossima. Se la risposta è “mai”, quel reparto sta ancora solo usando l’AI, il loop non è partito.

Non conta quanto token bruci ma cosa resta dopo

Le aziende nate trent’anni fa restano indietro non perché usino meno AI, ma perché il loro organigramma è stato disegnato prima che esistesse un’alternativa al mettere una persona su ogni compito. Cambiarlo ora significa smontare processi che hanno funzionato per decenni, ed è un lavoro che nessun dashboard di token può velocizzare. Le aziende che nascono oggi non hanno questo problema, e la differenza tra chi vince e chi perde questa fase si vede meno nella fattura di Anthropic o OpenAI e più in quante decisioni, alla fine del trimestre, vengono ancora prese da un umano che rilegge tutto da capo.

Il ruolo umano che resta, in questo schema, è quello descritto anche in un pezzo recente su chi oggi gestisce insieme persone e agenti: meno produzione diretta, più verifica, correzione, approvazione finale. Un lavoro che a differenza dei token non si può comprare a peso.

Chi guarda la classifica dei token e pensa di aver capito qualcosa dell’azienda del 2026 sta guardando la metrica sbagliata. La domanda utile non è quanti token, ma quanti di quei token tornano indietro sotto forma di conoscenza che il prossimo agente non deve reinventare.

Fonti: Fortune, The Pragmatic Engineer, Business Insider / Y Combinator.

AI & GENAI, TECH & BUSINESS

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

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

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

Ogni istruzione ha un costo e un’autorità

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

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

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

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

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

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

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

Le regole si caricano solo dove servono

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

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

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

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

Le skill portano dentro la procedura al momento giusto

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

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

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

Un agente separato per il lavoro che non vuoi leggere

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

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

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

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

Gli hook girano fuori dal contesto

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

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

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

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

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

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

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

Quando l’istruzione è nel posto sbagliato

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

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

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

Un’istruzione non è una garanzia

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

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

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

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

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

AI & GENAI, TECH & BUSINESS

Vendor lock-in AI: l’errore architetturale dei progetti enterprise

Conversazione vera, due settimane fa, con il CTO di un’azienda manifatturiera italiana medio-grande. Loro hanno un sistema AI in produzione da quattordici mesi, costruito sopra le API di OpenAI con function calling, prompt engineerizzati con cura, memoria conversazionale gestita in Pinecone, agente che orchestra cinque tool diversi. Funziona bene, gli utenti sono contenti, il management è soddisfatto. Mi chiama perché ha letto i miei articoli su AI privata e vuole capire se ha senso, per loro, valutare una migrazione verso un setup on-premise con modelli open-weight.

La mia risposta è stata: “Tecnicamente sì, però oggi la migrazione vi costa quanto rifare metà del prodotto da zero”. Lui ha avuto un momento di silenzio, poi ha chiesto: “Come è possibile? Usiamo l’API standard di OpenAI. Mi avevano detto che era portabile”. La risposta a quella domanda è il tema di questo articolo. È un fenomeno che chiamo “vendor lock-in tecnico AI“, e fa fallire più progetti AI enterprise di quanti se ne discutano apertamente.

Il debito tecnico che non si vede

Le aziende che costruiscono prodotti AI sopra API cloud accumulano un debito tecnico di portabilità che non emerge nei primi mesi. Funziona tutto, perché ogni provider rispetta il proprio contratto API. Però sotto la superficie, dozzine di scelte tecniche e operative legano profondamente il prodotto al provider specifico, in modi che diventano evidenti solo quando si prova a cambiare.

Vorrei elencare i punti di lock-in più ricorrenti, in ordine crescente di gravità.

System prompt engineerizzati per quirk specifici del modello. Ogni LLM ha le sue idiosincrasie. Claude reagisce a certe formulazioni in modo diverso da GPT-4. Gemini ha pattern di risposta tutti suoi. Mistral e Llama hanno default culturali diversi. Quando il vostro team di prodotto ha lavorato 6 mesi per perfezionare prompt che funzionano bene sul modello scelto, quei prompt non funzionano più allo stesso modo se cambiate modello. La migrazione richiede re-engineering completo, con cicli di test e regression.

Function calling con sintassi proprietaria. OpenAI ha introdotto il function calling con uno schema specifico. Anthropic ha il suo formato per i tool. Gemini ha un altro ancora. Anche se tutti sono “function calling”, il modo in cui passare gli schemi, gli argomenti, le risposte è leggermente diverso. Codice che orchestra agenti complessi con dieci tool diversi è ricco di queste specificità.

Embedding model legati al provider. Se avete fatto RAG con embeddings di OpenAI ada-002 o text-embedding-3-large, quei vettori non sono compatibili con embeddings di Cohere, Voyage, BGE. Per cambiare modello di embedding, dovete re-indicizzare tutto il corpus documentale, che su grandi volumi richiede tempo e costa risorse.

Vector database con schemi rigidi. Avete usato Pinecone con metadati strutturati in un certo modo, indici composti definiti, filtri configurati. Migrare a Qdrant, Weaviate o Milvus significa rifare lo schema, validare i risultati, magari riadattare le query applicative.

Memoria conversazionale tarata sul modello. I limiti di token, le strategie di summarization, le truncation policies, sono tutti calibrati sul modello specifico. Cambiando modello, la memoria si comporta diversamente, i contesti vengono troncati in modo diverso, le conversazioni perdono coerenza in punti diversi.

Monitoring e observability legati alle API. Avete configurato logging strutturato per le chiamate OpenAI con i loro request ID, latency metrics, cost tracking basato sui loro pricing tier. Cambiare provider significa rifare l’osservabilità.

Skills del team. Il vostro sviluppatore AI senior conosce profondamente l’API OpenAI dopo due anni di lavoro. Conosce le edge case, sa come reagire ai 429, ha intuizione per i prompt che funzionano. Su un provider nuovo, quella conoscenza è azzerata. Servono mesi di learning curve.

Sommato tutto, una migrazione fra provider AI cloud su un’applicazione in produzione di 12+ mesi richiede tipicamente 2-4 mesi di lavoro di team specializzato. Quei mesi sono pieni di rischio: i clienti si lamentano dei comportamenti diversi, qualità delle risposte temporaneamente peggiore, bug che emergono solo in produzione, costi che non rientrano nei piani.

L’astrazione che salva la vita architetturale

C’è una soluzione architetturale ben nota, e si chiama “abstraction layer”. L’idea è semplice: invece di chiamare direttamente le API del provider AI, fate passare ogni interazione attraverso un layer intermedio che espone un’interfaccia stabile compatibile (tipicamente compatibile con OpenAI, perché è lo standard de facto). Il layer si occupa di tradurre nel formato del provider specifico sottostante. Quando volete cambiare provider, cambiate solo il layer, non le applicazioni.

Sembra banale, ma poche aziende lo fanno bene. La maggior parte di quelle che ho visto in advisory ha un’astrazione “leggera” che gestisce solo il routing delle chiamate al LLM, ma non astrae le altre cinque-sei superfici di integrazione (embeddings, vector DB, memoria, tools, logging). Risultato: il giorno della migrazione, scoprono che l’astrazione copre solo il 30% del problema.

L’astrazione completa deve coprire sette superfici, e qui entra il valore di un orchestratore maturo come LocalAI.io, su cui ho investito personalmente come cofondatore.

1. Chat completions. LocalAI espone l’endpoint OpenAI-compatible standard, ci puntate il vostro codice esistente, e il modello sotto può essere Llama, Mistral, Qwen, DeepSeek o anche un OpenAI/Claude pass-through. Cambiate il modello dalla console, le applicazioni continuano a funzionare.

2. Embeddings. Stessa cosa per il modello di embedding. Esponete l’endpoint embedding-compatible OpenAI, dietro c’è il modello che decidete (bge-m3, multilingual-e5, OpenAI ada). Cambiate dietro senza toccare il codice.

3. Function calling. L’orchestratore unifica le specifiche function calling fra provider diversi, traducendo in tempo reale.

4. Vector database. Qui l’astrazione è più sottile: serve un layer applicativo (LangChain, LlamaIndex, o codice custom) che si interfacci con un’API generica di vector DB. Qdrant, Weaviate, Chroma hanno tutti adapter per le librerie principali.

5. Memoria conversazionale. Va gestita in un livello applicativo che non dipenda dal modello specifico. Esistono librerie come mem0 che fanno questo lavoro bene.

6. Monitoring. Centralizzato sull’orchestratore, non sui singoli provider. Tutto il logging passa per il layer, indipendentemente da chi sta servendo le richieste.

7. Cost tracking. Anche qui centralizzato. L’orchestratore conta i token, applica le sue policy di pricing, espone le metriche aggregate.

Con un’astrazione completa di queste sette superfici, una migrazione di provider AI può ridursi a un’ora di lavoro di reconfigurazione, invece di tre mesi di refactor. È una differenza che, su un’applicazione enterprise, si traduce in 50.000-200.000 euro risparmiati ogni volta che cambiate.

Quando vale la pena pagare il costo dell’astrazione

Una nota di onestà. L’abstraction layer ha un costo iniziale. Aggiunge una dipendenza al vostro stack, un piccolo overhead di latenza (5-30ms tipicamente), un componente in più da manutenere. Per startup che stanno facendo POC veloci, è probabilmente overkill, perché il rischio di voler cambiare provider entro 6 mesi è basso e gli investimenti accumulati sono minimi.

Per le aziende enterprise che stanno costruendo un sistema AI destinato a vivere 3-5 anni, l’astrazione vale praticamente sempre l’investimento. Tre situazioni dove l’astrazione è essenziale:

Quando il modello scelto oggi non sarà quello di fra 24 mesi. L’ecosistema AI evolve velocemente. Nel 2024 OpenAI dominava. Nel 2026 Claude, Gemini, Mistral, modelli open-weight sono tutti competitivi su task specifici. Nel 2028 lo scenario sarà ancora diverso. Un’azienda che si lega oggi a un singolo provider si trova a inseguire la concorrenza con due anni di ritardo.

Quando la compliance può cambiare. Una banca italiana che oggi usa Claude potrebbe domani avere requisiti che impongono di portare il modello in casa per AI Act o evoluzioni normative. Se ha un’astrazione, la migrazione è di una settimana. Se non ha, sono 4 mesi.

Quando vi serve usare modelli diversi per task diversi. L’approccio “best model per ogni task” sta diventando standard. Claude per scrittura, GPT per reasoning, DeepSeek per codice, Qwen per estrazione strutturata, Mistral per italiano fluente. Senza astrazione, dovete integrare 5 SDK diversi. Con astrazione, è un parametro nel routing.

L’errore tipico che vedo nei progetti AI enterprise

Per chiudere, vorrei raccontare il pattern di errore più frequente che vedo nei progetti AI enterprise che falliscono. Si svolge sempre nello stesso modo, in tre fasi.

Fase 1: prototipo veloce. Il team prodotto vuole muoversi rapidamente. Chiamano direttamente l’API OpenAI, fanno il POC in due settimane, lo presentano al management. Il management è entusiasta, dà luce verde a una versione di produzione. Decisione presa: usiamo OpenAI come fornitore principale.

Fase 2: produzione e accumulo. Nei 12-18 mesi successivi, il team costruisce features sopra features. System prompt sempre più sofisticati, function calling, RAG con Pinecone, agenti multi-step. Tutto su API OpenAI. Nessuno si pone il problema dell’astrazione perché funziona tutto bene.

Fase 3: il momento di verità. Arriva una di queste situazioni: i costi OpenAI superano i budget previsti, il management chiede di portare l’AI in casa per ragioni di sovranità o compliance, un competitor si vanta di prestazioni migliori con Claude e il management vuole switchare. A questo punto il team scopre che la migrazione costa 3-4 mesi di lavoro e mette a rischio il prodotto. Si rinvia. Si rinvia ancora. Poi qualcuno decide che è meglio non toccare niente, e l’azienda resta legata al provider scelto due anni prima, anche quando non è più la scelta migliore.

Quel pattern, per me, è la singola causa più frequente di stagnazione strategica nei progetti AI enterprise italiani. La soluzione non è tecnicamente difficile (un abstraction layer maturo si setta in due settimane). È una decisione architetturale da fare presto, prima che l’accumulo di lock-in la rende troppo costosa.

Tre azioni concrete per chi sta valutando ora

Per chi sta costruendo o ha appena messo in produzione un sistema AI enterprise, tre azioni che vale la pena valutare nei prossimi 30 giorni.

Audit del lock-in attuale. Mappare quali punti del vostro stack sono legati al provider AI specifico. System prompt, embeddings, function calling, vector DB, memoria, logging, expertise del team. Quantificare quanto tempo costerebbe oggi una migrazione totale a un provider diverso. Se la stima è oltre un mese di lavoro, avete un debito tecnico che vale la pena ridurre.

Introduzione progressiva dell’abstraction layer. Non serve un big-bang refactor. Si può introdurre un’astrazione progressivamente: cominciando dalle chat completions (l’80% del traffico tipico), poi embeddings, poi function calling. In 6-8 settimane è possibile arrivare a un’astrazione completa su un sistema esistente.

Test di portabilità periodici. Anche se non avete intenzione di cambiare provider oggi, fate un esercizio: ogni 6 mesi, provate a far girare una percentuale del traffico (5-10%) su un provider alternativo via l’abstraction layer. Misura due cose: la qualità delle risposte resta accettabile, e l’astrazione regge il routing. Se sì, siete davvero portabili. Se no, scoprite dove sono i punti deboli mentre i costi della migrazione sono ancora bassi.

Per chi vuole approfondire il setup di un’architettura AI sovrana basata su abstraction layer, ho scritto questa serie di articoli: GDPR e LLM, hardware locale, TCO on-premise, scelta del modello open-weight, AI Act checklist, installazione di LocalAI, cloud sovrano italiano. Insieme coprono lo stack completo. Per una conversazione specifica sul vostro contesto, c’è la pagina Advisory.

La domanda finale, quella che cambia il futuro architetturale del vostro sistema AI, è semplice. Se domani il provider che usate oggi raddoppiasse i prezzi, deprecasse il modello che vi serve, o cambiasse i termini commerciali in modo per voi inaccettabile, in quanto tempo sareste in grado di rispondere? Se la risposta è in mesi, avete un problema architetturale che vale la pena affrontare adesso, mentre la migrazione costa ancora poco.