Почему Remix 3 проектируется с расчётом на AI-агенты для написания кода

Проектировать фреймворк для AI-агентов написания кода — значит относиться к агенту как к первоклассному потребителю API, а не просто допускать работу AI-инструментов поверх фреймворка. Именно это различие лежит в основе бета-версии Remix 3, и оно куда конкретнее, чем можно судить по заголовкам в духе «Remix отказался от React». Репозиторий Remix 3 включает agent skill по пути template/.agents/skills/remix/, который CLI распространяет в каждое создаваемое приложение — тем самым переводя заявления из плоскости конференционных докладов в нечто, что можно изучить прямо сейчас.

В этой статье мы разберём, является ли тезис «спроектировано для AI-агентов написания кода» архитектурным обязательством или маркетинговым глянцем. Remix 3 служит здесь кейсом для более широкого вопроса, с которым скоро столкнётся каждый frontend-разработчик: какой образ мой фреймворк представляет LLM и поддаётся ли этот образ обучению?

Что на самом деле означает «проектирование для AI-агентов написания кода»

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

• AI-assisted development описывает процесс создания — использование LLM для написания кода самого фреймворка. Именно этот угол зрения выбирает материал Capaxe, и он ничего не говорит о том, насколько удобен получившийся фреймворк для написания кода агентами.
• AI-compatible означает, что агент способен создавать работающий код для фреймворка — так же, как и для любой достаточно задокументированной библиотеки. В той или иной мере AI-совместим каждый фреймворк.
• Designed for AI coding agents означает, что сама поверхность API рассматривается как цель для генерации кода. Примитивы фреймворка выбираются в том числе потому, что они снижают когнитивную нагрузку LLM при генерации, проверке или редактировании кода.

Практический тест для третьей категории: поставляет ли фреймворк что-либо, что агент потребляет напрямую? Remix 3 — да, и именно это отличает его от фреймворков, которые лишь заявляют о дружелюбности к LLM в блог-постах.

Принципы Remix сквозь призму агента

Три принципа Remix 3 — Web APIs, Runtime-over-Build и Composable Abstractions — усиливают единое архитектурное обязательство перед подходом Model-First, а не существуют как независимые цели. Эти принципы описаны в постах команды Remix «Wake up, Remix!» и Remix 3 Beta Preview.

Model-First — архитектурное ограничение, а не UX-слоган

Model-First в Remix 3 — не UX-принцип, а архитектурное ограничение: каждое решение по API оценивается с точки зрения того, может ли LLM предсказать результат, не симулируя конвейер сборки. LogRocket в своём материале частично сфокусировался на «LLM-противоречии» и привёл реакцию с Reddit («Есть ли вообще кто-то, кто не взял денег от венчурных инвесторов и при этом думает об LLM?»). Однако механизм, лежащий в основе этого дизайна, — предсказуемость.

Рассмотрим модель состояния из ранних прототипов Remix 3:

// Прототип Remix 3, показанный на Remix Jam 2025 — иллюстративный, API ещё в процессе разработки
function Counter(this: Remix.Handle) {
  let count = 0; // обычная переменная замыкания

  return () => (
    <div>
      <div>{count}</div>
      <button onClick={() => {
        count++;
        this.update(); // явная команда перерисовки
      }}>
        Increment
      </button>
    </div>
  );
}

Ключевой момент — явный вызов this.update(). При использовании useState в React триггер перерисовки неявен: агент должен знать правила реконсилятора, семантику массива зависимостей для связанных эффектов и то, какие мутации отслеживаются. При явном вызове обновления причинно-следственная связь видна прямо в коде. Ничего не нужно выводить. Как выразился Алекс Котлярский, «LLM плохо справляются с React, производя “безобразные нагромождения useEffect’ов и случайных хаков”». Model-First — это дизайнерский ответ именно на этот сценарий сбоя.

Web APIs сокращают поверхность, которую агент должен запомнить

Приоритет Web Platform APIs усиливает подход Model-First, заменяя специфичные для фреймворка абстракции примитивами, которые LLM уже знает из своих обучающих данных. Обработчики Remix 3 принимают стандартный Request и возвращают стандартный Response; формы используют FormData; взаимодействие компонентов опирается на CustomEvent. Агенту, генерирующему обработчик запроса, не нужно изучать проприетарный объект контекста — он сопоставляет паттерны с веб-семантикой, которая встречается во всём корпусе серверного JavaScript. Меньше специфичных абстракций означает меньшую грамматику для изучения и меньше шансов «галлюцинировать» несуществующий метод.

