Codice generato dall'AI: il debito che migliora ogni numero che il management guarda

La riunione di fine trimestre stava andando benissimo, merito del codice generato dall'AI.

Il responsabile tecnico proiettava un grafico con i rilasci degli ultimi tre mesi: la linea saliva.

Il team aveva adottato un assistente di programmazione a gennaio e da allora la lista delle cose da fare si svuotava a una velocità che nessuno ricordava.

Quattro settimane dopo quella riunione, lo stesso sistema si è seduto un venerdì pomeriggio, con i clienti collegati, e nessuno in azienda sapeva spiegare perché.

Ho visto questa scena ripetersi in aziende che non hanno niente in comune tra loro, e ha sempre lo stesso finale: qualcuno apre il file responsabile e si accorge che non lo ha scritto nessuno.

Il codice generato dall'AI non sta sostituendo i programmatori.

Sta facendo una cosa più subdola e costosa: sta riempiendo le aziende di software che funziona e che nessuno è in grado di giudicare.

E il problema non è tecnico, è di contabilità.

Per la prima volta nella storia del software esiste uno strumento che migliora tutti gli indicatori che il management guarda (commit, ticket chiusi, feature consegnate) mentre peggiora tutti quelli che il management non guarda.

Nessuno si accorge di niente finché non arriva il conto.

Questo articolo racconta com'è fatto quel conto: cosa produce esattamente il codice sintetico non supervisionato, come si misura con dei numeri invece che a sensazione, quali scelte tecniche l'AI non può fare al posto tuo e chi, dentro un'azienda, deve essere in grado di dire no.

Se stai adottando questi strumenti in un team, la parte che ti interessa di più è quella sulle due misure che ti fanno ascoltare da chi decide.

Quante strade può prendere il codice dentro una singola funzione, e quante classi devi capire per riuscire a cambiarne una.

Il codice generato dall'AI non è sbagliato: è senza futuro

Torniamo a quel venerdì pomeriggio.

Il sistema non ha ceduto perché qualcuno aveva scritto codice sbagliato.

Il codice compilava.

I test passavano, quelli generati insieme al codice.

Le funzionalità facevano esattamente quello che dovevano fare nei casi normali, ed erano state testate per settimane senza un problema.

È caduto al primo caso che nessuno aveva descritto: cinquecento persone che modificano gli stessi dati nello stesso momento, dopo una migrazione su un archivio di produzione grande venti volte quello di prova.

La ragione è una sola, ed è la frase che vale la pena portarsi via da questo articolo.

L'AI risponde all'ultimo prompt, non al ciclo di vita del tuo sistema.

Genera la soluzione perfetta per il problema che le hai descritto stamattina.

Il tuo sistema, però, deve sopravvivere anche alle prossime mattine per i seguenti anni: requisiti che cambiano, un team che passa da tre a venti persone, un carico che triplica perché l'azienda ha successo.

È la differenza tra un cuoco e chi apre il frigorifero affamato alle undici di sera.

Entrambi producono qualcosa di commestibile.

Solo uno dei due ha in testa anche la cena di domani, la spesa della settimana e il fatto che quel piano di lavoro dovrà essere pulito da qualcun altro.

La conseguenza pratica è che il debito prodotto in questo modo non assomiglia al debito che conosciamo:

Ed è per questo che sfugge a tutte le pratiche di governo del debito tecnico nate quando il codice lo scrivevano solo le persone: quelle pratiche presuppongono che da qualche parte esista qualcuno che sapeva cosa stava facendo.

I sei difetti ricorrenti del codice generato dall'AI

Quello che colpisce, dopo aver visto ripetersi queste situazioni, è che i sintomi si somigliano tutti.

Cambiano le aziende, i settori e i team, e ritrovi sempre gli stessi sei difetti.

Non sono difetti casuali: sono la conseguenza diretta di come funziona lo strumento.

Descrivi un'operazione, ottieni un'operazione.

Tutto quello che non hai nominato nel prompt semplicemente non esiste.

