Cursor AI: usare i coding agents per programmare

Questo tutorial di leerob mostra come lavorare in pratica con i coding agents dentro Cursor AI, l'editor con un agent integrato. Il filo conduttore non è "lasciar scrivere il codice all'AI e sperare bene", ma costruire un metodo: pianificare le feature, capire il codice, trovare e correggere i bug, fare review e test, e infine adattare l'agent al proprio progetto. Sono concetti che valgono per qualsiasi coding agent, non solo per Cursor, e questo li rende utili sia al builder che vive nel terminale sia al founder che vuole capire come il proprio team produce software oggi.

L'harness e il peso dell'intento nel prompt

Il punto di partenza è capire dentro cosa gira l'agent. Cursor lo descrive come un harness fatto di tre componenti: le istruzioni che si danno al modello (system prompt e regole), i tool che gli si mettono a disposizione (modificare file, cercare nel codice, eseguire comandi nel terminale) e il modello stesso, che l'utente può scegliere tra diversi modelli di frontiera. I dettagli dell'harness restano sotto il cofano: quello che risulta decisivo è come si parla al modello. Un prompt molto semplice costringe l'agent a indovinare layout, componenti e stile; un prompt dettagliato, che rimanda a pattern già presenti nel codice o che allega informazioni come i log, alza nettamente la probabilità di un output di qualità. L'intento che si trasmette tramite il prompt è la leva principale.

Gestire il contesto come memoria di lavoro

Mentre si conversa con l'agent, lo scambio accumula contesto: i messaggi, le chiamate ai tool, i contenuti dei file letti. Questo contesto funziona come la memoria di lavoro dell'agent, potente ma con dei limiti. Il consiglio operativo è semplice: per una nuova feature conviene aprire una nuova conversazione, e quando l'agent inizia a sbagliare o a deviare dal percorso è il segnale per ripartire da capo. I modelli più recenti sono bravi a recuperare il contesto giusto da soli quando hanno buoni tool di ricerca sul codice; se si conosce il file esatto lo si può taggare nel prompt, altrimenti l'agent lo trova.

Capire il codice, poi costruire feature con plan mode

Una delle parti più dense riguarda la comprensione del codice. Cursor fornisce all'agent tool di ricerca precisi: la ricerca per corrispondenza esatta con grep (e ripgrep ricorsivo, fino all'instant grep ottimizzato per codebase grandi) per trovare nomi di funzioni o variabili, e la ricerca semantica per trovare parti di codice in base al significato, anche quando la parola cercata non compare letteralmente nel file. L'agent può inoltre lanciare sub-agent, come l'explore sub-agent che lavora in una finestra di contesto separata per non appesantire la conversazione principale, e generare diagrammi mermaid per visualizzare l'architettura. Un avvertimento ricorrente: chiedere modifiche senza prima capire come funziona il codice porta l'agent a creare funzioni o pattern nuovi quando esisteva già codice riutilizzabile, e così si accumula tech debt. Capito il codice, si passa alla feature partendo da un piano. La plan mode di Cursor ricerca il codice, pone domande di chiarimento e produce un piano passo-passo modificabile prima di generare codice: nella demo l'autore lascia volutamente vago il prompt iniziale per costruire insieme all'agent i requisiti, rivede il piano interattivo in markdown, avvia il dev server in locale, verifica nel browser integrato, incolla l'errore che compare per farlo correggere e itera sul design con screenshot e input vocale.

Debugging e code review allo stesso standard del codice scritto a mano

Il debugging segue gli stessi principi validi per chiunque, umano o agent: riprodurre il problema, ridurlo al caso minimo, isolare una variabile per volta, partire da ipotesi precise, strumentare il codice con logging e infine scrivere un test per prevenire regressioni. Per i bug semplici basta incollare l'errore e l'agent lo risolve; per quelli sistematici Cursor offre una debug mode che raccoglie prima evidenze a runtime, genera ipotesi, aggiunge logging mirato, chiede di riprodurre il problema e poi propone una correzione basata sui dati raccolti. Tra i suggerimenti: chiedere a più modelli di risolvere lo stesso bug per confrontare gli approcci, far usare all'agent tool esterni o un MCP server per portare dati reali nel contesto, e soprattutto capire davvero la soluzione proposta prima di accettarla, perché gli agent a volte allucinano spiegazioni plausibili che non centrano la causa. Sul fronte review, lo standard di ciò che si fa entrare nel codice non cambia tra scrittura a mano e generazione AI: il codice generato può sembrare corretto ma essere leggermente sbagliato. Il flusso mostrato parte da una self-review (la funzione "find issues" dell'agent individua, per esempio, stringhe non tradotte), passa alla richiesta di spezzare le modifiche in commit semantici e aprire una PR, aggiunge una passata di AI code review sulla PR con strumenti come BugBot che segnalano bug di logica o funzioni duplicate, e arriva a far scrivere all'agent i test sull'infrastruttura esistente. C'è anche la pratica di usare gli agent per testare e fare fuzzing di molte varianti dell'applicazione, e di ottimizzare la parte più lenta della pipeline (test, type check, build) perché quei risparmi si moltiplicano su ogni sessione.

Personalizzare l'agent con rules e skills

L'ultimo capitolo riguarda l'adattamento. Cursor offre due livelli di personalizzazione che ricalcano l'onboarding di un nuovo collega: le rules per le cose che l'agent deve sapere sempre e le skills per la conoscenza specializzata da caricare quando serve. Le rules sono file markdown visti all'inizio di ogni conversazione, vanno tenute corte, specifiche e con rimandi a esempi nel codice, e si versionano in Git per condividerle col team; troppe rules consumano contesto inutilmente e possono confondere l'agent. Le skills si caricano in modo dinamico, sono nella forma più semplice file markdown ma possono includere asset o script, e possono funzionare come workflow (l'autore cita una skill /pr che crea commit, push e PR). Rules, skills, MCP server e sub-agent si impacchettano e si condividono tramite plugin in un marketplace. Ultimo spunto: l'agent sa usare praticamente qualsiasi CLI installata nel terminale, dalla GitHub CLI a Docker, e basta chiederglielo (per esempio "controlla perché la CI è fallita su questa PR").

La conclusione pratica è che la competenza chiave non è più scrivere ogni riga a mano, ma saper dirigere un coding agent: dare intento chiaro, partire da un piano, verificare con test e review, e codificare ciò che si impara dentro rules e skills riutilizzabili. Per un builder significa shippare più in fretta senza rinunciare al controllo sulla qualità; per un founder significa capire cosa rende davvero produttivo un team che lavora con gli agent, al di là dello strumento specifico.