Lavorare con Claude Fable 5 continua a insegnarmi una vecchia lezione: la mappa non è il territorio.
La mappa, una rappresentazione del lavoro da fare, sono i miei prompt, le mie competenze e il contesto, è ciò che do a Claude. Il territorio è dove il lavoro deve avvenire, il codebase, il mondo reale, i suoi vincoli effettivi.
La differenza tra la mappa e il territorio è ciò che chiamo incognite. Quando Claude si imbatte in un'incognita, deve prendere una decisione basata sulla sua ipotesi migliore di ciò che voglio. Più lavoro viene svolto, più incognite Claude potrebbe incontrare.
Fable è il primo modello in cui trovo che la qualità del lavoro sia limitata dalla mia capacità di chiarire le sue incognite.
È importante sottolineare che pianificare in anticipo non è sempre sufficiente. Puoi trovare incognite in profondità nell'implementazione, oppure le tue incognite potrebbero indicarti che dovresti effettivamente risolvere il problema in un modo completamente diverso.
Ho scoperto che lavorare con Fable è un processo iterativo di scoperta delle mie incognite prima, durante e dopo l'implementazione.
Ho creato alcuni artefatti di esempio per trovare le incognite qui, ma assicurati di tornare per costruire l'intuizione su quando usarli.
Conoscere le tue incognite
Quali sono le tue incognite? Quando mi rivolgo a Claude con un problema, tendo a scomporlo in 4 modi:
- Certezze note: Questo è essenzialmente ciò che c'è nel mio prompt. Cosa dico all'agente che voglio?
- Incognite note: Cosa non ho ancora capito, ma sono consapevole di non aver capito?
- Cerchezze ignote: Cosa è così ovvio che non lo scriverei mai, ma lo riconoscerei se lo vedessi?
- Incognite ignote: Cosa non ho considerato affatto? Di quale conoscenza non sono a conoscenza? So quanto possa essere buono qualcosa?
I migliori programmatori agentici hanno relativamente poche incognite. Guardare qualcuno come Boris o Jarred fare prompt è ovvio per me che sappiano esattamente cosa vogliono nei dettagli. Sono profondamente in sintonia sia con il codebase che con i comportamenti del modello.
Ma danno anche per scontate le incognite. In molti modi, ridurre e pianificare le tue incognite è l'abilità della programmazione agentica. Ma fortunatamente, questa è un'abilità che puoi migliorare, lavorando con Claude.
Aiuta Claude ad aiutarti
Istruire Claude è un equilibrio delicato. Se sei troppo specifico, Claude seguirà le tue istruzioni anche quando una svolta potrebbe essere più appropriata. Se sei troppo vago, Claude spesso prenderà decisioni e farà supposizioni basate sulle best practice del settore che potrebbero non essere adatte al tuo compito.
Quando non tieni conto delle tue incognite, fallisci in entrambi i modi. Non sai quando il percorso sarà pieno di ostacoli e non sai quando sarà libero, ma vuoi comunque che Claude devii.
Claude può aiutarti a scoprire le tue incognite più velocemente. Può cercare nel tuo codebase e su internet molto rapidamente e sa molto di più sull'argomento medio di te. Può anche iterare dal fallimento più velocemente.
La parte più importante di questo processo è dare a Claude un contesto sul tuo punto di partenza. Ad esempio, digli dove ti trovi nel tuo processo di pensiero; rivela la tua esperienza con il problema e il codebase; e lascia che lavori con te come un partner di pensiero.
Ho già scritto sull'uso di HTML con Claude, in quasi tutti questi casi, un artefatto HTML è il modo migliore per visualizzarlo e rappresentarlo.
In questo articolo descrivo alcuni dei modelli che uso per scoprire queste incognite. Non uso ogni tecnica ogni volta, ma è una raccolta utile di tecniche da avere.
Pre-implementazione
Analisi dei punti ciechi
Quando inizi un lavoro, una delle cose più utili che puoi fare è capire i tuoi punti ciechi. Ad esempio, se stai scrivendo una funzionalità in una nuova parte del codebase o stai usando Claude per aiutarti con un lavoro sconosciuto come iterare su un design, è probabile che tu abbia molte incognite ignote.
Potresti non sapere quali domande fare, come sia "buono", quale lavoro storico sia stato fatto o quali buche evitare.
Per farlo, puoi chiedere a Claude di aiutarti a trovare le tue incognite ignote e spiegartele. Mi piace usare le parole letterali "analisi dei punti ciechi" e "incognite ignote". Dargli un contesto su chi sei e cosa sai è solitamente importante.
Prompt di esempio:
- "Sto lavorando per aggiungere un nuovo provider di autenticazione ma non so nulla dei moduli di autenticazione in questo codebase. Puoi fare un'analisi dei punti ciechi per aiutarmi a capire le mie incognite ignote rilevanti e aiutarmi a fare prompt migliori?"
- "Non so cosa sia la color grading ma devo fare la color grading di questo video. Puoi insegnarmi a capire le mie incognite ignote sulla color grading, in modo che io possa fare prompt migliori?"
Brainstorming e prototipi
Quando lavoro in un'area con molte certezze ignote, che coinvolgono criteri che so definire solo quando li vedo, mi piace chiedere a Claude di fare brainstorming e prototipi con me.
È estremamente prezioso identificare e verbalizzare le certezze ignote all'inizio durante la prototipazione, perché scoprirle durante l'implementazione può essere (relativamente) costoso. Piccole modifiche in una funzionalità o specifica possono causare implementazioni drasticamente diverse nel codice e può essere più difficile per il tuo agente annullare le modifiche precedenti.
Ad esempio, potresti voler vedere come appare un pulsante aggiunto a un frame senza dover cablare una route backend o mantenere uno stato aggiuntivo nel frontend.
Il design visivo è qualcosa che per me è difficile da articolare, ma so cosa voglio quando lo vedo. In questi casi, chiedo diversi approcci di design per un artefatto.
Inizio anche quasi ogni sessione di programmazione con una fase di esplorazione o brainstorming. Questo mi aiuta a iniziare con l'intenzione di definire l'ambito del progetto. Claude spesso trova approcci di alto valore che mi sarei perso e talvolta perde la foresta per gli alberi. Il brainstorming mi impedisce di impostare un ambito troppo ristretto o troppo ampio.
Prompt di esempio:
- "Voglio una dashboard per questi dati ma non ho gusto visivo e non so cosa sia possibile. Fammi una pagina HTML con 4 direzioni di design completamente diverse in modo che io possa reagire."
- "Prima di cablare qualsiasi cosa, crea un singolo file HTML che simuli la nuova barra degli strumenti dell'editor con dati fittizi. Voglio reagire al layout prima che tu tocchi l'app reale."
- "Ecco il mio problema approssimativo: gli utenti abbandonano dopo l'onboarding. Cerca nel codebase e fai un brainstorming di 10 punti in cui potremmo intervenire, dal più economico al più ambizioso. Ti dirò quali risuonano."
Interviste
Una volta che ho fatto abbastanza brainstorming, probabilmente ho ancora incognite.
In questo caso, chiedo a Claude di intervistarmi su eventuali incognite o ambiguità. Quando chiedi a Claude di intervistarti, cerca di dargli un contesto sul tuo problema per guidare le sue domande. Ecco alcuni esempi.
Prompt di esempio:
- "Intervistami una domanda alla volta su qualsiasi cosa ambigua, dai la priorità alle domande in cui la mia risposta cambierebbe l'architettura."
Riferimenti
A volte non puoi descrivere in dettaglio ciò che vuoi. Ad esempio, potresti non avere il linguaggio o potrebbe essere così complicato che ti ci vorrebbe un bel po' di tempo.
In questo caso, la risposta migliore è un riferimento. Mentre puoi includere diagrammi, documentazione o immagini, il miglior riferimento in assoluto è il codice sorgente.
Se hai una libreria che implementa qualcosa in un certo modo o un componente di design che ti piace davvero, punta semplicemente Fable alla cartella e digli cosa cercare, anche se è in un linguaggio diverso.
Questo è anche il modo in cui funziona Claude Design. Non devi passargli un file (anche se puoi farlo anche tu). Puoi puntarlo a un modulo su un sito web che ti piace, e legge il codice sottostante, non solo lo screenshot. Questo fornisce dettagli molto più ricchi sul markup, la struttura e come il componente è effettivamente costruito.
Prompt di esempio:
- "Questa crate Rust in vendor/rate-limiter implementa esattamente il comportamento di backoff che voglio. Leggila e reimplementa la stessa semantica nel nostro client API TypeScript."
Piani di implementazione
Quando penso di essere pronto per implementare, tendo a chiedere a Claude di mettere insieme un piano di implementazione da rivedere che si concentri sulle parti che potrebbero essere più soggette a modifiche, ad esempio per rivedere modelli di dati, interfacce di tipo o flussi UX. Questo permette a Claude di far emergere cose che potrei effettivamente dover modificare.
Prompt di esempio:
- "Scrivi un piano di implementazione in HTML, ma inizia con le decisioni che è più probabile che modifichi: modifiche al modello dati, nuove interfacce di tipo e tutto ciò che è rivolto all'utente. Seppellisci il refactoring meccanico in fondo, mi fido di te su quella parte."
Durante l'implementazione
Note di implementazione
Una volta che sono soddisfatto del mio piano, apro una nuova sessione e passo eventuali artefatti al prompt. Ad esempio, potrei passare un file di specifica e un prototipo e chiedere a un agente di implementarlo.
Ma la verità è che non importa quanta pianificazione fai, ci sono sempre incognite ignote in agguato. L'agente potrebbe scoprire durante il suo lavoro che deve prendere una strada diversa a causa di un caso limite trovato nel codice.
Chiedo a Claude Code di mantenere un file temporaneo 'implementation-notes.md' (o .html) in cui tiene traccia delle decisioni che prende in modo che possiamo imparare per il nostro prossimo tentativo.
Prompt di esempio:
- "Mantieni un file implementation-notes.md. Se incontri un caso limite che ti costringe a deviare dal piano, scegli l'opzione conservativa, registrala sotto 'Deviazioni' e continua."
Post-implementazione
Presentazioni e spiegazioni
Una delle parti più importanti del rilasciare qualcosa è ottenere consenso e approvazioni. Creare artefatti di presentazione e spiegazione nel documento finale aiuta a:
- Accelerare la comprensione quando i revisori iniziano con le stesse incognite che avevi tu
- Accelerare le approvazioni quando gli esperti vogliono vedere che hai tenuto conto delle incognite e dei punti di fallimento comuni che avrebbero anticipato
Prompt di esempio:
- "Impacchetta il prototipo, la specifica e le note di implementazione in un unico documento che posso lasciare cadere in Slack per ottenere consenso. Inizia con la GIF demo."
Quiz
Dopo una lunga sessione di lavoro, Claude potrebbe aver realizzato molto più di quanto pensassi. Leggere i diff del codice può darmi solo una comprensione superficiale di ciò che è successo, poiché gran parte del comportamento dipenderà dai percorsi di codice esistenti.
Chiedere a Claude di farmi un quiz sulla modifica dopo avermi dato un sacco di contesto mi aiuta a capire cosa succede. Faccio il merge solo dopo aver superato perfettamente il quiz.
Prompt di esempio:
- "Voglio assicurarmi di capire tutto ciò che è successo in questa modifica. Fammi un report HTML sulle modifiche da leggere e capire con contesto, intuizione, cosa è stato fatto, ecc. e un quiz in fondo sulle modifiche che devo superare."
Come tutto questo si unisce: lanciare Fable
Il video di lancio per Fable è stato montato interamente da Claude Code. Questo era un nuovo dominio per me e non sono affatto un esperto.
Quindi ho iniziato con ciò che sapevo. Sapevo che Claude poteva usare il codice per montare video e trascriverli, ma non ero sicuro che fosse abbastanza accurato. Ho poi chiesto a Claude di spiegarmi come funzionava la trascrizione come Whisper, e se sarei stato in grado di tagliare accuratamente cose come "uhm" o lunghe pause usando ffmpeg.
Volevo che Claude creasse un'interfaccia utente che fosse sincronizzata con le parole che stavo dicendo, ma non ero sicuro che ci sarebbe riuscito, quindi ho chiesto a Claude di creare un video prototipo usando Remotion e una trascrizione per vedere se avrebbe funzionato.
Infine, il video stesso sembrava un po' spento, cosa che sapevo fosse il risultato della color grading ma non sapevo davvero cosa fosse la color grading. Il mio primo tentativo è stato cercare di far fare a Claude alcune variazioni da scegliere, ma ho capito che non sapevo come fosse "buono" quando si trattava di color grading. Quindi, invece, ho chiesto a Claude di insegnarmi la color grading per scoprire le mie incognite.
Puoi guardare una spiegazione più approfondita su questo qui.
Abbinare la Mappa e il Territorio
Migliori diventano i modelli, più puoi ottenere con l'approccio giusto. Quando un compito a lungo orizzonte torna sbagliato, è probabile che tu debba dedicare più tempo a definire le tue incognite o a creare un piano di implementazione che permetta a Claude di improvvisare attraverso di esse.
Ogni spiegazione, brainstorming, intervista, prototipo e riferimento è un modo economico per scoprire ciò che non sapevi prima che diventi costoso da riparare.
Quindi inizia il tuo prossimo progetto chiedendo a Claude di aiutarti a trovare le tue incognite.
