Come creare un ciclo di intelligenza artificiale autocorrettivo che rileva i propri errori prima che tu li veda

C'è un momento preciso che separa chi usa l'AI in modo occasionale da chi la gestisce davvero come un sistema.

È il momento in cui smettono di essere la persona che coglie l'errore.

Adesso, per la maggior parte delle persone, il ciclo funziona così. Chiedi qualcosa a Claude. Leggi l'output. Noti che qualcosa non va. Lo segnali. Ottieni una versione corretta. La leggi. Noti qualcos'altro. Lo segnali di nuovo. Tu sei il livello di verifica, manualmente, ogni singola volta, per ogni singola attività.

Un ciclo di autocorrezione ti rimuove completamente da quella posizione. Il sistema genera, controlla il proprio lavoro rispetto a uno standard reale, coglie ciò che ha sbagliato, lo corregge, e solo allora ti mostra il risultato. Quando vedi l'output, gli errori evidenti sono già stati individuati e gestiti. Ciò che rimane a te è il giudizio sulle cose che richiedono davvero un essere umano, non la rilettura di una prima bozza della macchina.

Questa è la costruzione completa. Alla fine avrai l'esatta architettura, gli esatti prompt, e gli esatti modi di fallimento da testare prima di affidare a questo sistema qualcosa di importante.

Perché Questo Non è Come Chiedere Semplicemente Due Volte

Il primo istinto ovvio è chiedere al modello di controllare il proprio lavoro nella stessa conversazione. "Rivedi ciò che hai appena scritto e correggi eventuali errori." Questo aiuta un po'. Ma non costruisce un vero ciclo di autocorrezione, e capire il perché è l'intera base di ciò che segue.

Un modello che rivede il proprio output nello stesso contesto, con lo stesso ragionamento che ha prodotto l'errore in primo luogo, tende a difendere il proprio lavoro piuttosto che a esaminarlo genuinamente. Questo non è un difetto specifico di un modello. È un problema strutturale. Lo stesso passaggio che ha generato una risposta plausibile ma sbagliata non è ben posizionato per notare che è sbagliata, perché dall'interno, la risposta sembra ancora plausibile. Chiedere "sei sicuro?" produce rassicurazioni più spesso di quanto produca un vero riesame.

La soluzione non è chiedere meglio. È l'architettura. Un vero ciclo di autocorrezione separa il lavoro di produrre una risposta dal lavoro di giudicarla, usando un passaggio diverso, un prompt diverso, e idealmente un quadro di riferimento completamente diverso, in modo che il giudizio non sia contaminato dagli stessi punti ciechi che hanno creato l'errore.

I Tre Ruoli di Cui Ogni Ciclo di Autocorrezione Ha Bisogno

Ogni sistema di autocorrezione funzionante, indipendentemente dall'attività specifica, si riduce a tre ruoli distinti. Capire chiaramente questi ruoli è più importante di qualsiasi prompt specifico sotto, perché una volta che li vedi, puoi costruire un ciclo per quasi ogni attività inserendo i dettagli.

Il Creatore. Produce l'output effettivo. Scrive il codice, redige il contenuto, fa la ricerca, esegue il compito. A questo ruolo dovrebbe essere data la massima libertà creativa e il minimo vincolo, perché il suo compito è produrre un primo tentativo, non uno perfetto.

Il Giudice. Non costruisce nulla. Il suo unico compito è valutare l'output del Creatore rispetto a uno standard specifico e scritto, non a un vago senso di qualità. Il codice supera i suoi test. La bozza corrisponde al brief. La ricerca risponde effettivamente alla domanda posta. Il Giudice dovrebbe idealmente avere accesso a qualcosa che il Creatore non ha: il materiale originale, la suite di test, il documento dei requisiti effettivo, in modo da avere una verità di base indipendente da controllare, piuttosto che rileggere lo stesso output e formarsi una nuova opinione.

Il Manager. Legge il verdetto del Giudice e decide cosa succede dopo. Inviarlo di nuovo al Creatore con feedback specifici. Segnalarlo a un umano. Contrassegnare l'attività come completata. Qui si trova anche la tua condizione di arresto, la regola che impedisce al ciclo di funzionare all'infinito quando qualcosa non può essere effettivamente corretto automaticamente.

