Por Canuto  

Anthropic documentó un experimento que empuja la programación autónoma con IA hacia un nuevo umbral: 16 instancias de Claude trabajando en paralelo para construir, desde cero y en Rust, un compilador de C capaz de compilar el kernel de Linux 6.9. El resultado, logrado tras casi 2.000 sesiones y un gasto cercano a USD $20.000, no solo pone sobre la mesa una nueva forma de ingeniería con “equipos de agentes”, sino también preguntas incómodas sobre calidad, límites técnicos y seguridad del software generado sin supervisión humana continua.
***

  • Anthropic encargó a 16 agentes de Claude escribir un compilador de C en Rust y reportó que logró construir Linux 6.9 para x86, ARM y RISC-V.
  • El proyecto consumió cerca de 2.000 sesiones de Claude Code y costó casi USD $20.000, con 2.000 millones de tokens de entrada y 140 millones de salida.
  • El experimento dejó lecciones sobre pruebas, CI y paralelismo, pero también evidenció límites: dependencia parcial de GCC, ausencia de ensamblador y enlazador propios, y código generado poco eficiente.

 

Un experimento de programación autónoma que apunta al “software a escala”

Anthropic publicó un informe técnico firmado por Nicholas Carlini, investigador del equipo de salvaguardias, en el que describe un enfoque de supervisión y ejecución para modelos de lenguaje llamado “equipos de agentes”. La idea central consiste en ejecutar múltiples instancias de Claude en paralelo, trabajando sobre una base de código compartida, sin intervención humana activa durante la ejecución cotidiana.

Para poner el enfoque a prueba, Carlini encargó a 16 agentes construir un compilador de C basado en Rust, desde cero, con una meta que funciona como prueba de estrés: que el resultado pudiera compilar el kernel de Linux. Según el reporte, tras casi 2.000 sesiones de Claude Code y un costo total cercano a USD $20.000, el equipo produjo un compilador de 100.000 líneas que construye Linux 6.9 en x86, ARM y RISC-V.

El texto enfatiza que el compilador es un artefacto interesante por sí mismo, pero el objetivo del experimento fue extraer aprendizajes sobre el diseño de arneses para agentes autónomos de larga duración. En particular, el foco está en cómo escribir pruebas que mantengan a los agentes en el camino, cómo estructurar el trabajo para paralelizar avances y en qué puntos aparece el límite práctico de este esquema.

Para el público de tecnología, IA y mercados, la historia toca una fibra sensible: si la programación pasa de ser un proceso artesanal a una “capacidad industrial” operada por agentes, el costo marginal de producir software podría caer. Esa promesa es atractiva para startups y corporaciones, pero también eleva el impacto de errores, regresiones o vulnerabilidades cuando nadie revisa manualmente cada cambio.

Cómo Anthropic habilitó “Claudes de larga duración” con un bucle simple

El punto de partida, según Carlini, es que andamiajes existentes como Claude Code suelen asumir un operador humano disponible. En tareas largas, el modelo puede resolver una parte, pero luego tiende a detenerse y esperar una nueva instrucción, una aclaración o una actualización del estado.

Para sostener el progreso autónomo, el autor diseñó un arnés que coloca a Claude en un bucle. Cuando una tarea termina, el sistema dispara inmediatamente la siguiente sesión. El informe incluye un ejemplo de script que corre de forma continua y redirige la salida a archivos de registro, junto con una advertencia explícita: debe ejecutarse en un contenedor, no en una máquina real.

El prompt del agente, explica, le pide a Claude dividir el problema en partes pequeñas, llevar seguimiento de lo que hace, decidir qué sigue y continuar hasta que “esté perfecto”. Aun así, el texto admite fallos curiosos propios de la automatización: en un caso, Claude ejecutó un comando para terminar procesos y se “mató” a sí mismo, cortando el bucle.

