Cursor AI Projects: più agenti, più lavoro da revisionare

Con Cursor Projects, Cursor AI cambia l’unità di lavoro nella programmazione: dal singolo prompt a una coda di attività da revisionare. Il 10 settembre 2026, Cursor ha introdotto in beta un coordinatore, un contesto di progetto condiviso e trigger ricorrenti. I team possono così delegare senza avviare manualmente ogni attività, mentre il collo di bottiglia si sposta sulla definizione dell’ambito, sulla verifica e sulla decisione di cosa integrare.

Questa è una guida operativa per responsabili engineering, founder tecnici e titolari di agenzie. La domanda utile non è quanti agenti Cursor riesca ad avviare. È se il team sappia gestire il lavoro restituito senza perdere il controllo di costi e qualità.

Che cos’è davvero Cursor Projects in Cursor AI

Un Cursor Project è un contenitore persistente per un insieme di attività, come una funzionalità, una migrazione o un’app completa. Al suo interno opera un agente coordinatore, che in questa configurazione svolge il ruolo di responsabile. Pianifica il lavoro e ne delega l’esecuzione, ma non scrive direttamente il codice.

Il codice viene prodotto dagli agenti di implementazione su macchine cloud. Il coordinatore può crearne diversi, farli lavorare in parallelo e riportare i risultati al team per la verifica. Se un test deve essere eseguito su una macchina locale, può avviare lì un agente locale.

Il secondo elemento è il contesto condiviso. Ogni Project conserva file sincronizzati tra il cloud e le macchine locali usate dagli agenti. Questi file possono raccogliere ricerca, artefatti, conoscenza della codebase, istruzioni di test e indicazioni su come il team vuole che il lavoro venga svolto.

Il passaggio di consegne cambia: un nuovo agente non deve più riscoprire ogni volta il comando di test o i confini di un servizio, purché il contesto salvato nel Project sia corretto e aggiornato.

Il terzo elemento sono le sottoscrizioni. Si può chiedere a un Project di monitorare un canale Slack, eseguire attività secondo una pianificazione o seguire le pull request. Quando arriva un segnale corrispondente, può partire nuovo lavoro delegato senza che qualcuno debba scrivere un altro prompt.

Gli agenti ricorrenti non sono una novità assoluta per Cursor. La release del 19 agosto permetteva già ai Cloud Agents di monitorare pull request, thread Slack e pianificazioni. Projects riunisce quel lavoro ricorrente sotto un unico coordinatore, con un contesto condiviso che può accompagnare una sequenza di attività più lunga.

È questo il vero rilascio. Cursor non offre semplicemente un’altra chat per programmare: dà al lavoro delegato uno spazio persistente.

Perché la coda di revisione è il vero impatto sul business

Il contesto condiviso può ridurre la preparazione ripetitiva. Cursor non ha pubblicato dati sull’aumento di velocità e la beta è troppo recente per ricavarne uno: per ora, quindi, non è prudente inserire ore risparmiate in un budget.

Il cambiamento misurabile riguarda la destinazione del tempo del team. Un coordinatore può creare lavoro di implementazione su più corsie parallele, mentre un singolo reviewer continua a leggere le modifiche in sequenza. Questo squilibrio può trasformare un backlog vuoto in una coda piena di pull request.

La coda funziona quando le attività hanno confini stretti, i test sono affidabili e chi revisiona può decidere rapidamente. Diventa costosa quando gli agenti restituiscono diff troppo ampi, lavoro duplicato o modifiche dall’intento poco chiaro. L’output parallelo resta lavoro in attesa finché qualcuno non lo approva.

L’effetto non è uguale per ogni utente di Cursor. Uno sviluppatore indipendente che gestisce una sola attività ben delimitata alla volta potrebbe ottenere poco da un coordinatore. Un team con test deboli o senza un reviewer designato rischia di generare più incertezza che produttività. Chi usa già automazioni ricorrenti con i Cloud Agents beneficia soprattutto del contesto condiviso del Project, non del trigger in sé.

A chi serve e cosa cambia nel lavoro quotidiano

Un responsabile engineering SaaS alle prese con una migrazione

Affidare a un solo Project una migrazione circoscritta, con esclusioni esplicite, comandi di test, regole di rollout e confini di responsabilità. Il coordinatore può distribuire le modifiche meccaniche tra gli agenti di implementazione, mentre il responsabile controlla la sequenza e i punti più rischiosi.

Il vantaggio è la continuità tra più branch. Conviene misurare le modifiche accettate e il tempo di revisione, non l’attività degli agenti.

Un direttore tecnico di agenzia che gestisce progetti cliente

Le note di configurazione, le convenzioni di sviluppo, i percorsi dei test e le regole di consegna di un cliente possono restare nel contesto condiviso del relativo Project. Le attività di manutenzione ricorrenti partono così dalle stesse istruzioni operative, senza un nuovo prompt di onboarding.

