Скрытая цена JavaScript-фреймворков для ИИ-агентов

Агент потратил одиннадцать минут на чтение руководства по миграции, прежде чем написал хоть одну строку кода. Не ваш агент, а тот, которого коллега на прошлой неделе натравил на проект SvelteKit с тем же промптом, что вы дали своему React-приложению час назад. Ваш закончил примерно за восемь минут и четыре миллиона токенов. Их агент работал семнадцать минут и потратил почти десять миллионов токенов, и большую часть разницы съела модель, которая терпеливо переучивалась версии фреймворка, никогда не встречавшейся ей при обучении. У этого разрыва теперь есть название: цена JavaScript-фреймворков для ИИ. И благодаря по-настоящему необычному для нашей индустрии поступку, когда кто-то реально измерил, а не просто утверждал, у нас наконец есть настоящие цифры.

Нолан Лоусон, который годами заменяет фронтенд-фольклор реальными бенчмарками, недавно сделал очевидную вещь, до которой никто не додумался. Он описал небольшое, но не тривиальное приложение про покемонов с поиском, фильтрацией, страницами с подробностями и данными из PokéAPI и поручил агенту построить его двенадцатью способами: Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, Hono с htmx, Gracile с Lit и простой Vite без какого-либо UI-фреймворка. Каждый фреймворк получил пять независимых запусков с одним и тем же промптом, каждую сборку проверяли набором тестов на соответствие, чтобы агент не мог схитрить, а результаты оценивали по стоимости, времени, токенам и метрикам Lighthouse. Эксперимент не идеальный, и Лоусон сам это признаёт. Но это первая честная попытка, которую я видел, назначить ценник на решение, которое большинство команд принимает на глазок.

Что на самом деле измерил бенчмарк

Установка была намеренно нейтральной. Агент получал спецификацию, ему говорили использовать последнюю версию нужного фреймворка, а архитектуру он выбирал сам: SSR или CSR, как ему больше нравится. Если фреймворк поставлялся с официальным MCP-сервером, навыком агента или плагином, их предоставляли, чтобы никто не мог пожаловаться, что его недопредставили в обучающих данных. Тесты на соответствие проходили по дереву доступности, а не по сырому DOM, и это было важно, потому что один из участников рендерит через shadow DOM. Каждый фреймворк получил пять запусков, результаты приведены как медианы. Исключение составил Angular: дважды он не смог создать тестируемое приложение вообще, поэтому часть его чисел основана на трёх запусках.

• Стоимость сборки варьировалась от медианных примерно $2,67 до $4,97 за приложение, то есть примерно двукратный разброс между самым дешёвым и самым дорогим фреймворком.
• Потребление токенов говорило то же самое, но громче: около 4 миллионов токенов у самых дешёвых стеков и почти 10 миллионов у самых дорогих.
• Время выполнения шло вровень со стоимостью: примерно от 8 минут на быстром конце до 17 минут на медленном.
• SvelteKit, Gracile+Lit и Angular стабильно оказывались самыми дорогими сборками. Astro и связка Hono+htmx стабильно были дешёвыми.
• Неожиданно, но сборка на голом Vite без фреймворка уступила нескольким настоящим фреймворкам. Какая-никакая структура лучше её отсутствия, даже для машины.

Два доллара за сборку звучат как ерунда. Для одной сборки это и есть ерунда. Но агентная разработка по своей природе итеративна, и первый результат никто не принимает. Умножьте этот разброс на десятки сессий агента в неделю на разработчика, на всю команду и на год, и двукратный коэффициент по токенам для вашего стека превращается в реальную статью расходов. Важнее другое: токены служат прокси для того, что меня волнует больше денег, а именно для того, сколько проб и ошибок модели нужно, чтобы выдать правильный код на вашем фреймворке. Большое количество токенов обычно означает, что агент запутался, перечитывает документацию и повторяет попытки. Это сигнал о качестве, замаскированный под расходы.

Почему одни фреймворки делают агентов дорогими

Проведя годы за обучением и оценкой моделей, я считаю результаты менее загадочными, чем они выглядят. Три механизма объясняют почти весь разброс, и ни один из них не связан с тем, какой фреймворк «лучше» в традиционном смысле.

Плотность обучающих данных определяет судьбу

Главное преимущество React в эпоху агентов состоит не в модели программирования, а в том, что десятилетие туториалов, репозиториев на GitHub и ответов на Stack Overflow вжало его идиомы в веса каждой передовой модели. Агент, пишущий на React, в основном вспоминает. Агент, пишущий на Gracile, в основном открывает для себя: в запусках бенчмарка агенты, не знавшие фреймворка, клонировали его репозиторий или читали скомпилированный код из node_modules. Это токены, сожжённые на ликбез до того, как появился хоть какой-то пользовательский код. Та же динамика меняет то, как разработчики вообще находят знания. Я писал о том, что происходит с корпусом знаний разработчиков по мере угасания Stack Overflow, а фреймворковый аспект здесь представляет собой резкий частный случай: непопулярные инструменты не просто лишены сообщества, они отсутствуют в самой модели.

Постоянная смена API это регулярный налог на токены

Слабый результат SvelteKit имеет конкретную, почти смешную причину: агент читал руководство по миграции на SvelteKit v3 в каждом запуске, потому что эта версия была слишком новой, чтобы попасть в обучающие данные модели. Каждое ломающее изменение во фреймворке обесценивает шаблоны, которые модель запомнила, и заставляет её заново выводить правильный API из документации на этапе инференса. Этим платят токенами, в каждой сессии, каждый пользователь. Фреймворки воспринимают смену мажорных версий как маркетинговое событие. Для тех, кто работает с агентами, это регулярная доплата. Скучный фреймворк, который не ломал свой API три года, по этой метрике является премиальной функцией.

Многословность накапливается в цикле

Стоимость Angular, похоже, соответствовала его объёму кода: больше сгенерированных строк означает больше токенов на выходе, больше токенов для перечитывания при каждой следующей правке и больше поверхности, на которой агент может споткнуться. Это обобщается. Любой стек с многословным выводом инструментов, шумными логами сборки или медленными командами тестов заставляет агента продираться через больше текста на каждой итерации, а каждая проваленная проверка линтера или типов запускает ещё один дорогой круг. Практики повсюду говорят об одном и том же: доминирует стоимость итераций, а не стоимость генерации. Фреймворк с быстрым, тихим и строгим инструментарием дешевле в эксплуатации, чем либеральный, потому что строгость ловит ошибки агента за один цикл, а не за пять.

Каждое ломающее изменение в вашем фреймворке это налог, который кто-то платит токенами. И в отличие от человека, читающего changelog, модель платит его в каждой сессии.

Проблема игральной кости в бенчмарках агентов

Тут включаются мои старые привычки из оценки ML, потому что самая важная деталь всего исследования это доверительные интервалы. Вывод LLM является распределением, а не точкой. Медианная стоимость сборки React Router была примерно на доллар хуже, чем у Hono+htmx, но самый дешёвый отдельный запуск React Router оказался ниже, чем самый дорогой запуск Hono. Диапазоны существенно перекрываются. Запуски SvelteKit колебались от примерно $3,20 до $6,80. Иногда агент просто выпадает на низкие значения, уходит в сторону и сжигает пару миллионов токенов по причинам, не имеющим отношения к фреймворку.

Данные об использовании инструментов подтверждают ту же мысль. Фреймворки поставлялись с MCP-серверами и файлами навыков, и агенты ими пользовались… иногда. MCP-сервер Nuxt не был задействован ни разу за пять запусков. Файлы навыков TanStack Start обнаружили в двух запусках из пяти. Навык React Router использовался каждый раз. Один и тот же промпт, одна и та же обвязка, совершенно разное поведение: это стохастическая природа инструмента. Значит, каждая ветка в Twitter, утверждающая «фреймворк X так хорош для агентов, я переписал всё приложение», основанная на одном дне вайб-кодинга, измеряет шум. Один запуск это анекдот. Если вы собираетесь позволить стоимости ИИ влиять на архитектурное решение, а я считаю, что стоит, требуйте медианы по повторным запускам, прежде чем верить чему-либо, включая этот бенчмарк.

Качество результата: всё сходится к «нормально»

Самый неожиданный результат в том, что не варьировалось. Оценки Lighthouse по Performance, Accessibility и Cumulative Layout Shift почти достигли потолка по всем двенадцати стекам: почти везде 99 и 100. При чёткой спецификации и наборе тестов на соответствие современные агенты создают компетентные, доступные небольшие приложения практически на любом фреймворке. Планка качества поднялась настолько, что фреймворк почти не отличает результат на контентном сайте.

Единственная метрика качества с реальным разбросом это объём отправляемого JavaScript: ноль КиБ у островных сборок Astro и Hono+htmx и до примерно 142 КиБ у самого тяжёлого SPA. Total Blocking Time везде оставался незначительным, а LCP был слишком шумным, чтобы из него что-то вытянуть. Здесь стоит сделать две честные оговорки. Тестовое приложение ближе к Википедии, чем к Figma, поэтому оно льстит многостраничным архитектурам, а сам Lighthouse структурно смещён против SPA. Тем не менее результат с ванильным JavaScript заслуживает паузы: агент, которому велели использовать чистый Vite без фреймворка, выдал оценки хуже нескольких настоящих фреймворков, включая самый высокий сдвиг макета среди всех сборок. Фреймворки кодируют соглашения, а агенты на соглашения опираются очень сильно. Дай модели протоптанную колею, и она в ней останется. Дай ей чистое поле, и она будет импровизировать, не всегда удачно.

Чего этот бенчмарк не может сказать