• Metodi che fanno troppe cose: il prompt descrive un'operazione complessa senza scomporla, e ottieni una funzione unica che la esegue tutta. Il risultato è codice che non puoi testare a pezzi, non puoi riusare, e dove per cambiare una riga devi aver capito tutto il resto.
• Confini architetturali ignorati: senza un'istruzione esplicita nel prompt l'AI accede ai dati dal punto in cui riceve la richiesta, cioè un controller ASP.NET Core che interroga direttamente il DbContext, e mescola le regole di business con la presentazione. Da lì in poi qualunque riordino significa riscrivere.
• Errori ingoiati in silenzio: blocchi di gestione delle eccezioni vuoti, o che scrivono una riga generica e proseguono come se niente fosse. In produzione significa dati che si corrompono per ore prima che qualcuno se ne accorga, e a segnalarlo sarà un cliente.
• Test che verificano la propria implementazione: controllano che un certo metodo sia stato chiamato con certi parametri, cioè un Verify di Moq sulla chiamata al repository invece di un assert sul risultato, non che il sistema produca l'esito giusto. Si rompono a ogni riordino e regalano una falsa sensazione di sicurezza, che è peggio di nessuna sicurezza.
• Nessuna gestione degli accessi simultanei: quasi nessun prompt la menziona, quindi in Entity Framework Core non compare nessun controllo di concorrenza sulla riga. Il codice è corretto con un utente su un archivio di prova, catastrofico quando due SaveChanges partono insieme e l'ultimo cancella il lavoro del primo.
• Librerie di terze parti scelte a caso: pacchetti NuGet suggeriti senza guardarne maturità, ultimo aggiornamento o vulnerabilità note. Ti ritrovi una catena di dipendenze che nessuno ha mai guardato in faccia e che nessuno sta aggiornando.

Il filo che li lega è sempre lo stesso: sono tutte cose che una persona esperta considera senza pensarci, perché ha già pagato il prezzo di non averle considerate in passato.

Il problema, quindi, non è lo strumento.

È usarlo senza avere i fondamenti per valutare il suo operato.

Un bisturi in mano a chi conosce l'anatomia salva vite.

In mano a chi non la conosce fa danni con una precisione impressionante.

Con gli assistenti di programmazione funziona in egual modo, e la differenza tra i due scenari non è lo strumento: è chi lo tiene.

Ed è qui che il mercato ha spostato il prezzo.

Come si misura la qualità del codice generato dall'AI: due numeri da portare in riunione

Arriva sempre il momento in cui devi convincere qualcuno che non è un tecnico.

Vai dal responsabile e gli dici che quel codice è fragile.

Lui guarda il grafico dei rilasci che sale e ti chiede su cosa ti basi.

"Secondo me" non è una risposta adatta a quella riunione.

Ed è il motivo per cui le due metriche che seguono valgono più di qualunque argomentazione: trasformano un'impressione in un numero che sta in una slide.

La prima si chiama complessità ciclomatica, l'ha definita Thomas McCabe negli anni Settanta e conta quanti percorsi diversi può prendere l'esecuzione dentro una singola funzione.

È un modo di misurare in quanti modi quel pezzo di codice può comportarsi.

Il codice sintetico prodotto senza supervisione sta tipicamente tra 15 e 30.

Il valore raccomandato per codice mantenibile è sotto 10, quello ancora accettabile non supera 15.

Tradotto per chi decide: ogni punto in più è un caso di test in più da scrivere, un modo in più di rompersi in produzione e un giorno in più di lavoro per il prossimo che dovrà metterci le mani senza aver scritto lui quella funzione.

Quel prossimo, spesso, è la stessa persona che otto mesi dopo, non si ricorda niente.

La seconda metrica misura quante altre classi una classe deve conoscere per funzionare.

Il codice generato da richieste non strutturate sta tipicamente tra 8 e 15, dove il valore sano è sotto 5.

Il significato pratico è immediato: per modificare una cosa devi capirne altre dieci.

È l'effetto domino che trasforma una modifica da mezz'ora in una settimana di lavoro fatta con la paura addosso, e nelle basi di codice con anni di generazione automatica non controllata questi valori arrivano a un punto in cui rifare da zero costa meno che sistemare.

Portati in riunione, i due numeri stanno in due righe:

Questi due numeri, presi insieme, sono lo strumento più efficace che hai per farti ascoltare.

