Da qualche giorno, almeno secondo la Casa Bianca, l’intelligenza artificiale non esiste più. Al suo posto c’è la Superintelligenza, sigla SI. Nessun salto tecnologico, nessun nuovo modello: è cambiato solo il nome.

Cosa è successo

Il 22 settembre, all’Assemblea Generale dell’ONU, Trump ha annunciato che i documenti del governo USA useranno “super” al posto di “artificiale”, perché quest’ultima parola farebbe sembrare la tecnologia finta. Il nome è stato scelto con una serie di sondaggi su Truth Social, tra Superior, Extreme e Supreme Intelligence. Il messaggio finale: chi vince la SI, vince. E gli Stati Uniti, a suo dire, sono molto avanti rispetto alla Cina.

Piccolo problema: “superintelligenza” significa già un’altra cosa. Nella ricerca indica un’intelligenza che supera quella umana in quasi ogni compito: il traguardo, non il punto di partenza. Chiamare così il chatbot che ci riassume le email vuol dire dichiarare raggiunto qualcosa che nessuno ha ancora raggiunto.

È marketing, e pure fatto bene

“Artificiale” suona come surrogato. “Super” suona come primo della classe. Non è una questione di precisione, è posizionamento: lo stesso schema del Golfo del Messico diventato Golfo d’America. Rinominare per rivendicare. L’AI è di tutti; la SI, nella narrazione, è americana. Il messaggio non è per gli ingegneri, ma per investitori, elettori e concorrenti.

Con un’ironia: anche “artificial intelligence” negli anni ’50 fu una scelta di comunicazione, pensata per suonare ambiziosa e attirare fondi. Siamo solo passati da un’etichetta ambiziosa a una ancora più ambiziosa.

Perché interessa a chi fa software

Le parole spostano le aspettative, e le aspettative qualcuno le deve gestire. Se già oggi ci sentiamo dire “l’ho fatto con l’AI in cinque minuti”, figuriamoci con la superintelligenza. Il nome non migliora l’output, non riduce gli errori, non scrive i test. Alza solo l’asticella. E il divario tra promessa e realtà, nei progetti, lo colmiamo noi.

Quindi no, non è finita l’era della AI. È finita, forse, l’era del nome. Quando la superintelligenza arriverà davvero ce ne accorgeremo, e non servirà un sondaggio sui social per deciderlo.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Abbiamo passato decenni a costruire macchine che lavorassero al posto nostro. Adesso che ci riescono, ci lamentiamo che lo fanno meglio di noi.

Non è una novità. La lavatrice doveva liberarci dal bucato, il foglio di calcolo dai conti a mano, il compilatore dall’assembly. Ogni volta abbiamo festeggiato il tempo guadagnato e, allo stesso tempo, rimpianto qualcosa che non sapevamo di tenere così tanto.

Con l’intelligenza artificiale però il rimpianto ha un sapore diverso. Non ci sta togliendo la fatica: ci sta mettendo davanti a uno specchio.

In questi giorni ho visto il video di un ragazzo che raccontava la sua tesi. Sei mesi di lavoro: studiare gli algoritmi, fare i calcoli, scrivere il codice, disegnare i grafici. Il percorso classico, fatto bene.

Sei mesi contro tre ore

Poi, per curiosità, ha dato l’introduzione della tesi a ChatGPT. In tre ore ne è uscita una tesi completa. E, a detta sua, migliore della sua.

La cosa che mi ha colpito non è il risultato. È la sua faccia mentre lo raccontava. Non c’era entusiasmo per lo strumento, c’era una domanda: allora a cosa sono serviti quei sei mesi?

È una domanda legittima. Ma credo sia posta male.

Non è solo una questione di codice

Lo stesso schema lo vedo nella robotica. Per anni abbiamo detto che i robot avrebbero fatto i lavori pesanti, ripetitivi, pericolosi. Quelli che nessuno voleva fare.

Oggi un braccio robotico assembla con una precisione che nessun operaio può mantenere per otto ore. Un robot di magazzino non si stanca e non sbaglia scaffale. E invece di dire “finalmente”, diciamo “ci rubano il lavoro”.

Volevamo macchine brave. Le abbiamo avute. Solo che le immaginavamo brave fino a un certo punto: abbastanza da aiutarci, non abbastanza da superarci.

Cosa ci dà fastidio, davvero

Non ci dà fastidio che la macchina lavori. Ci dà fastidio che il suo lavoro renda visibile quanto valeva il nostro, misurato solo sul prodotto finale.

Per anni abbiamo confuso lo sforzo con il valore. Sei mesi di tesi sembravano valere di più di tre ore perché erano costati di più. Ma il costo non è mai stato il punto.

Quello che il ragazzo ha costruito in sei mesi non è la tesi. È la capacità di capire se una tesi è buona. Senza quei sei mesi non saprebbe dire che quella di ChatGPT è migliore. Non saprebbe nemmeno dove controllare se ha sbagliato un calcolo.

L’AI produce l’artefatto. Il giudizio su quell’artefatto resta a chi ha fatto la strada lunga almeno una volta.

E per chi guida un team?

Lo vivo anche io, nei progetti con i clienti. Sempre più spesso sento dire “quella cosa l’ho fatta con Claude in pochi minuti”. E la prima reazione, lo ammetto, è sentirsi sminuiti.

Poi mi ricordo di cosa viene dopo quei pochi minuti. Qualcuno deve capire se il codice regge, se è sicuro, se si potrà mantenere tra due anni. Qualcuno deve dire di no a una soluzione che funziona oggi e crolla domani.

Per un tech lead questo cambia tre cose:

• Smettere di misurare le persone sulle ore. Se il valore era lo sforzo, l’AI lo ha azzerato. Se il valore è il giudizio, è appena diventato più prezioso.
• Proteggere la strada lunga per i junior. Chi non ha mai fatto un calcolo a mano non saprà riconoscere quando la macchina sbaglia.
• Usare l’AI come acceleratore, non come alibi. Si usa, si verifica, si capisce. Sempre.

Forse va bene così

Non siamo mai contenti. Quando le macchine non sapevano fare niente, ci lamentavamo che erano stupide. Ora che sanno fare molto, ci lamentiamo che sono troppo brave.

Forse l’insoddisfazione non è un difetto. È il segnale che stiamo cercando il nostro posto in un mondo che cambia più in fretta di noi.

Quei sei mesi non sono stati buttati. Sono il motivo per cui quel ragazzo, oggi, sa riconoscere una buona tesi quando la vede. Anche se non l’ha scritta lui.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Ti è mai capitato di stare in una riunione e sentire frasi come “l’agente usa MCP per chiamare i tool, ma la context window è piena e il modello allucina”? Tutti annuiscono. Tu annuisci. Poi torni alla scrivania e cerchi su Google.

Tranquillo, non sei solo. Il mondo dell’intelligenza artificiale corre veloce e si porta dietro un vocabolario tutto suo, fatto di inglesismi e sigle. La buona notizia è che dietro quasi ogni parola c’è un concetto semplice. Vediamoli insieme, senza formule e senza ansia.

Le fondamenta

Modello

È il “cervello” dell’AI: un enorme file pieno di numeri che, messi insieme, sanno fare una cosa, per esempio scrivere testo, riconoscere immagini o tradurre. Quando senti “è uscito un nuovo modello”, è come dire che è uscita una nuova versione di quel cervello, di solito più brava della precedente.

