Lavorare bene con Claude¶

Il vibe coding non è solo chiedere e ricevere, è una collaborazione che funziona meglio quando si conoscono le regole del gioco. Questo capitolo raccoglie le pratiche operative che fanno la differenza tra un'esperienza frustrante e un flusso di lavoro produttivo.

Gestire gli errori¶

Gli errori non sono incidenti di percorso, sono il percorso. Ogni progetto descritto nei capitoli precedenti ha attraversato decine di errori prima di funzionare. La differenza tra un principiante bloccato e un principiante produttivo sta nel modo in cui affronta questi errori.

La strategia più semplice è anche la più efficace. Quando qualcosa non funziona, basta copiare il messaggio di errore e incollarlo nella conversazione con Claude, senza cercare di interpretarlo. Claude è progettato per leggere messaggi di errore e nella maggior parte dei casi sa cosa fare. Non serve capire cosa significa "TypeError: Cannot read properties of undefined", basta incollarlo.

Quando l'errore da solo non basta, conviene aggiungere il contesto di ciò che si stava facendo. "Ho cliccato il pulsante Converti e appare questo errore" è molto più utile di "non funziona". La combinazione di errore tecnico e descrizione in linguaggio naturale è spesso tutto ciò che serve per individuare il problema.

Il momento più insidioso arriva quando Claude propone una correzione, la correzione non risolve il problema, e Claude propone la stessa correzione riformulata in modo diverso. Questo è un loop, e riconoscerlo è una competenza che vale la pena sviluppare. I segnali sono riconoscibili: la stessa porzione di codice viene modificata per la terza volta, l'errore cambia forma ma non scompare, le spiegazioni di Claude diventano più lunghe ma meno concrete.

Uscire da un loop richiede un cambio di strategia, non più tentativi nella stessa direzione. Alcune possibilità concrete:

• Riformulare il problema. Invece di continuare a descrivere l'errore, descrivere il risultato atteso. "Quando clicco Converti dovrebbe apparire il file markdown nella colonna di destra" sposta l'attenzione dalla diagnosi all'obiettivo.
• Chiedere un approccio diverso. "Questa strada non funziona, quale alternativa esiste?" autorizza Claude ad abbandonare la soluzione corrente senza doverla difendere.
• Fare un passo indietro. A volte il problema è a monte, un'installazione incompleta, una dipendenza mancante, un file nella posizione sbagliata. Chiedere di verificare i prerequisiti anziché insistere sulla correzione può sbloccare situazioni che sembravano irrisolvibili.
• Aprire una nuova conversazione. Se la sessione è lunga e il contesto si è accumulato, può essere più efficace iniziare da capo con una descrizione pulita del problema. Claude non porta con sé i pregiudizi della conversazione precedente.

Mantenere il contesto¶

Claude ragiona all'interno di una finestra di contesto, lo spazio che contiene la conversazione dall'inizio fino all'ultimo messaggio. Tutto ciò che sta dentro la finestra è visibile, tutto ciò che ne esce è perduto. La finestra è ampia ma non è infinita. In una sessione di lavoro intensa, con scambi di codice, screenshot e correzioni ripetute, la si può saturare.

Quando la finestra si avvicina al limite il comportamento di Claude cambia in modo sottile. Le risposte diventano meno precise, i dettagli concordati all'inizio della sessione vengono dimenticati, errori già risolti ricompaiono. Non è un malfunzionamento, è un limite fisico dell'architettura.

La strategia più efficace è prevenire il problema con sessioni brevi e focalizzate. Invece di una conversazione-maratona in cui si progetta, costruisce, testa e corregge tutto nello stesso flusso, conviene separare le attività. Una sessione per impostare la struttura del progetto, un'altra per costruire la prima funzionalità, un'altra ancora per risolvere quel bug persistente. Ogni sessione parte con un contesto pulito e un obiettivo preciso.

