Swarms de agentes de Cursor: cómo reconstruyeron SQLite en Rust y qué revela sobre el coste real de los modelos

El artículo, publicado en el blog de investigación de Cursor el 20 de julio de 2026 y firmado por Wilson Lin, describe un experimento de seguimiento a un proyecto anterior de la compañía: un "swarm" (enjambre) de agentes de IA que a comienzos de año había intentado construir un navegador web desde cero. Aquel primer experimento, calificado por la propia Cursor como puramente empírico y construido "a ciegas" mediante ensayo y error, funcionó como prueba de concepto pero produjo software lejos de estar pulido. Desde entonces, el objetivo declarado del equipo ha sido entender lo suficientemente bien el comportamiento de estos enjambres como para poder diseñarlos de forma deliberada, en lugar de dejar que emerjan por tanteo. Para medir ese progreso, retomaron una tarea con la que el swarm original ya había tenido dificultades: construir SQLite —el motor de bases de datos— completamente desde cero, en Rust, usando únicamente su documentación (835 páginas), sin acceso al código fuente original, a los binarios, a los conjuntos de pruebas ni a internet.

Es importante señalar, como marco de lectura, que se trata de un artículo de investigación autopublicado por Cursor en su propio blog corporativo: no es un paper revisado por pares ni un análisis independiente, sino la propia empresa presentando resultados de sus experimentos internos con su propio producto. Esto no significa que los datos sean falsos, pero conviene tenerlo presente al valorar las cifras de rendimiento y coste que se citan, ya que provienen enteramente de sus propias mediciones.

La arquitectura del enjambre se basa en dos roles diferenciados que reflejan la estructura de árbol que adoptan naturalmente las tareas grandes: agentes "planificadores", impulsados por los modelos más potentes, que dividen un objetivo en piezas y las delegan; y agentes "trabajadores", generalmente impulsados por modelos más rápidos y baratos, que ejecutan esas piezas concretas. Según el artículo, este diseño es una superestructura más flexible que los sistemas de orquestación rígidos: en lugar de imponer una topología fija al problema, la forma del enjambre crece para ajustarse a los contornos del problema, y el cómputo y el contexto escalan en proporción a la complejidad de la tarea. Cursor sostiene que este es el motivo por el que el diseño generaliza bien a tareas tan distintas como construir un navegador, resolver problemas matemáticos, optimizar kernels de GPU, encontrar y corregir vulnerabilidades en software de código abierto, aumentar la cobertura de pruebas de su propio código o generar miles de millones de tokens de datos sintéticos de entrenamiento.

Una idea central del artículo es qué aporta esta estructura de árbol a la gestión de la memoria de los agentes. Cuando un único agente asume una tarea completa, tiene que recorrer todo el árbol él solo, descendiendo a cada tarea concreta mientras mantiene en su contexto los antecesores, su posición actual y el objetivo general. Cursor propone que esto explica por qué los agentes individuales que trabajan durante mucho tiempo tienden a "desviarse" (drift): o se concentran en el trabajo inmediato y pierden de vista el panorama general, o mantienen el panorama general y hacen peor el trabajo concreto. En un enjambre, en cambio, un planificador nunca implementa, por lo que su contexto nunca se llena de detalle de bajo nivel, y un trabajador nunca planifica, por lo que puede dedicar todo su contexto a una pieza acotada de trabajo. El artículo sugiere que esta eficiencia de contexto —más que el paralelismo en sí mismo— es lo que permite escalar el enjambre, y que este beneficio aparece a cualquier escala, incluso en tareas de tamaño moderado. Como paralelismo conceptual, citan al economista Ronald Coase y su pregunta sobre por qué existen las empresas: los costes de coordinación crecen más rápido que el propio trabajo, por lo que las organizaciones se asientan en niveles jerárquicos acotados en lugar de dejar que todos hablen con todos.

Otro punto técnico relevante es que Cursor tuvo que construir desde cero un sistema de control de versiones (VCS) propio para el enjambre, porque herramientas como Git o Cargo dependen de bloqueos poco granulares que funcionan bien para un desarrollador humano pero resultan inviables para el volumen de actividad de cientos de agentes concurrentes. Según el artículo, el enjambre del navegador de principios de año alcanzaba un pico de aproximadamente 1.000 commits por hora sobre Git; el nuevo sistema alcanza picos de alrededor de 1.000 commits por segundo. Además de la necesidad de mayor rendimiento, poseer esta capa fue importante porque todo cambio del sistema pasa por el VCS, que es donde las colisiones se hacen visibles por primera vez, y varios de los mecanismos de coordinación del enjambre están implementados directamente ahí.

A ese ritmo de actividad —comentan— aparecen modos de fallo que los equipos humanos de ingeniería, que trabajan a un ritmo mucho más lento, no suelen encontrar, y para los que hicieron falta soluciones específicas:

- Diseño "de cerebro dividido" (split-brain): dos planificadores, sin conocimiento mutuo, implementan el mismo concepto de formas distintas en partes distintas del código. Lo resolvieron mediante instrucciones (prompting): los planificadores toman las decisiones de diseño ellos mismos, en vez de delegarlas, y se les exige garantizar que ningún par de subárboles delegados decida la misma cuestión.

- Contención entre planificadores: una forma más difícil de conflicto surge cuando dos planificadores sí se conocen entre sí y "pelean" mediante cambios sucesivos sobre los mismos archivos. El problema, señalan, son dos visiones distintas de la realidad, algo que ninguna herramienta de fusión de código puede arreglar por sí sola. La solución fue hacer que los agentes registren sus decisiones en documentos de diseño compartidos; el código que depende de una decisión lleva una referencia comprobada por el compilador a ese documento, y cuando los planificadores se contradicen sin saberlo, un agente "reconciliador" fusiona los documentos y esa resolución se propaga después a través de las referencias.

- Conflictos de fusión (merge conflicts): dentro del enjambre los agentes chocan constantemente sobre los mismos archivos, y para resolver una colisión tendrían que detenerse, absorber el contexto del otro agente y fusionar en torno a él; los agentes trabajadores son malos haciendo esto y, en la práctica, o sobrescriben el cambio ajeno o abandonan el propio. La solución fue crear un agente "tercero neutral" que interviene en los conflictos de fusión y los resuelve en nombre de todas las partes, con el único objetivo de ser imparcial y eficiente, de forma similar a como funcionan las colas de fusión (merge queues) en equipos de ingeniería humanos.

- "Megaarchivos": algunos archivos se convierten en lugares especialmente populares donde trabajan muchos agentes; cada uno añade solo una pequeña cantidad de código y ningún agente concreto es responsable de mantenerlos pequeños, de modo que estos archivos gigantes "atascan" todo el sistema: son caros de transportar, comparar (diff) y fusionar, y se convierten en focos constantes de colisiones. La solución fue dar a los trabajadores una manera de marcar archivos hinchados; una vez marcados se bloquean nuevos commits sobre ellos y un agente externo descompone el archivo sobredimensionado en módulos más pequeños.

- Osificación: los agentes han aprendido, de trabajar en bases de código existentes con humanos supervisando, a no tocar el código central aunque necesite cambiar. Cursor decidió "licenciar la rotura intencional": un agente que juzga que vale la pena un cambio central puede hacer un parche focalizado fuera de su ámbito y dejar un comentario explicando por qué lo hizo. El compilador propaga el cambio por el resto del sistema y todo lo que dependía del diseño anterior deja de compilar; cada agente que se topa con uno de esos errores encuentra el comentario, lee el razonamiento y actualiza su propia pieza de trabajo para ajustarse al nuevo diseño.

El artículo dedica también una sección a lo que llaman "lentes de revisión". En un sistema que es a la vez de larga duración y multiagente, los errores se acumulan, y el enjambre necesita corregirse antes de que pequeños fallos se conviertan en cimientos defectuosos. Cursor experimentó con muchos tipos de revisión: dar a un agente revisor la transcripción completa del trabajador, o solo su resultado final, o nada más que el propio código base; también probaron revisores ejecutándose sobre modelos distintos, con entrenamiento y "personalidad" diferentes. Ninguna lente por sí sola detecta todo, pero lentes descorrelacionadas se suman entre sí, de forma similar a como los sistemas de conducción autónoma alcanzan una fiabilidad superior a la humana sin que ningún componente individual sea perfecto. Según el artículo, el cómputo dedicado a la revisión tiene un retorno muy alto, porque revisar es mucho más barato que el trabajo que se audita, y sospechan que este sistema de revisión apilada fue un factor importante en la calidad sostenida de las ejecuciones.

