16 agentes de Claude y un compilador de C: qué hizo posible el experimento

El 5 de febrero de 2026, el investigador de Anthropic Nicholas Carlini publicó los resultados de un experimento con 16 instancias de Claude Opus 4.6: durante dos semanas y casi 2.000 sesiones, escribieron un compilador de C en Rust. El relato técnico original de Anthropic cifra el consumo en 2.000 millones de tokens de entrada, 140 millones de salida y algo menos de 20.000 dólares de API. El artefacto tenía unas 100.000 líneas y podía construir Linux 6.9 para x86, ARM y RISC-V.

Ese resultado no demuestra que 16 agentes sustituyan a un equipo ni que el software estuviera listo para producción. Demuestra algo más preciso: un sistema de agentes puede avanzar durante mucho tiempo cuando el objetivo se divide, existe un verificador que devuelve señales útiles y el entorno limita el daño. La capacidad transferible es aprender a evaluar ese sistema completo —modelo, arnés, pruebas, permisos y revisión— en vez de atribuir el resultado al modelo aislado.

Qué contó realmente el experimento

Cada agente trabajaba dentro de un contenedor Docker, clonaba un repositorio local y reclamaba una tarea mediante un archivo. Git servía para sincronizar cambios: si dos agentes intentaban tomar el mismo trabajo, el conflicto obligaba al segundo a escoger otro. No había un agente central que asignara cada paso. Sí había una arquitectura humana previa que convertía una ambición abierta en trabajo observable.

El bucle podía volver a iniciar Claude tras cada sesión, de modo que una ejecución terminada no detenía el proyecto. El prompt pedía dividir el problema, registrar el progreso y elegir la siguiente tarea. Carlini advierte expresamente que ese tipo de bucle debe ejecutarse en un contenedor, no en la máquina real. Persistencia no es seguridad: repetir un agente defectuoso solo repite sus posibilidades de error.

El resultado se sometió a pruebas más informativas que el recuento de líneas. Según el informe, podía construir un kernel Linux 6.9 arrancable en tres familias de arquitectura, además de proyectos como QEMU, FFmpeg, SQLite, PostgreSQL y Redis. Alcanzó un 99% en la mayoría de las suites de compiladores utilizadas, incluida GCC Torture, y compiló y ejecutó Doom. Cada cifra describe el conjunto ensayado; no equivale a compatibilidad completa con el lenguaje C ni con todo programa existente.

El oráculo fue la pieza decisiva

Cuando los agentes intentaron compilar el kernel entero, todos chocaron con el mismo fallo. El paralelismo no ayudaba: 16 procesos perseguían un único obstáculo y podían pisarse. Carlini cambió el verificador. Usó GCC como oráculo conocido y compiló aleatoriamente la mayoría de archivos con GCC y un subconjunto con el nuevo compilador. Si el kernel funcionaba, el defecto no estaba en ese subconjunto; si fallaba, podía reducirse.

Ese diseño transformó un “funciona o no” gigante en muchos indicios localizables. Después aún fue necesario aplicar depuración delta para encontrar pares de archivos que funcionaban por separado y fallaban juntos. La lección no es que más agentes resuelvan cualquier problema, sino que el trabajo paralelo necesita unidades separables y una señal que atribuya el error.

Un buen verificador cumple tres condiciones. Mide lo que importa, localiza el fallo con suficiente precisión y es más difícil de engañar que la tarea. En código, compilar no basta: deben ejecutarse pruebas de comportamiento, análisis estático, comprobaciones de seguridad y casos de regresión. Si la métrica recompensa una salida superficial, un agente persistente puede optimizar la apariencia de éxito.

Los límites forman parte del resultado

La versión descrita en febrero no tenía un generador x86 de 16 bits capaz de arrancar Linux desde modo real y delegaba esa fase en GCC. Su ensamblador y enlazador seguían siendo problemáticos; no construía todos los proyectos; el código generado era menos eficiente que el de GCC incluso con las optimizaciones de GCC desactivadas; y la calidad del Rust quedaba lejos de la de un especialista. Añadir funciones y corregir errores rompía con frecuencia capacidades anteriores.

