Cursor Projects mette un coordinatore sopra migliaia di agenti di coding

Cursor ha lanciato Cursor Projects in beta il 10 settembre, collocando un agente coordinatore al di sopra di potenzialmente migliaia di subagenti di coding. Il coordinatore non scrive codice: pianifica, delega, monitora i risultati e rimane disponibile mentre gli altri agenti eseguono il lavoro in parallelo.

Questa divisione del lavoro rappresenta la scommessa centrale di Cursor Projects. Gli sviluppatori non dovrebbero più dover supervisionare ogni agente né tradurre un progetto ampio in una sequenza di prompt isolati. Possono descrivere il risultato complessivo e guidare un coordinatore che gestisce il livello esecutivo.

È anche una sfida diretta all'attuale modello di centro di comando per il coding agentico. L'app Codex di OpenAI aiuta gli sviluppatori a gestire più agenti paralleli, mentre Cursor vuole che il proprio coordinatore gestisca quel parallelismo per conto dello sviluppatore. La competizione si sta spostando da un completamento del codice migliore al controllo del lavoro di ingegneria di lunga durata.

Cursor Projects trasforma un obiettivo in un'operazione continua

Il cambiamento importante non è il numero di agenti, ma il nuovo livello che decide cosa debbano fare tutti quegli agenti.

Secondo l'annuncio ufficiale di Projects, gli utenti supervisionano ciascun Project dialogando con un agente coordinatore. Il coordinatore suddivide il lavoro in incarichi e indirizza altri agenti verso ricerca, implementazione, test e revisione del codice.

Cursor afferma che il coordinatore delega il lavoro anziché eseguirlo. Di conseguenza, può rimanere reattivo mentre i subagenti proseguono i propri incarichi. Uno sviluppatore può modificare le priorità o fornire feedback senza dover attendere il completamento di ogni attività attiva.

Ogni Project viene eseguito principalmente nel cloud, sul proprio computer. Il lavoro può continuare dopo che lo sviluppatore ha chiuso il laptop e il sistema può eseguire più agenti di quanti una macchina locale possa ragionevolmente supportare.

L'esecuzione locale rimane parte del progetto. Quando una modifica richiede l'accesso all'ambiente dello sviluppatore, il coordinatore può avviare un agente locale per effettuare test o altro lavoro specifico della macchina.

Projects mantiene inoltre file condivisi tra i computer cloud e locali utilizzati dai suoi agenti. Questi file possono contenere ricerche, artefatti di implementazione, istruzioni di test, dettagli architetturali e preferenze apprese durante lavori precedenti.

Questo contesto condiviso affronta una debolezza ricorrente dello sviluppo agentico. Una nuova sessione di coding spesso inizia con un'altra spiegazione del repository, delle sue convenzioni e del lavoro già completato.

Cursor Projects tratta invece il contesto come una risorsa del progetto. Quando un subagente scopre il modo corretto di testare un servizio, gli agenti successivi possono riutilizzare quelle istruzioni.

Il prodotto introduce anche le subscription, trigger persistenti collegati a eventi o pianificazioni. Un coordinatore può osservare le pull request, monitorare un canale Slack o eseguire un'attività in orari specificati.

Questo modifica l'unità di interazione di base. Lo sviluppatore non sta semplicemente chiedendo a un agente di completare un'attività: sta stabilendo un'operazione che continua a rispondere a nuovo lavoro.

Cursor identifica tre categorie iniziali: sviluppo di funzionalità, migrazioni di grandi dimensioni e manutenzione continua. Ogni categoria va oltre la durata di una normale chat e di solito copre diverse pull request.

Il lavoro sulle funzionalità può iniziare con agenti che analizzano la codebase e registrano le proprie scoperte. Il coordinatore prepara quindi un piano e assegna lavoro di implementazione o testing a più subagenti.

Dopo il rilascio, lo stesso Project può conservare il ragionamento alla base delle decisioni precedenti. Cursor afferma che può monitorare i log e rispondere alle segnalazioni di bug utilizzando quel contesto accumulato.

Le migrazioni seguono un ritmo diverso. Il coordinatore applica gradualmente un approccio concordato, consentendo agli sviluppatori di esaminare attentamente le prime pull request prima di concedergli maggiore margine operativo.

La manutenzione continua, che Cursor chiama gardening, non ha un punto finale definito. Un Project può monitorare regressioni, problemi ricorrenti di qualità del codice o componenti che dovrebbero confluire in un sistema di design condiviso.

