00:00:00Компания Anthropic только что совершила нечто грандиозное: они выпустили 16 агентов Claude на волю,
00:00:05чтобы те написали C-компилятор. Спустя две недели непрерывной работы они действительно создали его.
00:00:11Компилятор смог собрать ядро Linux и даже запустить Doom — это впечатляет и было невозможным
00:00:16в старых версиях Opus 4. Однако многие называют это достижение кликбейтом
00:00:22и полуправдой из-за сомнительных методов, которые Anthropic использовала для достижения результата.
00:00:28Так сжульничали ли в Anthropic? Подписывайтесь, и давайте разберемся.
00:00:31Мы разделим это видео на три части. Сначала разберем, как был устроен эксперимент,
00:00:37затем перейдем к ключевым выводам, которые будут полезны любому разработчику,
00:00:42и в конце выясним, можно ли считать результаты валидными. У меня есть мысли
00:00:47о том, как именно Anthropic удалось создать этот компилятор. Проектом руководил Николас
00:00:52Карлини — по-моему, очень талантливый человек. Давайте посмотрим, как он все
00:00:58организовал. Проект находился в директории под названием Upstream, которая была подключена
00:01:03к 16 разным Docker-контейнерам. На схеме их всего четыре, но представьте, что их 16.
00:01:08В каждом контейнере работала версия Claude Code на базе Opus 4.6. Агент
00:01:15клонировал репозиторий Upstream в Workspace, вносил изменения и отправлял
00:01:21их обратно (push). Это было умно: каждый агент работал в изоляции,
00:01:27не мешая остальным. Если возникал конфликт слияния, Claude
00:01:32сам его разрешал и пушил правки в Upstream. Агенты выбирали себе задачи из списка.
00:01:38Я не уверен, создавались ли задачи человеком или самим агентом на основе тестов,
00:01:44но существовал перечень задач с именами, и каждый агент брал новую,
00:01:50создавая для нее отдельную сессию. Чтобы агенты работали долго,
00:01:56использовался цикл Ralph: агент выполнял задачу, пушил в Upstream, брал следующую
00:02:02в новой сессии и так по кругу. Если вы смотрели наше видео о Ralph, то знаете,
00:02:08что для долгой работы агентов нужны четко определенные задачи. Но если одновременно
00:02:13работают 16 агентов, как не дать им взять одну и ту же задачу? Нужна блокировка.
00:02:19Хотя автор об этом не упоминал, это работает так: агент выбирает задачу,
00:02:24создает текстовый файл с ее названием и делает коммит, чтобы заблокировать ее
00:02:30за собой, после чего пушит это в Upstream. Если другой агент выберет ту же задачу
00:02:36и создаст такой же файл, при попытке пуша Git выдаст ошибку,
00:02:42что файл уже существует, и агенту придется взять другую задачу. Именно так
00:02:48Карлини тестировал выносливость долгоживущих агентов на базе Opus 4.6,
00:02:53и результаты поражают. В ходе эксперимента он обнаружил интересные вещи,
00:03:00которые пригодятся любому разработчику. Во-первых, нужно создать тестовую среду
00:03:07или скрипт для прогона разных типов тестов. Когда Ник (мы теперь на "ты")
00:03:12проводил эксперимент, он заметил, что Claude ломал старые функции
00:03:17при работе над новыми. Поэтому он собрал качественный набор тестов
00:03:23из популярных open-source проектов: SQLite, libjpg и Redis. Чтобы не засорять контекст,
00:03:29он настроил вывод только полезных логов — в основном сообщений об ошибках,
00:03:35а все остальные логи сохранял в файл, чтобы Claude мог заглянуть туда при необходимости.
00:03:41Но когда тестов тысячи, их прогон занимал бы у агентов часы,
00:03:47которые можно потратить на полезную работу. И тут Ник придумал кое-что хитрое.
00:03:52Он добавил флаг "fast" в тестовую среду: теперь агент запускал только
00:03:581% или 10% тестов от общего числа. Если каждый из 16 агентов прогонял по 10%,
00:04:05в сумме это давало 160% покрытия — более чем достаточно. При этом
00:04:13набор тестов для каждого агента был рандомизирован, но с фиксированным
00:04:19сидом (seed) для детерминизма. Таким образом, агенты получали разные наборы
00:04:25случайных тестов и вместе проходили весь пакет гораздо быстрее.
00:04:31Следующий прием тоже остроумен, но спорен: использование существующих технологий.
00:04:36До этого агенты успешно гоняли юнит-тесты из open-source проектов,
00:04:41разбивая их на части. Но когда дело дошло до компиляции ядра Linux,
00:04:46все усложнилось: исходники — это не разрозненные тесты. Каждый агент
00:04:53пытался скомпилировать всё целиком, натыкался на ту же ошибку,
00:04:58пытался её исправить и затирал правки коллег. Ник решил это так:
00:05:04каждый агент компилировал лишь часть кода, а остальное доделывал GCC
00:05:09(стандартный компилятор GNU). Ник назвал GCC "оракулом", так как ядро Linux
00:05:15точно должно собираться им идеально. Если при частичной сборке своим компилятором
00:05:22что-то ломалось, виноват был точно агент, а не GCC. Так агент фокусировался
00:05:27на исправлении своих багов, а не чужих. Это спорный момент, ведь Claude
00:05:34должен был написать компилятор с нуля, а тут привлекается готовый.
00:05:40Но об этом позже. Перейдем к следующему пункту: наделите агентов памятью.
00:05:46Поскольку новые задачи выполнялись в свежих сессиях Claude без истории,
00:05:51Ник решил обновлять файл README и вести логи прогресса с инструкциями,
00:05:57на чем остановилась работа. Это давало новым сессиям хорошую базу
00:06:03и помогало избежать повторного внесения уже исправленных багов.
00:06:09И последний, очевидный совет: давайте агентам разные роли.
00:06:13Прелесть параллельной работы в том, что над одним куском кода можно
00:06:18делать несколько вещей сразу. Когда код не писался, Ник давал агентам
00:06:23уникальные задачи: один искал дубликаты, другой оптимизировал производительность,
00:06:29а третий даже критиковал дизайн с позиции Rust-разработчика (надеюсь,
00:06:35он не кричал об этом остальным агентам). Но при всем успехе проекта
00:06:40главный вопрос остается: сжульничали ли в Anthropic? Отчасти — да.
00:06:45Задача была создать C-компилятор с нуля без доступа к интернету, и агент
00:06:51сам писал весь код. Или нет? У него был доступ к тестовым пакетам
00:06:57open-source проектов и к скомпилированному GCC. Технически он мог
00:07:03тестировать GCC, подавая входные данные и изучая результат, чтобы
00:07:10корректировать дизайн своего компилятора на Rust. С другой стороны,
00:07:16если бы я сам писал компилятор с нуля, я бы сделал так же — изучил бы
00:07:24аналоги. Вот если бы речь шла о компиляторе для совершенно нового
00:07:31языка программирования, задача была бы в разы сложнее. Возможно,
00:07:36Нику стоит попробовать именно это. Но давайте поговорим об автономности.
00:07:41Да, Claude написал весь код, но под жестким контролем человека.
00:07:47Человек выбирал тесты, запускал циклы, строил тестовую среду
00:07:53и распределял роли. Это далеко от сценария "попросил и забыл".
00:07:57Я бы не назвал агента полностью автономным, ведь неизвестно,
00:08:04каким бы вышел результат без участия человека. И даже при такой поддержке
00:08:11у компилятора Claude были серьезные ограничения. Например, он использовал
00:08:16ассемблер и линковщик от GCC, потому что его собственные были слишком забагованы.
00:08:22Также ему понадобился 16-битный x86-компилятор от GCC для загрузки Linux.
00:08:28И в довершение — код был неэффективным. Самая оптимизированная версия
00:08:33компилятора Claude работала медленнее, чем самая медленная версия GCC.
00:08:39Так что разработчикам пока не о чем беспокоиться. По крайней мере, сейчас.
00:08:46too buggy. It also needed GCC's 16-bit x86 compiler in order to boot up Linux. And to top that all off,
00:08:54the code wasn't very efficient. The most optimized version of the Claude's compiler was less
00:09:00performant than the least optimized version of the GCC compiler. So it looks like developers
00:09:05aren't going anywhere anytime soon, or at least for now.