// Обработчик Remix 3: стандартные Request/Response Web Platform — иллюстративный пример
async function action(request: Request): Promise<Response> {
  const form = await request.formData();
  const name = form.get("name");
  return new Response(`Hello, ${name}`, { status: 200 });
}

Runtime-over-Build устраняет конвейер, который агент не видит

Предпочтение runtime перед шагами сборки усиливает подход Model-First, поскольку шаг сборки — это скрытое преобразование, которое агент не может наблюдать из исходного кода. Когда поведение фреймворка определяется во время выполнения из кода, который агент может прочитать, исходный код и есть источник истины. Когда поведение зависит от прохода компилятора, плагина кодогенерации или трансформации бандлера, агент вынужден мысленно симулировать конвейер, который никогда не видит, чтобы предсказать результат. Runtime-over-build — это не самостоятельный принцип, а прямое следствие подхода Model-First.

Composable Abstractions сохраняют поведения локальными

Компонуемые минималистичные абстракции усиливают то же ограничение, сохраняя поведения локальными и явными, а не размазанными по дереву провайдеров и эффектов. Фреймворк, в котором маршруты живут в одном месте, обработчики возвращают стандартные объекты Response, а middleware владеет полным жизненным циклом запроса, даёт AI-агенту фиксированную, обучаемую грамматику — сокращая бюджет токенов, необходимых для генерации корректного кода по новому промпту.

Конкретное доказательство: репозиторий remix-run/agent-skills

Agent skills — это структурированные наборы инструкций, которые AI-агент загружает, чтобы научиться правильно использовать конкретный инструмент: упакованный ответ на вопрос «как писать код для этого фреймворка». Репозиторий Remix 3 включает собственные agent skills в директории .agents/skills, и именно эти встроенные skills переводят заявления Remix 3 об AI-агентах из маркетинговой плоскости в нечто, что разработчик может прочитать, проверить и оценить прямо сейчас, а не просто философию из доклада.

Следующее основано на README репозитория Remix 3 и встроенных agent skills в директории .agents/skills на момент написания статьи; репозиторий активно разрабатывается, и детали могут измениться.

Согласно README Remix 3, агенты не устанавливают skill отдельно — он поставляется внутри репозитория фреймворка и копируется в шаблон приложения на шаге CLI prepack. README говорит об этом прямо:

Агенты, создающие приложение Remix 3 из этого репозитория, должны использовать app skill remix. Шаг CLI prepack копирует этот skill в шаблон приложения, чтобы сгенерированные приложения могли использовать те же инструкции.

App skill remix проводит агента через всю поверхность приложения Remix 3 — структуру, маршруты, контроллеры, middleware, валидацию, доступ к данным, аутентификацию, сессии, загрузку файлов, настройку сервера, UI-компоненты, гидратацию, навигацию и тесты — построенную вокруг единого npm-пакета remix и его subpath imports. Значимость здесь структурная: фреймворк, который поставляет собственный agent skill внутри репозитория и распространяет его в каждое сгенерированное приложение, относится к агенту как к первоклассному потребителю своего API — точно так же, как к разработчикам-людям, читающим документацию.

Именно это обнаруживает проверка утверждения frantic.im «LLM плохо справляются с React» применительно к Remix 3. Жалоба реальна и широко распространена; вопрос в том, делает ли Remix 3 что-то с этим помимо риторики. Встроенный app skill remix — это операциональный ответ: он не просто заявляет о более чистом API, но поставляет инструкции, позволяющие агенту правильно использовать этот API, в каждое создаваемое приложение.

Почему «чёткие формы» важны для агентов

Чёткие, предсказуемые формы фреймворка снижают бюджет токенов и нагрузку на инференс агента при выполнении каждой задачи — именно поэтому команда Remix позиционирует дружелюбность к AI как архитектурную цель, а не маркетинговый тезис. В Remix 3 Beta Preview это сформулировано прямо:

AI вознаграждает фреймворки с чёткими формами: маршруты в одном месте, контроллеры, возвращающие ответы, middleware, владеющий аспектами жизненного цикла запроса.

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

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

2. Детерминированные цели кодогенерации. Когда маршруты всегда живут в одном месте, а обработчики всегда возвращают Response, у агента есть известный шаблон для сопоставления паттернов. Он генерирует по форме, а не импровизирует структуру. Детерминированные цели — это разница между тем, правильно ли агент завершит обработчик маршрута с первой попытки, или произведёт те самые «случайные хаки», о которых пишет frantic.im.

