Claude Code: come iniziare con un progetto vero
Pubblicazione originale: · Sergey Zhadov
Questo è un articolo d’archivio tradotto. Data e prezzi si riferiscono alla pubblicazione originale, non a un nuovo annuncio di oggi.
Claude Code lavora nella cartella del progetto. Può leggere la struttura, seguire i collegamenti tra file, modificare codice ed eseguire comandi. Una prima sessione sensata parte dall'esplorazione, passa per un piano piccolo e finisce con diff e test. Chiedergli di migliorare tutto è un ottimo modo per creare casino.
Installare senza magie inutili
Anthropic consiglia oggi l'installazione nativa. Per Windows documenta PowerShell, CMD e WinGet; macOS e Linux hanno procedure dedicate. npm resta disponibile, ma non è più l'unica risposta e i requisiti di Node.js possono cambiare.
Verifica con claude --version. Se qualcosa non torna, claude doctor esegue una diagnosi in sola lettura. Servono internet e un account idoneo. Il piano gratuito Claude.ai non garantisce l'accesso a Claude Code.
Avviare dalla radice del repository
Apri il terminale nella cartella del progetto ed esegui claude. Prima controlla git status e proteggi le modifiche importanti non ancora registrate. Questa noia diventa utile quando un edit va storto.
La prima richiesta deve essere esplorativa: spiegare lo scopo, trovare entry point, moduli principali e comandi di test e build, senza modificare nulla. Così capisci se l'agente ha afferrato il progetto o sta già sparando cavolate con sicurezza.
Assegnare un compito verificabile
Non scrivere migliora l'app. Descrivi sintomo, risultato atteso, limiti e verifica. Esempio: il modulo invia due ordini dopo un doppio clic; trova la causa, proponi la modifica minima, mantieni invariata l'API e mostra prima un piano.
Un compito decente ha un traguardo: test verdi, tipi validi, file estranei intatti e bug non più riproducibile. Senza criteri, l'agente può scrivere montagne di codice e concludere poco.
Controllare il piano prima della patch
Chiedi causa probabile, file coinvolti e verifiche. Se un difetto minuscolo richiede di rifare mezzo progetto, ferma il circo e restringi l'ambito.
Consenti piccoli blocchi di modifica e leggi ogni diff. Configurazione, migrazioni, dipendenze, accesso e pagamenti richiedono più attenzione. Un tono deciso non rende buona una patch rischiosa.
Verificare con comandi, non con la fede
Esegui test, linter, controllo dei tipi e build già usati dal progetto. Ripeti personalmente i controlli critici. Senza test, riproduci almeno l'errore iniziale e un percorso vicino.
Leggi git diff prima del commit. Elimina commenti inutili, formattazione casuale e modifiche fuori tema. Un commit deve raccontare una correzione, non un sacco di rottami.
Non consegnare tutte le chiavi
Non incollare password, chiavi API, dati clienti o configurazioni di produzione. Controlla .gitignore e i file cambiati. Mantieni la conferma per comandi rischiosi e limita gli strumenti quando possibile.
Saltare i permessi per risparmiare tre clic è una pessima furbata. Prima crea un punto recuperabile, poi lascia agire l'agente.
Verdetto: prima la mappa, poi il bisturi
Claude Code serve davvero quando segue il contesto tra file. Il flusso affidabile è esplorazione, piano stretto, diff piccolo, controlli automatici e revisione umana.
Parti da un errore riproducibile. Allarga il lavoro solo se la struttura è compresa e i test passano. Se vuole riscrivere tutto al primo messaggio, blocca quella pagliacciata.
Traduzione verificata:
