- 16 agentes de Claude colaboraron en paralelo para completar un compilador de C basado en Rust, alcanzando un nivel capaz de compilar el kernel de Linux 6.9
- Con unas 2,000 sesiones y un costo de 20,000 dólares, generaron una base de código de unas 100,000 líneas, con soporte para las arquitecturas x86, ARM y RISC-V
- Los agentes trabajaron continuamente sin intervención humana mediante un arnés de bucle automático, y mejoraron la eficiencia con una estructura de pruebas, paralelización y reparto de roles
- El resultado mostró compatibilidad con GCC y una alta tasa de pruebas superadas, aunque aspectos como la generación de código x86 de 16 bits, el enlazador y la calidad de optimización siguen incompletos
- Este experimento sirvió para comprobar los límites y posibilidades de un equipo autónomo de LLM, y plantea como reto clave futuro la seguridad y el control de calidad en entornos de desarrollo totalmente autónomos
Resumen del proyecto de compilador de C basado en un equipo de agentes
- Un experimento en el que varias instancias de Claude colaboran en paralelo para desarrollar una sola base de código
- Sin intervención humana en tiempo real, repiten de forma autónoma la escritura, prueba y corrección de código
- El objetivo era completar un compilador de C escrito en Rust para compilar directamente el kernel de Linux
- Se usaron un total de 16 agentes, unas 2,000 sesiones y 200 millones de tokens de entrada y 140 millones de tokens de salida
- El resultado fue un compilador de 100,000 líneas, capaz de compilar el kernel de Linux 6.9 y proyectos clave de código abierto (QEMU, FFmpeg, SQLite, Redis, etc.)
Diseño del arnés de Claude para ejecución de larga duración
- Claude Code requería entrada humana, pero un arnés de ejecución automática con estructura de bucle infinito permitió el avance autónomo
- Una estructura de repetición automática que ejecuta la siguiente tarea inmediatamente después de completar la anterior
- Hubo incluso un caso en el que Claude ejecutó por error
pkill -9 bash y terminó cerrándose a sí mismo
- La estructura de ejecución en paralelo aprovechó contenedores Docker y sincronización con Git
- Cada agente trabajaba en
/workspace y luego hacía push a /upstream
- Se evitaron conflictos de trabajo con locks basados en archivos de texto
- Claude resolvía directamente los conflictos de merge
Cómo operó el sistema paralelo de Claude
- La ventaja de la ejecución en paralelo fue la depuración simultánea y la diferenciación de roles
- Algunos agentes se encargaban de escribir código, y otros de documentación, control de calidad y optimización de rendimiento
- No existía comunicación ni un coordinador central; cada agente elegía de forma autónoma la siguiente tarea
- En el historial de Git quedaron registrados los bloqueos de trabajo y documentos de progreso de cada agente
Lecciones obtenidas del trabajo de programación con el equipo de Claude
La importancia de las pruebas de alta calidad
- Como Claude trabaja de forma autónoma según las pruebas dadas, la precisión del verificador es fundamental
- Si hay falsos positivos, el desarrollo puede avanzar en una dirección equivocada
- Se construyó una canalización de integración continua (CI) para forzar la verificación de que las funciones existentes no se rompan
- Se aseguró la calidad usando scripts de compilación de código abierto y una suite de pruebas para compiladores
Diseño del entorno desde la perspectiva de Claude
- Cada agente comienza en un contenedor nuevo sin contexto, por lo que es indispensable documentar el estado del avance
- Se les indicó actualizar continuamente el README y los archivos de progreso
- Prevención de contaminación de contexto: se minimizaron los logs y los errores se registraron de forma identificable con la palabra clave
ERROR
- Para compensar la falta de percepción del tiempo, se realizaron pruebas de muestra del 1 al 10% con la opción
--fast
Límites de la paralelización y cómo resolverlos
- Cuando hay muchas pruebas independientes, la paralelización es sencilla, pero la compilación del kernel de Linux generó conflictos al ser una tarea gigante y única
- Como solución, se usó GCC como compilador oráculo de referencia
- Algunos archivos se compilaban con GCC y el resto con el compilador de Claude
- Cuando fallaba, era posible acotar el archivo problemático y hacer depuración en paralelo
- Después se utilizó delta debugging para detectar errores de dependencia mutua
Diferenciación de roles entre agentes
- Se repartieron roles especializados como eliminación de código duplicado, mejora de rendimiento, generación de código más eficiente, mejora de la estructura en Rust y documentación
- La combinación de paralelismo y especialización mejoró la eficiencia para gestionar una base de código grande
Evaluación del rendimiento del modelo Opus 4.6
- Hasta Opus 4.5 no era posible compilar proyectos grandes; con Opus 4.6 se alcanzó por primera vez un nivel práctico
- Se trató de una implementación clean room, usando solo la biblioteca estándar de Rust y sin acceso a internet
- Superó el 99% de la GCC torture test suite y fue capaz de ejecutar Doom
- Limitaciones:
- No puede generar código x86 de 16 bits, por lo que en la etapa de arranque aún necesita invocar a GCC
- El ensamblador y el enlazador están incompletos, y persisten algunos bugs
- La eficiencia del código generado es baja, incluso menos eficiente que GCC con las optimizaciones desactivadas
- La calidad del código Rust es aceptable, pero no alcanza nivel experto
Límites y posibilidades de los equipos autónomos de agentes
- El proyecto funciona como benchmark para medir los límites de la colaboración autónoma de los LLM
- El desarrollo totalmente autónomo conlleva aseguramiento de calidad y riesgos de seguridad
- Existe el riesgo de confundir el simple hecho de pasar pruebas con una implementación realmente terminada
- Se expresa preocupación por desplegar código sin verificación humana
- Aun así, demostró que un equipo de agentes autónomos puede completar proyectos complejos
- Con el avance de los modelos, se plantea como tarea esencial una estrategia de desarrollo autónomo seguro
Perspectivas a futuro
- El avance de los modelos de lenguaje evoluciona de autocompletado en IDE → completado de funciones → programación en pareja → ejecución autónoma de proyectos
- Los Agent teams muestran la posibilidad de un desarrollo completamente autónomo
- Junto con la sorpresa por la rapidez del avance tecnológico, se subraya la necesidad de nuevos marcos éticos y de seguridad
- Se espera que los usos positivos compensen los riesgos negativos, pero se destaca la necesidad de prepararse para un nuevo paradigma de desarrollo
2 comentarios
Como no es un compilador de C hecho en C, sino un proyecto hecho únicamente con la biblioteca estándar de Rust, me parece que la crítica de que en los datos de entrenamiento hay código C de gcc/clang es un poco mover la portería. De todos modos, es impresionante.
Comentarios en Hacker News
Trabajé casi 10 años en Google en compilar el kernel de Linux con Clang. Este proyecto (clangbuiltlinux.github.io) supuestamente logró lo mismo con un LLM, 2,000 sesiones y 20 mil dólares en costos de API. Es sorprendente que incluso llegue a arrancar. Aun así, la eficiencia del código generado es baja, e incluso es menos eficiente que una versión de GCC con optimizaciones desactivadas. Aun así, es un proyecto realmente genial
Es un enfoque mucho más realista que el proyecto del navegador de Cursor. Dicen que fue una implementación clean room, usando solo la biblioteca estándar de Rust y sin acceso a internet. Un compilador de 100 mil líneas supuestamente puede compilar Linux 6.9, QEMU, FFmpeg, SQLite, Postgres y Redis.
Opus 4.5 fue el primero en poder pasar pruebas grandes, y este resultado parece haber exprimido casi por completo ese límite.
A pesar de varias restricciones, me parece un experimento impresionante
Al principio pensé “wow, impresionante”, pero pronto cambié de opinión. Un compilador de C es un software con una especificación muy estricta, así que es relativamente fácil para un LLM.
Pero la mayor parte de lo que hacemos ocurre en entornos donde los requisitos son ambiguos y los objetivos cambian constantemente. Me pregunto si también funcionará bien en esas áreas
Se siente raro esperar que el resultado sea perfecto. Lo sorprendente es que esto sea posible en absoluto. Es posible que este tipo de intentos se reflejen en el entrenamiento del próximo Opus o Sonnet, y que algún día aparezca un modelo capaz de crear por sí solo un compilador eficiente
Dicen que este proyecto puede compilar el kernel de Linux, QEMU, FFmpeg, Redis e incluso Doom. Es realmente sorprendente.
Pero este tipo de sistemas de agentes funciona bien en áreas que se pueden probar, mientras que tiene límites en áreas donde se necesita contexto, como la toma de decisiones de negocio
Es un proyecto genial, pero habría sido mejor omitir la mención de “clean room”. Como es un modelo entrenado con código con copyright, en realidad está más cerca de lo contrario
Según este issue de GitHub, el problema se debía a una ruta de include faltante. El compilador en sí estaba bien
Me gustaría que publicaran todos los prompts y la estructura de agentes. Sería excelente para aprender, pero reproducirlo por cuenta propia gastando 20 mil dólares es pesado
Esto parece una versión que sí funciona del blog de Cursor. La evidencia de que realmente compiló el kernel de Linux es mucho más convincente
Este es un enfoque del tipo “puedes construir pirámides pero no catedrales” (texto relacionado).
Básicamente metieron una enorme cantidad de recursos de cómputo para forzar la implementación de la funcionalidad, y se podría decir que se quemaron 20 mil dólares.
Obtener resultados lineales con cómputo exponencial tiene sentido, pero a largo plazo parece una dirección ineficiente