Por Canuto  

Cursor afirma que una arquitectura de agentes planificadores y trabajadores puede mejorar el rendimiento del software generado por IA, reducir los conflictos de coordinación y bajar radicalmente los costos frente al uso de modelos avanzados en cada etapa.
***

  • El nuevo enjambre de Cursor alcanzó entre 73% y 85% de las pruebas de SQLite en cuatro horas, mientras el sistema anterior llegó a descontrolarse.
  • La nueva arquitectura redujo los conflictos de fusión de más de 70.000 a menos de 1.000 y pasó de aproximadamente 1.000 commits por hora a 1.000 por segundo.
  • El sistema híbrido con Opus 4.8 y Composer 2.5 costó USD $1.339, frente a USD $10.565 para la configuración con GPT-5.5.

La evolución de los agentes de inteligencia artificial está desplazando el foco desde la generación de código hacia la coordinación de sistemas completos. Cursor sostiene que los enjambres de agentes pueden abordar tareas largas y complejas mediante una división estructurada entre planificación, ejecución, revisión y control de cambios.

La empresa probó esta idea con una tarea exigente: construir SQLite desde cero en Rust usando únicamente su documentación, el código fuente, los conjuntos de pruebas, el binario original y acceso a Internet. La comparación enfrentó un sistema antiguo y uno nuevo bajo el mismo presupuesto de tiempo y con los mismos modelos.

El resultado favoreció al diseño actualizado en todas las configuraciones evaluadas. Según el blog de Cursor, el nuevo enjambre alcanzó 80% de las pruebas en cuatro horas usando Grok 4.5, mientras la versión anterior perdió el control y tuvo que pausarse antes de completar dos horas.

La prueba también permitió observar una diferencia económica importante. Un modelo avanzado puede reservarse para las decisiones de mayor complejidad, mientras modelos rápidos y económicos ejecutan la mayoría de las tareas ya descompuestas.

Este enfoque plantea una posible transformación en la economía del desarrollo de software. El recurso escaso dejaría de ser solamente la capacidad de escribir código y pasaría a ser la capacidad de expresar correctamente una intención, convertirla en especificaciones y mantener la coordinación entre cientos de agentes.

Un árbol de tareas para evitar la sobrecarga

El sistema organiza los proyectos como árboles. El objetivo principal ocupa la raíz, los planificadores dividen el problema en ramas y los trabajadores ejecutan las unidades básicas que aparecen en las hojas.

Los agentes planificadores utilizan modelos más inteligentes para tomar decisiones de diseño, dividir objetivos y delegar responsabilidades. Los agentes trabajadores suelen utilizar modelos más rápidos y menos costosos para implementar cada parte.

La arquitectura no impone una topología fija. El enjambre crece según la forma del problema, por lo que el cómputo y el contexto pueden aumentar en proporción a la complejidad de la tarea.

Cursor afirma que esta estructura se ha utilizado en proyectos diversos. Entre ellos menciona la construcción de un navegador, la resolución de problemas matemáticos, la optimización de núcleos de GPU, la corrección de vulnerabilidades y la generación de miles de millones de tokens de datos sintéticos.

La división también busca resolver una limitación de los agentes individuales. Un agente que intenta completar toda la tarea debe recordar el objetivo general mientras desciende por cada detalle, una combinación que puede provocar desvíos y pérdida de contexto.

En el enjambre, el planificador no implementa y el trabajador no necesita diseñar la estrategia completa. Cada uno concentra su ventana de contexto en una función más estrecha, lo que podría explicar la mejora incluso en tareas de tamaño moderado.

La compañía relaciona esta lógica con una idea del economista Ronald Coase. Las empresas existen, en parte, porque los costos de coordinación crecen más rápido que el trabajo, por lo que las organizaciones distribuyen sus actividades en unidades limitadas en lugar de permitir que todos interactúen con todos.

El problema de coordinar miles de cambios

El volumen de actividad obligó a Cursor a crear un nuevo sistema de control de versiones desde cero. Herramientas como Git y Cargo utilizan bloqueos de grano grueso que funcionan para equipos humanos, pero resultan inadecuadas cuando cientos de agentes trabajan simultáneamente.

El enjambre que construyó el navegador alcanzó aproximadamente 1.000 commits por hora. El nuevo sistema, en cambio, llegó a un máximo cercano a 1.000 commits por segundo.

El control de versiones no solo debía acelerar los cambios. También se convirtió en el punto donde las colisiones se hacen visibles y donde se implementan varios mecanismos de coordinación, como la resolución neutral de conflictos y el control de archivos demasiado grandes.

