Il tuo team scrive codice più in fretta. Sa ancora com'è fatto il sistema che sta costruendo?
L'AI ha alzato la velocità di produzione senza alzare quella di comprensione. Il Dio del Codice è il riferimento tecnico che dà a un team .NET il linguaggio comune per giudicare il codice generato invece di accettarlo.
Richiedi il libro per te o per il team
Le pull request sono raddoppiate. Il tempo per revisionarle no.
Il codice funziona, ma nessuno sa più spiegare perché è fatto così.
Il debito tecnico non si accumula più a velocità umana.
La velocità è aumentata. Il controllo no.
Negli ultimi due anni la produttività apparente dei team di sviluppo è cresciuta in modo evidente. Le funzionalità arrivano prima, i task si chiudono più in fretta. Su questo non c'è discussione.
Quello che è cresciuto molto meno è la capacità del team di rispondere a tre domande che, in un'azienda, valgono più della velocità.
Le tre domande che oggi mettono in difficoltà quasi tutti i team
Perché questa parte è fatta così? Se la risposta è "l'ha generata Copilot e i test passavano", non è una decisione tecnica: è un'adozione.
Dove sono davvero i dati di questa entità? Se servono venti minuti e tre persone per ricostruirlo, il modello dati non è più governato.
Cosa succede se cambiamo questo pezzo? Se nessuno sa rispondere senza aprire l'IDE e cercare, i confini del sistema si sono dissolti.
Non è un problema di strumenti. Copilot, Claude Code e gli agenti che useremo l'anno prossimo sono strumenti straordinari, e chi li rifiuta per principio sta solo scegliendo di andare più piano. Il problema è che producono codice plausibile a una velocità superiore a quella con cui un team riesce a capirlo, e la differenza tra le due velocità si accumula da qualche parte.
Si accumula nel debito tecnico. Solo che prima si formava alla velocità di una persona che scrive. Adesso si forma alla velocità di una macchina che genera.
Cosa è cambiato con l'AI e cosa non è cambiato affatto
Buona parte della confusione nasce dal trattare l'AI come una rottura totale con il passato. Non lo è. Alcune pratiche sono diventate meno rilevanti, altre sono diventate decisive proprio ora.
| Pratica | Prima dell'AI | Oggi |
|---|---|---|
| Scrivere codice a mano | Il grosso del lavoro | Una parte minore, e continuerà a scendere |
| Ricordare la sintassi | Utile | Sostanzialmente irrilevante |
| Leggere codice altrui | Competenza importante | Competenza centrale. Il codice generato è, a tutti gli effetti, codice scritto da altri |
| Definire confini | Buona pratica | Condizione di sopravvivenza. Senza confini l'AI genera ovunque |
| Test come specifica | Disciplina virtuosa | Unico modo per accettare modifiche ampie che non hai scritto tu |
| Conoscere i design pattern | Serviva per scriverli | Serve per riconoscerli in ciò che leggi e capire se sono usati a proposito |
| Motivare una scelta architetturale | Compito dell'architetto | Compito dell'architetto, con una differenza: ora nessuno strumento lo farà al posto suo |
L'AI ha svalutato la scrittura e ha rivalutato il giudizio. Un team che ha investito in architettura, test e pattern oggi va molto più veloce con gli stessi strumenti. Un team che non lo ha fatto sta accumulando un sistema che nessuno controlla, più in fretta di prima.
I quattro sintomi della black box
Nessuno decide di costruire una black box. Ci si arriva un merge alla volta.
La review si è svuotata
Le pull request passano da 200 a 2.000 righe. Formalmente vengono revisionate, di fatto vengono approvate. Nessuno legge duemila righe con l'attenzione con cui ne leggeva duecento.
Le convenzioni si sono sdoppiate
Nella stessa solution convivono tre modi di gestire gli errori, due di accedere ai dati, quattro di validare un input. Ognuno era corretto nel prompt in cui è nato. Insieme sono un sistema senza standard.
Il modello dati è diventato opaco
Entità duplicate con nomi simili, campi calcolati in due punti con logiche diverse, migrazioni generate senza rileggerle. La domanda "qual è la fonte di verità" non ha più una risposta rapida.
La conoscenza è uscita dal team
Il sapere su come funziona il sistema non è più nelle persone né nella documentazione: è in un prompt scritto tre mesi fa e mai salvato. Quando quella persona va in ferie, il sistema diventa illeggibile.
Nessuno di questi sintomi si manifesta come un bug. Il software funziona. Si manifestano come stime che saltano, incidenti che nessuno sa spiegare e, alla fine, come una richiesta di riscrittura presentata alla direzione.
L'AI esegue. L'architettura decide.
C'è una separazione che va tenuta ferma, ed è l'unica cosa che rende sostenibile l'uso intensivo degli assistenti: un modello esegue benissimo una decisione architetturale, ma non è nelle condizioni di prenderla.
Non è una questione di potenza. È una questione di informazioni. Un modello non sa quali funzionalità sono già state promesse a un cliente, chi manterrà quel codice fra due anni, quale modulo è già stato venduto come componente separato, quale vincolo contrattuale impedisce di spostare quei dati altrove. Nessuna finestra di contesto contiene queste cose, perché non stanno nel repository: stanno nelle riunioni.
Quando si lascia decidere al modello non succede niente di drammatico nell'immediato. Succede che la decisione viene presa comunque, in modo implicito, dal primo suggerimento accettato. E una decisione architetturale implicita è esattamente la definizione di black box: una scelta che vincola il sistema e che nessuno ha mai discusso.
Delega all'AI
Estrarre metodi e rinominare in modo coerente.
Scrivere i test che nessuno ha voglia di scrivere.
Tradurre uno schema o un contratto in codice.
Passaggi meccanici e reversibili, dove vale i soldi che costa.
Tieni per te
Dove finisce un modulo e dove inizia il prossimo.
Chi possiede un dato e chi può scriverlo.
Quale contratto esponi all'esterno e come lo fai evolvere.
Tutto ciò che definisce confini, cioè i prossimi cinque anni di manutenzione.
Le quattro superfici con cui si mantiene il controllo
Non servono strumenti nuovi. Serve usare seriamente quattro cose che molti team avevano derubricato a buone intenzioni.
L'architettura come vincolo, non come diagramma
Un'architettura serve se impedisce qualcosa. Se il livello di dominio non può referenziare quello di infrastruttura, l'AI non può scriverci dentro una query, per quanto glielo si chieda male. Architettura esagonale, separazione a strati e confini di modulo diventano il perimetro entro cui la generazione è libera di muoversi senza fare danni.
I test come specifica eseguibile
Su codice che non hai scritto, i test smettono di essere una buona pratica e diventano la condizione che rende accettabile il merge. Prima i test di caratterizzazione sul comportamento attuale, verificati a mano, poi la modifica assistita. Se passano prima e dopo, la modifica è difendibile in review.
Con un'avvertenza che pochi considerano: un modello che scrive test guardando l'implementazione produce test che confermano il codice, non che ne verificano il comportamento atteso. Un test che riproduce un bug esistente lo congela per sempre.
I design pattern come vocabolario condiviso
Il valore dei pattern non è mai stato scriverli: era avere un nome comune per una struttura ricorrente. Oggi quel valore è cresciuto, perché serve a leggere in fretta ciò che l'AI genera. "Qui ha messo uno Strategy dove bastava un metodo" chiude una discussione in dieci secondi. Senza quel vocabolario, la stessa review diventa un'ora di opinioni.
Le decisioni scritte, non ricordate
Ogni scelta strutturale va scritta con la sua motivazione e le alternative scartate. Non serve un processo pesante: servono poche righe versionate insieme al codice. È l'unico antidoto reale alla black box, perché trasforma una decisione implicita in un documento che il prossimo sviluppatore, e il prossimo modello, possono leggere e rispettare.
Il debito tecnico alla velocità della macchina
C'è una ragione precisa per cui il codice generato senza presidio produce più debito di quello scritto a mano, e non è la qualità del singolo frammento. Spesso il singolo frammento è migliore della media di quello che scriverebbe uno sviluppatore stanco alle sei di sera.
La ragione è che un modello ottimizza per la richiesta che ha davanti, non per il sistema in cui la risposta finirà. Gli chiedi un endpoint che salva un ordine e ottieni un controller che apre il contesto, valida, salva e restituisce. Funziona. Poi serve anche la mail di conferma, e finisce nello stesso metodo. Poi il log su un servizio esterno. Dopo tre iterazioni hai un controller che fa cinque cose, non testabile senza database, e nessuno ricorda quale transazione protegga cosa.
Il codice non era sbagliato in nessuno dei tre passaggi. Mancava una decisione su dove finisse la responsabilità di quel controller, e quella decisione il modello non la prende. La prende chi conosce il sistema, oppure non la prende nessuno.
Con un presidio tecnico
L'AI accelera dentro confini decisi da persone.
Le review restano possibili: il diff è leggibile e atteso.
Il team legge di più e, leggendo, impara.
La conoscenza resta nel repository e nelle persone.
Senza
L'AI accelera anche la produzione di scelte mai discusse.
Le review diventano un rituale di approvazione.
Il team consegna ma non impara: dipende dallo strumento.
La conoscenza evapora insieme alle sessioni di chat.
Dove sono davvero i dati, e chi li possiede
Il codice si riscrive. I dati no.
È il motivo per cui la perdita di controllo sul modello dati è il danno più caro fra quelli che l'uso indiscriminato dell'AI può produrre, e anche il più silenzioso.
Un assistente che non vede il quadro completo tende a risolvere il problema che ha davanti aggiungendo: una colonna qui, una tabella di appoggio lì, un campo denormalizzato perché la query era lenta. Ogni intervento è ragionevole preso da solo. Dopo sei mesi la stessa informazione vive in tre posti, aggiornata da due percorsi diversi, e nessuno sa quale sia quello autorevole.
Le domande a cui un responsabile tecnico deve saper rispondere sempre
Qual è la fonte di verità di ogni entità del dominio, e chi ha il diritto di scriverla.
Quali dati escono dal perimetro aziendale, verso quali servizi e con quali garanzie contrattuali.
Quale codice può modificare lo schema, e come quella modifica arriva in produzione.
Cosa si rompe, e per chi, se quel dato cambia forma.
Un sistema è sotto controllo quando puoi cambiarlo senza avere paura, non quando funziona. La differenza tra le due condizioni si misura il giorno in cui un cliente chiede una modifica che tocca il modello dati.
Cosa contiene il libro, in concreto
300 pagine dense, senza esercizi scolastici e senza codice di riempimento.
Fondamenti di C# e .NET, partendo dal perché
Il linguaggio, la piattaforma, l'ambiente e i criteri con cui si sceglie uno stack. Non la sintassi: le regole con cui si prende una decisione tecnologica e la si difende davanti al team e alla direzione.
24 design pattern, con i casi in cui non vanno usati
I 23 pattern della Gang of Four più il Null Object, ognuno implementato in C#, con il ragionamento su costo, alternativa più semplice e segnali di uso improprio.
Creazionali
Abstract Factory, Builder, Factory Method, Prototype, Singleton
Strutturali
Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Comportamentali
Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor, Null Object
12 architetture valutate su progetti reali
Layered, esagonale, MVC, MVVM, DDD, CQRS, event driven, microservizi, peer to peer e le altre. Per ciascuna: il problema che risolve, il costo che introduce, il contesto in cui diventa un errore.
Il rapporto con l'AI nello sviluppo professionale
Come cambia il mestiere quando la scrittura si automatizza, cosa resta umano e perché chi sa progettare aumenta di valore mentre chi si limita a produrre diventa sostituibile.
Metodo e disciplina tecnica
Il sistema SHARP per gli obiettivi di crescita, gli effetti Dunning-Kruger e impostore dentro un team tecnico, le abitudini che distinguono chi consolida competenza da chi accumula corsi.
Per chi è questa edizione
CTO e direttori tecnici
Hai adottato gli assistenti AI e cerchi un criterio per capire se il team li sta usando bene. Ti serve un riferimento comune da mettere in mano a persone con seniority diverse.
Team lead e architetti
Devi decidere quali strumenti entrano nel team, con quali regole, e difendere quelle decisioni davanti agli sviluppatori e alla direzione.
Sviluppatori senior .NET
Fai review di codice che non hai scritto e vuoi un vocabolario preciso per motivare un rifiuto senza trasformarlo in una questione di gusto personale.
Team con software in manutenzione
Il valore dell'azienda è in una codebase che deve durare altri dieci anni. Ogni scelta non governata oggi diventa un costo ricorrente domani.
Per chi non è
Non è un manuale di riferimento del linguaggio: per quello esistono la documentazione Microsoft e testi ottimi come Pro C#, e questo libro non li sostituisce. Non è un prontuario di prompt. Non è una raccolta di novità di .NET destinata a invecchiare in un anno. Se cerchi un tutorial da seguire in sequenza, questo non lo è.
Adottato da team tecnici, non solo letto da singoli
"Un libro che trasmette la stessa concretezza di Matteo come consulente: zero teoria vuota, solo strumenti che funzionano davvero in produzione. Lo consiglio a tutti i professionisti che vogliono crescere sul serio."
Direttore Generale, Il Sole24Ore
"Lo abbiamo adottato come riferimento tecnico per tutto il team di sviluppo. La progressione dai fondamenti all'architettura esagonale è chiara e applicabile. I nostri pull request sono migliorati in modo evidente."
Direttore IT, Wakiwi
"Il Dio del Codice ha dato al nostro team un linguaggio comune: design pattern, architettura, qualità del codice. In pochi mesi abbiamo visto una differenza concreta nella manutenibilità dei nostri sistemi .NET."
Direttore Tecnico, Cotonella S.p.a.
"Finalmente un libro che spiega l'architettura software come si fa davvero in azienda, non su esempi finti. I capitoli su CQRS e microservizi ci hanno aiutato ad affrontare un progetto industriale molto complesso."
CEO, AG Informatica Automazioni Industriali
"Ho capito finalmente come integrare la progettazione del database con l'architettura software. Il capitolo sull'event sourcing mi ha aperto una prospettiva completamente nuova sui dati."
Specialista Database, Wakiwi
"Arrivavo da VB6 e mi sentivo perso nell'ecosistema .NET moderno. Questo libro mi ha dato un percorso chiaro: dai fondamenti di C# fino ai pattern architetturali. Adesso guido le scelte tecniche del mio team."
Sviluppatore Senior, Bonifiche Veronesi
Chi ha scritto il libro, e perché può permetterselo
Sistemi progettati e mantenuti, non casi di studio
LegalDesk
Gestionale cloud per studi legali. Architettura progettata da zero, scalabilità e sicurezza su dati sensibili. Fondato, scalato e ceduto.
iHawk
Sistema di allarme anti intrusione con visione artificiale. Vincoli di affidabilità in cui un falso negativo non è un bug accettabile.
STR Vision
Piattaforma per la gestione immobiliare. Modernizzazione di un sistema legacy verso un'architettura mantenibile, senza fermare l'operatività.
Se ti serve per un team e non per una persona
Il libro dà il risultato migliore quando lo legge un gruppo, non un individuo: il valore sta nel vocabolario condiviso, e un vocabolario condiviso da una persona sola non serve a niente.
Se stai valutando l'adozione per il tuo team, indicalo nella richiesta con il numero di persone. Ti rispondo io con le condizioni per le copie multiple, i tempi di consegna e, se ha senso per il vostro contesto, come impostare la lettura perché produca un cambiamento misurabile nelle review invece di restare uno scaffale.
Copie multiple per il team.
Fattura intestata all'azienda.
Formati ebook, brossura, copertina rigida e audiolibro.
Percorso di approfondimento se il team vuole andare oltre il libro.
Le obiezioni che ricevo più spesso
Il Dio del Codice
300 pagine su architettura, design pattern e metodo, più il manuale Come diventare un Architetto Software, l'accesso alla community e la checklist per i colloqui tecnici.
Lascia i tuoi dati e ricevi il link d'acquisto insieme ai materiali digitali. Se la richiesta è per un team, indicalo nel messaggio.
Nessuna promessa di trasformazione rapida. Un libro tecnico si applica leggendolo e lavorandoci sopra, e il risultato dipende da quanto il team lo usa davvero.