Le righe importanti le scrivi tu

Cos'è e perché conta

Se fai l'app con Claude e non capisci il codice, il giorno che si rompe sei bloccato. Non sai dove guardare, e chiedi di sistemare una cosa che non sai neanche descrivere. Più l'app cresce, più pesa.

Claude Code ha già una risposta dentro: gli stili di output. Uno stile è un insieme di istruzioni che cambia come Claude ti risponde per tutta la sessione. Oltre a quello di base, che si chiama Default, ne ha quattro già inclusi: Proactive, Concise, Explanatory e Learning. Learning è quello pensato per imparare.

Con Learning il lavoro di routine lo fa ancora lui. Ma quando arriva a un pezzo con una scelta vera, ti lascia scrivere qualche riga e intanto ti spiega le sue scelte. L'app la finisci lo stesso, ma alcune righe chiave le hai scritte tu. È per chi costruisce da solo con Claude e vuole capire il proprio codice abbastanza da ripararlo.

1. Come si accende

C'è una strada per ogni posto dove usi Claude Code. Il comando e i due menu salvano la scelta nel file .claude/settings.local.json del progetto: vale solo in quel progetto, e solo per te.

1. Nel terminale: scrivi /output-style learning. Il comando non guarda maiuscole e minuscole. Se scrivi solo /output-style, ti mostra gli stili e segna quello attivo.
2. Sempre nel terminale, con il menu: scrivi /config e scegli Output style.
3. Nell'estensione di VS Code: scrivi / nella casella dei messaggi e scegli Output styles.
4. Nell'app desktop: qui /config apre le impostazioni dell'app, non il menu. Scrivi tu il campo outputStyle nel file .claude/settings.local.json del progetto, come qui sotto, poi apri una sessione nuova.

{
  "outputStyle": "Learning"
}

Nel file conta la maiuscola: va scritto Learning, non learning. Un nome scritto male non dà errore: ti lascia nello stile Default, senza avvisarti. Se il file ha già altre impostazioni, aggiungi solo la riga outputStyle dentro le graffe che ci sono.

Se vuoi Learning in tutti i progetti, metti lo stesso campo nel file del tuo utente, ~/.claude/settings.json. Ma le impostazioni di un progetto vincono su quelle dell'utente: se un progetto ha il suo outputStyle, lì vale quello.

Se cambi stile a metà sessione, nell'ultima versione di Claude Code il nuovo stile vale dal tuo messaggio successivo: non serve ricominciare.

2. Cosa succede mentre lavora

Gli dai un compito come al solito. Da lì va così:

1. Il lavoro di routine lo fa lui: i file da creare, i collegamenti, le parti che si scrivono in un modo solo.
2. Quando arriva a un pezzo con una scelta vera, si ferma. La documentazione fa tre esempi: come gestire un errore, come organizzare i dati, una regola della tua app che si può scrivere in più modi giusti.
3. Nel file, nel punto esatto, lascia un commento segnaposto: la parola inglese per «da fare» seguita da (human), cioè «persona». Per trovarlo, cerca (human) nel file.
4. Ti manda una richiesta Learn by Doing in tre parti: Context, cosa c'è già; Your Task, cosa devi scrivere e dove; Guidance, a cosa pensare mentre scrivi.
5. Poi si ferma e aspetta. Tu scrivi quelle poche righe al posto del segnaposto e gli dici che hai finito.
6. Lui legge il tuo codice, risponde con un riquadro Insight su quello che hai scritto e riprende il lavoro.

Intanto, prima o dopo il codice che scrive, aggiunge dei riquadri Insight: due o tre punti sul perché delle sue scelte, legati al tuo progetto. Stanno nella conversazione: non finiscono nei tuoi file come commenti.

Una cosa da sapere subito: uno stile è un'istruzione, non una garanzia. Claude decide lui quali pezzi lasciarti, e in un compito senza scelte vere può non lasciarti niente. Se vuoi un pezzo preciso, chiediglielo: è la sezione dopo.

