$20,000. 2 semanas. 16 agentes Claude. El primer compilador de C de Anthropic creado por IA

BBetter Stack
Computing/SoftwareBusiness NewsVideo & Computer GamesInternet Technology

Transcript

00:00:00Anthropic acaba de hacer algo asombroso: soltaron a 16 agentes de Claude para que construyeran
00:00:05un compilador de C y, tras trabajar sin parar durante dos semanas, lograron uno capaz de compilar
00:00:11el kernel de Linux e incluso ejecutar Doom. Es impresionante y algo que no era posible
00:00:16con las versiones anteriores de Opus 4. Pero muchos dicen que este logro es puro "clickbait"
00:00:22y una verdad a medias por las cuestionables técnicas que usó Anthropic para lograrlo.
00:00:28Entonces, ¿hizo trampa Anthropic? Suscríbete y vamos a descubrirlo.
00:00:31Dividiremos este video en tres partes. Primero, veremos cómo se configuró el experimento;
00:00:37luego, los hallazgos clave que creo que servirán a todo desarrollador,
00:00:42y finalmente, analizaremos si los resultados son válidos, porque tengo mis dudas
00:00:47sobre cómo Anthropic construyó este compilador. Este experimento fue obra de Nicholas
00:00:52Carlini, quien me parece un tipo brillante. Veamos cómo lo organizó todo.
00:00:58El proyecto real vivía en un directorio llamado "Upstream", el cual estaba montado
00:01:03en 16 contenedores Docker diferentes. Aquí solo se ven cuatro, pero imaginemos que son 16.
00:01:08Cada contenedor tenía una versión de Claude Code ejecutando Opus 4.6,
00:01:15clonaba el repo Upstream en su Workspace, hacía los cambios allí y luego
00:01:21los enviaba a Upstream. Fue astuto porque cada agente trabajaba de forma aislada sin
00:01:27afectar a los demás. Si surgía algún conflicto de fusión, Claude era lo bastante
00:01:32inteligente para resolverlo y subirlo a Upstream. Cada agente elegía ciertas tareas.
00:01:38No sé si las tareas las generaba un humano o el mismo agente tras ejecutar pruebas,
00:01:44pero había una lista de tareas con nombre y cada agente tomaba una nueva.
00:01:50Cada vez que tomaba una tarea, se iniciaba una sesión nueva. Para que los agentes
00:01:56siguieran funcionando largo tiempo se usó un bucle Ralph: trabajaban en la tarea,
00:02:02la terminaban, subían los cambios, iniciaban sesión nueva y repetían el proceso.
00:02:08Si viste nuestro video sobre Ralph, sabrás que la clave para agentes de larga duración
00:02:13es tener tareas bien definidas. Pero con 16 agentes a la vez,
00:02:19¿cómo evitas que elijan la misma tarea? Con el bloqueo de tareas.
00:02:24Aunque el autor no lo explica a fondo, existe una lista de tareas; el agente elige una,
00:02:30crea un archivo de texto con el nombre de la tarea y hace un "commit" para bloquearla
00:02:36y subirla a Upstream. Así, solo ese agente trabaja en ella. Si otro elige la misma
00:02:42y crea el mismo archivo, al intentar subirlo a Upstream, Git lo rechazará indicando
00:02:48que el archivo ya existe, obligándolo a buscar otra tarea. Así fue como Carlini
00:02:53puso a prueba la resistencia de los agentes impulsados por Opus 4.6, y los resultados
00:03:00son asombrosos. Pero durante este experimento, descubrió cosas muy interesantes
00:03:07de las que cualquier desarrollador puede aprender. Lo primero es crear un entorno
00:03:12de pruebas o un script que ejecute varios tests, porque cuando Nick —ya
00:03:17somos amigos— hacía el experimento, Claude rompía funciones ya creadas al trabajar en una nueva.
00:03:23Así que creó un entorno de pruebas con tests de alta calidad de repositorios famosos como
00:03:29SQLite, libjpg y Redis. Para no saturar el contexto del modelo, se aseguró de que
00:03:35el entorno solo mostrara logs útiles (errores) y guardara el resto en un archivo aparte
00:03:41para que Claude lo consultara si era necesario. No obstante, con miles de pruebas,
00:03:47los agentes tardarían horas en ejecutarlas todas en lugar de estar produciendo.
00:03:52Aquí Nick fue muy ingenioso: añadió una bandera de "vía rápida" a su entorno de pruebas,
00:03:58haciendo que cada agente ejecutara solo el 1% o el 10% de los tests según Nick decidiera.
00:04:05Si cada agente corría el 10%, cubrían el 160% de los tests, lo cual es excelente.
00:04:13El truco estaba en que los tests específicos
00:04:19que ejecutaba cada agente eran aleatorios, pero con la misma semilla para que
00:04:25fueran deterministas. Así, cada agente hacía tests distintos y, entre todos, cubrían
00:04:31toda la suite mucho más rápido que si uno solo lo hiciera todo. El siguiente
00:04:36punto es brillante, aunque polémico, ya que implica usar tecnología que ya existe.
00:04:41Hasta ahora, cada agente ejecutaba pruebas unitarias de otros proyectos de código abierto,
00:04:46lo cual funcionaba bien al dividirlas en bloques. Pero al compilar el kernel de Linux,
00:04:53al no ser pruebas unitarias individuales, la cosa se complicó porque cada agente
00:04:58intentaba compilarlo todo, encontraba el mismo error y trataba de corregirlo pisando el trabajo ajeno.
00:05:04Nick lo solucionó haciendo que cada agente compilara solo un porcentaje
00:05:09y dejando que GCC (el compilador de GNU) se encargara del resto. Nick llamó a GCC
00:05:15"el oráculo", pues el kernel de Linux debería compilarse perfectamente con él.
00:05:22Si un agente compilaba una sección del kernel con su propio compilador
00:05:27y el resto con GCC, si algo fallaba, la culpa era sin duda del compilador del agente
00:05:34y no de GCC; así el agente corregía ese error específico sin interferir con otros.
00:05:40Esto es polémico porque se usó un compilador existente para algo que Claude
00:05:46debía hacer desde cero. Hablaremos más de esto al final del video.
00:05:51Pasemos al siguiente punto: darle memoria a tu agente. Como las nuevas tareas las
00:05:57hacían sesiones de Claude nuevas sin recuerdo de lo anterior, Nick vio que era
00:06:03útil actualizar el archivo "readme" y tener archivos de progreso con instrucciones
00:06:09sobre dónde se quedaron y el avance del proyecto. Así, las nuevas sesiones tenían
00:06:13una base sólida y no repetían errores ya corregidos. Y el último punto,
00:06:18más obvio, es asignar roles. La ventaja de tener varios agentes trabajando
00:06:23en paralelo es que pueden hacerse varias cosas al mismo código a la vez.
00:06:29Cuando no se escribía código nuevo, Nick asignaba roles únicos como
00:06:35buscar código duplicado, optimizar el rendimiento al máximo o incluso
00:06:40criticar el diseño desde la perspectiva de un desarrollador de Rust (espero que no
00:06:45lo anduviera presumiendo). Pero a pesar del éxito, la gran pregunta es:
00:06:51¿Hizo trampa Anthropic? Bueno, un poco. La tarea era construir un compilador
00:06:57de C desde cero y el agente no tenía internet, por lo que él creó todo el código.
00:07:03¿O no? Porque sí tenía acceso a suites de pruebas de otros proyectos y a la
00:07:10versión compilada de GCC. Técnicamente pudo haber examinado a fondo GCC,
00:07:16dándole entradas y analizando salidas para guiar el diseño de su propio
00:07:24compilador escrito en Rust. Pero seamos honestos: si yo hiciera un compilador de C
00:07:31desde cero, haría lo mismo. Miraría otros compiladores, vería cómo están hechos
00:07:36y usaría eso para orientar el mío. Ahora, si estuviera creando un compilador para
00:07:41un lenguaje totalmente nuevo, sería mucho más difícil y esa sería una prueba
00:07:47excelente para ver si Claude es capaz de crear compiladores desde cero.
00:07:53Quizás sea otra idea para Nick, pero hablemos de la autonomía del experimento,
00:07:57que también se puso a prueba. Es cierto que Claude escribió el código, pero
00:08:04con mucha guía humana. Un humano decidió qué pruebas correr, inició el bucle,
00:08:11decidió usar Ralph, construyó el entorno de pruebas y asignó los roles específicos.
00:08:16Así que, aunque no es simplemente pedirle a Claude que haga un compilador y ya,
00:08:22tampoco diría que el código fue escrito por un agente 100% autónomo,
00:08:28porque ¿qué tan bueno habría sido el compilador sin la intervención humana?
00:08:33Incluso con todos los sistemas diseñados por Nick, el compilador de Claude
00:08:39tuvo limitaciones clave. Por ejemplo, usó el ensamblador y el enlazador de GCC
00:08:46porque los que creó fallaban mucho. También necesitó el compilador x86 de 16 bits de GCC
00:08:54para arrancar Linux. Y para colmo, el código no era muy eficiente.
00:09:00La versión más optimizada del compilador de Claude era menos potente que
00:09:05la menos optimizada de GCC. Así que parece que los programadores no nos iremos a ningún lado... por ahora.

