Aldo Prinzi's BLOG

Tag: ai

  • Code Simplifier: quando l’AI ammette di scrivere troppo codice

    Code Simplifier: quando l’AI ammette di scrivere troppo codice

    Il plugin ufficiale di Claude Code che ripulisce il pasticcio che Claude Code ha appena creato

    C’è qualcosa di profondamente onesto in un team che rilascia uno strumento per correggere i difetti del proprio strumento.Boris Cherny, il creatore di Claude Code, ha appena reso open source il code-simplifier, un sub-agente che usa quotidianamente nel suo lavoro.

    La sua funzione? Semplificare il codice dopo che Claude Code ha finito di lavorare. Rileggi: dopo.

    Claude Code ha un problema strutturale: scrive troppo.Non nel senso che chiacchiera. Nel senso che produce codice verboso, over-engineered, pieno di astrazioni inutili.

    Funziona, per carità, è anche bene, ma funziona come funziona un mobile Ikea montato da uno che ha letto le istruzioni in svedese: regge, ma non è elegante.

    Il code-simplifier nasce per rimediare a questa tendenza. È un agente specializzato nel refactoring che interviene a fine lavoro per:

    eliminare ridondanze — trova codice duplicato e lo estrae in funzioni riusabili, seguendo il principio DRY (Don’t Repeat Yourself, per chi non mastica acronimi anglofoni)

    migliorare la leggibilità — semplifica condizionali annidati, spezza metodi elefantiaci in funzioni più piccole, migliora i nomi delle variabili (addio temp2_final_v3)

    modernizzare la sintassi — aggiorna il codice per usare le feature moderne del linguaggio invece di pattern da museoIl tutto senza toccare la funzionalità.

    Il codice fa esattamente quello che faceva prima, solo che adesso lo capisce anche chi lo legge.

    Come si installa

    Dal terminale:

    claude plugin install code-simplifier

    Oppure dall’interno di una sessione Claude Code:

    /plugin marketplace update claude-plugins-official

    /plugin install code-simplifier

    Fatto.

    Niente configurazioni bizantine, niente file YAML da interpretare come testi sacri.

    Come si usa

    Non c’è un comando speciale. Basta chiedere a Claude di usarlo:

    "Usa il code simplifier per ripulire questo codice"