Прежде чем кто-либо перепишет продакшен-приложение по демо с покемонами, давайте честно обозначим границы. Это одно небольшое, в основном контентное приложение с минимумом сквозного состояния, без локализации, без сложных форм и без команды людей, которые будут поддерживать его пять лет. Это реальное ограничение, и это та же ловушка, вокруг которой я постоянно хожу в этом блоге: AI-бенчмарки систематически упускают бо́льшую часть того, как выглядит реальная работа. Свойства, которые делают фреймворк хорошим для агентов на greenfield-игрушке (знакомость, простота, статическая структура), не те свойства, которые важны на восемнадцатом месяце запутанного продукта.

Есть и более глубокая мысль, которую правильно уловили скептики фреймворков в обсуждении. Большая часть исторической ценности фреймворка никогда не была в том, что он позволяет делать, а в том, что он запрещает. Java завоевала корпоративную разработку отчасти потому, что заставляла десять тысяч программистов писать похожий код. Фреймворки это системы ограничений для команд людей, которые приходят, уходят и друг друга неправильно понимают. Агенту не нужны ограничители от скуки или разработки ради строчки в резюме. Ему нужны чёткая спецификация и набор тестов. Один практик описал именно такую инверсию на htmx: агент легко справлялся с простыми страницами, но спотыкался на сложной форме с состоянием, теряя состояние и ломая переключатели, то есть делая то, что React сделал бы с первой попытки, пока не появилось достаточно тестов, чтобы держать его в рамках. Ограничение, которое важно для агентов, это не фреймворк. Это набор тестов на соответствие.

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

Как измерить стоимость ИИ для своего стека

Не экстраполируйте на свою кодовую базу чужой бенчмарк, в том числе этот. Ваш репозиторий, ваша спецификация и выбранная модель дадут собственное распределение. Хорошая новость в том, что измерить стоимость ИИ действительно просто, потому что агенты для написания кода уже отчитываются обо всём необходимом. Если хотите понять, как цикл, контекст и разрешения взаимодействуют, прежде чем их инструментировать, хорошей основой станет наш материал о том, как на самом деле работает агентный CLI для написания кода. Затем сделайте следующее:

1. Выберите вертикальный срез, который отражает вашу реальную работу: фичу, затрагивающую слой данных, управление состоянием и UI, а не лендинг.
2. Напишите тесты на соответствие в первую очередь. Тесты служат и воротами качества, и защитой от читерства: агент без тестов объявит победу раньше времени.
3. Запускайте один и тот же промпт минимум пять раз на каждый кандидат-стек или конфигурацию. Указывайте медианы и диапазоны, никогда не одиночные запуски.
4. Логируйте общее количество токенов (с разбивкой на чтение из кэша, входные и выходные), время выполнения, стоимость, а также количество вызовов инструментов и циклов повторов.
5. Отслеживайте, сколько токенов уходит на чтение документации: руководства по миграции, changelog, раскопки в node_modules. Это и есть ваш налог на дефицит обучающих данных, измеренный напрямую.
6. Перезапускайте бенчмарк после крупных обновлений фреймворка. Стоимость ИИ дрейфует по мере смены API и сдвига границ обучения моделей.

Сам харнесс может занять вечер скриптования. Вот скелет, которым я пользовался. Детали флагов CLI зависят от вашего агента, но структура универсальна:

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

Следите за количеством повторов так же внимательно, как за общей суммой токенов. По моему опыту, токены на принятый тест это самая честная метрика: она сводит стоимость, путаницу и корректность в одно число и наказывает ту ошибку, которая реально вредит, когда агент пять раз подряд ловит ошибки компиляции, прежде чем выдать то, что проходит тесты. Фреймворк, на котором агент чисто проходит с первой или второй попытки, всегда победит номинально «более дешёвый», который требует постоянных исправлений.

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

Так стоит ли переписывать приложение на Angular на Astro, потому что агентам так дешевле? Нет. Разница в долларах мала, разброс велик, тестовое приложение игрушечное, а миграция стоила бы в токенах агентов больше, чем вы сэкономите за десятилетие. Тот, кто продаёт вам миграцию фреймворка «ради агентов», занимается тем же рассуждением на вайбах, которым индустрия всегда и занималась, только с новым обоснованием, прикрученным сбоку.

Но стоимость ИИ заслужила место за столом решений рядом с рынком кадров, глубиной экосистемы и размером бандла. Для greenfield-проектов доказательства указывают в одном направлении: выбирайте стеки с глубоким представлением в обучающих данных, медленной сменой API, строгим и тихим инструментарием и соглашениями, которые модель видела десять тысяч раз. Скучные технологии всегда были прагматичным выбором, агенты просто сделали скуку измеримой. Фиксируйте версии фреймворков, потому что каждое обновление теперь ещё и налог на инференс, пока модели не догонят. И инвестируйте в тесты на соответствие независимо от выбранного фреймворка: это единственный актив, который делает каждого агента дешевле, держит его честным, когда он буксует, и окупается долго после того, как нынешняя модель устареет. Фреймворки будут продолжать меняться. Выживают тесты и привычка измерять.