Por Canuto  

Los nuevos enjambres de agentes de Cursor lograron reconstruir SQLite en Rust y alcanzar 100% en las pruebas, mientras reducían conflictos, código y costos. El experimento sugiere que los modelos más costosos podrían reservarse para planificar, dejando la ejecución cotidiana a sistemas mucho más baratos.
***

  • El nuevo sistema de Cursor separa a los modelos de frontera, que planifican, de trabajadores más baratos que ejecutan las tareas.
  • Las nuevas configuraciones llegaron a 100% en la suite sqllogictest y redujeron hasta 85% el tamaño de la base de código.
  • El híbrido con Opus 4.8 y Composer 2.5 costó USD $1.339, frente a USD $10.565 de GPT-5.5 funcionando en solitario.

Cursor puso a prueba una nueva arquitectura de enjambres de agentes de inteligencia artificial con una tarea especialmente exigente: reconstruir SQLite en Rust usando únicamente su documentación. Los agentes no tuvieron acceso al código fuente, a las suites de pruebas originales, al binario de SQLite ni a Internet.

El experimento comparó el sistema actualizado con un enjambre anterior que sufría conflictos de fusión y generaba grandes volúmenes de trabajo desperdiciado. Según The Decoder, las nuevas configuraciones alcanzaron posteriormente 100% en la suite de pruebas, mientras el diseño anterior se estancó por sus propios problemas de coordinación.

Un enjambre dividido entre pensar y ejecutar

Cursor organiza su nuevo sistema en dos roles definidos. Los agentes planificadores utilizan modelos de frontera para descomponer un objetivo amplio en tareas pequeñas, mientras los agentes trabajadores emplean modelos rápidos y baratos para completar esas instrucciones.

La compañía sostiene que esta separación resuelve principalmente un problema de contexto. Un agente solitario debe recorrer todo el árbol de decisiones y recordar al mismo tiempo el objetivo general, la tarea actual y los detalles acumulados durante trabajos prolongados.

Cuando esa carga se concentra en una sola instancia, aumenta el riesgo de que el agente se desvíe. En el diseño de Cursor, los planificadores no escriben código y los trabajadores no toman decisiones de planificación, lo que limita la mezcla de responsabilidades.

El resultado es un árbol de tareas que puede adaptarse mientras avanza el trabajo. Cada decisión permite abrir nuevas tareas, corregir instrucciones o redistribuir esfuerzos sin exigir que todos los agentes conozcan la totalidad del proyecto.

Cursor describe este enfoque como una especie de compilador probabilístico. La intención del usuario entra como una especificación amplia y el sistema intenta transformarla, paso a paso, en trabajo ejecutable.

Para la empresa, la principal restricción no está necesariamente en la capacidad de escribir código. El reto consiste en expresar la intención con suficiente precisión para que las distintas instancias ejecuten una estrategia coherente.

Del cuello de botella de Git a un sistema propio

El enjambre de navegador anterior de Cursor alcanzaba cerca de 1.000 commits por hora en Git. Su arquitectura incluía agentes trabajadores, un agente juez y un integrador encargado de resolver los conflictos.

Sin embargo, el integrador terminó creando más cuellos de botella de los que eliminaba. El nuevo sistema llegó a unos 1.000 commits por segundo, una velocidad que expuso modos de falla poco comunes en equipos humanos.

Ante ese volumen, Cursor construyó su propio sistema de control de versiones. La empresa necesitaba coordinar cambios generados a una velocidad capaz de superar los supuestos habituales de las herramientas creadas para equipos de desarrolladores.

Uno de los problemas recibió el nombre de diseño de cerebro dividido. Dos planificadores podían concebir la misma idea sin saberlo y luego implementarla de maneras diferentes en lugares distintos del proyecto.

La situación empeoraba cuando los planificadores conocían el trabajo de los demás. En esos casos, podían bloquearse mutuamente mediante ediciones competitivas que aumentaban la complejidad en lugar de acercar el proyecto a una solución.

Cursor respondió haciendo que los agentes registraran sus decisiones en documentos de diseño compartidos. El código relacionado con cada decisión regresaba al documento mediante una referencia verificada durante la compilación.

Cuando aparecía un conflicto de fusión, un agente neutral intervenía para resolverlo. Además, los trabajadores podían señalar archivos demasiado grandes para que otro agente los dividiera en módulos más pequeños.