Non si tratta di nuove attività di ingegneria. Il cambiamento è che Cursor le presenta come carichi di lavoro persistenti e coordinati anziché come conversazioni separate con singoli agenti di coding.

Come funziona Cursor Projects oltre una singola chat

Il meccanismo di Cursor combina delega, contesto durevole, esecuzione nel cloud e trigger ricorrenti in un unico ciclo di controllo di lunga durata.

Comprendere il funzionamento di Cursor Projects parte dal modello coordinatore-lavoratore. Il coordinatore è responsabile del risultato più ampio, mentre subagenti specializzati gestiscono parti delimitate del lavoro.

Un subagente potrebbe ispezionare un servizio, implementare un componente, eseguire una suite di test o indagare su un errore. Il coordinatore valuta questi output e decide cosa debba accadere in seguito.

Questa architettura consente al lavoro di distribuirsi. Le attività indipendenti possono essere eseguite simultaneamente, mentre quelle dipendenti possono attendere gli input necessari.

La sola esecuzione parallela non risolve il coordinamento di grandi progetti. Più agenti possono anche produrre ricerche duplicate, modifiche incompatibili, assunzioni in conflitto e una coda di revisione più lunga.

Il coordinatore è quindi più importante quando riesce a suddividere il lavoro in modo netto. Deve assegnare obiettivi distinti, preservare le dipendenze e decidere quali output meritino un'ulteriore iterazione.

Anthropic ha documentato insegnamenti simili durante la costruzione del proprio sistema multi-agente. Il suo agente principale delega la ricerca a lavoratori specializzati, ma l'azienda ha rilevato che incarichi vaghi creavano duplicazioni e lacune di copertura.

Anthropic ha inoltre riferito che l'uso parallelo degli strumenti ha ridotto fino al 90% il tempo di ricerca per query complesse. Ha tuttavia sottolineato che la complessità del coordinamento cresce rapidamente con l'aggiunta di agenti a un'attività.

Queste conclusioni si applicano direttamente allo sviluppo software. L'aggiunta di lavoratori aumenta il potenziale throughput, ma aumenta anche il numero di interfacce in cui le assunzioni possono divergere.

Il contesto condiviso di Cursor è pensato per ridurre tale divergenza. Offre agli agenti un luogo persistente in cui conservare conoscenze operative che altrimenti scomparirebbero alla fine di una conversazione.

Il contesto può includere fatti specifici del repository, come comandi di build o requisiti di test. Può anche registrare preferenze, decisioni architetturali e lezioni tratte da approcci falliti.

Questo crea una forma di memoria del progetto. Si distingue dalla finestra di contesto temporanea di un modello perché gli artefatti utili restano disponibili tra agenti e ambienti di esecuzione separati.

Per i team di ingegneria, questa memoria può diventare importante quanto il codice generato. Una modifica priva del suo ragionamento può essere difficile da mantenere, soprattutto quando un altro agente gestisce la modifica successiva.

Il contesto persistente solleva anche una questione di governance. I team dovranno decidere quali istruzioni generate dagli agenti restino affidabili e quando le indicazioni obsolete debbano essere riviste.

Un'istruzione di test errata potrebbe diffondersi negli incarichi futuri. Una nota architetturale obsoleta potrebbe indirizzare diversi subagenti verso la stessa implementazione scorretta.

Projects non elimina dunque il lavoro di documentazione. Cambia chi crea la documentazione, con quale frequenza cambia e quanto direttamente i lavoratori automatizzati dipendano da essa.

Le subscription aggiungono un altro meccanismo. Anziché attendere un prompt dello sviluppatore, un Project può reagire quando si apre una pull request, inizia un controllo pianificato o un messaggio Slack segnala un problema.

Questo rende il coordinatore guidato dagli eventi. Può collegare il lavoro di sviluppo a segnali già presenti nell'ambiente operativo di un team.

Il risultato assomiglia più a una funzione di ingegneria permanente che a un assistente temporaneo. Il Project osserva, assegna lavoro, valuta i progressi e risponde nuovamente quando cambiano le condizioni.

Questa struttura spiega perché Cursor enfatizzi il lavoro che sopravvive a una singola chat. Una piccola modifica raramente richiede un coordinamento persistente, mentre un programma di migrazione o manutenzione sì.

La pressione si sposta dalla velocità di coding al coordinamento

Cursor Projects mette pressione su ogni piattaforma di coding agentico affinché dimostri che agenti paralleli possano produrre sistemi coerenti, non semplicemente più modifiche.

OpenAI ha presentato la propria app Codex come un centro di comando per gestire più agenti di coding. Gli sviluppatori possono eseguire attività in thread separati, ispezionare le modifiche, commentare i diff e lavorare su incarichi paralleli.

Il modello dell'app Codex mantiene lo sviluppatore visibilmente coinvolto nell'orchestrazione di quei thread. Cursor Projects trasferisce una parte maggiore di tale orchestrazione a un agente coordinatore.

Questa distinzione è più importante di un semplice confronto di funzionalità tra Cursor Projects e Codex. Entrambi i prodotti supportano lavoro nel cloud, esecuzione parallela e attività di maggiore durata.

La questione più profonda riguarda dove risieda la responsabilità di gestione. Lo sviluppatore coordina diversi agenti capaci, oppure un agente di livello superiore li coordina sotto la direzione umana?

Cursor privilegia la seconda strada per ampie quantità di lavoro. L'utente guida un coordinatore, e quel coordinatore decide quanti lavoratori creare e dove distribuirli.

L'approccio può ridurre il sovraccarico umano di pianificazione. Gli sviluppatori non devono creare manualmente un thread separato per ogni area del repository, errore di test o opzione di implementazione.

Può anche rendere il sistema più difficile da ispezionare. Quando la delega diventa ricorsiva, il percorso da una richiesta umana a una modifica specifica del codice si allunga.

Un'interfaccia da centro di comando espone le singole attività più direttamente. Un'interfaccia guidata da coordinatore può nascondere tale complessità, ma la complessità nascosta non scompare.

Questa tensione influenzerà i confronti tra Cursor Projects e Codex più dei benchmark grezzi sui modelli. I team devono sapere come ciascun sistema delimiti il lavoro, renda visibili le decisioni, gestisca i conflitti e supporti la revisione.

Anche l'impostazione di Cursor riflette questo cambiamento. A febbraio l'azienda ha descritto una “terza era” dello sviluppo software, incentrata su flotte di agenti che gestiscono interi corpi di lavoro.

La sua precedente ricerca sulla scalabilità degli agenti ha esaminato centinaia di agenti concorrenti al lavoro su un unico progetto. Quegli esperimenti hanno coinvolto oltre un milione di righe di codice generate e trilioni di token.

La scala della ricerca non si traduce automaticamente in affidabilità in produzione. Mostra però che Cursor ha studiato il coordinamento come un problema ingegneristico separato.

OpenAI persegue la stessa destinazione più ampia partendo da una diversa direzione d'interfaccia. I suoi materiali su Codex enfatizzano agenti paralleli, ambienti isolati, organizzazione dei progetti, skill e automazioni in background.

Entrambe le aziende stanno andando oltre la chat con un singolo agente. La questione ancora aperta è quanta astrazione gli sviluppatori accetteranno prima di sentirsi scollegati dal codice e dal suo ragionamento.

La pressione competitiva si estende inoltre oltre Cursor e OpenAI. Qualsiasi piattaforma di coding costruita attorno a un agente interattivo deve ora rispondere a richieste che attraversano mesi, repository ed eventi operativi ricorrenti.

Un modello valido può completare un'attività isolata. Un sistema di progetto durevole deve preservare le priorità, recuperare dagli errori, integrare i risultati e decidere quando chiedere aiuto a una persona.

Si tratta di una categoria di prodotto diversa. La qualità del modello resta essenziale, ma orchestrazione, memoria, isolamento, osservabilità e controlli di revisione determinano sempre più se il sistema funzioni in produzione.

Gli sviluppatori continueranno a preoccuparsi della qualità e della velocità del codice. Gli acquirenti aziendali chiederanno anche chi possa tracciare una decisione, limitare l'accesso di un agente e interrompere un processo errato.

Cursor Projects alza queste aspettative senza però risolverle. La sua beta offre a Cursor l'opportunità di dimostrare se lo sviluppo guidato da un coordinatore possa funzionare al di fuori di progetti interni attentamente osservati.

I risultati interni di Cursor sono promettenti, ma non costituiscono una prova indipendente

