Come usare Claude Fable per ridurre gli errori nel coding AI

C’è una vecchia formula del linguista Alfred Korzybski, «la mappa non è il territorio», che torna utile per capire cosa succede quando si affida un lavoro di sviluppo a un agente come Claude Fable, un modello della famiglia Mythos, il livello più capace di Anthropic. La mappa è quello che gli diamo: il prompt, le istruzioni, il contesto, le skill. Il territorio è dove il lavoro accade davvero, il codice reale con i suoi vincoli, le sue trappole, le sue dipendenze impreviste. Lo scarto tra le due cose ha un nome preciso nella field guide che Anthropic ha pubblicato sul blog di Claude: sono le incognite, ed è lì che si gioca la qualità del risultato.

L’autore, Thariq Shihipar, che lavora nel technical staff dell’azienda, lo dice senza giri di parole: Fable è il primo modello in cui, scrive, la qualità del lavoro è limitata dalla sua capacità di chiarire le incognite. Un’affermazione che sposta il baricentro. Per anni il collo di bottiglia dell’AI generativa è stato la macchina, quanto sapeva, quanto capiva, quanto contesto reggeva. Con un modello abbastanza capace il vincolo cambia natura, e finisce addosso a chi il prompt lo scrive.

Il cambio di prospettiva conta soprattutto dove gli agenti stanno entrando nei processi reali. La domanda smette di essere «lo strumento è capace» e diventa «sappiamo cosa vogliamo, e sappiamo nominare quello che ancora non abbiamo capito», una questione di maturità organizzativa prima ancora che di tecnologia.

Quattro tipi di incognite dentro un prompt

Shihipar recupera la vecchia griglia di Donald Rumsfeld, quella dei «known knowns» e degli «unknown unknowns», e la porta dentro il lavoro con l’agente. Nel primo quadrante ci sono le cose che sappiamo e mettiamo nel prompt, quello che diciamo esplicitamente all’agente di volere. Accanto stanno i «known unknowns», le domande che sappiamo di doverci porre, questioni ancora aperte di cui però siamo consapevoli.

Poi arriva la parte scivolosa. Gli «unknown knowns» sono le cose troppo ovvie per scriverle, quelle che riconosceremmo all’istante vedendole ma che non penseremmo mai di specificare. E il quadrante nero, gli «unknown unknowns», è quello che non abbiamo nemmeno considerato: la buca che non sapevamo la strada potesse avere.

I primi due quadranti li governiamo già scrivendo meglio. Sono gli altri due, il non-detto e il non-pensato, a separare un risultato mediocre da uno buono, e sono anche i più difficili da presidiare da soli. Shihipar nota che i migliori nel coding agentico hanno poche incognite, perché conoscono a fondo sia il codice sia i comportamenti del modello; eppure anche loro danno per scontato di averne, e proprio ridurre e mettere in conto le proprie incognite resta la vera competenza da allenare, una competenza che si affina lavorando con Claude.

Troppo precisi o troppo vaghi

Istruire un agente è un equilibrio delicato, ricorda l’autore. Con un prompt troppo dettagliato Claude esegue alla lettera anche quando cambiare strada sarebbe la scelta migliore. Se invece è troppo vago, riempie i vuoti con scelte da manuale, sensate in astratto ma non sempre adatte al caso concreto. Quando non si tiene conto delle proprie incognite, avverte Shihipar, si sbaglia in tutte e due le direzioni. La via d’uscita non passa dallo scrivere di più, passa dal dare all’agente il contesto del punto di partenza: da dove veniamo, cosa abbiamo già provato, quali vincoli non sono negoziabili.

Ecco perché conviene rovesciare il rapporto e usare il modello per far emergere il non-detto, non solo per produrre. Claude cerca nel codice e in rete molto più in fretta di noi, sa più cose sulla media degli argomenti, impara dagli errori in tempi che una persona non regge. Un iceberg rende l’immagine: prima di iniziare, gran parte di quello che serve sapere sta sotto la linea di galleggiamento, sommersa e piena di punti interrogativi. Il lavoro di scoperta la porta a galla, un pezzo alla volta.

Shihipar traduce tutto questo in pratiche concrete, ognuna pensata per ridurre lo scarto tra la mappa e il territorio, distribuite lungo le tre fasi del lavoro: prima, durante e dopo l’implementazione. Vale la pena guardarle da vicino, perché sono trasferibili ben oltre il codice

Prima del codice: il blind spot pass e le altre sonde

Il primo gruppo di pratiche serve a scovare quello che non vediamo. Il «blind spot pass» è la mossa più diretta: si chiede a Claude di rileggere il piano o il codice e di dire cosa manca, dove annidano i rischi, quali buche evitare, spiegando all’agente chi siamo e cosa già sappiamo, così da illuminare gli unknown unknowns con uno sguardo esterno. L’esempio che porta è concreto: chi deve aggiungere un provider di autenticazione in una parte di codice che non conosce chiede a Claude un blind spot pass proprio per far emergere le incognite nascoste e imparare a formulare meglio le domande.

I brainstorm e i prototipi lavorano invece sugli unknown knowns, quei criteri che sappiamo definire solo quando li vediamo: far generare a Claude quattro direzioni di design molto diverse per una dashboard, oppure un mockup della toolbar con dati finti, costa poco e permette di reagire prima di scrivere una riga di backend.

Poi c’è il ribaltamento dei ruoli, l’intervista: si lascia che sia l’agente a farci domande, una alla volta, con priorità a quelle la cui risposta cambierebbe l’architettura. Le reference contano quanto le istruzioni, e il riferimento migliore resta il codice sorgente: mostrare all’agente come è fatta davvero una libreria, anche in un altro linguaggio, vale più di uno screenshot o di mille righe di specifiche. Chiude la fase il piano di implementazione, scritto prima di toccare il codice e costruito attorno alle parti più a rischio di cambiare, i modelli dati, le interfacce, i flussi utente, quelle su cui conviene decidere subito.

Il quiz da superare prima del merge

Mentre l’agente lavora, un file di appunti tiene insieme il percorso. In un «implementation-notes.md» Claude annota le deviazioni dal piano e le decisioni prese strada facendo, perché per quanto si pianifichi ci sono sempre unknown unknowns in agguato, e un caso limite trovato nel codice può imporre un’altra rotta. Le scelte così non evaporano, restano leggibili al tentativo successivo.

Finito il lavoro, il modello serve a due cose che di solito si trascurano. La prima è far scrivere all’agente il pitch o l’explainer di quello che ha fatto, per accelerare la comprensione e l’approvazione di chi deve dare l’ok, soprattutto quando quei revisori partono dalle stesse incognite da cui siamo partiti noi; un unico documento con prototipo, specifiche e note, pronto da lasciare in un canale Slack, accorcia di molto la strada verso il via libera.

La seconda è il controllo, e qui Shihipar propone un’idea che vale la pena rubare: il quiz. Si chiede a Claude di interrogarci sul codice che ha prodotto, e si procede al merge solo dopo aver risposto bene a tutto. Ribalta l’abitudine, perché non è l’umano a validare la macchina, è la macchina a verificare che chi la usa abbia capito cosa sta per mandare in produzione.

Il video di lancio di Fable, montato in Claude Code

Che non sia teoria lo mostra il modo in cui è nato il video di lancio di Fable, montato dall’inizio alla fine dentro Claude Code, in un campo, il video editing, che per Shihipar era terreno nuovo. È partito da quello che sapeva: Claude poteva tagliare e trascrivere video via codice, ma restava il dubbio sull’accuratezza.

Ha chiesto all’agente di spiegargli come funziona una trascrizione tipo Whisper e se davvero si potessero togliere esitazioni e pause lunghe con ffmpeg. Voleva un’interfaccia sincronizzata con le parole pronunciate, e non sapendo se fosse possibile ha fatto costruire a Claude un prototipo con Remotion. Alla fine il video appariva un po’ spento, questione di color grading, che però lui non sapeva cosa fosse: invece di far scegliere tra varianti alla cieca, ha chiesto a Claude di spiegarglielo, per scoprire le proprie incognite. Ogni sonda lungo il percorso, dall’explainer al prototipo all’intervista, è stata un modo economico per scoprire prima quello che sarebbe costato caro dopo.

Con la macchina ormai così avanti, il valore non lo estrae chi ha lo strumento più potente, lo estrae chi sa interrogarsi, chi sa dire cosa vuole e ha l’onestà di ammettere cosa ancora non sa. Il dubbio, di solito trattato come una debolezza da nascondere, diventa qui una risorsa operativa, e ogni punto cieco portato alla luce prima è un costo evitato dopo. È un ribaltamento che tocca il modo di organizzare il lavoro, perché sposta l’attenzione dagli strumenti da comprare alle abitudini da costruire, e mette al centro persone capaci di fare le domande giuste più che di avere già tutte le risposte.

E allora la domanda che resta, a valle di una field guide come questa, non riguarda più quanto siano diventati bravi i modelli, ma quanto siamo disposti a diventare bravi noi nel nominare le nostre incognite, adesso che la mappa può finalmente avvicinarsi al territorio.