LLM (Large Language Model)

Un modello linguistico di grandi dimensioni. È il tipo di AI che sta dietro a Claude, ChatGPT, Gemini e simili. Ha “letto” una quantità enorme di testi e ha imparato come si costruiscono le frasi, i ragionamenti, il codice. Il suo mestiere, in fondo, è uno solo: prevedere quale parola viene dopo. Solo che lo fa così bene da sembrare che capisca.

Parametri

Sono i numeri dentro il modello, le “manopole” che si regolano durante l’apprendimento. Quando leggi “un modello da 70 miliardi di parametri”, pensa a 70 miliardi di manopole. Più parametri di solito significa più capacità, ma anche più costi per farlo funzionare.

Addestramento (training)

È la fase in cui il modello impara. Gli si mostrano miliardi di esempi e lui aggiusta le sue manopole finché non diventa bravo. È un processo lunghissimo e costosissimo, che avviene una volta sola (o quasi) prima che il modello arrivi nelle nostre mani.

Inferenza

Se l’addestramento è andare a scuola, l’inferenza è il giorno dell’esame. È il momento in cui il modello, già addestrato, usa quello che sa per rispondere a te. Ogni volta che scrivi una domanda a un chatbot e ricevi una risposta, quella è inferenza. Quando le aziende parlano di “costi di inferenza”, parlano di quanto costa far rispondere il modello a milioni di persone.

Parlare con il modello

Prompt

È semplicemente quello che scrivi all’AI: la domanda, la richiesta, le istruzioni. Il cosiddetto prompt engineering è l’arte di scrivere richieste chiare. Spoiler: funziona come con i colleghi. Più contesto dai, migliore è il risultato.

Token

L’AI non legge parole intere, ma pezzetti di parole chiamati token. “Incredibile” potrebbe diventare “In”, “cred”, “ibile”. I token sono l’unità di misura di tutto: si paga a token, si misura la lunghezza a token, i limiti sono in token. Pensali come le monete del mondo AI.

Finestra di contesto (context window)

È la “memoria a breve termine” del modello: quanta roba riesce a tenere in mente contemporaneamente durante una conversazione. Si misura in token. Se la conversazione diventa troppo lunga e supera la finestra, il modello inizia a “dimenticare” le cose dette all’inizio. Come quando al telefono ti dettano un numero troppo lungo.

Allucinazione

Quando l’AI si inventa qualcosa con assoluta sicurezza: una citazione mai detta, un libro mai scritto, una funzione che non esiste. Non lo fa per cattiveria. Ricordi che il suo mestiere è prevedere la parola successiva? A volte la previsione più “plausibile” non è quella vera. Per questo le risposte importanti vanno sempre verificate.

Temperatura

Una manopola che regola quanto l’AI è creativa o prevedibile. Temperatura bassa: risposte precise, sempre simili, ottime per dati e codice. Temperatura alta: risposte più fantasiose e variabili, utili per brainstorming e scrittura creativa.

Multimodale

Un modello che non capisce solo il testo, ma anche immagini, audio, documenti o video. Puoi fotografare uno scontrino e chiedergli di dividere il conto: quello è multimodale.

Dal chiacchierare al fare

Tool (strumenti)

Da solo, un modello sa solo scrivere. Ma se gli dai degli strumenti, come la possibilità di cercare sul web, leggere un file, fare un calcolo o mandare una mail, può agire nel mondo. Il tool use è proprio questo: il modello decide quale strumento usare e quando.

Agente

Qui arriva la parola del momento. Un agente è un’AI a cui non chiedi una singola risposta, ma un obiettivo. “Trovami tre fornitori, confronta i prezzi e preparami una tabella.” L’agente ragiona, pianifica i passi, usa gli strumenti, controlla i risultati e va avanti finché non ha finito. La differenza con un chatbot? Il chatbot ti dice come si fa. L’agente lo fa.

Harness

Letteralmente vuol dire “imbracatura”, come i finimenti di un cavallo. Ed è un’ottima immagine: il modello è il cavallo, forte ma senza direzione. L’harness è tutto quello che gli sta intorno e lo rende utile: le istruzioni di sistema, gli strumenti a disposizione, la gestione della memoria, i controlli, il ciclo “pensa, agisci, verifica”. Lo stesso modello dentro due harness diversi può comportarsi in modo molto diverso. Per questo, oggi, costruire un buon harness conta quasi quanto avere un buon modello.

MCP (Model Context Protocol)

Una specie di presa universale per l’AI. Prima, collegare un modello a Gmail, a un database o a un gestionale richiedeva ogni volta un lavoro su misura. MCP è uno standard aperto che definisce un modo comune per farlo: chi crea un servizio espone un “connettore” MCP, e qualsiasi AI compatibile può usarlo. Pensa alla USB: una porta, mille dispositivi.

Guardrail

Sono i “guardrail” proprio come in autostrada: regole e controlli che impediscono all’AI di uscire di strada. Evitano che dia risposte pericolose, che esegua azioni non autorizzate o che parli di cose che non le competono.

Come si rende un modello più bravo

Fine-tuning

Prendi un modello già addestrato e gli fai fare un “corso di specializzazione” su un tema preciso, con dati tuoi. È come assumere un laureato brillante e formarlo sulle procedure della tua azienda.

RAG (Retrieval-Augmented Generation)

Nome complicato, idea semplicissima: prima di rispondere, l’AI va a cercare le informazioni giuste in una raccolta di documenti (i manuali aziendali, le FAQ, i contratti) e poi risponde basandosi su quelli. È l’esame “a libro aperto”. Riduce le allucinazioni e permette all’AI di conoscere cose che non ha mai visto durante l’addestramento.

Embedding

Il modo in cui l’AI trasforma parole e frasi in coordinate numeriche, come punti su una mappa. Concetti simili finiscono vicini: “gatto” sta vicino a “felino”, lontano da “trattore”. È la tecnologia che rende possibile il RAG e la ricerca “per significato” invece che per parola esatta.

Ragionamento (reasoning)

Alcuni modelli, prima di rispondere, “pensano ad alta voce” dentro di sé: scompongono il problema, provano strade diverse, si correggono. Ci mettono un po’ di più, ma su problemi complessi (matematica, codice, analisi) i risultati migliorano parecchio. È la differenza tra rispondere d’istinto e prendersi un minuto per rifletterci.

Le sigle da riunione

AI generativa: l’AI che crea contenuti nuovi (testi, immagini, musica) invece di limitarsi a classificarli o analizzarli.

GPT: sta per Generative Pre-trained Transformer. “Transformer” è l’architettura, cioè la struttura interna, su cui si basano quasi tutti i modelli linguistici moderni. Non è sinonimo di “AI”, anche se spesso lo si usa così.

API: la “porta di servizio” attraverso cui i programmi parlano con il modello, senza passare dalla chat. È quello che usano gli sviluppatori per integrare l’AI nelle loro app.

GPU: i processori grafici nati per i videogiochi, che si sono rivelati perfetti per far girare l’AI. Sono il motivo per cui si parla tanto di chip, data center ed energia.

Open weights: modelli i cui “pesi” (i famosi parametri) sono pubblici e scaricabili. Puoi farli girare sui tuoi server, invece di usarli solo tramite il servizio di un’azienda.