Otro elemento novedoso que describen es dejar que los propios agentes den forma a su entorno de trabajo, inspirándose en la "estigmergia", el mecanismo por el que organismos como hormigas o termitas coordinan su comportamiento sin comunicación directa: modifican el entorno, y el entorno modifica al siguiente organismo. En ejecuciones anteriores ya habían codificado reglas como "toma notas" o "documenta decisiones" porque parecían obviamente buenas; en retrospectiva, según cuentan, estas reglas permitían a los agentes institucionalizar conocimiento para sus futuras versiones y compañeros de equipo. Llevaron esta idea más lejos con un experimento de contexto compartido y autoescrito por los propios agentes, al que llaman "Field Guide" (guía de campo): una carpeta que pertenece enteramente a los agentes, cuyo archivo índice se inyecta automáticamente al inicio de cada agente, y que los propios agentes deben curar, con la única restricción de un presupuesto de líneas. La lógica subyacente es que los pesos del modelo están congelados, así que lo que vale la pena capturar son precisamente los encuentros sorprendentes, para que la trayectoria del siguiente agente sea más corta. Cursor lo describe como un experimento temprano con resultados prometedores, y anticipa beneficios aún mayores en bases de código que los agentes no controlan por completo, apuntando como línea de investigación futura a entrenar modelos específicamente para escribir pensando en sus "sucesores".

El experimento central del artículo consistió en instruir a esta nueva versión del enjambre —con todas las mejoras descritas— para implementar la totalidad del manual de SQLite (835 páginas) en Rust, sin código fuente, sin conjuntos de pruebas, sin el binario original y sin acceso a internet. Para medir el progreso usaron sqllogictest, un conjunto de pruebas del propio proyecto SQLite diseñado para comprobar que distintos motores de bases de datos devuelven los mismos resultados ante las mismas consultas; contiene millones de consultas con respuestas correctas conocidas, y la puntuación es la fracción que la base de datos construida por el enjambre acierta. El swarm nunca fue informado de que ese conjunto de pruebas existiera. Tras cada ejecución revisaron manualmente el código y el proceso, comprobando que no hubiera trampas ni atajos y confirmando que el sistema se hubiera construido de forma pareja y no solo en las zonas que las pruebas evalúan. También destacan que los agentes eligieron sus propias estrategias: algunos construyeron cimientos amplios y puntuaron bajo durante horas antes de un repunte tardío, mientras que otros profundizaron en un área concreta, puntuaron pronto y luego se estancaron mientras rellenaban el resto; según el artículo, las tendencias importan más que las puntuaciones exactas en un momento dado.

Se probaron cuatro configuraciones de modelos, combinando capacidad y coste: (1) GPT-5.5 como planificador y trabajador a la vez, descrito como un modelo frontera potente de principio a fin; (2) Grok 4.5 como planificador y trabajador, presentado como el modelo frontera más eficiente en coste de Cursor, usado como punto de comparación; (3) Opus 4.8 como planificador junto con Composer 2.5 como trabajador, combinando juicio de un modelo frontera con ejecución eficiente; y (4) Fable 5 como planificador junto con Composer 2.5 como trabajador, para comprobar si un planificador de un nivel superior hace que la combinación híbrida sea más o menos rentable. (Opus es la familia de modelos insignia de Anthropic y GPT es de OpenAI; son vínculos de dominio público que el artículo no explicita. La fuente no detalla el origen de Composer 2.5 ni de Fable 5, y se refiere a Grok 4.5 como "nuestro" modelo frontera eficiente en coste).

El nuevo arnés (harness) superó al antiguo en todas las combinaciones probadas. La combinación con Fable 5 superó aproximadamente dos tercios del conjunto de pruebas en la primera hora. Al llegar al límite de cuatro horas, las nuevas ejecuciones se situaron entre el 73% y el 85% de aciertos, frente a un rango de entre el 11% y el 77% en las ejecuciones antiguas; la ejecución antigua con Grok 4.5 tuvo que pausarse antes de alcanzar las dos horas por descontrol del proceso. Cada configuración nueva terminó, más adelante, alcanzando el 100% del conjunto de pruebas. El artículo señala que, para este ciclo, la comparación relevante es entre versiones del arnés (antiguo vs. nuevo) más que entre modelos, y que las diferencias de comportamiento resultaron ser mucho mayores de lo que sugieren las diferencias de puntuación. En una nota al pie, los autores explican que originalmente querían incluir un modelo llamado GPT-5.6 Sol como configuración frontera, pero que ese modelo parecía más sensible a la redacción literal y al énfasis del texto que los demás modelos probados, generando espirales de descontrol ("runaway spirals") no vistas con otros modelos; al no haber tiempo para ajustar las instrucciones a un modelo llegado tan recientemente —y no querer sesgar la comparación ajustándolas solo para uno—, optaron por sustituirlo por GPT-5.5.

El artículo profundiza después en los datos concretos de las ejecuciones. Comparando la actividad de Grok 4.5 bajo el arnés antiguo frente al nuevo: la ejecución antigua produjo 68.000 commits en sus primeras dos horas, un ritmo unas 70 veces superior al de la nueva ejecución. Los autores plantean dos lecturas posibles: que esa actividad fuera más productiva, o que la mayoría de esos commits fueran trabajo improductivo (fricción, contención, churn). Los datos de conflictos de fusión apuntan a la segunda interpretación: la ejecución antigua acumuló más de 70.000 conflictos antes de ser pausada, acelerándose en lugar de estabilizarse, mientras que la nueva registró menos de mil conflictos en sus cuatro horas completas. Los conflictos se concentraban donde los archivos crecían más: en la ejecución antigua, los archivos más grandes siguieron creciendo durante toda la ejecución, y su archivo más conflictivo acumuló 7.771 conflictos, tocado por 1.173 agentes distintos; en la nueva ejecución, el archivo más disputado de toda la base de código registró solo 47 conflictos.

El mayor fallo de coordinación del enjambre antiguo —el "cerebro dividido", es decir, planificadores duplicando el trabajo del otro— se manifestó en la estructura de paquetes (crates, en la terminología de Rust), donde en un proyecto de este tipo cada crate corresponde aproximadamente a un componente principal. La ejecución antigua se dispersó hasta 54 crates, incluyendo tres paquetes SQL independientes; la nueva ejecución se asentó en nueve crates desde el principio y nunca añadió ninguno más. Todo esto se refleja en el tamaño final del código: en la combinación con Fable 5, tanto el enjambre antiguo como el nuevo terminaron superando el conjunto de pruebas completo, pero el antiguo necesitó 64.305 líneas de código de motor frente a las 9.908 del nuevo. La combinación con Opus mostró un patrón similar: 19.013 líneas con una puntuación del 97% bajo el arnés antiguo, frente a 4.645 líneas con el 100% bajo el nuevo.

Una parte especialmente relevante del artículo es la dedicada a la economía de los modelos. Aunque todas las combinaciones de modelos produjeron una calidad similar, los costes variaron enormemente: desde 1.339 dólares en la combinación híbrida de Opus 4.8, hasta 10.565 dólares usando solo GPT-5.5. Los datos de tokens muestran de dónde viene esa diferencia: la estructura del gasto fue consistente en todas las ejecuciones, con los trabajadores acaparando al menos el 69% de los tokens (y más del 90% en la mayoría de los casos); sin embargo, los dólares se repartieron de forma distinta a los tokens porque los tokens del planificador son más caros. En la combinación de Opus 4.8 como planificador y Composer 2.5 como trabajador, Opus produjo una fracción pequeña de los tokens totales pero representó aproximadamente dos tercios del coste, mientras que Composer, como trabajador, gestionó la inmensa mayoría de los tokens por el tercio restante del coste.

