Escalar la codificación autónoma de larga duración

• Cursor experimentó para comprobar si podía completar proyectos de gran escala ejecutando agentes de codificación autónoma en paralelo durante semanas
• Al principio usó una estructura de colaboración dinámica, pero aparecieron cuellos de botella por conflictos de lock y trabajo duplicado
• Después separó los roles en Planner y Worker, mejorando mucho el paralelismo y la eficiencia
• Con esta estructura, implementó un navegador web desde cero, con cientos de agentes escribiendo más de 1 millón de líneas de código
• Los resultados muestran que una estructura simple y un diseño de prompts adecuado son la clave para escalar la codificación autónoma de largo plazo

---

Límites de un solo agente

• Los agentes de codificación individuales actuales son eficientes para tareas simples, pero en proyectos complejos son lentos
  • Ejecutar varios agentes en paralelo es una dirección natural para escalar, pero la coordinación del trabajo es difícil
• Al comienzo se probó un método de colaboración dinámica sin planificación previa
  • Una estructura en la que cada agente observa el estado de los demás y decide por sí mismo la siguiente tarea

Proceso de aprendizaje colaborativo

• Se introdujo una estructura en la que todos los agentes tenían la misma autoridad y coordinaban el trabajo mediante archivos compartidos
  • Cada agente revisaba el estado de otros agentes, recibía una tarea y actualizaba su estado
  • Para evitar duplicaciones, se utilizó un mecanismo de lock
• Problemas
  1. Los agentes retenían el lock demasiado tiempo o no lo liberaban, haciendo que la velocidad total cayera al nivel de solo 2 o 3 de 20
  2. Se producía inestabilidad del sistema, por ejemplo al fallar mientras tenían el lock o al modificar archivos sin lock
• Se cambió a control de concurrencia optimista (optimistic concurrency control)
  • Lectura libre, y escritura configurada para fallar cuando hubiera cambios de estado
  • Era simple y estable, pero en una estructura sin jerarquía los agentes mostraban un comportamiento evasivo ante el riesgo
  • Evitaban problemas difíciles y repetían solo cambios pequeños, generando un ciclo de trabajo sin avance

Estructura de planners y workers

• Se pasó a un pipeline jerárquico con separación de roles
  • Planners: exploran la base de código y generan tareas; si hace falta, crean planners subordinados
  • Workers: solo ejecutan la tarea asignada y, al terminar, hacen push de los cambios
• En cada ciclo, un agente juez (judge) decide si se avanza a la siguiente etapa
  • Esta estructura resolvió la mayoría de los problemas de colaboración y permitió escalar proyectos grandes

Experimentos de larga duración

• Objetivo del experimento: implementar un navegador web desde cero
  • Se ejecutó durante cerca de una semana y escribió más de 1 millón de líneas de código en 1,000 archivos
  • Cientos de workers hicieron push a la misma rama al mismo tiempo, pero los conflictos fueron mínimos
  • El código resultante se publicó en GitHub
• Experimentos adicionales
  • Migración de Solid a React: en 3 semanas, cambios de +266K/-193K, confirmando que era posible hacer merge
  • Mejora de renderizado de video: una versión en Rust logró una aceleración de 25x y añadió funciones de zoom, paneo y motion blur
  • Ese código se incorporará pronto a producción

Principales aprendizajes

• Tras invertir decenas de miles de millones de tokens, se comprobó que, aunque no es completamente eficiente, el rendimiento fue mejor de lo esperado
• La selección del modelo es clave para el trabajo autónomo de larga duración
  • GPT-5.2 destacó en mantener la concentración, seguir instrucciones e implementar con precisión
  • Opus 4.5 tendía a terminar rápido
  • GPT-5.2 fue más adecuado para el rol de planner que GPT-5.1-codex
  • Se eligió el mejor modelo según cada rol
• Eliminar complejidad contribuyó a mejorar el rendimiento
  • El rol de integrador de calidad (integrator) más bien generaba cuellos de botella
  • Los workers podían resolver conflictos por sí mismos
• La estructura simple fue la más efectiva
  • La teoría de sistemas distribuidos o los modelos de diseño organizacional solo resultaron parcialmente útiles
  • Si la estructura era demasiado escasa, aparecían conflictos y duplicaciones; si era demasiado compleja, aumentaba la fragilidad
• El diseño de prompts influye de forma decisiva en el comportamiento del sistema
  • Cumple un papel clave para mantener la concentración a largo plazo, evitar comportamientos patológicos y fomentar la colaboración

Retos a futuro

• La coordinación multiagente sigue siendo un problema difícil
  • Hace falta mejorar para que, al completar una tarea, el planner planifique automáticamente el siguiente paso
  • Algunos agentes se ejecutan durante demasiado tiempo, por lo que necesitan reinicios periódicos
• Sin embargo, sobre la pregunta central —“si se aumentan los agentes, ¿se puede escalar la codificación autónoma?”—
  • Se confirmó que cientos de agentes pueden colaborar durante semanas y lograr avances reales
• Esta tecnología se reflejará en el futuro en las funciones de agentes de Cursor

[GN⁺]

Comentarios de Hacker News

• Me pareció interesante porque estoy trabajando en algo relacionado con el texto de Steve Yegge, Welcome to Gas Town