Key Takeaway

Aunque Anthropic logró un hito al crear un compilador funcional de C mediante agentes de IA en paralelo, el éxito dependió profundamente de la guía humana y de la utilización de herramientas de software ya existentes como puntos de referencia.

Highlights

Uso coordinado de 16 agentes de Claude Opus 4.6 trabajando en contenedores Docker aislados durante dos semanas.

El compilador desarrollado fue capaz de compilar el kernel de Linux y ejecutar el videojuego Doom.

Implementación de un sistema de bloqueo de tareas mediante archivos de texto y commits de Git para evitar conflictos.

Estrategia de 'vía rápida' en las pruebas donde cada agente ejecutaba una subserie aleatoria y determinista de tests.

Uso de GCC como un 'oráculo' para validar secciones específicas del código y aislar errores en el compilador de la IA.

Necesidad de intervención humana crítica para la arquitectura del entorno de pruebas

Timeline

Introducción y configuración del experimento de Anthropic

El video comienza detallando la hazaña de Anthropic: el despliegue de 16 agentes Claude para construir un compilador de C en solo 14 días. Este sistema utilizó contenedores Docker y un repositorio central denominado "Upstream" para gestionar el flujo de trabajo distribuido. El narrador explica que cada agente operaba de forma aislada para no interferir con el progreso de los demás, utilizando Claude Code para resolver conflictos de fusión automáticamente. Esta sección es fundamental para entender la escala técnica y el costo de 20,000 dólares invertidos en potencia de cómputo. La introducción también plantea la duda sobre si los resultados son genuinos o simplemente una estrategia de marketing engañosa.

