Cursor 3: una nuova era del coding AI con agenti in parallelo

Novità di Cursor 3

La versione 3.0 punta più sull'infrastruttura che sulla rifinitura dell'UI. Ecco cosa è davvero cambiato.

Workspace unificato per gli agenti

Tutta l'attività degli agenti ora vive in un'unica interfaccia. La sidebar mostra ogni agente in esecuzione sulla tua macchina o sul cloud, inclusi quelli avviati da Slack, GitHub, Linear, mobile e web. Un'unica vista.

Il workspace è per natura multi-repo. Un agente può aggiornare componenti frontend mentre un altro applica una patch a una libreria backend. Prima di Cursor 3, questo richiedeva finestre IDE separate e continui cambi di contesto.

Due aggiunte degne di nota: le Schede Agente ti permettono di vedere più chat agente affiancate o in griglia. Le chat degli agenti sono ora anche schede standard dell'editor, quindi split-pane e scorciatoie da tastiera funzionano come previsto. Niente da reimparare. Design Mode ha una sezione dedicata più sotto.

Esecuzione di più agenti in parallelo

Il comando /best-of-n gira nella chat dell'agente dentro l'IDE, non nella Finestra Agenti. Per usarlo, apri un repository Git, apri la chat Agente nel layout editor classico ed esegui /best-of-n seguito da un elenco di modelli separati da virgola e dal tuo task. Per esempio: /best-of-n sonnet, gpt, composer fix the flaky logout test.

Cursor crea un worktree Git separato per ogni modello, così le esecuzioni non interferiscono tra loro. Al termine, puoi rivedere gli output, fare commit e push dal worktree selezionato o eseguire /apply-worktree per riportare le modifiche nella tua copia di lavoro principale. Puoi anche personalizzare la configurazione dei worktree per progetto tramite .cursor/worktrees.json.

Cursor ora indirizza le esecuzioni parallele multi-modello tramite /best-of-n nella chat agente dell'IDE, mentre il vecchio flusso di selezione non è più il percorso consigliato.

Il comando /worktree segue la stessa strada: chat agente nell'IDE, repo Git richiesto, worktree isolato per agente.

La scelta del "migliore" riflette le euristiche di valutazione di Cursor, non necessariamente le tue. Leggi tu stesso gli output.

Una nota pratica: ogni esecuzione di modello è fatturata in modo indipendente alla normale tariffa per token senza sconti in bundle. Tre modelli significa tre addebiti separati. Più avanti approfondirò il sistema di crediti.

Passaggio tra agenti locali e cloud

Gli agenti cloud girano su macchine virtuali Ubuntu isolate. Il passaggio funziona in entrambe le direzioni.

Spostare dal cloud al locale ti dà accesso al file system, al server di sviluppo locale e agli strumenti di test desktop. Portare una sessione sul cloud consente ai task di lunga durata di continuare dopo che chiudi il laptop. Quando l'agente finisce, i risultati ti aspettano nella Finestra Agenti. Gli agenti cloud producono anche demo e screenshot del loro lavoro, che puoi rivedere prima di riportare qualcosa in locale.

Le sessioni degli agenti si muovono bidirezionalmente tra locale e cloud. Immagine dell'autore.

Per i team enterprise, gli agenti cloud self-hosted sono disponibili dal 25 marzo 2026. Codice, esecuzione degli strumenti e artifact di build restano all'interno della tua infrastruttura. Un processo worker si connette in uscita al cloud di Cursor via HTTPS, senza bisogno di porte in ingresso o VPN. Gli agenti self-hosted sono sul piano Enterprise; gli agenti cloud standard sono disponibili su Pro e superiori.

Puoi definire l'ambiente cloud con un file .cursor/environment.json alla radice del repo. Conserva i secret nella tab Secrets delle Impostazioni di Cursor, non in quel file.

Dal commit alla pull request in un unico flusso

La nuova interfaccia dei diff ti consente di vedere le modifiche a livello di parola, preparare i commit e aprire una pull request senza lasciare la Finestra Agenti. Il rendering dei diff di file grandi è più veloce e leggero in memoria nella 3.0.

Quando usi /worktree nell'editor classico, ogni agente lavora sul proprio worktree isolato, quindi i diff sono già puliti quando arrivi alla revisione. Niente grovigli di modifiche sovrapposte.