AGI (Artificial General Intelligence): un’ipotetica AI capace di fare qualsiasi compito intellettuale al livello di un essere umano. Se ne parla tantissimo, non c’è accordo su cosa significhi esattamente né su quando (e se) arriverà.

Vibe coding: scrivere software descrivendo a parole quello che vuoi e lasciando che sia l’AI a scrivere il codice. Divertentissimo per i prototipi, da maneggiare con cura quando il progetto diventa serio.

In chiusura

Il vocabolario dell’AI sembra una barriera, ma è soprattutto un insieme di metafore: cervelli, memorie, esami, strumenti, imbracature. Una volta capita l’idea dietro la parola, la sigla smette di fare paura.

E la prossima volta che in riunione qualcuno dice “l’agente allucina perché la context window è satura”, potrai annuire. Ma stavolta sapendo esattamente di cosa si parla.

Happy

1 100 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Ogni generazione di sviluppatori senior ha pensato che quella dopo avesse la vita troppo facile. Chi ha imparato senza Stack Overflow ha guardato con sospetto chi ci è cresciuto dentro, e chi è cresciuto con Stack Overflow ha detto le stesse cose sui framework che nascondono tutto. Quasi sempre si sbagliavano: gli strumenti alzavano il livello del punto di partenza e la competenza si ricostruiva un po’ più in alto.

Prima di scrivere il resto di questo articolo mi sono chiesto se non stia facendo esattamente lo stesso errore. Non ne sono del tutto sicuro. Però credo che questa volta ci sia una differenza che vale la pena guardare da vicino, e non riguarda quanto è potente lo strumento: riguarda in quale punto del percorso toglie attrito.

Lo stesso strumento fa due cose opposte

Quando io uso l’intelligenza artificiale per generare un modulo, sto delegando qualcosa che so fare. Leggo il risultato e vedo subito se la gestione degli errori è messa dove serve, se quella query diventerà un problema con dieci volte i dati, se quella scelta mi vincola su una cosa che tra sei mesi dovrò cambiare. Non lo vedo perché sono più intelligente: lo vedo perché quelle tre cose le ho già sbagliate, e le ho pagate.

Quando un junior usa lo stesso strumento, sta delegando qualcosa che non ha mai fatto. Il risultato è identico. Quello che manca è tutto quello che succedeva prima che il risultato arrivasse.

È lì che si formava la competenza. Non nel codice finito, che era anzi la parte meno interessante, ma nelle quattro ore passate a capire perché non partiva, nel dead end preso e abbandonato, nell’errore letto tre volte prima di accorgersi che diceva esattamente cosa fare. Quelle ore sembravano tempo perso, e in senso stretto lo erano: producevano poco. Producevano però un modello mentale di come le cose si rompono, che è l’unica cosa che poi permette di guardare del codice e sentire che qualcosa non torna prima di sapere perché.

Quell’attrito non era un difetto del processo. Era il processo.

Il plateau invisibile

C’è un effetto collaterale meno ovvio e secondo me più insidioso.

Prima, il livello di un junior si vedeva dal suo output. Il codice diceva dov’era: cosa aveva capito, cosa stava ancora imitando, cosa non aveva mai incontrato. Era un segnale rumoroso ma leggibile, e serviva a due persone — a chi lo seguiva, per calibrare il lavoro da assegnargli, e a lui, per sapere dove si trovava.

Oggi quel segnale è quasi sparito. L’output di un junior con un buon assistente è spesso indistinguibile da quello di una persona con cinque anni di esperienza. Sembra una buona notizia, e in parte lo è. Ma significa anche che nessuno dei due — né chi guida né chi impara — ha più un modo semplice di sapere a che punto è la crescita. La differenza salta fuori tutta insieme, e sempre nel momento peggiore: il primo problema che non assomiglia a niente di già visto, il primo incidente in produzione, la prima volta che lo strumento propone una soluzione plausibile e sbagliata.

Il rischio non è avere junior meno capaci. È avere junior che sembrano competenti, si sentono competenti, e scoprono di non esserlo in una situazione dove quella scoperta costa cara a tutti.

E poi c’è il problema economico

Qui la faccenda smette di essere pedagogica.

I compiti che davamo ai junior avevano tutti le stesse caratteristiche: ben delimitati, a basso rischio, ripetitivi, con un risultato verificabile. Erano i gradini bassi della scala, e servivano esattamente a quello — far salire qualcuno.

Sono anche, con precisione quasi comica, i compiti che oggi l’intelligenza artificiale svolge meglio. Più veloce, a costo quasi nullo, senza bisogno di supervisione.

Quindi il problema non è solo “come faccio a insegnare”. È che il lavoro con cui si insegnava non ha più una ragione economica per esistere. Chi decide come allocare le persone su un progetto si trova davanti a una scelta che dieci anni fa non c’era: quel task lo do a una persona che deve imparare, sapendo che ci metterà tre giorni invece di venti minuti e che il risultato sarà peggiore, oppure lo chiudo stasera. La seconda opzione è sempre difendibile sul singolo progetto, e sistematicamente disastrosa sui tre anni.

Nessuno prende mai la decisione di smettere di formare le persone. Si arriva lì una consegna alla volta.

Cosa provo a fare, senza sapere se basta

Non ho una risposta pulita. Ho alcune cose che sto provando, con risultati diseguali.

Prima scrivi, poi confronta. Su un pezzo scelto — non su tutto, sarebbe insostenibile — chiedo che la prima stesura sia fatta a mano, e solo dopo generata. Il valore non è nella versione scritta a mano, che quasi sempre è peggiore. È nel confronto: perché lo ha risolto così, cosa non avevo considerato, cosa invece nel mio era meglio e va tenuto. Il confronto insegna moltissimo, ma funziona solo se hai qualcosa da confrontare.

La review si sposta dal codice al ragionamento. Non chiedo più solo se funziona. Chiedo perché quella scelta, cosa è stato scartato, cosa si rompe se il carico decuplica, cosa succede se quel servizio esterno risponde lento invece che dare errore. Se le risposte non ci sono, il codice non passa — anche quando funziona perfettamente. Non è pignoleria: è che il codice che nessuno sa spiegare è codice che nessuno potrà cambiare.

Il debug di roba scritta da altri, presto. Un incidente in produzione insegna in un pomeriggio quello che un task assegnato non insegna in un mese, e non è delegabile: l’assistente ti aiuta a leggere lo stack trace, non ti toglie la responsabilità di capire perché quel sistema è fatto così. È anche l’unico attrito rimasto che non si può comprimere.

Proprietà lunga su qualcosa di piccolo. Un componente vero, in produzione, seguito per mesi. Le conseguenze delle proprie scelte che tornano indietro dopo sei mesi sono il maestro più efficace che conosco, e sono l’esatto opposto della logica del task chiuso in venti minuti.

La cosa che non so

Resta aperta un’obiezione seria, che mi faccio da solo.

Forse la competenza che stiamo cercando di preservare non è più quella che serve. Forse il mestiere si sposta davvero verso il giudizio, la revisione, la capacità di decidere cosa vale la pena costruire — e forse quelle si possono allenare direttamente, senza passare dalle quattro ore sull’errore di compilazione. Se è così, quello che ho scritto qui sopra è nostalgia travestita da metodo, e tra dieci anni farà sorridere come le prediche su Stack Overflow.