Non chiedono a nessuno di fidarsi del tuo istinto: mostrano una curva che sale mese dopo mese, nello stesso periodo in cui saliva anche quella dei rilasci.

È anche la ragione per cui alcune aziende hanno smesso di aspettare che questa figura arrivi dal mercato e la stanno costruendo internamente.

La chiamano AI Quality Gate Engineer: sta tra l'output degli assistenti e il codice che va in produzione, e le aziende che se la sono costruita in casa la pagano più di uno sviluppatore senior.

La domanda supera l'offerta, perché quella combinazione di competenze architetturali e comprensione degli strumenti è ancora rarissima.

Rarissima significa due cose: che le aziende la cercano e non la trovano, e che nessuno la insegna.

Il Corso Architetto Software Ai nasce per colmare proprio quel vuoto, con revisioni sul tuo codice e sui tuoi numeri.

Non impari a usare meglio l'AI: impari a giudicarne l'output prima che diventi un problema di qualcun altro.

Il debito di sicurezza silenzioso: le falle che nessun test intercetta

C'è una categoria di problemi che non compare in nessuna metrica e che le aziende italiane sottovalutano con più costanza di tutte le altre.

Non fa cadere niente, non rallenta niente, non emerge in fase di test.

Sta lì e aspetta.

Il codice generato funziona, ma non è sicuro per impostazione predefinita, e le falle che produce hanno una forma ricorrente.

Mancano i controlli sui dati che entrano nel sistema, perché lo strumento assume che arrivino già puliti da chi chiama.

È l'assunzione più ragionevole del mondo dentro un esempio, e la più pericolosa in un'applicazione esposta.

Gli oggetti vengono ricostruiti da dati esterni senza un elenco esplicito dei tipi ammessi: è la porta d'ingresso classica per chi vuole far eseguire codice arbitrario al tuo server.

I token di autenticazione vengono gestiti senza verifiche rigorose su scadenza e revoca, il che significa che un accesso tolto a qualcuno può continuare a funzionare per ore.

E ogni tanto spunta un algoritmo di cifratura obsoleto come MD5 o SHA1 applicato a dati sensibili, semplicemente perché negli esempi su cui il modello è stato addestrato c'era.

Quest'ultimo punto merita un momento di attenzione, perché spiega tutti gli altri.

Questi strumenti hanno imparato dal codice che esisteva, e il codice che esisteva conteneva vent'anni di pratiche superate.

Non stanno sbagliando: stanno riproducendo fedelmente una media storica in cui gli errori di ieri pesano quanto le soluzioni di oggi.

Nessuno di questi problemi fa fallire un test.

Tutti diventano un incidente il giorno in cui qualcuno di competente li cerca sul tuo sistema in produzione, e a quel punto la conversazione non è più con il tuo responsabile tecnico: è con un cliente, un ufficio legale e, se hai dati personali, con un'autorità.

Quanto costa il codice generato dall'AI dopo sei mesi: come si vede nelle due metriche

Il conto non arriva sotto forma di catastrofe.

Arriva sotto forma di giornate che si allungano, e per questo quasi nessuno lo collega alla causa.

Nei team che ho seguito dopo un incidente la sequenza è sempre la stessa, e si legge esattamente nei due numeri di prima.

La complessità mediana delle funzioni toccate dall'automazione parte dai valori sani del progetto e nell'arco di sei mesi si assesta stabilmente sopra la soglia di guardia.

L'accoppiamento la segue con un trimestre di ritardo, perché serve tempo perché le classi nuove si aggancino a tutto il resto.

Quando quelle due curve hanno finito di salire, il team se ne accorge da tutt'altra parte.

Le stime iniziano a sbagliare sistematicamente per difetto: una modifica preventivata in mezza giornata ne chiede due, e non perché qualcuno abbia lavorato male, ma perché per toccare una cosa bisogna capirne altre dieci.

Gli incidenti che richiedono un ritorno d'emergenza alla versione precedente crescono in modo esponenziale, e la percentuale di tempo che il team passa a sistemare invece che a costruire supera quella che passava prima di adottare gli strumenti.

Questi numeri non escono da uno studio teorico: escono dalle analisi post incidente dei team che tornano a chiedere supporto architetturale dopo mesi passati ad accumulare debito tecnico senza accorgersene.