3. Usalo su una funzione vera

Rende di più su una funzione che ti serve davvero che su un esercizio. Le righe da tenere per te sono le regole della tua app: sono quelle che cambierai quando cambia l'idea, e quelle che guarderai per prime quando qualcosa non torna. Scrivigli così:

Sto aggiungendo [la funzione, per esempio: massimo 3 progetti per chi usa la versione gratis]. Scrivi tu la parte di routine: file, collegamenti, interfaccia. Le regole della mia app, cioè cosa succede in ogni caso e come gestire gli errori, lasciale a me con il segnaposto (human), una alla volta. Per ognuna dimmi in che file è, cosa ricevo e cosa devo restituire.

Quando hai scritto le tue righe:

Ho finito il segnaposto (human) in [nome del file]. Leggi il mio codice e dimmi se c'è un caso che non gestisco, senza riscriverlo tu. Poi vai avanti.

4. Quando sei bloccato, chiedi un indizio

Capita di guardare il segnaposto e non sapere da dove partire. Non chiedergli subito la soluzione: se la leggi già fatta, la prossima volta sei di nuovo lì. Chiedigli un indizio:

Sono bloccato sul segnaposto (human) in [nome del file]. Non scrivere il codice. Dammi un indizio solo: la prima cosa da controllare o la domanda che mi devo fare. Se dopo due indizi sono ancora fermo, mostrami un esempio simile, ma non uguale.

Se proprio non è il momento, puoi sempre dirgli di scrivere lui quel pezzo. Ma prima prova con gli indizi: è lì che il codice diventa tuo.

5. Quando hai fretta, torna a Default

Learning rallenta, ed è giusto così. Le risposte sono più lunghe di Default per come è fatto lo stile, quindi consumi più token in uscita. Quando devi solo chiudere una cosa, torna allo stile base:

/output-style default

Default sta nella lista con gli altri stili, quindi lo trovi anche in /config e nel menu di VS Code. Nell'app desktop togli la riga outputStyle dal file. Quando hai di nuovo tempo, rimetti Learning.

6. Se vuoi solo le spiegazioni: Explanatory

Se di scrivere codice non hai voglia ma vuoi capire cosa succede, c'è Explanatory. Fa il lavoro come Default e aggiunge gli stessi riquadri Insight, con il perché delle sue scelte. Non ti lascia niente da scrivere e non si ferma ad aspettarti.

Si accende allo stesso modo: /output-style explanatory nel terminale, oppure Explanatory nel file, con la E maiuscola. Anche qui le risposte sono più lunghe di Default, quindi più token. Explanatory va bene quando entri in un pezzo di codice che non conosci; Learning quando scrivi una funzione che dovrai mantenere tu.

Gli errori più comuni

• Scrivere learning minuscolo nel file. Nel file va Learning: con un nome sbagliato resti in Default e nessuno te lo dice.
• Aspettarsi un segnaposto (human) a ogni risposta. Claude decide quali pezzi lasciarti: se ne vuoi uno, chiediglielo.
• Lasciarlo acceso quando hai fretta. Le risposte lunghe consumano più token: torna a Default e riaccendilo dopo.
• Mettere Learning in ~/.claude/settings.json e non capire perché in un progetto non parte. Le impostazioni del progetto vincono: guarda se lì c'è un altro outputStyle.
• Creare a mano .claude/settings.local.json e finire per metterlo su git. Quando lo crea Claude Code, lo tiene fuori da git da solo; se lo crei tu, aggiungilo al .gitignore.

Checklist

• Learning è acceso nel progetto dove sto lavorando
• Se l'ho messo nel file, c'è scritto Learning con la L maiuscola
• Gli ho chiesto di lasciarmi le regole della mia app con il segnaposto (human)
• Ho scritto le mie righe e gli ho detto che ho finito
• Ho letto l'Insight sul mio codice
• So come tornare a Default quando ho fretta

Domande frequenti