Opus 4.6 и команда ИИ-агентов написала компилятор С за 2 недели

Исследователь Anthropic Николас Карлини провёл эксперимент с так называемыми agent teams — группой автономных LLM-агентов, которые работают над одним проектом без постоянного участия человека.

В качестве стресс-теста он запустил 16 экземпляров Claude Opus 4.6 и поручил им написать компилятор С на Rust с нуля. Цель была следующей: компилятор должен уметь собирать Linux kernel. После почти 2000 сессий, двух недель работы и затрат около 20 000 долларов агенты выдали кодовую базу на ~100 000 строк, которая действительно собирает Linux 6.9 под x86, ARM и RISC-V.

Человек почти не вмешивался. Claude работал в бесконечном цикле: завершал задачу, брал следующую. Каждый агент запускался в отдельном контейнере, клонировал общий репозиторий, брал «лок» на конкретную подзадачу через файл в git, вносил изменения и пушил результат. Конфликты случались часто, но модель в большинстве случаев справлялась с их разрешением самостоятельно.

Ключевая часть эксперимента оказалась не в самом компиляторе, а в инфраструктуре вокруг него. Без хороших тестов агенты быстро начинали «чинить не то». В итоге основная работа исследователя свелась к проектированию тестовых harness’ов, CI и формату логов так, чтобы модель могла ориентироваться без подсказок. Например, вывод тестов специально делали коротким, с явными маркерами ошибок, а тяжёлые проверки запускались в случайной, но детерминированной подвыборке.

Параллельность работала хорошо, пока задачи были независимыми. Когда агенты дошли до сборки ядра Linux, все упёрлись в одни и те же баги. Решением стало использование GCC как «оракула»: часть файлов компилировалась эталонным компилятором, часть новым, что позволило локализовать ошибки и снова распараллелить работу.

В итоге компилятор собирает Linux, QEMU, FFmpeg, SQLite, Redis и даже Doom, но с оговорками. Нет собственного ассемблера и линкера, 16-битный x86 кодогенератор не реализован, производительность кода ниже GCC, а добавление новых фич часто ломает старые.

Русскоязычное сообщество про AI в разработке

Друзья! Эту новость подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!

@python_leader
06.02.2026 00:22 UTC
Первоисточник

Комментарии

@MEGA_Nexus
05.02.2026 20:04 UTC
+18

добавление новых фич часто ломает старые.

Иными словами за 20 000$ получили одноразовый код.

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

@xaoc80
05.02.2026 20:09 UTC
+9

20000$ - это затраты на агентов, надо полагать. ЗП самой команды в таких случаях, как правило, не считают

@st---v
05.02.2026 21:29 UTC
+1

"там нет структуры и логики" - это вы исходники данного компилятора изучили, что бы сделать такой вывод? или это ваше предположение?
PS: проблема переписывания работающего кода ИИ-чат-ботами, по моим наблюдениям, была исправлена ещё полгода назад.

05.02.2026 22:26 UTC
+6

PS: проблема переписывания работающего кода ИИ-чат-ботами, по моим наблюдениям, была исправлена ещё полгода назад.

По моим - еще вчера во всяком случае точно исправлена не была. Может сегодня конечно поменялось что..

@Dmitriila
05.02.2026 21:51 UTC
0

Они решили изобрести 1С

@Error1024
05.02.2026 22:02 UTC
+1

Исходники любого компилятора - это не возможный для поддержки код, без структуры и логики. Специфика такая.

05.02.2026 22:54 UTC
0

Не соглашусь, GCC живёт и поддерживается уже почти сорок лет. Не будь там структуры и логики, фиг бы он пережил 90-е.

05.02.2026 23:15 UTC
+3

Загляните в исходники GCC, а потом в CCC и сделайте выводы сами. Признаться честно у CCC они не самые "нечитаемые" среди виденных мною homebrew компиляторов.

06.02.2026 10:06 UTC
0

