La demo funzionava. Poi è arrivata la produzione.

Il modello scrive il componente. Ma chi decide sulla scalabilità?

Un modello AI può scrivere un endpoint REST in meno di un minuto. Può farlo bene, nel rispetto di convenzioni standard, con gestione degli errori decente e una struttura che compila al primo tentativo. Questo non è in discussione.

Quello che non fa — a meno che non venga interrogato nel modo giusto, da qualcuno che sa già cosa cercare — è ragionare sulle implicazioni di quel componente nel sistema più ampio. Quante richieste concorrenti reggerà? Questa query si trasforma in un full table scan quando il dataset supera il milione di righe? Il pattern che ha scelto introduce un accoppiamento che fra tre sprint renderà impossibile cambiare il modello dati?

L'AI risponde a quello che le chiedi. Non vede quello che non hai chiesto. E la parte difficile dell'ingegneria del software non è scrivere le righe — è sapere quali domande fare prima che il problema si manifesti in produzione.

Un senior developer che usa l'AI per generare codice lo usa come acceleratore. Sa dove il modello tende a prendere scorciatoie, sa dove intervenire, sa cosa verificare. Il modello da solo prende le stesse decisioni architetturali di un junior che non conosce ancora i pattern di fallimento. Le prende più velocemente, il che le rende potenzialmente più pericolose.

La demo funzionava. Accidenti.

C'è una soglia nel ciclo di vita di ogni progetto costruito in fretta — che sia vibe coding, un hackathon, un MVP tirato su in un weekend — che io chiamo technical cliff. La demo funziona. Funziona bene. I dati sono quelli giusti, il flusso è quello giusto, il cliente è entusiasta. Si va avanti.

Poi arriva il primo mese di utilizzo reale. Utenti concorrenti. Dati sporchi. Casi limite che nessuno aveva previsto perché in demo si controllava tutto. E il sistema inizia a mostrare le sue fondamenta.

Non è un problema dell'AI. È un problema della demo come modalità di validazione. La demo dimostra che l'idea funziona — non che il sistema funzionerà. Sono due cose completamente diverse, e confonderle è uno dei modi più costosi per sprecare un progetto promettente.

Il codice generato da un modello non porta con sé la storia delle decisioni che lo hanno prodotto. Non c'è un commit message che spiega perché si è scelto quell'approccio invece di un altro. Non c'è un ADR — Architecture Decision Record — che documenti i trade-off considerati. C'è solo il risultato. E il risultato, senza contesto, è difficile da mantenere, difficile da far evolvere, difficile da revisionare quando qualcosa va storto.

Il codice rispetta le normative?

Questa è la domanda che nessuno fa fino a quando qualcuno la fa per conto terzi.

Il codice generato da un modello non è intrinsecamente conforme a nulla. Il modello non sa in quale mercato opererà il sistema, non sa se tratterà dati personali di cittadini europei, non sa se l'interfaccia dovrà rispettare gli standard di accessibilità, non sa se il sistema rientra nell'ambito dell'AI Act. Sa scrivere codice che funziona per il caso che gli hai descritto.

• GDPR Dove vengono loggati i dati? Per quanto tempo? Con quale base giuridica? Chi può accedervi? La pseudonimizzazione è implementata o è solo dichiarata nei commenti? Il modello può generare un sistema che raccoglie tutto — log, sessioni, input utente — senza che nessuno abbia esplicitamente chiesto il contrario.
• Accessibilità La European Accessibility Act è in vigore. Per molte categorie di prodotti e servizi digitali, l'accessibilità non è una feature opzionale — è un requisito legale. Un'interfaccia generata dall'AI senza prompt specifici produrrà HTML semanticamente corretto quanto le istruzioni che ha ricevuto. Spesso: non abbastanza.
• AI Act Se il sistema che stai costruendo prende decisioni che impattano le persone — anche in modo indiretto — potrebbe ricadere nelle categorie a rischio dell'AI Act europeo. Chi valuta il livello di rischio? Chi documenta il sistema per gli obblighi di trasparenza? Non il modello che ha scritto il codice.

La compliance non è un layer che si aggiunge alla fine. È una serie di vincoli che determinano le scelte architetturali fin dall'inizio. Ignorarla in fase di prototipo per aggiungerla dopo è quasi sempre più costoso che partire con i requisiti giusti.

Il Paradosso di Jevons applicato al codice.

Nel 1865 William Stanley Jevons osservò che le macchine a vapore più efficienti non avevano ridotto il consumo di carbone — lo avevano aumentato. Quando una risorsa diventa più economica, se ne usa di più, non di meno. Il consumo totale cresce anche se il consumo per unità cala.

Il codice generato dall'AI costa pochissimo per riga. La conseguenza diretta è che se ne genera molto di più. Più funzionalità, più servizi, più componenti, più layer. Il progetto cresce a una velocità che non aveva mai avuto prima.

Ma ogni riga di codice ha un costo che non è quello di scrittura — è quello di lettura, manutenzione, test ed evoluzione. Una codebase che cresce due volte più veloce non diventa necessariamente due volte più manutenibile. Spesso il contrario: la superficie che deve essere capita, testata e mantenuta si espande più rapidamente della capacità del team di comprenderla.

Chi governa questo processo? Chi decide quando smettere di aggiungere e iniziare a consolidare? Chi tiene il filo tra ciò che esiste e ciò che serve davvero? Questa è la domanda che nell'articolo precedente ho chiamato "il problema che viene prima del codice" — e che il Paradosso di Jevons rende ancora più urgente quando il codice costa quasi zero.

La finestra di contesto non vede il progetto.

C'è qualcosa di paradossale nel modo in cui un modello conosce un progetto. Dopo una sessione lunga — qualche ora di lavoro, decine di file modificati — il modello probabilmente conosce meglio di te quali versioni delle dipendenze Maven sono state dichiarate nel pom.xml, o quale variante esatta dell'API di una libreria è stata usata in quel componente specifico. Il dettaglio implementativo è lì, nella finestra di contesto, preciso e disponibile.

Ma il perché del sistema tende a scomparire. A cosa serve questo modulo? Chi lo usa e in quale condizione? Quale problema di business risolve questa scelta architetturale? Questa è la conoscenza che si degrada — non perché il modello dimentichi nel senso letterale, ma perché quella conoscenza non era mai stata codificata nel prompt, nel codice, nella struttura del progetto. Era nella testa di chi ha iniziato a costruire.

Il risultato è un modello che ottimizza localmente — questo metodo, questo file, questa funzione — senza avere accesso alla coerenza globale. Può rendere un componente più elegante peggiorando l'architettura complessiva. Può risolvere il bug segnalato introducendo un'inconsistenza che emerge tre sprint dopo. Non per malevolenza. Per mancanza di contesto.