Más allá de la anécdota, el enfoque revela una tensión típica de la IA aplicada a ingeniería: cuando se quita al humano del medio, cualquier error operacional puede tener efectos acumulativos. En un entorno corporativo, esos riesgos suelen mitigarse con permisos mínimos, entornos efímeros y auditoría, aspectos que el propio autor sugiere al recomendar el uso de contenedores.

Paralelismo con Docker y Git: coordinación sin orquestador

El reporte sostiene que correr múltiples instancias en paralelo ataca dos debilidades de un agente único: una sesión solo puede hacer una cosa a la vez, y la especialización se vuelve difícil. Con varios agentes, algunos pueden depurar mientras otros documentan, mejoran rendimiento o realizan tareas puntuales.

La implementación descrita es deliberadamente “rudimentaria”. Se crea un repositorio Git vacío y, para cada agente, se inicia un contenedor Docker con el repositorio montado como upstream. Cada agente clona una copia local, trabaja y empuja cambios a ese upstream cuando termina.

Para evitar que dos agentes resuelvan el mismo problema en simultáneo, el arnés usa un mecanismo de bloqueo basado en archivos de texto dentro de un directorio de tareas. Un agente reclama una tarea escribiendo un archivo, y si otro intenta reclamar lo mismo, la sincronización con Git fuerza al segundo a elegir una tarea distinta. Luego el agente integra cambios, resuelve conflictos de fusión, empuja y elimina el bloqueo.

Un dato clave es lo que no existe en el sistema: no hay un agente de orquestación, ni un canal adicional de comunicación entre agentes, ni un proceso formal de objetivos de alto nivel. El autor explica que deja que cada Claude decida qué hacer, y que en muchos casos el modelo toma el “siguiente problema más obvio”, manteniendo documentos de intentos fallidos y pendientes.

La lección principal: pruebas de altísima calidad o el agente optimiza lo equivocado

Para Carlini, el bucle infinito solo sirve si el agente sabe cómo avanzar. Por eso, la mayor parte del esfuerzo se concentró en el entorno: pruebas, scripts, retroalimentación y mecanismos para orientar a Claude sin supervisión humana constante.

Una recomendación central del informe es escribir pruebas “casi perfectas”. Si el verificador está mal diseñado, el modelo puede resolver el problema incorrecto, y lo hará con eficiencia. Mejorar el arnés de prueba implicó encontrar conjuntos de pruebas de compiladores de alta calidad, construir verificadores y scripts para compilar paquetes de código abierto, y observar los modos de falla para crear nuevas pruebas específicas.

Cerca del final del proyecto, el reporte dice que Claude comenzó a romper funcionalidad existente cada vez que implementaba una nueva función. Para contener ese patrón, el autor construyó una canalización de integración continua y aplicó reglas más estrictas, con el objetivo de impedir que nuevos commits dañaran el comportamiento ya conseguido.

Este punto resuena más allá del caso del compilador. En cualquier sistema con agentes, la prueba se convierte en el “contrato” que gobierna la conducta. En mercados de software, esto se traduce en una conclusión directa: el capital invertido se mueve desde escribir código hacia diseñar validaciones, pruebas y controles de calidad que eviten resultados engañosos.

Diseñar para las limitaciones del modelo: contexto y “ceguera de tiempo”

Otra lección del informe se resume en “ponerse en los zapatos de Claude”. Cada agente arranca en un contenedor nuevo y sin contexto, y el autor observó que el modelo debe invertir tiempo en ubicarse, sobre todo en proyectos grandes. Para reducir fricción, incluyó instrucciones para mantener archivos README extensos y notas de progreso, con actualizaciones frecuentes.

El documento también enumera limitaciones que deben ser “diseñadas alrededor”. Una es la contaminación de la ventana de contexto: el arnés no debe imprimir miles de bytes inútiles. Según Carlini, conviene mostrar solo unas pocas líneas y guardar el resto en archivos, con formatos fáciles de procesar, por ejemplo marcando errores con la palabra “ERROR” en la misma línea para que herramientas como grep los ubiquen.