Il principio di progettazione critico in tutti e tre i ruoli: la verifica deve fare riferimento a qualcosa al di fuori del ragionamento del Creatore stesso. Una suite di test. Un documento originale. Una checklist scritta. Una seconda chiamata AI con un'inquadratura genuinamente diversa. Qualsiasi cosa che non sia semplicemente "lo stesso modello, interrogato di nuovo, con lo stesso respiro."

Costruire i Passaggi di Consegna

Il vero lavoro ingegneristico in un ciclo di autocorrezione non sono i prompt intelligenti per ogni ruolo. È la struttura di ciò che passa tra di loro, e questa è la parte che la maggior parte delle persone che costruiscono il loro primo ciclo salta completamente, per poi chiedersi perché il sistema si comporti in modo imprevedibile.

Un passaggio di consegna necessita di tre proprietà per funzionare in modo affidabile. Un formato definito, in modo che il ruolo ricevente non debba analizzare prosa libera e indovinare cosa è importante. Un trigger definito, in modo che non sia il Creatore a decidere quando ha finito. E un percorso di fallimento definito, in modo che quando qualcosa non va liscio, ci sia un passaggio successivo specificato invece che il sistema si rompa silenziosamente o vada in loop all'infinito.

In pratica, questo significa che il Creatore dovrebbe produrre qualcosa di strutturato, non solo testo conversazionale. Un risultato chiaro più una dichiarazione esplicita di ciò di cui è incerto. Il Giudice valuta quindi quell'output strutturato rispetto a uno standard scritto e restituisce il proprio verdetto strutturato, non un paragrafo di prosa vaga, ma un chiaro promosso, bocciato, o necessita-revisione, con il motivo specifico allegato. Il Manager legge quel verdetto strutturato, non il contenuto grezzo, e decide l'azione successiva in base a regole stabilite in anticipo, non improvvisando un giudizio al momento.

Ecco una struttura template che funziona per la maggior parte delle attività, che il lavoro sottostante sia scrittura, codice o ricerca:

