Cursor pubblica i risultati di un esperimento lungo: un sistema di agenti che lavorano in parallelo per ricostruire SQLite da zero in Rust, partendo solo dalla documentazione. L’architettura ha due ruoli: agenti pianificatori con i modelli più costosi che scompongono l’obiettivo in sotto-compiti, e agenti esecutori con modelli economici che li implementano.

Il dato che conta riguarda il costo. Cambiare quali modelli fanno quali lavori non cambia la qualità del risultato finale, ma cambia i costi in modo drastico. Un modello forte che pianifica e uno economico che esegue producono lo stesso output di un modello forte che fa tutto, a una frazione del prezzo.

Cursor attribuisce il guadagno all’efficienza del contesto più che al parallelismo grezzo. Il pianificatore non scrive mai codice, quindi il suo contesto resta libero dai dettagli di basso livello. L’esecutore non pianifica mai, quindi spende tutto il suo contesto su un solo pezzo. La forma del sistema cresce per adattarsi al problema, come un’organizzazione che si divide in unità quando i costi di coordinamento superano il valore del lavoro diretto.

Questo filo lo stavamo seguendo. Il 12 luglio raccontavamo come GPT-5.6 Sol Ultra avesse usato 64 sottoagenti in parallelo per una dimostrazione matematica verificata. Il post di Cursor porta lo stesso principio sul terreno del software e gli dà una cornice economica: quale modello assegnare a quale ruolo, e quanto costa.

Cursor è onesta sui limiti. Il primo swarm aveva costruito un browser “lontano dal software rifinito”. Anche SQLite da zero resta una prova di concetto, non un prodotto pronto.

Nel dettaglio

Da dove viene.

A inizio anno Cursor aveva lanciato un primo swarm con un obiettivo ambizioso: costruire un browser web da zero. L’esperimento era riuscito come prova di concetto, ma il risultato era software grezzo, non rifinito. L’approccio era deliberatamente empirico: partire da una tela bianca e migliorare per tentativi fino a trovare qualcosa di stabile.

Il nuovo lavoro torna su un compito che il vecchio swarm aveva fallito: ricostruire SQLite in Rust a partire dalla sola documentazione. Stesso task, stessi modelli, stesso budget di tempo. Misurano quanto della test suite ufficiale (tenuta da parte, non vista durante lo sviluppo) ciascun sistema supera.

I numeri.

Con Grok 4.5, il nuovo swarm raggiunge l’80% della test suite in quattro ore. Il vecchio swarm doveva essere fermato prima della seconda ora perché “spiraleggiava”. Cursor riporta che ogni configurazione di modelli testata con il nuovo sistema ha battuto il vecchio.

Sul fronte della velocità di esecuzione, Cursor ha costruito un sistema di version control da zero. Il vecchio picco era circa 1.000 commit all’ora con Git. Il nuovo sistema arriva a 1.000 commit al secondo. Il VCS è dove i conflitti diventano visibili, e alcuni meccanismi di coordinamento sono implementati direttamente lì dentro.

Perché il contesto conta più del parallelismo.

La tesi centrale è che il guadagno viene dall’efficienza del contesto, non dal fatto di girare in parallelo. Quando un singolo agente affronta un compito intero, deve tenere in mente l’obiettivo globale, la posizione corrente nell’albero del lavoro e i dettagli di basso livello. Dopo un po’ perde il filo: o si concentra sul pezzo e dimentica il quadro, o tiene il quadro e fa peggio sul pezzo.

Nello swarm, il pianificatore non implementa mai. Il suo contesto resta pulito. L’esecutore non pianifica mai. Il suo contesto è tutto per un pezzo stretto. La forma del sistema cresce per adattarsi al problema, invece di imporre una topologia fissa.

Cursor cita Ronald Coase: le organizzazioni si stratificano in unità con confini perché i costi di coordinamento crescono più in fretta del lavoro. Lo swarm fa la stessa cosa con gli agenti.

Dove si rompe.

A 1.000 commit al secondo, compaiono modi di guasto che i team umani non incontrano.

Il primo è il split-brain: due pianificatori, ignari l’uno dell’altro, implementano lo stesso concetto in due modi diversi in parti diverse del codice. Cursor lo risolve con prompting: i pianificatori prendono le decisioni di design da soli e devono garantire che due sotto-alberi non decidano la stessa domanda.

Il secondo è il conflitto fra pianificatori: due pianificatori che sanno l’uno dell’altro si combattono con modifiche back-and-forth sugli stessi file. Il merge tool non risolve un disaccordo, risolve solo testo. Cursor fa registrare le decisioni in documenti di design condivisi.

Cosa manca.

Il post è onesto sui limiti: il swarm che costruisce SQLite resta una prova di concetto, non software pronto. La “nuova economia dei modelli” è descritta nei risultati (mix diversi, costi diversi, qualità simile) ma i numeri specifici di costo non sono pubblicati nel dettaglio. Per chi costruisce agenti, la direzione è chiara (pianificatore forte + esecutore economico), ma la calibrazione esatta resta da fare sul proprio caso.

Questo conferma un filo che attraversa le ultime settimane: l’orchestrazione conta più del modello. Oggi tre paper convergenti dicevano la stessa cosa con dati di produzione. Il 12 luglio GPT-5.6 Sol Ultra mostrava 64 sottoagenti paralleli per la matematica. Ora Cursor porta l’evidenza empirica sul codice.