Non riesco a escluderlo. So solo che il giudizio, per come l’ho visto formarsi nelle persone con cui ho lavorato, è sempre arrivato dopo aver sbagliato abbastanza volte da riconoscere le forme. E che non ho ancora visto nessuno svilupparlo guardando funzionare cose che non ha capito.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Il debito tecnico ha una qualità che oggi rimpiango: si vede.

Lo riconosci mentre leggi. La funzione da quattrocento righe, il campo chiamato flag2, la logica di business finita dentro il controller, il modulo che tutti sanno di dover riscrivere e nessuno riscrive mai. Fa male al momento del contatto, e questo è esattamente ciò che lo rende gestibile: un dolore immediato è un segnale, e sui segnali si può decidere. Sai cos’hai, sai più o meno cosa costerebbe sistemarlo, e se scegli di non farlo è una scelta.

Da un paio d’anni sto vedendo accumularsi qualcosa di diverso, che non ha nessuna di queste proprietà. Lo chiamo debito di comprensione, per mancanza di un nome migliore.

Definizione

È codice corretto, funzionante, spesso scritto meglio della media del progetto che nessuno in azienda sa spiegare.

Non “nessuno ha letto”. Nessuno sa spiegare: perché quella scelta e non un’altra, quali alternative sono state scartate, cosa succede se l’input arriva in un formato leggermente diverso, quale vincolo del sistema quel pezzo sta rispettando senza dirlo. Il codice è lì e fa il suo lavoro. Il modello mentale che lo ha prodotto non è mai entrato in nessuna testa.

La differenza rispetto al debito tecnico è che qui non c’è niente da vedere. Il linter è verde. La copertura dei test è buona, perché i test li ha generati lo stesso strumento. La complessità ciclomatica è più bassa della media del repository. Nessuna metrica che usiamo oggi si accorge di questo debito, per la semplice ragione che tutte le nostre metriche guardano il codice, e il codice non ha alcun problema. Il problema è dall’altra parte, nelle persone, e lì non misuriamo niente.

Non è nuovo, è solo accelerato

Vale la pena essere onesti: questo debito è sempre esistito. La persona che se ne va portandosi via l’unico modello mentale di un sottosistema. Il modulo scritto in una notte prima della consegna e mai più guardato. La libreria integrata copiando l’esempio della documentazione e funzionante per motivi che nessuno ha indagato. Codice che nessuno capisce ne abbiamo sempre avuto.

Quello che è cambiato è il tasso di accumulo. Prima il debito di comprensione cresceva alla velocità con cui una persona poteva produrre codice senza capirlo e quella velocità era bassa, perché scrivere codice che non capisci è comunque faticoso e lento. C’era un limite fisico che faceva da freno, non per virtù ma per attrito.

Quel limite non c’è più. Oggi una persona può immettere in un sistema, in una settimana, più codice non compreso di quanto ne avrebbe prodotto in un anno. E può farlo mentre tutti gli indicatori di qualità migliorano.

Come si manifesta

Il debito di comprensione non si annuncia. Si vede di riflesso, e quasi sempre in fenomeni che attribuiamo ad altro:

La modifica piccola che nessuno vuole prendere in carico. Un cambiamento apparentemente banale su una certa area, e in pianificazione cala il silenzio. Non è pigrizia: è che nessuno sa cosa si romperà.

Le stime che si gonfiano su zone precise del sistema senza che nessuno sappia dire perché. Se chiedi, ti risponderanno “quella parte è delicata”. Delicata di solito significa opaca.

“Funziona, non toccarlo”. La frase più costosa dell’intero mestiere, e il sintomo più diretto.

I bug risolti aggiungendo codice invece che togliendolo. Chi ha il modello del sistema rimuove la causa; chi non ce l’ha aggiunge una condizione attorno al sintomo. È un indicatore che si legge nei diff, ed è piuttosto affidabile.

La riscrittura che sembra più economica della modifica. Su un componente di sei mesi fa. Quando arriva questo, il debito non è da pagare: è già stato pagato, in perdita.

Un modo per misurarlo

Non ho una metrica automatica da proporre e diffido di chi la propone. Ho un esercizio, che si fa in mezz’ora su una lavagna.

Si elencano le aree del sistema, e per ognuna si scrive quante persone sono in grado di spiegarla senza aprirla: cosa fa, perché è fatta così, cosa la rompe. Non “quante ci hanno lavorato”. Quante la sanno spiegare.

È il bus factor applicato alla comprensione anziché all’accesso, e il risultato è di solito peggiore di quanto chiunque si aspettasse soprattutto sulle parti costruite di recente e in fretta, che sono anche quelle che in retrospettiva sembravano essere andate meglio.

Cosa lo riduce

La regola del “spiegamelo”. In revisione non passa ciò che l’autore non sa spiegare, anche quando funziona perfettamente. Il criterio non è “l’ho letto”, è “so dirti cosa succede se”. Va detto chiaramente al team che questo non è un test di lealtà verso gli strumenti: vale identico per il codice scritto a mano, e ha sempre dovuto valere. È solo che prima capitava di rado di scrivere qualcosa che non si sapeva spiegare.

Documentare le decisioni, non il codice. Il codice generato è già ampiamente commentato, spesso più del necessario, e quei commenti dicono cosa fa che era la parte già leggibile. Quello che manca è il perché: quali alternative sono state considerate, quale vincolo ha deciso, cosa era vero al momento della scelta e potrebbe non esserlo più. Bastano dieci righe per decisione, tenute vicino al codice.

Chiedere le alternative scartate al momento giusto. Il momento in cui il contesto è massimo è quando il codice viene generato, non sei mesi dopo. “Cosa hai considerato e perché hai escluso il resto” è la domanda che trasforma un output in una comprensione, e costa trenta secondi allora contro tre giorni poi.

Rotazione deliberata. Chi non ha scritto una parte deve metterci le mani prima che sia un’emergenza. È l’unico modo per scoprire quanto è opaca mentre scoprirlo costa poco.

E contrarlo consapevolmente, quando serve. Come per il debito tecnico, non è la contrazione il problema. Per uno script interno, un prototipo, una cosa che vivrà tre settimane, generare qualcosa che nessuno capisce è perfettamente razionale. Il debito diventa pericoloso quando è una scoperta invece che una decisione — quando ci si accorge di averlo il giorno in cui bisogna ripagarlo.

Perché conta più di prima

Il debito tecnico ha un’ultima proprietà consolante: è ripagabile con lavoro. Anche molto, anche noioso, ma lavoro e oggi il lavoro di riscrittura costa meno di quanto sia mai costato.

Il debito di comprensione no. Non si ripaga generando altro codice, perché il codice non è mai stato il problema. Si ripaga solo con il tempo di persone che si siedono e ricostruiscono un modello mentale che nessuno ha mai avuto, partendo da un artefatto che non è stato scritto per essere spiegato. È l’unica forma di debito che gli strumenti che lo producono non aiutano a estinguere.

Il debito tecnico si vede nel codice. Il debito di comprensione si vede solo nelle persone — e per questo, quando lo vedi, di solito è tardi.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Invece di cercare l’ennesimo tema pronto ho descritto quello che volevo. Il lavoro più importante, però, non l’ha fatto l’AI.

Il tema giusto è sempre quello di qualcun altro

