Big ball of mud: perché i sistemi costruiti con agenti AI diventano fragili

Un flusso di lavoro con un agente AI nasce quasi sempre per risolvere un problema piccolo: riassumere le email del mattino, tenere in ordine i file di un progetto, preparare un cruscotto. Funziona, si usa ogni giorno e a un certo punto nessuno ricorda più come è fatto. Il 2 ottobre 2026 Tanner Kohler di Nielsen Norman Group ha pubblicato "The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile", un articolo che dà un nome a questo processo e lo descrive con le parole di chi lo ha vissuto.

Cos'è un big ball of mud

L'espressione viene da un articolo del 1997 di Brian Foote e Joseph Yoder, che osservava come gran parte del software reale fosse costruito per esigenze immediate e non per durare. NN/g la riprende così: un sistema messo insieme per funzionare nel breve periodo, senza un'architettura pensata per il lungo. Un sistema del genere può funzionare, ma costa molto da mantenere, perché richiede continue toppe invece di un'infrastruttura stabile.

La novità dell'articolo è l'applicazione ai sistemi agentici: insiemi di istruzioni, cartelle e flussi che persone non necessariamente tecniche costruiscono per lavorare con un agente. Nell'articolo, sono i partecipanti a una ricerca a descrivere cosa succede quando costruire diventa facile e pianificare no.

I cinque schemi

Il codice usa e getta. I primi file, nati come prova senza pianificazione né test, finiscono dentro i flussi di lavoro e ci restano. Un partecipante dice: "I'm kind of stuck in the way that it works. I've never really taken the time to greenfield improve what I did". Si evita di ricostruire per mancanza di tempo e per paura di rompere qualcosa.

La crescita a pezzi. Le funzioni si aggiungono una alla volta, secondo il bisogno del momento, senza un'architettura. Un utente avanzato osserva: "You're constantly trying to refine the system, and you're not actually going out and using the system".

Mantenerlo funzionante. Quando qualcosa si rompe o deriva, si rattoppa invece di rifare, perché si è diventati dipendenti dallo strumento. Le correzioni rapide fatte con l'AI tengono in piedi il sistema ma erodono la comprensione. Un fondatore dice che sarebbe frustrato se gli togliessero lo strumento.

Nascondere la polvere sotto il tappeto. I contenuti non ordinati si accumulano in cartelle "cassetto della roba" che solo l'AI sa attraversare. Tra gli esempi dell'articolo c'è un cassetto di articoli non sintetizzati, da cui l'informazione è stata recuperata in modo errato dopo 45 minuti.

La ricostruzione. Prima o poi il sistema va rifatto: non corrisponde più ai bisogni, è diventato incomprensibile, o è comparso un metodo migliore. Un partecipante lo riassume così: "This had grown to something beyond what I was still able to keep in my head".

Tre tipi di contesto, da tenere separati

L'articolo si appoggia a una distinzione che NN/g ha introdotto il 18 settembre in "The 3 Roles of Context for AI Agents". Il contesto globale è fatto di istruzioni e conoscenze valide in tutto il sistema. Il contesto locale riguarda un compito, un progetto o un flusso specifico. Il contesto ambientale è composto dai flussi di informazioni come email, Slack e trascrizioni di riunioni, accessibili all'AI ma non curati deliberatamente.

Le raccomandazioni di NN/g sono quattro: tenere separati i tre tipi di contesto nella documentazione, nominarli quando si chiede una modifica, verificare periodicamente il contesto globale e rinfrescare quello locale quando la qualità dei risultati cala.

La domanda che decide

Il criterio più utile dell'articolo è una domanda: se volessi cambiare il funzionamento del sistema, saprei cosa modificare nella libreria di contesto? Se la risposta è sì, il controllo è sufficiente. Se è no, significa che ci si affida all'AI per orientarsi nel proprio stesso sistema, ed è il segnale che conviene ricostruire.

Cosa significa per chi progetta e sviluppa

Questa parte è una mia lettura, non una tesi di NN/g, che parla di sistemi agentici e non di prototipi front-end. Chi lavora con l'AI in un processo di design o di sviluppo ha già queste cose: file di istruzioni per l'agente, cartelle di riferimento, prompt riusati da un progetto all'altro. Gli stessi cinque schemi vi si riconoscono con facilità, e la domanda di NN/g si può provare subito su uno di questi sistemi. Se non sai dire quale file cambiare per modificare un comportamento dell'agente, probabilmente stai già mantenendo una toppa.

Un modo pratico di applicarla è scegliere un flusso che usi ogni settimana e scrivere, in poche righe, quali istruzioni sono globali, quali locali e quali arrivano dall'ambiente. Se l'esercizio è difficile, il problema è nel sistema e non nell'esercizio.

Fonti

1. Nielsen Norman Group, Tanner Kohler, “The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile”, 2 ottobre 2026
2. Nielsen Norman Group, “The 3 Roles of Context for AI Agents”, 18 settembre 2026 (letto solo il riepilogo in elenco)