Según el artículo, muy pocos momentos de una tarea grande requieren realmente inteligencia de nivel frontera —como la descomposición inicial, las decisiones de diseño o ciertos compromisos (trade-offs)—; una vez que un planificador frontera ha reducido la ambigüedad a una instrucción explícita y detallada, los modelos más baratos simplemente tienen que seguirla, lo que representa una fuente enorme de ahorro potencial de costes. Como ejemplo concreto: en la ejecución donde GPT-5.5 actuó como planificador y trabajador a la vez, solo los trabajadores costaron 9.373 dólares; en la ejecución donde Opus 4.8 planificó y Composer 2.5 trabajó, toda la flota de trabajadores costó 411 dólares. Un detalle adicional que señalan al comparar las dos combinaciones híbridas: el planificador Fable 5 generó una factura ligeramente menor que el planificador Opus 4.8, pese a tener un precio por token aproximadamente el doble, porque usó muchos menos tokens de planificación; sin embargo, los trabajadores de la ejecución con Fable consumieron varias veces más tokens, de modo que esa ejecución en su conjunto resultó sustancialmente más cara.

El artículo cierra con una reflexión conceptual bajo el título "las especificaciones como prompts". Argumenta que cada salto de capacidad en IA ha elevado el nivel de abstracción al que puede trabajar un ingeniero: el autocompletado permitía trabajar línea a línea; los primeros modelos elevaron eso a un bloque de código; los agentes lo elevaron a un archivo o una funcionalidad (feature); y con los enjambres, la unidad de trabajo pasa a ser la especificación (spec) completa. Para que esto funcione, el enjambre tiene que ser capaz de seguir realmente esa especificación, que es de lo que trata gran parte del artículo. Le dieron al enjambre 835 páginas de texto y obtuvieron a cambio una base de datos; lo que resultó escaso en este experimento —y lo que esperan que sea escaso en la ingeniería de software en el futuro— es la descripción correcta de la intención. Vista así, el enjambre empieza a parecerse a un compilador: un compilador traduce el código fuente hacia código máquina a través de una serie de pasos intermedios, y el enjambre hace algo parecido con la intención, donde los planificadores traducen un objetivo en árboles de tareas y luego lo van reduciendo paso a paso a trabajo ejecutable. La diferencia, subrayan, es que un compilador preserva el significado en cada paso, mientras que el enjambre es probabilístico en cada uno de ellos; según los autores, todo lo descrito en el artículo —los sistemas de control de versiones, los mecanismos anticolisión, las lentes de revisión, la guía de campo— existe precisamente para cerrar esa brecha.

Como cierre práctico, Cursor invita a los lectores a explorar por sí mismos el resultado del enjambre: el código de la ejecución en solitario con Opus 4.8 está publicado en el repositorio github.com/cursor/minisqlite. Según indican, a un primer vistazo el resultado "se ve genial", pero aclaran explícitamente que no han hecho un análisis manual más profundo, e invitan a terceros a revisarlo y comunicar lo que encuentren. Además, para tener una referencia del coste de usar modelos frontera en solitario, ejecutaron también Opus 4.8 y Fable 5 por su cuenta; esas ejecuciones solo se calificaron de manera informal, por lo que los autores dicen no extraer conclusiones sobre su calidad, aunque esperarían, por experiencia previa, que ambos modelos rindieran bien; sus costes aparecen representados como barras con trama diferenciada en los gráficos del artículo original.

En conjunto, el artículo defiende una tesis clara y coherente con el título elegido para este resumen de la fuente: la orquestación —cómo se reparten los roles de planificación y ejecución entre agentes, cómo se gestionan las colisiones a gran velocidad, cómo se revisa el trabajo y cómo se comparte el conocimiento entre agentes— puede pesar tanto o más que el tamaño o la potencia bruta del modelo subyacente a la hora de determinar tanto la calidad final del software producido como, sobre todo, su coste. La combinación de un planificador caro pero usado con moderación junto con trabajadores baratos usados en volumen aparece, según sus propios datos, como la vía más económica para obtener resultados equivalentes a los de usar un modelo frontera de punta a punta. Conviene, eso sí, leer estas cifras como lo que son: resultados de experimentos internos de una empresa que vende precisamente herramientas de agentes de codificación, presentados en su propio blog sin revisión externa independiente.