3. Runtime как источник истины. Когда выполняемый код является полной спецификацией поведения, агент может прочитать исходный код и знать результат. Нет прохода компилятора для симуляции, нет границы "use client" / "use server" для анализа, нет планировщика реконсилятора для предсказания. Чем меньше скрытых поведений агент должен симулировать мысленно, тем надёжнее он генерирует и редактирует код.

Ничто из этого не требует признания того, что Remix 3 лучше React. Достаточно лишь заметить, что «чёткие формы» — это измеримое свойство поверхности API, и что LLM чувствительны к нему.

Честная контрпозиция

Наиболее весомые критические аргументы в адрес позиционирования Remix 3 как AI-агентного фреймворка имеют реальные основания, но не все бьют в правильную цель — и этот зазор важен при оценке того, выдерживает ли заявление об агентной дружелюбности проверку.

• Критика «венчурного тренда» утверждает, что «model-first» гонится за хайпом в ущерб реальным болям разработчиков. Строчка с Reddit, которую процитировал LogRocket, отражает это подозрение. Контраргумент — артефакт: встроенный agent skill, который встраивается в каждое сгенерированное приложение, — это на редкость конкретный способ гнаться за трендом.
• Меньше обучающих данных. LogRocket характеризует Remix 3 как построенный на форке Preact. Фреймворк, представленный в публичных корпусах LLM значительно меньше, чем React, изначально проигрывает в качестве предсказания следующего токена — что, примечательно, именно тот пробел, для закрытия которого и существует встроенный agent skill. Skill, распространяемый в шаблон приложения при создании проекта, внедряет актуальные, корректные соглашения, которые агент иначе был бы вынужден извлекать из скудных обучающих данных.
• Статус беты и миграция. Remix 3 — это бета. Материал команды Remix о слиянии с React Router позиционирует React Router v7 как путь продолжения для существующих пользователей Remix v2; Remix 3 — это отдельный экспериментальный рерайт, а не обновление. Делать на него ставку в продакшене сегодня преждевременно.

Критика «венчурного тренда» небезосновательна, но задаёт неверный вопрос: встраивание agent skill в собственный репозиторий фреймворка — это не ставка на распространение Preact, а ставка на то, что спецификации agent skill станут критерием выбора фреймворка.

Что это означает, если вы никогда не прикоснётесь к Remix 3

Даже разработчики, которые никогда не напишут ни строчки кода на Remix 3, ощутят влияние его дизайнерских решений, поскольку он устанавливает новую ось конкуренции: фреймворки будут всё чаще оцениваться по качеству работы с агентами — по качеству цели, которую они представляют LLM, — а не только по удобству для разработчиков.

Этот сигнал виден по всей экосистеме. Предложение llms.txt стандартизирует способ предоставления сайтами и проектами LLM-читаемого контекста. Встроенные agent skills формируются как формат доставки специфичных для инструмента соглашений. Remix 3 — заметно ранний пример крупного веб-фреймворка, поставляющего выделенный agent skill внутри собственного репозитория и распространяющего его в каждое создаваемое приложение.

Долгосрочный урок не зависит от того, добьётся ли Remix 3 успеха. Каждый фреймворк, желающий оставаться конкурентоспособным в рабочих процессах с участием агентов — таких, которые терминал-ориентированные агенты вроде OpenCode делают рутиной, — столкнётся с тем же вопросом, на который отвечает Remix 3: какой образ мой фреймворк представляет LLM и поддаётся ли этот образ обучению?

Команды, выбирающие инструментарий, тоже начнут его задавать. «Насколько хорошо мой AI-агент пишет код для этого фреймворка?» становится критерием выбора наравне с размером бандла и DX, присоединяясь к традиционным компромиссам Next.js vs Remix, которые уже определяют этот выбор.

Заключение

Remix 3 — наиболее наглядный из доступных сегодня кейсов того, что значит строить фреймворк с агентом как первоклассным потребителем: явные обновления состояния, примитивы Web Platform, runtime как источник истины и встроенные agent skills, которые поставляют необходимые LLM соглашения в каждое создаваемое приложение. Независимо от того, примете ли вы его, следующий конкретный шаг — оценить собственный стек тем же образом: изучить встроенные skills в директории .agents/skills, разобраться, как фреймворк упаковывает свои соглашения для агента, и спросить себя, представляют ли инструменты, которые вы используете сегодня, форму, которую LLM способен освоить.

Часто задаваемые вопросы

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.