Tutorial della serie Claude Code 4: Quali sono i casi d'uso di Claude Code?

Casi d'uso tipici

Classifico i casi d'uso in quattro categorie, in ordine decrescente di frequenza.

Prima categoria: Comprendere il codice

Questa è probabilmente la categoria più utilizzata. Quando si eredita un progetto, si guarda un modulo vecchio, o si apre un repository senza documentazione, si chiede direttamente.

Come fare:

claude "Di cosa si occupa questo progetto? Dov'è l'entry point?" — Leggerà package.json, la struttura delle directory, i file chiave e fornirà una sintesi.
Aprire una funzione e chiedergli di spiegare la logica, disegnare il flusso (con descrizione testuale).
Fargli tracciare il percorso completo di una richiesta API dal frontend al database.

Qui, ciò che fa è essenzialmente aiutarci a fare il "lavoro sporco della lettura del codice". Non devi passare ore a fare grep e ricomporre mentalmente il puzzle. Lui traccia il percorso, tu fai le valutazioni.

L'alternativa per questa categoria è: cercare manualmente nel codice, prendere appunti, disegnare diagrammi di chiamata.

Seconda categoria: Scrivere e modificare codice

Questa è la categoria più discussa, ma in realtà non è la più utilizzata. Lo scenario di scrittura del codice è solitamente questo:

Generare nuove funzionalità: "Aggiungi un'interfaccia per modificare l'email sotto il modulo user, con validazione del formato email e scrivi test unitari."
Refactoring tra file: "Sostituisci tutte le occorrenze di moment() con dayjs() in questi tre file, senza alterare altra logica."
Migrazione e upgrade: "Converti questo componente Vue 2 nella sintassi Vue 3 Composition API."

Il codice generato potrebbe non essere perfetto al primo tentativo, ma può applicare modifiche su più file in una volta, e puoi fare diff file per file, accettando o rifiutando singolarmente.

L'alternativa per questa categoria è: scrivere manualmente codice ripetitivo, cercare e sostituire riferimenti tra file manualmente.

Terza categoria: Debug e correzione

Quando si presenta un bug, il flusso di lavoro tipico è: guardare l'errore, localizzare il file, indovinare la causa, provare a modificare, se non funziona tornare indietro. Claude Code può ricevere direttamente l'intero stack di errori e, combinato con il codice del progetto, localizzare il problema.

Uso tipico:

Passargli l'output di un test fallito, leggerà il codice correlato, proporrà una modifica, e dopo la modifica eseguirà di nuovo il test per vedere se passa.
In caso di errore CI, incollare il log, fargli correggere, poi eseguire git diff per confermare le modifiche.

Qui il suo ruolo è più simile a un "primo ispettore". Il tempo per pensare lo spendi tu, ma a scorrere i file, confrontare le differenze ed eseguire comandi di verifica ci pensa lui.

L'alternativa per questa categoria è: eseguire ripetutamente i test, leggere i log degli errori, confrontare manualmente le differenze di codice.

Quarta categoria: Automazione varia

Questa categoria è la meno appariscente, ma sommando i tempi risparmiati è la più significativa.

Esempi:

Scrivere messaggi di commit Git: claude "Scrivi un messaggio di commit in formato Conventional Commits basato sul git diff corrente"
Generare descrizioni delle PR: Fargli confrontare le differenze tra il branch corrente e main, generare un riepilogo delle modifiche e le note di test.
Scrivere note di rilascio: Fargli leggere la cronologia dei commit dell'ultima settimana e generare un CHANGELOG.
Risolvere problemi di ambiente: "L'installazione di questa dipendenza ha dato errore, guarda l'output del terminale e trova la causa."

Queste attività hanno in comune: non sono complesse, ma sono noiose. Farle da soli richiede cambiare finestra e scrivere molto. Affidandole a lui, in pochi secondi sono fatte.

L'alternativa per questa categoria è: modificare manualmente il testo, scrivere documentazione formale, cercare soluzioni a problemi di configurazione.

Una "mappa"

Inserendo queste quattro categorie nel flusso di lavoro quotidiano, la mappa è più o meno questa:

Ottenere un progetto sconosciuto
    │
    ▼
[Comprendere il codice] ─── Capire struttura, entry point e logica chiave
    │
    ▼
Iniziare a scrivere una nuova funzionalità o modificare un modulo
    │
    ▼
[Scrivere/modificare codice] ─── Generare implementazione, refactoring tra file
    │
    ▼
Eseguire test, appare un bug
    │
    ▼
[Debug e correzione] ─── Analizzare errore, localizzare, correggere, rieseguire
    │
    ▼
Prepararsi al commit
    │
    ▼
[Automazione varia] ─── Scrivere commit, descrizione PR, note di rilascio
    │
    ▼
Commit, completato

Non è necessario usarlo in tutti e quattro i quadranti. Alcuni team lo usano solo per comprendere il codice, altri solo per scrivere test e inviare PR. Scegli lo scenario che ti causa più problemi e inizia da lì.

Due criteri utili per decidere

Se non sei sicuro se affidare o meno un'attività a Claude Code, puoi porti due domande:

1. Questa attività è più "meccanica" che "creativa"?

Modificare centinaia di riferimenti, formattare output, generare codice boilerplate — cose che prese singolarmente richiedono molto tempo, ma di cui hai già la soluzione in mente. Adatte da affidare a lui.

2. Il "costo di verifica" di questa attività è alto o basso?

Se una modifica richiede continui salti, esecuzione di test e lettura di log per essere confermata, la persona che fa tentativi va lentamente. Claude Code può completare il ciclo "modifica-esegui-verifica-modifica" autonomamente, e tu sarai molto più sollevato.