Да, я глянул и исходники GCC, и глянул на Claude's C Compiler.

Если в коде GCC - везде аккуратные "кирпичики" из небольших чистых функций. то CCC - "шлакоблоки" копипасты и отмазок.

Хм, а не является ли код CCC частично следствием отравления контекста агентов "Мы пишем компилятор для C", отчего они и путались между Rust/C?

А вообще, нужен следующий эксперимент: 32 Клода, которые два месяца будут рефакторить и переписывать CCC до идиоматического чистого Rust, с фокусом на логику и структуру проекта. :)

@YoungSkipper
05.02.2026 22:18 UTC
+1

Через 2 года это будет стоить 200 долларов и знимать два дня. И подобный одноразовый код станет обыденностью -- если нужно будет поправить что-то то проще будет написать с нуля, чем что либо разбирать.

05.02.2026 22:24 UTC
+11

Через 2 года это будет стоить 200 долларов

или 200000

06.02.2026 21:59 UTC
+1

Про 2 года - это настолько смелый предмет, достойный фанатика или уровня СЕО компании, заинтересованного в инвестициях.

Замедление прогресса и упор "потолок" уже виден невооружённым взглядом. Даже заинтересованные СЕО "смещают" свои обещания на более поздние сроки.

Трезво оценивая: текущий уровень уже неплох, а рассчитывать на 100 кратное улучшение (удешевление) - ну очень оптимистично.

@house2008
06.02.2026 03:49 UTC
+4

Иными словами за 20 000$ получили одноразовый код.

В этом видимо и вся прелесть для создателей ЛЛМок, все напишут неподдерживаемый софт, и потом чтобы расширить функциональность или пофиксить баги проще с ноля всё еще раз написать опять за 20к$. Нужно отдать должное, это гениальный бизнес план.

@davidaxxon
05.02.2026 20:07 UTC
+5

Так и запишем

"Модель Opus 4.6 доказала свою неспособность доводить проекты до ума без пинков от живого эксперта"

@fahitos44
05.02.2026 20:46 UTC
0

У курсора вот недавно тоже было нечто похожее

https://habr.com/ru/amp/publications/985330/

@Dhwtj
05.02.2026 21:48 UTC
0

Слэш лишний в конце

Нет, там вообще не пытались пройти формальные тесты. Тут хоть пытались

@Vedomir
06.02.2026 09:07 UTC
+2

Насколько я помню, когда народ взял этот репозиторий и попробовал его скомпилировать, выяснилось что это не получается и сыплются десятки ошибок. Что не помешало заявить о грандиозном успехе ИИ.

@15432
05.02.2026 20:48 UTC
+4

Не забываем, что LLMки обучались в том числе и на коде компиляторов, то есть, у них уже был готовый рабочий исходник "в голове"

@wmns
05.02.2026 21:15 UTC
+2

Давайте говорить как есть: они его просто взяли и скопипастили. Списывали две недели, ещё и тыкать носом в тетрадь приходилось.

05.02.2026 21:39 UTC
+2

Не, у них вышло вольное сочинение на тему. Причём если посмотреть репу, то там весь код в духе "пофигу, что у нас Rust, пишем, как будто это C, не перечитываем, не переписываем"

@Error1024
05.02.2026 22:04 UTC
+8

А «кожаные» с нуля прям компиляторы пишут? То что ЛЛМ смогла довести компилятор си до рабочего состояния о чем то да и говорит.

06.02.2026 06:34 UTC
0

Ну в какой-то момент всё-таки писали с нуля.

06.02.2026 08:03 UTC
0

Ну берем самый "олдовый" из живых - GCC - был получен Столлманом в ходе переписывания, еще более олдового, компилятора Pastel(Столлману отдали исходники компилятора языка Паскаль, сказав "используй как хочешь"). А прежде чем GCC научился в "полную поддержку Си 89" - прошло лет 5.

@chehow815
06.02.2026 05:26 UTC
0