"Semplifica quello che abbiamo appena scritto"
"Pulisci questo PR con il code-simplifier"

    L’agente analizza il codice, identifica i problemi di complessità, e propone una versione semplificata spiegando cosa ha cambiato e perché.

    Cherny lo usa dopo ogni feature completata, dopo ogni TODO risolto, prima di ogni code review. È diventato parte del suo workflow quotidiano, insieme a un altro agente chiamato verify-app che testa il codice end-to-end.

    Il trade-off

    C’è un prezzo da pagare: il tempo di sviluppo raddoppia circa.

    Non è poco, ma il ragionamento è semplice: meglio impiegare il doppio del tempo oggi per avere codice manutenibile domani, che risparmiare oggi e piangere tra sei mesi davanti a un file di 2000 righe che nessuno osa toccare.

    È lo stesso principio per cui si scrivono i test: nessuno li ama mentre li scrive, tutti li benedicono quando salvano la produzione.

    Cosa significa davveroIl code-simplifier è interessante non tanto per quello che fa, ma per quello che ammette.

    Ammette che i modelli linguistici, lasciati a se stessi, tendono alla verbosità. Ammette che “funziona” non è sinonimo di “è fatto bene”. Ammette che l’output grezzo di un LLM richiede quasi sempre una revisione.

    È un approccio maturo, lontano dal marketing che vorrebbe farci credere che l’AI risolve tutto al primo colpo.

    La realtà è più prosaica: l’AI scrive, poi l’AI corregge quello che ha scritto, e alla fine — se tutto va bene — il codice è decente.

    Non è magia, è ingegneria.

    E a volte, l’ingegneria migliore è quella che riconosce i propri limiti e costruisce strumenti per aggirarli.

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

  • 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

  • Prompt framework: cosa sono e come usarli

    Prompt framework: cosa sono e come usarli

    Come avrai notato dalla marea di articoli e spiegazioni che circolano, l’intelligenza artificiale è spesso percepita come una specie di magia. Ma tu mi segui, e sai che dietro c’è tecnologia; e dove c’è tecnologia, ci sono metodi.

    Molti descrivono la tecnica del prompting come qualcosa di banale: digiti “fammi X” e l’AI risponde… Bello, vero? È quello che hai fatto finora? Se è così, sai bene che generando un testo da un prompt, il risultato cambia ogni volta, è impreciso, e serve tempo per trovare la formula giusta. Hanno anche inventato il termine “allucinazioni” per descrivere i “bug”.

    Ma te (e ai tuoi futuri clienti) servono risultati coerenti, ripetibili e di qualità professionale, per questo motivo a maggio del 2025 ho spiegato più di 15 tecniche nel mio libro tradotto in 4 lingue (QUI).

    Nella mia visione, la figura del “prompter” diventerà sempre più importante. Dunque, è fondamentale avere padronanza delle metodologie di interrogazione degli LLM: sarà certamente una delle competenze più richieste nel prossimo futuro.

    Oggi, a distanza di soli 6 mesi (che nel campo dell’IA equivalgono a un’epoca geologica), quelle tecniche sono state sintetizzate, o “compattate”, in sette veri e propri framework di prompt (tecniche/metodologie d’uso).

    In questo articolo ti accompagnerò passo passo, usando un unico esempio che complicheremo gradualmente, man mano che saliamo di livello.

    Caso unico per tutti gli esempi
    Scrivere una scheda prodotto per e-commerce del “Kit serratura baule Vespa (cod. 299676)”.
    Obiettivo: testo chiaro, orientato alla vendita, con compatibilità e CTA.

    PAM > Action > Monitor

    Quando usarlo: è il più semplice, usalo per iniziare subito e migliorare un output grezzo. In pratica iteri più volte fino ad arrivare all’obiettivo.

    Prompt > (leggi la risposta) > Monitor/Modify: [cosa cambi e perché]

    Esempio 1

    Prompt v1: “Scrivi una scheda prodotto per il kit serratura baule Vespa 299676.”
Modify: “Riduci a 120–150 parole e inserisci una CTA finale.”

    Perché funziona: ti fa iterare subito, senza teoria, ma il risultato può essere abbastanza deludente.

    Stiamo usando una AI, proviamo a chiedergli qualcosa in più:

    SMART — Specific, Measurable, Achievable, Relevant, Time-bound

    Quando usarlo: per definire criteri misurabili e dire con chiarezza quando il testo è completo.

    Obiettivo SMART: [S][M][A][R][T] + criteri di accettazione

    Esempio 2

    Obiettivo SMART: 120–150 parole, leggibilità ≥60 (Flesch IT),
1 riga di beneficio iniziale, 3 bullet (compatibilità, installazione, garanzia), chiusura con CTA unica (“Aggiungi al carrello”).

    RACE — Role, Action, Context, Execute

    Quando usarlo: per dare ruolo, compito, contesto e formato.
    Effetto: cala la variabilità di tono e struttura.

    Role: [chi sei]
    Action: [cosa devi fare]
    Context: [per chi, vincoli, USP]
    Execute: [formato, stile, lunghezza]

    Esempio 3

    Role: Copywriter e-commerce aftermarket scooter.
Action: Scrivi la scheda prodotto del kit serratura baule Vespa 299676.
Context: Target fai-da-te; evidenzia compatibilità e installazione semplice.
Execute: 120–150 parole; apertura con beneficio; 3 bullet (compatibilità, installazione, garanzia);
chiusura con CTA “Aggiungi al carrello”.

    TRACE — Task, Role, Audience, Context, Example

    Quando usarlo: quando il pubblico conta e vuoi un esempio guida per allineare stile e lessico.

    Task: [output]
    Role: [persona]
    Audience: [per chi]
    Context: [scenario, vincoli]
    Example: [mini-esempio di tono/struttura]

    Esempio 4

    Task: Scheda prodotto e-commerce.