Uno de los fallos detectados fue el diseño de cerebro partido. Dos planificadores podían desconocer el trabajo del otro y desarrollar la misma idea de formas distintas en diferentes partes del código.

Para reducir ese riesgo, Cursor indicó a los planificadores que tomaran decisiones de diseño por su cuenta. También les exigió comprobar que dos subárboles delegados no decidieran la misma cuestión.

Otro problema apareció cuando los planificadores conocían la existencia del otro y competían mediante cambios sucesivos sobre los mismos archivos. En ese caso, las herramientas de fusión no resolvían el desacuerdo porque el conflicto involucraba visiones distintas de la realidad.

La respuesta consistió en registrar las decisiones en documentos de diseño compartidos. El código dependiente de cada decisión mantiene una referencia verificada por el compilador, de modo que un reconciliador puede fusionar documentos y propagar la resolución.

Los conflictos de fusión también exigieron una intervención específica. En lugar de obligar a los trabajadores a absorber el contexto de los demás, un agente neutral resuelve las colisiones en nombre de todas las partes, con un objetivo de imparcialidad y eficiencia.

Cursor identificó además los llamados megaficheros. Son archivos que reciben pequeños cambios de muchos agentes, crecen sin un responsable claro y terminan provocando costos elevados de transporte, comparación y fusión.

Cuando un trabajador marca un archivo como abultado, el sistema bloquea nuevos commits sobre ese archivo. Luego, un agente externo lo divide en módulos más pequeños para reducir las colisiones futuras.

SQLite como prueba de rendimiento y costo

La nueva versión del enjambre recibió la instrucción de implementar el manual completo de SQLite, con 835 páginas, en Rust. Para medir los resultados se utilizó sqllogictest, un conjunto de pruebas diseñado para comprobar que distintos motores de bases de datos entreguen respuestas iguales ante las mismas consultas.

El conjunto contiene millones de consultas con respuestas conocidas. La calificación representa la fracción de resultados correctos obtenidos por la base de datos construida por los agentes.

Los agentes nunca supieron que ese conjunto existía. Después de cada ejecución, Cursor revisó manualmente el código y la trayectoria de trabajo para buscar atajos, trampas o una optimización limitada a las pruebas.

La empresa también advirtió que los agentes siguieron estrategias diferentes. Algunos construyeron una base amplia y obtuvieron puntuaciones bajas durante horas antes de registrar un salto tardío, mientras otros profundizaron primero en un área y luego ampliaron la cobertura.

Se evaluaron cuatro combinaciones de modelos. La primera utilizó GPT-5.5 como planificador y trabajador, la segunda empleó Grok 4.5 en ambos roles, la tercera combinó Opus 4.8 como planificador con Composer 2.5 como trabajador y la cuarta unió Fable 5 con Composer 2.5.

El sistema nuevo superó al antiguo en cada mezcla. El híbrido con Fable 5 pasó aproximadamente dos tercios del conjunto durante la primera hora, mientras las ejecuciones nuevas llegaron a entre 73% y 85% en el límite de cuatro horas.

Las ejecuciones antiguas variaron entre 11% y 77% en ese mismo plazo. La ejecución antigua con Grok 4.5 fue pausada antes de completar dos horas, mientras cada nueva configuración continuó hasta superar 100% del conjunto.

La diferencia no se limitó a la puntuación. Bajo el sistema antiguo, la ejecución con Grok 4.5 produjo 68.000 commits durante sus primeras dos horas, cerca de 70 veces el ritmo de la nueva ejecución.

Sin embargo, los datos sugirieron que gran parte de esa actividad era trabajo innecesario. El sistema antiguo acumuló más de 70.000 conflictos de fusión antes de ser detenido, mientras el nuevo registró menos de 1.000 durante cuatro horas.

El archivo más disputado del sistema antiguo acumuló 7.771 conflictos y fue modificado por 1.173 agentes. En la nueva ejecución, el archivo más conflictivo de toda la base de código registró 47 conflictos.

La estructura final también cambió. El enjambre antiguo creó 54 crates, incluidos tres paquetes SQL separados, mientras el nuevo se estableció temprano en nueve crates y nunca agregó otro.

En la mezcla con Fable 5, ambos sistemas terminaron superando el conjunto completo, pero el antiguo necesitó 64.305 líneas de código del motor. El nuevo alcanzó ese resultado con 9.908 líneas.

La mezcla con Opus 4.8 mostró una diferencia similar. El sistema antiguo llegó a 97% con 19.013 líneas, mientras el nuevo alcanzó 100% con 4.645 líneas.

