Cursor ha testato uno sciame di agenti aggiornato confrontandolo con il sistema precedente, chiedendo a entrambi di ricostruire SQLite in Rust usando solo la documentazione, senza accesso al codice sorgente o a Internet. Ogni configurazione del nuovo sistema ha infine raggiunto il 100 percento nella suite di test, mentre lo sciame precedente è stato rallentato da numerosi conflitti di merge e da lavoro duplicato.

In Cursor, le flotte di agenti sono passate da progetto di ricerca a prodotto centrale. Con Cursor 3, gli sviluppatori possono eseguire flotte di agenti IA in parallelo. Anysphere, la società dietro Cursor, è stata recentemente acquisita da SpaceX di Elon Musk per $60 billion.

Il sistema separa gli agenti in due ruoli. Gli agenti planner, alimentati da modelli frontier, scompongono ricorsivamente un obiettivo in attività più piccole. Gli agenti worker, che usano modelli più veloci ed economici, completano tali attività. Il processo crea un albero di task che può cambiare man mano che il lavoro procede.

Cursor afferma che questa divisione affronta soprattutto un problema di gestione del contesto. Un singolo agente deve attraversare l’intero albero dei task mantenendo sia l’obiettivo complessivo sia l’attività immediata, il che può contribuire a spiegare perché gli agenti deviano durante lavori di lunga durata. Nel design a sciame di Cursor, i planner non scrivono codice e i worker non pianificano.

Git non riusciva a stare al passo con 1,000 commit al secondo

Un precedente sciame browser di Cursor aveva raggiunto circa 1,000 commit all’ora su Git. Quel sistema usava agenti worker, un agente giudice e un integratore responsabile della risoluzione dei conflitti. Alla fine, l’integratore è diventato più un collo di bottiglia che una soluzione.

Il nuovo sciame ha raggiunto 1,000 commit al secondo. Cursor ha quindi costruito un proprio sistema di controllo versione, affermando che agenti operanti a quella velocità producevano modalità di errore che i team di ingegneria umani normalmente non incontrano. Il risultato rende l’esperimento meno centrato sulla sola generazione grezza di codice e più sulla capacità dell’infrastruttura di sviluppo software di coordinare migliaia di modifiche automatizzate senza collassare in lavoro duplicato.

Un problema era ciò che Cursor ha chiamato "split-brain design". In questo schema, due planner costruivano inconsapevolmente lo stesso concetto in aree diverse della codebase e lo implementavano in modi differenti. La contesa diventava ancora più difficile da gestire quando i planner erano consapevoli l’uno dell’altro e si bloccavano a vicenda con modifiche concorrenti.

Per ridurre questi problemi, Cursor ha fatto documentare agli agenti le decisioni in documenti di progettazione condivisi. Il codice associato a una decisione rimandava al documento pertinente tramite un riferimento verificato in fase di compilazione.

Quando si verificavano conflitti di merge, interveniva un agente neutrale per risolverli. I worker segnalavano inoltre i file troppo grandi affinché un agente esterno potesse suddividerli in moduli più piccoli. Poiché gli agenti avevano imparato a evitare di toccare il codice core mentre lavoravano in codebase esistenti supervisionate da esseri umani, Cursor ha deliberatamente permesso loro di rompere le cose. Un agente poteva correggere codice al di fuori dell’area assegnata, e il compilatore avrebbe propagato la modifica attraverso il sistema.

Cursor ha testato più revisori e una guida operativa mantenuta dagli agenti

Cursor ha valutato diversi metodi di revisione. Un revisore riceveva la trascrizione completa del worker, un altro vedeva solo l’output del worker e un terzo vedeva solo la codebase. Nessun singolo punto di vista individuava ogni problema, ma Cursor ha riscontrato che combinare prospettive non correlate migliorava l’affidabilità.

L’azienda ha anche testato una "field guide", una cartella di conoscenze mantenuta dagli agenti stessi entro un limite fisso di righe. Ogni agente riceveva il contenuto della cartella all’avvio. Poiché i pesi dei modelli sono fissi dopo l’addestramento, Cursor ha affermato che era utile registrare scoperte inattese affinché gli agenti successivi potessero prendere scorciatoie.

Per il benchmark, Cursor ha fornito allo sciame il manuale SQLite di 835 pagine e gli ha chiesto di costruire un’implementazione in Rust. Gli agenti non hanno ricevuto il codice sorgente di SQLite, suite di test, il binario SQLite o accesso a Internet. Il benchmark era sqllogictest, una suite di test contenente milioni di query SQL con risposte note. Lo sciame non sapeva dell’esistenza del benchmark. Questa configurazione ha reso il compito un test di aderenza alle specifiche e integrazione di sistema, più che una traduzione di codice sorgente o un’ottimizzazione specifica per il benchmark.

