16 агентов Claude за две недели написали C-компилятор на 100 000 строк за $20 000

Исследователь команды Safeguards в Anthropic Николас Карлини провёл эксперимент: 16 экземпляров Claude Opus 4.6 работали параллельно над общим репозиторием и писали на Rust компилятор C с нуля. Человек почти не вмешивался. За две недели и около 2000 сессий Claude Code агенты выдали 100 000 строк кода. Компилятор собирает загружаемое ядро Linux 6.9 на x86, ARM и RISC-V. Счёт за API составил чуть меньше $20 000.

Как устроена связка агентов

Основа схемы проста. Claude запускается в бесконечном цикле: закончил задачу — берёт следующую. Каждый агент живёт в отдельном Docker-контейнере, клонирует общий bare git-репозиторий и пушит туда изменения. Чтобы агенты не решали одно и то же, используются блокировки: Claude создаёт текстовый файл вроде current_tasks/parse_if_statement.txt, а git не даёт второму агенту занять ту же задачу. Конфликты слияния случаются часто, но модель разбирается с ними сама.

Оркестратора нет, общих каналов связи между агентами тоже нет. Каждый сам решает, что делать дальше, обычно берёт «следующую самую очевидную» проблему. Один раз агент случайно выполнил pkill -9 bash и прервал собственный цикл.

Основные усилия ушли не на промпты, а на окружение: тесты, логи, обратная связь. Вывод тестов ограничен несколькими строками, чтобы не засорять контекст. Ошибки пишутся в одну строку с меткой ERROR для grep. Для борьбы со «слепотой ко времени» добавлена опция --fast, которая прогоняет детерминированную для агента выборку в 1% или 10% тестов.

Где упёрлись в потолок

Пока тесты независимы, параллелить просто: каждый берёт свой упавший тест. Но ядро Linux — одна гигантская задача. Все 16 агентов натыкались на одну и ту же ошибку и перезаписывали правки друг друга. Выход нашли через GCC как эталонный оракул: случайную часть файлов ядра компилировал GCC, остальное — Claude. Так агенты стали чинить разные баги в разных файлах. Для пар файлов, которые ломались только вместе, применили delta debugging.

Также агентам назначили роли: один сводил дублирующийся код, другой ускорял сам компилятор, третий занимался эффективностью генерируемого кода, четвёртый выступал критиком архитектуры с позиции Rust-разработчика, пятый вёл документацию.

Цифры и ограничения

• Объём: около 100 000 строк на Rust, без зависимостей кроме стандартной библиотеки.
• Ресурсы: 2 млрд входных и 140 млн выходных токенов, почти $20 000.
• Тесты: 99% на большинстве наборов, включая GCC torture.
• Собирает: Linux 6.9 (x86, ARM, RISC-V), QEMU, FFmpeg, SQLite, Postgres, Redis, Doom.
• Чистая комнатная разработка: у Claude не было доступа к интернету.
• Без своего ассемблера и линкера: эти модули автоматизировали последними, они всё ещё глючат.
• 16-битный x86 для real mode не реализован: вывод превышает 60 КБ при лимите ядра 32 КБ, поэтому вызывается GCC.
• Код менее эффективен, чем у GCC даже с отключёнными оптимизациями.

Карлини прямо пишет, что компилятор почти упёрся в предел возможностей Opus: новые функции и исправления регулярно ломали старое. Прогресс по линейке заметен: ранние Opus 4 едва справлялись с рабочим компилятором, Opus 4.5 впервые прошёл крупные тестовые наборы, но не собирал реальные проекты.

Практические выводы

Главный урок для тех, кто строит автономных агентов: качество проверяющего механизма важнее самой модели. Если верификатор неточен, агент уверенно решит не ту задачу. Поэтому тесты нужно писать с расчётом на модель: короткий вывод, grep-совместимые логи, быстрые детерминированные подвыборки, CI, не дающий ломать прошлые коммиты.

Второе: параллелизм требует декомпозиции. Если задача монолитна, лишние агенты только мешают, а известный рабочий эталон помогает разрезать её на независимые части.

Третье: $20 000 за компилятор уровня Linux-сборки намного дешевле команды инженеров, но всё же дороже подписки. Код опубликован, и его можно проверить на своих C-проектах. Сам автор оговаривается: полностью автономная разработка несёт реальные риски, и без человеческого контроля качества кода и безопасности пока не обойтись.