Cursor in pratica: 6 task dove l’editor AI fa risparmiare tempo

👁 115 letture

Cursor fa risparmiare più tempo non quando scrivi nuovo codice, ma in tutto ciò che un programmatore fa intorno: leggere progetti altrui, correzioni su più file, test e capire perché qualcosa non funziona. Abbiamo raccolto sei task dove la differenza è più evidente, con esempi di prompt.

Se stai installando Cursor per la prima volta, inizia dal tutorial passo dopo passo. Qui diamo per scontato che tu conosca il pannello Agent e la Plan Mode.

Analizzare un progetto altrui

Ricevi un repository che non hai mai visto e domani devi modificare qualcosa. Invece di passare ore a cliccare tra i file, chiedi all’Agent i punti di ingresso principali, i moduli chiave e cosa vale la pena leggere prima delle modifiche. Questo comando è suggerito dallo stesso quickstart di Cursor. Poi chiedi nello specifico: dov’è la logica dei pagamenti, da dove arriva questo valore, chi chiama questa funzione. Cursor risponde indicando i file, non con generalità.

Modifiche che toccano più file

Cambiare il nome di un campo nel database, aggiungere un nuovo parametro a una funzione usata in venti posti, passare a una nuova versione di una libreria. Farlo manualmente è noioso e soggetto a errori. In Plan Mode descrivi la modifica, Cursor prima analizza il progetto e mostra un piano, e tu lo approvi prima della prima modifica. Poi rivedi il confronto delle modifiche file per file.

Test per codice che non ne ha

Ogni progetto ha parti per cui nessuno ha scritto test, perché c’era sempre qualcosa di più urgente. Selezioni un modulo e chiedi test per i casi limite. È fondamentale che Cursor li esegua subito e corregga quelli che falliscono per problemi del test stesso, non del codice. Il quickstart consiglia esplicitamente di chiedere all’agent di eseguire i controlli che il progetto già usa.

Trovare la causa di un errore

Incolli il messaggio di errore o un frammento di log e chiedi di indicare la causa, non subito la correzione. Prima la diagnosi, poi la modifica, perché un agent a cui chiedi subito di riparare può mascherare il sintomo invece di rimuovere la causa. Solo quando la spiegazione ha senso, chiedi la correzione.

Correzioni rapide in un punto

Per piccole cose non ti serve l’Agent. Selezioni una funzione, premi Cmd + K (Ctrl + K) e scrivi cosa deve cambiare: aggiungi gestione lista vuota, riscrivi in async, aggiungi validazione. È il caso d’uso che usi più spesso, perché richiede pochi secondi.

Per queste correzioni vale una regola che conviene applicare a tutto il resto: più piccolo è il frammento che selezioni, più precisa è la modifica. Selezionare una singola funzione dà un risultato prevedibile, selezionare un intero file invita Cursor a correggere cose che non hai chiesto.

Documentazione e descrizione modifiche

Descrizione di una pull request, commento a una funzione complessa, istruzioni per avviare il progetto. Cursor conosce il codice che hai appena modificato, quindi lo descrive con più precisione di una chat generica a cui dovresti incollare tutto.

Esempio: da un errore nei log alla correzione

Ecco come appare un’intera conversazione per un errore tipico, suddivisa in passaggi. Supponiamo che un form di ordine a volte salvi un indirizzo vuoto.

• Diagnosi. Incolli un frammento di log e scrivi: “A volte l’ordine si salva con indirizzo vuoto. Trova le possibili cause, non modificare ancora il codice.” Cursor indica dove l’indirizzo viene validato e dove potrebbe essere sovrascritto.
• Conferma. Chiedi un test che riproduca l’errore. Se il test fallisce, hai la prova che la causa è quella giusta.
• Correzione. Solo ora chiedi una modifica che faccia passare il test, senza toccare altre parti del form.
• Controllo. Chiedi di eseguire tutti i test, per verificare che la correzione non abbia rotto nient’altro.

Quattro brevi comandi invece di un unico “riparalo” producono una modifica che capisci e di cui ti fidi. Inoltre resta un test che catturerà questo errore se dovesse ripresentarsi.

Esempio: nuova funzione in un progetto altrui

Il secondo scenario frequente è aggiungere una funzione a codice che non hai scritto. Inizi chiedendo dove funzioni simili sono già implementate, ad esempio come funziona l’export dati esistente. Poi chiedi un piano in Plan Mode, modellato su ciò che già esiste nel progetto. Così il nuovo codice assomiglia al resto, non a un innesto da un altro mondo, ed è più facile da rivedere per qualcuno del team.

Dove Cursor non sostituisce il pensiero

Parliamo onestamente dei limiti, perché ne abbiamo scritto anche nell’articolo su come un editor con AI non aiuta se non sai cosa chiedere:

• le decisioni architetturali le prendi ancora tu, Cursor può solo prepararle,
• la sicurezza richiede revisione umana, specialmente per login e dati clienti,
• le modifiche senza test sono rischiose come quando scrivi a mano, solo che nascono più velocemente.

Pro o Pro+

Il piano Pro basta per il lavoro quotidiano su uno o due progetti. Pro+ ha senso durante sprint intensivi, quando l’agent lavora per te per la maggior parte della giornata. I dettagli sui limiti li abbiamo descritti nell’articolo Quanto costa Cursor, e sul cambio di modelli nella guida su Grok in Cursor.

// continua a leggereAutomatizzazione con AI: strumenti, costi e scenari praticiMagazineModelli decisionali vs LLM: quanto risparmi su un milione di classificazioniBenchmarkFoto stile anni 80 con l’AI: 10 prompt ed esempi praticiGuide