Cursor ha testato quattro configurazioni: GPT-5.5 solo, Grok 4.5 solo, Opus 4.8 come planner con Composer 2.5 come worker, e Fable 5 come planner con Composer 2.5 come worker. Il nuovo sistema ha superato il vecchio in ogni configurazione. Dopo quattro ore, le nuove esecuzioni hanno ottenuto punteggi tra il 73 e l’85 percento, rispetto all’11-77 percento delle vecchie esecuzioni. Ogni configurazione del nuovo sistema ha poi raggiunto il 100 percento.

Il vecchio sciame generava più lavoro di quanto ne completasse

Le esecuzioni con Grok 4.5 hanno mostrato perché il sistema precedente restava indietro. Il vecchio sciame ha prodotto 68,000 commit in due ore, circa 70 volte più del nuovo sistema. Cursor ha affermato che la maggior parte di quell’attività era sprecata. La vecchia esecuzione ha accumulato oltre 70,000 conflitti di merge, mentre la nuova è rimasta sotto 1,000 per l’intero test.

Il file più conteso nella vecchia esecuzione ha registrato 7,771 conflitti che coinvolgevano 1,173 agenti. Il dato comparabile nella nuova esecuzione era di 47 conflitti. Lo stesso problema di split-brain è apparso anche nella struttura dei pacchetti. La vecchia esecuzione ha diviso il progetto in 54 crate Rust e ha creato tre pacchetti SQL separati, mentre la nuova si è stabilizzata presto su nove crate.

Nella configurazione Fable 5, il vecchio sciame ha richiesto 64,305 righe di codice del motore, contro 9,908 righe per il nuovo sistema. Nella configurazione Opus, il vecchio sistema ha prodotto 19,013 righe e ha ottenuto il 97 percento. Il nuovo sistema ha raggiunto il 100 percento con 4,645 righe. Per Cursor, meno righe e meno conflitti facevano parte dello stesso risultato: lo sciame migliorato ha svolto meno lavoro di implementazione ridondante, raggiungendo al contempo prestazioni di test più elevate.

I modelli worker più economici hanno prodotto la maggiore differenza di costo

I costi totali variavano da $1,339 per la configurazione ibrida Opus a $10,565 per GPT-5.5 eseguito da solo. I worker rappresentavano almeno il 69 percento dei token in ogni esecuzione e di solito oltre il 90 percento. Poiché i token dei planner erano più costosi, la distribuzione dei costi era diversa da quella dei token. Nell’esecuzione ibrida Opus, il planner ha prodotto solo una piccola quota dei token ma ha rappresentato due terzi del conto totale.

La scelta del modello worker ha prodotto il divario di costo più ampio. Nell’esecuzione GPT-5.5, i soli worker sono costati $9,373. Nell’esecuzione che usava Opus e Composer, l’intera flotta di worker è costata $411 a qualità comparabile. Cursor ha attribuito la differenza quasi interamente ai prezzi. Composer 2.5 ottiene benchmark al livello di Opus 4.7 e GPT-5.5, ma costa $0.50 per milione di token di input e $2.50 per milione di token di output. Secondo il fondatore di Cursor Michael Truell, il modello si basa su Kimi K2.5.

Cursor sostiene che solo alcune parti di un’attività ampia richiedono l’intelligenza di un modello frontier, incluse la scomposizione dei task e le decisioni progettuali chiave. Una volta che un planner frontier risolve l’ambiguità, modelli più economici possono seguire il piano. Tuttavia, le esecuzioni ibride hanno anche mostrato che la qualità del planner contava ancora. Il planner Fable 5 ha usato meno token di pianificazione rispetto a Opus, ma i suoi worker hanno richiesto molti più token per completare il lavoro, rendendo l’esecuzione Fable più costosa nel complesso.

Cursor descrive gli sciami come una sorta di compilatore probabilistico che converte l’intento in lavoro eseguibile, un passo alla volta. L’azienda ha affermato che il vincolo principale dell’esperimento era descrivere accuratamente tale intento. Cursor ha pubblicato la codebase dell’esecuzione Opus solo come minisqlite su GitHub.

L’articolo afferma che esecuzioni di questo tipo non sono più limitate agli esperimenti di laboratorio. Una versione prerelease di Fable 5 ha gestito gran parte della riscrittura di Bun da Zig a Rust. Sessantaquattro istanze hanno scritto più di un milione di righe di codice in 11 giorni a un costo di circa $165,000. L’uso in produzione resta diverso: uno studio pubblicato alla fine del 2025 ha rilevato che il 68 percento degli agenti usati in produzione completava non più di dieci passaggi prima dell’intervento di un essere umano. Per il 47 percento, il limite era inferiore a cinque passaggi. Questo contrasto lascia aperta la principale questione pratica: quanta parte del flusso di lavoro controllato e altamente parallelo di Cursor possa trasferirsi in ambienti di produzione, dove gli esseri umani interrompono ancora rapidamente la maggior parte delle esecuzioni degli agenti.