Il debito tecnico che il vibe coding lascia alle PMI

Negli ultimi due anni ho fatto un numero crescente di audit tecnici su richiesta di piccole e medie aziende che avevano commissionato — o realizzato internamente, con l’aiuto di strumenti AI — un software che a un certo punto ha smesso di funzionare come si aspettavano. Il pattern che vedo è sempre più simile: velocità iniziale sorprendente, poi un rallentamento progressivo, poi un blocco. Ogni piccola modifica richiede più tempo della precedente, finché aggiungere anche una funzione semplice diventa un progetto a sé.

Questo non è un problema dell’intelligenza artificiale in sé. È quello che succede a qualsiasi codice — scritto da un umano, da un’AI, o da entrambi — quando cresce senza una struttura pensata per durare. Il vibe coding accelera semplicemente il ritmo con cui questo debito si accumula, perché rimuove la frizione naturale che normalmente costringe uno sviluppatore a fermarsi e chiedersi “questa è la scelta giusta a lungo termine, o solo quella più veloce adesso?”

Come si riconosce, in pratica

Nei report di audit che scrivo, ci sono alcuni segnali che tornano quasi sempre:

Duplicazione invisibile. La stessa logica di business — un calcolo di prezzo, una regola di validazione — esiste in tre punti diversi del codice, leggermente diversa in ognuno, perché ogni volta è stata “rigenerata” invece che riutilizzata.

Assenza di test. Non c’è modo di sapere se una modifica rompe qualcosa altrove senza testarla manualmente, punto per punto, ogni volta.

Dipendenze fantasma. Il sistema si appoggia a servizi esterni, chiavi API, configurazioni che nessuno in azienda sa più spiegare — “funzionava così, non abbiamo toccato niente”.

Architettura assente. Non esiste una separazione chiara tra le parti del sistema: modificare la UI rompe la logica di pagamento, cambiare un fornitore di email richiede di toccare venti file diversi.

Cosa consiglio di fare, concretamente

Non consiglio quasi mai di buttare tutto e ripartire da zero — è la reazione istintiva, ma è quasi sempre la scelta più costosa e più rischiosa. Il codice esistente, per quanto disordinato, contiene decisioni di business già validate dal mercato: prezzi, regole, casi limite che qualcuno ha già scoperto a sue spese.

L’approccio che funziona è quasi sempre incrementale: un audit che mappa dove sta davvero il rischio (non tutto il debito tecnico è uguale — alcune parti fragili del sistema non vengono quasi mai toccate, altre sono nel percorso critico di ogni vendita), poi un piano di interventi mirati, con test scritti prima di toccare le parti più delicate, in modo da poter verificare che ogni modifica non rompa quello che già funziona.

Il costo di questo lavoro è quasi sempre inferiore a quello di una riscrittura completa, ed è drasticamente inferiore al costo di continuare a ignorare il problema finché il sistema non regge più le richieste del business. La domanda da farsi non è “possiamo permetterci un audit”, ma “possiamo permetterci di scoprire quanto è fragile il sistema nel momento peggiore possibile — durante un picco di vendite, o davanti a un investitore”. È il tipo di intervento che faccio più spesso sui gestionali interni costruiti in fretta e mai più rivisti.