Aldo Prinzi's BLOG

Categoria: Professione

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

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

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

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

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

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

    I dati non sono opinioni

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

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

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

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

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

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

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

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

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

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

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

    Lo studente che si corregge il compito da solo

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

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

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

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

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

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

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

    Dall’atmosfera al rigore: l’Ingegneria Agentica

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

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

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

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

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

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

    La lezione strategica

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

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

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

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

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

  • I Senior Dev sono la scialuppa di salvataggio delle aziende tech

    I Senior Dev sono la scialuppa di salvataggio delle aziende tech

    L’AI e il paradosso economico del codice a buon mercato.

    Di recente, Jensen Huang (CEO di Nvidia) ha sganciato una delle sue solite bombe: l’AI non sta rendendo la vita degli sviluppatori più difficile e non sta togliendo lavoro; sta togliendo difficoltà e costi. La sua tesi è lineare: siccome l’AI abbassa i costi di sviluppo, la domanda di software aumenterà in modo esponenziale. Quindi, le aziende assumeranno più programmatori, non meno.

    Sulla carta, Huang ha ragione da vendere. È il vecchio Paradosso di Jevons del 1865 applicato ai token: se rendi una risorsa (il carbone allora, il codice oggi) incredibilmente più efficiente ed economica, non ne consumerai meno. Ne consumerai molta di più, perché sbloccherai una domanda latente gigantesca. Progetti che prima marcivano nel backlog perché “costava troppo svilupparli” diventeranno improvvisamente sostenibili.

    Ma nella realtà di chi gestisce team e scrive codice tutti i giorni, le cose sono molto più complicate. E la chiave per non far affondare le aziende informatiche nei prossimi anni risiede in un fattore che Huang non menziona, ma che i dati gridano forte: l’esperienza accumulata sul campo.

    L’effetto “Canarino nella miniera” e lo stallo dei Junior

    Se l’AI è un moltiplicatore di produttività, perché il mercato dei programmatori entry-level sembra congelato?

    Uno studio monumentale della Stanford University (intitolato, non a caso, “Canaries in the Coal Mine?“) ha analizzato i dati reali sui flussi di pagamento dei lavoratori americani. I risultati descrivono uno shock asimmetrico brutale:

    • I programmatori all’inizio della carriera (22-25 anni) nelle posizioni più esposte all’AI hanno subito un crollo occupazionale relativo del 16%.
    • Nello stesso periodo, l’occupazione per i programmatori senior ed esperti (35-49 anni) negli stessi identici settori è cresciuta del 6-9%.

    Perché questa disparità? Gli economisti di Stanford la spiegano distinguendo tra due tipi di conoscenza: quella codificata e quella tacita.

    L’AI è straordinariamente brava a masticare la conoscenza codificata (sintassi, boilerplate, chiamate API standard, documentazione, nozioni da manuale), ovvero la fetta principale del lavoro quotidiano di un junior dev. Quella parte di codice è stata industrializzata e resa economica.

    Ma l’AI fallisce miseramente davanti alla conoscenza tacita: quel mix di intuito, visione d’architettura, comprensione dei bisogni del business e “trucchi del mestiere” non scritti che un programmatore accumula solo dopo anni passati a risolvere bug in produzione alle tre del mattino.

    Il “Trust Gap”: perché non possiamo fidarci del codice a colpi di prompt

    C’è un altro dato che i sostenitori dell’automazione totale ignorano: la crisi di fiducia nell’AI.

    Secondo il Developer Survey di Stack Overflow, a fronte di un’adozione massiccia dell’AI nei flussi di lavoro (oltre l’80%), la fiducia nella correttezza dei suoi output è crollata dal 40% a un misero 29%. Più del 46% dei programmatori professionisti dichiara di diffidare attivamente dei suggerimenti generati dagli algoritmi.

    I più scettici in assoluto? Proprio i programmatori senior.

    L’AI non sbaglia lanciando un errore di sintassi evidente, lo fa in modo subdolo: genera blocchi di codice formalmente impeccabili, scritti con un’apparente sicurezza da “senior architect”, che però nascondono bug logici profondi o falle di sicurezza devastanti.

    Se metti uno strumento del genere in mano a chi non ha ancora sviluppato il senso critico e l’esperienza necessaria per fare audit riga per riga, ti ritroverai in pochissimo tempo con sistemi instabili, tenuti insieme da “vibrazioni e nastro adesivo digitale”. Il tempo risparmiato a generare il codice viene puntualmente perso (con gli interessi) nella fase di debugging e refactoring.

    I Senior Dev potenziati dall’AI sono la nuova frontiera

    La verità è che l’AI non sta eliminando i programmatori, ma sta ridefinendo drasticamente chi è indispensabile all’interno di un’azienda informatica.

    Per restare a galla e capitalizzare l’abbattimento dei costi di sviluppo, le aziende informatiche non hanno bisogno di un esercito di prompt-engineer junior che copia-incolla righe di codice senza comprenderle. Hanno un disperato bisogno di artigiani del software senior che sappiano agire da validatori, architetti e orchestratori di sistemi complessi.

    Un programmatore con 10 o 15 anni di esperienza, supportato da un assistente AI, diventa una forza distruttiva sul mercato. Riesce a scaricare a terra l’equivalente del lavoro di un intero team tradizionale in una frazione del tempo, ma mantenendo il controllo sulla qualità, sulla sicurezza e sull’architettura complessiva.

    Non è un caso che in Silicon Valley stia nascendo una nuova metrica retributiva: il “token budget” come quarto pilastro della compensazione (accanto a stipendio, bonus e azioni). I programmatori di alto livello oggi negoziano l’accesso alla potenza di calcolo (con budget di centinaia di migliaia di dollari in token per dipendente) perché sanno che avere a disposizione agenti autonomi avanzati è l’unico modo per decuplicare il proprio impatto produttivo.

    In conclusione: l’esperienza non si prompta (scusami il neologismo…)

    Se gestisci un’azienda informatica e pensi che l’AI sia la scusa perfetta per tagliare il personale esperto e sostituirlo con codice generato automaticamente, preparati a pagare un conto salatissimo in termini di debito tecnico e incidenti di sicurezza.

    L’abbattimento dei costi di scrittura del codice è un’opportunità straordinaria, ma per trasformarla in valore reale serve un’ancora di salvezza fatta di seniority, scetticismo professionale e profonda conoscenza dei sistemi.

    L’intelligenza artificiale scrive il codice, l’esperienza costruisce il software

  • Moonshot, Olivetti e il vecchio informatico italiano che a Pechino verrebbe assunto domani stesso.

    Moonshot, Olivetti e il vecchio informatico italiano che a Pechino verrebbe assunto domani stesso.

    Ho letto nei giorni scorsi un reportage di cento ore dentro Moonshot AI, l’azienda di Pechino dietro Kimi, uno dei modelli linguistici più interessanti di questo ciclo.

    Il nome cinese dell’azienda significa letteralmente Dark Side of the Moon, in omaggio ai Pink Floyd, e le sale riunioni portano i nomi delle band rock occidentali, trecento persone le attraversano, l’età media è sotto i trenta, valutazione intorno ai diciotto miliardi di dollari.

    Nessun dipartimento. Nessun titolo. Nessun OKR. Nessun KPI. Niente timbratura in entrata e in uscita. Le responsabilità esistono, ma non sono sezionate fino al molecolare come siamo abituati a vedere nelle grandi aziende occidentali.

    Fin qui, la storia esotica di una startup che si è concessa il lusso di reinventare l’organizzazione. Potrebbe essere una delle tante ma quello che mi ha fermato è un passaggio preciso, dove il giornalista prova a mettere in parole la filosofia di assunzione dell’azienda.

    Moonshot descrive i middle manager delle grandi aziende tech come modelli sovra adattati, persone che hanno passato anni a ottimizzare per un particolare sistema di KPI, un particolare linguaggio di reporting, un particolare gioco politico interno. Il loro algoritmo è diventato ipercompetente in un unico ideale locale. Quando l’ambiente cambia, non riescono più ad adattarsi e non perché siano stupidi, al contrario, proprio perché sono stati bravissimi a rispondere a un contesto che ora non esiste più.

    E assumono invece per quelli che chiamano modelli base: persone con capacità di apprendimento pura, istinto di trasferimento di dominio, la capacità di operare senza coordinate predefinite.

    Cercano attivamente i drifter dotati, gente che magari non ha il curriculum più brillante ma che in qualche dimensione riesce a vedere attraverso il tempo. Almeno cinquanta dipendenti di Moonshot hanno già fondato o cofondato una startup, più della metà ha cambiato ruolo internamente almeno una volta.

    Uno degli ingegneri aveva previsto l’ascesa di DeepSeek e di Kimi stesso già nel 2023, quando nessuna delle due aziende aveva un prodotto reale, leggendo forum di sviluppatori. Il mentore che lo ha portato dentro aveva un unico criterio di selezione, una domanda sola. Questa persona crede di dover far parte di qualcosa di grande?

    Ho chiuso l’articolo e mi sono fatto una domanda molto semplice. Quanti di quei cinquanta lo assumerebbe domani mattina un’azienda italiana?

    La risposta: per chi ha fatto quarant’anni di questo mestiere in questo paese, è zero virgola.

    Il curriculum come totem

    In Italia il curriculum è ancora una reliquia sacra. Si guarda l’università, si guarda il voto di laurea, si guarda l’azienda precedente, si guarda l’anzianità, si guarda il titolo formale. Il drifter dotato, quello che ha cambiato tre settori, che magari non si è laureato, che ha visto arrivare una tecnologia leggendo la gente giusta al momento giusto, in Italia non passa nemmeno il primo screening del recruiter. Viene scartato in automatico, spesso da un software, perché il suo percorso non è lineare.

    E qui c’è la prima inversione di segnale clamorosa. La linearità del percorso, che nell’articolo su Moonshot viene descritta come il sintomo esatto della sovra specializzazione, come il bug che produce i modelli rigidi che poi non sanno più adattarsi, da noi viene ancora letta come una virtù… Un bel curriculum italiano è un curriculum lineare, con avanzamenti regolari, titoli crescenti, nessun buco temporale sospetto, nessun cambio di settore troppo brusco. In altre parole, è esattamente il curriculum di qualcuno che Moonshot, leggendolo, scarterebbe senza nemmeno chiudere il PDF.

    Il titolo come carta d’identità

    A Moonshot i titoli non esistono, sei uno dei trecento e fai quello che va fatto, punto. Ricorda la prima Microsoft. In Italia il titolo è quasi una questione notarile, senior, lead, principal, head of, director, VP, C level, con tutte le gradazioni intermedie che servono a giustificare scatti di carriera e differenze di stipendio che altrimenti nessuno saprebbe spiegare.

    Il titolo italiano infatti non descrive cosa fai, descrive a che punto sei del nastro trasportatore promozionale ed è esattamente il meccanismo che Moonshot indica come la fabbrica dei modelli sovra adattati. Ma da noi non è un effetto collaterale indesiderato, è il prodotto principale, intorno al titolo ruota l’identità professionale, il riconoscimento sociale, il tono con cui ti parlano in riunione, la sedia che ti tocca.

    Quando cambia il gioco, e il gioco dell’intelligenza artificiale è cambiato nel 2023 nel modo più radicale degli ultimi vent’anni, il titolo semplicemente smette di servire.
    Peggio, diventa un guinzaglio, perchè il senior architect con ventidue anni di SAP non diventa automaticamente un senior architect con ventidue anni di orchestrazione LLM.

    Ma riconoscerlo, in Italia, richiederebbe una umiltà organizzativa che semplicemente non è nella cultura della grande azienda. Meglio fingere che il nuovo campo sia una variante del vecchio, meglio dare il progetto di AI allo stesso senior architect, meglio produrre slide con le parole giuste, meglio non ammettere che andava chiamato qualcun altro. Qualcuno, magari, con un curriculum non lineare.

    Gli OKR come coreografia

    Gli OKR sono arrivati in Italia come rituale di importazione, copiati male da Google e applicati perfino peggio. Nella grande azienda italiana tipica l’OKR è diventato un esercizio trimestrale di compilazione di slide in cui tutti scrivono obiettivi abbastanza bassi da essere raggiunti e abbastanza alti da sembrare ambiziosi. Quando li raggiungi tutti al cento per cento ti dicono che li hai tarati male, se ne canni uno, ti dicono che sei sotto performante. Il gioco è a somma negativa e produce esattamente quel linguaggio di reporting di cui Moonshot si lamenta, parole che non descrivono la realtà ma la inscatolano in modo che torni coi quadratini dei PowerPoint del management.

    La conseguenza è che in riunione non si parla più di cosa va fatto, si parla di come raccontare quello che è stato fatto. Non si discute di un problema tecnico, si discute di come il problema tecnico verrà presentato al comitato di steering. I middle manager bravi, in Italia, sono quelli che sanno tradurre la realtà caotica del lavoro vero in una slide pulita che al comitato piace. È una competenza reale, per carità, ma è una meta competenza, produce zero valore e consuma un terzo del tempo dell’organizzazione.

    La gerarchia come coperta termica

    A Moonshot la struttura è piatta per scelta filosofica: sopra le trecento persone ritengono che la suddivisione eccessiva delle responsabilità uccida la capacità di adattamento.

    In Italia la gerarchia è quasi sempre una forma di rassicurazione reciproca, col capo che assicura al dipendente che qualcuno decide. Il dipendente poi rassicura il capo che qualcuno esegue. HR rassicura l’azienda che esiste un organigramma. L’organigramma rassicura gli investitori che c’è governance. Nessuno di questi livelli ha come funzione primaria produrre valore. Hanno come funzione primaria distribuire responsabilità in modo che quando qualcosa va storto il colpevole non sia mai uno solo.

    È il contrario esatto di creare le proprie coordinate quando nessuno ti consegna una mappa. Da noi la mappa è sacra, anche quando è sbagliata. Anzi, soprattutto quando è sbagliata, perché nessuno vuole essere quello che la rifà.

    Il rapporto col fallimento

    A Moonshot cinquanta persone su trecento hanno già fondato o cofondato una startup. Molti sono tornati, molti sono rimasti. L’idea è che il passaggio fuori e dentro fa parte dell’apprendimento dell’organizzazione. Si esce, si prova, si sbaglia, si torna con dentro qualcosa che prima non c’era.

    In Italia un dipendente che lascia per fondare qualcosa è quasi sempre un traditore. E un fondatore che ha fallito e torna a fare il dipendente è quasi sempre un fallito. Non un veterano con cicatrici utili. Un fallito. Le cicatrici in Italia non sono un curriculum, sono uno stigma. Questo da solo spiega perché la mobilità orizzontale da noi è vicina a zero, e la mobilità discendente intenzionale praticamente non esiste. Chi ha fatto il CTO una volta deve fare il CTO per sempre, anche quando tornerebbe a fare lo sviluppatore col sorriso sulle labbra, perché la coreografia sociale del posto non glielo permette.

    L’età come pregiudizio a doppio taglio

    Qui arriviamo al punto che mi interessa di più, e che ho scritto nel titolo. Moonshot ha età media sotto i trenta. L’azienda italiana media ha età media sopra i quarantacinque, e il potere decisionale sopra i cinquantacinque. Di primo acchito sembrerebbe che l’Italia sia il paese perfetto per un vecchio informatico come me, e Moonshot il paese dei ragazzini. La realtà è l’opposto esatto.

    Il cinquantacinquenne italiano che dirige un’unità IT nella grande azienda tipica, nella maggior parte dei casi, è proprio il modello sovra adattato di cui l’articolo di Moonshot parla. Ha passato venticinque anni a ottimizzare per un ambiente specifico. Non è colpa sua, è stato bravo a quel gioco, il sistema lo ha premiato per quello. Il punto è che il gioco è cambiato nel 2023 e nessuno lo ha avvisato. Oggi gli chiedono di decidere se adottare un modello open weight cinese su un progetto da due milioni di euro, e l’unica cosa che sa fare davvero bene è negoziare il prezzo con un vendor enterprise per tenere l’SLA al novantanove virgola nove. Quelle due cose non hanno niente in comune.

    Ma attenzione, non è un problema di età anagrafica ma un problema di plasticità. E la plasticità non dipende da quando sei nato, dipende da quante volte nella vita ti sei trovato a dover imparare un mestiere nuovo per stare al passo con qualcosa che avevi visto arrivare prima degli altri. Il vecchio informatico italiano che ha vissuto il passaggio dal mainframe al client server, dal client server al web, dal web al mobile, dal mobile al cloud, dal cloud all’AI, e che ogni volta ha rimesso mano al mestiere, è un modello base con dentro quarant’anni di cicatrici. È esattamente il profilo che Moonshot sta cercando. Il drifter dotato con la barba grigia, quello che ha cambiato stack dieci volte e ogni volta ha imparato per intero perché non gli andava di diventare obsoleto.

    Quel profilo in Italia esiste, ne conosco tanti. Siamo tanti.

    Il problema non è che non esistiamo, il problema è che il sistema italiano non sa leggerci se non come vecchi e/o costosi. Ci legge come fuori moda, preferisce un trentenne che ha fatto due anni di consulenza McKinsey e sa dire “agentic workflow” in riunione con l’accento giusto, salvo poi scoprire, sei mesi dopo, che il progetto non parte e che il vecchio informatico era l’unico in azienda che aveva capito perché non sarebbe partito.

    Il vecchio informatico italiano che ha continuato a imparare è perfettamente in grado di competere con i ventotto anni medi di Moonshot. Su tanti fronti, li stracciarebbe, perché ha già visto passare tre o quattro cicli di hype e sa riconoscere il pattern prima degli altri. Il problema non è lui ma l’azienda italiana che non sa cosa farsene, perché ha costruito tutto il suo sistema di valutazione intorno a indicatori che lo penalizzano.

    Gli Olivetti avevano ragione

    E qui arriviamo al punto olivettiano, che per me non è un esercizio di memoria storica ma la cosa più attuale che ci sia. Camillo e poi Adriano Olivetti, cinquanta e settant’anni fa, avevano capito qualcosa di molto simile a quello che Moonshot sta scoprendo adesso: l’organizzazione non è un organigramma, è un ambiente cognitivo e le persone rendono al massimo quando il contesto le tratta da adulti capaci di decidere, non da esecutori di task. Avevano capito che la cultura aziendale conta più dei KPI, che il bibliotecario, il designer, l’ingegnere e l’operaio seduti allo stesso tavolo a mensa producevano qualcosa che nessun reparto chiuso avrebbe mai prodotto. Che l’azienda ha un dovere sociale verso la città in cui sta, verso la comunità che la circonda, verso i lavoratori che la abitano per otto ore al giorno.

    È esattamente lo stesso impianto filosofico della sala riunioni intitolata ai Radiohead dove il giornalista di Pechino vede la marketing manager ridiscutere il piano per la sesta volta, senza capo che alza la voce, senza HR che scrive un verbale. Ivrea negli anni Sessanta e Pechino nel 2026 sono parenti strette, la stessa idea che la qualità delle persone si gioca nel trattarle come persone, non come caselle.

    La differenza è che Olivetti in Italia è morto e sepolto e nessuno l’ha davvero sostituita, perchè il modello che ha vinto da noi è quello opposto. Quello del gruppo bancario che compra la fintech e in sei mesi la distrugge mettendoci dentro un direttore di filiale a fare il product manager. Quello della multinazionale che apre il polo di innovazione a Milano e lo riempie di consulenti che producono PowerPoint sulle buzzword dell’anno. Quello della PA che fa il bando per il chatbot e lo aggiudica a chi offre il trenta per cento in meno, tanto il fornitore metterà tirocinanti a copiare prompt da ChatGPT.

    Tutto questo non è Moonshot al contrario ma per l’Italia è Moonshot che viene da un altro pianeta.

    Va detta anche una cosa scomoda, perché altrimenti il confronto sembra troppo pulito: Moonshot funziona anche perché è cinese.

    Ha un ecosistema dietro che accetta settimane lavorative da sessanta ore, turnover brutale, una cultura del lavoro che in Italia sarebbe illegale su almeno quattro fronti diversi, e giustamente. Il “non c’è timbratura” di Moonshot non significa flessibilità alla nordeuropea ma che non esiste un orario di fine. Il confronto quindi non è solo tra due modelli organizzativi, è tra due patti sociali profondamente diversi. Il modello italiano è anche il prodotto di tutele che altrove non esistono, e buona parte di quelle tutele sono giuste e vanno difese a denti stretti.

    Ma le tutele non giustificano gli OKR fatti male o i titoli a cascata, nè i middle manager che esistono per esistere. Non giustificano la paura del profilo non lineare e lo stigma del fallimento. Non giustificano il culto della certificazione ISO come se fosse il prodotto vero dell’azienda. Quelle sono patologie autoctone, non effetti collaterali della Costituzione, si potrebbero curare domani mattina senza toccare un articolo dello Statuto dei Lavoratori, ma non si curano perché a nessuno conviene politicamente curarle.

    La domanda finale

    La domanda che il reportage su Moonshot pone ai team di intelligenza artificiale è molto semplice, e si presta bene ai poster in sala riunioni. State assumendo modelli sovra adattati o modelli base? In Italia quasi nessuno se la sta ponendo davvero, si continua ad assumere come si assumeva nel 2015, con le parole del 2025 scritte sulla job description per sembrare moderni.

    Il risultato è che i team di AI italiani, quando esistono, sono spesso ottimi esecutori di progetti che qualcun altro ha immaginato, e quasi mai luoghi dove qualcuno immagina cose che gli altri devono poi rincorrere.

    Questo mentre in giro per il mondo gente di trent’anni e gente di sessanta con ancora voglia di imparare, sta ridisegnando il mestiere da zero ogni sei mesi (come facciamo in Canonity n.d.r).

    Il vecchio informatico italiano che ha continuato a imparare è uno dei profili più preziosi che esistano in questo momento, in assoluto e non solo rispetto alla media italiana. Ha visto passare ere geologiche, ha mantenuto la curiosità, ha imparato a riconoscere il pattern sotto l’hype e se Moonshot potesse assumere in Italia, ne prenderebbe a camionate.

    Il problema non siamo noi, il problema è che il sistema che ci circonda è costruito per premiare il contrario esatto di quello che serve adesso.

    Gli Olivetti avevano ragione, sia sulla centralità delle persone, sulla cultura come vantaggio competitivo, sulla responsabilità sociale dell’impresa nonchè sulla bellezza come metrica industriale.

    Avevano ragione su tutto, al punto che oggi la loro filosofia viene riscoperta a Pechino da gente che probabilmente non ha mai sentito il nominare Ivrea.

    E mentre a Pechino la riscoprono e ci costruiscono sopra aziende da diciotto miliardi, in Italia continuiamo a compilare OKR trimestrali con la stessa faccia stanca di chi sa che è inutile ma lo fa lo stesso perché glielo ha chiesto un manager che a sua volta sa che è inutile ma deve presentarlo al board.

    A un certo punto qualcuno dovrà pur dirlo ad alta voce. Provo io, intanto.