Hemos estado experimentando con agentes de programación que se ejecutan de forma autónoma durante semanas.

Nuestro objetivo es entender hasta dónde podemos llevar los límites de la programación basada en agentes para proyectos que normalmente llevan meses en completarse por equipos humanos.

Este artículo describe lo que hemos aprendido al ejecutar cientos de agentes concurrentes en un solo proyecto, coordinando su trabajo y observando cómo escriben más de un millón de líneas de código y billones de tokens.

#Los límites de un único agente

Los agentes actuales funcionan bien para tareas específicas, pero son lentos para proyectos complejos. El siguiente paso natural es ejecutar varios agentes en paralelo, pero averiguar cómo coordinarlos es un desafío.

Nuestro primer instinto fue que planificar de antemano sería demasiado rígido. El camino en un proyecto grande es ambiguo y la división adecuada del trabajo no es evidente desde el principio. Comenzamos con una coordinación dinámica, donde los agentes deciden qué hacer en función de lo que los demás están haciendo en ese momento.

#Aprender a coordinarse

Nuestro enfoque inicial daba a los agentes el mismo estatus y les permitía coordinarse entre sí mediante un archivo compartido. Cada agente comprobaba lo que los demás estaban haciendo, asumía una tarea y actualizaba su estado. Para evitar que dos agentes tomaran la misma tarea, usamos un mecanismo de bloqueo.

Esto falló de maneras interesantes:

1. Los agentes mantenían los bloqueos durante demasiado tiempo o se olvidaban de liberarlos por completo. Incluso cuando el bloqueo funcionaba correctamente, se convertía en un cuello de botella. Veinte agentes se ralentizaban hasta un rendimiento efectivo de dos o tres, con la mayor parte del tiempo dedicada a esperar.

2. El sistema era frágil: los agentes podían fallar mientras mantenían bloqueos, intentar adquirir bloqueos que ya tenían o actualizar el archivo de coordinación sin adquirir el bloqueo en absoluto.

Probamos reemplazar los bloqueos con control de concurrencia optimista. Los agentes podían leer el estado libremente, pero las escrituras fallaban si el estado había cambiado desde la última lectura. Esto era más sencillo y más sólido, pero seguía habiendo problemas más profundos.

Sin jerarquía, los agentes se volvieron reacios al riesgo. Evitaban las tareas difíciles y, en su lugar, realizaban cambios pequeños y seguros. Ningún agente asumía la responsabilidad de los problemas difíciles o de la implementación de extremo a extremo. Esto llevó a que el trabajo diera vueltas durante largos períodos de tiempo sin lograr avances.

#Planificadores y trabajadores

Nuestro siguiente enfoque fue separar los roles. En lugar de una estructura plana donde cada agente hace todo, creamos un pipeline con responsabilidades diferenciadas.

• Planificadores exploran continuamente la base de código y crean tareas. Pueden generar subplanificadores para áreas específicas, haciendo que la propia planificación sea paralela y recursiva.

• Trabajadores asumen tareas y se concentran por completo en completarlas. No se coordinan con otros trabajadores ni se preocupan por la visión global. Simplemente se dedican a su tarea asignada hasta terminarla y luego envían sus cambios.

Al final de cada ciclo, un agente juez determinaba si debía continuar; luego la siguiente iteración comenzaba desde cero. Esto resolvió la mayoría de nuestros problemas de coordinación y nos permitió escalar a proyectos muy grandes sin que ningún agente desarrollara visión de túnel.

#En ejecución durante semanas

Para probar este sistema, lo pusimos a trabajar en un objetivo ambicioso: crear un navegador web desde cero. Los agentes se ejecutaron durante casi una semana, escribiendo más de 1 millón de líneas de código en 1,000 archivos. Puedes explorar el código fuente en GitHub.

A pesar del tamaño de la base de código, los nuevos agentes aún pueden entenderla y avanzar de forma significativa. Cientos de workers se ejecutan en paralelo, enviando cambios (push) a la misma rama con conflictos mínimos.

Aunque pueda parecer una simple captura de pantalla, crear un navegador desde cero es extremadamente difícil.

Otro experimento fue hacer una migración in-place de Solid a React en la base de código de Cursor. Tomó más de tres semanas, con +266K/-193K ediciones. Todavía necesita una revisión cuidadosa, pero estaba pasando nuestro CI y las verificaciones iniciales.

Otro experimento fue mejorar un producto próximo a lanzarse. Un agente de larga duración hizo que el renderizado de video fuera 25 veces más rápido con una versión eficiente en Rust. También agregó compatibilidad para hacer zoom y desplazarse suavemente con transiciones tipo resorte naturales y desenfoques de movimiento, siguiendo el cursor. Este código se fusionó y estará en producción pronto.

Tenemos algunos otros ejemplos interesantes aún en ejecución:

• Java LSP: 7,4K commits, 550K LoC
• Emulador de Windows 7: 14,6K commits, 1,2M LoC
• Excel: 12K commits, 1,6M LoC

#Lo que hemos aprendido

Hemos ejecutado billones de tokens a través de estos agentes con un solo objetivo. El sistema no es perfectamente eficiente, pero es mucho más efectivo de lo que esperábamos.

La elección del modelo importa para tareas de ejecución muy prolongada. Descubrimos que los modelos GPT-5.2 son mucho mejores para trabajo autónomo extendido: seguir instrucciones, mantener el enfoque, evitar desviaciones e implementar las cosas de forma precisa y completa.

Opus 4.5 tiende a detenerse antes y a tomar atajos cuando le conviene, devolviendo el control rápidamente. También descubrimos que diferentes modelos sobresalen en distintos roles. GPT-5.2 es mejor planificador que GPT-5.1-Codex, aunque este último está entrenado específicamente para programar. Ahora usamos el modelo más adecuado para cada rol en lugar de un modelo universal.

Muchas de nuestras mejoras vinieron de eliminar complejidad en lugar de añadirla. Inicialmente creamos un rol de integrador para control de calidad y resolución de conflictos, pero descubrimos que generaba más cuellos de botella de los que resolvía. Los workers ya eran capaces de manejar los conflictos por sí mismos.

El mejor sistema suele ser más simple de lo que cabría esperar. Al principio intentamos modelar sistemas de computación distribuida y diseño organizacional. Sin embargo, no todos funcionan bien para agentes.

La cantidad adecuada de estructura está en un punto intermedio. Con muy poca estructura, los agentes entran en conflicto, duplican trabajo y se desvían. Demasiada estructura crea fragilidad.

Una parte sorprendentemente grande del comportamiento del sistema se reduce a cómo formulamos los prompts para los agentes. Lograr que se coordinen bien, eviten comportamientos patológicos y mantengan el enfoque durante largos períodos requirió mucha experimentación. El harness y los modelos importan, pero los prompts importan más.

#Próximos pasos

La coordinación entre múltiples agentes sigue siendo un problema difícil. Nuestro sistema actual funciona, pero estamos muy lejos de lo óptimo. Los planificadores deberían activarse cuando sus tareas se completen para planificar el siguiente paso. A veces los agentes se ejecutan durante demasiado tiempo. Todavía necesitamos reinicios periódicos para combatir la deriva y la visión de túnel.

Pero la pregunta central —si podemos escalar la programación autónoma simplemente añadiendo más agentes a un problema— tiene una respuesta más optimista de lo que esperábamos. Cientos de agentes pueden trabajar juntos en una sola base de código durante semanas, logrando avances reales en proyectos ambiciosos.

Las técnicas que estamos desarrollando aquí acabarán definiendo las capacidades de los agentes de Cursor. Si te interesa trabajar en los problemas más difíciles del desarrollo de software asistido por IA, nos encantaría saber de ti en hiring@cursor.com.