Cursor ha pubblicato dati di adozione notevoli, ma tali dati misurano l'attività all'interno di Cursor anziché miglioramenti verificati nella qualità del software.

Cursor afferma di aver utilizzato Projects internamente per diversi mesi. I carichi di lavoro riportati includono l'adozione di framework, la sostituzione di sistemi di styling, la distribuzione di funzionalità e la manutenzione di design system attraverso numerose pull request.

L'azienda riferisce che i nuovi utenti di Projects integrano il 30 percento di pull request in più. Afferma inoltre che le persone che utilizzano principalmente Projects integrano un numero di pull request sei volte maggiore.

Questi numeri meritano un'interpretazione prudente. Nel suo annuncio, Cursor non ha pubblicato la dimensione del campione, il periodo di osservazione, il metodo di controllo, il mix di repository o i dettagli statistici.

Il volume delle pull request misura inoltre la produttività, non necessariamente il valore. Un numero maggiore di modifiche integrate può indicare una consegna più rapida, ma questa metrica non rivela i tassi di difetti, la frequenza dei rollback, il carico delle revisioni o i costi di manutenzione.

Gli effetti di selezione potrebbero influenzare il confronto. Gli ingegneri che adottano Projects più intensamente potrebbero lavorare su attività facilmente suddivisibili tra agenti oppure essere già a proprio agio nella gestione dell'automazione.

I dati di Cursor dovrebbero quindi essere considerati prove interne relative al prodotto. Sostengono la necessità di ulteriori test, ma non dimostrano un aumento generale della produttività per ogni organizzazione di ingegneria.

L'esempio del design system è più concreto. Cursor afferma che un Project interno analizza le nuove pull request, estrae componenti e crea regole di lint dopo aver rilevato lo stesso errore due volte.

L'azienda prevede che quel Project intervenga su un numero compreso tra 20 e 100 pull request al giorno. Inizialmente un ingegnere umano revisionava ogni correzione, riducendo poi la supervisione man mano che il sistema migliorava.

Questa progressione illustra il modello di fiducia previsto da Cursor. I team iniziano con una revisione ravvicinata, osservano se le correzioni tengono e ampliano gradualmente l'autonomia.

Rivela anche il carico di lavoro che Projects potrebbe creare. Un sistema che interviene su 100 pull request al giorno può sovraccaricare i revisori se le sue modifiche sono rumorose, ridondanti o difficili da prioritizzare.

I conflitti di merge creano un ulteriore rischio. Subagenti paralleli possono lavorare in modo produttivo su aree indipendenti, ma le modifiche sovrapposte richiedono coordinamento sia a livello di codice sia di intento.

I test non risolvono completamente questo problema. Due modifiche possono superare i rispettivi test locali pur producendo un'interazione indesiderabile dopo l'integrazione.

Anche i confini di sicurezza sono importanti. Un coordinatore persistente può accedere al codice sorgente, alle macchine locali, alle pull request, ai messaggi Slack, ai log e ai segnali relativi al deployment.

Ogni connessione amplia il contesto utile del sistema. Ognuna amplia anche le conseguenze di istruzioni errate, autorizzazioni eccessive o input compromessi.

I trigger basati su abbonamento richiedono particolare attenzione. Un messaggio dannoso o fuorviante in un canale monitorato potrebbe tentare di influenzare un agente, a meno che il sistema non separi i contenuti non attendibili dalle istruzioni autorizzate.

I team avranno bisogno di regole chiare su ciò che il coordinatore può leggere, sulle azioni che può avviare e sulle modifiche che richiedono sempre approvazione. Le tracce di audit devono collegare il lavoro delegato all'evento che lo ha attivato.

La memoria a lungo termine presenta una sfida correlata. Il contesto condiviso diventa più utile nel tempo, ma un contesto errato può anch'esso persistere e influenzare il lavoro futuro.

Le organizzazioni hanno bisogno di modi per ispezionare, rivedere, far scadere e attribuire le istruzioni memorizzate. In caso contrario, la memoria di progetto rischia di diventare un livello di configurazione opaco.

Cursor ha descritto in precedenza l'obiettivo delle codebase a guida autonoma, in cui gli agenti possono integrare modifiche, gestire i rollout e monitorare la produzione. Projects avvicina questa visione a un prodotto rivolto agli utenti.

Tuttavia, il linguaggio della guida autonoma non dovrebbe oscurare la responsabilità. Il software di produzione continua a comportare conseguenze per la sicurezza, l'affidabilità, il diritto e i clienti, che restano in capo all'organizzazione che lo distribuisce.