Cursor ha anche annunciato un accordo definitivo per acquisire Graphite, uno strumento di gestione delle pull request, il 18 dicembre 2025. Stavo quasi per ometterlo dato che i dettagli d'integrazione non sono confermati, ma l'acquisizione potrebbe rimodellare questo flusso una volta conclusa.

Design Mode e browser integrato

Descrivere una modifica di UI a parole è più lento che indicarla. Design Mode risolve questo.

Premi Cmd+Shift+D per attivare uno strumento di selezione sopra il browser integrato. Usa Shift+drag per selezionare un'area, Cmd+L per inserire un elemento selezionato nella chat dell'agente, oppure Option+click per aggiungerlo al campo di input. L'agente riceve l'HTML, il CSS applicato e il riquadro di delimitazione visivo. Invece di scrivere un paragrafo per descrivere il problema di layout, selezioni l'elemento e dici "stringi questo".

Il browser include anche Chrome DevTools. Gli agenti possono avviare un server di sviluppo locale, cliccare pulsanti, leggere i log della console e verificare che le modifiche abbiano funzionato davvero.

Composer 2: il modello di coding integrato di Cursor

Composer 2 è stato lanciato il 19 marzo 2026, due settimane prima di Cursor 3. È il modello che alimenta gli agenti nel nuovo workspace.

È costruito su una base Kimi K2.5 di Moonshot AI, con pretraining continuo e un'esecuzione di reinforcement learning su scala 4x sopra. Cursor non ha divulgato il modello base al lancio. Un utente lo ha trovato negli header API il giorno successivo. Il co-fondatore Aman Sanger ha riconosciuto la svista: "È stato un errore non menzionare la base Kimi nel nostro blog fin dall'inizio. Lo correggeremo per il prossimo modello."

Se i numeri dei benchmark non fanno per te, la versione breve è: Composer 2 è più veloce ed economico delle alternative di terze parti. Vai direttamente alla tabella dei prezzi qui sotto.

Nel CursorBench di Cursor, Composer 2 ottiene 61,3 contro 44,2 di Composer 1.5, circa un salto del 39%. Eroga oltre 200 token al secondo, in parte grazie a kernel GPU personalizzati che Cursor costruisce in-house invece di affidarsi solo a stack di inferenza di terze parti. CursorBench non è auditato in modo indipendente, quindi considera i numeri con questo in mente. GPT-5.4 lo batte su compiti più difficili, ma sui task di CursorBench (in media 352 righe su otto file) Composer 2 supera Claude Opus 4.6 con circa il 90% di costo per token in meno. Quel divario di costo è il numero più interessante.

Ecco la ripartizione dei prezzi:

Nei piani individuali a pagamento, Composer 2 ha il proprio pool di utilizzo separato dai crediti per i modelli frontier selezionati manualmente. È basato sulla spesa, non sulle richieste. La ripartizione completa dei crediti è nella sezione prezzi qui sotto. Il modello ha una finestra di contesto da 200.000 token con auto-sintesi: quando il contesto si riempie, comprime a circa 1.000 token e continua.

Composer 2 è costruito apposta per il coding agentico. Non ti aiuterà con altro.

Cursor 3 come ambiente di sviluppo agent-first

Il CEO di Cursor, Michael Truell, ha descritto lo sviluppo software con AI in tre ere. Prima è arrivato l'autocomplete su Tab, che completa il codice ripetitivo. Poi gli agenti sincroni, che guidano il modello passo dopo passo. Ora gli agenti cloud girano in autonomia su orizzonti temporali più lunghi, con gli sviluppatori che agiscono da registi più che da autori.

I dati d'uso riflettono questo cambiamento. Come notato prima, il rapporto agenti-Tab si è ribaltato tra inizio 2025 e inizio 2026.

La cornice di Truell: "Cursor non riguarda più principalmente lo scrivere codice. Riguarda aiutare gli sviluppatori a costruire la fabbrica che crea il loro software." È una dichiarazione di visione, non una descrizione di prodotto. La maggior parte degli sviluppatori che usa Cursor 3 oggi sta ancora rivedendo e correggendo continuamente l'output degli agenti. Non ho ancora visto un codebase in cui la fabbrica si autogestisca. Ma l'interfaccia è costruita nell'ottica che quella versione sia più vicina di quanto sembri.