1FORMATO OUTPUT DEL CREATORE
2Risultato: [l'output effettivo]
3Confidenza: [alta / media / bassa]
4Incertezze note: [qualsiasi cosa di cui non sei sicuro, dichiarata esplicitamente]
5Assunzioni fatte: [qualsiasi cosa tu abbia assunto senza che ti fosse detto]
6
7FORMATO VERDETTO DEL GIUDICE
8Verdetto: [PROMOSSO / BOCCIATO / NECESSITA REVISIONE]
9Controllato rispetto a: [lo standard specifico utilizzato, ad es. il brief originale,
10la suite di test, il documento originale]
11Problemi specifici trovati: [problemi esatti, non un'impressione generale]
12Confidenza in questo verdetto: [alta / media / bassa]
13
14AZIONE DEL MANAGER
15Se PROMOSSO: segna come completato, consegna all'utente.
16Se BOCCIATO o NECESSITA REVISIONE: rimanda al Creatore con i problemi
17specifici del Giudice allegati. Incrementa il contatore delle revisioni.
18Se il contatore delle revisioni supera [N]: ferma il ciclo, segnala a un umano
19con la cronologia completa di ciò che è stato tentato e perché è fallito.

Sembra più struttura di una conversazione informale andata e ritorno, e lo è. Quel costo iniziale è ciò che ti dà un sistema che si comporta allo stesso modo al centesimo ciclo come al primo, invece di andare alla deriva in modo imprevedibile man mano che il contesto si accumula.

Il Giudice Ha Bisogno di una Verità di Base, Non Solo di un'Opinione

Questo è il principio più importante dell'intero sistema, e merita una sezione a sé perché sbagliarlo mina silenziosamente tutto il resto.

Un Giudice che vede solo l'output del Creatore, senza alcun riferimento indipendente da controllare, può solo valutare la coerenza interna, se l'output sembra coerente e ben formattato. Non può valutare la correttezza, se l'output corrisponde effettivamente a ciò che è stato richiesto o risolve effettivamente il problema reale. Una risposta sicura ma sbagliata, ben formattata e internamente coerente, passerà inosservata a un Giudice senza verità di base ogni volta.

Per le attività di codifica, la verità di base è la suite di test, l'output effettivo dell'esecuzione del codice, i risultati di lint, lo stato della build. Non "questo codice sembra giusto", ma "ha effettivamente superato il test quando è stato eseguito".

Per le attività di contenuto, la verità di base è il materiale originale e il brief originale, affiancati alla bozza. Non "si legge bene", ma "ogni affermazione specifica in questa bozza risale a qualcosa di effettivamente presente nella fonte, e il pezzo soddisfa effettivamente ogni requisito del brief".

Per le attività di ricerca, la verità di base sono i risultati di ricerca effettivi e i documenti originali su cui la ricerca avrebbe dovuto basarsi. Non "questo riassunto suona autorevole", ma "ogni affermazione può essere ricondotta a una fonte specifica, e le fonti che sono state cercate erano effettivamente quelle pertinenti".

Se non riesci ad articolare quale sia la verità di base del Giudice per la tua attività specifica, non hai ancora un ciclo di autocorrezione. Hai un ciclo di riformulazione, dove l'errore sicuro del Creatore viene riformulato con sicurezza dal Giudice invece di essere effettivamente individuato.

La Condizione di Arresto Non è Opzionale

Il modo più comune in cui un ciclo di autocorrezione diventa un pasticcio costoso e fuori controllo è l'assenza di una condizione di arresto esplicita e rigida. Senza di essa, un Creatore e un Giudice possono ciclare indefinitamente, ogni revisione che innesca un'altra valutazione, ogni valutazione che innesca un'altra revisione, mentre i costi aumentano e nessuno se ne accorge fino all'arrivo della fattura.

Una vera condizione di arresto necessita di tre componenti, e tutte e tre dovrebbero essere applicate come logica esplicita, non lasciate al giudizio del modello al momento.

Un numero massimo di iterazioni. Un limite rigido ai cicli di revisione, dopo il quale il Manager è costretto a segnalare a un umano indipendentemente dal fatto che il Giudice sia soddisfatto o meno.

Una soglia di qualità che sia effettivamente misurabile, non aspirazionale. "Abbastanza buono" come istruzione all'interno di un prompt non è una condizione di arresto, perché è un suggerimento che il modello può e ignorerà eventualmente sotto la giusta pressione. Una barra specifica e verificabile, tutti gli undici casi di test vengono superati, o la bozza corrisponde a tutti e cinque i requisiti del brief dichiarati, è una condizione di arresto, perché può essere verificata meccanicamente piuttosto che giudicata soggettivamente ogni volta.

Un tetto di costo o di tempo. Un budget assoluto che l'attività non può superare indipendentemente dallo stato in cui si trova quando quel tetto viene raggiunto. Questa è la protezione che ti protegge specificamente dallo scenario peggiore, un'attività genuinamente irrisolvibile che va in loop finché qualcuno non nota la fattura.

CONDIZIONI DI ARRESTO

Revisioni massime: 3. Al 3° verdetto fallito, fermati e segnala

a un umano con la cronologia completa delle revisioni allegata, non tentare

un 4° ciclo automaticamente.

Soglia di qualità: tutti gli elementi della checklist del Giudice devono mostrare PROMOSSO,

non "per lo più promosso" o "abbastanza vicino."

Tetto di budget: se questa attività ha consumato più di [X] token o

[Y] minuti, fermati immediatamente indipendentemente dallo stato attuale e segnala

cosa è stato completato rispetto a ciò che rimane.

Scrivi questi nella logica effettiva del Manager, non in un'istruzione morbida all'interno di un prompt più lungo che il modello può superare sotto pressione.

Un Esempio Pratico: Produzione di Contenuti con Autocorrezione

Per rendere la cosa concreta, ecco esattamente come i tre ruoli e la condizione di arresto si uniscono per un'attività reale e comune: trasformare un documento originale in un contenuto finito senza che un umano rilegga manualmente ogni bozza.

Il Creatore riceve il materiale originale e il brief, e produce una bozza. Il suo output include la bozza stessa, più una dichiarazione di confidenza esplicita e un elenco di tutto ciò di cui era incerto durante la scrittura, un numero specifico di cui non era completamente sicuro fosse nella fonte, un'affermazione che ha dedotto piuttosto che trovato dichiarata direttamente.

Il Giudice riceve la bozza e la fonte originale affiancate, mai la bozza in isolamento. Controlla tre cose specifiche, ciascuna con il proprio promosso o bocciato. Ogni affermazione fattuale nella bozza risale a qualcosa di effettivamente presente nella fonte. La bozza soddisfa ogni requisito specifico del brief, lunghezza, tono, sezioni richieste. L'argomento o il gancio principale è effettivamente presente e non diluito da riempitivi. Il Giudice restituisce un verdetto strutturato con un promosso o bocciato su ciascuno dei tre controlli separatamente, perché comprimere tutto in un unico punteggio complessivo nasconde esattamente quale dimensione è fallita.

Il Manager legge quel verdetto strutturato. Un promosso pulito su tutti e tre invia la bozza a una coda di output finale. Un fallimento sulla dimensione del controllo dei fatti la rimanda al Creatore con l'affermazione non verificata specifica segnalata direttamente, non un'istruzione vaga di "ricontrollare l'accuratezza." Un fallimento sulla conformità al brief la rimanda con il requisito mancante specifico nominato. Dopo tre cicli falliti sullo stesso controllo specifico, il Manager interrompe completamente il ciclo e segnala a un umano con la cronologia completa di ciò che è stato tentato, piuttosto che continuare a riprovare un problema che il sistema ha già dimostrato di non poter risolvere da solo.

Questo è un sistema piccolo. Tre ruoli, un formato di passaggio di consegna strutturato, una condizione di arresto esplicita. È anche un sistema che potresti genuinamente eseguire senza supervisione e di cui ti fideresti dell'output, perché ogni modo di fallimento ha un percorso definito invece di uno indefinito.

Testare il Ciclo Prima di Fidarsi

Prima di affidarti a qualsiasi sistema di autocorrezione per qualcosa di veramente importante, eseguilo deliberatamente attraverso questi specifici stress test. La maggior parte dei cicli che falliscono nell'uso reale avrebbero fallito immediatamente uno di questi test, se qualcuno si fosse preoccupato di controllare prima.

Il test del compito irrisolvibile. Dai deliberatamente al Creatore un compito che non può completare secondo lo standard del Giudice, apposta. Il Manager raggiunge correttamente il limite di iterazioni e segnala a un umano, o continua a girare all'infinito, bruciando costi su un compito che non sarebbe mai riuscito?

Il test dell'errore sicuro ma sbagliato. Dai al Giudice un output che sai già essere sottilmente sbagliato, qualcosa che si legge bene ma contiene un errore fattuale o logico specifico. Il Giudice, con il suo riferimento di verità di base, lo individua correttamente? Se il Giudice promuove qualcosa che sai essere rotto, il tuo riferimento di verità di base non viene effettivamente controllato, o il controllo è troppo superficiale.

Il test del punto cieco dello stesso modello. Se il tuo Creatore e Giudice girano sullo stesso modello sottostante, vale la pena controllarlo direttamente. Dai al Giudice un output contenente esattamente il tipo di errore che quel modello tende caratteristicamente a fare. Se il Giudice lo lascia passare, hai costruito un ciclo che condivide i suoi punti ciechi tra i ruoli, il che vanifica l'intero scopo di separarli. Considera l'uso di un modello genuinamente diverso, o almeno di un'inquadratura del prompt significativamente diversa, per il ruolo del Giudice specificamente.

Il test della fuga di costi. Calcola il percorso peggiore attraverso il tuo sistema, revisioni massime, chiamate di modello più costose coinvolte, lunghezza del contenuto ragionevole più lunga, e calcola quanto costa effettivamente in dollari reali e tempo reale. Se quel numero ti allarmerebbe apparire su una fattura reale, le tue condizioni di arresto non sono ancora abbastanza strette.

Eseguire questi quattro test prima di fidarsi di un ciclo di autocorrezione con qualcosa di reale coglie la stragrande maggioranza dei fallimenti che altrimenti si presenterebbero per la prima volta di fronte a un cliente, un capo, o il tuo stesso estratto conto.

Errori Comuni che Rompono Silenziosamente un Design Altrimenti Buono

Anche con la giusta architettura a tre ruoli, una manciata di errori di implementazione specifici si ripresentano ripetutamente in domini completamente diversi, e conoscerli in anticipo ti evita di riscoprire ciascuno nel modo più duro.

Lasciare che il Giudice veda solo l'output del Creatore, senza alcun riferimento indipendente. Questo è l'errore più comune di gran lunga, e trasforma silenziosamente il tuo sistema da un controllo di correttezza a un controllo di coerenza. Un Giudice senza nulla con cui confrontarsi può solo dirti che l'output sembra internamente coerente, mai se sia effettivamente corretto.

Dare a ogni ruolo lo stesso modello con solo una sottile differenza di istruzione sovrapposta. Se il Giudice esegue lo stesso modello sottostante del Creatore, con solo un prompt diverso che gli dice di "essere critico", spesso eredita gli stessi identici punti ciechi del Creatore, perché è fondamentalmente lo stesso processo di ragionamento che indossa un cappello diverso. Dove il budget lo consente, un modello genuinamente diverso per il ruolo del Giudice produce una reale indipendenza piuttosto che una indipendenza teatrale.

Trattare il Manager come un semplice pass-through invece di dargli una vera memoria dei tentativi precedenti. Un Manager senza visibilità su ciò che è già stato tentato su questa attività specifica invierà felicemente lo stesso feedback fallito al Creatore una seconda e terza volta, producendo lo stesso risultato fallito identico ogni volta, perché nulla nel sistema ricorda che questo esatto approccio è già fallito una volta.

Saltare i quattro stress test perché il sistema ha funzionato bene nell'unica demo eseguita che tutti hanno guardato attentamente. Un sistema che si comporta correttamente mentre lo guardi attentamente e un sistema che si comporta correttamente mentre funziona senza supervisione sono affermazioni diverse. Solo la seconda è il vero scopo di costruire un ciclo di autocorrezione in primo luogo. Se non hai testato deliberatamente le modalità di fallimento, non sai effettivamente quale affermazione sia vera per il tuo sistema.

Scrivere la condizione di arresto come un'istruzione morbida invece di una logica rigida. "Fermati quando è abbastanza buono" all'interno di un prompt non è una condizione di arresto, è un suggerimento che il modello può e ignorerà sotto la giusta pressione. Un contatore di iterazioni rigido che il Manager controlla meccanicamente prima di permettere un altro ciclo è una condizione di arresto. La differenza tra questi due conta enormemente la prima volta che un compito si rivela genuinamente irrisolvibile.

Un Secondo Esempio Pratico: Codice con Autocorrezione

La stessa struttura sembra diversa ma segue una logica identica quando il compito è codice invece di contenuto, e vedere entrambi affiancati chiarisce quanto poco cambi effettivamente tra i domini.

Il Creatore qui è un agente di codifica che lavora su un compito definito, una correzione di bug, una funzionalità, un refactoring. Il suo output strutturato non è solo il diff del codice, ma anche l'output effettivo del comando dal tentativo di eseguirlo, i risultati dei test, l'output di lint, lo stato della build, raggruppati nel passaggio di consegna. Un Creatore che produce codice ma non lo esegue mai non sta effettivamente ricoprendo correttamente il ruolo del Creatore, perché codice sintatticamente plausibile che fallisce la propria suite di test è peggio di nessun codice, poiché sembra finito senza esserlo.

Il Giudice controlla tre cose specifiche e verificabili. La modifica ha superato la suite di test esistente senza che i test stessi siano stati modificati? Poiché un Creatore che modifica silenziosamente un test per farlo passare è un fallimento specifico e sorprendentemente comune che vale la pena controllare direttamente. L'analisi statica e il linting sono tornati puliti? Il diff affronta effettivamente il compito che è stato assegnato, non un problema correlato ma diverso che il Creatore ha deciso fosse più interessante da risolvere lungo la strada? Ciascuno di questi riceve il proprio promosso o bocciato esplicito nel verdetto strutturato.

Il Manager instrada in base a quale controllo specifico è fallito. Una suite di test fallita torna al Creatore con l'output del test fallito esatto allegato direttamente, non un'istruzione generica di "correggere i test." Una discrepanza di ambito, dove il diff ha risolto un problema diverso da quello assegnato, viene segnalata immediatamente a un umano piuttosto che andare in loop, perché si tratta di un fallimento di giudizio su quale fosse effettivamente il compito, non di un difetto meccanico che il Creatore può semplicemente risolvere iterando da solo.

Nota che la struttura sottostante qui, Creatore produce e invia con prove, Giudice controlla rispetto a criteri specifici nominati con un verdetto per controllo, Manager instrada in base esattamente a quale controllo è fallito, è identica all'esempio di produzione di contenuti sopra. Questa è la vera lezione che vale la pena portare avanti vedendo due domini diversi affiancati. Una volta che hai la struttura corretta, applicarla a un nuovo tipo di compito è principalmente una questione di scrivere una nuova checklist specifica per il Giudice, non di riprogettare l'intera architettura da zero ogni volta.

Scalare a Più Cicli Concorrenti

Una volta che un singolo ciclo di autocorrezione è genuinamente affidabile, la prossima vera domanda è come eseguirne diversi contemporaneamente senza che il sistema diventi ingestibile, poiché è esattamente qui che la maggior parte delle persone sbaglia il secondo tentativo di scalare.

La tentazione è di avviare molti cicli simultaneamente non appena il primo funziona, affrontando cinque compiti diversi in parallelo perché l'architettura lo supporta tecnicamente. Resisti più a lungo di quanto sembri necessario. Ogni ciclo concorrente aggiuntivo è un altro posto dove una condizione di arresto può fallire silenziosamente, un altro posto dove i costi possono scappare inosservati, un altro posto dove il riferimento di verità di base di un Giudice potrebbe essere sottilmente sbagliato in un modo che si mostra solo sotto volume reale piuttosto che in un singolo test di esecuzione.

Il percorso di scaling più sicuro è l'espansione sequenziale con una genuina soglia di fiducia ad ogni passo. Ottieni un ciclo che funziona in modo abbastanza affidabile da aver smesso di controllare attentamente il suo output, il che significa che supera costantemente i tuoi controlli a campione manuali per un periodo di tempo reale, non solo una singola demo di successo. Solo allora aggiungi un secondo ciclo per un compito diverso. Tieni traccia del tasso di fallimento effettivo di ogni ciclo nel tempo, non solo se sembrava funzionare sulle esecuzioni che ti è capitato di osservare.

Quando esegui più cicli contemporaneamente, dai seria considerazione a un dashboard di costi condiviso per tutti, non al monitoraggio per ciclo in isolamento. Un singolo ciclo con un budget ragionevole per attività sembra completamente a posto in isolamento. Dieci cicli ciascuno individualmente entro il budget possono comunque sommarsi a un totale genuinamente allarmante che nessuno nota fino all'arrivo della fattura aggregata, proprio perché il monitoraggio di ogni singolo ciclo sembrava a posto da solo.

L'unica abitudine che previene i problemi di scaling prima che inizino: registra ogni innesco di condizione di arresto in ogni ciclo, non solo i completamenti con successo. Un ciclo che raggiunge il suo limite massimo di iterazioni e segnala a un umano sta facendo esattamente ciò che dovrebbe fare, ma se un ciclo specifico raggiunge costantemente quel limite mentre altri raramente lo fanno, questo è un segnale che lo standard del Giudice per quel particolare compito è o mal calibrato, troppo severo per passare effettivamente, o sta controllando rispetto alla verità di base sbagliata. Quel modello è invisibile se stai tracciando solo i successi e trattando ogni escalation come un evento isolato e irrilevante piuttosto che come un dato puntuale sul design di quel ciclo specifico.

Da Dove Iniziare Questa Settimana

Non provare a costruire un sistema di autocorrezione completamente generale al primo tentativo. Scegli un compito specifico, ristretto, ben definito che fai già regolarmente, qualcosa con uno standard chiaro che potresti scrivere se ti venisse chiesto, e costruisci il ciclo a tre ruoli attorno a quel singolo compito per primo.

Scrivi la checklist del Giudice esplicitamente prima di scrivere una singola riga del prompt del Creatore. Lo standard che stai controllando dovrebbe modellare ciò che chiedi al Creatore di produrre, non il contrario. Se non riesci ancora a scrivere la checklist, non sai ancora abbastanza cosa significa "corretto" per questo compito per automatizzare la verifica, e vale la pena scoprirlo prima di costruire qualsiasi cosa.

Esegui i quattro stress test sopra prima di fidarti del ciclo con qualcosa che conta davvero, non dopo che qualcosa è già andato storto di fronte a qualcuno. Aggiungi la condizione di arresto come logica reale e rigida fin dalla primissima versione, non come ripensamento una volta che sei già stato bruciato da un ciclo fuori controllo.

Una volta che un ciclo è genuinamente affidabile, funziona senza supervisione, coglie errori reali, si ferma pulitamente quando dovrebbe, il secondo va molto più veloce. Non perché i prompt si trasferiscano direttamente, di solito devono essere riscritti per il nuovo compito, ma perché capisci già la forma effettiva del problema. Separa la costruzione dal giudizio. Dai al giudizio qualcosa di reale da controllare. Scrivi la condizione di arresto come logica, non come speranza.

Quella forma è l'intera disciplina. Tutto il resto è solo applicarla al compito che hai di fronte.

Segui @cyrilXBT per i modelli di ciclo esatti e le configurazioni Creatore-Giudice-Manager alla base di tutto in questo articolo.