Chi ha un blog su WordPress conosce il rito. Si apre la directory dei temi, si sfogliano le demo, se ne installano tre o quattro. Ognuno ha qualcosa che non serve: slider, page builder, pannelli con quaranta opzioni. E ognuno manca proprio della cosa che volevi.

Personalmente ho passato tantissimo tempo a installare, nagivare, cercare, configurare temi per trovare quello che meglio si adattasse alle mie esigenze, e sopratutto che fosse un tema light e non un configuratore pieno di mille funzioni per me inutili.

Il motivo è semplice. Un tema pensato per migliaia di siti deve accontentare tutti, e quindi non è fatto su misura per nessuno. Questa volta ho provato a fare il contrario: invece di adattarmi a un tema, ho descritto quello che volevo.

Ho scritto i requisiti, non il codice

Ho aperto una conversazione con Claude e ho scritto quello che scriverei in un brief per il mio team.

Volevo un layout chiaro, leggero e minimale. In home, l’ultimo articolo in evidenza e sotto le anteprime dei precedenti. Poi le categorie e la ricerca. Un box con il link al mio libro. E un box con gli altri miei siti, che si notasse senza invadere la pagina.

Nessuna specifica tecnica e nessun mockup. La prima versione è arrivata già completa: template PHP, stili, font, e i box del libro e dei siti modificabili da Aspetto > Personalizza, senza toccare il codice.

Il lavoro vero è stato guardare e correggere

La prima versione era buona, ma non era ancora il mio blog. Il lavoro è iniziato lì, con un giro di revisione alla volta: guardavo il risultato, decidevo cosa cambiare e lo chiedevo.

Ogni mio articolo ha un’immagine, quindi le anteprime in home dovevano mostrarla. Ho molte categorie, e un elenco lunghissimo nella barra laterale era rumore: ora si vedono le otto con più articoli e un pulsante apre le altre. Nella pagina dell’articolo ho tolto del tutto la barra laterale, perché lì conta solo leggere. Infine ho spostato il box degli altri siti sopra le categorie.

Ogni modifica ha richiesto pochi minuti. Ma nessuna di queste decisioni poteva prenderla l’AI, perché dipendevano da come è fatto il mio blog e da come lo voglio.

C’è stato anche un bug vero. Controllando le anteprime su mobile è emerso che i blocchi di codice più lunghi allargavano la pagina oltre lo schermo. Su un blog dove capita spesso di pubblicare codice non è un dettaglio. È stato corretto, ma bisognava accorgersene.

L’AI ha scritto il codice. Sapere cosa volevo, e accorgermi di cosa non andava, è rimasto compito mio.

Cosa c’è dentro Margine

Il nome viene dalle note a margine: quelle che si scrivono leggendo, con l’evidenziatore in mano. Il giallo dell’evidenziatore compare in pochi punti. Sottolinea il titolo dell’ultimo articolo, compare quando passi il mouse sui titoli e colora il box con i miei altri siti.

Alcune scelte non si vedono ma contano.

• Font inclusi nel tema. I caratteri sono salvati dentro il tema e non vengono caricati da Google Fonts. Il browser di chi legge non contatta server esterni, un aspetto che in Europa ha anche risvolti legati al GDPR.
• Leggerezza. Niente framework e un solo piccolo script, quello che apre e chiude le categorie. Se JavaScript è disattivato, le categorie vengono mostrate tutte.
• Pagina dell’articolo. Il testo sta in una colonna di lettura comoda. L’immagine in evidenza è più larga del testo.

Il conto da pagare

Un tema fatto su misura non è gratis, anche se non l’ho comprato.

Non riceve aggiornamenti automatici. Se una nuova versione di WordPress cambia qualcosa, sistemarlo tocca a me. Non c’è un forum di supporto né una community che ha già incontrato lo stesso problema. E un tema non è un file qualsiasi: gira sul server e passa per ogni pagina del sito. Pubblicarlo senza capire cosa fa sarebbe come approvare una pull request senza leggerla.

Per me è un costo accettabile, perché il codice lo so leggere e modificare. Per chi non sviluppa, un tema ben mantenuto resta probabilmente la scelta più sensata. L’AI abbassa il costo di costruire qualcosa, ma non quello di mantenerlo nel tempo.

Cercare o costruire

Per anni la domanda è stata: quale tema scelgo? Per software piccolo e su misura come questo, la domanda sta diventando un’altra: so descrivere quello che mi serve?

Costruire costa sempre meno. Quello che non cala è la fatica di decidere: sapere cosa vuoi, riconoscere quando il risultato non va bene, prenderti la responsabilità di quello che metti online. Chi sa farlo ha un vantaggio vero. Chi non lo sa rischia di passare dal catalogo dei temi a quello delle risposte dell’AI, prendendo la prima che sembra funzionare.

Margine è online e mi piace. Se trovi qualcosa che non va, scrivimelo, oltre all’autore del blog, sono anche il suo sviluppatore.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Perché nell’era dei coding agent, la figura del programmatore diventa più strategica — non per revisionare le righe di codice, ma per decidere se quello che è stato costruito ha senso nel contesto in cui dovrà vivere.

C’è una scena che si ripete ogni giorno in decine di team di sviluppo: uno sviluppatore apre il suo tool AI preferito, descrive in linguaggio naturale una funzionalità, e in pochi secondi riceve indietro un blocco di codice pulito, ben strutturato, documentato. Il codice compila. I test passano. La PR viene aperta.

Fin qui tutto bene. Il problema arriva dopo.

Perché quel codice, tecnicamente ineccepibile, potrebbe essere completamente sbagliato per il sistema in cui dovrà vivere. Potrebbe ignorare le convenzioni interne non documentate da nessuna parte. Potrebbe aggirare un layer di autenticazione aziendale. Potrebbe replicare una logica già esistente altrove nel codebase, ma con un nome diverso. Potrebbe scalare in modo incompatibile con l’architettura scelta tre anni fa per ragioni che il team attuale ha dimenticato.

L’AI non lo sa. Non può saperlo.

Il codice corretto nel contesto sbagliato

Per anni abbiamo dibattuto se l’AI avrebbe “rubato il lavoro ai programmatori”. Era la domanda sbagliata. La domanda giusta è: quale lavoro sta cambiando, e in che direzione?

La risposta che emerge dai dati degli ultimi mesi è chiara: l’AI eccelle nel trasformare intenzioni in codice. È straordinariamente brava a scrivere boilerplate, a generare test, a costruire endpoint CRUD, a scaffoldare UI. Tutto quello che un tempo era il pane quotidiano — e il principale collo di bottiglia — delle squadre di sviluppo.

Quello che l’AI non sa fare è capire il contesto. I senior developer confermano di passare tempo a correggere suggerimenti AI che mancano l’intento architetturale: non perché il codice sia sbagliato in assoluto, ma perché non è quello che quel sistema, in quel momento, con quella storia alle spalle, avrebbe dovuto ricevere.

“L’AI non prende le decisioni difficili su architettura, compliance o sicurezza. Non può capire pienamente la business logic di un’azienda. Quella supervisione resta in mano agli ingegneri esperti.”

Questa non è una critica all’AI. È una descrizione precisa di come funziona: ottimizza sulla base di pattern generali. Ma ogni azienda è una deviazione dai pattern generali.

Non è code review. È validazione contestuale.

C’è una distinzione importante da fare, e spesso viene persa nel dibattito pubblico.

