Aldo Prinzi's BLOG

Categoria: Audacia

  • L’oblomovismo digitale

    L’oblomovismo digitale

    Ieri sera stavo leggendo un articolo su Lucy sulla cultura che parla dell’oblomovismo, quella sindrome tutta russa, dal romanzo di Gončarov del 1859, che descrive una pigrizia metafisica: l’incapacità di agire e di prendere decisioni. Il protagonista, Oblomov, non si alza dal letto per le prime centocinquanta pagine. Non perché sia stupido: ha studiato, ha conosciuto il mondo, si è convinto di potersi rendere utile alla patria. Ma la realtà si è mostrata troppo dura e lui si è ritirato progressivamente. Ha lasciato l’impiego, ha smesso di leggere, e passa le giornate a contorcersi tra le lenzuola.

    E mentre leggevo, pensavo a una cosa che vedo ogni settimana.

    Parlo con imprenditori, professionisti, gente che manda avanti aziende da vent’anni. Gli chiedo se stanno usando l’AI. Mi rispondono tutti allo stesso modo: “Sì, ho provato ChatGPT, ma non è granché per quello che faccio io.” Poi cambiano discorso. Come Oblomov che riceve i visitatori nel suo letto, un mondano, un impiegato, uno scrittore, ascolta tutti, annuisce, e non si alza.

    Ecco il punto: non sono stupidi. Sono Oblomov.

    La malattia è sistemica

    L’articolo di Lucy racconta una cosa interessante. La critica russa dell’epoca non interpretò l’oblomovismo come un difetto individuale, ma come un tratto nazionale. Il critico Dobroljubov ci scrisse un saggio intero: una malattia congenita dello spirito russo che ostacolava il progresso. Non la pigrizia di uno, ma l’inerzia di tutti.

    L’oblomovismo delle aziende italiane di fronte all’AI ha esattamente questa natura. Non è che il singolo imprenditore sia pigro. È che l’intero ecosistema, dalla formazione al rapporto con la tecnologia, dalla burocrazia alla cultura del “abbiamo sempre fatto così”, produce e riproduce torpore. Ognuno si è costruito la sua Oblomovka personale, la tenuta remota dove le regole del mondo esterno non arrivano. Il commercialista che dice “i miei clienti hanno bisogno del rapporto personale”. L’avvocato che dice “il diritto italiano è troppo complesso per una macchina”. Il manifatturiero che dice “noi facciamo cose fisiche, mica software”.

    Ognuno ha le sue ragioni. Oblomov aveva le sue.

    Quello che sta succedendo, raccontato da chi lo vive

    Con grande senso della sincronia un mio amico ieri mi ha inoltrato un post di Matt Shumer, da sei anni alla guida di una startup AI, pubblicato su X che è diventato virale.

    Ha scritto che ha smesso di dare la versione educata di quello che sta succedendo.

    Il divario tra percezione pubblica e realtà è diventato troppo grande, e troppo pericoloso.

    Il passaggio che mi ha colpito di più: Shumer racconta di descrivere un’applicazione in linguaggio naturale, andarsene dal computer per quattro ore, e tornare a trovare il lavoro finito. Non una bozza da correggere, il prodotto completo, migliore di quello che avrebbe fatto lui stesso. L’AI apre l’app, clicca i pulsanti, testa le funzionalità, itera come farebbe uno sviluppatore, e lo avvisa solo quando è soddisfatta del risultato.

    Io scrivo codice da prima del Commodore VIC-20, quando avevo un Sinclair ZX81 con 1K di memoria e il BASIC si componeva premendo combinazioni di tasti. Ho certificazioni Microsoft degli anni ’90. So cosa vuol dire debuggare un segfault alle tre di notte. Eppure quello che Shumer descrive è esattamente quello che vivo anche io, ogni giorno, da mesi. Non è hype. Non è marketing. È la mia giornata lavorativa del lunedì.

    Ma Shumer dice anche un’altra cosa che merita attenzione. Cita un managing partner di un grande studio legale che passa ore ogni giorno a usare l’AI. Non perché sia un giocattolo, ma perché funziona meglio dei suoi associati su molte attività. E ogni paio di mesi, diventa significativamente più capace. L’organizzazione METR, che misura la durata dei compiti che l’AI può completare autonomamente, un anno fa registrava circa dieci minuti. Oggi siamo a diverse ore. Ha raddoppiato i tempi in soli sette mesi e sta accelerando.

    Al meetup di Milano che raccontavo nel mio ultimo post, ho visto un fotografo e un avvocato, nessuna formazione tecnica, costruire applicazioni funzionanti con l’AI. Non vibe coding: architettura, obiettivi, percorso. Competenza di dominio tradotta in prodotto, senza intermediari.

    Mentre Oblomov resta a letto.

    Il gusto del covo

    La cosa che mi ha colpito di più nell’articolo di Lucy è un passaggio su Tommaso Landolfi e quello che chiamava “il senso della lustra”, il gusto del covo. Un piacere voluttuoso di chi si rintana nella propria casa in decadenza, mentre intorno tutto crolla. La casa crolla, sì, ma crolla lentamente, e nel frattempo ci si sta bene.

    Questa è l’immagine più precisa che abbia mai trovato per descrivere quello che vedo nelle aziende italiane. L’inerzia non è solo paralisi, è comfort. I margini calano, la competitività si erode, i concorrenti che hanno agito guadagnano velocità e capacità di analisi, ma il covo è caldo. E ci si convince che il proprio settore sia speciale, immune, diverso.

    Non lo è. Nessun settore lo è.

    Oblomov si innamora di Olga, una donna che potrebbe salvarlo. Ma per sposarla dovrebbe rendersi degno della vita che lei rappresenta, e questo, scrive Gončarov, è una cosa che in pratica non si può fare, per quanto appaia realizzabile in teoria. Così Olga lo lascia e sposa Štolc, il tedesco positivo, il pragmatico. Oblomov riprecipita nel torpore. Sposa una donna che lo accudisce come un bambino. E muore di un colpo apoplettico.

    L’azienda che rimanda non esplode. Diventa irrilevante un trimestre alla volta.

    Alzarsi dal letto

    Non scrivo questo per fare terrorismo psicologico. Lo scrivo perché il vantaggio più grande che potete avere in questo momento è semplicemente essere in anticipo. La finestra è ancora aperta: la maggior parte delle aziende italiane non si è mossa. Chi entra in una riunione e dice “ho usato l’AI per fare questa analisi in un’ora invece che in tre giorni” è la persona più preziosa nella stanza. Non domani, adesso.

    Ma la finestra non resterà aperta a lungo.

    “Addio vecchia Oblomovka”, dice Štolc alla fine del romanzo, “il tuo tempo è finito.”

    Gončarov lo scrive con un pizzico di malinconia, credi che il mercato ne avrà alcuna?

    La scelta è semplice, anche se non è facile: alzarsi dal letto, o aspettare il colpo apoplettico.

    Photo by RDNE Stock project:
    https://www.pexels.com/photo/man-lying-on-sofa-beside-vacuum-5591469/

  • 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 🙂

  • AlexNet è tornata. E non per nostalgia.

    AlexNet è tornata. E non per nostalgia.

    Ogni tanto la tecnologia fa una cosa controintuitiva: invece di correre in avanti a testa bassa, si ferma, si gira e guarda indietro. Non per rimpiangere il passato, ma per ricordarsi come si costruiscono davvero le cose che durano.
    È esattamente quello che è successo a novembre 2025 quando il Computer History Museum, insieme a Google, ha deciso di rendere pubblico il codice sorgente originale di AlexNet.

    Il codice sorgente del 2012, quello che ha cambiato la storia dell’intelligenza artificiale.

    Non è un’operazione nostalgica, e non è nemmeno un regalo per chi vuole “rifare AlexNet oggi”. È un gesto culturale. È come dire: prima di discutere dell’ennesimo modello miracoloso, forse vale la pena tornare a vedere come nasce una vera discontinuità tecnologica.

    AlexNet nasce nel 2012 all’Università di Toronto, da Alex Krizhevsky, Ilya Sutskever e Geoffrey Hinton. Vince ImageNet in modo così netto da rendere improvvisamente obsoleti anni di approcci precedenti, dimostrando in un colpo solo che le reti neurali profonde non sono solo belle teorie: funzionano, scalano e cambiano le regole del gioco.

    Da lì in poi il deep learning diventa la norma, le GPU diventano strumenti scientifici e la computer vision prende una direzione completamente nuova.

    Ma oggi AlexNet non ci interessa per la sua potenza.

    Oggi confrontata con gli standard attuali. Ci interessa per un motivo molto più profondo: come è stata pensata.

    Il codice che oggi possiamo leggere su GitHub
    🔗 https://github.com/computerhistory/AlexNet-Source-Code

    Non è elegante, modulare, o “clean”. È scritto in CUDA C++ ed è brutalmente onesto. La memoria GPU viene gestita a mano, i layer non sono entità astratte ma strutture concrete, il training non è un loop astratto, ma è un flusso rigido e dichiarato. Non esiste separazione tra modello, training, preprocessing ed esecuzione: tutto è intrecciato, perché tutto fa parte dello stesso problema.

    Leggerlo oggi è quasi uno shock culturale per chi è cresciuto a colpi di framework. Qui non c’è nulla che ti protegga. Se qualcosa non funziona, non puoi incolpare una libreria: sei tu. Ed è proprio questo che rende il codice di AlexNet così prezioso. Ti costringe a capire perché una scelta è stata fatta, quali compromessi sono stati accettati, quali limiti hardware hanno guidato l’architettura.

    AlexNet, in altre parole, non era “solo un modello”. Era un sistema completo. Dataset, preprocessing, training su GPU, tuning manuale, gestione della memoria, flusso end-to-end. Tutto insieme. Nulla aveva senso da solo.

    Ed è qui che il collegamento con l’IA di oggi diventa quasi imbarazzante per quanto è evidente.

    Image

    Nel 2025 passiamo una quantità enorme di tempo a discutere su quale sia il modello migliore. Come se il problema fosse lì. Ma un singolo LLM, per quanto impressionante, soffre degli stessi limiti strutturali che avevano le singole reti neurali prima di AlexNet: non ha memoria vera, non ha visione di processo, non ha responsabilità sul risultato finale. Da solo, è fragile.

    Il valore reale oggi emerge quando smettiamo di ragionare in termini di “modello” e iniziamo a ragionare in termini di sistema. Quando progettiamo flussi, step, ruoli, controlli. Quando decidiamo quale modello deve fare cosa, in quale momento, con quale contesto e con quale verifica. Quando l’intelligenza artificiale smette di essere una risposta brillante e diventa un processo governato.

    AlexNet ci ricorda che le rivoluzioni non nascono da un singolo componente eccezionale, ma da un’architettura chiara. È lo stesso principio che oggi ritroviamo nei sistemi di orchestrazione multi-modello e, più in generale, in piattaforme come Canonity, dove il focus non è il prompt perfetto o il modello più grosso, ma la struttura che tiene tutto insieme. Non il singolo output, ma il flusso che lo rende affidabile.

    AlexNet non ci colpisce più per la potenza, ma per la lucidità. Per il fatto che, prima che tutto diventasse automatico, qualcuno aveva capito che l’IA non è magia statistica, ma ingegneria dei sistemi. Il rilascio del suo codice non è una celebrazione del passato: è un promemoria molto attuale.

    Se vogliamo davvero capire dove sta andando l’intelligenza artificiale, ogni tanto dobbiamo fare quello che fa questo repository: tornare alle fondamenta, sporcarci le mani con l’architettura e ricordarci che le vere innovazioni non nascono dall’ultimo modello, ma dalla capacità di mettere ordine nella complessità.

  • 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.

  • Verso l’approccio AGNOSTICO

    Verso l’approccio AGNOSTICO

    Negli ultimi giorni Microsoft ha annunciato che non si affiderà più a un unico modello di intelligenza artificiale (OpenAI), ma integrerà anche Anthropic, aprendo la strada a un futuro multi-modello.
    Nell’articolo, questa scelta viene descritta esplicitamente come un approccio “agnostico”: non vincolarsi a un solo modello, ma sfruttare di volta in volta quello più adatto.

    https://thereview.strangevc.com/p/microsofts-model-switch-why-ai-middleware

    Tra le motivazioni principali spiccano due aspetti:

    • Flessibilità: la possibilità di usare il modello giusto per il compito giusto.
    • Evoluzione naturale: entro 12 mesi ogni prodotto enterprise AI supporterà almeno due modelli.

    Quando ho letto queste parole, ho sorriso.

    Perché questa stessa intuizione io l’avevo già colta alla fine del 2024. Dopo tanti rimandi, a marzo, sfruttando l’occasione di una demo, ho deciso di mettere mano a una prima bozza del progetto.

    Il 26 giugno ho completato l’MVP, che ancora oggi recita:

    “u-prompt: Ciao. Questo MVP serve a dimostrare che u-prompt è un sistema chatbot-agentico alimentato dall’intelligenza artificiale –>e agnostico<–, nel senso che durante la tua chiacchierata puoi decidere di –>utilizzare agenti differenti<– per rispondere a singole domande ad esempio per sfruttarne –>le caratteristiche speciali<–.”

    Nei giorni successivi, confrontandomi con alcuni amici, abbiamo deciso di portare avanti il progetto e fissato la data del go-live: 15 settembre. Una scelta fatta mesi prima che Microsoft rendesse pubblica la sua svolta.

    Domani, 18 settembre, la startup viene presentata a Palermo ai cantieri culturali alla Zisa nell’ambito di un evento sull’AI.

    La differenza?

    Mentre Microsoft annuncia oggi di voler lavorare con due modelli, in u-prompt abbiamo già messo insieme, per la prima volta, cinque modelli diversi in un unico prompt.

    Questo percorso – dall’MVP al progetto online – dimostra che non viviamo di parole, ma di fatti. E soprattutto dimostra, prepotentemente, una capacità di anticipare il futuro e affrontare le sfide senza paura.

    Interessati? -> hey[at]u-prompt.com

    Early adopters? -> u-prompt.com

  • Creare, non seguire – Lezioni dal mio percorso imprenditoriale

    Creare, non seguire – Lezioni dal mio percorso imprenditoriale

    L’innovazione parte da dentro, non dalla moda del momento

    Spesso si pensa che fare impresa significhi inseguire trend o replicare quello che “va di moda”. Ma come sottolinea bene Alessandro Benetton, “Penso che inventare qualcosa di nuovo (non innovativo ma nuovo) sia veramente difficile”

    Da anni, quando penso o immagino ogni mio primo progetto, parto dalla consapevolezza non sta nell’agganciarmi alle tendenze mainstream, ma nel creare valore da zero: osservando bisogni reali, sperimentando strade mai battute, e restando fedele alla mia visione.

    Benetton lo ribadisce: imprenditore significa avere coraggio, indipendenza e discontinuità, dissentire e costruire percorsi non lineari e per me ha ragione.

    Il momento della mia svolta è arrivato quando ho deciso di non seguire gli altri, ma di provarci da solo, imparando strada facendo, anche sbagliando.

    Le cose più significative sono nate così: da una consapevolezza profonda, dall’ascolto di stimoli esterni, da una fusione tra audacia e metodo, con l’intento di risolvere un problema e trarne il massimo vantaggio per tutti, azienda e cliente:

    Teche Rai
    DocuBox
    Flussu
    Medigenium
    u-prompt

    Se sei un imprenditore o stai iniziando un progetto, il consiglio è semplice: non inseguire la moda, ma coltiva qualcosa di tuo. Coltiva la discontinuità, resta fedele alla tua visione, e costruisci valore.

    I veri risultati arrivano quando intrecci coraggio e metodo, anche se ti dicono che sei “troppo avanti”, come fanno con me, non cambiare, combatti le menti vecchie!