Un modello come Claude può lavorare da solo su un progetto software per ore, anche di notte. Funziona però solo dentro una struttura che lo obbliga a dimostrare ogni passo con un test, e non a dichiararlo fatto.
In questi giorni circola un prompt per Claude Fable 5.2 che organizza il lavoro proprio così: un piccolo team di agenti con ruoli separati, regole sulle prove e un resoconto pronto al mattino. Lo smontiamo pezzo per pezzo, accostandolo a quello che Anthropic ha pubblicato sul suo blog di ingegneria.
Il problema: un agente non ricorda la sessione precedente
Un lavoro di una notte intera non sta in una sola sessione. L'agente lavora a blocchi, e ogni blocco riparte senza ricordare cosa è successo prima. Anthropic lo descrive così nel post di novembre 2025 sugli agenti di lunga durata (Effective harnesses for long-running agents).
Nello stesso post gli errori tipici sono due. L'agente prova a fare troppo in un colpo solo e lascia lavori a metà senza documentarli. Oppure, verso la fine, dichiara il progetto finito prima del tempo.
La soluzione proposta non è un modello più intelligente, è un'organizzazione fatta di file:
- un file di avanzamento che ogni sessione legge all'inizio e aggiorna alla fine;
- una lista di funzionalità in JSON, tutte segnate come "non superate" finché qualcuno non le verifica;
- commit git descrittivi, così la sessione successiva capisce cosa è cambiato e può annullare un errore;
- uno script di avvio, per non perdere tempo ogni volta a capire come far partire l'app.
Nel prompt che circola questo ruolo lo svolge NOTES.md. Il Mapper lo scrive all'inizio (comandi, struttura dei moduli, file a rischio) e il team lo aggiorna dopo ogni passo, "così la notte sopravvive a un crash o a un riavvio".
Il ciclo di lavoro
Il prompt fissa un ordine preciso: Mappa, test che fallisce, modifica minima, verifica, revisione. Se il Prover non riesce a riprodurre il risultato, la modifica torna al Builder con l'output esatto dell'errore. Arriva in pull request solo ciò che ha passato entrambi i controlli.
I ruoli del team e perché chi scrive non deve giudicare
Il prompt divide il lavoro tra sei agenti. Ognuno ha un compito stretto e, soprattutto, qualcosa che non può fare.
| Ruolo | Cosa fa | Cosa non fa |
|---|---|---|
| Lead | Pianifica, assegna, verifica, ed è l'unico che vi scrive | Non scrive codice delle funzionalità |
| Mapper | Legge tutto il repository e scrive NOTES.md | Non modifica il codice |
| Breaker | Trasforma ogni issue in un test che fallisce | Non implementa la soluzione |
| Builder (fino a 4) | Uno per issue indipendente, scrive la modifica | Non tocca file che non sono suoi |
| Prover | Riesegue da zero, in sola lettura, ogni controllo che un builder dichiara superato. Se rifiuta, la decisione è definitiva | Non corregge, rimanda indietro |
| Reviewer | Legge ogni diff contro la specifica "come uno sconosciuto che la detesta" | Non approva per simpatia |
La separazione più importante è tra chi scrive e chi controlla. Nel post di marzo 2026 sulla progettazione degli harness (Harness design for long-running application development), Anthropic osserva che un agente che valuta il proprio lavoro tende a lodarlo con sicurezza anche quando la qualità è mediocre. Rendere scettico un valutatore esterno è molto più facile che rendere autocritico chi ha prodotto il codice.
Per questo nel prompt il Prover gira in un contesto nuovo: non ha visto come è nato il codice, e quindi non ha niente da difendere. Ogni passaggio di consegne usa sempre gli stessi quattro campi: ISSUE, TEST, EVIDENCE, NEXT STEP.
Cosa conta come prova
Nel prompt una cosa è fatta solo se uno strumento lo ha dimostrato durante la sessione: un test che passa, un controllo dei tipi, un benchmark, un diff. Frasi come "dovrebbe funzionare" o "sembra giusto" non valgono.
Il punto di partenza è un test che fallisce. Prima che qualcuno scriva codice, il Breaker traduce l'issue in un test rosso. Se non ci riesce, il problema non è ancora stato capito, e l'agente deve fare una domanda invece di tirare a indovinare. Poi vince la modifica più piccola che fa diventare verde quel test.
Tre regole impediscono di barare:
- Nessun test può essere indebolito, saltato o cancellato per ottenere il verde.
- Se un qualsiasi test della suite completa diventa rosso, il lavoro nuovo si ferma finché la regressione non è risolta.
- Prima del resoconto il team rifà i controlli: ogni test falliva prima e passa dopo? La suite passa su un checkout pulito? È cambiato qualcosa che nessuno aveva chiesto?
Un avvertimento che arriva da Anthropic. Nei loro esperimenti Claude tendeva a fermarsi agli unit test o a chiamate curl, senza verificare l'app dal punto di vista di chi la usa. Il salto di qualità è arrivato con l'automazione del browser, che ha fatto emergere bug invisibili leggendo solo il codice (fonte). I test valgono quanto ciò che controllano davvero.
Cosa serve per farlo girare
Questo prompt non va incollato in una chat. Serve un ambiente in cui gli agenti possano leggere il repository, lanciare comandi ed eseguire test, per esempio Claude Code. Il prompt dà per scontati tre elementi:
- un repository esistente, con issue o funzionalità già descritte;
- una suite di test che si lancia con un solo comando, altrimenti il Prover non ha niente da rieseguire;
- permessi limitati: niente segreti, dati di produzione, migrazioni, fatturazione o pubblicazioni senza il vostro sì. Il prompt lo chiede a parole, ma conviene imporlo anche con i permessi dell'ambiente.
Poi ci sono i costi. Un team di agenti costa molto più di un agente singolo, e Anthropic ha pubblicato numeri precisi. Nel post di marzo 2026, un generatore di videogiochi retrò costruito da un agente solo ha richiesto 20 minuti e 9 dollari, ma il gioco non funzionava. Con l'harness completo a tre agenti ci sono volute 6 ore e 200 dollari, e il risultato era nettamente migliore. Una DAW nel browser, con l'harness aggiornato, è costata circa 3 ore e 50 minuti e 124,70 dollari (fonte).
Quei test usavano modelli precedenti (Opus 4.5 e 4.6), quindi non valgono come preventivo per Fable 5.2. Indicano però l'ordine di grandezza, e spiegano perché il prompt chiede subito un budget in ore e in dollari.
Come adattare il prompt al vostro progetto
Il prompt ha dei segnaposto tra parentesi quadre. Vanno compilati con cura, perché decidono quanto lavoro parte e con quali confini.
| Segnaposto | Cosa inserire |
|---|---|
| [REPO] | Il repository su cui lavorare |
| [ISSUES / FEATURE] | Issue già scritte e circoscritte, non un'idea di prodotto |
| [07:30] | L'ora del resoconto mattutino |
| max [4] builder | Quante issue indipendenti lavorare in parallelo |
| [20 minuti] | Dopo quanto tempo un agente bloccato scrive una domanda, mette da parte l'issue e passa alla successiva |
Prima del primo avvio il Lead vi fa al massimo quattro domande: cosa significa "fatto", cosa non va mai toccato, quali sono i comandi di build e di test, qual è il budget in ore e in dollari. Le risposte diventano le regole del team, che ogni agente legge prima di agire. Il prompt chiede anche di vedere il team, l'ordine delle issue e il piano della notte prima del via. Conviene fermarsi davvero a leggerli.
Al mattino non arriva un prodotto finito. Arrivano pull request, ognuna con un riepilogo di una riga, il test che la dimostra, l'output prima e dopo, i file toccati, il livello di rischio, il modo per annullarla e una sezione "perché questo potrebbe rompersi". Insieme arriva una tabella con lo stato di ogni issue (dimostrata, bloccata, parcheggiata) e una sola decisione da prendere: merge, riprovare o scartare.
Quella decisione resta a voi. Il valore del metodo sta qui: la notte produce lavoro già verificato e documentato, e la mattina si spende a decidere, non a ricontrollare.
Il prompt da copiare
Ecco il prompt completo, così come circola. Copiatelo e compilate i segnaposto tra parentesi quadre prima di avviarlo.
<prompt>
<role> Act as my senior engineering team that ships while I sleep. One lead, five specialists, one rule: nothing is done until a machine proves it. Think like a staff engineer who has been burned by "works on my machine": trust tool output, never confidence. </role>
<objective> Take [REPO] from [ISSUES / FEATURE] to merge-ready pull requests by [07:30]. Every change ships with the test that proves it, a green full suite and a reviewed diff. </objective>
<intake> Before the first run, ask me max 4 questions: what "done" means, what you must never touch, my build and test commands, and my budget in hours and dollars. Save the answers as Team Rules every agent reads before acting. </intake>
<crew> Lead plans, assigns and verifies, never writes feature code, and is the only agent that messages me. Mapper reads the whole repo first and writes NOTES.md: commands, module seams, risky files. Breaker turns every issue into a failing test before anyone builds. Builders, one per independent issue (max [4]), each own their files and nothing else. Prover runs in a fresh read-only context and re-runs every check a builder claims; its rejection is final. Reviewer reads each diff against the spec like a stranger who hates it. Every handoff uses ISSUE, TEST, EVIDENCE, NEXT STEP. </crew>
<proof> A claim counts only with evidence from a tool run in this session: a passing test, a type check, a benchmark or a diff. "Should work", "looks right" and "probably" are not evidence. No failing test first means the issue is not understood yet: ask, don't guess. </proof>
<loop> Map → Break → Build → Prove → Review. The smallest change that turns the test green wins. If the Prover can't reproduce it, it goes back to the builder with the exact output. Anything red in the full suite stops new work until the regression is fixed. Checkpoint NOTES.md after every step so the night survives a crash or a restart. </loop>
<rules> Never weaken, skip or delete a test to get green. Never touch secrets, production data, migrations, billing or anything public without my yes. No new dependency without a reason in the PR. No refactors beyond the issue. Stuck for [20 minutes]: write one question, park the issue, move on. </rules>
<pr_format> For each PR: one-line summary, the issue it closes, the test that proves it, output before and after, files touched, risk level, and how to roll it back. </pr_format>
<morning_brief> At [07:30] send me one message: a table of issue, proving test and status (proven / blocked / parked) with the reason; total time and cost; every Prover rejection and how it was resolved; and one decision for me: merge, retry or drop. </morning_brief>
<final_check> Before reporting, attack your own work. Did every test fail before the change and pass after it? Does the full suite pass on a clean checkout? Did anything change that nobody asked for? Would the diff survive a reviewer who hates it? End each PR with "WHY THIS COULD BREAK" and prefer a boring fix with proof over a clever one without it. </final_check>
<start> First, ask me your 4 questions. Then show me the crew, the issue order and tonight's plan, and wait for my go. </start>
</prompt>
Fonti
- Effective harnesses for long-running agents, Justin Young, Anthropic Engineering, 26 novembre 2025
- Harness design for long-running application development, Prithvi Rajasekaran, Anthropic Engineering, 24 marzo 2026
- Il testo del prompt analizzato circola come screenshot sui social. Non siamo riusciti a risalire all'autore originale.