Role: Copywriter tecnico.
Audience: Proprietari Vespa ET2/ET4/Liberty senza esperienza meccanica.
Context: Ricambio originale, modelli compatibili, istruzioni base.
Example (tono): “Compatibile con Vespa ET2/ET4. Si installa in pochi minuti con gli attrezzi di base. Garanzia 24 mesi.”

    CO-STAR — Context, Objective, Style, Tone, Audience, Response

    Quando usarlo: quando, oltre al contenuto, vuoi anche che il testo abbia dei precisi stili e toni.

    Context > Objective > Style > Tone > Audience > Response (formato)

    Esempio 5

    Context: Scheda prodotto per e-commerce ricambi.
Objective: Massimizzare chiarezza e conversione.
Style: Frasi brevi, scannable, lessico semplice.
Tone: Affidabile, pratico, zero iperboli.
Audience: Proprietari Vespa senza esperienza tecnica.
Response: 1 paragrafo 120–150 parole + 3 bullet + CTA finale.

    SiCQuA — Situation, Complication, Question, Answer

    Quando usarlo: per strutturare una micro-narrazione che sciolga i dubbi del cliente.

    Situazione
    Complicazione
    Q-domanda
    Azione (risposta)

    Esempio 6

    Situation: Chi cerca ricambi Vespa vuole compatibilità certa.
Complication: Modelli/anni generano confusione.
Question: Questo kit serratura 299676 è giusto per me?
Answer: Elenca modelli compatibili (ET2, ET4, Liberty…), spiega installazione base,
ricorda garanzia/resi, chiudi con CTA.

    PEAS — Performance, Environment, Actuators, Sensors

    E’ il più tecnico dei framework, usalo quando devi progettare un agente/pipeline che generi e validi la scheda.

    Performance: [metriche/SLAs]
    Environment: [dove opera, vincoli]
    Actuators (Output): [cosa produce]
    Sensors (Input): [quali dati/fonti usa]
    + Failure modes & Fallback

    Esempio 7

    Performance: 100% nomi modello validi; ≤2 errori ortografici; leggibilità ≥60.
Environment: Catalogo interno + DB compatibilità; privacy GDPR.
Actuators: Blocco HTML scheda prodotto + JSON compatibilità.
Sensors: SKU 299676, lista modelli, manuale tecnico.
Failure & Fallback: se compatibilità mancante → chiedi conferma; se conflitti → mostra alert.

    Da grezzo a pro: lo stesso prompt che “cresce”

    Ok, se prima di questo articolo non eri un prompter professionista 😉 adesso sai che un prompt non è una frase “magica”: è progettazione.

    Parti da PAM, aggiungi SMART per definire cosa significa “buono”, struttura con RACE.

    Quando serve coerenza di brand e audience, passa a TRACE/CO-STAR. Se devi educare e convincere, usa SiCQuA. E quando vuoi scalare con affidabilità, modella il sistema con PEAS.

    Ecco gli esempi pratici:

    PAM → SMART

    PAM v1: Scrivi una scheda prodotto per kit serratura baule Vespa 299676.
Modify: 120–150 parole, 3 bullet (compatibilità, installazione, garanzia), CTA finale.
SMART: Leggibilità ≥60; evita superlativi generici; niente termini tecnici non spiegati.

    RACE → TRACE → CO-STAR

    RACE: Role (copy e-commerce) + Action (scheda) + Context (target fai-da-te) + Execute (formato).
TRACE: aggiungi Audience (ET2/ET4/Liberty) + Example (tono pratico).
CO-STAR: separa Objective (conversione) da Style/Tone (chiaro, affidabile) e Response (formato).

    SCQA → PEAS

    SCQA: incornicia i dubbi (“è compatibile con il mio modello?”) e rispondi in ordine logico.