La parte crudele è la sequenza temporale.

Il guadagno di velocità è immediato e visibile a tutti. Il costo arriva sei mesi dopo, e si presenta come "il team è meno produttivo di prima".

A quel punto la conclusione più naturale, e più sbagliata, è che serva più automazione.

È lo stesso meccanismo di chi accende un finanziamento per pagarne un altro: sul momento il conto torna, e ogni mese il problema diventa un po' più grande di quanto sembri.

Quali soglie mettere sul codice generato prima che entri in produzione

Rinunciare agli strumenti non serve a niente, ed è una posizione tanto comoda quanto sbagliata e destinata al fallimento.

Quello che serve è un punto di controllo umano competente prima che il codice entri nella base condivisa, attrezzato con criteri espliciti invece che con il buon senso di chi capita a fare la revisione quel giorno.

Su questo conviene essere pratici, perché è il punto in cui la maggior parte dei team si ferma.

Sanno che serve un controllo, non sanno cosa scriverci dentro, e finiscono per adottare una regola generica del tipo "il codice generato va rivisto", che nessuno riesce ad applicare in modo uniforme e che dopo tre settimane sparisce.

Le regole che sopravvivono a tre settimane sono tre, e nessuna riguarda lo strumento:

• Un responsabile umano per ogni modifica: il nome di chi ha accettato quel codice, non di chi ha lanciato il prompt. Se domani quel pezzo si rompe, deve esserci qualcuno in grado di spiegare perché è fatto così. È la regola che da sola elimina metà del problema, perché nessuno mette la firma su qualcosa che non ha letto.
• Soglie numeriche dichiarate in anticipo: sopra 15 di complessità ciclomatica la modifica non passa e va scomposta, sopra 5 classi conosciute si discute il confine prima di scrivere altro. Non "valuteremo caso per caso": due numeri scritti, uguali per tutti, che tolgono la discussione dal terreno delle opinioni e delle simpatie personali.
• I vincoli dentro la richiesta, non dopo: l'architettura, i confini tra i moduli e le convenzioni del progetto devono stare nel prompt prima che il codice esista. Correggere a valle costa dieci volte tanto e produce sempre lo stesso risultato: una toppa coerente con niente.

Sono tre regole banali, e la ragione per cui quasi nessuno le ha non è la difficoltà tecnica.

Richiedono qualcuno con l'autorità per bloccare una consegna, e quell'autorità in azienda va riconosciuta prima, non nel momento in cui serve.

Tutto quello che viene dopo, cioè trasformarle in una politica aziendale scritta, con le zone di rischio e i controlli automatici nella catena di rilascio, è un lavoro diverso e lo trovi spiegato nella governance del codice generato in azienda.

La domanda non è "quanto codice riusciamo a produrre", ma "chi in questa azienda è in grado di giudicarlo".

Se la risposta è una persona sola, quella persona è il vostro punto di rottura.

Se la risposta è nessuno, il conto sta già arrivando, anche se ancora non lo vedete.

Le tre regole le hai lette e sono banali.

La ragione per cui in azienda tua non ci sono non è tecnica: è che manca qualcuno con l'autorità per fermare una consegna, e quell'autorità non arriva con il titolo sul biglietto da visita.

Si costruisce dimostrando, una decisione alla volta, ed è il lavoro che facciamo nel Corso Architetto Software Ai.

Impari a scrivere le soglie, a farle accettare e a difenderle quando qualcuno prova a saltarle.

Siti web e web application: la scelta che l'AI non può fare al posto tuo

Immagina di dover costruire due edifici.

Il primo è una vetrina su una strada: deve essere bella, si deve vedere da lontano, chi passa deve capire in tre secondi cosa vendi.

Il secondo è un impianto industriale: nessuno lo guarda passando, ma dentro ci lavorano trecento persone contemporaneamente e non si deve fermare mai.

Nessuno userebbe lo stesso progetto per entrambi.

Nello sviluppo web succede tutti i giorni, ed è la decisione che nessun assistente automatico prenderà mai al posto tuo, perché richiede di sapere cosa sarà quel sistema tra cinque anni.

La frattura vera non è tra due tecnologie.

