Salvatore Mosaico · 2026
Nota dell’autore
Questo saggio nasce da un’esperienza professionale diretta. Il metodo MOSAICO è il nome dato dall’autore a un’organizzazione del software fondata sul riuso sistematico e sulla separazione in livelli. Le scene progettuali sono simulazioni costruite per chiarirne le conseguenze nell’epoca dell’intelligenza artificiale. Le prospettive sul lavoro sono riflessioni dell’autore, non previsioni certe.
Indice
- 1. La domanda: se l'IA programma, chi programmerà?
- 2. Il metodo MOSAICO: riuso, livelli e composizione
- 3. Dal riuso del codice al riuso dell'intelligenza tecnica
- 4. Ciò che l'IA sa fare e ciò che ancora non possiede
- 5. Il programmatore sale di livello
- 6. Le nuove competenze decisive
- 7. Simulazione 1: costruire un'applicazione con l'IA
- 8. Simulazione 2: quando il codice funziona ma il prodotto è sbagliato
- 9. Simulazione 3: revisione, sicurezza e guasti
- 10. La formazione dei nuovi programmatori
- 11. Professioni che cambiano e nuovi ruoli
- 12. Il metodo MOSAICO nell'epoca dell'IA
- 13. Conclusione: meno digitazione, più ingegneria
1. La domanda: se l'IA programma, chi programmerà?
Sono stato un programmatore molto capace. Per anni il mio vantaggio non è consistito soltanto nello scrivere bene una singola procedura, ma nel non doverla riscrivere ogni volta. Ho costruito librerie di base per il database, l'interfaccia utente e i servizi ricorrenti; sopra queste ho collocato API di livello 1; sopra ancora le API specifiche dell'applicazione, che chiamavo livello 2. L'applicazione finale utilizzava il livello 2. Così, davanti a un nuovo progetto, una parte molto ampia del lavoro - spesso circa il sessanta per cento - era già disponibile.
Oggi descrivo a un'intelligenza artificiale ciò che desidero e la vedo produrre in poco tempo una buona interfaccia, molte funzionalità e codice in quasi qualsiasi linguaggio. Io stesso ho smesso di sviluppare nel modo tradizionale. Non ho però smesso di costruire applicazioni: utilizzo le competenze accumulate per orientare lo strumento, riconoscere ciò che manca e trasformare un risultato rapido in un buon prodotto.
Da questa esperienza nasce la domanda: quale sarà il futuro dei programmatori? Se la produzione materiale del codice diventa sempre più economica, la professione perde valore oppure cambia oggetto?
La risposta sostenuta in queste pagine è che il programmatore non scompare: sale di livello. Il valore si sposta dalla digitazione delle istruzioni alla comprensione del problema, dall'implementazione locale all'architettura, dalla conoscenza sintattica al controllo del comportamento complessivo. La macchina può moltiplicare il codice; qualcuno deve ancora decidere quale sistema meriti di esistere, come debba essere composto e quando sia abbastanza affidabile da essere consegnato. Il futuro non appartiene a chi scrive più righe, ma a chi sa trasformare meglio un'intenzione in un sistema verificabile.
2. Il metodo MOSAICO: riuso, livelli e composizione
Il nome MOSAICO esprime bene l'idea: un'applicazione non viene scolpita ogni volta da un unico blocco, ma composta con tessere già progettate, provate e compatibili. La creatività non è annullata dal riuso; si sposta dalla fabbricazione di ogni elemento alla scelta e alla disposizione degli elementi.
L'ARCHITETTURA MOSAICO
Librerie di base: componenti stabili per database, interfaccia utente, accesso ai dati, comunicazione e servizi comuni.
Livello 1: API funzionali generali che nascondono i dettagli delle librerie e offrono operazioni coerenti ai progetti.
Livello 2: API proprie dell'applicazione specifica; descrivono il dominio e utilizzano esclusivamente il livello 1.
Applicazione: interfaccia e flussi finali, costruiti attraverso le capacità esposte dal livello 2.
La regola secondo cui il livello 2 utilizza soltanto il livello 1 è decisiva. Impedisce all'applicazione di dipendere direttamente da decine di dettagli tecnici. Se cambia il database o la libreria grafica, l'impatto dovrebbe essere assorbito nei livelli inferiori. Se cambia una regola del dominio, si interviene principalmente nel livello 2.
Questa non è soltanto una tecnica per risparmiare tempo. È una forma di governo della complessità. Ogni livello possiede un vocabolario, un compito e un confine. Le parti inferiori devono essere generali; quelle superiori diventano progressivamente più vicine al problema reale.
Il sessanta per cento già pronto non significa che tutti i progetti siano uguali. Significa che molte difficoltà non sono nuove: autenticazione, persistenza, validazione, visualizzazione, notifiche, gestione degli errori. Separarle dal nucleo specifico evita di confondere infrastruttura e valore del prodotto.
3. Dal riuso del codice al riuso dell'intelligenza tecnica
L'IA amplia radicalmente il principio del riuso. Una libreria tradizionale riusa codice già scritto. Un modello generativo riusa schemi appresi da quantità enormi di esempi e può adattarli a una nuova richiesta. Non recupera soltanto una funzione identica: sintetizza una possibile implementazione.
Il metodo MOSAICO e l'IA, però, non sono la stessa cosa. MOSAICO crea dipendenze esplicite, confini decisi e componenti di cui il progettista controlla l'identità. L'IA può generare rapidamente una soluzione, ma tende a ottimizzare la richiesta immediata. Se non riceve vincoli architetturali, può duplicare logica, attraversare i livelli, scegliere librerie incoerenti e produrre un sistema elegante in superficie ma costoso da mantenere.
Il nuovo riuso ha quindi bisogno del vecchio rigore. L'IA accelera la produzione; l'architettura impedisce che l'accelerazione diventi accumulo. Più codice può essere generato, più diventano importanti le regole che limitano dove quel codice deve vivere e da che cosa può dipendere.
Qui l'esperienza del programmatore esperto conserva un enorme vantaggio. Chi ha già visto sistemi crescere, guastarsi e diventare ingestibili riconosce i costi futuri nascosti in una scorciatoia presente. La macchina vede bene il frammento richiesto; l'architetto deve vedere il ciclo di vita.
4. Ciò che l'IA sa fare e ciò che ancora non possiede
L'IA attuale è molto efficace nel generare strutture di progetto, componenti grafici, query, test, documentazione, conversioni tra linguaggi e implementazioni di funzionalità comuni. È anche un ottimo interlocutore per esplorare alternative o per spiegare un codice sconosciuto.
Ma il fatto che un programma compili e che la schermata sia gradevole non dimostra che il prodotto sia giusto. L'IA non possiede spontaneamente la storia dell'organizzazione, i compromessi concordati con il cliente, le eccezioni non documentate, il significato economico di un errore o la responsabilità delle conseguenze. Può ricevere questo contesto, ma qualcuno deve selezionarlo, mantenerlo coerente e accorgersi di ciò che non è stato detto.
QUATTRO DISTINZIONI ESSENZIALI
Codice valido / requisito corretto: il software può eseguire perfettamente la cosa sbagliata.
Demo / prodotto: una dimostrazione felice non prova sicurezza, resilienza, accessibilità e manutenzione.
Test superato / rischio governato: i test coprono scenari scelti; non certificano automaticamente quelli dimenticati.
Risposta plausibile / decisione responsabile: una soluzione convincente richiede comunque proprietario, controlli e criteri di accettazione.
Dire che l'IA “non è capace di fare MOSAICO” significa allora qualcosa di preciso: può implementarne i pezzi e perfino rispettarne le regole, se gliele forniamo; non è però garante autonoma della continuità architetturale. Senza memoria organizzata, verifiche automatiche e supervisione, ogni nuova richiesta rischia di farle reinventare il sistema.
5. Il programmatore sale di livello
Per molto tempo programmare ha significato tradurre un algoritmo in istruzioni rigorose. Ora la traduzione può essere in parte delegata. Il programmatore diventa sempre più colui che progetta la lingua intermedia con cui persona e macchina collaborano: specifiche, contratti delle API, esempi, test, schemi dei dati, vincoli e criteri di qualità.
Non basta saper chiedere bene in linguaggio naturale. Il cosiddetto prompting è soltanto l'ingresso. La competenza vera consiste nel mantenere coerenza attraverso decine di richieste, capire il codice prodotto, prevedere le interazioni e costruire un processo che renda gli errori visibili presto.
Il passaggio può essere descritto così: da autore di ogni riga a responsabile del sistema; da risolutore di compiti isolati a progettista di confini; da cercatore di sintassi a giudice di alternative; da esecutore a direttore tecnico di agenti software.
Questo non elimina la necessità di saper programmare. Chi non comprende variabili, strutture dati, concorrenza, transazioni, protocolli e complessità non sa controllare ciò che l'IA genera. Il codice diventa forse meno frequentemente scritto a mano, ma deve essere letto con maggiore attenzione.
6. Le nuove competenze decisive
Comprensione del dominio. Tradurre i bisogni vaghi in regole esplicite; distinguere ciò che il cliente chiede da ciò di cui il processo ha realmente bisogno.
Architettura e modularità. Stabilire responsabilità, dipendenze, contratti e direzione delle chiamate. È il cuore del metodo MOSAICO e diventa più importante quando il codice nasce rapidamente.
Specificazione. Scrivere criteri di accettazione, casi limite, esempi e invarianti. Una richiesta precisa vale più di molte correzioni tardive.
Lettura e revisione del codice. Capire comportamento, effetti collaterali e assunzioni di codice non scritto personalmente. Il programmatore del futuro leggerà forse più di quanto digiterà.
Testing strategico. Non soltanto generare test, ma scegliere che cosa deve essere provato: proprietà, confini, errori, integrazioni, regressioni e scenari ostili.
Sicurezza e privacy. Gestire identità, autorizzazioni, segreti, dati personali, dipendenze e superfici di attacco. L'IA accelera anche la produzione di vulnerabilità plausibili.
Osservabilità e diagnosi. Log, metriche, tracce e allarmi devono spiegare il comportamento del sistema in produzione. Un'applicazione generata rapidamente resta opaca se non sa raccontare ciò che le accade.
Valutazione degli strumenti. Scegliere modelli, librerie e piattaforme senza legare il prodotto a una moda. Conoscere costi, licenze, qualità, portabilità e dipendenza dal fornitore.
Comunicazione e responsabilità. Spiegare decisioni tecniche a clienti e colleghi; dichiarare l'uso dell'IA; sapere chi approva una modifica e chi risponde del risultato.
7. Simulazione 1: costruire un'applicazione con l'IA
Immaginiamo di dover realizzare un sistema di prenotazione per un piccolo centro medico. Una richiesta frettolosa potrebbe essere: “crea un'app moderna per gestire appuntamenti”. L'IA produrrebbe probabilmente una bella schermata, un database e alcune operazioni. Ma il progetto non è ancora definito.
RIUNIONE DI PROGETTO · DALL'IDEA AL CONTRATTO
Cliente: Voglio che un paziente possa prenotare rapidamente.
Progettista: Può prenotare qualunque prestazione? Occorre una prescrizione? Chi può vedere il motivo della visita?
Cliente: Alcune prestazioni richiedono approvazione; la segreteria vede i dati amministrativi, non le note cliniche.
Progettista: Allora definiamo ruoli, stati della prenotazione, regole di autorizzazione e conservazione dei dati prima di generare le schermate.
IA: Riceve contratti delle API, schema dei dati, esempi e criteri di accettazione; implementa una prima versione.
Nel modello MOSAICO, il livello 1 offre capacità generali: autenticare un utente, salvare un'entità, inviare una notifica, registrare un evento. Il livello 2 espone operazioni di dominio: richiedere una prenotazione, approvarla, annullarla, verificare la disponibilità. L'interfaccia chiama soltanto queste operazioni.
Il valore del programmatore non è aver digitato il modulo di calendario. È aver scoperto le regole nascoste, impedito che l'interfaccia aggirasse le autorizzazioni e trasformato il requisito in contratti controllabili.
L'IA comprime il tempo tra specifica e prototipo. Ciò rende possibile mostrare presto il prodotto e correggere la comprensione. Ma la rapidità non deve confondere il prototipo con la conclusione.
8. Simulazione 2: quando il codice funziona ma il prodotto è sbagliato
Una piattaforma commerciale applica automaticamente uno sconto del dieci per cento agli ordini superiori a cento euro. L'IA implementa la regola e tutti i test proposti passano. Dopo la consegna emerge che la soglia deve essere calcolata al netto dell'IVA, che alcuni prodotti sono esclusi e che due promozioni non possono cumularsi.
REVISIONE · IL PRIMO ERRORE NON È NEL CODICE
Sviluppatore junior: La funzione è corretta: se totale > 100 applica il dieci per cento.
Responsabile di prodotto: È corretta rispetto a una specifica incompleta.
Architetto: La logica promozionale è finita nell'interfaccia. Deve stare nel livello 2, essere indipendente dalla UI e ricevere un totale qualificato.
Revisore: Aggiungiamo esempi contrastanti: 99 euro netti più IVA; 110 euro di prodotti esclusi; due promozioni contemporanee.
La lezione è fondamentale: il debugging non riguarda soltanto il codice. Esiste un debugging dei requisiti, dell'architettura e del modello mentale. L'IA può correggere rapidamente una funzione, ma non può indovinare con affidabilità una politica commerciale mai formulata.
Il programmatore del futuro deve quindi saper fare domande che producano differenze osservabili. Un buon caso di prova non conferma soltanto il comportamento atteso; separa interpretazioni alternative del requisito.
9. Simulazione 3: revisione, sicurezza e guasti
Consideriamo una funzione generata dall'IA per eliminare un utente. La risposta cancella la riga principale e restituisce “operazione riuscita”. Sembra completa. Una revisione professionale deve però chiedere: che cosa accade agli ordini? Ai documenti fiscali? Ai consensi? Ai log? La cancellazione è consentita oppure occorre anonimizzare? Un amministratore può eliminare se stesso? L'operazione è reversibile?
CHECKPOINT PRIMA DEL RILASCIO
Correttezza: sono definiti invarianti, transazioni e comportamento in caso di operazione parziale?
Sicurezza: l'identità è verificata e l'autorizzazione controllata sul server, non soltanto nella UI?
Dati: sono rispettati conservazione, minimizzazione, audit e relazioni tra entità?
Resilienza: che cosa succede se database, rete o servizio esterno non rispondono?
Osservabilità: un operatore potrà capire che cosa è avvenuto senza esporre dati sensibili?
Queste domande mostrano perché il software professionale non coincide con il testo sorgente. Comprende dati, infrastrutture, procedure operative, persone, responsabilità e conseguenze. L'IA può assistere ciascun controllo; non elimina la necessità di decidere quali controlli siano obbligatori.
La produttività non può essere misurata soltanto in funzionalità generate. Una squadra è produttiva quando consegna valore senza accumulare rischi invisibili. Il codice prodotto oggi diventa manutenzione domani.
10. La formazione dei nuovi programmatori
Se gli studenti possono generare un programma intero, continuare a valutarli soltanto sulla capacità di scriverlo da zero conduce a due risultati: uso nascosto dell'IA oppure esercizi artificialmente sorvegliati. La formazione deve includere lo strumento e spostare l'attenzione sul pensiero informatico.
Le basi restano indispensabili: algoritmi, strutture dati, logica, sistemi operativi, reti, database e principi dei linguaggi. Non perché ogni dettaglio debba essere ricordato, ma perché queste conoscenze permettono di formulare ipotesi e diagnosticare errori.
UNA POSSIBILE PROVA DI PROGRAMMAZIONE
Parte A · Lettura: spiega il comportamento di un codice generato e individua dipendenze ed effetti collaterali.
Parte B · Progettazione: definisci API, dati, invarianti e casi limite prima dell'implementazione.
Parte C · Uso dell'IA: genera una soluzione dichiarando richieste, strumenti e modifiche effettuate.
Parte D · Verifica: scrivi test capaci di smentire la soluzione e analizza un errore introdotto deliberatamente.
Parte E · Difesa orale: motiva le scelte e modifica il progetto quando cambia un requisito.
Un esercizio particolarmente utile consiste nel fornire un'applicazione funzionante ma mal progettata. Gli studenti devono separarla in livelli, ridurre le dipendenze e spiegare che cosa diventa riutilizzabile. È una formazione molto vicina al metodo MOSAICO e al lavoro reale.
Imparare a programmare nell'epoca dell'IA significa anche imparare a non delegare troppo presto. Prima si formula un piano, poi si chiede aiuto; prima si prevede il comportamento, poi si esegue; prima si definisce un criterio di correttezza, poi si accetta la risposta.
11. Professioni che cambiano e nuovi ruoli
Le previsioni serie sull'occupazione invitano alla cautela: l'esposizione all'IA riguarda soprattutto compiti, non automaticamente intere professioni. Per gli sviluppatori junior il rischio più concreto è la compressione delle attività semplici con cui in passato si imparava sul lavoro. Questo rende urgente creare apprendistati nei quali i giovani possano comunque fare esperienza di diagnosi, revisione e responsabilità crescente.
Diminuirà il valore relativo di alcune attività: scrivere codice ripetitivo, cercare sintassi elementare, convertire meccanicamente formati, produrre CRUD standard o prime bozze di interfaccia. Crescerà invece il valore di chi sa integrare sistemi, governare dati, verificare sicurezza, progettare esperienze d'uso, valutare l'output dell'IA e assumere responsabilità sul risultato.
Emergeranno ruoli ibridi: product engineer capaci di muoversi tra problema e implementazione; architetti di piattaforma che costruiscono i “livelli 1” aziendali; responsabili della qualità dei sistemi generati; specialisti di sicurezza per catene di sviluppo assistite; curatori del contesto che mantengono specifiche, documentazione e regole accessibili agli agenti.
Ma il titolo professionale conta meno della combinazione di competenze. Il programmatore più solido unirà profondità tecnica, conoscenza del dominio, capacità di comunicare e disciplina nel controllo. L'Europa continua a segnalare una carenza di specialisti ICT avanzati, in particolare in IA e sicurezza: la domanda non scompare, diventa più selettiva. Il pericolo maggiore non è che l'IA sostituisca tutti i programmatori. È che un'organizzazione confonda la facilità di produrre una demo con la capacità di governare un sistema reale.
12. Il metodo MOSAICO nell'epoca dell'IA
Il metodo MOSAICO può evolvere da collezione di librerie a piattaforma intelligibile anche per l'IA. I suoi livelli devono diventare non soltanto codice, ma contratti: documentazione concisa, esempi d'uso, schemi, test automatici e divieti espliciti.
Il livello 1 dovrebbe offrire percorsi preferenziali sicuri: accesso ai dati, autenticazione, logging, errori, configurazione. Il livello 2 dovrebbe parlare la lingua dell'applicazione e impedire alla UI di conoscere l'infrastruttura. L'IA riceve queste regole come contesto e genera soltanto entro i confini stabiliti.
MOSAICO + IA · PROCESSO OPERATIVO
1. Intento: descrivere l'obiettivo, gli utenti, i vincoli e ciò che non deve accadere.
2. Architettura: assegnare ogni responsabilità al livello corretto e definire i contratti.
3. Generazione: far produrre all'IA una modifica piccola, tracciabile e coerente con i componenti esistenti.
4. Verifica: eseguire test, analisi, revisione umana e controllo dei casi limite.
5. Consolidamento: quando una capacità è realmente generale, promuoverla nel livello riutilizzabile appropriato.
In questa forma il metodo non viene superato dall'IA: diventa la struttura che consente all'IA di essere produttiva senza disordinare il sistema. L'intelligenza generativa fornisce velocità locale; MOSAICO fornisce memoria architetturale.
C'è anche una nuova possibilità. In passato il costo di generalizzare un componente poteva superare il vantaggio immediato. Oggi l'IA riduce il costo di documentare, testare e adattare. Il riuso può quindi crescere, purché non si trasformi in astrazione prematura: si promuove una tessera soltanto dopo averne riconosciuto la vera generalità.
13. Conclusione: meno digitazione, più ingegneria
La programmazione non è mai stata soltanto scrittura di codice. Il codice era il mezzo obbligato attraverso cui un'intenzione diventava comportamento. Ora quel mezzo può essere prodotto in parte da una macchina. La responsabilità del comportamento, però, non scompare.
Il programmatore del futuro dovrà saper definire problemi, disegnare confini, comporre servizi, leggere codice, progettare prove, controllare rischi e comprendere le persone che useranno il sistema. Dovrà conoscere l'IA abbastanza da sfruttarla e l'informatica abbastanza da non esserne ingannato.
La mia esperienza personale conduce a un paradosso solo apparente: ho smesso di sviluppare nel vecchio senso, ma continuo a costruire applicazioni. L'IA esegue una parte maggiore del lavoro materiale; le competenze maturate negli anni mi consentono di scegliere, dirigere, correggere e riconoscere un buon prodotto.
Il metodo MOSAICO anticipava questa trasformazione. Già allora il vantaggio non consisteva nel riscrivere tutto, ma nell'organizzare ciò che era stato appreso e nel comporre rapidamente una soluzione nuova. Oggi le tessere possono anche essere generate; resta essenziale il disegno del mosaico. L'IA non rende inutile il programmatore. Rende meno preziosa la semplice produzione di righe e più preziosa la capacità di attribuire a ogni riga un posto, uno scopo, una prova e una responsabilità.
Il futuro del programmatore non è competere con la macchina nella velocità di scrittura. È diventare la persona capace di dire alla macchina che cosa costruire, di capire che cosa ha realmente costruito e di rispondere delle conseguenze.
Riferimenti essenziali
- International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure (2025): l'esposizione tende a trasformare i compiti più che a cancellare automaticamente intere professioni.
- International Labour Organization, The future of work: How will junior programmers be affected? (2025): attenzione particolare ai percorsi di ingresso e alle attività formative dei programmatori junior.
- Commissione europea, State of the Digital Decade 2025: diffusione crescente di IA, cloud e big data, insieme alla persistente scarsità di competenze ICT avanzate.
- ACM / IEEE-CS / AAAI, Computer Science Curricula 2023: formazione informatica fondata su competenze, responsabilità professionale e integrazione delle nuove aree dell'IA.
- David Parnas, On the Criteria To Be Used in Decomposing Systems into Modules (1972): modularità come occultamento delle decisioni soggette a cambiamento.
- Fred Brooks, No Silver Bullet (1986): distinzione tra complessità accidentale e complessità essenziale del software.
Testo concepito per la pubblicazione online. È consentita la citazione di brevi estratti con indicazione dell’autore e del titolo.
Leggi anche
Matematica nell’epoca dell’intelligenza artificiale