Funzionalità chiave che restano e migliorano

Le funzionalità core delle versioni precedenti sono ancora presenti e per lo più invariate.

File e comprensione del codice

Rimane il pieno supporto al Language Server Protocol (LSP). Vai-a-definizione, ricerca simboli, documentazione al passaggio del mouse e navigazione tra file funzionano come in VS Code. I riferimenti di contesto come @Files, @Folders e @Docs sono supportati. La Finestra Agenti non rimuove l'accesso a livello di file; aggiunge uno strato sopra.

Cursor Marketplace e plugin

Il Cursor Marketplace aggiunge capacità agli agenti tramite installazioni di plugin con un clic. Un plugin include una combinazione di Skills (prompt che gli agenti possono invocare su richiesta), Subagent, server MCP, Hook e Regole. Spiegazione completa nella documentazione di Cursor.

I plugin disponibili coprono un ampio spettro: AWS, Figma, Linear, Stripe, Vercel, Datadog, Snowflake e altro. I piani Teams ed Enterprise possono impostare marketplace privati di team. Per Enterprise, l'import dei plugin di terze parti è disattivato per impostazione predefinita a meno che un admin non li abiliti.

Una lacuna che non dovrebbe esistere: non c'è un'interfaccia integrata per impostare variabili d'ambiente per i server MCP dei plugin del Marketplace. Il workaround è aggiungere manualmente il server a ~/.cursor/mcp.json con un campo env e disabilitare la voce duplicata nelle Impostazioni di Cursor. Funziona, ma è il tipo di cosa che non dovrebbe richiedere un workaround in un prodotto a pagamento.

Automations

Le Automations, rilasciate il 5 marzo 2026, sono agenti sempre attivi attivati da eventi esterni: schedulazioni, messaggi Slack, issue di Linear, eventi GitHub e incident di PagerDuty. L'agente avvia un sandbox cloud e segue le istruzioni usando MCP e modelli configurati. Quando la memoria è attiva, l'agente ottiene accesso a un blocco note persistente (piccoli file di testo come MEMORIES.md che sopravvivono tra un'esecuzione e l'altra). È l'agente a decidere cosa annotare: progressi, pattern individuati, contesto da esecuzioni precedenti. L'esecuzione successiva legge quelle note e riparte da lì. Puoi visualizzare e modificare questi file nella sezione Automations della dashboard.

Prezzi e requisiti dei piani di Cursor 3

Non tutte le funzionalità sono disponibili su ogni piano. Ecco l'attuale ripartizione:

Gli agenti cloud e Composer 2 richiedono Pro o superiore. I Marketplace di team richiedono Teams o Enterprise, e gli agenti cloud self-hosted sono solo Enterprise.

Cursor gestisce due pool di crediti separati sui piani individuali a pagamento: uno per Auto mode e l'uso di Composer, descritto da Cursor come "generoso" senza un tetto pubblicato, e uno per i modelli frontier selezionati manualmente come Claude o GPT. Quando scegli un modello manualmente, attinge al pool crediti. Auto mode no.

Nota per gli utenti intensivi: sviluppatori sul piano Pro che avviano sessioni di agenti frequenti riportano una spesa reale più vicina a $40–$50 al mese una volta scattati gli extra. I $20 sono la base.

Come Cursor 3 cambia i workflow degli sviluppatori

Ecco un confronto concreto per un task standard di backend API:

Il cambiamento non è da difficile a facile. È da scrivere a dirigere. Passi meno tempo sull'implementazione e più tempo a definire i requisiti e rivedere l'output. Se lo scambio vale dipende dal task e, onestamente, da quanto ti fidi dell'agente in un dato giorno.

I task di lunga durata ne beneficiano di più. Un refactoring che richiederebbe ore in un terminale può andare a un agente cloud, tu chiudi il laptop, l'agente continua e i diff ti aspettano al ritorno.

Cursor 3 vs. versioni precedenti di Cursor

Il primo Cursor (dal 2022 al 2024) era uno strumento IDE-first. Editing di file assistito dall'AI in un ambiente VS Code.

