Quando l’AI scrive codice, le 5S contano ancora?
Un articolo di: Donato Pascazio
L’AI ha cambiato il modo in cui scriviamo codice — ma ha reso i principi 5S più importanti o obsoleti? Una riflessione su come Sort, Set in Order, Shine, Standardize e Sustain si evolvono quando il tuo pair programmer non dorme mai e genera centinaia di righe in secondi.
Il modello industriale Toyota
Giappone, secondo dopoguerra.
Un territorio affamato, impoverito e ferito dalla guerra. Intriso di povertà economica e di estrema disciplina. Qui, nasce, con questi presupposti, il Toyota Production System ( da ora in poi, TPS ).
Quello che allora era il modello industriale di riferimento per la produzione degli autoveicoli era il sistema statunitense Ford. Tali industrie, difatti, erano capaci di produrre un parco macchine molto vasto… Ma ad un costo proibitivo, per il gruppo industriale guidato da Eiji Toyoda.
Bisognava pensare ad un’alternativa, facendo di necessità virtù. Nasce così il sistema di produzione Toyota: produzione Just In Time, sistema di tracciamento Kanban, riduzione degli sprechi Muda, flusso continuo e l’applicazione delle 5S.
La fabbrica digitale del software
Italia, 2026.
I presupposti del TPS sono, oggi più che mai, attuali, perché l’idea di fondo non riguarda soltanto i luoghi di produzione fisici, ma una filosofia applicabile a qualsiasi processo che debba durare nel tempo senza perdere qualità. Anche la produzione software, che pure appartiene al dominio dell’intellettuale, genera inevitabilmente sprechi: solo che, mentre nel metallo sono immediatamente visibili, nel codice tendono a restare nascosti, sotto forma di attrito, contesto che si perde e scelte che si stratificano fino a diventare irreversibili.
In questa direzione, trovo molto centrata anche la lettura proposta in “Agentic AI: la disruption dopo la disruption”, che mostra come l’Agentic AI non stia soltanto accelerando la scrittura del codice, ma stia spostando il valore verso chiarezza, vincoli e capacità di giudizio, perché l’ambiguità, quando incontra l’automazione, non si riduce: si moltiplica.
È per questo che, quando si parla di qualità del software, la domanda che conta davvero è quanto sia ordinato il posto in cui produciamo; ed è qui che le 5S, applicate ai sorgenti, smettono di essere una teoria e diventano igiene dell’ecosistema, non morale del singolo.
Il sistema delle 5S applicato ai sorgenti
Seiri (整理) — Separare l’inutile
Nei sorgenti restano spesso riferimenti che non servono più, perché si rifattorizza di continuo e, nella fretta di far funzionare tutto, si tende a rimandare la parte più scomoda e concettualmente più problematica: analizzare in modo profondo le interdipendenze ormai orfane. È così che compaiono funzioni “zombie”, blocchi commentati “per sicurezza” e pezzi di codice lasciati lì come se non conoscessimo strumenti di versionamento del codice diversi dal commentare l’inutile.
Questo genere di residui crea rumore, e il rumore, in una codebase, è più pericoloso di quanto sembri, perché confonde la lettura, rallenta le decisioni e rende più difficile capire cosa sia vivo e cosa sia già morto. Separare l’inutile richiede tempo e cura, ma restituisce spazio mentale e controllo operativo, perché riduce l’attrito e rende il sistema più ispezionabile.
In questo senso, Seiri non è un atto estetico, ma una scelta netta: decidere cosa resta, e cosa deve sparire.
Poi però arriva l’AI
Quando entrano in gioco gli agenti, la produzione di materiale collaterale diventa improvvisamente economica: basta un prompt e compaiono file, varianti, tentativi, commenti, riferimenti che sembrano utili nell’immediato ma che spesso non lo saranno nel lungo periodo. La sovrapproduzione diventa facile, e proprio per questo rischia di diventare normale, se non si mantiene un criterio severo su ciò che merita di restare nella codebase.
Seiri, con l’AI, torna quindi ad essere la stessa scelta di prima, ma a un ritmo molto più alto: cosa resta, e cosa sparisce.
Seiton (整頓) — Mettere in ordine
I progetti nascono quasi sempre con un’idea di ordine, perché all’inizio esistono confini chiari e luoghi digitali che hanno un senso, nei quali il codice viene organizzato secondo aree concettuali e responsabilità ben distinte. Il problema arriva quando il progetto cresce e, nel tentativo di essere rapidi, quell’ordine si piega, finché non diventa normale vedere un componente UI che si porta dentro le chiamate al server, pro domo propria, come se la separazione delle responsabilità fosse un dettaglio e non una condizione di manutenibilità.
Questo è codice “a blocchi”, verticale, che può sembrare comodo nell’immediato, ma che nel tempo rende difficile capire dove finisca una responsabilità e dove ne inizi un’altra, soprattutto quando bisogna modificare qualcosa senza rompere ciò che già funziona. In un magazzino le viti stanno insieme e sono separate per dimensione, perché l’ordine serve a trovare ciò che serve quando serve; nei sorgenti è lo stesso, perché funzioni e logiche devono avere un posto preciso, in file e librerie dedicate, così che chi verrà dopo, spesso noi stessi, possa capire rapidamente dove mettere le mani.
In questo senso, Seiton non riguarda l’estetica della struttura, ma la sua leggibilità: rendere naturale la posizione delle cose, in modo che il progetto continui a essere ispezionabile anche quando cresce.
Poi però arriva l’AI
Con gli agenti questa disciplina tende a saltare facilmente se non la si richiede in modo esplicito, perché l’AI, quando trova una scorciatoia, la percorre senza percepire il costo che quella scorciatoia avrà nel tempo. È così che compaiono costanti infilate dove “è più comodo” e componenti che ignorano il principio di SOC anche se il progetto lo rispettava ovunque, mentre l’entropia, invece di crescere lentamente, accelera, e con essa scivola via la mappa: resta la responsabilità del funzionamento, ma diventa più difficile capire dove intervenire.
Per questo serve un contesto preciso, anche nei prompt, nel quale sia chiaro come è fatto lo spazio del progetto e dove ogni cosa deve finire, perché, se la struttura non è esplicitata e difesa, l’AI non la preserva: la interpreta.
Seiso (清掃) — Pulire
Nel TPS, Seiso è pulizia costante, perché ciò che è sporco tende a nascondere i problemi, mentre ciò che è pulito li rende immediatamente visibili. Nel software accade qualcosa di molto simile, poiché la pulizia non riguarda l’estetica, ma la leggibilità: quando il codice è leggibile, è anche ispezionabile, e quando è ispezionabile diventa possibile intervenire senza procedere alla cieca.
Pulire, nei sorgenti, significa refactoring e manutenzione continua, cioè rimuovere il superfluo che si accumula naturalmente nel tempo sotto forma di duplicazioni, codice ridondante, metodi troppo lunghi e logiche che si complicano senza un vero motivo. La complessità, infatti, raramente esplode in un singolo momento; più spesso si stratifica, lentamente, finché ciò che prima era semplice da modificare diventa fragile, e quindi costoso.
Seiso, in questo senso, è il gesto che impedisce al progetto di perdere forma: non perché lo renda “bello”, ma perché lo mantiene governabile.
Poi però arriva l’AI
Quando entrano in gioco gli agenti, la verbosità diventa un rischio ricorrente, perché l’AI tende a produrre soluzioni funzionanti aggiungendo strati, wrapper, commenti e varianti che, nell’immediato, sembrano utili, ma che nel tempo aumentano peso e superficie di manutenzione. Se la pulizia non è parte del processo, il codice generato finisce per accumulare debito tecnico più rapidamente del normale, proprio perché la velocità di produzione supera la velocità con cui il sistema viene semplificato.
Per questo, con l’AI, Seiso non è un “di più”: è il modo con cui si evita che la codebase cresca solo in volume, perdendo controllo.
Seiketsu (清潔) — Standardizzare
Una volta stabiliti ordine e pulizia, Seiketsu consiste nel rendere quelle pratiche ripetibili, perché, se non vengono trasformate in regole condivise, restano episodi, e il sistema torna lentamente al disordine. Nel software questo significa definire standard chiari, che riguardano non soltanto lo stile del codice, ma anche la struttura del progetto e le convenzioni con cui ci si intende: naming, organizzazione delle directory, gestione delle dipendenze, forma dei test e criteri di integrazione. Gli standard riducono l’ambiguità e permettono al lavoro di restare coerente anche quando cambiano le persone o cresce il perimetro, evitando che ogni nuova modifica introduca un dialetto diverso nello stesso repository.
In questo senso, Seiketsu non serve a “uniformare per gusto”, ma a preservare una lingua comune, perché una codebase che parla con troppe voci, anche se funziona, diventa più difficile da governare.
Poi però arriva l’AI
Gli agenti non “scrivono codice” nel modo in cui lo intendiamo noi: imitano il contesto che trovano, e, se lo standard è chiaro, tendono a seguirlo, mentre, se è implicito, lo interpretano, trasformando l’interpretazione in incoerenza. È così che nascono varianti silenziose, nelle quali le stesse cose vengono chiamate in modi diversi, i pattern si duplicano e le convenzioni si piegano, finché il progetto continua a funzionare ma perde la sua lingua comune.
Seiketsu, nell’era degli agenti, significa quindi rendere lo standard “macchina-leggibile”, affidandolo a strumenti che lo applicano in modo automatico, come formatter, lint, template, test e quality gate, non per controllare le persone, ma per evitare che l’AI moltiplichi eccezioni fino a farle diventare norma.
Shitsuke (躾) — Disciplina
Shitsuke è la disciplina necessaria per mantenere nel tempo ciò che è stato costruito con le altre S, ed è proprio per questo che è spesso la parte più difficile: mentre ordinare e pulire sono azioni visibili, la disciplina è un comportamento stabile, che si vede soprattutto quando si ha fretta. Nel software questa disciplina prende forma in pratiche e meccanismi che impediscono al progetto di degradarsi, come code review fatte realmente, test automatici che proteggono dalle regressioni e controlli che rendono difficile introdurre incoerenze senza accorgersene.
In altre parole, Shitsuke è ciò che fa sì che lo standard non resti un documento, ma diventi un’abitudine del sistema.
Poi però arriva l’AI
Con gli agenti è possibile produrre grandi quantità di codice in tempi ridotti, e questo cambia il rapporto tra produzione e controllo, perché la velocità di generazione non garantisce la qualità della traiettoria. Se prima si poteva sperare di “accorgersi” degli errori con il tempo, oggi il rischio è che l’errore venga replicato e distribuito prima ancora che qualcuno lo guardi con attenzione.
È per questo che, nell’era dell’Agentic AI, la disciplina ingegneristica non diventa meno importante, ma più necessaria, perché, se la produzione accelera, anche la capacità del sistema di verificare, bloccare e correggere deve essere incorporata nel processo, e non affidata all’eroismo del singolo.
Qualità come processo
Se il Toyota Production System nacque perché, in un contesto di risorse limitate, lo spreco era un lusso che non ci si poteva permettere, oggi lo sviluppo software vive un vincolo diverso ma analogo, perché, quando la produzione accelera e si distribuisce su più layer e più file, il costo reale non è generare codice, ma mantenerlo coerente, comprensibile e ispezionabile nel tempo. In questo scenario, l’Agentic AI non elimina il problema del disordine, ma ne cambia la dinamica, perché l’ambiguità non resta locale e non resta lenta, bensì tende a moltiplicarsi, fino a diventare struttura. È per questo che le 5S, applicate ai sorgenti, non sono un ritorno al passato né un esercizio di stile, ma un modo concreto di difendere qualità e controllo: separando il rumore, mantenendo chiari i confini, pulendo ciò che si stratifica, stabilizzando una lingua comune e incorporando nel processo quella disciplina che, altrimenti, rimarrebbe affidata alla memoria e alla buona volontà del singolo.