16 agentes de Claude crean un compilador de C por $20.000 (y mucha supervisión humana)

¿Qué pasa si pones 16 copias de Claude a programar juntas durante dos semanas con un presupuesto de 20.000 dólares? Nicholas Carlini, investigador de Anthropic, acaba de responder esa pregunta de la manera más espectacular posible: creando un compilador de C completamente funcional desde cero.

El resultado es impresionante sobre el papel: 100.000 líneas de código en Rust capaces de compilar un kernel de Linux 6.9 para arquitecturas x86, ARM y RISC-V. El compilador pasa el 99% de las pruebas de tortura de GCC y, en lo que Carlini llamó "la prueba definitiva del desarrollador", logra compilar y ejecutar Doom.

Pero, como siempre en el mundo de la IA, los detalles importan más que los titulares.

La orquesta sin director

Carlini utilizó una función nueva de Claude Opus 4.6 llamada "equipos de agentes". Cada instancia de Claude funcionaba en su propio contenedor Docker, clonando un repositorio Git compartido, reclamando tareas mediante archivos de bloqueo y enviando el código completado de vuelta al repositorio principal.

Lo fascinante es que no había un agente orquestador. Cada Claude identificaba de manera independiente el problema más obvio en el que trabajar y comenzaba a resolverlo. Cuando surgían conflictos de fusión, los resolvían por su cuenta. Es como ver a 16 programadores trabajar en el mismo proyecto sin hablar entre ellos, comunicándose solo a través del código.

Esta metodología de agentes paralelos coordinándose a través de Git es realmente novedosa. Pero aquí viene la primera gran advertencia: un compilador de C es prácticamente la tarea perfecta para la IA semi-autónoma.

El problema perfecto (que no existe en la vida real)

Piénsalo: la especificación de C tiene décadas de antigüedad y está perfectamente definida. Existen suites de pruebas exhaustivas. Hay compiladores de referencia contra los que comparar. La mayoría de los proyectos de software del mundo real no tienen ninguna de estas ventajas.

La parte difícil del desarrollo no es escribir código que pase las pruebas; es averiguar qué pruebas deberían existir en primer lugar. Es definir qué problema estás resolviendo realmente. Es navegar los requisitos cambiantes, las restricciones de negocio y las decisiones de arquitectura que no están en ningún manual.

Carlini fue honesto sobre las limitaciones del compilador resultante. Le falta un backend de x86 de 16 bits necesario para arrancar Linux desde modo real, así que delega en GCC para ese paso. Su ensamblador y enlazador siguen siendo problemáticos. Incluso con todas las optimizaciones habilitadas, produce código menos eficiente que GCC con todas las optimizaciones deshabilitadas.

El muro de las 100.000 líneas

Pero quizás lo más revelador es lo que Carlini describe hacia el final del proyecto: "arreglar bugs y añadir características frecuentemente rompía funcionalidad existente". Cualquiera que haya visto crecer una base de código más allá del punto donde cualquier contribuidor la entiende completamente reconocerá este patrón.

El modelo llegó a este muro alrededor de las 100.000 líneas, lo que sugiere un techo práctico para la programación agéntica autónoma, al menos con los modelos actuales. Los agentes de IA pierden coherencia con el tiempo, y este experimento nos da una cifra concreta de dónde empieza a colapsar todo.

El trabajo humano detrás de la "autonomía"

Aquí está el detalle que más me llama la atención: aunque el titular habla de agentes "autónomos", Carlini pasó un tiempo considerable construyendo el andamiaje que hizo posible el proyecto. No fue programación en pareja con humanos, pero tampoco fue realmente autónomo.

Tuvo que diseñar arneses de prueba, pipelines de integración continua y sistemas de retroalimentación ajustados específicamente para las formas particulares en que fallan los modelos de lenguaje. Descubrió, por ejemplo, que la salida verbosa de las pruebas contaminaba la ventana de contexto del modelo, haciendo que perdiera el hilo de lo que estaba haciendo.

Cuando los 16 agentes se atascaron tratando de arreglar el mismo bug del kernel de Linux simultáneamente, tuvo que usar GCC como oráculo de referencia, compilando la mayoría de los archivos del kernel con GCC y solo un subconjunto con el compilador de Claude.

"Claude trabajará autónomamente para resolver cualquier problema que le dé", escribió Carlini, "así que es importante que el verificador de tareas sea casi perfecto, de lo contrario Claude resolverá el problema equivocado".

¿Implementación limpia o descompresión difusa?

Anthropic describe el compilador como una "implementación de sala limpia" porque los agentes no tenían acceso a Internet durante el desarrollo. Pero este encuadre es algo engañoso. El modelo subyacente fue entrenado con enormes cantidades de código fuente disponible públicamente, casi seguramente incluyendo GCC, Clang y numerosos compiladores de C más pequeños.

En el desarrollo tradicional de software, "sala limpia" significa específicamente que los implementadores nunca han visto el código original. Por ese estándar, esto no lo es.

Un comentarista en Hacker News lo expresó de manera más cruda: "Fue más bien un intento de fuerza bruta para descomprimir de manera difusa el conocimiento almacenado dentro de la red".

El verdadero costo de la innovación

Los 20.000 dólares en costos de API también merecen contexto. Esa cifra cubre solo los tokens y excluye los miles de millones gastados entrenando el modelo, el trabajo humano que Carlini invirtió construyendo el andamiaje, y las décadas de trabajo de ingenieros de compiladores que crearon las suites de prueba e implementaciones de referencia que hicieron posible el proyecto.

Pero no debería oscurecer lo que el proyecto realmente demuestra. Hace un año, ningún modelo de lenguaje podría haber producido algo cercano a un compilador multi-arquitectura funcional, incluso con este tipo de supervisión y un presupuesto ilimitado.

Entre el entusiasmo y la preocupación

El propio Carlini se sintió conflictuado sobre sus resultados. "Construir este compilador ha sido de lo más divertido que he tenido recientemente, pero no esperaba que esto fuera ni remotamente posible tan temprano en 2026", escribió.

También expresó preocupaciones arraigadas en su carrera previa en pruebas de penetración: "La idea de que programadores desplieguen software que nunca han verificado personalmente es una preocupación real".

Y ahí está el quid de la cuestión. Este experimento nos muestra tanto las posibilidades como los límites de la programación agéntica actual. Los agentes pueden producir código funcional para problemas bien definidos, pero necesitan una supervisión humana sofisticada y se topan con muros de complejidad bastante claros.

La pregunta no es si la IA puede programar. La pregunta es: ¿en qué punto la supervisión necesaria para que funcione se vuelve más costosa que simplemente programar nosotros mismos?