Cursor 1.0 (giugno 2025) è stato il primo rilascio stabile. Cursor 2.0 (ottobre 2025) ha portato il primo modello Composer e il browser in-app. Cursor 2.5 (febbraio 2026) ha aggiunto subagenti async e il marketplace dei plugin. Cursor 2.6 (marzo 2026) ha aggiunto i marketplace di team.

Cursor 3.0 rende ufficiale il cambiamento. Gli agenti cloud sono usciti dall'Editor e ora vivono esclusivamente nella Finestra Agenti. Anche il supporto ai worktree è cambiato: la vecchia UI a tendina è stata deprecata e sostituita dai comandi /worktree e /best-of-n , che girano nella chat dell'editor classico. Se hai documentazione interna su come usare il menu a tendina dei worktree o avviare agenti cloud dall'interno dell'Editor, è obsoleta.

Cursor ha sfruttato la ricostruzione 3.0 per ripagare debito di performance della 2.x: patch a leak di memoria e CPU, React Compiler. Robinson ha descritto il risultato come più veloce e meno soggetto a scatti dell'UI. Windows è pienamente supportato e l'interfaccia gestisce più workspace in una singola finestra.

Il salto dalla 2.x alla 3.0 è più strutturale di quanto sembri. Le versioni precedenti aggiungevano funzionalità di agent a un IDE. Cursor 3 aggiunge un IDE a una piattaforma di agent. L'ordine conta.

Cursor 3 vs. IDE tradizionali

Gli IDE tradizionali sono file-centrici. Apri un file, modifichi testo e l'IDE ti aiuta a digitare più velocemente. Anche con GitHub Copilot installato, l'astrazione resta il documento.

Cursor 3 rende il file secondario. L'interfaccia principale è la coda dei task. L'IDE diventa il fallback per modifiche troppo specifiche per essere descritte in un prompt.

Il confronto però sta diventando più sfumato. GitHub Copilot ora offre agenti cloud e code review anche nei piani individuali. JetBrains include Junie, il suo agente di coding autonomo, con gli abbonamenti AI. E, come detto, Cursor ora gira dentro gli IDE JetBrains via ACP. Ormai tutti hanno agenti. La vera differenza con Cursor 3 è che il workspace è stato costruito attorno a loro, non aggiunto a un editor esistente.

Limitazioni e questioni aperte

L'esperienza quotidiana ha più attriti di quanto suggeriscano i materiali di lancio.

Supervisione dello sviluppatore

Gli agenti commettono errori. Su task complessi multi-file, ne commettono molti. Rivedere l'output degli agenti richiede sufficiente familiarità con il codebase per cogliere assunzioni errate, funzioni allucinate e logica che quasi funziona. Il tempo risparmiato nello scrivere si sposta sulla lettura e sulla validazione. Gli sviluppatori che non sanno leggere il codice generato per verificarlo non riusciranno a mantenere il codebase funzionante. Non è una critica specifica a Cursor; vale per ogni strumento di coding agentico.

Affidabilità degli agenti cloud

I fallimenti nel setup dell'ambiente sono un problema documentato e in corso. I secret non possono essere iniettati durante lo script di setup iniziale, solo post-setup. Sessioni parallele prolungate consumano risorse significative; utenti hanno riportato uso pesante di RAM su macchine che dovrebbero reggerlo. Tieni le sessioni sotto le due ore se puoi e aggiungi checkpoint di re-indicizzazione per tutto ciò che è più lungo.

Un'altra lacuna specifica: la Plan Mode non è ancora disponibile nella web UI di Cursor. Puoi avviare ed eseguire agenti cloud, inclusa la pianificazione, dall'app desktop Cursor 3, ma non direttamente da cursor.com/agents.

C'è anche un bug noto per cui gli agenti si bloccano quando la Finestra Agenti non è in primo piano. È stato segnalato poco dopo il lancio ed era irrisolto ai primi di aprile 2026. Per uno strumento costruito su sessioni di lunga durata, è un problema reale.

Sugli agenti paralleli in generale: ricerche di Google DeepMind sui sistemi multi-agente hanno riscontrato un'amplificazione degli errori fino a 17,2 volte in reti non strutturate. Anche con il 99% di affidabilità per agente, dieci agent concatenati scendono a circa il 90% complessivo. Il comando /best-of-n usa worktree isolati, il che limita parte di ciò. Non lo elimina.

