Il collo di bottiglia nello sviluppo software non è più la scrittura del codice: è decidere cosa costruire, come collegarlo e come mantenerlo man mano che cambia. Per due decenni, la carenza è stata nella capacità produttiva; oggi, la produzione di codice è abbondante ed economica, e la carenza si è spostata interamente sulle decisioni di progettazione che nessuno strumento di generazione di codice può prendere al posto tuo.
Questo ha una conseguenza concreta per qualsiasi azienda che acquisti servizi di sviluppo nel 2026: la tariffa oraria per la scrittura di codice sta diminuendo, mentre il costo di una cattiva decisione architetturale sta aumentando. Acquistare come se fossimo ancora nel 2019, confrontando i fornitori in base a prezzo e velocità, significa ottimizzare la variabile sbagliata.
L'intuito suggerisce che se la produzione di codice è più rapida, i progetti dovrebbero terminare prima. I dati, però, raccontano una storia diversa.
Il report DORA 2024, compilato da Google Cloud a partire da circa 39.000 professionisti del settore, ha rilevato che un aumento del 251% nell'adozione dell'IA era correlato a una diminuzione dell'1,5% nella velocità di consegna e a una diminuzione del 7,2% nella stabilità. Ciò non era dovuto a una qualità intrinseca scadente del codice generato, ma all'aumento delle dimensioni dei batch di modifiche: veniva distribuito più codice contemporaneamente, le revisioni erano meno accurate e il codice presentava più errori. Nello stesso studio, il 39,2% degli sviluppatori ha dichiarato di avere poca o nessuna fiducia nel codice generato dall'IA.
GitClear, analizzando 211 milioni di righe di codice tra il 2020 e il 2024, ha documentato l'altro lato dello stesso fenomeno: il codice sottoposto a refactoring o "spostato" è diminuito da circa 251 TP3T nel 2021 a meno di 101 TP3T nel 2024, mentre il copia-incolla è aumentato da 8,31 TP3T a 12,31 TP3T e i blocchi duplicati sono aumentati di otto volte.
Si scrive di più, si riorganizza di meno. Si accumula.
Lo studio METR del luglio 2025 ha aggiunto una sfumatura che va affrontata con onestà. In una sperimentazione controllata con 16 sviluppatori open-source esperti e 246 attività reali, i partecipanti hanno impiegato 19% in più utilizzando l'IA, anche se si aspettavano di essere 24% più veloci e, dopo il test, credevano ancora di essere stati 20% più veloci. La stessa METR ha riesaminato il disegno sperimentale nel febbraio 2026 per individuare potenziali distorsioni di selezione e una coorte più ampia ha mostrato una differenza molto minore. Il risultato esatto è oggetto di dibattito. Ciò che non è oggetto di dibattito è la scoperta secondaria: la velocità percepita e la velocità effettiva sono disaccoppiate.
Quando la percezione della velocità si disconnette dalla realtà, la disciplina che corregge la rotta non è l'esecuzione, bensì la progettazione.
Non tutte le decisioni tecniche hanno lo stesso peso. La differenza pratica sta tra ciò che può essere cambiato in una settimana e ciò che plasmerà i prossimi cinque anni.
Tipo di decisione | Esempio | Costo della modifica successiva |
Attrezzo | Framework frontend, libreria grafica | Basso: settimane |
Fornitore di modelli | Passaggio da un LLM a un altro | Sotto c'è uno strato di astrazione |
Modello dati | Come rappresentare un cliente o un ordine | Alto: influisce su tutto ciò che è costruito sopra di esso |
Confini tra sistemi | Quale modulo contiene quali informazioni? | Molto alto: riscrittura parziale |
Modello di permesso | Chi può vedere e fare cosa, e con quale tracciabilità | Molto alto: implica sicurezza e conformità |
Le prime due righe sono quelle che generano più confusione nelle riunioni tecniche. Le ultime tre, invece, determinano se, tra tre anni, l'azienda sarà in grado di far evolvere il proprio sistema o se dovrà riscriverlo da zero.
Un esempio concreto che si ripete nella logistica, nelle assicurazioni e nella sanità è la decisione se una "cartella clinica" debba essere un'entità autonoma con un proprio ciclo di vita o semplicemente una vista costruita sopra altre tabelle. Questa decisione viene presa nella seconda settimana di un progetto, quasi sempre senza discussione, e determina per anni se le modifiche possono essere verificate, se è possibile imporre la conservazione dei dati e se la cartella clinica può essere resa disponibile a terzi tramite un'API. Nessun generatore di codice prenderà mai questa decisione, perché non è una questione di programmazione: è una questione di business.
Questo è il lavoro che svolgiamo in sviluppo di software personalizzato [link interno] Prima di scrivere la prima riga: definisci cosa esiste, chi possiede cosa e quale contratto ha ciascun modulo con gli altri.
L'architettura di un sistema aziendale è definita da quattro confini. Quando tutti e quattro sono ben definiti, il sistema si evolve. Quando uno qualsiasi di essi si offusca, il sistema si degrada, anche se il codice è impeccabile.
La frontiera dei dati. Ogni dato dovrebbe avere un unico proprietario: un sistema che lo elabora e altri che lo interrogano. L'alternativa, ovvero tre sistemi che scrivono le stesse informazioni, genera contraddizioni che nessun livello superiore è in grado di risolvere ed è la causa principale della maggior parte dei progetti di business intelligence che si concludono con discussioni su quale sia il numero corretto.
La frontiera dei contratti. I moduli comunicano tramite interfacce esplicite, versionate e documentate. Un contratto è una promessa: "questo è ciò che fornisco, questo è ciò che garantisco, questo è ciò che modifico previo preavviso". Senza contratti, ogni integrazione rappresenta un nuovo accoppiamento e ogni modifica una negoziazione.
Il confine dei permessi. La definizione di chi può vedere cosa e chi può fare cosa dovrebbe essere parte integrante del sistema, non una condizione ripetuta in quaranta punti diversi. Questo confine è diventato cruciale con l'avvento degli agenti di intelligenza artificiale in grado di eseguire azioni: se il modello di permessi si è dimostrato fragile con gli utenti umani, si sgretola con le identità non umane.
Il confine dell'osservabilità. Un sistema in cui è impossibile sapere cosa è successo, quando e perché, non è né gestibile né verificabile. E da quando sono state introdotte componenti probabilistiche nella catena, la tracciabilità ha cessato di essere una buona pratica operativa ed è diventata un requisito di governance.
Questi quattro confini sono ciò che struttura un'architettura componibile, un approccio che sviluppiamo in dettaglio nella nostra analisi su architettura componibile, API e intelligenza artificiale
Non è necessario un audit formale per individuare i primi sintomi. Questi sono gli indicatori che compaiono per primi:
Quando si manifestano tre o più di questi sintomi, aumentare la capacità di sviluppo non accelera nulla. Aumenta solo il numero di persone in attesa che venga presa una decisione di progettazione.
Spesso, l'importanza dell'architettura viene dimostrata in termini ingegneristici, motivo per cui perde terreno nei comitati di gestione. Tradotto in linguaggio aziendale, una buona architettura soddisfa quattro requisiti misurabili:
Riduci i costi derivanti dal cambiare idea. Un'azienda in grado di modificare la propria offerta, il processo di fatturazione o il modello di prezzo in poche settimane compete in modo diverso rispetto a un'azienda che necessita di sei mesi.
Trasforma la tecnologia in una risorsa, non in una spesa ricorrente. Un sistema con una chiara attribuzione della proprietà del codice, documentazione e contratti espliciti è prezioso in fase di due diligence. Un sistema che si affida a un unico fornitore non lo è.
Consente di sostituire i componenti senza dover ricostruire l'intero gruppo. Ciò è particolarmente rilevante per i modelli di intelligenza artificiale, i cui prezzi, funzionalità e politiche di utilizzo cambiano più volte all'anno.
Consente di verificare le decisioni. Con l'inasprirsi del quadro normativo europeo, è fondamentale poter dimostrare cosa ha fatto il sistema e con quali dati; la raccolta di dati è passata dall'essere auspicabile a obbligatoria.
In The Cloud Group, questo processo è formalizzato in TCG-SAF™, il nostro framework per l'architettura dei sistemi: cinque fasi (Visione, Domini, Moduli, Progettazione, Esecuzione) e un unico documento di architettura che governa l'intero processo di sviluppo. Non si tratta di una scelta estetica, ma del motivo per cui possiamo fornire garanzie scritte sulle scadenze: una data può essere confermata solo quando l'ambito del progetto è stato definito prima dell'inizio dei lavori.
Nel momento di massimo entusiasmo, si presumeva che se tutti avessero avuto accesso agli stessi modelli, le capacità si sarebbero uniformate. È accaduto l'opposto. Due aziende con lo stesso accesso agli stessi strumenti ottengono risultati radicalmente diversi, e la differenza risiede nei loro dati proprietari, nella loro conoscenza del settore e nella qualità dell'integrazione tra i loro sistemi.
I modelli diventano merci. Gli strumenti di generazione del codice diventano merci. Ciò che non diventa una merce è la capacità di trasformare funzionalità generiche in un sistema specifico, affidabile e proprietario.
Questa capacità ha un nome antico e piuttosto poco affascinante: ingegneria.
L'architettura del software è l'insieme delle decisioni relative ai componenti da utilizzare, alle informazioni che ciascuno di essi contiene e alle modalità di comunicazione tra di essi. È più importante del codice stesso, perché quest'ultimo può essere riscritto in poche settimane, mentre la modifica del modello dati o dei confini tra i sistemi può richiedere una riscrittura parziale del prodotto.
I sintomi tipici includono: le piccole modifiche richiedono lo stesso tempo di quelle grandi, le stime sono inaffidabili, ogni nuova integrazione costa quanto la prima, ci sono aree del sistema che il team evita di toccare e la conoscenza del flusso di informazioni dipende da una sola persona.
No: la aumenta. Quando generare codice è economico, la scarsità si sposta sulla decisione di cosa costruire e come connetterlo. Il rapporto DORA del 2024 ha rilevato che una maggiore adozione dell'IA è correlata a una minore stabilità delle consegne, proprio perché il volume delle modifiche cresce senza un corrispondente aumento della disciplina di progettazione.
I tre aspetti più costosi da ripristinare sono il modello dati (come vengono rappresentate le entità aziendali), i confini di proprietà tra i sistemi (quale modulo controlla quali informazioni) e il modello di autorizzazioni e tracciabilità. Cambiare framework o fornitori di modelli è relativamente poco costoso.
Dipende dal grado di accoppiamento, ma in genere il costo cresce in modo non lineare nel tempo: ogni mese di sviluppo basato su un confine mal definito aggiunge codice che dipenderà da quella decisione. Ecco perché un audit tecnico preliminare di solito costa una frazione di quanto costerebbe la riscrittura che evita.
Sì. L'approccio usuale consiste nell'isolare il sistema esistente dietro contratti espliciti e sostituire i domini uno alla volta, anziché riscrivere tutto in una volta. Ciò richiede una valutazione preliminare che stabilisca le priorità di modernizzazione dei domini in base al rischio e al valore aziendale.
Sospetti che la tua architettura sia l'ostacolo? Il nostro servizio di audit tecnico del software fornisce una diagnosi scritta di architettura, codice, debito tecnico e sicurezza entro 10 giorni lavorativi a un prezzo fisso. Nessuna proposta commerciale inclusa: prima la diagnosi, poi la decisione. Richiedi la verifica → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