Estas limitaciones impiden resumir “compila Linux” como “reemplaza a GCC”. Compilar un kernel es una prueba importante, pero la madurez de un compilador incluye corrección semántica, diagnósticos, compatibilidad, rendimiento del código, estabilidad y mantenimiento. El propio repositorio público del compilador advierte que no recomienda usar el código y que no había sido validado para corrección. También permite inspeccionar el artefacto en lugar de confiar solo en la narración.

Conviene fechar cualquier observación del repositorio. Un proyecto vivo puede recibir miles de cambios después del experimento, por lo que su estado actual no prueba qué produjo exactamente la ejecución inicial. Una evaluación reproducible fija un commit, un entorno, las suites, los comandos y los resultados. Sin ese corte, el éxito posterior puede atribuirse retroactivamente a los agentes originales.

Autonomía no significa ausencia de trabajo humano

Carlini no se sentó a depurar cada función con Claude. Su intervención estuvo en otro nivel: definió la arquitectura deseada, construyó el bucle, creó pruebas, mejoró la señal cuando los agentes se atascaron y decidió qué contaba como éxito. Llamar a eso “mucha supervisión” puede sugerir vigilancia continua que el informe no describe; llamarlo “sin humanos” oculta el diseño del experimento. La formulación correcta separa ejecución autónoma de ingeniería del entorno.

Para comparar con un equipo humano habría que incluir el mismo denominador: coste de API, cómputo, horas de diseño del arnés, revisión, mantenimiento futuro y valor del conocimiento previo incorporado a pruebas y herramientas. Los casi 20.000 dólares son una cifra verificable de API, no el coste total de desarrollar y operar un compilador ni una estimación salarial equivalente.

También hay un sesgo de selección útil de reconocer. Un compilador dispone de especificaciones, implementaciones de referencia y grandes suites de pruebas. Muchos proyectos empresariales comienzan con requisitos contradictorios, datos incompletos y criterios que cambian. Cuanto menos observable sea “correcto”, más trabajo humano se desplaza desde escribir código hacia diseñar y mantener el verificador.

Cómo trasladarlo a un proyecto real

Antes de lanzar agentes en paralelo, se escribe un contrato de éxito ejecutable. Cada tarea debe tener entradas, límites, pruebas y un dueño de integración. Las tareas se escogen para que puedan avanzar sin modificar las mismas superficies. Un registro guarda qué agente reclamó qué, qué commit produjo, qué pruebas ejecutó y qué artefactos dejó. Si dos agentes se bloquean mutuamente, el sistema debe reasignar o reducir el problema.

Después se limita el radio de daño. La arquitectura de aislamiento descrita por Anthropic separa el acceso al sistema de archivos del acceso de red: permitir solo uno deja vías para exfiltrar datos o escapar mediante contenido descargado. Un agente de pruebas puede escribir en su copia de trabajo y hablar con un registro concreto; no necesita secretos personales, producción ni autoridad para borrar recursos externos.

La aprobación humana tampoco debe aparecer en cada comando rutinario, porque la fatiga convierte el botón en reflejo. En su análisis posterior sobre cómo contener agentes en distintos productos, Anthropic explica que el aislamiento del sistema operativo permite autorizar un espacio limitado y reservar la intervención para excepciones. La revisión se coloca en fronteras con consecuencias: ampliar red, leer secretos, fusionar cambios, desplegar o borrar.

Finalmente, se ensaya el fallo antes de aumentar el paralelismo. Se rompe una prueba, se fuerza un conflicto, se corta una dependencia y se introduce una instrucción maliciosa en un archivo. El sistema debe conservar trazas, detenerse sin destruir trabajo y permitir reconstruir por qué aceptó un cambio. Dieciséis agentes multiplican el rendimiento posible, pero también las acciones y la superficie que auditar.

La pregunta que queda después del titular

El experimento no fija un “muro” universal en 100.000 líneas: esa cifra pertenece a un artefacto y una configuración. Tampoco demuestra desarrollo autónomo general. Sí prueba que un modelo de 2026, rodeado de un bucle persistente, aislamiento, control de versiones y un oráculo fuerte, pudo producir y mejorar un sistema de software grande durante miles de sesiones.

La conclusión útil para otro proyecto es operacional: antes de contratar más agentes, invierta en hacer observable la corrección. Si una prueba localiza el error, los permisos contienen el daño y cada cambio es reversible, el paralelismo puede aportar. Si nadie puede decir con precisión qué significa terminar bien, 16 agentes solo llegan más deprisa al problema equivocado.