Quando si parla di “supervisione umana sul codice AI”, si pensa immediatamente alla code review tradizionale: qualcuno che legge le righe, controlla la sintassi, verifica la logica. Un processo lineare, scalabile, in qualche modo automatizzabile anch’esso.

Ma quello di cui stiamo parlando è qualcosa di diverso. È la capacità di rispondere a domande che non stanno nel codice:

Questo componente rispetta la nostra strategia di separazione dei dati per i clienti enterprise? Questo pattern di retry è compatibile con i limiti di rate del servizio esterno che usiamo in produzione? Questa struttura del database è coerente con come evolverà il prodotto nei prossimi dodici mesi?

Sono domande che richiedono conoscenza dell’organizzazione, non del linguaggio di programmazione. Richiedono di aver vissuto le scelte passate, di conoscere i vincoli non scritti, di capire dove il sistema sta andando oltre il ticket corrente.

Il programmatore esperto, in questo scenario, non è un controllore di qualità. È un traduttore tra due mondi: l’AI, che conosce il codice, e l’azienda, che conosce se stessa.

Il rischio invisibile: la produttività che nasconde la fragilità

I numeri sulla produttività sono reali. I team che adottano strumenti AI scrivono più codice, aprono più PR, consegnano più velocemente. Ma c’è un dato che viene spesso ignorato: i team che usano AI riportano un aumento del 41% nel code churn e una diminuzione della stabilità del delivery.

Più codice non significa più valore. Significa più superficie da mantenere, più potenziali punti di rottura, più debito tecnico nascosto sotto uno strato di sintassi perfetta.

La produttività individuale sale. La confidenza collettiva no. I developer scrivono più veloce, ma passano più tempo a questionare, revisionare e validare quello che viene spedito. Il collo di bottiglia non è sparito: si è spostato a valle.

E questo è esattamente il punto in cui la figura del senior developer diventa critica. Non per rallentare il processo, ma per dare direzione alla velocità. Per trasformare la quantità di output in qualità di sistema.

Cosa cambia concretamente nel lavoro quotidiano

I dati di inizio 2026 mostrano uno spostamento già in atto: i senior developer riportano che il loro tempo si è redistribuito dall’80% di coding a circa il 60% tra architettura e review, 30% mentoring, e solo il 10% di coding vero e proprio.

Non è una riduzione di valore. È una elevazione del livello in cui il valore viene creato.

In pratica, questo significa spostare l’attenzione da “questo codice funziona?” a domande più profonde: questo codice appartiene a questo sistema? È strutturato in modo che tra sei mesi un altro developer — umano o AI — possa capire le decisioni prese? Si integra con le scelte architetturali esistenti senza creare dipendenze nascoste? Rispetta i vincoli di compliance del settore in cui operiamo?

Il codice generato dall’AI è come un candidato brillante al colloquio: sa rispondere bene alle domande standard. Il programmatore esperto è chi sa fare le domande che non stanno nel template del colloquio.

Il contesto aziendale non è documentabile. Si porta addosso.

C’è un’ultima considerazione, forse la più sottovalutata.

Molto del contesto aziendale che conta — le ragioni di una scelta architetturale fatta due anni fa, la complessità di un’integrazione con un sistema legacy, le aspettative implicite di un cliente chiave — non è scritto da nessuna parte. Vive nella testa delle persone che ci hanno lavorato.

L’AI può leggere la documentazione, i commenti nel codice, i file di configurazione. Non può leggere le discussioni Slack cancellate, le decisioni prese in una call informale, il motivo per cui quella tabella del database si chiama in quel modo che sembra strano ma ha una ragione precisa.

Questo è il vantaggio competitivo del programmatore esperto nell’era dell’AI: non la velocità di scrittura, non la conoscenza dei framework, ma la capacità di portare dentro ogni decisione tecnica il peso specifico di un’organizzazione reale, con la sua storia, i suoi vincoli e le sue ambizioni.

L’AI sa costruire. Il programmatore esperto sa costruire qui, per questo, in questo modo — e sa spiegare perché la differenza conta.

Articolo basato su ricerche e dati da: Veracode GenAI Code Security Report (2025), Gartner (ottobre 2025), daily.dev Vibe Coding Report (2026), Anthropic Agentic Coding Trends Report (2026), CIO.com Senior Developer Roles (2025), formation.dev How AI Changes Senior Engineers (2025).

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Il sipario si è riaperto sui palchi italiani e la musica dal vivo è tornata a vibrare nelle piazze, negli stadi e nei palazzetti. Dopo il silenzio forzato causato dalla pandemia, la voglia di partecipare a un concerto, di cantare a squarciagola insieme a migliaia di persone, è più forte che mai. Tuttavia, questo tanto atteso ritorno ha portato con sé una sorpresa amara: i prezzi dei biglietti sono lievitati in modo esponenziale. Oggi, assistere a un concerto in Italia è diventato per molti un lusso.

Ma cosa si nasconde dietro questa impennata dei costi? E perché la musica, un tempo esperienza popolare e condivisa, sembra oggi sempre più riservata a pochi?

I fattori chiave dietro l’aumento dei costi

Diversi elementi, alcuni globali e altri specifici del mercato post-pandemico, stanno convergendo per spingere i prezzi dei biglietti verso l’alto:

• La Fame da Live: La Domanda Repressa:
  • Anni di restrizioni e annullamenti hanno creato una domanda accumulata enorme. I fan desiderano ardentemente rivivere l’esperienza del concerto, e questa “fame” spinge naturalmente i prezzi verso l’alto. Eventi che vanno sold-out in pochi minuti sono la prova tangibile di questa sete di musica dal vivo.
• Aumento dei Costi di Produzione:
  • L’inflazione generale ha colpito ogni settore, inclusa l’organizzazione di eventi. I costi per il noleggio delle strutture, l’energia (luci, audio), i materiali per scenografie e allestimenti, e i trasporti (carburante per tir e bus turistici) sono aumentati sensibilmente.
  • Anche il personale (tecnici, sicurezza, montatori) ora ha costi maggiori, in parte per adeguamento all’inflazione, in parte per la carenza di alcune figure professionali emerse dopo la pandemia.
  • Le produzioni sono poi sempre più complesse: gli spettacoli attuali spesso richiedono investimenti massicci in tecnologia, schermi LED, effetti speciali che gravano sul budget complessivo.
• Cachet degli Artisti Maggiorati:
  • Le superstar internazionali, e in misura crescente anche gli artisti italiani di primo piano, hanno presumibilmente aumentato i loro compensi. Questo può essere un modo per recuperare i mancati guadagni del periodo pandemico o semplicemente per capitalizzare l’elevata domanda e il successo attuale. Un cachet più alto si traduce direttamente in un prezzo del biglietto più elevato.
• Il Ruolo del Dynamic Pricing:
  • Sempre più piattaforme di vendita adottano il “dynamic pricing”, un sistema di prezzi dinamici. Questo significa che il costo del biglietto non è fisso, ma varia in tempo reale in base alla domanda. Se un concerto è molto richiesto, il prezzo può aumentare man mano che i biglietti vengono venduti, anche per i posti rimanenti. Questo meccanismo, comune nel settore aereo o alberghiero, è relativamente nuovo nel mondo dei concerti e può portare a differenze di prezzo significative per lo stesso settore a seconda del momento dell’acquisto.
