Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Con Claude Fable 5 la qualità delle risposte non è più limitata dalla potenza del modello, ma dalla capacità di chi scrive i prompt di riconoscere i propri punti ciechi. Lo spiega Thariq Shihipar, sviluppatore Anthropic, in una serie di consigli pratici che ribaltano l’approccio tradizionale: prima di chiedere, bisogna capire cosa non si sa. Il modello, riattivato il 1° luglio 2026 dopo poco più di due settimane di blocco governativo e protetto da un nuovo classificatore che blocca in oltre il 99% dei casi la tecnica per aggirare le protezioni segnalata nel report Amazon, è così performante che il vero collo di bottiglia sono gli «unknown unknowns» dell’utente.
Unknown Unknowns: la matrice dei punti ciechi
Shihipar adatta la celebre matrice della conoscenza per descrivere ciò che accade quando interroghiamo un modello di frontiera come Fable 5. La differenza la fanno soprattutto le cose che non abbiamo neppure preso in considerazione.
| Categoria | Significato |
|---|---|
| Known Knowns | Ciò che è dichiarato esplicitamente nel prompt. |
| Known Unknowns | Domande che sappiamo di non aver ancora risolto. |
| Unknown Knowns | Conoscenza talmente ovvia che non la scriveremmo mai, ma la riconosceremmo subito. |
| Unknown Unknowns | Cose che non abbiamo affatto considerato. |
Per Shihipar, Fable 5 è il primo modello in cui la qualità dell’output viene frenata proprio dalla difficoltà dell’utente di far emergere gli unknown unknowns. I programmatori più esperti con gli agenti di codice ne hanno pochi, aggiunge, ma si aspettano sempre di incontrarne.
Troppo specifici o troppo vaghi: l’errore che blocca Fable 5
La pianificazione anticipata non basta. Essere troppo specifici rischia di inchiodare Fable 5 a istruzioni che andrebbero cambiate in corso d’opera; essere troppo vaghi produce risposte generiche basate su impostazioni standard inadatte al compito specifico. «When you don’t account for your unknowns you fail both ways» (se non tieni conto delle tue incognite, sbagli in entrambi i casi), scrive Shihipar.
La via d’uscita è fornire a Claude abbastanza contesto sul proprio punto di partenza – a che punto si è con il ragionamento, quale esperienza si ha del problema – e usare il modello per scoprire più in fretta ciò che non si sa. Claude può scandagliare codebase e cercare online a velocità elevata, e conosce la maggior parte degli argomenti meglio dell’utente medio.
Le tecniche per eliminare i punti ciechi prima di scrivere codice
Shihipar descrive diverse tecniche da applicare prima ancora di iniziare l’implementazione. Il filo conduttore è trasformare ogni sessione di prompting in un’indagine su ciò che ancora non si conosce.
- Blindspot pass. Chiedere direttamente a Claude di identificare gli unknown unknowns. Un prompt d’esempio: «Sto lavorando per aggiungere un nuovo provider di autenticazione, ma non so nulla dei moduli auth in questa codebase. Puoi fare un blindspot pass per aiutarmi a individuare gli unknown unknowns rilevanti e suggerirmi come formulare meglio i prompt?»
- Brainstorming e prototipazione. Per i campi in cui abbondano gli «unknown knowns», come il design visivo, Shihipar fa generare a Claude diverse direzioni progettuali molto diverse tra loro sotto forma di artefatti HTML, in modo da poter reagire a qualcosa di concreto.
- Interviste strutturate. Claude pone una domanda dopo l’altra sulle ambiguità del progetto, dando priorità a quelle le cui risposte cambierebbero l’architettura.
- Note di implementazione. Durante la codifica, un file temporaneo
implementation-notes.mdregistra ogni decisione presa da Claude, così da poter imparare dal tentativo successivo. Se emergono casi limite imprevisti, il modello sceglie l’opzione più conservativa, annota lo scostamento e prosegue. - Pitch, spiegazioni e quiz. A implementazione conclusa, Shihipar fa produrre a Claude documenti di sintesi per gli stakeholder e un report HTML con un quiz sulle modifiche effettuate. Non si fa merge finché non si supera il quiz senza errori.
L’intero flusso è stato messo alla prova nel montaggio del video di lancio di Fable, interamente realizzato con Claude Code. Shihipar non aveva esperienza di video editing: è partito da ciò che sapeva (Claude può editare e trascrivere video con codice), ha chiesto a una persona esperta di spiegargli come funziona la trascrizione con Whisper e se si potessero tagliare pause e parole di riempimento con ffmpeg, ha costruito un prototipo con Remotion per le sovrimpressioni sincronizzate e, quando il colore risultava piatto, invece di valutare alla cieca diverse varianti di color grading si è fatto insegnare da Claude i fondamenti della materia per far emergere le proprie lacune.
«Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix» (ogni spiegazione, brainstorming, intervista, prototipo e riferimento è un modo economico per scoprire ciò che non sapevi, prima che correggerlo diventi costoso), sintetizza Shihipar.
Perché il prompting resta il fattore decisivo anche dopo il ritorno di Fable 5
Fable 5 era stato sospeso dal governo statunitense il 12 giugno 2026, dopo che un report di ricercatori Amazon aveva mostrato una tecnica per aggirare alcune protezioni del modello e ottenere codice dimostrativo di sfruttamento di vulnerabilità software. La riattivazione del 1° luglio è stata accompagnata da un nuovo classificatore di sicurezza che blocca oltre il 99% dei tentativi di riprodurre quella tecnica, con un margine di sicurezza (safety margin) deliberatamente più ampio rispetto al passato, a costo di qualche falso positivo in più sulle attività lecite di coding e debugging.
Dal 1° al 7 luglio 2026 Fable 5 è incluso fino al 50% dei limiti settimanali per i piani Pro, Max, Team e per alcuni Enterprise; dopo quella data sarà disponibile tramite crediti d’uso. La finestra di utilizzo rende ancora più preziosa la capacità di ottenere output di qualità con pochi prompt mirati.
Qui le strategie di Shihipar si saldano con l’impostazione di sicurezza di Anthropic: il modello è potente e sorvegliato, ma la differenza di risultato la fa ancora chi scrive il prompt. La lezione per sviluppatori e professionisti è netta: investire tempo nel definire i propri unknown unknowns non è un lusso, è l’unico modo per sfruttare davvero un modello di frontiera senza sprecare tentativi e senza incappare nei falsi positivi dei classificatori.
Fonti
