A Field Guide to Fable: Finding Your Unknowns

Punti chiave

1. Metafora guida: la mappa non è il territorio. La mappa = ciò che si fornisce a Claude (prompt, skill, contesto). Il territorio = dove il lavoro avviene realmente (codebase, mondo reale, vincoli). Lo scarto tra i due = gli unknowns. Di fronte a un unknown, Claude decide sulla base della sua migliore ipotesi su ciò che si desidera → più ampio è il lavoro, più unknowns incontra.
2. Il plateau di Fable. "Fable è il primo modello in cui trovo che la qualità del lavoro sia limitata dalla mia capacità di chiarire i suoi unknowns" — il collo di bottiglia si è spostato dal modello alla chiarezza umana. Pianificare in anticipo non basta: gli unknowns emergono a metà implementazione, oppure rivelano che il problema andava risolto diversamente. → un processo iterativo: scoprire i propri unknowns prima, durante e dopo.
3. I 4 quadranti (matrice degli unknowns). Known knowns = ciò che è nel prompt (ciò che si dichiara di volere); Known unknowns = ciò che non è ancora stato risolto ma di cui si è consapevoli; Unknown knowns = "troppo ovvio da scrivere, ma lo riconoscerei" (il "lo saprò quando lo vedrò"); Unknown unknowns = "la buca che non si sapeva potesse esserci sulla strada".
4. La vera competenza. "ridurre e pianificare i propri unknowns è LA competenza della programmazione agentica". I migliori (cita Boris, Jarred) hanno pochi unknowns (in sintonia sia con la codebase sia con i comportamenti del modello) ma presumono che alcuni restino. Buona notizia: è una competenza che migliora lavorando con Claude.
5. Istruire Claude è un equilibrio delicato. Troppo preciso → Claude segue le istruzioni anche quando sarebbe meglio un cambio di rotta. Troppo vago → Claude colma i vuoti con le best practice del settore, non necessariamente adatte al caso. Senza gestire i propri unknowns, si fallisce su entrambi i fronti. Rimedio: fornire a Claude il contesto sul proprio punto di partenza (dove si è nel proprio ragionamento, la propria esperienza col problema) e trattarlo come un partner di pensiero. Claude esplora la codebase e il web molto rapidamente e itera dal fallimento più velocemente di noi.
6. PRIMA — Blindspot pass. quando si lavora in territorio sconosciuto (unknown unknowns), chiedere a Claude di trovare e spiegare i propri punti ciechi. Usare le parole letterali "blindspot pass" e "unknown unknowns" più il contesto su chi si è. Es. "sto aggiungendo un nuovo provider di autenticazione ma non so nulla dei moduli di auth… fai un blindspot pass"; "insegnami a capire i miei unknown unknowns sul color grading così posso scrivere prompt migliori".
7. PRIMA — Brainstorm & prototipi. per gli unknown knowns (criteri definibili solo vedendoli, ad es. il design visivo). Verbalizzarli precocemente, poiché scoprirli durante l'implementazione è costoso (una piccola modifica alla specifica può significare codice radicalmente diverso, difficile da annullare). Iniziare quasi ogni sessione con una fase di esplorazione/brainstorm per inquadrare l'ambito (né troppo ristretto né troppo ampio). Es. "fammi una pagina HTML con 4 direzioni di design radicalmente diverse così posso reagire"; "simula la nuova toolbar in un unico file HTML con dati fittizi prima di toccare l'app reale"; "fai un brainstorm di 10 punti di intervento possibili, dal più economico al più ambizioso".
8. PRIMA — Interviste. dopo il brainstorm, chiedere a Claude di intervistarci sulle ambiguità rimanenti, una domanda alla volta, dando priorità alle "domande la cui risposta cambierebbe l'architettura".
9. PRIMA — Riferimenti. quando non si riesce a descrivere ciò che si vuole, il miglior riferimento è il codice sorgente. Indicare a Fable una cartella/libreria (anche in un altro linguaggio) e dire cosa cercarvi. Claude Design funziona così: puntato su un modulo di un sito, legge il codice sottostante (markup, struttura, costruzione effettiva), non solo lo screenshot. Es. "questo crate Rust implementa esattamente il backoff che voglio — reimplementa la stessa semantica nel nostro client TypeScript".
10. PRIMA — Implementation plan. chiedere un piano guidato dalle decisioni più suscettibili di cambiare (modelli di dati, interfacce di tipo, flussi UX) e relegando in fondo il refactoring meccanico ("su quella parte mi fido di te"). Il piano fa emergere ciò che effettivamente andrà modificato.
11. DURANTE — Implementation notes. per quanta pianificazione si faccia, restano unknown unknowns (l'agente trova un edge case mentre scrive il codice). Far tenere a Claude Code un implementation-notes.md temporaneo in cui registra le decisioni "così da poter imparare per il nostro prossimo tentativo". Es. "se incontri un edge case che impone una deviazione, scegli l'opzione conservativa, registrala sotto 'Deviations' e continua".
12. DOPO — Pitch & explainer. shippare significa ottenere consenso e approvazioni. Impacchettare prototipo + specifica + note in un unico documento che "parta dalla GIF della demo" → accelera la comprensione (i revisori partono dagli stessi unknowns) e le approvazioni (gli esperti vogliono vedere che i loro punti di rottura sono stati coperti).
13. DOPO — Quiz. dopo una lunga sessione, leggere i diff dà solo una comprensione superficiale (il comportamento dipende dai percorsi di codice esistenti). Chiedere a Claude un report HTML + un quiz sulle modifiche — "non integro finché non supero perfettamente il quiz".
14. Prova concreta: il video di lancio di Fable. , montato interamente con Claude Code in un ambito che Thariq non padroneggiava — parte da ciò che conosce (Claude può montare/trascrivere video tramite codice), si fa spiegare Whisper/ffmpeg, prototipa un'interfaccia sincronizzata sulle parole via Remotion, poi si fa insegnare da Claude il color grading (non avendo idea di cosa significhi "buono") invece di generare varianti alla cieca.
15. Punchline. "ogni explainer, brainstorm, intervista, prototipo e riferimento è un modo economico per scoprire ciò che non si sapeva prima che diventi costoso da correggere" → "inizia il tuo prossimo progetto chiedendo a Claude di aiutarti a trovare i tuoi unknowns". Il residuo dell'apprendimento diventa la mappa per la volta successiva ("ciò che si impara diventa la mappa per la prossima volta").
16. Collegamenti. converge con il Compounding Knowledge Lifecycle (capitalizzare ciò che si è appreso), il loop engineering, e la nota [[willison-fable-judgement-delegation-subagents-2026-07-03]] (stesso autore citato, Thariq, stesso momento su Fable) — due sfaccettature complementari: Willison su lasciar giudicare Fable, Thariq su ridurre i propri unknowns per guidarlo meglio.