Otra limitación es la “ceguera de tiempo”. El informe afirma que Claude no puede decir la hora y, si se le deja solo, puede pasar horas ejecutando pruebas en vez de avanzar. Como mitigación, el arnés imprime progresos incrementales de forma infrecuente y ofrece un modo –fast por defecto, que ejecuta una muestra determinista por agente del 1% o 10%, pero aleatoria entre máquinas virtuales, para cubrir archivos sin saturar el contexto.

En términos de ingeniería de producto, estas decisiones muestran que la autonomía no depende solo del modelo. Depende de la interfaz de retroalimentación, de cómo se resume el estado y de cómo se prioriza el trabajo. Es un recordatorio importante para empresas que adoptan agentes: sin un buen diseño de señales, la IA desperdicia cómputo en acciones de bajo valor.

Cuando el kernel de Linux frenó el paralelismo: GCC como “oráculo”

El paralelismo fue directo cuando existían muchas pruebas independientes fallando. Cada agente podía tomar una falla distinta. Cuando el conjunto alcanzó 99% de éxito, según el reporte, los agentes pasaron a compilar proyectos pequeños y medianos de código abierto, citando ejemplos como SQlite, Redis, libjpeg, MQuickJS y Lua.

Sin embargo, el kernel de Linux presentó un problema diferente. Compilar Linux es una sola tarea enorme, y el informe describe cómo varios agentes se topaban con el mismo error, lo corregían, y luego sobrescribían cambios de otros. En ese escenario, tener 16 agentes no ayudaba, porque todos terminaban trabajando en lo mismo.

La solución fue usar GCC como un “oráculo en línea” de compilador conocido bueno. El autor construyó un nuevo arnés que compilaba aleatoriamente la mayor parte del kernel con GCC, y solo el resto con el compilador creado por Claude. Si el kernel compilaba, el problema no estaba en el subconjunto de archivos manejados por Claude. Si fallaba, se refinaba el diagnóstico recompilando partes con GCC.

Ese método permitió que los agentes se repartieran errores por archivos distintos, hasta que el compilador pudo compilar todos. Después, el texto agrega que aún fue necesario aplicar depuración delta para encontrar pares de archivos que fallaban juntos, pero funcionaban por separado. Es un ejemplo concreto de cómo el “paralelismo” también requiere técnicas de particionamiento del problema.

Resultados y cifras: 2.000 sesiones, 2.000 millones de tokens y un compilador de 100.000 líneas

Anthropic presenta el proyecto como un benchmark de capacidades. Carlini afirma que usó el compilador como referencia a lo largo de la serie Claude 4. El plan inicial fue ambicioso: un compilador optimizador desde cero, sin dependencias, compatible con GCC, capaz de compilar el kernel de Linux y diseñado para soportar múltiples backends, con un IR en SSA para habilitar pasos de optimización.

En la evaluación, el informe indica que, en casi 2.000 sesiones durante dos semanas, Opus 4.6 consumió 2.000 millones de tokens de entrada y generó 140 millones de tokens de salida, con un costo total de “poco menos” de USD $20.000. El autor lo califica como un proyecto extremadamente costoso frente a planes comerciales, pero también como una fracción de lo que costaría desarrollarlo solo o con un equipo.

El texto afirma que fue una implementación de “sala limpia”: Claude no tuvo acceso a internet durante el desarrollo y el compilador depende únicamente de la biblioteca estándar de Rust. Además de construir Linux 6.9 arrancable en x86, ARM y RISC-V, el compilador puede compilar QEMU, FFmpeg, SQlite, postgres y redis, y alcanza 99% de éxito en la mayoría de los conjuntos de pruebas de compiladores, incluyendo el conjunto de pruebas de tortura de GCC.

Como guiño cultural para desarrolladores, el reporte señala que también compila y ejecuta Doom. Ese detalle funciona como atajo narrativo: no prueba completitud del estándar, pero sí sugiere un nivel práctico de integración que suele requerir muchas piezas del ecosistema de compilación y ejecución.