I Progetti in Chat offrono un livello di continuità che le singole conversazioni non hanno. Un Progetto raccoglie istruzioni persistenti e file di riferimento che restano disponibili in ogni nuova conversazione aperta al suo interno. Le istruzioni di progetto non consumano la finestra di contesto allo stesso modo dei messaggi della conversazione, ma forniscono a Claude il quadro d'insieme ogni volta che si riparte. Per un progetto di vibe coding di qualsiasi durata, lavorare all'interno di un Progetto è una scelta quasi obbligata.

Il file CLAUDE.md, già descritto nel capitolo 4, svolge un ruolo complementare. Le istruzioni di progetto in Chat definiscono il contesto generale, mentre CLAUDE.md (usato in Cowork e Code) registra le decisioni tecniche accumulate durante la costruzione. Convenzioni adottate, errori da non ripetere, scelte architetturali: tutto ciò che Claude dovrebbe sapere quando apre una nuova sessione sulla stessa base di codice. Senza questo tipo di memoria esterna ogni nuova sessione riparte da zero, con il rischio di reintrodurre problemi già risolti.

Ottenere risposte migliori¶

Non tutte le richieste hanno bisogno della stessa profondità di ragionamento. Chiedere a Claude di rinominare una variabile è diverso dal chiedergli di progettare l'architettura di un'applicazione. Claude Desktop offre due strumenti per calibrare la qualità delle risposte, entrambi accessibili direttamente dall'interfaccia di Chat.

Il primo è il ragionamento esteso. Si attiva dal selettore del modello in basso a destra, dove accanto al nome del modello compare un toggle "Ragionamento esteso" con la descrizione "Ragiona più a lungo per attività complesse". Quando è attivo, l'indicazione "Estesa" appare accanto al nome del modello. In questa modalità Claude dedica più tempo all'analisi prima di rispondere, il che produce risultati migliori su problemi articolati, quelli dove servono più passaggi di ragionamento o dove la soluzione non è immediata. Per richieste semplici il ragionamento esteso non aggiunge valore e consuma più risorse dell'abbonamento.

Il secondo strumento sono gli stili di risposta. Si trovano nel menu "+" a sinistra del campo di input, alla voce "Usa stile". Gli stili predefiniti includono Normale, Apprendimento, Conciso, Esplicativo e Formale, ed è possibile crearne di personalizzati con "Crea e modifica stili". Lo stile non cambia ciò che Claude sa, cambia come lo comunica. "Esplicativo" produce risposte più dettagliate e didattiche, "Conciso" va dritto al punto, "Formale" adotta un registro più strutturato. Nel vibe coding lo stile Esplicativo è utile quando si vuole capire perché Claude ha scelto una certa soluzione, non solo ricevere il codice.

La combinazione dei due strumenti è più efficace di ciascuno separatamente. Il ragionamento esteso con stile Esplicativo è la configurazione adatta quando si affronta un problema che non si riesce a risolvere e si vuole che Claude mostri il proprio ragionamento nel dettaglio. Per il lavoro di routine conviene tornare alla configurazione standard, sia per la velocità sia per il consumo di risorse.

Al di là degli strumenti dell'interfaccia, il fattore che incide di più sulla qualità delle risposte è il modo in cui si formula la richiesta. Il principio è la specificità: "il pulsante non funziona" produce risultati peggiori di "il pulsante Converti nella barra superiore non reagisce al clic, il cursore cambia forma ma non succede nulla". Uno screenshot dell'errore, il nome del file, il comportamento atteso e quello effettivo sono informazioni che permettono a Claude di lavorare sulla situazione reale anziché indovinare.

Quando Claude non fa quello che dice d'avere fatto¶

Questo è probabilmente l'aspetto più insidioso per chi non ha esperienza di programmazione. Claude può generare codice che sembra corretto, usa la sintassi giusta, ha una struttura ragionevole, ma non fa ciò che dovrebbe. Peggio ancora, Claude può affermare che un problema è risolto quando non lo è.

Il fenomeno si manifesta soprattutto dopo ripetuti tentativi falliti. Quando Claude ha provato tre o quattro soluzioni per lo stesso errore senza successo, le risposte successive tendono a diventare meno affidabili. Il codice generato può aggirare il problema anziché risolverlo, ad esempio sopprimendo un messaggio di errore senza eliminarne la causa, oppure restituendo un valore fisso dove dovrebbe esserci un calcolo. In questi casi Claude presenta la modifica con sicurezza, e senza test manuali la si potrebbe accettare come valida.

I segnali di allarme sono pochi ma riconoscibili. Risposte che dichiarano "ora funziona" senza spiegare cosa è cambiato meritano attenzione. Codice che diventa progressivamente più lungo e contorto a ogni iterazione suggerisce che Claude sta accumulando correzioni su correzioni senza una visione chiara del problema. Spiegazioni che diventano vaghe dove prima erano precise indicano che il modello si sta allontanando dal territorio in cui ha dati solidi.

La difesa più efficace è il test manuale sistematico. Ogni volta che Claude dichiara di aver risolto un problema, verificare che il comportamento sia effettivamente cambiato. Non basta che il codice non produca errori, deve produrre il risultato atteso. Questa verifica non richiede competenze tecniche, richiede solo la disciplina di provare ogni modifica prima di procedere alla successiva.

Quando il dubbio è forte, una strategia utile è chiedere a Claude di spiegare passo per passo cosa fa il codice che ha appena scritto. Se la spiegazione non corrisponde a ciò che si osserva, il problema è confermato. A quel punto conviene applicare le strategie descritte nella sezione sugli errori: riformulare il problema, cambiare approccio, o aprire una nuova conversazione.

Salvare il lavoro¶

Costruire un'applicazione funzionante e perderla per un errore è un'esperienza che capita una volta sola, perché dopo la prima volta si impara a salvare. Il version control (controllo di versione) è la pratica di registrare lo stato del progetto a intervalli regolari, in modo da poter tornare a una versione precedente se qualcosa va storto. Lo strumento standard si chiama Git.

Git può sembrare intimidatorio ma l'uso di base richiede tre concetti e tre comandi. I concetti sono il repository (la cartella del progetto tracciata da Git), il commit (un'istantanea del progetto in un dato momento) e lo staging (la selezione dei file da includere nella prossima istantanea). I comandi corrispondenti sono git add per selezionare i file, git commit per registrare l'istantanea e git log per consultare la storia.

Il repository locale vive sulla propria macchina, ma la vera sicurezza si ottiene quando una copia esiste anche altrove. GitHub è la piattaforma più usata per questo scopo, un servizio gratuito che ospita repository Git accessibili da qualsiasi dispositivo. Caricare il progetto su GitHub richiede un passaggio aggiuntivo dopo il commit, il comando git push, e una configurazione iniziale che si fa una sola volta. Il capitolo 9 descrive il procedimento completo.

In Cowork e Code il rapporto con Git è diverso. Code ha Git integrato nativamente e può eseguire commit, creare branch e gestire il repository in autonomia. Cowork non ha accesso diretto a Git ma può interagire con un repository se è disponibile un server MCP con questa funzionalità. In Chat, Git non è accessibile direttamente ma è possibile chiedere a Claude di generare i comandi da eseguire nel terminale.

Il momento giusto per un commit è ogni volta che il progetto raggiunge uno stato funzionante. L'applicazione si avvia e mostra la schermata principale: commit. Il pulsante di conversione funziona: commit. Il layout è quello definitivo: commit. Ogni commit è un punto di ritorno sicuro, e averne molti è sempre meglio che averne pochi. Il messaggio del commit descrive cosa è cambiato in modo leggibile: "aggiunta conversione PDF in markdown" è utile, "aggiornamento" non lo è.

Per chi preferisce non usare Git, l'alternativa minima è copiare l'intera cartella del progetto prima di ogni sessione di lavoro significativa. Una cartella "progetto-backup-10-aprile" è meno elegante di un commit Git ma svolge la stessa funzione di rete di sicurezza. L'importante è avere un modo per tornare indietro.