La economía de usar modelos especializados

Las cuatro mezclas produjeron una calidad parecida, pero sus costos fueron muy diferentes. La ejecución híbrida con Opus 4.8 y Composer 2.5 costó USD $1.339, mientras la configuración con GPT-5.5 en ambos roles llegó a USD $10.565.

Los trabajadores generaron al menos 69% de los tokens en todas las ejecuciones y más de 90% en la mayoría. Sin embargo, los tokens no se tradujeron directamente en el mismo porcentaje del gasto, porque los modelos utilizados para planificar tenían un precio superior.

En la mezcla de Opus 4.8 y Composer 2.5, Opus produjo una pequeña fracción de los tokens, pero representó aproximadamente dos tercios del costo. Composer manejó la mayoría de los tokens por el tercio restante del gasto.

La explicación propuesta es que pocas etapas requieren inteligencia de frontera. La descomposición inicial, las decisiones de diseño y ciertos compromisos pueden necesitar un modelo avanzado, pero la ejecución detallada puede quedar en manos de sistemas económicos.

La diferencia resulta especialmente visible al comparar los trabajadores. En la ejecución con GPT-5.5, los trabajadores costaron USD $9.373 por sí solos.

En la combinación donde Opus 4.8 planificó y Composer 2.5 trabajó, toda la flota de trabajadores costó USD $411. La reducción muestra por qué la asignación de modelos podría convertirse en una variable central para la rentabilidad de los sistemas autónomos.

Las dos ejecuciones híbridas también revelaron un matiz. Fable 5 tuvo un costo de planificación ligeramente menor que Opus 4.8, aunque su precio por token era aproximadamente el doble, porque empleó muchos menos tokens de planificación.

No obstante, los trabajadores de la ejecución con Fable utilizaron varias veces más tokens. Como consecuencia, el costo total de esa ejecución fue sustancialmente superior.

El sistema incorporó además revisiones apiladas. Cursor probó revisores con transcripciones completas, con solo la salida del trabajador o con acceso únicamente a la base de código.

También combinó modelos, entrenamientos y personalidades distintas. Ninguna lente detectó todos los errores, pero la empresa sostiene que la combinación de revisiones menos correlacionadas puede elevar la confiabilidad general.

Del código a la especificación

El enjambre utiliza el entorno como una memoria compartida. Cursor describe este mecanismo como estigmergia, un proceso de coordinación indirecta en el que los organismos modifican el entorno y esas modificaciones orientan a los siguientes participantes.

La empresa había incorporado reglas como mantener notas y documentar decisiones. Después creó un contexto compartido llamado Manual de Campo, una carpeta propiedad de los agentes cuyo archivo índice.md se inyecta automáticamente al inicio de cada tarea.

Los propios agentes deben decidir qué información conservar en ese manual. La única limitación indicada es un presupuesto de líneas, por lo que el sistema intenta registrar los encuentros inesperados que puedan ahorrar trabajo a futuros agentes.

Cursor considera que el experimento ofrece resultados iniciales prometedores. La compañía espera que el beneficio sea mayor cuando los agentes trabajen sobre bases de código que no controlen por completo.

Una línea de investigación futura consiste en entrenar modelos para escribir instrucciones útiles para sus sucesores. La idea es que una mejor captura del conocimiento produzca trayectorias posteriores más cortas y recompensas superiores.

La conclusión conceptual es que la unidad de trabajo puede estar cambiando. La autocompletación permitió trabajar línea por línea, los primeros modelos elevaron el nivel a bloques y los agentes lo llevaron a archivos o funciones.

Con los enjambres, la especificación se convierte en la unidad principal. Cursor entregó 835 páginas de prosa y obtuvo una base de datos, aunque la compañía reconoce que lo verdaderamente escaso será describir correctamente la intención.

El proceso se parece a un compilador que traduce código fuente a código de máquina mediante pasos intermedios. La diferencia es que el enjambre no preserva el significado de manera determinista, sino que introduce una probabilidad de error en cada etapa.

Los mecanismos de planificación, control de versiones, revisión y documentación buscan cerrar esa brecha. La base de código de una ejecución con Opus 4.8 quedó disponible públicamente en GitHub bajo el proyecto minisqlite, aunque Cursor aclaró que todavía no realizó un análisis manual más profundo.

El experimento no demuestra que los enjambres resolverán cualquier proyecto de software. Sí muestra que la arquitectura, la coordinación y la selección económica de modelos pueden importar tanto como la capacidad individual del modelo más avanzado.

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