200 задач. 248 тысяч поведенческих тестов. Девять моделей, среди них всё свежее на 2026 год: Opus 4.7, GPT 5.4, Gemini 3.1 Pro, Sonnet 4.6, Haiku 4.5. На SWE-bench те же модели стабильно берут 70 % и выше. Здесь — ноль. Полностью решённых задач у самой сильной модели — 3 %. У всех остальных — 0 % и ещё раз 0 %.
Это ProgramBench — новый бенчмарк от Meta Superintelligence Labs, Stanford и Harvard, опубликован в 2026 году (paper, github). И он измеряет совсем не то, что измеряют SWE-bench и HumanEval.
Чем ProgramBench отличается от других кодинг-бенчмарков
SWE-bench меряет, как агент чинит баги в существующем репозитории: даны исходники, есть issue, есть тесты, нужно сделать патч. HumanEval и MBPP меряют ещё более узкий навык — дописать функцию по сигнатуре. ProgramBench убирает все подсказки. Агенту выдают только скомпилированный бинарь и описание того, что эта программа должна делать. Никаких сорсов. Никакой декомпиляции. Никакого интернета. Задача — собрать программу с нуля так, чтобы она прошла поведенческие тесты, по 1240 в среднем на задачу.
Когда я первый раз увидел сайт programbench.com, подумал — очередной SWE-bench с другим набором репозиториев. Открыл лидерборд, увидел нули, полез в paper. Это не другой набор задач. Это другой ТИП задачи. SWE-bench и HumanEval оба формата спрашивают «дополни существующее». ProgramBench спрашивает «спроектируй с нуля».
Технически устроено просто. 200 задач, языки — Go, Rust, C, C++, Haskell, Java. Внутри — самые разные программы: от компактных терминальных утилит вроде jq, ripgrep, fzf до крупных систем — PHP-компилятор, FFmpeg, SQLite. Запуск — sandboxed Docker, единый mini-SWE-agent harness на все 200 задач, без ручной подкрутки под конкретную программу. Тесты — поведенческие: запускают эталонную реализацию и собранную, сверяют выходы.
И никто не справляется. Ни Opus 4.7 с миллионным окном, ни GPT 5.4, ни Gemini 3.1 Pro. Авторы в paper честно отмечают: задачи решаемы — все эталонные реализации проходят свои тесты. Просто текущим моделям, без скаффолдинга, не хватает архитектурной хватки.
Что показал паттерн результатов
Полностью резолвнутых задач ноль у всех. Скор «почти решено» (≥95 % поведенческих тестов прошли) распределился так:
Opus 4.7 — 3.0 %
Opus 4.6 — 2.5 %
Sonnet 4.6 — 1.0 %
GPT 5.4, Gemini 3.1 Pro, Gemini 3 Flash, Haiku 4.5, GPT 5.4 mini, GPT 5 mini — 0 %
Если же посмотреть не по моделям, а по задачам — там паттерн читается невооружённым глазом:
Топ-5 «вытянутых» проектов | Лучший скор | Что это |
|---|---|---|
nnn | 98 % | Терминальный файловый менеджер на C |
BLAKE3 | 98 % | Криптохэш с чёткой спекой |
brotli | 91 % | Компрессия Google, чёткая спека |
jq | 90 % | JSON-утилита |
fzf | 82 % | Fuzzy finder для терминала |
Худшие проекты | Лучший скор | Что это |
quickjs | 4 % | JS-движок |
PHP | 5 % | Компилятор языка программирования |
FFmpeg | 5 % | Мультимедиа-фреймворк |
gromacs | 9 % | Физический симулятор молекулярной динамики |
Маленькие утилиты с чёткой ответственностью — модель почти собирает. Большие системы со сложной архитектурой и множественными зависимостями — провал. Это и есть архитектура: не «написать функцию», а «декомпозировать задачу на 50 файлов, не уронить связность, не сломать инвариант через 200 коммитов кодогенерации». Чем шире декомпозиция нужна — тем хуже модель справляется. И чем больше скрытых требований не написано в спеке — тем тоже хуже.
Почему это бьёт по мечте vibe-кодеров
Зачем вообще ProgramBench нужен — потому что он бьёт ровно по той точке, где живёт основная мечта vibe-кодинга: «промптом закажу систему под ключ, AI соберёт». Я регулярно рассказываю на конференциях и в Telegram про то, что AI-агенты заметно ускоряют работу команды. И это правда — на хорошо размеченных, узких задачах. Но если убрать «хорошо размеченных» и «узких», получится ровно ProgramBench. И там у топовых моделей — ноль и ноль.
Стандартная грабля у того, кто только пробует работать через AI-агентов: даёт фразу «сделай мне приложение для учёта расходов с авторизацией и графиками» — и ждёт. Через час получает что-то, что вроде запускается. Через день оказывается, что половина зависимостей в requirements.txt несовместимы. Через неделю — что вся бизнес-логика держится на одном условии, скопированном из Stack Overflow трёхлетней давности. Дальше два сценария. Первый: проект выкидывают и идут делать руками. Второй: автор — менеджер с бюджетом, и тогда из этого вырастает гигантский технический долг, который доделывают живые инженеры за тройной прайс.
Что нужно, чтобы AI-агент действительно собрал работающий кусок системы:
Понимать, как устроен код. Не «писать», а уметь читать чужой и видеть, где у агента развалится логика.
Следить за процессом. Агент — это партнёр, который иногда выдаёт уверенно сформулированную ересь. Замены инженера он не делает; он умножает производительность того, кто уже умеет.
Грамотный контекст. Здесь чаще всего и спотыкаются. Контекст — это не «PRD на полстраницы и поехали». Это скиллы (как должно быть устроено мышление агента), описанные субагенты (кто за что отвечает), MCP-серверы (откуда тащим актуальные данные), документация проекта, история задач, архитектурные решения, инварианты.
Дальше — побочный эффект, который редко обсуждают вслух. Когда вы всё это аккуратно собираете, контекстное окно начинает забиваться под завязку. У меня недавно была статья про реальный потолок 1M-окна Opus 4.7 — он эффективно работает не на миллионе, а где-то до 300–400 тысяч токенов, дальше начинается деградация качества, что подтверждается system card Anthropic. Так что «больше контекста» в новых моделях — это не «больше комфорта», это новые фронтиры компакции и приоритизации. Косвенно ProgramBench и про это: 200 задач, и даже чёткая дока на каждую — не панацея. Где-то полнота требований выходит за зону внимания модели быстрее, чем агент успевает развернуть архитектуру.
(Кстати, интересный tangent. HumanEval и MBPP — раньше эталонные кодинг-бенчмарки — давно стоят на 90 % и выше. Их продолжают цитировать как «модели уже умеют программировать». На самом деле это значит другое: задача «дописать функцию по сигнатуре» решена. ProgramBench, SWE-bench Live и подобные — это попытки построить тесты, которые НЕ насыщаются мгновенно. Хорошо, что они появляются.)
Чего бенчмарк не показывает
Теперь честно про ограничения, иначе картина перекошена.
Первое. 0 % у восьми из девяти моделей значит, что бенчмарк сейчас не различает их по тонкости. Можно сказать, что Opus 4.7 «лучше остальных», потому что у него 3 % против 0–2.5 %. Но три процента — это шесть задач из двухсот. Статистическая разница есть, но опираться на неё для production-выбора пока опасно.
Второе и более существенное. Авторы используют единый mini-SWE-agent — намеренно простой harness: модель в цикле, без многошаговой оркестрации, без специализированных tool calls, без декомпозиции на субагентов. Это сделано осознанно, чтобы измерять способности самой модели, а не качество обвязки. В реальности же я каждый день работаю не с «голой моделью», а с Claude Code, у которого свои команды, свои подагенты, свой workflow. Бенчмарк меряет точку «модель в вакууме», прод живёт в точке «модель + инфраструктура». Между ними — большая разница, и она в пользу прода.
Третье. Стоимость не учтена. Нет цены за решённую задачу, нет токенов на агента. По моему опыту, расстановка моделей по соотношению «качество / стоимость» обычно отличается от расстановки по голому скору — модель, проигрывающая в качестве, на единицу денег нередко обгоняет. Здесь этого среза нет. Будем смотреть в paper, может, авторы добавят его отдельным приложением.
К слову, пока разбирал ProgramBench, понял, что самим бенчмаркам нужен такой же спокойный гид — что меряет каждый, для какой задачи нужен, на что смотреть. Собрал отдельным PDF: 31 тест по 9 категориям, не только кодинг (математика, длинный контекст, агенты, мультимодальность, безопасность, русский язык). Для каждого — короткая карточка с лидерами на май 2026 и ссылкой на оригинальный лидерборд. Лежит закреплённым в моём Telegram-канале, скачивается без регистрации. Если выбираете модель под задачу — может сэкономить время.
Что я забираю из этого для собственной работы
Цифра «0 %» — это не приговор кодинг-моделям. Это калибровка ожиданий.
AI отлично пишет код, когда декомпозиция уже сделана: понятно, какие компоненты, как они общаются, какой инвариант надо удержать. Декомпозицию пока делает человек. Кто это понимает — выигрывает: использует AI как партнёра и бьёт скорость в разы. Кто верит, что декомпозицию тоже сделает за него промпт — собирает технический долг, который потом приходит чинить за тройной прайс.
Дальше будет интересно. Бенчмарк свежий, paper открыт, docker-окружения и код опубликованы. Можно прогонять свои конфигурации — другой harness, более длинный chain-of-thought, агентскую систему с памятью и подагентами. Подозреваю, что в ближайшие месяцы цифры начнут расти. Но вряд ли они станут как у HumanEval. Это инвариант сложности задачи, не свойство «текущего поколения моделей».
А пока — не торопитесь верить, когда вам обещают, что «AI соберёт вам стартап с нуля по одному промпту». В лидерборде конкретного бенчмарка с конкретной методологией — три процента «почти», у всех остальных ноль.
Заметки и наблюдения по подобным экспериментам складываю в Telegram-канал AI Dev Team. Если хочется обсудить применение бенчмарка к вашему стеку или поделиться своими прогонами — пишите в личку. Open-source оркестратор-кит, на котором у меня живёт ежедневная работа с агентами — на GitHub.