Radar · 26/07/2026 · coding

Cursor formalizza l'economia degli swarm: pianificatore forte, esecutore economico

Cursor ha messo i suoi swarm di agenti su un compito vero: ricostruire SQLite in Rust usando solo le 835 pagine di documentazione, senza codice sorgente né internet. Il sistema nuovo divide gli agenti in due ruoli: pianificatori con modelli frontier che scompongono il lavoro, ed esecutori con modelli economici che lo portano a termine. Ogni configurazione del nuovo sistema ha raggiunto il 100% della test suite; la versione precedente si fermava fra 11 e 77%.

Perché ti riguarda: l’architettura conta più del modello singolo, e adesso c’è un numero per dimostrarlo. La configurazione ibrida Opus 4.8 come pianificatore e Composer 2.5 come esecutore ha speso 1.339 dollari contro i 10.565 di GPT-5.5 usato da solo, con lo stesso risultato finale (fonte: The Decoder, 26 luglio 2026). Gli esecutori consumano fra il 69 e il 90% dei token in ogni run: è lì che il risparmio si materializza, perché usi il modello costoso solo dove serve giudizio, non dove serve fatica.

Il principio va oltre il codice. Se hai un compito lungo con passaggi ripetitivi, separare chi decide da chi esegue cambia l’equazione costo-qualità. È la stessa direzione di tre paper che raccontavamo il 20 luglio: l’orchestrazione vince sulla potenza grezza.

Nel dettaglio

Il test di Cursor è serio come setup. Gli agenti ricevono il manuale SQLite di 835 pagine e devono produrre un’implementazione in Rust che passi sqllogictest, una suite con milioni di query SQL e risposte note. Niente codice sorgente, niente test suite visibile, niente internet. Quattro configurazioni a confronto: GPT-5.5 da solo, Grok 4.5 da solo, Opus 4.8 come pianificatore con Composer 2.5 come esecutore, e Fable 5 come pianificatore con Composer 2.5 come esecutore.

Dopo quattro ore, le configurazioni del nuovo sistema segnavano fra 73 e 85%, per poi arrivare tutte al 100%. Il vecchio sistema arrivava al massimo al 77% e in un caso si fermava all’11%.

Dove il vecchio sistema falliva. La versione precedente produceva 68.000 commit in due ore, circa 70 volte quelli del nuovo sistema. La maggior parte era lavoro sprecato: oltre 70.000 conflitti di merge accumulati, contro meno di 1.000 nel nuovo. Il problema principale era il cosiddetto “split-brain”: due pianificatori costruivano la stessa idea in posti diversi, con implementazioni diverse. Quando i pianificatori si conoscevano, si bloccavano a vicenda con modifiche in competizione.

Come lo hanno risolto. Gli agenti registrano le decisioni in documenti di design condivisi. Il codice collegato a una decisione porta un riferimento verificato dal compilatore. Quando i conflitti emergono, un agente neutrale li risolve. I file troppo grandi vengono segnalati per la scomposizione in moduli più piccoli.

Un dettaglio interessante è la field guide, una cartella di conoscenza mantenuta dagli agenti stessi con un limite di righe fisso. Ogni agente ne riceve il contenuto all’avvio. Siccome i pesi del modello sono congelati, catturare le scoperte sorprendenti permette agli agenti successivi di prendere scorciatoie. È memoria esterna, non addestramento.

Il costo. I totali vanno dai 1.339 dollari della configurazione Opus ibrida ai 10.565 di GPT-5.5 da solo. Gli esecutori consumano almeno il 69% dei token in ogni run, di solito oltre il 90%. I pianificatori costano di più per token ma ne usano molti meno. L’economia è chiara: spendi dove il giudizio conta, risparmi dove conta la perseveranza.

Un limite di lettura. I numeri vengono dall’implementazione di Cursor su un singolo compito, per quanto ambizioso. SQLite ha una specifica eccellente e una test suite rigorosa: condizioni quasi ideali per un agente. Non è detto che lo stesso vantaggio si mantenga su compiti con requisiti vaghi o documentazione frammentaria. E il fatto che Cursor abbia dovuto costruire un sistema di version control proprietario per gestire 1.000 commit al secondo dice quanto questa architettura sia legata a un’infrastruttura specifica, non replicabile con un prompt.

Se vuoi capire come applicare il principio della separazione fra pianificazione ed esecuzione ai tuoi compiti, la lezione del corso su come orchestrare più agenti parte da qui: ruoli chiari invece di responsabilità duplicate.

Scrivi per cercare fra corso, playbook, skill, paper…