La estrategia también cambió la relación de los agentes con el código existente. Como habían aprendido a evitar modificar el núcleo en proyectos con humanos involucrados, Cursor les permitió romper partes del sistema de manera deliberada durante este experimento.

Un agente podía aplicar parches fuera de su área asignada y dejar que el compilador propagara el cambio por el sistema. La empresa buscaba que la arquitectura tolerara experimentos controlados sin depender de una disciplina rígida en cada modificación.

Revisiones desde varios ángulos

Cursor probó distintos métodos para revisar el trabajo de los agentes. Un revisor recibió la transcripción completa del trabajador, otro observó solamente el resultado y un tercero examinó únicamente la base de código.

Ninguna perspectiva individual detectó todos los problemas. No obstante, la empresa encontró que la combinación de perspectivas no correlacionadas ofrecía mayor confiabilidad que confiar en un solo tipo de revisión.

El sistema también utilizó una guía de campo, una carpeta de conocimiento mantenida por los propios agentes y limitada a un número fijo de líneas. Cada instancia recibía ese material al comenzar su trabajo.

La guía buscaba conservar hallazgos inesperados para que los agentes posteriores pudieran aprovecharlos. Como los pesos de los modelos permanecen congelados durante el experimento, el conocimiento compartido funciona como una memoria externa y actualizable.

Cursor entregó al enjambre el manual de SQLite, con 835 páginas, y le pidió que construyera una implementación en Rust. El estándar de evaluación fue sqllogictest, una suite con millones de consultas SQL y respuestas conocidas.

El enjambre no sabía que esa suite existía. La prueba, por tanto, no consistía en ajustar el código a un conjunto de validaciones previamente conocido, sino en deducir el comportamiento esperado a partir de la documentación disponible.

La empresa evaluó cuatro configuraciones. Probó GPT-5.5 en solitario, Grok 4.5 en solitario, Opus 4.8 como planificador con Composer 2.5 como trabajador y Fable 5 como planificador con Composer 2.5 como trabajador.

Después de cuatro horas, las nuevas ejecuciones obtuvieron entre 73% y 85%, mientras que las antiguas se ubicaron entre 11% y 77%. Posteriormente, cada configuración del sistema nuevo alcanzó 100% en las pruebas.

El costo de crear trabajo desperdiciado

Las ejecuciones con Grok 4.5 mostraron por qué el enjambre anterior quedó rezagado. En dos horas, ese sistema produjo 68.000 commits, aproximadamente 70 veces más que el diseño actualizado.

La actividad adicional no representó una mayor productividad. El sistema antiguo acumuló más de 70.000 conflictos de fusión, mientras que el nuevo se mantuvo por debajo de 1.000 durante toda la prueba.

El archivo que recibió más disputas en la ejecución anterior registró 7.771 conflictos provocados por 1.173 agentes. En la nueva ejecución, el mismo problema produjo 47 conflictos.

La arquitectura anterior también fragmentó de forma excesiva la estructura del paquete. Terminó dividiendo el proyecto en 54 crates de Rust y creó tres paquetes SQL separados.

El nuevo enjambre se estableció desde el comienzo en nueve crates. Esa decisión redujo la complejidad organizativa y disminuyó la cantidad de puntos donde podían aparecer implementaciones duplicadas o incompatibles.

La diferencia también apareció en el volumen del código. En la configuración con Fable 5, el enjambre antiguo necesitó 64.305 líneas del motor, mientras que el nuevo utilizó 9.908.

En la configuración con Opus, el sistema anterior generó 19.013 líneas y obtuvo 97%. El nuevo alcanzó 100% con 4.645 líneas, una reducción significativa con resultados de prueba superiores.

En conjunto, Cursor afirmó que la nueva arquitectura redujo el tamaño de la base de código hasta 85% con puntuaciones iguales o mejores. La cifra sugiere que la coordinación puede importar más que el volumen bruto de cambios.

El antiguo enjambre produjo más actividad visible, pero esa actividad se convirtió en conflictos, duplicaciones y estructuras innecesariamente grandes. El nuevo diseño buscó producir menos cambios, aunque con una relación más clara entre cada tarea y el objetivo final.

Modelos baratos para la mayor parte del trabajo

Los costos totales de las ejecuciones oscilaron entre USD $1.339 para el híbrido de Opus y USD $10.565 para GPT-5.5 funcionando en solitario. La diferencia fue de casi 15 veces, pese a que los resultados fueron comparables.

Los trabajadores representaron al menos 69% de los tokens utilizados en cada ejecución. En la mayoría de los casos superaron 90%, porque las tareas de implementación requieren muchas más interacciones que la planificación inicial.

El consumo de tokens no determinó por sí solo la factura. Los tokens del planificador fueron más costosos, por lo que una parte pequeña del uso total podía explicar una proporción elevada del gasto.

En el híbrido de Opus, el planificador produjo una fracción reducida de los tokens, pero representó dos tercios de la factura total. La arquitectura, por tanto, no elimina el valor de los modelos caros, sino que intenta concentrarlo en decisiones concretas.

El modelo trabajador generó la brecha económica más amplia. En la ejecución de GPT-5.5, los trabajadores costaron USD $9.373 por sí solos, mientras toda la flota de trabajadores Composer 2.5 costó USD $411 en la configuración con Opus.

Composer 2.5 tiene un desempeño descrito como comparable al de Opus 4.7 y GPT-5.5, pero su precio es de USD $0,50 por millón de tokens de entrada y USD $2,50 por millón de tokens de salida.

Michael Truell, fundador de Cursor, indicó que Composer 2.5 se basó en Kimi K2.5. El dato ilustra cómo modelos con costos menores pueden ocupar el nivel de ejecución sin asumir las decisiones arquitectónicas más ambiguas.

Cursor sostiene que solo algunas partes de una tarea grande requieren la inteligencia de un modelo de frontera. Entre ellas están la descomposición del trabajo y las decisiones de diseño clave.

Una vez resuelta la ambigüedad, modelos más baratos pueden seguir el plan. Sin embargo, las ejecuciones híbridas mostraron que la calidad del planificador todavía importa, porque una instrucción menos precisa obliga a los trabajadores a gastar más tiempo y tokens.

Fable 5 utilizó menos tokens de planificación que Opus, pero sus trabajadores necesitaron muchos más tokens para terminar la implementación. La ejecución de Fable terminó siendo más costosa en general.

Una tecnología prometedora con límites actuales

La experiencia de Cursor no significa que todos los proyectos puedan automatizarse de inmediato. Un experimento controlado con documentación completa difiere de una base de código empresarial, donde existen requisitos cambiantes, secretos operativos y decisiones humanas difíciles de formalizar.

La propia evidencia sobre el uso productivo mantiene una perspectiva prudente. Un estudio publicado a finales de 2025 encontró que 68% de los agentes utilizados en producción no completaron más de diez pasos antes de que interviniera una persona.

Para 47% de esos agentes, el límite fue inferior a cinco pasos. Esos datos muestran una brecha entre la capacidad demostrada en una ejecución intensiva y la autonomía sostenida que las organizaciones consiguen en sus operaciones diarias.

Cursor ya trasladó parte de esta investigación a productos para desarrolladores. Con Cursor 3, los usuarios pueden ejecutar flotas enteras de agentes de IA en paralelo.

La empresa también vinculó su tecnología con proyectos de mayor escala. Una versión preliminar de Fable 5 gestionó gran parte de la reescritura de Bun, que pasó de Zig a Rust.

En ese proyecto, 64 instancias escribieron más de un millón de líneas de código durante 11 días. El costo aproximado fue de USD $165.000, una cifra que muestra tanto el potencial de escala como el gasto todavía asociado con este tipo de automatización.

Cursor publicó en GitHub la base de código de la ejecución individual con Opus bajo el nombre minisqlite. Ese material permite observar cómo un modelo de frontera aborda la implementación sin la división de roles del enjambre.

La adquisición de Anysphere, la empresa detrás de Cursor, por parte de SpaceX de Elon Musk por USD $60.000 millones también aparece como contexto empresarial de la expansión del producto. La operación sitúa a los enjambres de agentes dentro de una competencia tecnológica de gran escala.

El resultado más relevante del experimento no es que los modelos baratos reemplacen por completo a los modelos de frontera. La conclusión más precisa es que una arquitectura que asigna cada modelo a la tarea adecuada puede reducir costos sin sacrificar el resultado.

La planificación, la memoria compartida, las revisiones independientes y el control de conflictos forman parte del sistema completo. Sin esas capas, lanzar más agentes puede multiplicar el trabajo desperdiciado y hacer que la automatización se vuelva más cara que útil.

Para los equipos que evalúan herramientas de programación autónoma, la lección es concreta. La eficiencia no depende únicamente del modelo con mayor capacidad, sino de cómo se divide el contexto, cómo se verifican las decisiones y cómo se limita la coordinación entre instancias.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados