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.