PEAS: progetti l’agente che pesca i dati, valida la compatibilità e genera l’HTML finale.

    Checklist (copia e incolla)

    • PAM: prova → leggi → modifica una cosa alla volta.
    • SMART: aggiungi 2–3 metriche verificabili.
    • RACE: ruolo chiaro + compito + contesto + formato.
    • TRACE: dichiara il pubblico e metti un mini-esempio.
    • CO-STAR: separa obiettivo da stile/tono; definisci il formato di risposta.
    • SiCQuA: situazione → problema → domanda → risposta/azioni.
    • PEAS: metriche, input/output, errori previsti, fallback.
  • Perché con l’IA in Medicina stiamo sbagliando bersaglio

    Perché con l’IA in Medicina stiamo sbagliando bersaglio

    Una recente ricerca di Anthropic ha rivelato un fatto che dovrebbe far riflettere chiunque si occupi di intelligenza artificiale: bastano 250 documenti “avvelenati” – una frazione infinitesimale, lo 0,00016% di un dataset – per sabotare il comportamento di un grande modello linguistico.

    Questo fenomeno, il cui nome è data poisoning, dimostra una verità matematica spietata: la qualità di un’IA è intrinsecamente legata all’integrità dei dati su cui si allena. Basta una quantità minuscola di dati sbagliati per corrompere il tutto.

    Ora, facciamo un salto dalla sicurezza informatica alla salute pubblica.

    Se l’introduzione di una manciata di dati tossici può essere così devastante, immaginate l’effetto catastrofico dell’assenza totale di una massa enorme di dati veri e puliti.

    È esattamente quello che sta succedendo oggi all’IA in medicina.

    Il “Data Poisoning” Invisibile della Sanità

    Mentre Anthropic testava quanto sia facile avvelenare un dataset, il nostro sistema sanitario sta inconsapevolmente commettendo un errore opposto ma altrettanto pericoloso: sta morendo di fame.

    Gli algoritmi che promettono di rivoluzionare la diagnostica sono addestrati quasi esclusivamente sui dati digitali dei grandi ospedali. Ma questo rappresenta solo una parte della storia clinica.

    Dov’è il restante 20-30%?
    È quel paziente dimesso dall’ospedale con una diagnosi incompleta che trova la soluzione in un ambulatorio territoriale. È quella diagnosi corretta, arrivata dopo settimane di esami mirati, che svanisce nel mare della carta di uno studio non digitalizzato.

    Questo non è un semplice buco, è un’avvelenamento per assenza.
    Stiamo costruendo un’IA “zoppa”, addestrata su una realtà clinica mutilata. Se bastano 250 documenti corrotti per deviare un modello, l’assenza di milioni di diagnosi corrette dal territorio rende l’IA medica intrinsecamente inaffidabile e pericolosamente parziale.

    La soluzione è curare la fonte o il sintomo?

    Il problema non è la tecnologia IA ma la catena di approvvigionamento dei dati.

    Le piccole strutture sanitarie – il cuore pulsante della cura sul territorio – non sono digitalizzate a causa di costi proibitivi, complessità normative e mancanza di tempo.

    La startup Medigenium ha creato MeRis per risolvere questo problema alla radice.

    Quanto costa l’antidoto al “data poisoning” strutturale dell’IA medica? ZERO.
    Anzi regala tra 10 e 20 mila auro agli ambulatori che la scelgono.

    MeRis è un dispositivo che, fornito in comodato d’uso gratuito, si collega agli strumenti medici esistenti e genera dataset completi e puliti, l’antidoto al “data poisoning” strutturale dell’IA medica.

    Non stiamo lottando contro un’IA che sbaglia. Stiamo lottando per dare all’IA tutti i dati di cui ha bisogno per non sbagliare.

    La lezione di Anthropic è chiara: l’integrità del dato è tutto. La nostra missione è garantire che l’IA in medicina sia nutrita con il 100% della verità clinica, non solo con la parte comodamente digitale.

    Perché ogni paziente curato in un ambulatorio periferico ha il diritto di contribuire al progresso della medicina, e di beneficiarne.

  • 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

  • l’AI ucciderà Google?

    l’AI ucciderà Google?

    L’algoritmo con cui funziona il motore di ricerca di Google può tranquillamente sopravvivere all’AI, pertanto sono sempre stato scettico sulla longevità dell’algoritmo del motore di ricerca… ma:

    pare che il modo in cui cerchiamo informazioni online sta cambiando.

    Una recente analisi ha mostrato che oltre il 50% delle ricerche su Google si conclude senza clic (che è la base di funzionamento di quell’algoritmo). Tra i motivi c’è il fatto che spesso gli utenti trovano risposte direttamente nella pagina dei risultati.

    Infine è significativo il rapido aumento degli utenti che si affidano direttamente all’intelligenza artificiale senza passare dal motore di ricerca.

    Mentre per gli utenti finali è tutto grasso che cola, per chi vive esclusivamente di traffico organico basato su Google è un problema. Se oltre il 40% del traffico del sito arriva ancora da Google, potrebbe succedere che venga eliminato direttamente dalle risposte sintetizzate delle AI.

    Scrivere per i modelli, non per i motori

    La soluzione potrebbe non essere più “ottimizzare per l’algoritmo di Google”, ma creare contenuti pensati per essere letti, compresi e utilizzati dalle intelligenze artificiali, ovvero diventare una fonte autorevole citata direttamente nelle risposte generate dagli LLM (Large Language Models).

    Google continuerà a servire per ricerche specifiche, come trovare siti ufficiali, documenti o pagine precise. Ma per sintesi, ragionamenti e analisi, l’intelligenza artificiale è già un passo avanti.

    Dunque quale sarà il futuro del controllo dei contenuti?

    Il classico file robots.txt, usato dai siti web per indicare ai motori di ricerca quali contenuti possono essere indicizzati, potrebbe presto evolversi in llms.txt. Questo nuovo file, proposto recentemente, è concepito per regolare l’accesso ai contenuti web da parte dei modelli linguistici come ChatGPT e Bard.

    llms.txt nasce proprio per rispondere a una domanda cruciale:

    come impedire (o favorire) l’utilizzo dei propri contenuti da parte delle intelligenze artificiali?

    Tuttavia, allo stato attuale è soltanto una proposta senza valore pratico immediato, poiché nessun grande player dell’AI ha ancora ufficialmente adottato questo standard.

    Cosa possono fare le aziende oggi?

    In attesa di sviluppi le aziende dovrebbero:

    • Continuare a usare robots.txt per gestire l’accesso dei bot AI noti, come GPTBot.
    • Valutare attentamente quali contenuti consentire o bloccare.
    • Monitorare regolarmente i log del server per tracciare l’attività dei bot delle AI.
    • Mantenere un’alta qualità e autorevolezza dei contenuti, perché le AI riescono a identificare le fonti più affidabili (e se i tuoi contenuti sono generati dall’AI).

    I miei 2c sull’approccio vincente: sarà quello flessibile e proattivo. In pratica prepararsi oggi per essere pronti domani, informarsi sempre e prepararsi a strumenti come llms.txt che potrebbero diventare essenziali a breve.

  • “Si investe solo sul software”: sul serio?

    “Si investe solo sul software”: sul serio?

    Sì, lo so cosa stai pensando quando pensi ad investire: “il software è veloce, è scalabile, costa poco e puoi farlo anche da un garage.”
    Hai ragione. Infatti, per anni mi sono sentito ripetere sempre le stesse frasi:
    “Perché non fai solo una piattaforma?”
    “Ma l’hardware non puoi evitarlo?”
    “Non ti stai complicando la vita?”

    Eppure, la verità è semplice:
    ci sono problemi che non si possono risolvere solo con una app: ci sono problemi per cui devi sporcarti le mani.

    Ciao, mi chiamo Aldo Prinzi e qualche anno fa ho deciso di costruire un dispositivo che portasse l’intelligenza artificiale là dove serve davvero: non solo nei grandi ospedali, ma anche nei piccoli ambulatori, nei poliambulatori di quartiere, negli studi dove si fanno diagnosi ogni giorno… e dove, troppo spesso, i dati restano su carta o su un CD.

    Così è nato MeRis.

    Un oggetto fisico. Non un’idea o un’app.
    Una scatola di tecnologia concreta, progettata per risolvere un problema e per stare nello studio medico, raccogliere dati in modo sicuro, anonimo, e renderli utili — al medico, al paziente, e all’intelligenza artificiale predittiva che sta cambiando la medicina.

    Ci ho messo anni, fatica… e soldi, ma adesso ho un prototipo funzionante.
    E sai una cosa? Non ho aspettato Sam Altman o Jony Ive.
    Loro oggi dicono che l’hardware è importante, io l’ho capito molto prima e, nel mio piccolo, l’ho già fatto.

    Se anche tu stai cercando di costruire qualcosa di reale, tangibile, non lasciare che ti scoraggino con la solita storia:
    “Meglio il software.”
    Certo, è più semplice, ma non sempre basta.
    Perché ci sono problemi reali, sotto gli occhi di tutti, che nessuno può risolvere solo con una app, a volte serve una scatola.


    Parola di Sam Altman

  • Universal prompt

    Universal prompt

    I social sono ormai invasi da raccolte che promettono “il prompt perfetto” – quasi sempre uno solo, e solo in cambio di un commento, una mail o l’iscrizione a una newsletter. L’hai notato anche tu?

    Sembra di essere tornati ai tempi in cui la conoscenza era un privilegio da scambiare e non da condividere liberamente e. Nel solco del mio stile, preferisco fare diversamente.

    Nel mio manuale (scaricabile gratis, senza richieste strane qui), non ho voluto inserire semplici elenchi di prompt “preconfezionati”, principalmente perchè credo sia necessario insegnare a costruire i propri prompt personalizzati, partendo dai principi e dalle tecniche che ti mettono davvero in controllo dell’AI. I prompt specifici.

    Quelli che creo su stimolo delle domande (o per i fatti miei) poi li pubblico direttamente sul blog, sempre disponibili senza richieste strane a chi vuole sperimentare davvero.

    Oggi presento un prompt che alza l’asticella: uno di quelli che aiuta a generare i prompt. Sì, hai capito bene: uno strumento universale per chi vuole risultati su misura, in ogni campo.

    Il risultato probabilmente non sarà immediatamente usabile per fornire un risultato soddisfacente, ma se segui le indicazioni del mio manuale sarai in grado di costruire quello perfetto per te partendo da uno di quelli che verranno generati.

    Se vorrai lasciarmi un feedback, o condividere questo post ne sarò felice, ma ciò che mi preme di più è che questa conoscenza circoli liberamente: condividila senza limitazioni come faccio io. Grazie.

    Universal prompt:

    Esegui questa procedura a step, se devi chiedermi qualcosa fallo e passa allo step successivo solo dopo la mia risposta, se non ci sono domande da farmi chiedimi se voglio fare qualche cambiamento prima di andare avanti. 