Gestión de tareas y el ciclo de vida de los agentes

En esta etapa se profundiza en la logística operativa diseñada por Nicholas Carlini para mantener la productividad de los agentes. Se introdujo un bucle tipo "Ralph" donde los agentes tomaban tareas de una lista, las completaban y reiniciaban sesiones para evitar la degradación del contexto. Para prevenir que varios agentes trabajaran en lo mismo, se implementó un sistema de bloqueo basado en la creación de archivos de texto específicos en el repositorio. Si un agente intentaba subir una tarea ya ocupada, el sistema de Git rechazaba el cambio, obligándolo a buscar un nuevo objetivo. Este método garantizó una resistencia y autonomía operativa sin precedentes en modelos de lenguaje de gran tamaño.

Estrategias de pruebas y optimización del entorno

El análisis se centra aquí en cómo Carlini evitó que Claude rompiera funciones previamente validadas mediante un entorno de pruebas de alta calidad. Se integraron suites de tests de proyectos reconocidos como SQLite y Redis, pero filtrando los logs para no saturar el contexto del modelo. La innovación principal fue la bandera de "vía rápida", que permitía a cada agente correr solo una fracción aleatoria de los miles de tests disponibles. Al usar una semilla determinista, los agentes cubrían colectivamente el 160% de la suite total de pruebas en una fracción del tiempo habitual. Esta optimización fue clave para mantener un ritmo de desarrollo constante sin desperdiciar recursos en ejecuciones redundantes.

El dilema del oráculo y el uso de GCC

Esta sección aborda uno de los puntos más polémicos del experimento: la integración de GCC como referencia externa. Cuando la compilación del kernel de Linux se volvió demasiado compleja para los agentes individuales, Nick decidió que Claude compilaría solo ciertas partes mientras GCC manejaba el resto. Al tratar a GCC como un "oráculo", los agentes podían identificar con precisión si un fallo provenía de su propio código o del entorno externo. Aunque fue una solución ingeniosa para avanzar en el proyecto, genera dudas sobre la pureza de la creación desde cero. El narrador destaca que este método permitió corregir errores específicos sin que los agentes pisaran el trabajo de sus compañeros de equipo.

Asignación de roles, memoria y conclusiones finales

El tramo final del video discute la importancia de asignar roles específicos como optimizadores de rendimiento o críticos de diseño basados en Rust. También se destaca el uso de archivos "readme" actualizados para proporcionar una memoria persistente a las nuevas sesiones de los agentes. Sin embargo, el autor concluye que Anthropic "hizo trampa" parcialmente al depender de la estructura y lógica de compiladores existentes y una supervisión humana constante. El compilador resultante mostró ser menos eficiente que GCC y requirió herramientas de terceros para tareas críticas como el enlazado. En última instancia, el experimento demuestra el potencial de la IA colaborativa, pero confirma que la autonomía total en tareas de ingeniería compleja aún no se ha alcanzado.

Community Posts

View all posts