Il vero test della beta non è se il coordinatore possa generare molte pull request. È se i team possano comprendere tali modifiche e mantenere fiducia man mano che il lavoro delegato cresce di scala.

Le grandi migrazioni offrono il primo test più chiaro

Le migrazioni forniscono il caso d'uso iniziale più solido perché combinano lavoro ripetibile, progressi misurabili e punti naturali per la revisione umana.

Una grande migrazione contiene spesso centinaia di modifiche correlate. I team potrebbero dover sostituire un framework, aggiornare un'API, rimuovere un sistema di styling o applicare una nuova convenzione del repository.

Le prime modifiche richiedono riflessioni attente. Gli ingegneri devono identificare i casi limite, stabilire il modello desiderato e confermare che i test rilevino regressioni significative.

Le modifiche successive spesso ripetono il metodo stabilito. Ciò rende il lavoro adatto a un coordinatore che possa assegnare aree ristrette del repository a subagenti separati.

Cursor afferma che i suoi team hanno utilizzato Projects per migrazioni che comprendevano centinaia di pull request. Gli sviluppatori revisionano attentamente il lavoro iniziale, quindi riducono l'intervento quando l'approccio dimostra di essere stabile.

Questo è più adatto che chiedere contemporaneamente a migliaia di agenti di inventare un'unica funzionalità strettamente interconnessa. Le attività di migrazione hanno spesso confini più chiari e criteri di completamento più oggettivi.

Anche i progressi sono visibili. I team possono contare moduli migrati, errori irrisolti, correzioni richieste durante la revisione, conflitti di merge e regressioni dopo il deployment.

Queste misure aiutano le organizzazioni a valutare come Cursor Projects funzioni nella pratica. Rivelano se la maggiore produttività degli agenti riduca il tempo trascorso oppure sposti semplicemente l'impegno verso revisione e pulizia.

Lo sviluppo di funzionalità è un test più difficile. Le funzionalità contengono decisioni di prodotto ambigue, requisiti in evoluzione, compromessi nell'esperienza utente e dipendenze che emergono durante l'implementazione.

Un coordinatore può parallelizzare ricerca, prototipazione, test e lavoro sui componenti. Ha comunque bisogno di un'escalation affidabile quando i subagenti incontrano ipotesi incompatibili.

Il sistema deve anche preservare un intento di prodotto coerente. Una raccolta di componenti tecnicamente corretti non garantisce una funzionalità utile o comprensibile.

La manutenzione continua è ancora più difficile perché manca di un naturale punto di arrivo. Il coordinatore deve distinguere il lavoro preventivo di valore da un'attività infinita a bassa priorità.

Un Project che osserva ogni pull request può identificare schemi ripetuti. Tuttavia, può anche creare rumore di automazione o affrontare ripetutamente i sintomi invece dei problemi di progettazione sottostanti.

I team che valutano la beta dovrebbero iniziare con carichi di lavoro delimitati e reversibili. Una migrazione con codemod, l'espansione dei test o una pulizia del design system con ambito ristretto offrono risultati osservabili.

Dovrebbero registrare più dei conteggi di merge. Tra le misure utili figurano il tempo di revisione umana, la frequenza delle correzioni, i difetti riaperti, il tasso di rollback, il lavoro duplicato e il consumo totale di calcolo.

Il team dovrebbe inoltre definire condizioni di arresto prima di aumentare l'autonomia. Una soglia per test falliti, accesso inatteso ai file, correzioni ripetute in fase di revisione o conflitti di merge può attivare l'intervento umano.

La memoria di progetto merita una revisione attiva durante questi piloti. Gli ingegneri dovrebbero ispezionare ciò che gli agenti memorizzano e confermare che il contesto condiviso rifletta le pratiche correnti del repository.

Questo lavoro si collega naturalmente a una base di conoscenza ingegneristica. Il contesto generato dagli agenti diventa più utile quando i team possono confrontarlo con documentazione tecnica autorevole.

Una migrazione riuscita fornirebbe prove più solide di una dimostrazione ben rifinita. Mostrerebbe che il coordinatore può preservare un approccio unico attraverso molte modifiche senza perdere il controllo della qualità dell'integrazione.