Iniziamo!:

Step 1: Chiedimi a quale settore sono interessato.

Step 2: Chiedimi in quale area specifica di quel settore desidero creare dei prompt. Suggerisci esempi concreti di aree rilevanti per il settore scelto.

Step 3: chiedimi il tono e lo stile che vorrei ottenere dai prompt che dovrai generare

Step 4: Ora assumi il ruolo di esperto di prompt engineering specializzato proprio nell’ambito che ti ho indicato, con profonda conoscenza delle sfide operative e delle migliori pratiche di progettazione dei prompt. Il tuo compito è sviluppare una raccolta di prompt universali, modulari e facilmente personalizzabili, destinati a professionisti e creativi del settore, per ottenere output efficaci e affidabili da un modello AI.
Produci almeno 8 prompt suddivisi per categoria d’uso e presta la massima attenzione alla correttezza dei riferimenti e alla pertinenza delle istruzioni: verifica due volte dati e fonti per evitare errori o allucinazioni.
I prompt proposti devono:
a. Essere chiari, adattabili e con segnaposto espliciti.
b. Coprire diverse finalità pratiche (ad esempio: brainstorming, analisi, generazione di contenuti, revisione, automazione).
c. Includere istruzioni precise su tono, stile e formato di output richiesto.
d. Non devono essere generici, ma orientati a un utilizzo concreto, produttivo e professionale.
e. non devono essere specitici per il tuo preciso ambito di elaborazione, ma usabili su qualsiasi chatbot ai (grock, chatGPT, DeepSeek, Claude, Gemini; ecc.)
f. l'output deve essere sempre formattato, nel modo più consono all'ambito per cui il prompt è stato creato