Il vantaggio è ridurre i briefing ripetitivi. Il confine da non oltrepassare è la separazione tra clienti: contesto e credenziali di un account non devono mai finire in un bacino comune con quelli di un altro.

Un responsabile del support engineering che monitora le segnalazioni di bug

Collegare un solo canale Slack pubblico dedicato ai bug e applicare una regola di qualificazione restrittiva. Una segnalazione con passaggi riproducibili può entrare nel Project; domande, duplicati e incidenti specifici di un account restano invece in carico a una persona.

Il risultato utile è un branch pronto con le prove necessarie alla revisione, non un merge automatico. L’attuale documentazione sulle Automations di Cursor limita i trigger Slack ai canali pubblici, mentre l’annuncio di Projects non pubblica una matrice separata dei canali supportati.

Un team di piattaforma con manutenzione ricorrente

Un Project può conservare le istruzioni di test e la mappa dei servizi per un flusso di manutenzione ripetuto. Il coordinatore può seguire le pull request o una pianificazione e poi restituire il lavoro di implementazione a un responsabile designato.

Il vantaggio è un ciclo operativo stabile. Un team soggetto a regolamentazione dovrebbe attendere finché la propria verifica di sicurezza non copre il runtime cloud, il contesto sincronizzato, i secret e i controlli della beta.

Come eseguire un test controllato di Cursor AI Projects

Cursor non ha pubblicato né un’API per Projects né una guida dettagliata alla configurazione. Un test corretto deve quindi basarsi sull’interfaccia visibile della beta e sui controlli dei Cloud Agents già documentati.

1. 1

   Verificare accesso e fatturazione

   Cercare Projects nella barra di navigazione sinistra di Cursor. L’annuncio afferma che la beta è in distribuzione a tutti gli utenti, ma i Cloud Agents richiedono ancora un piano a pagamento. Prima di un test di team, verificare il feature flag nell’account effettivo, confermare il tipo di licenza e impostare un limite di spesa per l’intero team prima di aggiungere un trigger ricorrente.

2. 2

   Scegliere un’unica attività ripetibile

   Usare un solo repository e una sola categoria di lavoro a basso rischio, con un criterio di completamento chiaro. I candidati adatti hanno un comando di test noto, un perimetro ridotto per il diff e un responsabile in grado di valutare il risultato. Nel primo test vanno escluse le migrazioni con decisioni di prodotto irrisolte, le modifiche alle autorizzazioni e gli incidenti di produzione.

3. 3

   Scrivere il contesto operativo condiviso

   Inserire nel Project la mappa del repository, i passaggi di configurazione, i comandi di test, la definizione di completamento, le aree vietate e la regola di escalation. Questi file vanno trattati come documenti operativi da manutenere: un contesto condiviso errato non fa che replicare l’errore con maggiore efficienza.

4. 4

   Aggiungere un solo canale di ingresso

   Scegliere una pianificazione, una sottoscrizione alle pull request oppure un canale Slack. Specificare quali segnali sono validi, che cosa può delegare il coordinatore, quali prove deve restituire e quando deve fermarsi senza modificare il codice.

5. 5

   Assegnare un responsabile alla coda di revisione

   Designare un reviewer senior. Prima che una modifica possa procedere, richiedere il diff, l’output dei test e gli artefatti pertinenti. Durante la beta, l’autorità di merge deve restare esterna al Project.

6. 6

   Misurare solo il lavoro che supera la revisione

   Registrare attività avviate, modifiche accettate, minuti di revisione, rilavorazioni, difetti sfuggiti e consumo del modello. Confrontare questi dati con quelli della stessa categoria di attività prima del test. Il numero di agenti non va trasformato in una misura di produttività.

Quanto costa il test, compreso il tempo di revisione

Il piano di base è semplice da quantificare. Teams Standard costa $40 per utente al mese: quattro nuove licenze costano quindi $160 per un ciclo di fatturazione. Teams Premium costa $120 per utente al mese e include un utilizzo cinque volte superiore a Standard, ma acquistarlo prima che il test produca dati reali sui consumi elimina la parte più utile della prova.

La componente variabile è meno immediata. I Cloud Agents vengono addebitati in base ai prezzi API del modello selezionato. Per Teams ed Enterprise si aggiunge un Cursor Token Rate di $0.25 per milione di token di input, output e cache idonei forniti da terze parti. L’utilizzo on demand è attivo per impostazione predefinita su Teams e gli amministratori possono fissare un tetto mensile per l’intero team.

Ecco un modello circoscritto, in cui ogni dato sul carico di lavoro è esplicitamente un’ipotesi:

• Ipotesi sull’ambito: un repository, un trigger e non più di 20 attività che arrivano alla revisione.
• Ipotesi sull’utilizzo: ogni attività completata, comprese le operazioni del coordinatore e degli agenti di implementazione, consuma 100,000 token di input non memorizzati nella cache, 400,000 token letti dalla cache e 20,000 token di output su Claude Sonnet 5, senza token di scrittura nella cache.
• Ipotesi sulla revisione: un reviewer senior riserva 20 minuti per ogni attività restituita, con un costo complessivo di $100 l’ora.

Alle attuali tariffe di Claude Sonnet 5 applicate da Cursor, l’attività ipotizzata costa $0.20 per l’input, $0.08 per le letture dalla cache e $0.20 per l’output. Il token rate del piano Team aggiunge $0.13 sui 520,000 token idonei. Il costo d’uso ipotizzato è quindi $0.61 per attività, pari a $12.20 per 20 attività.

La revisione è la voce più onerosa. Venti attività da 20 minuti ciascuna richiedono 400 minuti, cioè 6 ore e 40 minuti. Con il costo ipotizzato di $100 l’ora, il tempo del reviewer vale $666.67.

Aggiungendo $160 per quattro nuove licenze Standard e includendo il consumo ipotizzato, a prescindere dal fatto che diventi o meno un’eccedenza, il totale lordo pianificato per il mese è $838.87. Non è una previsione di fattura: le licenze esistenti eliminano l’acquisto da $160, l’utilizzo incluso può assorbire i $12.20 e il lavoro reale di Projects potrebbe consumare più token, perché il coordinatore può delegare a diversi agenti.

Lo scopo del modello non è affermare che una revisione costi sempre $666.67, ma rendere il tempo di review una voce di budget autonoma. Prima di definire economico il test, occorre sostituire quantità di attività, minuti e costo complessivo con i dati reali del team.

Per una valutazione più ampia del prodotto e dell’abbonamento, la recensione completa di Cursor analizza l’editor, i Cloud Agents, i prezzi e i controlli di revisione già disponibili.

I limiti da conoscere

Primo: si tratta di una beta in distribuzione, non di uno standard operativo consolidato. L’annuncio cita la barra di navigazione sinistra, ma non fornisce per Projects una matrice di accesso, una ripartizione dei consumi, un controllo della concorrenza o un impegno sul livello di servizio. La disponibilità può quindi precedere la documentazione necessaria agli acquisti.

Secondo: il contesto condiviso trasporta istruzioni obsolete con la stessa facilità con cui distribuisce quelle corrette. Una nota sui test valida il mese scorso può sviare tutti gli agenti futuri dopo una modifica al repository. Ai file di contesto servono responsabili, date di revisione e regole di eliminazione.

Terzo: il coordinatore restituisce lavoro da controllare. È il contratto del prodotto. Non sostituisce la revisione umana, i test eseguibili, i controlli di sicurezza o la responsabilità del merge.

Quarto: è comunque l’ambiente a determinare se un agente può dimostrare la validità del proprio lavoro. I Cloud Agents devono poter accedere a repository, dipendenze, secret, comandi di avvio e rete necessari all’attività. Se la Build di un ambiente non riesce, resta attiva l’ultima Build completata con successo; un ambiente incompleto può però produrre codice plausibile senza prove valide.

Infine, ogni Project viene eseguito su un computer cloud; quando servono test specifici di una macchina, si usano agenti locali. I team con requisiti di rete privata devono includere questo confine nella verifica. Cursor Self-Hosted Machines può trasferire l’esecuzione degli strumenti su worker gestiti dal cliente, ma il ciclo dell’agente Cursor e l’elaborazione del modello rimangono nel cloud di Cursor.

Cosa fare adesso

Conviene agire questa settimana se il team ha attività ripetute e verificabili, un account Cursor a pagamento in cui la beta è visibile e un reviewer senior con spazio nella propria coda. Il punto di partenza è Teams Standard, con un repository, un trigger e un tetto di spesa rigido.

Meglio aspettare se Projects non è visibile, se il repository non riesce a eseguire i controlli nell’ambiente di un Cloud Agent o se nessuno è responsabile della revisione. Occorre attendere anche quando l’ufficio acquisti richiede un documento specifico di Projects su accesso o fatturazione che Cursor non ha pubblicato.

L’impatto è minimo per chi svolge attività una tantum, dispone già di sessioni agente con contesto sufficiente oppure deve necessariamente eseguire tutto in locale. Il coordinatore si giustifica soltanto quando il collo di bottiglia è mantenere la continuità fra più attività delegate.

Il prossimo passo è semplice: scegliere una categoria di attività ricorrente, limitare il test a 20 elementi revisionabili, assegnare un reviewer, impostare il limite di spesa del team e registrare per un ciclo di fatturazione modifiche accettate, minuti di revisione, rilavorazioni, difetti e consumo effettivo. Projects va mantenuto solo se l’output approvato migliora il workflow dopo aver conteggiato sia il costo del modello sia la coda umana.

Ricevi nella newsletter la prossima analisi operativa dei workflow AI.