--- title: Iterazione dei prompt: quando ritoccare, quando buttare, quando lasciar perdere description: Una guida pratica per migliorare i prompt con l’IA tramite iterazione. Impara quando rifinire, quando ripartire da zero e come riconoscere i rendimenti decrescenti prima di buttare ore per miglioramenti marginali. date: February 5, 2026 author: Robert Soares category: prompt-engineering --- Il primo prompt raramente funziona. Neanche il secondo. La domanda non è se itererai. La domanda è se le iterazioni ti faranno davvero andare avanti o se brucerai crediti mentre ti convinci di stare facendo progressi. La maggior parte delle guide sull’ingegneria dei prompt tratta l’iterazione come una virtù in sé, come se l’atto di ritoccare e testare garantisse automaticamente un miglioramento. Ma parla con chiunque abbia passato ore vere a rifinire prompt per sistemi in produzione e sentirai una storia diversa. A volte l’iterazione si accumula. A volte va in spirale. Saper distinguere le due cose è ciò che separa un perfezionamento strategico da una frustrazione costosa. ## La meccanica di un’iterazione utile Ogni iterazione di un prompt cambia qualcosa. Quelle utili cambiano le cose giuste. Quando ottieni un risultato che manca l’obiettivo, l’istinto è aggiungere più istruzioni, più esempi, più vincoli. Ma l’accumulo è solo uno degli strumenti. Come ha descritto un sviluppatore su Hacker News: "every time the model does something undesired, even minor I add an explicit rule in the system prompt" ([minimaxir, Hacker News](https://news.ycombinator.com/item?id=38657029)). Questo approccio funziona, ma ha anche notato che le regole accumulate possono "balloon quickly" quando emergono problemi durante i test. Funziona anche l’approccio opposto. A volte togliere istruzioni produce risultati migliori che aggiungerle. Un praticante ha osservato: "Sometimes even giving them 'drunken' prompts with just a few keywords is enough... If you specify too much they tend to hyperfixate on things" ([birracerveza, Hacker News](https://news.ycombinator.com/item?id=41395921)). Vincoli troppo stretti possono restringere il focus di un modello al punto da fargli perdere l’obiettivo reale. Quindi in che direzione vai? Dipende da come sta fallendo. ### Diagnosticare prima di cambiare Risultato troppo generico? Aggiungi specificità. Risultato troppo letterale? Togli vincoli. Risultato incoerente? Dai struttura. Risultato ripetitivo? Riduci gli esempi. Collega il problema alla correzione. Cambiamenti casuali producono risultati casuali, e i risultati casuali non ti insegnano nulla su cosa abbia fatto davvero la differenza. Chi diventa bravo in questo tratta l’iterazione come verifica di ipotesi, non come tentativi ed errori. Ogni modifica mette alla prova un’assunzione specifica sul perché l’ultimo risultato abbia fallito. Questa cornice mentale conta perché ti costringe a dire ad alta voce cosa pensi sia andato storto prima di cambiare qualsiasi cosa. ## Quando iterare e quando ripartire Iterare presuppone che il prompt attuale abbia una base su cui valga la pena costruire. Non è sempre vero. C’è un copione ricorrente: persone che rifiniscono un prompt mediocre per quindici iterazioni, aggiungendo clausole, esempi e vincoli finché il prompt diventa un groviglio di toppe accumulate. Ottengono qualcosa che funziona, più o meno, a volte. Ma sarebbero arrivati prima buttando via l’originale e ripartendo da un’impostazione pulita. La fallacia dei costi sommersi colpisce forte nell’ingegneria dei prompt. Hai passato venti minuti su questo prompt. Quasi funziona. Un ultimo ritocco e ci sei. Ma se l’impostazione era sbagliata dall’inizio, nessun perfezionamento la aggiusta. Riparti da zero quando: - Il tuo prompt è cresciuto oltre due paragrafi di istruzioni - Stai aggiungendo eccezioni per gestire eccezioni - La descrizione del compito non assomiglia più al tuo vero obiettivo - I risultati peggiorano, non migliorano, nonostante modifiche sensate Uno sviluppatore su Hacker News l’ha detta senza giri di parole: "I realized the real problem was that I hadn't figured out what I wanted in the first place" ([Kiyo-Lynn, Hacker News](https://news.ycombinator.com/item?id=44182188)). Prima di iterare, devi sapere che faccia ha il successo. Se non sai descrivere chiaramente l’output ideale, non può farlo neanche il tuo prompt. ### Il protocollo della ripartenza Quando riparti, non limitarti a cancellare e riscrivere. Prima estrai ciò che ha funzionato nei tentativi falliti. Magari la tua specifica di formato era buona anche se l’impostazione del compito era sballata. Magari gli esempi mostravano la cosa sbagliata ma l’indicazione sul tono ha centrato il punto. Recupera i pezzi che promettevano bene. Butta via l’impalcatura costruita attorno agli errori. Poi scrivi il nuovo prompt partendo dall’output e andando a ritroso. Inizia con esattamente ciò che vuoi vedere. Descrivi quell’output in parole semplici. Costruisci istruzioni che produrrebbero quel risultato specifico. Questo ribaltamento spesso produce prompt più puliti rispetto al tentativo di specificare la trasformazione dall’input all’output. ## Tenere traccia di ciò che funziona (senza complicarti la vita) Ti serve un sistema. Non ti serve un sistema complesso. Il metodo più semplice: tieni un documento in continuo aggiornamento. Ogni tentativo di prompt ha un numero, il testo del prompt, un output di esempio e una valutazione di una riga. "Struttura migliore ma ho perso il tono conversazionale." "Formato perfetto ma contenuto troppo superficiale." "Questo ha funzionato davvero." Come ha notato un praticante esperto: "Practice. Keep notes on what works for you. Pay attention to what other people do and take the best ideas" ([PaulHoule, Hacker News](https://news.ycombinator.com/item?id=34806670)). L’abitudine di prendere note conta più del formato specifico. ### Cosa annotare Per ogni iterazione, registra: - Cosa hai cambiato rispetto alla versione precedente - Perché pensavi che quella modifica avrebbe aiutato - Cosa è cambiato davvero nell’output - Se la modifica ti ha portato verso o lontano dal tuo obiettivo Quest’ultimo punto è cruciale. A volte una modifica produce un output diverso senza produrre un output migliore. Se non valuti esplicitamente la direzione, puoi iterare all’infinito senza progressi: solo differenze. ### Il problema del confronto Ecco la verità scomoda: confrontare output di prompt è più difficile di quanto sembri. Lo stesso prompt può produrre output notevolmente diversi in esecuzioni consecutive, il che significa che il miglioramento che ti sembra di vedere potrebbe essere solo variabilità. Un commentatore ha catturato bene questa frustrazione: "if you're 'tweaking' the prompt what you're really doing is just re-rolling the dice until you land in a neighborhood closer" cioè più vicino a ciò che vuoi ([ianbicking, Hacker News](https://news.ycombinator.com/item?id=38657029)). Sostiene che le tecniche siano un progresso reale solo quando funzionano su più casi di test, invece di produrre un singolo output riuscito. Per i prompt in produzione, questo conta enormemente. Un prompt che funziona alla grande una volta e fallisce tre volte è peggio di un prompt che funziona in modo adeguato ogni volta. Testare su un singolo esempio non ti dice nulla sulla coerenza. Testare su molti esempi sì, ma richiede più tempo. La via di mezzo: prova le modifiche sui tuoi tre input più rappresentativi. Se la modifica migliora tutti e tre, probabilmente hai trovato qualcosa di reale. Se migliora uno e peggiora un altro, probabilmente stai solo redistribuendo la variabilità. ## La trappola dei rendimenti decrescenti Ogni prompt ha un tetto. Se lo spingi oltre, stai ottimizzando il rumore. Le prime iterazioni di solito portano miglioramenti significativi. I prompt grezzi diventano funzionali. Quelli funzionali diventano affidabili. Ma a un certo punto i guadagni si restringono fino al punto in cui non riesci più a distinguere in modo affidabile il segnale dalla casualità. Un utente di Hacker News ha descritto lo schianto contro questo muro mentre iterava con agenti di IA: "just spin and spin, burn 30 dollars for one prompt" ([taosx, Hacker News](https://news.ycombinator.com/item?id=44182188)). L’automazione ha peggiorato la trappola. Quando iterare è gratis, iteri per sempre. Quando costa denaro o tempo, senti i rendimenti decrescenti nel portafoglio o nell’agenda. ### Riconoscere il limite Hai raggiunto i rendimenti decrescenti quando: - I cambiamenti producono output diversi ma non chiaramente migliori - Stai facendo ripetutamente lo stesso tipo di modifica (più specifico, poi più specifico ancora, poi ancora più specifico) - La qualità dell’output oscilla invece di salire - Passi più tempo a decidere se un output è migliore che a testare davvero i prompt A questo punto hai tre opzioni. Accettare l’output attuale come abbastanza buono. Cambiare approccio del tutto. Oppure riconoscere che il compito potrebbe essere oltre ciò che puoi ottenere solo con i prompt. ### Quando fermarsi L’abilità più difficile nell’iterazione dei prompt è sapere quando fermarsi. Non perché hai raggiunto la perfezione, ma perché ulteriori ritocchi non miglioreranno in modo significativo i risultati. Un altro commentatore ha trovato successo limitando esplicitamente le proprie ambizioni: "Instead of over optimizing my prompt I just try to find the minimal amount of representation to get the llm to understand my problem" ([someoneontenet, Hacker News](https://news.ycombinator.com/item?id=41395921)). Il minimo sufficiente batte spesso l’ottimo teorico. “Abbastanza buono” ha un vantaggio di produttività. Ogni ora che passi a ottimizzare un prompt che già funziona è un’ora che non spendi su altro. Il prompt perfetto conta meno di quanto pensi, soprattutto per compiti in cui rivedrai comunque l’output. ## Meta-prompting: far iterare l’IA per te C’è una scorciatoia che a volte funziona meglio dell’iterazione manuale. Invece di rifinire direttamente il prompt, descrivi l’obiettivo a un’IA e chiedile di generare un prompt per quell’obiettivo. Poi usa quel prompt generato in una conversazione nuova, senza contesto su come ci sei arrivato. Un praticante ha documentato questo approccio: "Ask Claude to come up with LLM prompt to solve problem" prima, poi usare quel prompt generato in una nuova conversazione. Ha visto un miglioramento da 148 a 428 parole usando solo 27 parole di meta-istruzione invece di rifinire direttamente il prompt originale ([slt2021, Hacker News](https://news.ycombinator.com/item?id=41395921)). Funziona perché i modelli di IA spesso strutturano i prompt in modo diverso dalle persone. Possono includere contesto o istruzioni che non ti verrebbero in mente. La conversazione nuova conta perché elimina l’inquinamento di contesto che si accumula durante l’iterazione manuale. Il meta-prompting non è sempre migliore. Ma quando sei bloccato, offre un angolo di attacco diverso. ## L’iterazione come apprendimento I prompt che scriverai tra sei mesi saranno migliori di quelli che scrivi oggi. Non perché avrai memorizzato modelli migliori, ma perché avrai interiorizzato schemi attraverso la ripetizione. Ogni iterazione ti insegna qualcosa su come i modelli linguistici interpretano le istruzioni, anche quando l’iterazione in sé non migliora l’output. Col tempo sviluppi intuizioni su scelta delle parole, struttura, specificità ed esempi che rendono migliori le prime bozze. La mentalità dell’iterazione va oltre i singoli prompt. Ogni progetto che usa prompt ti insegna qualcosa di trasferibile. Gli schemi che funzionavano per generare testi di marketing potrebbero informare come imposti prompt per la revisione del codice. Le modalità di fallimento che hai incontrato in un dominio riappaiono in altri. Come ha osservato un commentatore: "just practice. With different systems; sd, mj, chatgpt, gpt3, gptj etc." ([anonzzzies, Hacker News](https://news.ycombinator.com/item?id=34806670)). L’ampiezza dell’esperienza conta quanto la profondità dentro un singolo sistema, anche perché modelli diversi rivelano aspetti diversi di come funzionano i prompt. L’ingegneria dei prompt è una disciplina empirica travestita da disciplina linguistica. Impari facendo e osservando, non leggendo regole e applicandole. Le iterazioni che sembrano tempo buttato spesso contribuiscono alle intuizioni che userai anni dopo su problemi completamente diversi. Quindi itera. Tieni traccia di ciò che funziona. Nota quando stai girando a vuoto. Riparti quando serve. Ma riconosci anche che l’obiettivo non è un prompt perfetto. L’obiettivo è un output che ottenga ciò che ti serve. A volte “abbastanza buono” è davvero abbastanza buono, e la migliore iterazione è quella in cui decidi di fermarti.