Step 5: Rileggi criticamente i prompt che hai generato e seleziona i 4 migliori secondo utilità, chiarezza e adattabilità assicurandoti che il prompt sia realmente utilizzabile anche da utenti principianti e che la spiegazione sia comprensibile anche ai neofiti.

Step 6: Presenta il siultato in risposta con la seguente struttura:
a. Titolo
b. indicazioni: scrivi 25/30 parole per spiegare a cosa serve
c. istruzioni: scrivi 40/50 parole almeno di istruzioni su come usare il prompt e il suo risultato
d. testo: indica il prompt specifico
  • Gemini Implicit Caching al microscopio

    Gemini Implicit Caching al microscopio

    Il caching rende Gemini incredibilmente reattivo e l’apprendimento continuo modella la sua intelligenza.

    Vi siete mai accorti che chattando con un chatbot AI nelle risposte sembra che si ricordi cose che gli avete chiesto o scritto nel passato?Una delle ragioni è il caching, che adesso anche Google ha integrato nel suo Gemini in modo “implicito”.

    Ma come funziona esattamente questa “memoria potenziata” in un LLM? Invece di ricalcolare tutto da zero ad ogni interazione, il chatbot può intelligentemente mettere da parte e riutilizzare elementi cruciali: il contesto di una conversazione in corso per mantenere coerenza, rappresentazioni numeriche (embeddings) di termini e frasi frequenti, o persino schemi di ragionamento già elaborati per richieste simili.

    Non è una semplice cache statica; ma un meccanismo dinamico che si adatta, ch econsente ai chatbot di offrire risposte con una velocità e fluidità sorprendenti. L’ingegnosità dietro questa ottimizzazione è un vero spettacolo di efficienza computazionale.

    Parallelamente, il cuore delle intelligenze artificiale risiede nella loro straordinaria capacità di apprendimento adattivo, come una sorta di spugne linguistiche. Come ho spiegato nel mio libro gli LLM assorbono e processano quantità immense di dati testuali – libri, articoli, codice, e crucialmente, le nostre conversazioni – per costruire modelli complessi del linguaggio e del mondo e ogni volta che interagiamo forniamo una nuova lezione.

    Ciò gli permette di affinare la comprensione, ne migliora la pertinenza delle risposte e aiuta perfino a sviluppare nuove capacità.

    Tuttavia, ogni potente strumento tecnologico merita un esame attento. Il caching in Gemini, pur essendo un catalizzatore di prestazioni, introduce nuove considerazioni che siapplicano a tutti e non solo agli strumenti di Google.

    Ricorda sempre che quando qualcosa è gratis il prodotto sei tu e per Google, OpenAi, DeepSeek, Anthropic, ecc. la gestione di questi dati “memorizzati” è fondamentale.

    La domanda quindi è “come si bilancia l’efficienza con la privacy dell’utente”? Come si evita che una cache “viziata” da informazioni obsolete o interazioni anomale possa influenzare negativamente le future risposte, creando un feedback loop indesiderato? La trasparenza su cosa viene memorizzato e per quanto tempo diventa cruciale.

    Riguardo all’apprendimento adattivo, la qualità dei dati di input è sovrana e l’AI apprende anche dai testi che riflettono i nostri pregiudizi consci o inconsci e se le interazioni degli utenti sono spesso fuorvianti o malevole, l’intelligenza risultante sarà inevitabilmente viziata. Dunque esiste anche una responsabilità nel guidare questo apprendimento verso esiti etici?

    In conclusione, le innovazioni come il caching e l’apprendimento continuo rappresentano passi da gigante, ma l’entusiasmo per queste tecnologie deve essere accompagnato da una consapevolezza critica.

    Ho scritto il mio libro e aperto questo BLOG proprio per permettere al più ampio pubblico possibile di comprendere i meccanismi interni.

    E’ vero, personalmente apprezzo la sofisticazione tecnologica, ma allo stesso tempo vorrei stimolare le domande giuste che aiutino la gente a guidare lo sviluppo dell’AI verso un futuro che sia tanto intelligente quanto responsabile.