Considerazioni sulla sicurezza

Nel 2025 sono state trovate e patchate due CVE. CVE-2025-54136 (MCPoison) consentiva a strumenti MCP approvati di avere i propri comandi modificati silenziosamente; patch nella versione 1.3. CVE-2025-64106 era una vulnerabilità di esecuzione di codice remoto via deep-link con gravità 8,8, patchata in due giorni. Workspace Trust è anche disabilitato per impostazione predefinita. Se stai collegando strumenti MCP in un ambiente sensibile, conta.

Gli agenti cloud self-hosted, come detto prima, mantengono il lavoro degli agenti dentro la tua rete, ma la piattaforma Cursor non è disponibile come deployment on-premises completo. Cursor non ha certificazione FedRAMP o HIPAA. La disponibilità di BAA non è documentata pubblicamente, quindi verifica direttamente con Cursor prima di fare scelte di conformità. Se il tuo ambiente richiede FedRAMP o un deployment completamente on-premises, Cursor 3 non è adatto.

Altre due limitazioni pratiche da segnalare: Design Mode al momento funziona solo in Chrome; Firefox e Safari non sono supportati. E nei giorni successivi al lancio di Cursor 3, segnalazioni della community hanno documentato un consumo di token di Composer 2 circa 10 volte superiore al normale per alcuni utenti, legato a problemi di lettura cache.

Il modello a crediti

Come detto nella sezione sugli agenti paralleli, ogni modello /best-of-n viene addebitato separatamente. Un confronto a tre modelli su un task complesso può prosciugare gran parte del pool mensile in una singola sessione.

Chi dovrebbe usare Cursor 3?

Se già esegui workflow assistiti da agenti e vuoi tutto in un unico posto, questo fa per te. Ha più senso per team che lavorano su più repo, per task più lunghi da passare al cloud e per team enterprise che hanno bisogno che il codice resti nella propria infrastruttura.

Non lo consiglierei ai principianti. Non perché sia difficile da usare, ma perché gli agenti producono codice che devi leggere criticamente. Se non sai capire quando l'output è sbagliato, non puoi correggerlo e tra sei mesi il codebase lo mostrerà. Per script semplici o task una tantum, nemmeno il setup vale la pena. E se il tuo ambiente è regolato HIPAA o air-gapped, vedi la sezione Sicurezza prima di andare oltre.

Anche i grandi monorepo legacy sono un problema reale. Le finestre di contesto si rompono ancora su di essi.

Il futuro del coding AI con Cursor

Nel febbraio 2026, Cursor ha pubblicato "Towards Self-Driving Codebases", descrivendo esperimenti con migliaia di agenti orchestrati su grandi codebase. L'obiettivo dichiarato: "finché i codebase non saranno self-driving."

Le finestre di contesto si rompono ancora sui grandi monorepo. Gli agenti allucinano regolarmente. La visione è abbastanza lontana che non pianificherei in base ad essa.

Quello che fa Cursor 3 è mettere in posizione i pezzi principali: un modello in Composer 2, un'interfaccia nella Finestra Agenti, VM cloud come runtime e opzioni self-hosted per l'enterprise. Il codebase self-driving dipende da miglioramenti dei modelli che Cursor non controlla del tutto.

La cornice della "fabbrica" di Truell è ancora lontana dalla realtà. Per ora, sei ancora tu a ispezionare il pavimento della fabbrica.

Conclusione

Il cambiamento principale di Cursor 3 non è una funzionalità. È che l'interfaccia è stata ricostruita su un presupposto diverso: che l'agente, non il file, sia l'unità di lavoro. Due anni fa era una scommessa. I dati d'uso suggeriscono che sta ripagando.

Se si adatta al tuo workflow dipende da cose che non posso determinare da qui: dimensione del codebase, requisiti di sicurezza e se puoi convivere con un prodotto lanciato settimane fa che ha ancora spigoli. Se sei indeciso, rileggi la sezione Limitazioni prima di decidere.

Se vuoi andare oltre con Cursor nella pratica, il nostro corso Software Development with Cursor copre prompting, refactoring, testing e workflow con agenti.