È tra chi costruisce siti web e chi costruisce web application.

Sembrano la stessa cosa e non lo sono: hanno modelli di business diversi, curve di valore diverse e compensi radicalmente diversi per chi li costruisce.

Un sito web, per quanto sofisticato, esiste per comunicare: trasmettere contenuti, convertire visitatori, posizionarsi.

Si misura in traffico organico, tempo di caricamento, tasso di conversione.

Il rendering lato server è decisivo, perché i contenuti devono essere leggibili dai motori di ricerca senza che debbano eseguire codice per vederli.

Una web application esiste per gestire processi: coordinare operazioni tra più persone, tenere coerenti i dati mentre tutti scrivono, rispondere in tempo reale agli eventi.

Qui il posizionamento sui motori di ricerca è irrilevante.

Contano reattività, robustezza delle regole di business e capacità di crescere senza perdere coerenza.

Da questa distinzione discende tutto il resto, e chi la salta sbaglia la scelta nell'ottanta per cento dei casi, per quanto buono sia il codice che scriverà dopo.

È anche il punto in cui un assistente automatico è più pericoloso, perché ti darà comunque una risposta.

Gli chiedi come implementare una certa funzionalità e te la implementa, senza mai fermarsi a chiederti se quel sistema sarà una vetrina o un impianto.

Quella domanda deve fartela qualcuno, e se in azienda non c'è nessuno che la fa, la risposta la sceglie il caso.

ASP.NET MVC, Blazor e Minimal API: quale usare e quando

Sviluppare siti web con ASP.NET Core MVC resta la scelta professionale per i siti ad alto traffico dove il posizionamento conta.

Il server restituisce pagine già pronte: i motori di ricerca le leggono senza frizioni e il tempo di risposta iniziale è ottimale, perché il browser non deve eseguire nulla prima di mostrare qualcosa.

Per un blog ad alto traffico, un portale di contenuto o un negozio online con migliaia di prodotti, nel 2026 è ancora il riferimento del mercato professionale.

Blazor per applicazioni web interattive in C# risponde a un bisogno diverso: costruire interfacce ricche e reattive senza scrivere JavaScript, usando lo stesso linguaggio del resto del sistema.

Blazor Server tiene l'elaborazione sul server e sincronizza l'interfaccia attraverso una connessione permanente.

È la scelta giusta per i gestionali interni, dove la rete è affidabile e sotto controllo.

Blazor WebAssembly esegue tutto dentro il browser, elimina la dipendenza continua dal server e permette applicazioni che continuano a funzionare anche quando la connessione se ne va.

Il vantaggio più sottovalutato, però, non è nessuno dei due: è che con un solo linguaggio dal database all'interfaccia i modelli dei dati esistono una volta sola.

Sparisce un'intera categoria di errori, quelli in cui la definizione lato server e quella lato browser si sono allontanate e nessuno se n'è accorto fino al rilascio.

Le regole di validazione si scrivono una volta e valgono da entrambe le parti.

Ed è anche il motivo per cui gli assistenti automatici sbagliano meno su questo tipo di progetti: c'è una sola verità da rispettare, non due che devono andare d'accordo.

C'è poi un dettaglio che decide molte più giornate storte di quanto la sua fama suggerisca, e riguarda quanto vivono i servizi che il sistema costruisce per te.

In ASP.NET Core MVC ogni richiesta apre e chiude il proprio contesto: un servizio nasce con la richiesta e muore con la richiesta.

Tutto prevedibile.

In Blazor Server no.

I componenti vivono quanto dura la connessione dell'utente, che per una sessione lunga significa ore, a volte giorni.

Quello stesso servizio adesso vive quanto la sessione, non quanto l'operazione.

La conseguenza pratica riguarda il contesto di accesso al database, che non è pensato per essere usato da più operazioni insieme.

Condividerlo per tutta la sessione è una bomba a orologeria: due azioni simultanee sulla stessa connessione, e ti ritrovi errori che non riesci a riprodurre in locale.

Insieme arrivano gli accumuli di memoria che crescono in silenzio man mano che gli utenti collegati aumentano.

È esattamente il tipo di problema che un assistente automatico non ti segnalerà mai, perché il codice che ha scritto è corretto: è il contesto in cui gira che non gli è stato raccontato.

