AIREITERL’architettura di Cursor basata su coordinatore e subagent è davvero utile per le migrazioni di grandi codebase, ma non va confusa con un pulsante per riscrivere tutto senza supervisione. Funziona al meglio quando il lavoro può essere suddiviso in blocchi circoscritti e verificabili; diventa invece rischiosa quando gli agenti condividono contratti, file o regole di business non documentate. Anche il nome “Projects” va interpretato con cautela: la documentazione ufficiale attuale si concentra su subagent, esecuzione asincrona, cloud agent e attività di coding prolungate, più che su un’unica pagina di prodotto Projects descritta in modo uniforme.
Cosa offre davvero la beta di Cursor Projects ai team che affrontano una migrazione
La documentazione attuale sui subagent di Cursor descrive un Agent principale che delega attività specialistiche a finestre di contesto separate. Il subagent restituisce il risultato al proprio agente padre, può lavorare in primo piano o in background e può avere strumenti, modello e permessi di scrittura propri.
Per una migrazione, questa è un’unità architetturale utile: un coordinatore mantiene il perimetro e prende le decisioni, mentre gli specialisti esplorano il repository, implementano modifiche circoscritte, eseguono test o revisionano il risultato. Cursor documenta anche subagent cloud dotati di macchina virtuale, branch e clone del repository propri: un’impostazione sensibilmente più sicura rispetto a più agenti che modificano la stessa copia locale.
La cautela legata alla beta è importante. Una discussione sul rilascio di Cursor del febbraio 2026 annunciava subagent asincroni e annidati, ma alcuni utenti segnalavano problemi nell’avvio affidabile delle attività in background; in una risposta, lo staff di Cursor ha indicato che il problema relativo a is_background: true avrebbe dovuto essere risolto in Cursor 2.6. Disponibilità e comportamento vanno quindi considerati dipendenti dalla versione, non come caratteristiche garantite del sistema di coordinamento.
Il workflow di migrazione che trae vantaggio dal coordinamento
Un coordinatore è utile quando governa la sequenza delle attività, non quando tenta di scrivere ogni singola riga. Per una migrazione di framework o linguaggio, conviene distribuire il lavoro in questo modo:
| Ruolo | Output utile | Perché tenerlo in un contesto separato |
|---|---|---|
| Esploratore del repository | Mappa delle dipendenze, punti di ingresso, confini del codice generato | I risultati delle ricerche possono saturare il thread principale |
| Planner della migrazione | Pacchetti di lavoro ordinati e invarianti | La pianificazione richiede una visione dell’intero repository |
| Implementatore | Modifiche a un modulo, servizio o worktree | Un perimetro ristretto limita le modifiche estranee |
| Agente per i test | Controlli nuovi ed esistenti per una singola porzione | I log dei test sono prolissi e possono essere gestiti autonomamente |
| Reviewer | Rilevazioni su regressioni, sicurezza e convenzioni | Un contesto nuovo è meno condizionato dall’implementazione |
| Coordinatore | Verifica dei contratti, decisioni sui conflitti, ondata successiva | Serve un punto unico che riconcili output incompatibili |
Il report di Cursor sul coding prolungato descrive una struttura simile, composta da planner, worker e judge. Nell’esperimento di conversione da Solid a React, Cursor parla di oltre tre settimane di lavoro e di circa 266.000 aggiunte più 193.000 eliminazioni, sottolineando però che è stata comunque necessaria una revisione accurata. È una dimostrazione della capacità dell’architettura di sostenere un lavoro ampio, non la prova che una migrazione sia automaticamente pronta per la produzione.
Dove l’architettura dà il meglio nelle codebase di grandi dimensioni
1. Inventario e mappatura delle dipendenze
Le migrazioni di grandi dimensioni spesso falliscono già all’inizio, quando il team non individua un punto di utilizzo, uno script di build, un file generato o un’ipotesi legata al deployment. Un esploratore dedicato può analizzare queste superfici mentre il coordinatore trasforma i risultati in un registro della migrazione.
È un approccio più solido rispetto a chiedere a un unico agente di “migrare il repository”, perché l’output resta verificabile: pacchetti coinvolti, relazioni tra dipendenze, interfacce pubbliche, copertura dei test e ipotesi ancora da confermare. Le indicazioni di Cursor per la modernizzazione consigliano Plan Mode, .cursor/plans/ e regole di migrazione come .cursor/rules/migration.mdc.
2. Trasformazioni ripetitive e circoscritte
I subagent sono adatti a interventi come l’aggiornamento di chiamate a API deprecate, la conversione di moduli autonomi o la migrazione di servizi con interfacce stabili. Il confine sicuro non coincide semplicemente con il nome di una cartella. Serve invece una porzione di lavoro con:
- Un responsabile e un perimetro di file definiti.
- Un contratto di input/output scritto.
- Un comando per build e test.
- Un branch o un worktree isolato.
- Una definizione chiara di completamento.
La documentazione di Cursor avverte che più subagent che condividono il checkout predefinito possono sovrascriversi a vicenda. Worktree isolati o branch cloud mantengono separate le modifiche finché il coordinatore o una persona non le integra.
3. Code di manutenzione e verifiche in background
Le attività di manutenzione presentano spesso una parallelizzazione naturale: analizzare test instabili, esaminare avvisi sulle dipendenze, aggiornare la documentazione e revisionare una pull request sono lavori che possono procedere separatamente. L’esecuzione in background lascia reattivo il processo principale, mentre i cloud agent possono continuare a lavorare sulle proprie macchine virtuali.
Per le revisioni, la documentazione di Agent Review di Cursor mette a disposizione le modalità Quick e Deep. La revisione Deep è più lenta e costosa, e Cursor la consiglia per la logica complessa, il codice sensibile dal punto di vista della sicurezza e i refactoring di grandi dimensioni. Il workflow Source Control confronta l’intero insieme di modifiche locali con il branch principale, invece di limitarsi all’ultimo intervento.
Questo rende l’architettura utile anche nella manutenzione, ma la revisione deve restare un punto di controllo. Il report positivo di un child agent non equivale a un’integrazione superata con successo né a una pull request approvata.
Dove i workflow con coordinatore e subagent iniziano a rompersi
I contratti trasversali limitano il parallelismo sicuro
Le modifiche a frontend, backend, database e servizi non possono sempre essere eseguite in parallelo solo perché riguardano directory diverse. Un cambiamento allo schema può invalidare un’API; una modifica all’API può rompere i client generati; un’utilità condivisa può far collidere due interventi apparentemente indipendenti.
Una richiesta di funzionalità sul forum di Cursor per un “Monorepo Execution Plan” descrive bene la disciplina che manca: i worker con un perimetro definito dovrebbero ricevere requisiti globali, contratti API e modifiche allo schema, mentre un coordinatore dovrebbe validare route, tipi e schemi prima dell’integrazione. È una proposta degli utenti, non la prova che ogni fase di questo workflow sia già pronta e automatica.
Nelle migrazioni, conviene congelare i contratti prima di avviare gli agenti implementatori. Se un contratto deve cambiare, introducete una fase di compatibilità oppure fate di quel cambiamento la successiva decisione serializzata del coordinatore.
L’isolamento del contesto comporta anche perdita di contesto
I subagent partono da un contesto pulito: non ereditano automaticamente la conversazione dell’agente principale. Il coordinatore deve quindi passare esplicitamente regole pertinenti, pattern di riferimento, vincoli e artefatti. Un breve riepilogo può tralasciare proprio il caso limite che diventerà importante diverse ore dopo.
Meglio usare artefatti persistenti invece di affidarsi alla memoria della conversazione:
migration-plan.mdper perimetro e sequenza.migration-ledger.csvper lo stato dei pacchetti e le eccezioni.contracts/per gli snapshot di API e schema.decisions.mdper le alternative scartate.- Un report dei test allegato a ogni branch di implementazione.
Questo aiuta anche a gestire le decisioni ormai obsolete. Un coordinatore persistente può conservare la cronologia, ma la cronologia non è automaticamente la verità. Le ipotesi vanno rivalutate dopo aggiornamenti delle dipendenze, modifiche allo schema o la scoperta di un comportamento legacy non documentato.
Più agenti possono significare più costi e interferenze
La documentazione di Cursor stima che cinque subagent paralleli utilizzino all’incirca cinque volte i token di un lavoro equivalente svolto da un singolo agente. La stessa documentazione segnala che la scelta del modello può subire un fallback se un amministratore blocca quel modello, se il piano non lo supporta oppure se un piano legacy richiede Max Mode. Il budget non va quindi calcolato considerando soltanto il modello dell’agente principale.
I feedback degli utenti mostrano perché serva un ciclo di controllo esplicito:
“troppo pochi e i messaggi restano accodati per sempre, troppi e iniziano a interferire tra loro” — @siggelabor, X
Una discussione su Reddit racconta di utenti che hanno visto i subagent consumare una quantità inattesa di utilizzo dei modelli e che si sono affidati a .cursorrules per scoraggiare le deleghe, precisando però che la regola non era garantita. Limitate la concorrenza, assegnate modelli meno costosi all’esplorazione, riservate quelli più potenti alla pianificazione e alla revisione, quindi controllate i consumi prima di ampliare l’ondata successiva.
Il superamento dei test non dimostra che la migrazione sia riuscita
Il preprint SWE Refactor Bench è un avvertimento utile per qualsiasi recensione di Cursor Projects. Su 520 esecuzioni relative a 20 attività di migrazione di interi repository, soltanto 28 esecuzioni — il 5,4% — hanno superato l’audit della migrazione, i test comportamentali corretti e la verifica avversaria. Lo studio ha inoltre rilevato che le riscritture di linguaggio hanno ottenuto in media 5,6/100, contro 31,4/100 per le riscritture della toolchain di build.
La lezione è soprattutto metodologica: una migrazione richiede gate separati per verificare sostituzione e conservazione. Bisogna controllare che lo stack precedente sia assente dal codice sorgente e dalla chiusura della build; poi confrontare il comportamento; infine usare una verifica indipendente per individuare differenze nascoste. “La CI è verde” è un segnale, non il verdetto.
Un modo più sicuro per usare Cursor in una migrazione
- Definite la baseline del sistema esistente. Prima di modificare il codice, annotate comandi di build, interfacce pubbliche, output rappresentativi, percorsi sensibili alle prestazioni ed eccezioni note.
- Chiedete a un esploratore in sola lettura di mappare il repository. Includete pacchetti, artefatti generati, configurazione, script di deployment e lacune nei test.
- Create un piano e un registro della migrazione. Dividete il lavoro per comportamento e responsabilità, non soltanto per directory.
- Provate prima una singola porzione autonoma. Usate un’implementazione di riferimento già migrata per definire convenzioni di naming, gestione degli errori, compatibilità e test.
- Avviate implementatori con un perimetro preciso in branch isolati. Inserite in ogni prompt il contratto esatto e i percorsi che non devono essere modificati.
- Eseguite la validazione locale per ogni porzione. Prima di dichiarare il successo, richiedete controlli dei tipi, unit test, test di integrazione, output della build e un riepilogo del diff.
- Eseguite una revisione indipendente. Usate un reviewer con contesto nuovo e scegliete Deep Agent Review per le modifiche ad alto rischio o trasversali.
- Integrate a ondate. Il coordinatore riconcilia i contratti; una persona approva i merge che coinvolgono dati, autenticazione, infrastruttura o API pubbliche.
- Ripetete i controlli differenziali. Confrontate il sistema migrato con la baseline usando input rappresentativi e percorsi di errore.
- Fermatevi quando le evidenze peggiorano. Più parallelismo non significa progresso se aumentano code, conflitti, retry o rilievi in revisione.
Verdetto sulla beta di Cursor Projects in base al tipo di lavoro
| Tipo di lavoro | Adattamento | Raccomandazione |
|---|---|---|
| Modifiche ripetitive su moduli indipendenti | Alto | Usate implementatori paralleli con branch isolati e regole condivise |
| Aggiornamento di dipendenze o framework | Medio-alto | Pianificate prima, provate un modulo pilota e poi procedete per ondate |
| Grande riscrittura di linguaggio con test deboli | Medio-basso | Usate gli agenti per inventario e porzioni circoscritte; mantenete la validazione comportamentale sotto guida umana |
| Migrazione di schema e API tra più servizi | Medio | Serializzate le decisioni sui contratti e parallelizzate l’implementazione solo dopo aver stabilizzato il contratto |
| Manutenzione continua di test, PR e dipendenze | Alto | Usate agenti in background o cloud con limiti di concorrenza e di costo |
| Formattazione occasionale o aggiornamento del changelog | Basso | Usate un comando o una skill: un subagent aggiungerebbe complessità inutile |
| Rinomina massiva deterministica con test solidi | Medio | Preferite script e CI quando la trasformazione è meccanica e facilmente reversibile |
Il mio giudizio è questo: l’architettura di Cursor basata su coordinatore e subagent merita un progetto pilota per le migrazioni di grandi dimensioni quando il repository presenta confini verificabili e il team sa imporre l’isolamento dei branch. In un sistema scarsamente documentato e con una copertura comportamentale debole, il coordinatore dovrebbe occuparsi di inventario e verifiche, non agire da implementatore autonomo.
FAQ sulla beta di Cursor Projects
La beta di Cursor Projects è la stessa cosa dei subagent di Cursor?
La documentazione ufficiale di Cursor è organizzata attorno a subagent, esecuzione asincrona, cloud agent e coding multi-agent; “Projects” è un’etichetta beta il cui ambito può variare in base alla versione e all’account.
I subagent di Cursor possono lavorare in parallelo?
Sì, ma anche le attività indipendenti richiedono perimetri, contratti e worktree isolati definiti esplicitamente per evitare conflitti.
Un subagent può avviare un altro subagent?
Cursor documenta i subagent annidati. Usateli con moderazione, perché alberi più profondi aumentano il carico di coordinamento, il consumo di token e l’overhead di verifica.
Gli agenti continuano a lavorare dopo la chiusura del laptop?
I subagent cloud possono continuare a lavorare sulle proprie macchine virtuali; Cursor precisa che la configurazione MCP locale non viene riutilizzata automaticamente nel cloud.
Posso imporre un modello specifico per ogni subagent?
Cursor supporta modelli ereditati o specifici, ma le regole dell’amministratore, del piano e dei piani legacy possono attivare un fallback: verificate quindi l’utilizzo effettivo.
Come posso impedire ai subagent di avviarne altri?
Usate istruzioni per le attività e regole del repository, poi verificate il comportamento in base al vostro piano e alla vostra versione; i resoconti degli utenti suggeriscono che questi controlli non siano sempre garantiti.
La decisione da prendere prima di attivare uno swarm
Eseguite un progetto pilota di una settimana su una singola porzione della migrazione. Adottate questo approccio solo se le regressioni sfuggite ai controlli non aumentano e il tempo risparmiato supera il lavoro di coordinamento, il tempo dei reviewer e l’overhead legato all’utilizzo dei modelli. In caso contrario, per quel tipo di modifica è preferibile usare script, CI o un singolo agente.