Il debito tecnico non ha fondo: il codice può sempre peggiorare
L'ingegnere Zach Kehs ha sintetizzato in una frase il problema strutturale del software moderno: a differenza degli edifici fisici, il codice non crolla mai sotto il proprio peso.

👁 116 letture
Il 6 settembre 2026, Simon Willison ha segnalato sul suo weblog una citazione dell’ingegnere Zach Kehs tratta dall’articolo There’s No Limit to How Bad Code Can Get, che pone un problema strutturale del software in termini volutamente brutali.
- Zach Kehs ha pubblicato l'articolo "There's No Limit to How Bad Code Can Get", citato da Simon Willison il 6 settembre 2026
- La tesi centrale: il software non ha un limite fisico al degrado, a differenza delle strutture fisiche che cedono sotto il peso
- Il debito tecnico può accumularsi indefinitamente attraverso livelli di indirezione e perdita di prestazioni
Il ragionamento di Kehs parte da un’analogia fisica:
«Se continui ad aggiungere piani e stanze a un edificio per sempre, crollerà. Il software non ha questo vincolo. Il codice può sempre peggiorare. Ci può sempre essere un nuovo livello di indirezione o una riduzione delle prestazioni.»
La distinzione è precisa: la gravità impone un limite fisico alle costruzioni, le fa cedere prima che il disordine diventi infinito. Il software non ha un equivalente. Un’architettura mal progettata non produce un errore fatale immediato - produce lentezza, bug nascosti, manutenzione sempre più costosa, strati di astrazione che nessuno ricorda di aver aggiunto. Il sistema continua a funzionare, nel senso più debole del termine, mentre il debito tecnico si accumula senza segnali visibili dall’esterno.
Willison ha classificato il post sotto il tag technical-debt, inserendolo nel flusso regolare di citazioni che raccoglie da anni sul suo sito come strumenti di riflessione per chi costruisce software.
Implicazione pratica. Per chi sviluppa con strumenti AI - che generano codice velocemente, spesso senza considerare la manutenibilità futura - l’osservazione di Kehs è un avvertimento concreto. Il codice prodotto da un modello non crolla per inerzia propria: può degradare silenziosamente ad ogni iterazione, aggiungendo funzioni su funzioni, wrapper su wrapper, fino a rendere il sistema opaco. Chi usa AI per scrivere o estendere codice dovrebbe trattare ogni output come materiale che necessita di revisione strutturale, non solo funzionale, prima di entrare in produzione.
Google · Le tue fontiPiù in alto su Google con un solo clicAggiungi alle fonti preferite →More on this from NITIDO
notizie·LLM 0.35 aggiunge il supporto per GPT-6 Astra dalla riga di comando