Queste prove chiarirebbero anche la questione Cursor Projects rispetto a Codex. I team potrebbero confrontare la delega guidata da un coordinatore con attività parallele assegnate manualmente usando lo stesso repository e gli stessi standard di revisione.

Il sistema migliore non genererà necessariamente la maggior quantità di codice. Ridurrà lo sforzo totale necessario per ottenere un risultato stabile, comprensibile e manutenibile.

Cosa determinerà se Cursor Projects potrà scalare

Tre segnali determineranno se Projects diventerà un livello di controllo per l'ingegneria o resterà una beta impressionante per lavori insolitamente strutturati.

Il primo segnale è costituito da prove di produzione indipendenti. Cursor ha condiviso dati interni sulle pull request, ma i team esterni devono riportare tassi di difetti, impegno di revisione e tempi di consegna.

Le prove più solide proverranno da progetti con conseguenze operative reali. Grandi migrazioni, funzionalità multi-servizio e programmi di manutenzione persistente dovrebbero produrre confronti misurabili prima e dopo.

Se i team consegnano più rapidamente senza aumentare regressioni o carico di revisione, il modello di coordinatore di Cursor acquisisce credibilità. Se il volume di merge aumenta mentre cresce il lavoro di pulizia, l'affermazione centrale si indebolisce.

Il secondo segnale è una migliore osservabilità e governance. Gli sviluppatori devono poter vedere perché il coordinatore ha creato un'attività, quale contesto ha utilizzato e in che modo un risultato ha influenzato le decisioni successive.

Gli amministratori hanno inoltre bisogno di confini autorizzativi per macchine cloud, agenti locali, repository, sistemi di comunicazione e segnali di deployment. L'automazione persistente non può dipendere da una fiducia indiscriminata.

Controlli utili includerebbero tracce di delega, politiche di approvazione, cronologie del contesto, limiti delle risorse e meccanismi di interruzione chiari. Queste funzionalità determinano se le aziende possano gestire il coordinatore come infrastruttura.

Se Cursor renderà comprensibile la delega ricorsiva, potrà preservare la comodità dell'astrazione senza costringere i team a rinunciare alla visibilità. Controlli deboli limiterebbero l'adozione ai repository a minor rischio.

Il terzo segnale è la risposta delle piattaforme concorrenti. OpenAI supporta già agenti Codex paralleli e sta sviluppando automazioni in background collegate a trigger cloud.

Un passaggio verso una delega gestita dagli agenti convaliderebbe l'inquadramento del mercato proposto da Cursor. Una continua enfasi sull'orchestrazione umana diretta manterrebbe una differenza significativa tra i prodotti.

Anche il lavoro di Anthropic fornisce un importante riferimento tecnico. La sua ricerca su orchestratore e worker mostra sia i vantaggi prestazionali degli specialisti paralleli sia la rapida crescita dei problemi di coordinamento.

I concorrenti non devono copiare l'interfaccia di Projects. Possono sfidare Cursor offrendo flussi di revisione più solidi, un'esecuzione più sicura, una tracciabilità delle attività più chiara o una memoria di progetto più affidabile.

Cursor Projects non è quindi semplicemente un'altra release di un agente di coding. È una proposta per riorganizzare il rapporto tra sviluppatori e lavoratori automatizzati.

Lo sviluppatore si sposta di un livello sopra le singole attività di implementazione. Il coordinatore diventa responsabile della scomposizione, della pianificazione, della continuità e dell'azione ricorrente.

Questo modello esercita un'attrattiva evidente per migrazioni e programmi di manutenzione che i team faticano a completare. Concentra però anche più capacità di giudizio all'interno di un sistema le cui decisioni possono moltiplicarsi tra molti subagenti.

La beta avrà successo quando i team potranno delegare risultati più ampi senza perdere il ragionamento, i controlli e la responsabilità alla base del codice. La sola scala non dimostrerà questo risultato.

Gli sviluppatori che valutano Cursor Projects dovrebbero scegliere un carico di lavoro delimitato, definire misure di qualità e osservare dove si sposta effettivamente l'attenzione umana. Il coordinatore elimina il lavoro di coordinamento oppure lo trasferisce nella revisione, nella manutenzione del contesto e nella risposta agli incidenti?

Quella risposta conta ben oltre Cursor. Indicherà se la prossima fase dello sviluppo dell’AI apparterrà a persone che gestiscono molti agenti o ad agenti coordinatori che li gestiscono al posto nostro.