16 agentes de Claude escriben en dos semanas un compilador de C de 100 000 líneas por $20 000

Nicholas Carlini, investigador del equipo Safeguards de Anthropic, llevó a cabo un experimento: 16 instancias de Claude Opus 4.6 trabajaron en paralelo sobre un repositorio compartido para escribir desde cero un compilador de C en Rust. Casi no hubo intervención humana. En dos semanas y alrededor de 2000 sesiones de Claude Code, los agentes produjeron 100 000 líneas de código. El compilador genera un kernel de Linux 6.9 arrancable en x86, ARM y RISC-V. La factura de la API fue de poco menos de $20 000.

Cómo se organiza el sistema de agentes

El esquema es sencillo. Claude se ejecuta en un bucle infinito: cuando termina una tarea, toma la siguiente. Cada agente vive en su propio contenedor Docker, clona un repositorio git bare compartido y sube allí sus cambios. Para que los agentes no resuelvan lo mismo, se usan bloqueos: Claude crea un archivo de texto del tipo current_tasks/parse_if_statement.txt, y git impide que un segundo agente tome esa misma tarea. Los conflictos de fusión son frecuentes, pero el modelo los resuelve por sí solo.

No hay orquestador ni canales de comunicación comunes entre los agentes. Cada uno decide por su cuenta qué hacer a continuación y suele elegir el «siguiente problema más obvio». En una ocasión, un agente ejecutó por accidente pkill -9 bash y cortó su propio bucle.

El grueso del esfuerzo no se dedicó a los prompts, sino al entorno: pruebas, logs y retroalimentación. La salida de las pruebas se limita a unas pocas líneas para no saturar el contexto. Los errores se escriben en una sola línea con la etiqueta ERROR para poder usar grep. Para combatir la «ceguera temporal» se añadió la opción --fast, que ejecuta una muestra del 1% o del 10% de las pruebas, determinista para cada agente.

Dónde chocaron con el techo

Mientras las pruebas son independientes, paralelizar es fácil: cada agente toma su propia prueba fallida. Pero el kernel de Linux es una única tarea gigantesca. Los 16 agentes tropezaban con el mismo error y se sobrescribían los arreglos unos a otros. La salida llegó al usar GCC como oráculo de referencia: GCC compilaba una parte aleatoria de los archivos del kernel y Claude, el resto. Así, los agentes empezaron a corregir bugs distintos en archivos distintos. Para los pares de archivos que solo fallaban juntos se aplicó delta debugging.

También se asignaron roles a los agentes: uno unificaba el código duplicado, otro aceleraba el propio compilador, un tercero se ocupaba de la eficiencia del código generado, un cuarto actuaba como crítico de la arquitectura desde la perspectiva de un desarrollador de Rust y un quinto llevaba la documentación.

Cifras y limitaciones

• Tamaño: unas 100 000 líneas de Rust, sin más dependencias que la biblioteca estándar.
• Recursos: 2000 millones de tokens de entrada y 140 millones de salida, casi $20 000.
• Pruebas: 99% en la mayoría de las suites, incluida GCC torture.
• Compila: Linux 6.9 (x86, ARM, RISC-V), QEMU, FFmpeg, SQLite, Postgres, Redis, Doom.
• Desarrollo tipo clean room: Claude no tenía acceso a internet.
• Sin ensamblador ni enlazador propios: estos módulos fueron los últimos en automatizarse y todavía fallan.
• El x86 de 16 bits para real mode no está implementado: la salida supera los 60 KB frente al límite de 32 KB del kernel, así que se invoca a GCC.
• El código es menos eficiente que el de GCC, incluso con las optimizaciones desactivadas.

Carlini escribe sin rodeos que el compilador casi llegó al límite de las capacidades de Opus: las funciones nuevas y las correcciones rompían con regularidad lo que ya funcionaba. El avance dentro de la línea es visible: los primeros Opus 4 apenas lograban producir un compilador funcional, y Opus 4.5 pasó por primera vez grandes suites de pruebas, pero no compilaba proyectos reales.

Conclusiones prácticas

La lección principal para quienes construyen agentes autónomos: la calidad del mecanismo de verificación importa más que el propio modelo. Si el verificador es impreciso, el agente resolverá con total seguridad el problema equivocado. Por eso las pruebas hay que escribirlas pensando en el modelo: salida corta, logs compatibles con grep, submuestras deterministas y rápidas, y una CI que impida romper commits anteriores.

Segunda: el paralelismo exige descomposición. Si la tarea es monolítica, los agentes adicionales solo estorban, y un referente funcional conocido ayuda a dividirla en partes independientes.

Tercera: $20 000 por un compilador capaz de compilar Linux es mucho más barato que un equipo de ingenieros, pero sigue siendo más caro que una suscripción. El código está publicado y se puede probar con proyectos propios en C. El propio autor aclara que el desarrollo totalmente autónomo conlleva riesgos reales y que, por ahora, no se puede prescindir del control humano sobre la calidad y la seguridad del código.