Esiste anche una terza strada, spesso trattata come una scorciatoia per pigri e invece perfettamente legittima: le Minimal API di ASP.NET Core.

Introdotte in .NET 6 e migliorate in .NET 8, permettono di definire punti di accesso con una sintassi essenziale, tagliando via la struttura che nei casi semplici non serve a nessuno.

Sono la scelta corretta per servizi specializzati, comunicazioni interne tra parti dello stesso sistema, notifiche in arrivo da servizi esterni e tutti gli scenari dove la struttura completa porterebbe complessità senza portare valore.

Il rovescio è altrettanto netto: la stessa mancanza di struttura le rende inadatte come approccio principale per interfacce con centinaia di punti di accesso.

Lì la rigidità diventa il motivo per cui, tra due anni, qualcuno riesce ancora a orientarsi nel progetto.

Ridotte all'osso, le tre strade si scelgono così:

La scelta giusta si fa sempre guardando la vita prevista dell'applicazione.

Un sistema destinato a evolvere per dieci anni con team che cambiano ha bisogno di una struttura che guidi le decisioni di chi arriverà dopo.

Un prototipo da consegnare in quattro settimane per validare un'ipotesi può nascere snello, e si riscriverà bene se l'ipotesi regge.

Confondere i due contesti è uno degli errori più costosi che un team possa fare nelle prime settimane.

Ed è l'errore che gli strumenti generativi incoraggiano sistematicamente, perché rispondono all'ultima richiesta e non hanno idea di dove finirà quel codice.

Il tuo assistente risponde all'ultima richiesta.

Il tuo sistema deve reggere i prossimi dieci anni.

Quella distanza non la colma nessuno strumento: la colma qualcuno che sa cosa costa ogni scelta tra due anni, e nel Corso Architetto Software Ai è la cosa su cui lavoriamo ogni settimana, sui progetti veri di chi partecipa.

Smetti di scegliere lo stack a sensazione e inizi a sceglierlo in funzione della vita prevista del sistema.

La formazione la faccio di persona, quindi la capienza è quella che è.

Come si misurano complessità ciclomatica e accoppiamento in un progetto .NET

Le soglie servono a poco finché restano un discorso.

Diventano un punto di controllo il giorno in cui chiunque nel team può produrre quei due numeri in due minuti, senza chiedere il permesso a nessuno e senza installare niente.

In Visual Studio il percorso è Analizza, poi Calcola metriche del codice, e si può lanciare sull'intera soluzione o su un singolo progetto.

Il risultato è una tabella con una riga per assembly, per tipo e per metodo, e le colonne che ci interessano sono due: complessità ciclomatica e accoppiamento delle classi.

Accanto compare anche un indice di manutenibilità da 0 a 100 che riassume gli altri: comodo per una fotografia, inutile per una discussione, perché non dice mai quale pezzo è il problema.

Il modo giusto di leggere quella tabella non è dall'alto.

Si ordina per complessità in senso decrescente e si guardano le prime venti righe: sono il tuo debito concentrato, e quasi sempre stanno in tre o quattro file soli.

La misura singola però non dimostra niente, perché non esiste un progetto nato pulito.

Quello che dimostra qualcosa è la stessa misura ripetuta.

Salvi il risultato di oggi accanto al codice, con la data, e lo rifai ogni volta che chiudi una consegna importante.

Dopo tre misure hai una curva, e una curva è l'unica cosa che in riunione batte un grafico dei rilasci che sale.

Chi vuole togliere quella misura dalle mani delle persone la sposta dentro la compilazione.

Gli strumenti di analisi già inclusi in .NET sanno controllare da soli sia la complessità sia l'accoppiamento: di solito sono impostati per limitarsi a segnalare, ma si possono configurare perché trattino il superamento della soglia come un errore vero, alla pari di una parentesi dimenticata.

Da quel momento la soglia smette di essere una raccomandazione che qualcuno ricorda e qualcun altro no: è una compilazione che si ferma.

E una compilazione che si ferma non ha bisogno di autorità per essere rispettata, il che sposta il problema al livello in cui è più facile risolverlo, cioè prima che il codice esista invece che dopo, in una riunione dove qualcuno deve avere ragione.

Un'avvertenza, perché è il punto in cui i team si fanno male da soli.

Attivare quel controllo su una base di codice esistente produce centinaia di segnalazioni il primo giorno, il team lo disattiva entro una settimana e la cosa finisce lì.

Si attiva sul codice nuovo, si congela quello vecchio come punto di partenza accettato, e si guarda solo la differenza.

Visual Studio 2026: gli strumenti che trasformano un sospetto in una misura

Tutto quello che hai letto finora si regge su una condizione: qualcuno deve poter vedere cosa sta succedendo dentro il sistema.

Senza quella condizione, il controllo di qualità è un'opinione contro un'altra opinione.

E tra due opinioni, in riunione, vince quella di chi ha il ruolo più alto.

È per questo che l'ambiente di sviluppo ha smesso di essere una questione di gusti.

Cinque anni fa era il posto dove scrivevi il codice.

Oggi è il posto dove verifichi quello che ha scritto qualcun altro.

Visual Studio 2026 apre una finestra mentre l'applicazione è in funzione, e lì dentro vedi tre cose che in una revisione del codice non vedrai mai.

La prima è ogni domanda che il tuo programma sta facendo al database, nel momento esatto in cui la fa.

Sembra poco.

Poi ti capita questo: carichi cento ordini e per ognuno leggi il nome del cliente, una riga innocua, una proprietà come tante.

Sullo schermo compaiono cento richieste al database, una per cliente, quando ne bastava una sola.

Nel codice quella riga non ha niente di sospetto.

Lì, in fila, con il tempo scritto accanto a ognuna, è impossibile non vederla.

La seconda cosa che vedi è dove finisce il tempo.

Non "il sistema è lento": quale funzione, per quanti millisecondi, chiamata da chi.

La terza sono due fotografie della memoria scattate a distanza di minuti e messe a confronto, così scopri cosa il sistema continua ad accumulare e non butta mai via.

Sono tre problemi che i test non vedono, e non perché i test siano scritti male.

Girano su archivi minuscoli e con un utente solo: là dentro cento richieste al database non costano niente e la memoria non fa in tempo a riempirsi.

Si presentano quando arrivano dati veri e utenti veri.

Cioè in produzione, di venerdì pomeriggio.

Nello stesso ambiente c'è anche il lato che il codice lo scrive, e conviene capire cosa cambia.

Un assistente scollegato dal progetto conosce solo il file che hai aperto.

Un agente che conosce l'architettura che hai scelto e le convenzioni che il team ha adottato può segnalarti quando stai violando una regola che avevi stabilito tu.

Non toglie il bisogno di qualcuno che giudichi.

Cambia solo di cosa si discute: non più "compila", ma "sta dove avevamo deciso".

Resta un ultimo vantaggio, ed è quello che pesa di più in un articolo che parla di debito.

Il codice scritto anni fa su questo stack continua a funzionare, e sono pochi gli ecosistemi che possono prometterlo.

Se la tua base di codice non va riscritta ogni diciotto mesi perché qualcuno ha cambiato idea sulle convenzioni, hai almeno il tempo di ripagare il debito che accumuli.

L'Architetto Software: la figura che l'AI rende indispensabile

Alla fine, tutto converge su una domanda sola: chi, in azienda, ha l'autorità e la competenza per fermare qualcosa.

Non chi scrive più codice.

Chi guarda una modifica e capisce cosa farà al sistema tra due anni, e viene ascoltato quando lo dice.

L'Architetto Software non è un senior con qualche anno in più.

È chi prende un requisito ambiguo, spesso contraddittorio, e lo traduce in una struttura che regga la crescita dell'azienda: una struttura dove venti persone possono lavorare in parallelo senza pestarsi i piedi, e abbastanza flessibile da assorbire requisiti che oggi non esistono ancora.

Con gli strumenti generativi questa figura ha smesso di essere un lusso da grande impresa.

Mentre il codice si produce a una velocità che nessun team riesce più a leggere riga per riga, qualcuno deve guardare l'insieme.

Misurare il debito che si accumula settimana dopo settimana.

Decidere quando fermare le nuove funzionalità per rimettere ordine, e quando invece si può convivere con una soluzione imperfetta, che è una decisione altrettanto professionale.

C'è un modo semplice per capire se in un'azienda questa figura esiste davvero o è solo un titolo sul biglietto da visita.

Guarda cosa succede quando qualcuno propone di fermare una consegna.

Se la risposta è "vediamo dopo il rilascio", quella persona non è un Architetto: è un senior con un titolo più bello.

L'autorità di dire di no è la definizione operativa del ruolo, e, o esiste nell'organigramma, o non esiste da nessuna parte.

Il che spiega anche perché questa figura non nasce dentro i team in cui servirebbe di più.

Chi ha passato cinque anni a consegnare in fretta ha imparato benissimo a consegnare in fretta, e nel momento in cui gli chiedi di valutare l'impatto di una scelta sui prossimi tre anni si trova senza gli strumenti mentali per farlo, non per pigrizia ma perché nessuno gliel'ha mai chiesto prima.

Questa figura non si improvvisa e non si autocertifica.

Non emerge spontaneamente da dieci anni di lavoro senza guida, perché dieci anni senza guida producono dieci volte le stesse abitudini.

Serve esposizione prolungata a sistemi complessi in produzione, con problemi veri da risolvere mentre gli utenti aspettano e qualcuno chiede una stima.

Serve qualcuno che abbia già commesso gli errori architetturali che stai per commettere, così le conseguenze le impari senza pagarle tu o il tuo cliente.

E serve l'abitudine quotidiana a giudicare codice che non hai scritto, incluso quello generato, fino a riconoscere i problemi a colpo d'occhio invece che a incidente avvenuto.

Il resto è studio, e il percorso completo con le competenze e la sequenza in cui affrontarle è scritto in come si diventa Architetto Software.

C'è però una competenza che quel percorso elenca e che quasi nessuno allena davvero, ed è quella che decide le carriere: saper spiegare una decisione architetturale a chi non è tecnico, traducendola in costo, rischio e tempo.

Ho visto progetti morire per un problema di comunicazione, non di tecnica: scelte che tutti gli sviluppatori avevano capito benissimo, e che nessuno era riuscito a spiegare a chi firmava in tempo utile.

Chi sviluppa solo la profondità tecnica resta un ottimo esecutore con un tetto che scoprirà tardi.

Chi sviluppa solo la capacità di parlare diventa un responsabile che non regge la prima riunione difficile.

Servono entrambe, e la seconda si costruisce scrivendo: un documento che metta nero su bianco le alternative valutate, i criteri di scelta e le conseguenze attese, in una forma che chi decide possa leggere e usare.

Nei percorsi questa evoluzione è strutturata di proposito.

Non si lavora solo su come scrivere codice migliore: si lavora su come dimostrare, in euro e in rischio, perché quel codice è migliore.

Perché è l'unica cosa che nessuna ristrutturazione ti può togliere: non sta nell'azienda, sta in quello che gli altri sanno di poter dare per scontato quando ci sei tu.

L'automazione ha cambiato una cosa sola, ma l'ha cambiata per sempre: scrivere codice ha smesso di essere la parte scarsa del mestiere.

Quello che resta scarso è il giudizio, e il giudizio si costruisce in un modo solo, con qualcuno che ti corregge sui tuoi errori, sul tuo codice, sul tuo progetto.

I percorsi li seguo di persona, quindi, il numero di persone che riesco a prendere è limitato e la selezione è reale: se durante la prima chiamata mi accorgo che il tuo problema si risolve in un altro modo, te lo dico e ti risparmio i soldi.

Se invece è la strada giusta, si parte dal sistema che hai davanti oggi, non da un esercizio.

Hai finito questo articolo con qualcosa che la maggior parte dei tuoi colleghi non ha: sai come si misura il danno, sai dove guardare e sai chi dovrebbe poter dire no.

Manca solo la parte che nessun articolo può darti, cioè qualcuno che guardi il tuo sistema e ti dica dove stai sbagliando adesso.

È tutto quello che è il Corso Architetto Software Ai, e non prendo più persone di quante ne riesca a seguire davvero.

Chi esegue specifiche scritte da altri ne troverà sempre, di lavoro.

Chi decide come è fatto il sistema, invece, se lo sceglie.