Come uso Claude Code e Cursor per velocizzare lo sviluppo full-stack

Ultimamente me lo chiedono spesso: "Ma usi davvero l'AI per scrivere il codice?" La risposta breve è sì, Claude Code e Cursor fanno parte del mio lavoro quotidiano su progetti reali per i clienti. La risposta lunga è più utile, perché è il modo in cui usi questi strumenti a fare la differenza tra rilasciare più velocemente e rilasciare un disastro.

Questo articolo è uno sguardo pratico a dove questi strumenti mi fanno risparmiare davvero tempo nel lavoro full-stack, dove no, e come mantengo il risultato a un livello di qualità su cui metterei volentieri la mia firma.

Due strumenti, due compiti

Si tende a mettere tutti gli "strumenti di coding con AI" nello stesso calderone, ma io li uso per cose diverse.

• Cursor vive dentro l'editor. È ottimo per modifiche rapide e contestuali: rifattorizzare un componente, scrivere una funzione mentre osservo, completare automaticamente le prossime righe ovvie. Ha anche una propria modalità agente per modifiche più grandi, ma per me dà il meglio quando sono concentrato e voglio restarci.
• Claude Code lavora a livello di progetto. Lo uso soprattutto dal terminale (ha anche estensioni per IDE, un'app desktop e una versione web). Ci conto per attività più grandi su più file, come "porta questo nuovo endpoint attraverso service, controller e tipi" oppure "trova ogni punto in cui viene chiamata questa vecchia API e aggiornalo". È più bravo a tenere a mente un'intera modifica.

Nessuno dei due sostituisce la comprensione del codebase. Mi rendono più veloce nelle cose che so già fare.

Entrambi gli strumenti ora possono anche eseguire agenti in background o nel cloud e restituire un branch o una pull request finiti. È comodo per i compiti ben definiti, ma alza la posta sulla revisione: meno lavoro ho visto svolgersi, più attentamente leggo il risultato.

Il problema di business: il tempo degli sviluppatori è la tua risorsa più costosa

Se stai pagando per uno sviluppo, in realtà stai pagando ore. Tutto ciò che trasforma un'attività da un'ora in una da quindici minuti, senza abbassare la qualità, riduce direttamente i tuoi costi e accorcia i tempi.

Il punto critico è proprio quel "senza abbassare la qualità". Gli strumenti di AI possono produrre codice che sembra finito ma non lo è. Quindi la vera competenza non è scrivere prompt. È sapere quale lavoro delegare e revisionare l'output come faresti con la pull request di uno sviluppatore junior.

Dove questi strumenti mi fanno risparmiare tempo davvero

Boilerplate e "idraulica"

Ogni funzionalità full-stack ha un guscio prevedibile: un endpoint tipizzato, la validazione della richiesta, una query al database, il form corrispondente nel frontend, gli stati di caricamento ed errore. È un lavoro necessario ma poco interessante, ed è lì che l'AI offre l'accelerazione più grande e più sicura. Descrivo la forma, lo strumento la abbozza, io revisiono e aggiusto.

Modifiche ripetitive e meccaniche

Rinominare un concetto in quaranta file, aggiornare ogni punto di chiamata dopo una modifica a un'API, convertire un gruppo di componenti a un nuovo pattern. Fatto a mano è noioso e soggetto a errori. Claude Code lo fa in modo rapido e coerente, e io controllo il diff prima di accettarlo.

Test che altrimenti sarei tentato di saltare

Sotto scadenza, i test sono la prima cosa che si abbandona. L'AI rende economico scrivere i casi che salterei: la lista vuota, il token scaduto, l'invio duplicato. Più copertura con meno sforzo è una vittoria netta.

Capire codice che non conosco

Quando entro in un progetto esistente, posso chiedere a Claude Code di spiegarmi come si articola un sottosistema invece di leggere ogni file da zero. È un modo più rapido per orientarmi, e verifico comunque ciò che mi dice.

Dove non mi affido a loro

Il confine su cui mi sono assestato non riguarda davvero lo strumento. Sono due domande: quanto è reversibile questa modifica, e posso dimostrare che è corretta? Se qualcosa è facile da annullare e da verificare con i test, sono tranquillo nel lasciarne fare molto all'AI. Se crea vincoli di lunga durata, l'AI al massimo scrive una bozza, e la decisione finale resta mia.

• Architettura e modellazione dei dati. Queste decisioni si accumulano nel tempo. Le prendo io e uso l'AI solo per mettere alla prova le opzioni. Uno schema che sembra a posto e viene generato in trenta secondi può morderti settimane dopo.
• Tutto ciò che riguarda la sicurezza. Autenticazione, permessi, flussi di pagamento, isolamento tra tenant. Li scrivo e li revisiono con attenzione. L'AI genera volentieri un endpoint senza alcun controllo di autorizzazione.
• Logica di business sottile. Se le regole sono insolite o ci sono di mezzo soldi veri, voglio che una persona abbia il pieno controllo dei dettagli.
• Gestione degli errori. Il percorso felice viene generato benissimo; sono i fallimenti parziali, i retry e l'idempotenza che l'AI sbaglia in silenzio, e te ne accorgi solo quando gira in produzione.

Il rischio più profondo di solito non è il codice in sé. Sono le ipotesi che incorpora senza dirtelo. Una funzione generata può superare tutti i test pur presupponendo in silenzio che "questo campo c'è sempre" o che "questa lista non diventa mai grande". Nessuno l'ha messo per iscritto, quindi niente lo sta controllando. Il mio vero filtro è: questo codice incorpora un'ipotesi operativa che nient'altro sta verificando? Per validatori, CRUD e stati dell'interfaccia queste ipotesi sono locali e visibili, quindi sono tranquillo. Per il modello dei dati e i punti di integrazione sono globali e silenziose, ed è proprio lì che un'ipotesi sbagliata ma sicura di sé sopravvive alla revisione.

Un esempio concreto

Gran parte del mio lavoro recente riguarda piattaforme SaaS multi-tenant e sistemi di biglietteria: progetti con un backend NestJS o Node, un frontend React o Next.js tipizzato e molta superficie CRUD distribuita su tanti moduli: utenti, eventi, biglietti, pagamenti, notifiche.

Su un codebase del genere, lo schema è ripetitivo per costruzione: ogni modulo assomiglia al precedente. È il punto ideale per l'assistenza dell'AI. Posso impostare endpoint, DTO, validazione e form frontend di un nuovo modulo in una frazione del tempo abituale, e poi dedicare la mia vera attenzione alle parti che cambiano: le regole sui permessi, i casi limite, come si inserisce nell'architettura esistente.

Il risultato onesto non è magia. È che il 70% noioso va più veloce, il che lascia più tempo ed energie per il 30% che decide se la funzionalità è davvero buona.

Errori comuni che vedo

• Accettare grandi modifiche dell'AI senza leggerle. Più è grande il diff, più è probabile che qualcosa di sottile sia sbagliato.
• Scrivere prompt invece di pensare. Se non sai come appare un buon risultato, l'AI non può dirtelo. Produrrà semplicemente qualcosa.
• Saltare la fase del modello dei dati. Uno schema buttato giù in fretta dall'AI è uno schema con cui combatterai per mesi.
• Nessun test. La velocità senza una rete di sicurezza significa solo rompere le cose più in fretta.
• Lasciare che lo stile vada alla deriva. Senza indicazioni, l'AI scrive codice nel proprio stile, non in quello del progetto. Lo mantengo coerente con il codice circostante e scrivo le convenzioni del progetto nel file di istruzioni di ogni strumento (un CLAUDE.md per Claude Code, le regole di progetto per Cursor), così parte dai pattern giusti.
• Ignorare gli accoppiamenti sottili. Il bug costoso raramente è di sintassi. È un helper generato che diventa silenziosamente il punto in cui si incontrano autenticazione, stato della fatturazione e ipotesi di prodotto. Si rilascia in fretta e si pagano gli interessi dopo.
• Nessuna visibilità su chi usa l'AI e per cosa. Puoi avere una disciplina di revisione impeccabile e finire comunque nei guai se metà del team passa gli schemi di produzione a uno strumento di AI senza dirlo a nessuno. La governance, senza diventare paranoici, è un problema a sé.

Come mantengo alta la qualità

1. Modifiche piccole e revisionabili: preferisco guidare dieci modifiche mirate piuttosto che accettarne una gigantesca.
2. Leggo tutto: ogni riga scritta dall'AI riceve la stessa revisione della PR di un collega.
3. Test sui percorsi importanti: soprattutto sui casi di errore.
4. Rispetto i pattern esistenti: il codice deve somigliare al resto del codebase, non sembrare uscito da un altro progetto.
5. Le decisioni umane restano umane: architettura, sicurezza e logica legata ai soldi restano nelle mie mani.
6. Ogni modifica dell'AI deve rendere conto di sé: per qualsiasi cosa non banale, voglio che la modifica mostri cosa ha toccato davvero: quali tabelle, rotte o permessi sono cambiati, cosa potrebbe corrompere i dati o far trapelare informazioni tra tenant, prove del prima e dopo, test aggiunti o deliberatamente saltati, e un piano di rollback. Questa "ricevuta" conta più di quale strumento ha prodotto il codice.

Se ti interessa il quadro generale della costruzione di prodotti snelli in questo modo, ho scritto di come lo sviluppo assistito dall'AI aiuta a costruire MVP più velocemente senza perdere qualità.

Cerchi uno sviluppatore che usi gli strumenti moderni nel modo giusto?

Usare bene l'AI è una competenza. È la differenza tra uno sviluppo più rapido e pulito e una costosa operazione di pulizia in seguito. Uso questi strumenti ogni giorno per rilasciare più velocemente progetti web e mobile full-stack, senza tagliare gli angoli che contano.

Se è il tipo di sviluppatore che vuoi sul tuo progetto, dai un'occhiata al mio lavoro oppure scrivimi e raccontami cosa stai costruendo.