(Не было)

@Dhwtj
05.02.2026 21:36 UTC
+1

Тесты не получились.

Понадобились некодифицируемые знания в виде golden tests /сравнения с эталоном

Мдя...

Без формальной спецификации C (которой в полном виде не существует, только стандарт с UB и implementation-defined) автоматические тесты в принципе недостаточны. Golden tests — это признание: "мы не знаем что правильно, но знаем что делает GCC"

Но, если подумать, это не проблема LLM

P.S.

GCC ~15 млн строк (с фронтендами всех языков), чистый C-фронтенд + middle-end ~2-3 млн.

100к строк это очень мало. Видимо, только парсинг + кодоген, без оптимизаций

@
05.02.2026 21:54 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
05.02.2026 21:59 UTC
0

CompCert верифицирует только подмножество C (без части фич: VLA, некоторые битовые поля, goto-хитрости)

Linux и реальные проекты используют GCC-расширения (__attribute__, inline asm, statement expressions), которых в CompCert нет

@rogoz
06.02.2026 00:35 UTC
+1

Golden tests — это признание: "мы не знаем что правильно, но знаем что делает GCC"

Если задача собрать Linux, то это правильный подход. Код ядра - это в основном про возможность сборки с помощью GCC, а не соответствие стандартам.

@Error1024
06.02.2026 08:08 UTC
0

"мы не знаем что правильно, но знаем что делает GCC" - все верно, чтобы собрать Linux - надо быть конкретно GCC/C, Clang буквально флаг-в-флаг, атрибут-в-атрибут прикидывается GCC, чтобы тонны "как бы сишных исходников" собирать.

@Vedomir
06.02.2026 09:11 UTC
+1

Помню прошлый эксперимент с созданием таким образом браузера закончился репозиторием, который даже не компилировался, интересно здесь кто-то проверял результат или он ограничивается громкими заявлениями?

@wataru
06.02.2026 13:44 UTC
+6

Такое себе. Это не компилятор - а его приближение, найденное случайным поиском на фиксированном датасете. Вообще неподдерживаемый, забагованный и нерабочий продукт жизнедеятельности.

Во-первых, там написан неоптимизирующий компилятор: скомпилированнй код работает хуже gcc без оптимизаций. Неоптимизирующий компилятор Си - это не такая уж и сложная вещь. Почти работающие компиляторы Си можно написать в одно лицо. Вообще, простенькие компиляторы дают писать студентам в качестве задачи в нормальных университетах на курсах по компиляторам. Тут задача посложнее, конечно, но не на порядки. Десяток толковых инженеров за 2 недели точно справятся. Но, кроме всяких контестов, никто ничего такого уже лет 30 не делал, потому что это мертворожденное и бессмысленное занятие. Смысла в такой поделке нет, а допиливать это до настоящего оптимизирующего компилятора - работа на десятилетия.

Во-вторых, оно компилирует какой-то прибитый гвоздями набор исходников, на которых училось. Добавьте туда еще каких-нибдь проектов и придется тратить еще неизвестное количество недель и десяток дысяч долларов, чтобы оно и их компилировало. Например, оно не компилирует Hello, world без танцев с бубном.

В-третьих, и главное - этот "компилятор" компилирует даже программы с ошибками. Положительные тесты на то, что оно должно скомпилировать у них были, а вот отрицательных, похоже, не особо. Сколько еще тысяч долларов надо потратить на допиливание? Обратите внимание, поскольку там нет дизайна-логики-смысла, а лишь беспорядочная генерация случайных токенов с отсеиванием непроходящих тесты вариантов, тут нельзя сказать, что оставшиеся мелкие баги быстро и дешево допилить. Возможно оно сошлось в локальный оптимум, из которого очень далеко до правильной реализации. Возможно оно вообще никогда не сойдется. Все, кто пользовался агентами на достаточно сложных вещах сталкивались с этим, когда оно исправляет что-то оно ломает кучу других мест.