Límites reconocidos: dependencia parcial de GCC y eficiencia inferior

El informe es explícito sobre limitaciones. Una de ellas es que el compilador carece del compilador x86 de 16 bits necesario para arrancar Linux desde modo real, por lo que recurre a GCC en esa fase. El texto aclara que los compiladores x86_32 y x86_64 sí son propios.

También reconoce que no tiene su propio ensamblador y enlazador. Según Carlini, esas eran piezas que Claude empezó a automatizar al final, pero todavía resultan defectuosas. Incluso el video de demostración, indica el autor, se produjo usando ensamblador y enlazador de GCC.

Otra limitación es cobertura incompleta: puede construir muchos proyectos, pero no todos. El reporte insiste en que no es un reemplazo completo para un compilador real. Además, el código generado no es eficiente: aun con optimizaciones, produce menos código eficiente que GCC con optimizaciones desactivadas.

Finalmente, el autor evalúa la calidad del código Rust como “razonable”, pero lejos de lo que produciría un programador experto. También afirma que el compilador alcanzó casi el límite de las capacidades de Opus, y que nuevas características o correcciones a menudo rompían funcionalidad existente, un patrón que obligó a reforzar pruebas y disciplina de integración.

Un caso difícil: por qué el x86 de 16 bits se volvió una barrera

El reporte ofrece un ejemplo concreto de una limitación que no se logró resolver: implementar un generador de código x86 de 16 bits para arrancar en modo real. Carlini cuenta que Opus no fue capaz de completar esa parte, a pesar de muchos intentos.

La descripción técnica añade que, aunque el compilador puede generar x86 de 16 bits correcto usando prefijos de opcode 66/67, el resultado compilado supera 60 kb. Eso excede el límite de código de 32k impuesto por Linux, lo que lo vuelve inviable para esa etapa del arranque.

Como consecuencia, el sistema “hace trampa” y llama a GCC para esa fase. El texto aclara que esto aplica solo para x86. Para ARM o RISC-V, el compilador puede compilar completamente por sí mismo.

Este tipo de limitación ilustra un punto frecuente en agentes de software: no basta con lograr “correctitud” en abstracto. También se requiere cumplir restricciones del mundo real, como tamaños máximos, convenciones de herramientas y compatibilidades. Allí, los agentes pueden necesitar más guía, mejores objetivos, o criterios de optimización más estrictos.

Mirando hacia adelante: ambición, productividad y una advertencia de seguridad

Carlini cierra con una lectura evolutiva del trabajo con modelos de lenguaje. Describe una progresión: primero autocompletado en IDEs, luego completar funciones desde docstrings, y después la programación en pareja con agentes como Claude Code. En su visión, los equipos de agentes apuntan a proyectos completos ejecutados de forma autónoma, lo que permitiría a los usuarios ser más ambiciosos.

Al mismo tiempo, el informe subraya que el desarrollo totalmente autónomo trae riesgos reales. Cuando un humano se sienta con el modelo, puede sostener calidad consistente y detectar errores en tiempo real. En cambio, en sistemas autónomos, es fácil ver que las pruebas pasan y asumir que el trabajo está hecho, aunque “rara vez” lo está, según el texto.

El autor conecta esa preocupación con su experiencia previa en pruebas de penetración y explotación de vulnerabilidades en productos de grandes compañías. La idea de desplegar software que nadie verificó personalmente le parece inquietante. La frase no es un rechazo a la tecnología, sino un recordatorio de que la automatización amplifica tanto el bien como el daño.

Anthropic también comparte que el código fuente del compilador está disponible, e invita a descargarlo, leerlo y probarlo. El autor sostiene que la mejor manera de entender lo que los modelos pueden hacer es llevarlos al límite y estudiar dónde empiezan a romperse. En los “próximos días”, agrega, continuará pidiendo a Claude que implemente cambios para intentar abordar limitaciones restantes, lo que sugiere un proyecto vivo y un laboratorio en marcha.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados