Idea principale

Il volume di codice prodotto e le proprietà d'insieme di un sistema non variano di pari passo. La coerenza architetturale, l'affidabilità in esercizio, la sicurezza e la qualità delle integrazioni non sono quantità che si ottengono scrivendo di più: sono proprietà dell'insieme, che si degradano quando le parti si aggiungono senza che nessuno decida come devono stare insieme.

La domanda tecnica che conta si sposta quindi. «Possiamo codificare questo?» torna a essere una domanda banale non appena la produzione è abbondante; le domande che restano difficili sono altrove: possiamo integrarlo in modo pulito nell'esistente, possiamo mantenerlo, possiamo proteggerlo, possiamo farlo reggere nella realtà.

Ciò che il team tecnico apporta non è più principalmente la capacità di scrivere, è il giudizio su ciò che è ragionevole, robusto e sostenibile costruire in un dato contesto.

Contributo di «PM, sviluppatori e IA: i ruoli si confondono, le responsabilità restano» (2026-08-01). La formulazione più utile passa per ciò che diventa una commodity e ciò che non lo diventa. Produrre rapidamente una prima versione di codice smette di essere raro; il software invece non diventa una commodity, e nemmeno l'ingegneria, l'architettura, la sicurezza o la manutenibilità. Confondere le due cose porta a trattare come banale un mestiere di cui solo il primo passo si è banalizzato.

Perché è importante

Impedisce di leggere un'accelerazione della produzione come un vantaggio tecnico. Un sistema che cresce più in fretta delle decisioni che lo governano accumula un debito architetturale al ritmo stesso della sua crescita.

Offre anche il criterio con cui valutare una proposta tecnica una volta acquisita la fattibilità: integrazione, manutenibilità, sicurezza e tenuta in esercizio, i quattro punti in cui si rivela il costo reale.

Sfumature e limiti

L'affermazione non dice che la produzione non conti più: un team incapace di consegnare non ha nulla su cui decidere. Dice che la capacità di scrivere smette di essere il fattore limitante.

E una parte della coerenza può essere affidata agli strumenti — convenzioni imposte, test, revisioni automatiche — il che sposta il giudizio sulla definizione di queste salvaguardie senza eliminarlo.

Domande aperte

• Come misurare la perdita di coerenza di un sistema mentre cresce, prima che si manifesti sotto forma di incidenti?