Idea principale

File che si gonfiano troppo, test assenti, logica di dominio sparsa negli endpoint, architetture troppo complicate rispetto al bisogno, riscritture rimandate: niente di tutto questo è comparso con gli assistenti di sviluppo. C'erano già team che costruivano una cattedrale per montare una mensola, e aziende che confondevano la velocità di delivery con il valore reale.

A cambiare, quindi, non è la natura dei difetti ma il loro ritmo. Un assistente accelera quello che già andava troppo in fretta, rende meno visibile quello che già era mal compreso, e permette di impilare in poche ore decisioni che nessuno ha davvero preso.

Ne consegue che un sistema può ormai mostrare una maturità apparente senza aver attraversato le tappe che di solito la producono. Il difetto non è nuovo: è la velocità con cui si accumula a superare ormai quella con cui il team riesce a capire.

Perché è importante

Sposta la diagnosi. Attribuire questi difetti allo strumento porta a cercare uno strumento migliore o a vietarne l'uso; riconoscerli come vecchie patologie amplificate porta a rimettere in funzione i dispositivi che già li contenevano male — revisione, decisioni di architettura, test, scelte esplicite.

Offre anche una chiave di lettura per i progetti che si degradano in fretta: non è stata la generazione di codice a renderli fragili, ma il fatto che abbia eliminato il tempo durante il quale la fragilità restava correggibile.

Contributo di «Quattro giorni di vibe coding nei panni di un PM arrugginito» (2026-07-28). Osservato da vicino in quattro giorni di costruzione, il meccanismo assume una forma precisa e ripetibile. Un file nasce ragionevole, poi si gonfia fino a fare un po' di tutto, e il costo emerge tre giorni dopo, quando bisogna modificarlo. Gli strati si mescolano perché niente obbliga a decidere dove va la logica di dominio. Un'API che restituisce trentamila elementi viene trattata come una che ne restituisce duecento. Nessuna di queste mosse è nuova; nuovo è che si accumulano in poche ore e che la demo passa lo stesso. Il meccanismo si estende anche fuori dal codice: gli strumenti costruiti in un angolo, senza manutenzione e senza governance, sono un problema che le aziende conoscono dai tempi dei fogli di calcolo e delle macro — nemmeno questo l'assistente lo inventa: abbassa il prezzo d'ingresso, e quindi moltiplica gli oggetti che prendono quella strada.

Sfumature e limiti

Il cambio di scala non è neutro: oltre un certo ritmo, una differenza di quantità diventa una differenza di natura, perché i dispositivi umani di controllo — rileggere, discutere, decidere — non seguono la stessa curva.

E alcuni team disciplinati ottengono l'effetto opposto: lo stesso assistente scrive i test, separa il dominio dall'infrastruttura tecnica e propone una soluzione più semplice appena glielo si chiede in modo esplicito. Quello che fa spontaneamente e quello che sa fare sono due cose diverse.

Domande aperte

• Oltre quale ritmo di produzione i dispositivi umani di controllo smettono di essere dimensionati, e come misurarlo prima dell'incidente?