Aldo Prinzi's BLOG

Categoria: Automazione

  • Ho resuscitato il sogno di Feigenbaum e dei sistemi esperti

    Ho resuscitato il sogno di Feigenbaum e dei sistemi esperti

    C’è un filo che lega l’ubriacatura per l’intelligenza artificiale di oggi a un’epoca che molti conoscono solo per sentito dire: la metà degli anni Ottanta.

    Io quegli anni me li ricordo bene. C’ero.

    Ricordo l’aria del 1985, l’elettricità attorno alla sfida giapponese della Quinta Generazione, i manuali, la sensazione netta che stessimo per catturare l’intelligenza umana dentro una scatola logica. Edward Feigenbaum, da Stanford, aveva formulato un principio tanto limpido quanto radicale:

    “Il potere di un sistema intelligente non sta negli algoritmi generali di ragionamento, ma nella quantità e nella qualità delle conoscenze specialistiche che possiede.“

    Era l’era dei sistemi esperti. L’obiettivo era clonare la testa dei migliori specialisti — ingegneri, medici, periti — e tradurla in una base di conoscenza fatta di regole (SE… -> ALLORA) e in un motore inferenziale che le applicava. XCON, alla Digital, configurava i VAX meglio di molti tecnici: arrivò a oltre diecimila regole, e a una squadra intera per tenerle in piedi. Sembrava l’inizio di una rivoluzione definitiva.

    Invece arrivò il muro. Lo stesso Feigenbaum lo battezzò knowledge acquisition bottleneck: il collo di bottiglia dell’acquisizione della conoscenza: per costruire un sistema esperto servivano mesi di interviste.

    L’ingegnere della conoscenza torchiava l’esperto, gli estraeva (a fatica) le euristiche, le codificava a mano in migliaia di righe rigide. Un lavoro titanico, costosissimo e fragile: bastava un’eccezione non prevista perché il castello crollasse. E soprattutto: la macchina sapeva tutto di un mestiere e non imparava niente. Per insegnarle una cosa nuova serviva qualcuno che la scrivesse.

    Il mercato si disilluse, i budget furono azzerati, arrivò il lungo inverno dell’IA. Abbiamo archiviato tutto, convinti che quella strada fosse impraticabile.

    Salto in avanti. Anno 2026.

    Io ci sono anche qui.

    Dopo gli anni della fascinazione indiscriminata per i modelli linguistici — capaci di conversare su tutto, ma strutturalmente inaffidabili nei contesti verticali dove non è concesso sbagliare — in Canonity ci siamo fatti una domanda che per me aveva il sapore di un conto rimasto aperto per quarant’anni:

    Se un modello linguistico oggi fa l’acquisizione da solo, leggendo e strutturando moli immense di documenti, perché non riprendere il meccanismo dei sistemi esperti del 1985, ora che il collo di bottiglia è superabile?

    L’abbaglio degli ultimi tempi infatti è stato credere che bastasse dare in pasto un PDF a una chat, o costruire una pipeline RAG, per ottenere un professionista sintetico. E, spoiler, no, non funziona così. Il RAG ripesca frammenti simili alla domanda. Il linguaggio naturale senza architettura produce solo parodie probabilistiche dell’esperienza umana.

    La risposta che abbiamo costruito in Canonity parte da una formula precisa:

    La “competenza” di Canonity è il sistema esperto di Feigenbaum con l’acquisizione fatta dal modello e la curatela fatta con l’autore. È quello che avremmo voluto nel 1985, con un pezzo in più: la skill.

    Il collo di bottiglia rovesciato

    Nel nostro schema l’esperto non subisce più l’interrogatorio di un programmatore, ma semplicemente carica i documenti che ha: manuali, listini, procedure come fonti permanenti; preventivi fatti, ticket risolti come esempi. E, scometti? È il modello a fare il lavoro sporco: distilla gli esempi togliendo nomi, importi e dati riservati e tenendo ciò che insegnano; dà un verdetto a ogni documento rispetto allo scopo dichiarato; mette i documenti in relazione fra loro e trova dove si contraddicono; formalizza una prima architettura della conoscenza.

    Ma l’automazione lasciata a se stessa può inventare. Ed è qui che scatta la svolta: è l’esperto quello che valida.

    Risponde alle domande che il sistema gli propone dopo avere studiato i documenti e trovato cose che ha capito male. L’esperto decide, quando due fonti si contraddicono, quale vale. Corregge un’interpretazione con una nota, e la nota diventa parte della competenza come se fosse un documento. Approva lo schema del dominio. E prova: salva richieste vere e le fa rigirare a ogni revisione, per vedere se la competenza risponde come vuole lui, e se l’ultimo documento caricato ha peggiorato qualcosa.

    Finché non ha guardato, la competenza aggiornata non entra in esercizio.

    Non si estrae più la conoscenza col cucchiaino. Il modello costruisce l’impalcatura, l’esperto la verifica e la firma.

    Il pezzo in più: che cos’è davvero una skill.

    Nel 1985 avevamo basi di conoscenza statiche e motori inferenziali rigidi. Nel 2024 ci siamo accontentati di prompt fragili, affidati alla buona sorte della probabilità. Nel 2026 tutti vendono skill.

    Ed è giusto: una skill è una cosa seria che funziona, è la procedura: che cosa fare, in che ordine, con quali strumenti, che cosa controllare prima di consegnare, quando fermarsi. Una skill sa come si fa un lavoro.

    Quello che una skill non sa è che cosa si sa in quell’azienda: il catalogo, le regole di sconto, le eccezioni che si fanno da dieci anni e che nessuno ha mai scritto. Una skill senza competenza è un bravo professionista al primo giorno in un’azienda che non conosce. Una competenza senza skill è una biblioteca.

    Le due cose si affiancano. La skill dice come si fa; la competenza dice che cosa si sa. E la competenza è un oggetto fisico, non appartiene a nessun modello: si aggancia a quello che l’autore sceglie, e se domani lo cambia, resta.

    Un esempio: il catalogo e i cinque preventivi

    Un’azienda vende impianti su misura. Carica il catalogo tecnico e le regole di sconto come fonti permanenti, e cinque preventivi già inviati come esempi.

    L’elaborazione distilla i preventivi: via i nomi dei clienti e gli importi puntuali, restano i criteri di scelta. Poi il sistema trova una discrepanza e bussa alla porta dell’esperto:

    C’è una contraddizione: un preventivo applica il 15% di sconto, la regola dice al massimo il 10%. Era un errore o un’eccezione?

    L’autore risponde:

    Un’eccezione: vale solo per i clienti conosciuti in fiera.

    In quell’istante la risposta entra nella competenza e ci resta.

    Ora agganciamo la competenza alla skill «rispondi a una richiesta di preventivo, usando il listino di settembre 2026 (path/al/listino.xlsx)». Da quel momento ogni richiesta che entra — in chat, o da un workflow che legge la posta — esce con un preventivo coerente col catalogo, con le regole e con l’eccezione della fiera.

    E con il modello linguistico che l’autore preferisce oggi! Se domani ne esce uno migliore o più economico e lo sostituisce, la competenza non si rifà: non è del modello.

    Chiudere il cerchio

    Quarant’anni fa eravamo partiti con l’intuizione giusta e gli strumenti sbagliati. Poi abbiamo passato un decennio a credere che la forza bruta dei parametri potesse sostituire la specificità della conoscenza umana.

    Feigenbaum aveva ragione fin dal principio: l’intelligenza applicata è competenza di dominio, non generalismo. Oggi abbiamo il motore per estrarla, l’esperto per verificarla e la skill per metterla al lavoro.

    Il sistema esperto non è più una promessa incompiuta del 1985. È tornato. E stavolta impara.

  • La mezz’ora di Godwin

    La mezz’ora di Godwin

    Nel 1793 un filosofo calcolò che mezz’ora di lavoro al giorno sarebbe bastata a tutti. Oggi? Questa cosa ci terrorizza.

    Prova a dire a qualcuno che: da domani una macchina farà per te la parte noiosa del tuo lavoro. I riepiloghi, i documenti da compilare, le mail da smistare, le riunioni di allineamento (non solo il verbale…), il codice di routine.

    Lo vedrai irrigidirsi e prima ancora di chiedersi cosa fare delle ore liberate, si chiederà quanto durerà lo stipendio.

    La gente ha voglia di lavorare. In quarant’anni di mestiere ho conosciuto pochissime persone che volessero davvero non fare niente, e ne ho conosciute moltissime che non sopportavano quello che erano costrette a fare: il ripetitivo, il rendicontato, il «facciamo così perché si è sempre fatto così». Quando il lavoro ha un senso le persone lo cercano, lo difendono, ci restano fino a tardi senza che nessuno glielo chieda.

    Il paradosso è che la liberazione dalla fatica inutile, che per secoli è stata un’utopia, oggi che è raggiungibile la consideriamo una forma di minaccia. La realtà è che nel sistema in cui viviamo il lavoro eterodiretto è l’unico titolo che autorizza a mangiare e a contare qualcosa per gli altri.

    Tolta la fatica, con l’architettura attuale non avremo nemmeno il permesso di esistere.

    Mezz’ora al giorno

    Nel 1793 (più o meno 240 anni fa) William Godwin nella sua “Inchiesta sulla giustizia politica” si pose una domanda, che oggi suona attualissima: quanto lavoro serve davvero per mantenere una comunità? Non si fermò alla domanda ma fece proprio i conti e arrivò a una cifra imbarazzante. Se il lavoro manuale fosse stato distribuito equamente fra tutti gli adulti abili, eliminando le occupazioni che servivano solo al lusso di pochi e al mantenimento di apparati inutili, sarebbe bastata mezz’ora al giorno a testa.

    Per Godwin l’uomo liberato dalla fatica si sarebbe messo a studiare, a sperimentare, a rendersi utile: la curiosità e il desiderio di contribuire gli sembravano motori più forti del salario. Il tempo era, ai suoi occhi, la risorsa che la disuguaglianza sottraeva alla maggioranza per regalarla a una minoranza che viveva del lavoro altrui.

    Thomas Malthus cinque anni dopo gli rispose con un intero saggio sulla popolazione, per spiegargli che qualunque abbondanza sarebbe stata mangiata dalle nascite.

    E il dibattito è andato avanti così per due secoli.

    La stima ha fatto scuola e nel 1880 Paul Lafargue, ne Il diritto alla pigrizia, chiedeva tre ore al giorno; Bertrand Russell nel 1932, nell’Elogio dell’ozio, quattro. John Maynard Keynes nel 1930 scrisse che i suoi nipoti, intorno al 2030, avrebbero lavorato quindici ore a settimana e si sarebbero trovati davanti al vero problema: cosa fare del tempo.

    Mancano quattro anni alla scadenza di Keynes e la produttività per ora lavorata ha superato le sue stime, sebbene le ore siano rimaste più o meno le stesse.

    Dove è finito il tempo

    I guadagni di produttività ci sono stati, ed enormi. Sono andati però quasi tutti a chi possiede il capitale, sotto forma di dividendi, e molto poco a chi lavora, sotto forma di ore in meno a parità di paga.

    Poi è successa una cosa che Godwin aveva intravisto e che David Graeber ha raccontato nel 2018 con un titolo poco elegante, Bullshit Jobs: l’automazione della produzione materiale ha moltiplicato le mansioni di controllo, rendicontazione e coordinamento, lavori che chi li svolge spesso giudica inutili e che esistono soprattutto per tenere in piedi la disciplina del salario. Le occupazioni parassitarie che il filosofo voleva abolire, insomma, invece di sparire si sono vestite da ufficio.

    Chi ha letto Il riflesso e il midollo ha già incontrato Jevons: le macchine a vapore più efficienti fecero crescere il consumo di carbone invece di ridurlo. Con il lavoro di testa succede lo stesso. Ad esempio rendere la stesura di un documento o di un pezzo di codice dieci volte più veloce ha fatto esplodere la domanda di revisioni, allineamenti, versioni e conformità… e le ore? Sono rimaste le stesse.

    Lafargue aveva aggiunto l’ultimo pezzo già nell’Ottocento: nelle poche ore che gli restano, un lavoratore stanco consuma e tace.

    Il ricatto

    L’intelligenza artificiale si distingue dalle rivoluzioni precedenti per un motivo preciso: lavora sul linguaggio, sull’analisi, sul codice.

    La macchina a vapore ha sostituito i muscoli, il gestionale ha velocizzato la contabilità, questa entra nelle mansioni cognitive intermedie, riassumere, redigere, filtrare, prototipare. Esattamente la parte del lavoro che la gran parte delle persone, se potesse, lascerebbe volentieri a qualcun altro.

    Dovrebbe essere la buona notizia del secolo… E invece? Viene vissuta come una condanna perché il sistema converte ogni ora risparmiata collettivamente in un rischio individuale: meno ore necessarie, meno posti, meno titoli per sedersi a tavola.

    Ci hanno messo nella posizione di avere paura che, nel momento in cui la fatica se ne va, lo stipendio la segua.

    I numeri dicono che la gente vuole lavorare e allo stesso tempo smettere di sprecarsi. Fra giugno e dicembre 2022, in Gran Bretagna, 61 aziende e circa 2.900 dipendenti hanno provato per sei mesi la settimana di quattro giorni con il modello 100:80:100: stesso stipendio, 80% delle ore, stessa produzione attesa.

    Sembra assurdo ma alla fine il risultato è:

    • Il burnout dichiarato è sceso del 71%
    • Lo stress ridotto del 39%
    • I giorni di malattia? Due terzi meno!
    • Il fatturato medio? Cresciuto dell’1,4%…

    Alla fine 56 aziende su 61 hanno deciso di non tornare indietro e il 15% dei lavoratori ha dichiarato che nessuna cifra lo avrebbe convinto a tornare ai cinque giorni. Il lavoro è rimasto ma è aumentato il tempo per farne qualcos’altro.

    Le condizioni perché l’AI produca lo stesso effetto su scala si conoscono da tempo: orario ridotto a parità di paga, un reddito che non dipenda per intero dal posto (il reddito di base, finanziato tassando le rendite dell’automazione, è la versione più discussa) e una AI usata per togliere lavoro inutile invece che per contare i minuti di chi resta.

    Sono tre scelte politiche, e il bello è che la parte tecnica, per una volta, è già pronta.

    Le altre ventitré ore e mezza

    Godwin fece il suo conto in un’Inghilterra di campi e telai e lo presero per un sognatore. Due secoli dopo abbiamo costruito la macchina che rende quel conto credibile anche per il lavoro di testa, e la prima reazione collettiva è stata chiedere di spegnerla.

    Mi chiedo, e questa volta con paura, se sia perché la mezz’ora porta con sé una domanda scomoda, e cioè chi decide (o il non sapere) cosa fare delle altre ventitré ore e mezza.

    Chiedo: se da domani una macchina si prendesse la parte noiosa del tuo lavoro e lo stipendio restasse lo stesso, cosa faresti del tempo?

    … Ma soprattutto, quanto ci hai messo a pensare alla paga prima di pensare al tempo?

  • Il riflesso e il midollo

    Il riflesso e il midollo

    Jev, Laya e i modelli che decidono senza scrivere: cosa insegnano, anche giocando a Doom, a chi mette l’AI dentro il software.

    Il 15 settembre una startup di San Francisco ha presentato il suo primo modello e, fra le demo del lancio, lo ha messo a giocare a Doom, ovviamente il modello non vede lo schermo e non scrive una parola: riceve lo stato della partita descritto a testo, sceglie cosa fare e il marine si muove.

    Nella stessa pagina, con un’onestà che di questi tempi fa quasi tenerezza, gli autori ammettono che un bot tradizionale, senza un grammo di intelligenza artificiale, potrebbe giocare meglio.

    A Doom, del resto, nessuno chiedeva di vincere, serviva a dimostrare quello che chi scrive software sospetta da tempo, e cioè che per buona parte delle decisioni che affidiamo all’AI “stiamo pagando un romanziere per fare il centralinista” (<- Opus 5)

    Un bit a prezzo pieno

    Chiunque abbia mai messo un modello linguistico dentro un’applicazione conosce la scena: arriva un’email e bisogna capire a quale ufficio mandarla, se è qualcosa di urgente, se il cliente minaccia di andarsene, ecc. Per saperlo chiediamo a un modello addestrato a scrivere testo (saggi, codice, ecc.) di comporre un piccolo JSON, un token alla volta. Lo prendiamo e lo passiamo a un validatore per assicurarci che le parentesi siano tutte al loro posto, oltre ad altre verifiche che si trasformano in attese misurate in secondi e in token pagati a prezzo pieno.

    Facciamo tutto questo per ottenere quello che in fondo è un bit: vero/falso.

    TypeSafe AI scommette sul rovescio. Il suo modello si chiama Jev e non genera testo: gli si passa uno stato (un’email, un ticket, un oggetto JSON) insieme a una serie di domande tipizzate, e lui risponde a tutte in un solo passaggio, attaccando una probabilità a ogni risposta! Esattamente quello che serviva a chi scrive codice!

    Le domande possono essere di tre tipi, una scelta fra opzioni che decidi tu, un punteggio su una scala descritta a parole e un sì o no espresso come probabilità (che chiamano noul).

    I tempi dichiarati stanno fra 70 e 500 millisecondi, il prezzo è di 0,042 dollari per milione di token in ingresso, perchè l’uscita non si paga.

    Loro stessi parlano di if intelligenti, ed è la definizione più utile di tutto il lancio. Dietro ci sono un seed da quaranta milioni di dollari guidato da DCVC e un fondatore, Diogo Almeida, che in OpenAI ha contribuito a costruire i metodi da cui è nato ChatGPT; sulla home della sua nuova azienda si legge che i modelli addestrati in quel modo sono fatti per compiacere le persone più che per decidere in modo affidabile… E non posso che essere d’accordo.

    La promessa più ripetuta è che Jev non può allucinare. Questa cosa è vera? Beh in un senso più stretto non può restituire un valore che non esiste nello schema, perché lo schema lo scrivi tu, però può benissimo restituire il valore sbagliato. Tradotto: non ordinerà mai un piatto che non sta nel menù (allucinazione), però può ordinare quello che non volevi.

    Kahneman, il carbone e le note in fondo alla pagina

    Anche i nomi raccontano qualcosa. System One viene da Kahneman, ma chi ha letto Pensieri lenti e veloci ricorda che il Sistema 1 è anche il responsabile di buona parte dei nostri errori, rapido e sicuro di sé proprio quando sbaglia (TypeSafe lo ammette nelle FAQ, e promette di spiegare più avanti perché i suoi modelli possono fare meglio). Jev viene invece da William Stanley Jevons, l’economista che nell’Ottocento vide le macchine a vapore più efficienti far crescere il consumo di carbone invece di ridurlo: per chi vende è un piano industriale, per chi paga un avvertimento, ma pochi giorni dopo è arrivata l’alternativa aperta. Laya, di Convai Innovations.

    Licenza Apache 2.0, parla la stessa lingua di Jev, noul compreso. Il suo fondatore, Nandakishor Mukkunnoth, rivendica di averci lavorato già nel marzo 2025 con un paper sulla previsione delle vendite, con l’amarezza di chi si è visto passare davanti una startup da quaranta milioni… … …

    Sono tre modelli (inglese da 421 milioni di parametri, multilingue da 322 e una versione specializzata) con pesi sotto il gigabyte, che girano su una GPU da data center di qualche anno fa o su un Mac. La tabella in cima alla scheda è fatta per circolare: 0,766 di accuratezza contro lo 0,727 di Jev, calibrazione tre volte migliore, 32,8 millisecondi contro più di duecento.

    Poi si scorre fino a una sezione che si chiama, testualmente, Honest Limits, e va riconosciuto che l’hanno scritta loro. Lo 0,766 appartiene alla versione addestrata sulla parte di training dello stesso benchmark su cui viene misurata, mentre i modelli di base fanno peggio di chi risponde sempre con l’opzione più frequente.

    La calibrazione da record arriva dopo aver ritarato il modello, che così come viene distribuito è più sicuro di sé del dovuto. I numeri di Jev sono presi da terzi, con campioni e domande diverse, e i 32,8 millisecondi sono calcolo locale su GPU contro una chiamata di rete verso la costa ovest degli Stati Uniti, dove TypeSafe tiene il servizio.

    Resta poi da chiedersi cosa misurino davvero questi test.

    L’accuratezza di TypeSafe è l’accordo con la media di GPT-6 Astra e Fable 5.1, e il riferimento del benchmark su cui gioca Laya è un modello maestro che concorda con se stesso nel 73,5% dei casi: i modelli veloci vengono giudicati da quanto somigliano a quelli lenti, e battere il maestro dopo aver studiato sui suoi compiti è un bel risultato, ma è un’altra cosa rispetto a battere la realtà.

    Nei benchmark completi c’è anche un numero che ci interessa: nel test sulle intenzioni con venti opzioni, il modello multilingue indovina l’italiano una volta su due, contro l’82% del modello inglese sull’inglese. Il riconoscimento dei jailbreak, su dati mai visti, si ferma fra il 71 e il 76% di risposte giuste e TypeSafe avverte che un testo scritto apposta dentro lo stato può spostare la risposta.

    Quis custodiet ipsos custodes, chiedeva Giovenale, e la domanda vale anche per i modelli blasonati, per i modelli che scappano, ecc. Ma questa è un’altra storia.

    Chi ha vinto davvero a Doom

    Doom, intanto, è diventato il banco di prova non ufficiale di entrambi e il test più istruttivo è un deathmatch in cui Laya ha battuto Jev cinque round a uno, prendendo il doppio delle decisioni perché in locale rispondeva prima.

    Nessuno dei due vede un pixel: è il codice a leggere il gioco, a riassumerlo in poche righe e a trasformare la risposta in tasti premuti.

    Fra i modelli e il gioco, poi, c’era uno scudo, uno strato di codice deterministico uguale per tutti e due che blocca gli spari senza munizioni o senza bersaglio, devia i passi contro i muri e sblocca il giocatore quando resta incastrato. Ha corretto l’88% delle decisioni di Laya e il 31% di quelle di Jev, che sbagliava meno ma arrivava tardi e sparava su una scena già cambiata.

    Una partita di ventisei secondi non dimostra niente in generale, pone però la domanda giusta, quella sulla correttezza delle risposte alla massima velocità. Esiste un progetto di drone costruito attorno a Jev: il controllo di volo gira a 500 cicli al secondo ed è codice e Jev dà consigli due volte e mezza al secondo.

    In biologia funziona allo stesso modo.

    Il corpo umano è costruito sullo stesso schema. Se appoggiamo la mano su una stufa accesa, la ritiriamo prima ancora di sentire il dolore: il segnale non fa in tempo a salire al cervello, perché l’arco riflesso si chiude nel midollo spinale che comanda ai muscoli per conto suo. Il cervello viene informato dopo, a mano già salva. Lo scudo di Doom e il riflesso del drone fanno esattamente questo: rispondono senza pensare, e ovviamente arrivano in tempo.

    Vale anche per Laya, che pure è nata per sapere quanto fidarsi di sé. Davanti a un testo in khmer, il modello inglese non esita: sbaglia risposta con una confidenza del 95%, perché l’alfabeto che ha davanti non lo ha mai visto e non ha modo di saperlo. Nessuna soglia di confidenza lo fermerebbe, visto che la confidenza è proprio la cosa sbagliata.

    A salvarlo è un frammento di Python che precede il modello: guarda in che alfabeto è scritto il testo, ci mette mezzo millisecondo, e lo instrada al checkpoint giusto. Anche qui la decisione importante la prende una regola… che l’intelligenza l’ha derivata dal cervello del suo creatore.

    La domanda è il programma

    Si legge adesso che con questi modelli il prompt engineering dovrebbe sparire, ma come al solito i giornalisti dovrebbero imparare prima di scrivere perchè succede esattamente il contrario.

    Nella pagina che dedica ai difetti di Jev, TypeSafe scrive che il modello prende le domande alla lettera, risponde a quella che hai scritto e non a quella che intendevi. Raccomanda di non chiedergli ciò che il codice sa calcolare e di non nascondere più giudizi in una sola domanda.

    Nel mio libro sul fare domande all’AI sostengo (tesi ormai oggi divenuta dottrina) che la qualità della risposta dipende da come è posta la domanda. Con un modello generativo una domanda mal posta si può ancora correggere leggendo la risposta, qui no: la risposta è un numero secco, senza spiegazioni da cui capire dove abbiamo sbagliato. Inoltre ogni domanda va scritta come si scrive una riga di codice, perché è una riga di codice. Chi programma con Jev passa il tempo a scomporre i giudizi in domande semplici e a decidere quali lasciare al modello e quali no.

    Il risparmio è reale, ma va letto per intero.

    Chi ha costruito un agente che usa il computer mettendo Jev al posto di un modello di frontiera ha misurato 0,0002 dollari a decisione contro 0,032, cioè centosessanta volte meno. La stessa persona ha però annotato che ogni ragionamento intermedio che il modello grande faceva da solo, e gratis, ha dovuto riscriverlo a mano come codice deterministico. I token costano meno perché una parte del lavoro è tornata al programmatore.

    Da qui passa la scelta fra i due, Jev regge fino a 255 opzioni (oltre una certa soglia lavora in due passaggi, lo spiegano loro, ma 255 opzioni possono sembrare “abbastanza”), accetta 64K token fra stato e domande, funziona senza addestramento e rallenta poco quando le domande aumentano; in cambio i dati partono per l’America, il servizio è in accesso anticipato e sul prezzo sono loro stessi a dire di non poter dimostrare che non sia sussidiato.

    Laya gira in casa nostra (e per chi tratta dati sensibili non è un dettaglio) ma va addestrato sui nostri casi e ritarato sui nostri dati prima di credere alle sue probabilità, vuole meno di una ventina di opzioni per domanda e nella configurazione standard del modello inglese legge circa 320 token di stato, una mail e non un contratto.

    Ovviamente il costo zero è quello della licenza; la GPU, chi la gestisce e chi prepara gli esempi restano a carico vostro.

    Abbiamo “trovato finalmente un centralinista da mettere al posto del romanziere?” (<- sempre Opus 5). Potrebbe essere una buona notizia per chiunque abbia l’AI in produzione e debba far quadrare i conti, ma nella partita vinta cinque a uno quasi nove decisioni su dieci del vincitore le ha corrette un pezzo di codice che di intelligenza artificiale non sa niente.

    Siamo all’inizio, chissà come sarà nel 2030, ma al momento la medaglia, se proprio va assegnata, spetta a lui: il riflesso, alla fine, l’ha avuto il midollo.

  • Il software a buon mercato e l’illusione del “localhost”.

    Il software a buon mercato e l’illusione del “localhost”.

    Perché l’AI ha reso facile iniziare, ma non finire.

    Sento ripetere spesso una narrazione stanca, divisa tra due estremismi opposti: da una parte l’entusiasmo di chi giura che l’ingegneria del software sia morta e che chiunque possa riscrivere un’intera infrastruttura complessa con tre prompt; dall’altra, il cinismo di chi liquida tutto come una truffa generatrice di codice spazzatura.

    La verità, come accade quando la tecnologia incontra la dura legge dell’economia reale, è più netta. L’intelligenza artificiale ha abbattuto una parte importante del costo di creazione del software, soprattutto nella fase iniziale di prototipazione. Ma non ha abbattuto automaticamente i costi di produzione reale: la sicurezza, la distribuzione, la manutenzione, la conformità e l’acquisizione dei clienti.

    Il punto centrale è questo: oggi è molto più facile generare codice, ma non è diventato molto più facile costruire un prodotto affidabile.

    I dati non sono opinioni

    Non commettiamo l’errore di pensare che il vibe coding — lo stile di programmazione in cui lo sviluppatore detta requisiti in linguaggio naturale e delega interamente la scrittura del codice all’IA — sia una moda passeggera o un fenomeno marginale. Le piattaforme di AI coding stanno crescendo a velocità eccezionali, ridefinendo le metriche finanziarie del settore software.

    Pensiamo a Lovable, arrivata a centinaia di milioni di ARR in pochissimi mesi, a Replit, che punta apertamente al miliardo di ricavi dopo il lancio del suo AI Agent, o a Cursor (Anysphere), ormai indicata come l’emblema di questa accelerazione. Anche i comportamenti del mercato lo confermano: secondo i dati di Sensor Tower e Wells Fargo, i rilasci di nuove applicazioni iOS nel 2025 sono aumentati sensibilmente, spinti proprio dalla straordinaria accessibilità degli strumenti generativi.

    Tuttavia, la crescita degli strumenti non si traduce automaticamente nel successo dei prodotti generati.

    In molti cercano di spiegare l’alto tasso di abbandono dei progetti sostenendo che, poiché solo una piccola parte della popolazione sa usare davvero questi strumenti (circa l’1%), allora il 99% dei progetti fallisce. È una tesi interessante, ma espressa in modo troppo meccanico: confonde due metriche diverse. Il problema non è chi usa lo strumento, ma dove si ferma il progetto.

    La realtà è che moltissimi progetti restano bloccati nel limbo che separa la demo dalla produzione. Funzionano magnificamente sul proprio computer (“localhost”), sembrano convincenti in una schermata o in un video di trenta secondi sui social, ma falliscono quando devono incontrare il mondo vero: gestire utenti reali, pagamenti sicuri, permessi, dati personali, logging, scalabilità e continuità operativa.

    Il vibe coding riduce il costo di scrittura iniziale, non il costo totale del software. Il software non è solo codice: è architettura, sicurezza, reputazione, assistenza e responsabilità. Per questo, in un mondo in cui il codice diventa abbondante e a costo marginale quasi nullo, il vantaggio competitivo si sposta verso ciò che il codice da solo non può risolvere: i canali commerciali, il brand, la fiducia, la SEO e la comprensione profonda del problema. Il codice diventa infinito; l’attenzione degli utenti, invece, resta una risorsa scarsissima.

    La trappola dell’8%: perché non riscriverete l’ERP con un prompt

    Anche sul piano aziendale, dobbiamo evitare gli estremismi. La tesi secondo cui ogni media o grande impresa potrà riscriversi internamente l’ERP, il CRM o il sistema di payroll semplicemente affidandosi a qualche prompt è debole.

    Anish Acharya, general partner di a16z, ha sollevato un punto fondamentale: la spesa per lo sviluppo software rappresenta storicamente solo una quota limitata dei costi complessivi aziendali, circa l’8-12%.

    Usare l’intelligenza artificiale per ricostruire da zero sistemi delicati e complessi come il payroll o l’ERP aziendale per risparmiare una frazione di quella percentuale espone l’azienda a rischi operativi intollerabili, a fronte di risparmi del tutto modesti.

    La conclusione corretta non è rifiutare l’AI, ma non usarla dove il rischio supera di gran lunga il beneficio. L’AI ha senso quando accelera i processi dei team competenti, quando integra workflow frammentati o quando costruisce strumenti interni controllati.

    Lo studente che si corregge il compito da solo

    Il problema più serio del vibe coding ingenuo non è la quantità di codice prodotto, ma la qualità del codice che sopravvive nei repository aziendali.

    Le ricerche sulla sicurezza indicano che il codice generato da AI può apparire perfettamente funzionante a una prima verifica visiva, nascondendo al contempo vulnerabilità gravi.

    Veracode ha rilevato che circa il 45% del codice generato da modelli AI contiene debolezze strutturali legate alle OWASP Top 10, con criticità particolarmente alte su Cross-Site Scripting (XSS) e log injection.

    Il rischio non è teorico e chiedere a un modello di verificare la sicurezza del codice che esso stesso ha generato equivale a far valutare l’esame allo studente che lo ha appena sostenuto. Senza test indipendenti e controlli esperti, si finisce per mettere online sistemi intrinsecamente fragili.

    Gli incidenti reali lo confermano. Il caso Orchids — dimostrato in un test reale con un giornalista della BBC — ha evidenziato come una piattaforma di vibe coding possa esporre vulnerabilità zero-click molto gravi se il modello di sicurezza non viene presidiato con competenza.

    Anche le recenti tensioni tra Apple e i creatori di questi strumenti ne sono la prova. La Linea Guida 2.5.2 dell’App Store vieta esplicitamente alle app di scaricare, installare o eseguire codice dinamico che modifichi le funzionalità dell’app approvata in fase di review. Le piattaforme che permettono di generare ed eseguire codice direttamente dentro l’ambiente mobile entrano in conflitto strutturale con questo modello di controllo.

    Va corretta, però, una forzatura che si legge in giro: le rimozioni massive dagli store non possono essere attribuite interamente al vibe coding. Google e Apple rimuovono costantemente milioni di app per violazioni di policy, spam, frodi o obsolescenza. I numeri sono reali, ma usarli come prova diretta della “spazzatura da vibe coding” è una correlazione debole e fuorviante.

    Dall’atmosfera al rigore: l’Ingegneria Agentica

    La vera distinzione che dobbiamo fare oggi non è tra chi usa l’AI e chi non la usa, ma tra il vibe coding ingenuo e l’ ingegneria assistita da AI.

    Il primo approccio è un atto di fede: generare, accettare e distribuire codice senza comprendere la logica sottostante. Il secondo è un processo rigoroso e controllato: gli agenti operano all’interno di una cornice protetta da specifiche (come un file di pianificazione strutturato), vincoli architetturali, test comportamentali end-to-end (E2E), gestione sicura dei segreti, database protetti (ad esempio tramite Row Level Security) e analisi statica e dinamica (SAST/DAST).

    Andrej Karpathy, che ha contribuito a diffondere l’espressione vibe coding, ha recentemente riconosciuto che quella fase puramente intuitiva sta lasciando il passo a qualcosa di più serio: l’ Ingegneria Agentica.

    E anche qui, la parola chiave non è autonomia totale, ma orchestrazione.

    Il programmatore professionista non scompare affatto; al contrario, assume un ruolo ancora più centrale.

    I Senior Dev rimangono la vera scialuppa di salvataggio delle aziende tecnologiche. Smettono di essere meri dattilografi di sintassi per diventare architetti, revisori e garanti della sicurezza, capaci di definire meglio gli obiettivi, i vincoli logici, l’architettura e i criteri di accettazione dell’opera.

    La lezione strategica

    Il vibe coding ha vinto come interfaccia di prototipazione rapida, ma ha perso come illusione di poter sostituire l’ingegneria del software. È uno strumento straordinario per dare forma visiva a un’idea, per validare un MVP o per creare piccole utilità e script interni in un ambiente controllato.

    Diventa pericoloso quando viene scambiato per un processo completo di sviluppo production-grade.

    Il futuro non sarà “tutti programmatori senza competenze” e non sarà nemmeno “l’AI è inutile perché produce codice sporco”. Il futuro è un modello ibrido: molte più persone potranno iniziare a creare software, ma solo chi saprà governare, verificare, rendere sicuro e mantenere il codice generato riuscirà a produrre valore reale.

    In sintesi: l’AI ha reso il software infinitamente più facile da iniziare, non più facile da finire. Ha ridotto la distanza tra l’idea e il prototipo, ma ha reso ancora più evidente la distanza tra il prototipo e il prodotto.

    La competenza del futuro non sarà scrivere ogni riga a mano; ma sapere cosa chiedere, cosa rifiutare, cosa verificare e cosa non mettere mai, per nessun motivo, in produzione senza un controllo di qualità.

  • Il modello più sicuro di sempre, spento un venerdì pomeriggio

    Il modello più sicuro di sempre, spento un venerdì pomeriggio

    Cosa insegna davvero il caso Fable 5 a chi costruisce qualcosa sopra un’AI che non controlla.

    Venerdì 12 giugno, ore 17:21 sulla costa Est,Anthropic riceve una lettera. Poche ore dopo, chi stava lavorando con Claude Fable 5 — il modello pubblico più potente che l’azienda avesse mai messo in commercio — si trova davanti a un errore secco:

    «Claude Fable 5 is not available. Please use Opus 4.8.»

    Avevi un’auto sportiva? Eccoti l’elettrica da città, per decreto.

    La lettera arriva dal Dipartimento del Commercio americano. Secondo Axios l’ha inviata il segretario Howard Lutnick a Dario Amodei: export control, sicurezza nazionale, divieto di accesso a Fable 5 e Mythos 5 per qualsiasi cittadino straniero, dentro o fuori dagli Stati Uniti. Siccome separare in tempo reale gli stranieri dal resto degli utenti non si può, Anthropic fa l’unica cosa possibile per essere in regola: stacca tutto, per tutti, in tutto il mondo. Gli altri modelli restano accesi.

    Fin qui la cronaca. Poi arriva il comunicato di Anthropic, ed è lì che le cose si fanno interessanti.

    Nel giro di poche righe l’azienda ci spiega che le protezioni di Fable sono «sostanzialmente più efficaci di qualsiasi modello mai rilasciato prima», testate per migliaia di ore insieme allo stesso governo americano e all’istituto britannico per la sicurezza dell’AI. E, nello stesso comunicato, ci dice che quel governo le ha ritenute abbastanza pericolose da spegnere il modello a centinaia di milioni di persone in una sera.

    Delle due, una, o i safeguard non erano così solidi, o il processo che li ha fermati non guarda i numeri. “Tertium non datur” dicevano i latini. ma Anthropic vorrebbe che credessimo ad entrambe le cose, contemporaneamente.

    C’è poi la difesa tecnica, e qui il ragionamento si morde la coda: il jailbreak, dicono, è stretto e non universale. La stessa capacità la tiri fuori anche da GPT 5.5, che però sotto export control non ci finisce. Probabilmente è vero, ma «non siamo pericolosi noi, lo è tutto il settore» non assolve nessuno: conferma soltanto che l’industria intera mette in circolo capacità che i governi non sanno governare, e che il confine tra “modello sicuro” e “modello da sequestrare” lo traccia una lettera tra pezzi grossi, non un benchmark.

    Ma c’è il dettaglio che quasi nessuno sottolinea, Mythos, il modello che sta sopra Fable, nasce come strumento di ricerca sulla sicurezza: serve a trovare e chiudere falle. Stando alle cronache, Mozilla ne ha sistemate a centinaia proprio grazie a lui e la stessa identica capacità che ieri tappava i buchi, oggi è la ragione del divieto.

    Il dual-use non è un incidente: è la natura della cosa. Un coltello affetta il pane e affetta anche un dito. La novità è che adesso lo Stato te lo può sequestrare via email, un venerdì qualsiasi.

    Ultima sfumatura, sempre da Axios: a muovere il Dipartimento del Commercio sarebbe stata un’altra azienda, che avrebbe dichiarato di aver “bucato” Mythos. Se è andata così, abbiamo un precedente nuovo di zecca. Nella corsa all’AI non ci si sfida più solo a colpi di benchmark: ci si sfida a colpi di segnalazione. La concorrenza con la carta intestata del ministero.

    Ma la parte che dovrebbe interessare a chi costruisce qualcosa — un prodotto, un servizio, un’azienda — non è chi abbia ragione tra Anthropic e Washington. È un’altra, ed è semplice.

    A quanto pare è la prima volta che un’AI pubblica viene spenta per ordine di un governo, e la lezione non riguarda Anthropic: riguarda noi tutti se la nostra roba gira sopra un solo modello, di un solo fornitore, sotto una sola giurisdizione… che non è la nostra.

    Non conta quanto siamo bravi, quanto paghiamo, basta una lettera che non hai scritto e non puoi nemmeno leggere, e il tuo “modello più potente del mondo” diventa un 404. In tutto il pianeta e senza alcun preavviso.

    Con un cortese suggerimento di ripiego: usa Opus 4.8.

    Noi italiani questa storia la conosciamo a memoria, abbiamo costruito l’Elea e la Programma 101 quando gli altri ci stavano ancora pensando, e poi abbiamo deciso che il futuro si faceva altrove. Dipendere da una tecnologia che non controlli è una scelta che si paga sempre. Di solito la paghi piano. Stavolta è bastata una sera.

    Anthropic dice che è un malinteso e che sta lavorando per riaccendere tutto ed è sicuramente vero, probabilmente tornerà tutto come prima, ma il punto non è se Fable 5 si riaccende stasera o domani, il punto è che adesso sappiamo quanto è fragile il “per sempre” su cui in tanti hanno appoggiato la loro attività.

    Il modello più sicuro di sempre. Spento in un pomeriggio.

    Il piano B è Canonity.

  • Sequoia dice che i servizi saranno il nuovo software. Canonity nasce esattamente per questo.

    Sequoia dice che i servizi saranno il nuovo software. Canonity nasce esattamente per questo.

    Recentemente Sequoia Capital ha pubblicato un articolo molto interessante: “Services: The New Software”. (LINK)

    La tesi è semplice ma dirompente: la prossima generazione di aziende AI non venderà software ma lavoro eseguito dall’intelligenza artificiale.

    La prossima azienda da mille miliardi sarà un’azienda software che si presenta al cliente come un fornitore di servizi. Non vende il tool ma il lavoro fatto. Tu non compri il software di contabilità, compri la contabilità chiusa. Il software è sotto il cofano, il cliente vede solo il risultato.

    La tesi è semplice ma dirompente: la prossima generazione di aziende AI non venderà software ma lavoro eseguito dall’intelligenza artificiale. In pratica per anni abbiamo costruito strumenti quali CRM, Contabilità, Tool di Marketing, tutti strumenti che aiutano le persone a fare il lavoro.

    Adesso però l’AI cambia il paradigma, non si tratta più di software che aiuta a lavorare, si tratta di software che fa il lavoro, sia quello noioso e ripetitivo, sia quello di analisi.

    Ma ogni founder si fa la stessa domanda: cosa succede quando la prossima versione di Claude o GPT, o Gemini rende il mio prodotto inutile? E ha ragione a preoccuparsi se vende lo strumento, ogni aggiornamento mangerà quote.

    Ma se vendi il lavoro fatto, ogni miglioramento del modello rende il tuo servizio più veloce, più economico e più difficile da battere… E se i modelli sono più di uno la partita è vinta “a tavolino”.

    L’AI ha imparato a parlare. Ora deve imparare a lavorare.

    Il claim di Canonity nasce proprio da questa idea:

    “L’AI ha imparato a parlare. È ora di insegnarle a lavorare.”

    Negli ultimi anni abbiamo visto modelli sempre più capaci di conversare. Ma “chattare” non è lavorare, il vero salto avviene quando l’AI viene inserita in workflow capaci di produrre risultati concreti.

    Sequoia divide il lavoro umano in due strati.

    Intelligence è eseguire regole complesse: tradurre specifiche in codice, testare, fare debug. Le regole sono tante ma sono regole — l’IA le impara.

    Judgement è decidere cosa costruire: quale feature ha priorità, se accettare debito tecnico, quando rilasciare anche se non è perfetto. Richiede esperienza, gusto, intuizione — anni di pratica.

    Da prompt a servizi

    Oggi chiunque può scrivere prompt o progettare workflow AI, ma questi prompt sono prodotti vendibili? No, sono semplicemente istruzioni.

    Canonity prova a cambiare questo paradigma permettendo a chiunque di:

    • creare un workflow AI
    • pubblicarlo nel marketplace
    • farlo utilizzare da altri
    • guadagnare ogni volta che viene eseguito

    Il punto chiave è questo: su Canonity non si vendono prompt.
    Si vendono esecuzioni.

    Alcuni esempi concreti? Immaginiamo alcuni servizi pubblicati nel marketplace Canonity.

    Analisi CV e job posting

    Un creator costruisce un workflow che:

    • analizza un annuncio di lavoro
    • analizza il curriculum del candidato
    • identifica competenze rilevanti
    • genera una lettera di presentazione personalizzata

    L’utente carica CV e job posting, Canonity restituisce la lettera pronta e il creator guadagna ogni volta che il workflow viene eseguito.

    Analisi del naming di una startup

    Un altro workflow potrebbe:

    • analizzare il nome della startup
    • confrontarlo con missione, prodotto e mercato
    • valutare coerenza e memorabilità
    • proporre alternative di naming più efficaci

    L’utente non compra un prompt, ma l’analisi prodotta dall’esecuzione del workflow.I

    La nascita di una execution economy

    Molti marketplace AI oggi vendono:

    • prompt
    • template
    • librerie di istruzioni

    Canonity propone qualcosa di diverso: una execution economy.

    Un luogo dove le persone pubblicano soluzioni AI
    e vengono pagate per ogni utilizzo reale.

    Perché ascoltare Sequoia

    Quando Sequoia Capital parla di nuove categorie tecnologiche, vale sempre la pena ascoltare. Nel loro portfolio ci sono aziende come:

    • Apple
    • Google
    • Airbnb
    • WhatsApp
    • NVIDIA

    E quando descrivono un cambiamento strutturale del mercato, vanno ascoltati perché spesso stanno anticipando ciò che accadrà nel prossimo decennio.

    Se i servizi sono il nuovo software

    Se davvero i servizi saranno il nuovo software, allora servirà un luogo dove questi servizi AI possano:

    • nascere
    • essere distribuiti
    • essere utilizzati
    • essere monetizzati

    Canonity prova a costruire esattamente questo: un posto dove chiunque può trasformare un’idea, un prompt o un workflow in un servizio AI eseguibile.

    Perché il vero valore non è nel prompt, ma nell’esecuzione.

  • Canonity e u-prompt: trasformare un’idea in un’app e monetizzarla.

    Canonity e u-prompt: trasformare un’idea in un’app e monetizzarla.

    Voglio prendermi un momento per raccontarvi cosa stiamo costruendo, partendo da un esempio concreto che mi è capitato proprio oggi.

    Tutto ha inizio quando un amico decide di imbarcarsi in una nuova avventura: un nuovo progetto per un nuovo prodotto. Come spesso accade a chi ha tra le mani un MVP (Minimum Viable Product), la prima cosa che ha fatto è stata battezzarlo con un nome che riteneva evocativo.

    Tuttavia, la mia esperienza mi suggeriva che quella scelta non fosse quella giusta per il suo target e invece di dargli un semplice parere soggettivo, ho deciso di creare un workflow di prompt che aiutasse chiunque a capire se il nome scelto per il proprio business sia davvero quello corretto.

    L’esperimento: 11 prompt e 5 modelli

    L’idea è semplice: tu mi dici cosa fa il prodotto e come vuoi chiamarlo; io ti restituisco un’analisi approfondita di costi e benefici, fornendoti anche una “storia” da raccontare quando ti chiederanno il perché di quel nome.

    Per realizzare questa analisi, ho aperto Canonity, il nostro editor grafico di step-prompt e ho strutturato il lavoro in tre passaggi fondamentali:

    1. Limitare le allucinazioni: Se chiedi troppe cose insieme a un’IA, tende a inventare ciò che non capisce, quindi ho diviso il processo di analisi in più step per aumentare drasticamente la precisione.
    2. Il potere del confronto: Ho replicato i passaggi di analisi sfruttando la capacità di modelli diversi per avere più punti di vista. Ho sottoposto la prima analisi a Grok, la successiva a Claude e poi anche a Gemini.
    3. Sintesi e Revisione: Infine, ho usato ChatGPT per riepilogare il tutto e DeepSeek per analizzare i pareri dei vari modelli e generare un riassunto finale.

    In totale, l’analisi di un singolo nome è stata suddivisa in 11 prompt eseguiti da 5 modelli diversi che hanno collaborato tra loro.

    Ho stampato il PDF dopo averlo eseguito e l’ho inviato al mio amico che… ha validato l’utilità di questo prompt.

    (Il sistema non si è limitato a dire se il nome fosse corretto, le tre cancellazioni in rosso erano tre esempi di nome alternativo più corretto, in relazione a ciò che quel prodotto fa) Del chè il messaggio del mio amico:

    La prova del nove (anzi del 4,99)

    La sua risposta è stata la migliore validazione possibile: non solo ha trovato l’analisi incredibilmente centrata — evidenziando aspetti critici come il costo del dominio o l’efficacia psicologica del nome — ma alla mia domanda provocatoria “Saresti stato disposto a pagare 4,99€ per questo?”, la risposta è stata un secco: “Ceeerto!”

    Cosa sono, quindi, Canonity e u-prompt?

    In poche parole:

    • Con Canonity ho realizzato l’applicazione (il workflow logico di analisi).
    • Attraverso u-prompt, ho messo in vendita l’esecuzione di quel workflow al prezzo di 4,99€.

    E questo è solo uno dei workflow –> app. Il sistema ne gestirà centinaia, migliaia, ogni utente ne potrà avere quante ne vuole… Saranno di sua proprietà e non dovrà mai vendere il prompt, solo l’esecuzione.

    Per esempio il nostro CEO, Stefano, sta già usando Canonity per disegnare un sistema che analizza i CV in relazione ai Job Post. L’app analizzerà l’annuncio, valuterà il tuo profilo/CV, ti suggerirà cosa enfatizzare e produrrà una lettera di presentazione adattata e su misura.

    Una volta pronta, la metteremo in vendita su u-prompt a 2,99€.

    Cosa ti serve per creare il tuo primo step prompt?

    Serve conoscenza tecnica dello strumento? Si, c’è un tutorial che in 7 passi (5/6 minuti) ti spiega come funziona

    Quale altra conoscenza tecnica serve? Nessuna, se hai scritto il prompt, premendo PLAY lo esegui e ottieni il risultato.

    FINE.

    Se vuoi capire come trasformare la tua competenza in un’app IA, o se hai domande su come funzionano i nostri strumenti, scrivici a hey [chiocciola] u-prompt.com.

    Il futuro è collaborativo

  • Il grande democratizzatore

    Il grande democratizzatore

    Opus 4.6, un meetup a Milano, e cosa c’entrano Camillo e Adriano Olivetti con l’IA

    Ieri sera ero al Claude Code meetup di Milano. Cinque speaker, cinque soluzioni da mostrare. Il primo sale sul palco, lancia la sua demo e… niente. Opus 4.5 risulta legacy. Il modello su cui aveva costruito tutto era già stato sostituito — durante l’aperitivo. Il secondo non ha nemmeno potuto presentare: la sua soluzione di sicurezza? Opus 4.6 la implementava già nativamente.

    Due presentazioni su cinque, obsolete nel tempo di un prosecco.

    Questo è il ritmo. Ma non è del ritmo che voglio parlare oggi.

    Perché tra quelle cinque presentazioni ce n’erano due che mi hanno colpito più del cambio di modello. E mi hanno fatto pensare a qualcosa di molto più grande.

    Il primo era un fotografo. Non un tecnico, non un ingegnere del software, non uno che ha mai scritto una riga di codice in vita sua. Un fotografo che in tre mesi e mezzo ha costruito un’applicazione per creare presentazioni alla velocità della luce. Funzionante. Bella. Che fa quasi tutto quello che fa Gamma — un prodotto su cui lavorano probabilmente decine di ingegneri a tempo pieno.

    Il secondo era un avvocato. Stesso schema: nessuna formazione tecnica. Ha preso decenni di esperienza nella revisione dei contratti e li ha trasformati in un’applicazione capace di riscrivere clausole prolisse, spiegando paragrafo per paragrafo il perché di ogni scelta di revisione. Non un riassunto generico, una revisione ragionata, con la competenza di chi quei contratti li mastica da vent’anni.

    Nessuno dei due sa programmare.

    Entrambi hanno costruito qualcosa che funziona.

    Qui si apre il punto che mi interessa davvero.

    Perché non hanno fatto vibe coding. Il vibe coding è quella cosa per cui apri una chat, scrivi “fammi un’app che fa X”, e speri che il risultato sia decente. A volte lo è. Spesso no. E quando non lo è, non sai perché e non sai come aggiustarlo.

    Questi due hanno fatto qualcosa di diverso. Hanno seguito il metodo: architettura, obiettivi, percorso.

    Il fotografo non ha detto “fammi un’app per le presentazioni”. Ha pensato a cosa gli serviva, ha progettato la struttura, ha definito il flusso. Poi ha usato l’AI come strumento per realizzare quello che aveva in testa. L’avvocato non ha detto “riscrivi questo contratto”. Ha codificato decenni di know-how in regole, logiche, criteri di valutazione. Poi ha chiesto all’AI di eseguire quel processo.

    La differenza tra vibe coding e il metodo è la stessa differenza che c’è tra chiedere a un muratore di “farmi una casa bella” e dargli un progetto architettonico.

    Il risultato si vede.

    L’AI è il grande democratizzatore.

    Non perché abbassa il livello, ma perché rimuove la barriera tra chi ha le competenze e chi ha anche gli strumenti per esprimerle.

    Il fotografo sapeva esattamente come doveva funzionare un sistema di presentazioni rapide. Lo sapeva meglio di qualsiasi team di ingegneri, perché lo viveva tutti i giorni. Quello che non sapeva era tradurre quella conoscenza in codice.

    L’avvocato sapeva esattamente cosa rende un contratto prolisso e cosa lo rende chiaro. Lo sapeva meglio di qualsiasi algoritmo, perché ci ha passato la carriera. Quello che gli mancava era il mezzo tecnico per trasformare quell’esperienza in un prodotto.

    Fino a ieri, queste persone avevano due opzioni: pagare qualcuno per costruire la loro idea (con tutti i problemi di traduzione che ne conseguono) o rinunciarci.

    Oggi ne hanno una terza: costruirla loro stessi.

    Non perché “tutti possono programmare” — questa è la retorica vuota. Ma perché chi ha una competenza reale, una visione chiara e la disciplina di pensare in modo strutturato, oggi può realizzarla. L’AI elimina la barriera sintattica, non quella intellettuale. E la barriera intellettuale è l’unica che conta davvero.

    A questo punto devo fare una confessione.

    Io sono un tecnico. Scrivo codice da quando avevo un Toshiba al plasma e il QBASIC era il linguaggio dei sogni. Ho certificazioni Microsoft degli anni ’90. Gestisco cluster Proxmox distribuiti su datacenter europei. So cosa vuol dire debuggare un segfault alle tre di notte.

    Ma sono anche un imprenditore. E come imprenditore, il mio idolo non è Steve Jobs, non è Elon Musk, non è nessuno della Silicon Valley.

    Il mio idolo è Camillo Olivetti.

    Un ingegnere di Ivrea che nel 1893 andò a Chicago con il suo maestro Galileo Ferraris, visitò i laboratori di Edison, e tornò in Italia con un’idea che oggi suona rivoluzionaria quanto allora: il compito di un’azienda non è sfruttare le capacità delle persone, ma elevarle.

    Camillo fondò la prima fabbrica italiana di macchine per scrivere nel 1908. Venti dipendenti, un capannone a Ivrea. Sì, la macchina per scrivere fu una democratizzazione — della parola scritta, dell’accesso alla comunicazione formale. Ma non era quello il punto. Il punto era la visione che c’era dietro la fabbrica.

    Camillo non vedeva i suoi operai come manodopera da ottimizzare ma come persone da far crescere. Riuniva i dipendenti nel cortile della fabbrica, saliva su una cassetta — come ai tempi dei comizi socialisti — e spiegava i problemi dell’azienda. Non delegava, non nascondeva: condivideva la conoscenza. Voleva che capissero il perché delle decisioni, non solo il cosa dovevano fare.

    Quando la crisi economica colpì, propose di ridurre l’orario per tutti piuttosto che licenziare qualcuno. I dipendenti risposero proponendo di lavorare a tempo pieno, con la promessa di recuperare il salario mancante a crisi finita. Questo non succede in un’azienda che sfrutta. Succede in un’azienda che ha investito nella consapevolezza delle proprie persone.

    Il figlio Adriano portò questa visione ancora più avanti, fino a farne un modello industriale unico al mondo. Ma il seme era di Camillo: l’impresa come strumento di elevazione, non di estrazione. Costruire qualcosa che funziona, che serve a chi lo usa, e che rende migliore chi ci lavora.

    Ecco perché l’uscita di Opus 4.6 mi interessa e non mi interessa allo stesso tempo.

    Mi interessa perché è il modello più capace mai rilasciato. Context window da un milione di token, adaptive thinking, agent teams, i punteggi più alti mai raggiunti nel coding agentico. Il fatto che Scott White di Anthropic dica che ormai usano Claude Code non solo gli sviluppatori ma anche product manager, analisti finanziari, professionisti di ogni tipo — è esattamente il segnale.

    Non mi interessa perché il modello, da solo, non cambia nulla. Quello che cambia è cosa le persone ci fanno.

    Un fotografo che costruisce un’alternativa a Gamma. Un avvocato che trasforma vent’anni di esperienza in un prodotto. Questa è la rivoluzione. Non il benchmark, non il punteggio su Terminal-Bench, non i milioni di token di contesto.

    La rivoluzione è che la competenza di dominio — quella vera, quella che si accumula in anni di lavoro — oggi ha finalmente uno strumento per esprimersi senza intermediari.

    Camillo Olivetti non diede ai suoi dipendenti solo una fabbrica in cui lavorare. Diede loro la comprensione di cosa stavano costruendo e perché. Li rese partecipi, non esecutori. E così facendo, elevò le loro capacità ben oltre quello che un contratto di lavoro avrebbe richiesto.

    L’AI sta facendo la stessa cosa, su scala globale. Non sta dando a tutti la possibilità di programmare — questa è la retorica vuota. Sta dando a chi ha una competenza reale la possibilità di esprimerla completamente, senza che la barriera tecnica la comprima, la traduca male, o la fermi del tutto.

    La macchina per scrivere non ha reso tutti scrittori. Ha reso possibile scrivere a chi aveva qualcosa da scrivere. L’AI non renderà tutti sviluppatori. Renderà possibile sviluppare a chi ha qualcosa da sviluppare.

    Il fotografo aveva qualcosa. L’avvocato aveva qualcosa. E avevano il metodo: sapere cosa costruire, progettare come costruirlo, e usare lo strumento per farlo.

    Architettura. Obiettivi. Percorso. Strumento. Capacità.

    Il resto è rumore.

    P.S. quelli in foto dovrebbero essere Camillo e suo figlio Adriano Olivetti… Ma l’AI ha dei limiti che non gli hanno permesso di generare la foto con i volti giusti… sicchè usa un po’ di immaginazione, grazie 🙂

  • Quanto ha senso un consiglio di amministrazione con un solo membro?

    Quanto ha senso un consiglio di amministrazione con un solo membro?

    Per un po’ di tempo abbiamo creduto di risolvere con un modello AI più grande, più veloce, più addestrato, più tutto.

    Ogni nuova versione sembrava portarci un passo più vicino a un punto di arrivo definitivo, come se bastasse aggiungere qualche miliardo di parametri per ottenere finalmente l’intelligenza “giusta”. Un’idea rassicurante, quasi infantile: se qualcosa non funziona, lo ingrandiamo. Ha sempre funzionato così, no?

    Poi è successa una cosa curiosa. Le persone che quei modelli li hanno costruiti hanno iniziato a dire, più o meno apertamente, che nemmeno loro sanno davvero come funzionano fino in fondo.

    Ilya Sutskever lo ha detto con una calma quasi sospetta: lo scaling infinito non è la risposta. Non perché i modelli non siano impressionanti, ma perché stiamo continuando a spingere sull’acceleratore senza sapere esattamente cosa stia succedendo sotto il cofano. Una strategia audace, certo. Ma non proprio quello che definiremmo “controllo”.
    (vedi link su “letture consigliate” in fondo all’articolo)

    Nel frattempo, noi utenti abbiamo sviluppato una dinamica tutta nostra. Parliamo con l’AI, aspettiamo la risposta, la correggiamo, rilanciamo. Poi di nuovo. Un dialogo continuo che, a guardarlo bene, assomiglia più a una riunione infinita che a un processo decisionale. Un problema serio, però, non si risolve in una risposta, ma in una sequenza di passaggi: comprendere, analizzare, scegliere, verificare, correggere, rifinire.

    Fino al 2025 lo abbiamo affrontato in modo ricorsivo. Domanda, risposta, controbattuta. Ancora. Come ho scritto nel mio post precedente, siamo diventati degli umarell digitali, affacciati alla finestra della chat, a commentare quello che l’AI stava facendo, pronti a intervenire dopo.

    È stato utile, va detto, e in qualche modo anche istruttivo, ma è plausibile che questo sia il modello definitivo di collaborazione uomo–macchina?

    A un certo punto inizierà semplicemente a sembrarci inefficiente continuare a dire all’AI “fammi questo”, con richieste isolate che interrompono il flusso, con ogni risposta che ci costringe a fermarci, a valutare per correggere e poi ripartire. Una conversazione infinita che ricorda sempre più quelle riunioni in cui nessuno ha preparato l’ordine del giorno.

    Così inizieremo a fare una cosa sorprendentemente umana: pensare prima, non per lasciare l’AI più libera, ma per essere noi molto più rigorosi.

    Pensaci, hai mai risolto un problema complesso tutto insieme?

    Quando un problema è davvero tale, lo si scompone. Lo si riduce. Lo si divide in problemi più piccoli e li si affronta uno alla volta, in sequenza. Si chiama “problem solving”, quello che funziona, non quello raccontato nei keynote.

    E se ci pensi ancora un po’ vedrai che è esattamente il percorso che abbiamo già fatto nel campo della programmazione dei computer: all’inizio c’era il programma monolitico, un unico blocco enorme che faceva tutto. Funzionava finché nessuno lo toccava. Poi l’utente chiedeva una modifica, qualcuno faceva una patch apparentemente innocua… e tutto il resto iniziava a comportarsi in modo imprevedibile.

    Abbiamo imparato allora a spezzare quel monolite in funzioni, ognuna con un compito preciso. Meno caos, più controllo, meno notti passate a chiedersi perché qualcosa si fosse rotto.

    Oggi siamo arrivati ai microservizi, non perché fosse elegante, ma perché è il modo sensato per gestire sistemi complessi: componenti piccoli, isolati, sostituibili, che comunicano in modo esplicito. Più lavoro prima, molta meno sorpresa dopo.

    Con l’AI vivremo la stessa identica evoluzione, solo compressa in meno anni (4/5 contro 10/15).

    Stiamo passando dal prompt monolitico che “fa un po’ di tutto” a sistemi in cui i compiti sono separati, assegnati, orchestrati, per ridurre gli errori e rendere i risultati finalmente ripetibili.

    Ed è qui che una delle osservazioni più interessanti ci arriva da Andrej Karpathy: ha fatto notare che interagire con un singolo modello non è un buon modo di usare l’AI.

    Secondo Andrej che in un consiglio di amministrazione composto solo dal CEO e da un consulente che annuisce, entrambi parlano ma nessuno contraddice davvero e non si cambia mai il percorso, non si evolve, non si allarga il punto di vista.

    La sua idea di LLM Council nasce proprio da qui: un sistema funziona quando il CTO e il CFO iniziano a prendersi a parolacce, quando uno dice “tecnicamente è perfetto” e l’altro risponde “sì, ma ci manda in fallimento” e il CEO media, il COO trova soluzioni e il CLO lo rende legale. Quando le voci dissonanti emergono prima, non quando è troppo tardi.
    (vedi link su “letture consigliate” in fondo all’articolo)

    Nel futuro, se vogliamo risultati affidabili, non dovremmo chiedere all’AI di “pensare meglio”, ma organizzare meglio il pensiero.

    Decidere noi i passaggi, stabilire chi fa cosa, prevedere controlli incrociati. Non libertà totale, ma responsabilità distribuita.

    Nel frattempo, ai piani alti, il panorama non è meno ironico.
    Satya Nadella probabilmente non immaginava che il futuro della sua azienda sarebbe stato meno una corsa ad ingrandire il modello di OpenAI e più un delicato esercizio di convivenza tra modelli diversi, filosofie diverse, interessi diversi.

    Più che scegliere il vincitore, oggi il lavoro vero è evitare che il consiglio di amministrazione esploda.
    (vedi link su “letture consigliate” in fondo all’articolo)

    E poi c’è Ivan Zhao, che sull’AI è rimasto alla finestra a guardare. Un po’ come un umarell di lusso: osserva, ascolta, non si lascia prendere dall’entusiasmo e aspetta di capire dove stia davvero andando il valore. Non sempre muoversi per primi è la strategia migliore.
    (vedi link su “letture consigliate” in fondo all’articolo)

    Il punto, però, resta sempre lo stesso.

    Nel 2026 non avremo un’AI più intelligente, inizieremo a smettere di usarla come una chat e inizieremo a trattarla come un sistema complesso, fatto di ruoli, sequenze e responsabilità.

    Il cambiamento non arriverà con proclami o rivoluzioni improvvise. Arriverà quando smetteremo di fare domande sempre migliori e inizieremo a progettare processi migliori. Avverrà quando passeremo dall’attesa alla direzione.

    Il futuro dell’AI, probabilmente, non sarà più intelligente.
    Sarà semplicemente meglio organizzato e, ironia della sorte, dipenderà molto meno dall’AI e molto più da te e da me.

    Letture consigliate

  • Da umarell a direttore d’orchestra

    Da umarell a direttore d’orchestra

    Canonity, u-prompt e la maturazione dell’AI come strumento

    Negli ultimi mesi ho osservato con crescente fastidio un equivoco diffondersi nel mondo dell’AI: l’idea che l’automazione coincida con il “lasciare fare tutto alla macchina”.
    È un equivoco pericoloso, perché confonde la delega con l’abdicazione e l’efficienza con l’imprevedibilità.

    Siamo umani.
    E quando lavoriamo — davvero — abbiamo bisogno di certezza del risultato, non dei capricci di un modello che oggi risponde bene e domani no.

    Gran parte dell’AI attuale, invece, è usata in modalità umarell: si apre una chat, si scrive un prompt, si osserva la risposta, la si corregge, la si rilancia. È un’iterazione continua, sincrona, fragile. Interessante, ma strutturalmente immatura.

    Ivan Zhao, fondatore di Notion, ha messo un punto fermo su questo tema in un post che considero fondamentale e che vale la pena citare direttamente:
    https://x.com/ivanhzhao/status/2003192654545539400

    Il concetto è semplice quanto definitivo: se stai guardando l’AI mentre lavora, non stai automatizzando nulla. Nessuno osserva una fabbrica mentre produce. Si progetta il processo, si avvia, si torna dopo.

    Il valore sta nel processo, non nella conversazione.

    Questa osservazione è la chiave per capire Canonity e u-prompt, e soprattutto perché sono due strumenti diversi che risolvono due problemi diversi.

    Canonity nasce come editor di prompt multi-modello LLM, ma sarebbe un errore fermarsi a questa definizione. Canonity non serve a “provare modelli a caso” né a demandare a una macchina la scelta del modello migliore (come fanno sistemi alla Perplexity).
    In Canonity la scelta del modello è umana. Sempre.

    Questo non è un limite. È una presa di posizione.

    Chi lavora sa che modelli diversi producono risultati diversi, con stili diversi, affidabilità diverse, bias diversi. Affidare questa scelta a un algoritmo significa accettare una variabilità che, nei contesti di lavoro reali, non è accettabile.

    Canonity parte da un presupposto semplice: l’umano è responsabile del risultato finale, quindi l’umano deve scegliere con quale cervello artificiale lavorare.

    Canonity è lo spazio in cui costruisci il tuo prompt automatico, lo testi, lo migliori, lo rendi stabile. È uno strumento personale, quasi intimo. Serve a te, per risolvere un problema tuo.

    Qui l’AI non è un giocattolo né un oracolo, ma un componente tecnico da configurare con attenzione.

    Quando quel prompt funziona e il risultato è affidabile, ripetibile, coerente, succede qualcosa di interessante: ti rendi conto che quel risultato non serve solo a te.

    Ed è qui che entra in gioco u-prompt.

    u-prompt non è un repository di prompt e non nasce per vendere “testi magici”. Nasce da un’idea molto più concreta: non vendere il prompt, vendi il risultato.

    Chi arriva su u-prompt non compra istruzioni, compra un output. Esattamente come in un juke-box: non compri il disco, ascolti la canzone.

    Questa distinzione è cruciale.

    Un prompt richiede competenza, contesto, manutenzione. Un risultato no. Un risultato risponde a un bisogno diretto e abbassa enormemente la soglia di accesso. Meno richiesta cognitiva significa molti più utenti potenziali.

    Canonity e u-prompt, insieme, separano in modo netto due momenti che fino a oggi erano confusi: la fase di costruzione e la fase di consumo.

    Canonity è per chi costruisce.
    u-prompt è per chi usa.

    Nel primo caso sei ancora “in cantiere”, stai progettando, testando, raffinando. Nel secondo, il cantiere non si vede più. Il lavoro è fatto. Il processo gira. L’utente non osserva nulla, ottiene solo il risultato.

    È esattamente il passaggio descritto da Ivan Zhao: dall’AI osservata all’AI che lavora mentre tu fai altro.
    Non perché “la macchina è più brava”, ma perché il processo è stato progettato bene.

    Qui avviene il salto da umarell a direttore.
    L’umarell guarda, commenta, corregge, il direttore non suona ogni strumento, ma decide chi suona cosa, quando e come.

    Canonity ti mette in mano la bacchetta. u-prompt apre il teatro al pubblico.

    Non c’è alcuna retorica futuristica in tutto questo, è una questione di maturità degli strumenti.

    Finché l’AI resta una chat da sorvegliare, non entrerà mai davvero nei processi produttivi. Finita la fase umarell adesso deve diventare un sistema che produce output affidabili, ripetibili e vendibili, allora sì che sarà uno strumento.

    Alla fine di gennaio 26 partirà la startup e una parte significativa dei prodotti sarà già utilizzabile. Non una promessa, ma strumenti concreti, pensati per chi lavora davvero e non ha tempo di fare l’umarell davanti allo schermo.