• En un post reciente con mis predicciones sobre LLM dije que para 2029 hacer un navegador con código asistido por IA ya no sería sorprendente, y este proyecto de Cursor sería el segundo intento. Otro ejemplo puede verse en este post de Reddit

  • Si la implementación fuera inteligente, probablemente solo tomarían el código fuente de Chromium de GitHub, quitarían funciones innecesarias y cambiarían la apariencia.
  • Para 2029 ya deberíamos subir el estándar al punto de que haya chistes sobre una IA creando un navegador para pelícanos.
  • Revisé unos 5 minutos el código del ejemplo de Reddit y el manejo de cálculo de layout de texto y bidi (texto bidireccional) estaba hecho un desastre. Es difícil llamar navegador de verdad a un “navegador” que no considera los estándares.
  • Es impresionante, pero me pregunto si el código de navegadores open source ya estaba incluido en los datos de entrenamiento del modelo.
  • Dijo que su predicción había fallado, pero me intriga por qué volvió al mismo podcast una semana después para hacer una nueva predicción.

• Corrí yo mismo los tests del repositorio y estaban llenos de errores y advertencias, y el CI llevaba mucho tiempo fallando. No estoy seguro de que eso deba llamarse un “caso exitoso”. Me parece que un enfoque centrado en asistencia al humano es más realista que la programación totalmente autónoma.

  • El codebase estaba dividido en cientos o miles de archivos pequeños, así que era casi imposible entender la estructura. El README también estaba flojo y no había explicación de dependencias. Podrá ser código hecho por IA, pero mantenerlo sería una pesadilla.
  • Parece que incluso el autor veía la programación totalmente autónoma más como un experimento para probar los límites de los LLM que como algo seriamente listo para producto. Por ahora estamos en una etapa donde solo puede producir “código decente por sí solo” en proyectos pequeños.
  • Si de verdad hicieron merge a un PR con CI roto, da para el chiste de que ya alcanzó calidad humana.
  • No está claro qué significa exactamente decir que es “lento”. ¿Velocidad de GPU? ¿Que es más lento que un humano? Al final me pareció un texto para inflar la burbuja de la IA.

• Me pregunto por qué ese PR todavía no se ha mergeado. La idea de un futuro donde enjambres de agentes de IA completen software complejo a largo plazo suena genial, pero el ejemplo actual es demasiado débil. El punto clave es cómo colaboran con humanos.

  • En mi experiencia, los agentes no convergen y terminan creando monstruos de código cada vez más caóticos.
  • Que no hayan publicado ni un solo proyecto simple que funcione hace que parezca carnada para atraer inversionistas. El boom de la IA se parece a la burbuja puntocom, pero esta vez se siente más enfocado en hacer dinero.
  • Ejemplos como un navegador, Excel o Windows 7 quizá estuvieron parcialmente en los datos de entrenamiento, pero aun así no alcanza para una réplica completa.
  • El código es tan enorme y tan problemático que revisarlo ya es imposible. Al final no queda otra que hacer merge en modo YOLO.
  • A mí me interesan las condiciones de convergencia. No importa si el código crece o se reduce; lo importante es que se estabilice en un estado óptimo.

• Es una lástima que no hayan hecho experimentos subiendo la dificultad por etapas. Si hubieran escalado de forma gradual, React CRUD → clon de Paint → administrador de archivos → navegador, se podría ver con claridad cada etapa del progreso.

• Yo también hice algo parecido con tjs. Es el validador de JSON Schema más rápido y preciso del mundo, y el patrón planner/delegate con git subtree funcionó muy bien. El software con estándares y tests bien definidos puede ser reescrito y optimizado rápidamente por agentes de IA. Los comandos relacionados pueden verse en spawn-perf-agents.md

• Construir un navegador desde cero es muy difícil, pero lo presentado en el texto tenía poco análisis detallado. Si todo queda en “compila”, entonces tiene poco valor. La verdadera prueba es si puede fusionar el siguiente cambio de forma estable.

  • El estándar mínimo para el coding con agentes es: “compila con éxito” → “se ejecuta correctamente” → “maneja casos límite”. Solo se puede confiar en un sistema que funcione de forma estable por más de un año y con menos bugs que un humano.
  • En la práctica, el CI también está fallando, así que incluso la afirmación de que “compila” resulta dudosa.

• Según el blog, usaron billones de tokens; calculado al precio del API de OpenAI, eso sería del orden de decenas de millones de dólares. Con eso quizá habría sido mejor simplemente donarle a un equipo de navegadores.

• Intenté compilarlo yo mismo y salieron más de 100 errores de compilación. La mayoría de los commits tenían el CI roto, y en la práctica era una combinación de varias librerías open source. quickjs, wgpu, winit, egui, html parser y otros componentes existentes fueron incorporados tal cual, pero el CEO habló de una “custom JS VM”, lo que lleva a confusión. Aun así, impresiona que la IA haya logrado hacer esa integración de forma autónoma.

  • Los componentes usados son muy parecidos a blitz, un navegador basado en Rust, así que podría haber estado en los datos de entrenamiento.
  • También salió el típico chiste de startup: “no importa si funciona; toma capturas de pantalla y enséñaselas a los inversionistas”.
  • Hay una estadística de que, de unas 60 mil ejecuciones del workflow, solo alrededor de mil tuvieron éxito. En esencia parece un montón de código sin validar.
  • Cierra con el chiste de que “cada quien debería hacerse su propio Cursor custom”.

• El código se veía muy frágil e inestable. Por ejemplo, la función render_placeholder parece simplemente código temporal para rellenar el frame buffer. Me da curiosidad qué papel cumple realmente ese código y cuánto cuestan, en tokens/tiempo, las pruebas individuales.

  • La forma de extraer atributos de etiquetas también se veía algo rara, como en esta parte.
  • Pero si Cursor puede corregirlo automáticamente, esa fragilidad también podría terminar siendo una estrategia para aumentar la dependencia a largo plazo.