• Il Peso del Bagarinaggio Online (Secondary Ticketing):
  • Un problema annoso che si è acuito nell’era digitale è il bagarinaggio online. Piattaforme non ufficiali o singoli rivenditori acquistano in massa i biglietti per poi rivenderli a prezzi esorbitanti, a volte il doppio o il triplo del valore nominale. Sebbene in Italia siano state introdotte norme per contrastarlo, il fenomeno persiste e contribuisce enormemente alla frustrazione dei fan e alla percezione di prezzi “folli”.
• L’Attrattiva dei Pacchetti VIP:
  • Molti artisti e promoter offrono pacchetti VIP che includono posti privilegiati, meet & greet, merchandise esclusivo o accesso a soundcheck. Questi pacchetti, estremamente costosi, riducono la disponibilità di biglietti “standard” a prezzi più accessibili, spingendo i fan a spendere di più per assicurarsi un posto.

L’impatto in Italia: Quando la musica diventa un lusso

In Italia, questa tendenza è particolarmente sentita. Basta confrontare i prezzi di un concerto di un grande artista internazionale oggi con quelli di qualche anno fa per notare un balzo notevole. Un biglietto per un parterre che nel 2019 poteva costare 50-70 euro, oggi può facilmente superare i 90-100 euro, senza contare le commissioni di servizio. Per i posti nelle tribune più costose o i pacchetti VIP, si possono toccare cifre di 200, 300 euro o più.

Questa situazione sta generando una crescente frustrazione tra i fan, che si sentono spesso esclusi o costretti a rinunciare a un’esperienza culturale che prima era più accessibile. Le discussioni sui social media e nei forum online pullulano di lamentele riguardo ai prezzi e alla difficoltà di ottenere biglietti onesti. C’è il rischio concreto che la musica dal vivo, un tempo un’esperienza popolare e inclusiva, diventi sempre più un lusso per pochi.

Conclusioni: Un futuro sostenibile per la musica live?

La musica dal vivo è un motore culturale ed economico fondamentale, capace di creare connessioni uniche tra artisti e pubblico. Tuttavia, l’attuale escalation dei prezzi solleva interrogativi sulla sua sostenibilità a lungo termine. Sarà fondamentale trovare un equilibrio tra i crescenti costi di produzione, le legittime esigenze degli artisti e il potere d’acquisto dei fan. Altrimenti, l’entusiasmo per il ritorno ai concerti potrebbe presto trasformarsi in una melodia amara.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Nell’era dell’intelligenza artificiale, saper “parlare” ai modelli di linguaggio (LLM) è diventato una competenza cruciale. Non si tratta più solo di porre domande, ma di formulare richieste in modo strategico per ottenere le risposte più accurate, creative e utili possibili. Questa disciplina è nota come Prompt Engineering.

Oggi ci immergeremo in questo affascinante campo, prendendo spunto da una fonte d’eccellenza: il whitepaper di Google intitolato “Prompt Engineering“, scritto dall’esperta Lee Boonstra. Questo documento offre una panoramica approfondita e pratica su come ottimizzare l’interazione con i modelli di IA.

Cos’è il Prompt Engineering e perché è così importante?

In parole semplici, il Prompt Engineering è l’arte e la scienza di progettare i “prompt” (le istruzioni o domande che diamo a un modello di IA) per guidare il modello verso l’output desiderato. Con l’avanzare degli LLM, la qualità dell’input influisce direttamente sulla qualità dell’output. Un prompt ben congegnato può fare la differenza tra una risposta generica e una soluzione su misura.

Il documento di Lee Boonstra per Google esplora diverse tecniche e configurazioni, offrendo una road map per chiunque voglia massimizzare il potenziale dell’IA generativa.

Punti Chiave dal Whitepaper di Google: “Prompt Engineering”

Ecco i pilastri fondamentali su cui si basa l’efficacia del Prompt Engineering, come delineati nel documento di Google:

1. Configurazione dell’Output degli LLM (LLM Output Configuration)

Non si tratta solo di cosa chiedi, ma anche di come il modello genera la risposta. Il whitepaper evidenzia parametri cruciali per affinare l’output:

• Output Length (Lunghezza dell’Output): Controllare la quantità di testo generato è fondamentale per evitare risposte troppo brevi o eccessivamente prolisse.
  • Esempio: Se chiedi “Spiegami il cambio climatico”, l’LLM potrebbe dare una risposta molto lunga. Se aggiungi “Spiegami il cambio climatico in 50 parole”, otterrai una sintesi concisa.
• Sampling Controls (Controlli di Campionamento): Questi influenzano la “creatività” o la “determinismo” delle risposte:
  • Temperature: Un valore più alto rende l’output più casuale e creativo (ottimo per brainstorming), mentre un valore più basso lo rende più focalizzato e deterministico (ideale per fatti o risposte precise).
    • Esempio:
      • Temperature alta (es. 0.8): “Scrivi una breve storia sull’incontro tra un unicorno e un astronauta.” -> Potrebbe generare trame molto diverse e inaspettate ad ogni esecuzione.
      • Temperature bassa (es. 0.2): “Qual è la capitale dell’Italia?” -> La risposta sarà sempre “Roma”.
  • Top-K e Top-P: Questi parametri regolano la selezione delle parole successive nella generazione. Top-K limita la scelta alle K parole con la probabilità più alta, mentre Top-P (o nucleus sampling) seleziona le parole la cui probabilità cumulativa supera una soglia P. Entrambi aiutano a controllare la diversità del testo generato.

2. Tecniche di Prompting Fondamentali (Prompting Techniques)

Il documento illustra diverse strategie per formulare i prompt:

• General Prompting / Zero-Shot: Questa è la forma più semplice, dove si fornisce un prompt diretto senza esempi. Il modello deve generare una risposta basandosi solo sulle sue conoscenze preesistenti.
  • Esempio: “Classifica la seguente frase come positiva, negativa o neutra: ‘Il film era un po’ noioso, ma la recitazione era buona.'”
• One-Shot & Few-Shot: Queste tecniche prevedono la fornitura di uno o più esempi nel prompt per mostrare al modello il formato o il tipo di risposta desiderata. Migliorano notevolmente l’accuratezza e la coerenza.
  • Esempio (One-Shot):
    • “Classifica la seguente frase come positiva, negativa o neutra.
    • Testo: ‘Adoro questo libro, è fantastico!’ Sentimento: Positivo
    • Testo: ‘Il film era un po’ noioso, ma la recitazione era buona.’ Sentimento:”
  • (L’LLM imparerà dal tuo esempio come formattare la risposta.)
• System, Contextual e Role Prompting:
  • System Prompting: Imposta istruzioni generali o una “personalità” di base per il modello che persistono attraverso le interazioni.
    • Esempio (impostato all’inizio della conversazione): “Sei un assistente di scrittura creativo. La tua missione è generare idee originali e stimolanti per racconti.”
  • Role Prompting: Assegna un ruolo specifico al modello (es. “Agisci come un esperto di marketing”) per indirizzare il tono e lo stile delle sue risposte.
    • Esempio: “Agisci come un nutrizionista esperto. Dammi tre consigli per una colazione equilibrata.”
  • Contextual Prompting: Fornisce al modello informazioni di sfondo o un contesto specifico per aiutarlo a generare risposte più pertinenti.
    • Esempio: “Considerando che stiamo pianificando un viaggio in Italia a luglio e siamo interessati a storia e arte, quali tre città consiglieresti di visitare e perché?”

3. Tecniche di Prompting Avanzate per il Ragionamento (Advanced Prompting Techniques)

Per compiti più complessi che richiedono ragionamento, il whitepaper approfondisce:

• Step-Back Prompting: Incoraggia il modello a fare un passo indietro e astrarre principi o premesse fondamentali prima di affrontare il problema specifico, migliorando la capacità di ragionamento.
  • Esempio:
    • Prompt originale: “Qual è la capitale dello stato che confina a nord con il Texas?”
    • Prompt Step-Back: “Qual è il concetto più ampio di questa domanda? (Risposta: Identificare una capitale statale dopo aver determinato uno stato basato su confini geografici.)
    • Poi, chiedi all’LLM di rispondere alla domanda originale basandosi sul concetto astratto.
• Chain of Thought (CoT): Insegna al modello a “pensare ad alta voce” e a mostrare i passaggi intermedi del suo ragionamento prima di arrivare alla risposta finale. Questo è estremamente efficace per problemi complessi.
  • Esempio:
    • “Giovanni aveva 5 mele. Ne ha date 2 a Maria e ne ha ricevute 3 da Luca. Quante mele ha ora Giovanni? Pensa passo dopo passo.”
    • Output atteso dall’LLM:
      • “Passo 1: Giovanni inizia con 5 mele.
      • Passo 2: Ne dà 2 a Maria, quindi 5 – 2 = 3 mele.
      • Passo 3: Ne riceve 3 da Luca, quindi 3 + 3 = 6 mele.
      • Risposta: Giovanni ha ora 6 mele.”
• Self-Consistency: Dopo aver usato il CoT, questa tecnica genera più percorsi di ragionamento e poi seleziona la risposta più coerente o frequente tra essi, aumentando l’affidabilità.
  • Esempio: Si chiede al modello di risolvere un problema complesso (es. di logica o matematica) più volte usando CoT, ottenendo diverse “catene di pensiero” e poi si confrontano i risultati per trovare la risposta dominante.
• Tree of Thoughts (ToT): Simile al CoT, ma permette al modello di esplorare più percorsi di ragionamento in modo ramificato, valutando le diverse “filiali” e scegliendo quella più promettente. Ideale per problemi che hanno più soluzioni intermedie o che richiedono esplorazione.
• ReAct (Reason & Act): Combina il ragionamento CoT con la capacità di agire (eseguire azioni o usare strumenti esterni, come la ricerca web). Il modello ragiona su cosa fare e poi esegue l’azione, integrando il ragionamento con l’interazione con l’ambiente esterno.
  • Esempio (ipotetico, se l’LLM ha accesso a strumenti):
    • Prompt: “Qual è il meteo attuale a Roma e la previsione per domani?”
    • Output atteso dall’LLM:
      • Ragionamento: Devo prima cercare il meteo attuale a Roma. Poi devo cercare la previsione per domani a Roma. Infine, combinerò queste informazioni.
      • Azione: Utilizzo lo strumento ‘Ricerca Web’ con la query ‘meteo attuale Roma’.
      • Azione: Utilizzo lo strumento ‘Ricerca Web’ con la query ‘previsioni meteo Roma domani’.
      • Risposta: Il meteo attuale a Roma è [X] e la previsione per domani è [Y].”

Conclusione

Il documento “Prompt Engineering” di Lee Boonstra per Google è una risorsa indispensabile per chiunque voglia padroneggiare l’interazione con i modelli di linguaggio. Comprendere e applicare queste tecniche non solo migliorerà la qualità degli output che otterrai, ma ti aprirà anche nuove possibilità nell’utilizzo dell’intelligenza artificiale per risolvere problemi complessi, automatizzare processi e stimolare la creatività.

Il Prompt Engineering non è solo una moda passeggera, ma una competenza fondamentale che continuerà a evolversi insieme all’IA. Inizia a sperimentare con questi suggerimenti e scopri il potenziale che puoi sbloccare!

Link al documento: Prompt Engineering di Google (Lee Boonstra)

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

“L’uomo è un animale religioso: non smette di credere, cambia solo in cosa.”

Umberto Galimberti

In un’epoca dominata dalla tecnologia e dalla razionalità dei dati, ci aspetteremmo che il pensiero critico regni sovrano. Eppure, nel cuore della Silicon Valley – patria dell’innovazione e del disincanto – qualcosa di profondamente arcaico è tornato a galla: la necessità di credere. E non in Dio, o almeno non nel Dio tradizionale, ma in nuovi idoli, nuovi codici, nuove gerarchie. I CEO non guidano solo aziende: guidano anime.

Il Vangelo secondo Peter Thiel

Peter Thiel, uno dei più iconici venture capitalist della Silicon Valley, non ha mai nascosto la propria ammirazione per la Bibbia. Lo stesso vale, in misura diversa, per Elon Musk, che ha parlato pubblicamente della resurrezione di Cristo come modello di pensiero per l’umanità. Non si tratta di religiosità nel senso confessionale, ma di una forma di fede funzionale: un sistema di valori semplice, rigido, performativo.

Il messaggio? Merito, eccellenza, intelligenza. Spesso in opposizione – neanche troppo velata – a concetti come diversità, equità e inclusione. Alcuni CEO parlano apertamente di “MEI” come antidoto al “DEI”. È una narrazione potente, che mescola l’etica protestante con l’efficienza algoritmica, il destino manifesto con il pitch deck.

Silicon Valley come nuova chiesa

Gli eventi come Code & Cosmos, dove si discute di scienza e Bibbia nello stesso spazio, rivelano che l’ansia esistenziale non è mai sparita. Si è solo travestita da branding. Le aziende diventano chiese, i valori aziendali si trasformano in dogmi. I leader carismatici offrono risposte rapide a domande complesse: chi siamo, dove andiamo, qual è il senso del nostro lavoro.

Il filosofo tedesco Max Weber, già nel primo Novecento, descriveva il legame tra spirito del capitalismo e morale protestante. Oggi quel legame è stato riformulato in chiave postmoderna: la salvezza non si guadagna con la fede, ma con il successo. Non si misura in paradisi ultraterreni, ma in exit milionarie.

Fede o obbedienza?

Il punto cruciale, tuttavia, non è solo cosa viene detto, ma come viene accolto. I giovani founder, i developer, i designer che popolano la Silicon Valley (e oggi anche le sue repliche globali) sembrano desiderosi di seguire visioni forti, anche a costo di rinunciare al dubbio. La fede, in questa forma, non è più un atto spirituale: è un’esigenza strutturale. Serve per orientarsi, per sentirsi parte di qualcosa, per avere un significato.

Ma quando la necessità di senso diventa cieca adesione, il rischio è la rinuncia al pensiero critico. E questo, oggi, è forse il vero campo di battaglia: non tra religione e scienza, ma tra autonomia e delega totale.

Conclusione: fede senza pensiero?

In fondo, non abbiamo smesso di credere. Abbiamo solo spostato il centro del culto. Dalla chiesa alla boardroom. Dal sacerdote al CEO. E questo non è di per sé un male, ma diventa problematico quando smettiamo di interrogarci. Perché una fede che non si pone domande non è fede: è obbedienza.

E se l’era digitale ha bisogno di nuovi valori, forse il primo da recuperare è proprio questo: il diritto al dubbio.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %