Quando l’AI va in loop: come uscirne

Loop AI = stesso problema, fix che non risolve, fix nuovo che rompe altro, sempre più disordine. Sintomo classico: dopo ore di lavoro hai meno progresso del punto di partenza, e ti senti più confuso. La soluzione non è insistere: è riconoscere il loop, fermarsi, ripartire pulito.

Perché questa lezione conta

Loop AI distruggono ore di lavoro mentre danno l’illusione di progresso. Ogni messaggio sembra avvicinarsi alla soluzione, in realtà introduce nuova complessità. Senza protocollo di reset, finisci con codebase peggiore di quando hai iniziato. Saperli riconoscere e uscirne è uno skill operativo, non opinione.

Obiettivo operativo

Alla fine devi saper:

1. riconoscere i 5 sintomi tipici del loop;
2. eseguire procedura di reset rapida senza ricominciare da zero;
3. decidere quando insistere, quando cambiare approccio, quando fermarsi.

Nucleo della lezione

1. I cinque sintomi

Stesso errore ripetuto: dopo 3+ tentativi, lo stesso errore (stesso messaggio, stesso punto del codice). Modello propone fix che non risolve davvero.

Patch sempre più grandi: ogni fix tocca più file, aggiunge più condizioni, più gestione errori, più branch logici. Codice gonfia. Probabile sintomo: il modello sta nascondendo il problema invece di risolverlo.

Nuove regressioni: fix di un bug introduce un altro bug. Fix di quello introduce un terzo. Catena di rotture, ognuna “risolta”.

Spiegazioni vaghe: il modello descrive cosa fa con frasi generiche (“ho migliorato la gestione”, “ora dovrebbe funzionare meglio”). Quando chiedi dettagli, ripete la stessa frase.

Cambi di strategia non dichiarati: messaggio 5 il modello usa async/await; messaggio 6 cambia a Promise.then; messaggio 7 a callback. Senza spiegare, senza giustificare. Sintomo di confusione.

Combinazione di 2-3 di questi → sei in loop. Stop.

2. Procedura di reset

Cinque passi, in ordine, senza saltare:

1. Stop. Non rispondere “fai meglio” o “non funziona ancora”. Quel messaggio aggiunge solo carburante.

2. Reset di stato (Git): git reset --hard o git checkout al commit prima del loop. Tornato a stato funzionante (anche se incompleto).

3. Riproduzione minima: prendi il bug e riproducilo nel modo più piccolo possibile. Funzione isolata, input specifico, output atteso vs osservato. Se non riesci a riprodurre, non puoi risolvere.

4. Diagnosi prima del fix: nuovo prompt, in chat o sessione fresca. “Riproduco bug così: [esempio]. Ipotesi possibili? Quale controllo per discriminarle?”. Niente fix subito.

5. Verifica ipotesi: applica il controllo proposto, riporta il dato osservato. Itera diagnosi se serve.

6. Solo dopo, fix mirato: con causa chiara, fix piccolo. Verifica con la riproduzione minima.

Tempo medio del reset completo: 30-60 minuti. Tempo perso continuando a iterare nel loop: 4-6 ore. Investimento netto positivo.

3. Decidere quando smettere

Dopo reset, tre esiti possibili:

A. Diagnosi chiara, fix corre: ottimo, continua.

B. Diagnosi rivela problema più profondo: bug in libreria, bug in mio codice ad altro livello, ambiguità nei requisiti. Fix richiede ripensamento, non patch. Spendi tempo lì.

C. Modello continua a sbagliare: cambia modello (passa a frontier), cambia strumento (chat → IDE AI o viceversa), o scrivi a mano la parte critica.

Soglia: se dopo reset + 1 ora di tentativo nuovo non hai progressi, fermati. Smetti per oggi, ritorna domani con mente fresca. Spesso la soluzione emerge senza il modello.

Fermarsi non è fallimento. Insistere ciecamente sì.

Procedura pratica

Riconosciuto loop:

1. Annota momento e sintomi: utile per capire pattern personali.
2. git reset --hard a stato buono noto.
3. Riproduzione minima del problema vero.
4. Apri sessione nuova (modello potrebbe avere contesto inquinato).
5. Prompt di diagnosi (vedi sotto), no fix.
6. Verifica ipotesi una alla volta.
7. Fix mirato solo dopo causa chiara.
8. Test di regressione: il caso che era rotto ora funziona, e nessun altro è rotto.
9. Documenta: nel decision log o note del task, “loop su X causato da Y, risolto con Z”. Per il futuro.

Laboratorio guidato

Pratica controllata: introduci deliberatamente un bug sottile in piccolo progetto (es. condizione > invece di >=, off-by-one, validazione invertita).

Chiedi a un’AI di trovarlo e correggerlo, ma in modo da provocare loop:

• non passare il messaggio d’errore preciso;
• accetta fix senza testare;
• riferisci “non funziona” senza dettagli.

Dopo 3 iterazioni: probabilmente sei in loop. Pratica:

1. git reset --hard (annulla tutti i fix).
2. Riproduci bug con esempio minimo (input + output osservato + output atteso).
3. Sessione fresca: “ho questo problema [esempio minimo]. NON proporre fix. Dammi 3 ipotesi di causa con controllo per discriminarle”.
4. Verifica ipotesi.
5. Fix mirato.

Misura: tempo loop vs tempo reset+nuova diagnosi. Quasi sempre il reset è più veloce, anche se sembra “buttare via lavoro”.

Output atteso

Una procedura personale “anti-loop” stampata o salvata. Cinque passi, da consultare quando senti che stai girando in tondo:

ANTI-LOOP CHECK
□ Stesso errore in 3+ tentativi?
□ Patch sempre più grandi?
□ Nuove regressioni?
□ Spiegazioni vaghe?
□ Cambi di approccio non dichiarati?

Se 2+ sì → STOP.

RESET:
1. git reset --hard
2. Riproduzione minima del bug
3. Sessione fresca + prompt diagnosi (NO fix)
4. Verifica ipotesi
5. Fix mirato + test regressione

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: riconoscere cicli improduttivi e riprendere controllo senza continuare a chiedere fix ciechi. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Sintomi: stesso errore ripetuto, patch sempre più grandi, nuove regressioni, spiegazioni vaghe, cambi di strategia non dichiarati.
• Azioni di reset: ridurre scope, ripristinare ultimo stato buono, isolare errore, fornire log precisi, chiedere diagnosi prima del fix.
• Quando cambiare modello, strumento o approccio e quando smettere di generare.

3. Applicazione: svolgi il laboratorio: simulare un bug che l’AI corregge male e praticare un reset con riproduzione minima. L’output da ottenere è: una procedura di recupero dai loop con passi di stop, diagnosi, isolamento e ripartenza.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho riconosciuto un loop AI in passato e sono uscito;
• ho una soglia personale per “sono in loop” (es. 3 tentativi falliti);
• so eseguire reset rapido senza panico;
• so quando smettere completamente vs cambiare strumento.

Errori comuni

Insistere “ora va”. Risposte tipiche del modello dopo iter 5: “ora dovrebbe funzionare”. Spoiler: no. Reset.

Niente git reset. Continui a accumulare fix sopra fix. Codice gonfio, irrecuperabile.

Stessa sessione lunga. Contesto inquinato. Modello ha “imparato” la falsa pista. Sessione nuova.

Nessuna riproduzione minima. Senza esempio piccolo che mostra il bug, ogni fix è speculativo.

Saltare diagnosi. Vai direttamente al fix dopo reset. Stessa pista, stesso loop.

Cambiare strumento per primo. Spesso il problema è il prompt o lo stato, non il modello. Reset prima, cambio strumento dopo.

Non documentare il loop. Stesso pattern di errore tornerà. Se non lo segni, lo ripeti.

Prompt di lavoro

Prompt diagnosi (post-reset):

Sono uscito da un loop AI. Stato attuale: codice tornato a commit funzionante. Bug isolato.

Riproduzione minima:
- Input: [esempio]
- Output osservato: [...]
- Output atteso: [...]
- Errore (verbatim, se presente): [...]
- Ambiente: [stack + versioni]

NON proporre codice/fix in questa risposta.

Voglio:
1. 3 ipotesi di causa, ordinate per probabilità.
2. Per ognuna: motivazione + un controllo specifico (comando, log, ispezione) per confermarla o escluderla.
3. NON saltare alla soluzione. Aspetto i risultati dei controlli.

Se non hai abbastanza info per formulare ipotesi, chiedimi cosa serve, non indovinare.

Esercizio finale

Riguarda 3 sessioni AI lunghe e difficili degli ultimi mesi. Per ognuna: c’è stato un loop? Quando è iniziato? In che momento avresti dovuto fermarti e fare reset? Quanto tempo hai sprecato continuando? Quasi sempre il momento giusto del reset è 2-3 messaggi prima di quando hai effettivamente smesso. Quel “prima” è ciò che la lezione insegna a riconoscere.