Cursor publica los resultados de un experimento extenso: un sistema de agentes que trabajan en paralelo para reconstruir SQLite desde cero en Rust, partiendo solo de la documentación. La arquitectura tiene dos roles: agentes planificadores con los modelos más costosos que descomponen el objetivo en subtareas, y agentes ejecutores con modelos económicos que los implementan.

El dato que importa es el costo. Cambiar qué modelos hacen qué trabajos no altera la calidad del resultado final, pero transforma los costos de manera drástica. Un modelo fuerte que planifica y uno económico que ejecuta producen el mismo output que un modelo fuerte que hace todo, a una fracción del precio.

Cursor atribuye la ganancia a la eficiencia de contexto más que al paralelismo bruto. El planificador nunca escribe código, así que su contexto se mantiene libre de detalles de bajo nivel. El ejecutor nunca planifica, así que gasta todo su contexto en un solo fragmento. La forma del sistema crece para adaptarse al problema, como una organización que se divide en unidades cuando los costos de coordinación superan el valor del trabajo directo.

Venimos siguiendo este hilo. El 12 de julio contábamos cómo GPT-5.6 Sol Ultra había usado 64 suagentes en paralelo para una demostración matemática verificada. El post de Cursor lleva el mismo principio al terreno del software y le da un marco económico: qué modelo asignar a cada rol, y cuánto cuesta.

Cursor es honesta sobre los límites. El primer swarm había construido un navegador “lejos del software pulido”. También SQLite desde cero sigue siendo una prueba de concepto, no un producto listo.

En detalle

De dónde viene.

A principios de año Cursor había lanzado un primer swarm con un objetivo ambicioso: construir un navegador web desde cero. El experimento había funcionado como prueba de concepto, pero el resultado era software crudo, no pulido. El enfoque era deliberadamente empírico: partir de una tela en blanco y mejorar por ensayo y error hasta encontrar algo estable.

El nuevo trabajo vuelve sobre una tarea que el swarm anterior había fallado: reconstruir SQLite en Rust a partir de solo la documentación. Misma tarea, mismos modelos, mismo presupuesto de tiempo. Miden qué porcentaje de la suite de pruebas oficial (apartada, no vista durante el desarrollo) supera cada sistema.

Los números.

Con Grok 4.5, el nuevo swarm alcanza el 80% de la suite de pruebas en cuatro horas. El swarm anterior tuvo que detenerse antes de la segunda hora porque “entraba en espiral”. Cursor reporta que cada configuración de modelos probada con el nuevo sistema superó al anterior.

En velocidad de ejecución, Cursor construyó un sistema de control de versiones desde cero. El pico anterior era alrededor de 1.000 commits por hora con Git. El nuevo sistema llega a 1.000 commits por segundo. El VCS es donde los conflictos se hacen visibles, y algunos mecanismos de coordinación están implementados directamente ahí.

Por qué el contexto importa más que el paralelismo.

La tesis central es que la ganancia viene de la eficiencia de contexto, no del hecho de ejecutar en paralelo. Cuando un agente individual enfrenta una tarea completa, debe mantener en mente el objetivo global, la posición actual en el árbol de trabajo y los detalles de bajo nivel. Después de un tiempo pierde el hilo: o se concentra en el fragmento y olvida la imagen general, o mantiene la imagen general y lo hace peor en el fragmento.

En el swarm, el planificador nunca implementa. Su contexto permanece limpio. El ejecutor nunca planifica. Su contexto es todo para un fragmento estrecho. La forma del sistema crece para adaptarse al problema, en lugar de imponer una topología fija.

Cursor cita a Ronald Coase: las organizaciones se estratifican en unidades con límites porque los costos de coordinación crecen más rápido que el trabajo. El swarm hace lo mismo con los agentes.

Dónde se rompe.

A 1.000 commits por segundo, aparecen modos de fallo que los equipos humanos no encuentran.

El primero es el split-brain: dos planificadores, ignorantes el uno del otro, implementan el mismo concepto de dos formas diferentes en partes diferentes del código. Cursor lo resuelve con prompting: los planificadores toman las decisiones de diseño solos y deben garantizar que dos subárboles no decidan la misma pregunta.

El segundo es el conflicto entre planificadores: dos planificadores que se conocen se luchan con modificaciones back-and-forth en los mismos archivos. La herramienta de merge no resuelve un desacuerdo, solo resuelve texto. Cursor hace registrar las decisiones en documentos de diseño compartidos.

Qué falta.

El post es honesto sobre los límites: el swarm que construye SQLite sigue siendo una prueba de concepto, no software listo. La “nueva economía de modelos” se describe en los resultados (diferentes combinaciones, diferentes costos, calidad similar) pero los números específicos de costo no se publican en detalle. Para quien construye agentes, la dirección es clara (planificador fuerte + ejecutor económico), pero la calibración exacta queda por hacer en cada caso.

Esto confirma un hilo que atraviesa las últimas semanas: la orquestación importa más que el modelo. Hoy tres papers convergentes decían lo mismo con datos de producción. El 12 de julio GPT-5.6 Sol Ultra mostraba 64 suagentes paralelos para matemática. Ahora Cursor aporta la evidencia empírica en código.