AI-агенты во фронтенд-разработке: как мы встроили их в рабочий процесс

AI как участник процесса разработки

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

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

Наибольшую ценность AI начинает приносить тогда, когда становится частью инженерного процесса.

Мы используем AI-агентов как дополнительный инструмент автоматизации — в основном Cursor и Codex. Но ключевую роль для нас играет не конкретный продукт, а среда, в которой работает агент.

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

Агент получает доступ к коду, внутренней документации, существующим реализациям и внешним инструментам. Это позволяет передавать ему не только небольшие изолированные задачи, но и последовательности действий: изучить текущий код, подготовить план изменений, реализовать решение и провести первичную проверку.

Такой подход меняет роль разработчика. Вместо ручного выполнения каждого действия он формулирует задачу, определяет ограничения, предоставляет необходимый контекст и проверяет результат. Ответственность за техническое решение при этом остается у человека, а AI берет на себя значительную часть рутинной работы.

На практике мы используем агентов для разных этапов фронтенд-разработки:

• создания базовых компонентов, страниц и повторяющихся элементов;
• верстки по данным из Figma через локальный MCP-сервер;
• планирования разработки задач;
• рефакторинга существующего кода;
• проверки технических гипотез;
• переноса и адаптации крупных фрагментов функциональности;
• формирования документации на основе повторяющихся действий и замечаний.

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

Ключевым условием стабильности результата, который выдаёт агент, становится не качество отдельного промта, а качество среды, в которой он работает. Чем понятнее архитектура проекта, чем точнее описаны правила и чем больше доступно примеров правильной реализации, тем более сложные задачи можно передавать AI без потери управляемости.

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

Что мы понимаем под AI-агентом

Термином «AI-агент» сегодня называют разные инструменты: от чат-ботов до систем, способных самостоятельно выполнять длинные последовательности действий.

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

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

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

Например, при создании новой страницы агент может:

1. Изучить конфигурацию маршрутов;
2. Найти страницы с похожей структурой;
3. Определить доступные компоненты дизайн-системы;
4. Создать необходимые файлы;
5. Подключить страницу к маршрутизации;
6. Проверить типизацию и сборку;
7. Исправить обнаруженные ошибки.

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

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

1. Код проекта

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

2. Архитектурные и командные правила

Одной структуры файлов недостаточно. Агенту нужно понимать, какие зависимости разрешены между модулями, где должна находиться бизнес-логика, как оформляются публичные экспорты, какие библиотеки используются и какие требования предъявляются к новому коду.

Без таких правил AI склонен выбирать решение, которое выглядит логичным локально, но нарушает устройство системы целиком.

3. Инструменты

В агентном режиме AI-агент может использовать дополнительные инструменты: поиск по проекту, терминал, линтер, TypeScript, тесты, браузер или MCP-серверы. Благодаря этому агент способен не только предложить код, но и получить данные из внешнего источника, применить изменения и проверить результат.

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

4. Критерии готовности

Агенту необходимо заранее объяснить, какой результат считается правильным. Это может быть успешная сборка, отсутствие ошибок типизации и линтинга, прохождение тестов или другие заранее прописанные условия.

Чем точнее определены критерии, тем меньше вероятность, что агент остановится после создания внешне правдоподобного, но фактически незавершенного решения.

Таким образом, рабочий процесс с AI-агентом можно представить как последовательность:

задача → изучение контекста → планирование → изменение проекта → автоматическая проверка → ревью разработчиком

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

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

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

Автоматизация типовых задач разработки

Генерация шаблонного кода

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

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

По отдельности такие действия занимают немного времени. Но в течение проекта они повторяются десятки и сотни раз, создавая значительный объем рутинной работы. Мы используем AI-агентов для автоматизации подобных задач.

Создание заготовок кода

Наиболее частый сценарий — создание стандартного каркаса нового модуля по правилам проекта: заготовки для UI-компонента, страницы, API-запроса, query- или mutation-хука, локального store, формы и схемы валидации, маршрута, вспомогательного сервиса.

Разработчик указывает тип модуля, его название и основные требования. После этого агент может:

1. Определить подходящее место в структуре проекта;
2. Найти аналогичные модули;
3. Создать директорию и необходимые файлы;
4. Подготовить базовые типы;
5. Подключить принятые в проекте библиотеки;
6. Добавить публичные экспорты;
7. Проверить типизацию и линтер.

Например, для нового API-запроса агент может создать функцию обращения к серверу, типы входных и выходных данных, query-хук и ключ кэша. Для локального store — описать начальное состояние, действия, селекторы и публичный экспорт. Для UI-компонента — подготовить файл компонента, типы свойств, стили и index.ts.

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

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

Разработчик получает готовый каркас, встроенный в структуру приложения, и может сосредоточиться на реализации поведения и бизнес-логики.

Базовые UI-компоненты

Наиболее простой сценарий — создание нового UI-компонента по правилам проекта.

Разработчик описывает назначение компонента, его входные параметры, ожидаемое поведение и прикладывает ссылку на компонент из Figma. После этого агент может:

1. Определить подходящее место в структуре проекта;
2. Создать директорию и необходимые файлы
3. Описать типы свойств;
4. Добавить стили;
5. Подготовить публичный экспорт;
6. Проверить типизацию и линтер.

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

Именно контекст проекта превращает обычную генерацию кода в полезную автоматизацию.

Генерация на основе существующей реализации

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

Это могут быть:

• карточки товаров или услуг;
• информационные панели;
• формы;
• модальные окна;
• баннеры;
• списки;
• блоки преимуществ;

Если в проекте уже есть несколько корректных примеров, агент может использовать их как шаблон и создать новый компонент в том же стиле.

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

Что остается за разработчиком при автоматизации задач

Даже в наиболее шаблонных задачах разработчик продолжает отвечать за итоговое решение.

Он проверяет:

• соответствует ли компонент реальной задаче;
• не дублирует ли он существующий код;
• правильно ли выбрано место в архитектуре;
• не усложнена ли реализация;
• учтены ли граничные состояния;
• соответствует ли интерфейс макету;
• не появились ли лишние зависимости.

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

Верстка из Figma через локальный MCP

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

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

Получив эти данные, агент сопоставляет параметры макета с существующими компонентами, классами и переменными дизайн-системы проекта. Для этого мы не используем отдельный формальный механизм преобразования стилей Figma в дизайн-токены — сопоставление выполняет сам агент на основе контекста кодовой базы.

Главная ценность такого подхода заключается не в сложности алгоритма, а в устранении ручного переноса данных. Разработчику достаточно передать агенту ссылку на элемент в Figma, после чего тот может получить необходимые параметры и подготовить реализацию, соответствующую макету и принятым в проекте правилам.

Как выглядит процесс

Работа обычно начинается с того, что разработчик выбирает в Figma нужный экран или компонент, описывает агенту ожидаемый результат, дает ссылку на элемент.

После этого агент может:

1. Получить данные выбранного элемента через MCP;
2. Проанализировать структуру макета;
3. Определить основные визуальные блоки;
4. Сопоставить стили Figma с существующими дизайн-токенами;
5. Создать или обновить код;
6. Вытащить и подключить необходимые изображения;

Такой подход сокращает количество ручных действий между макетом и первой рабочей реализацией.

Агенту не нужно отдельно объяснять, что заголовок имеет конкретный размер, между блоками используется определенный отступ, а карточка содержит изображение, текст и кнопку. Значительная часть этих данных уже присутствует в Figma и может быть получена автоматически.

Использование существующих компонентов проекта

Самая важная задача агента — не просто воспроизвести макет с помощью HTML и CSS, а встроить его в существующую систему.

Если в проекте уже есть кнопка, типографика, карточка, модальное окно или контейнер страницы, агент должен использовать их, а не создавать новые аналоги.

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

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

Работа с изображениями

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

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

Как повысить качество результата

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

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

Документация для AI-агентов

Качество работы AI-агента напрямую зависит от контекста, который он получает. Даже сильная модель не знает внутренних правил проекта, если они нигде не зафиксированы. Она может увидеть текущую структуру кода и попытаться вывести закономерности, но не всегда способна отличить осознанное архитектурное решение от исторически сложившегося исключения.

Поэтому один из ключевых элементов нашей работы с AI — создание документации, ориентированной не только на разработчиков, но и на агентов.

Такая документация описывает конкретные правила проекта:

• где должна находиться логика;
• как организована структура файлов;
• какие компоненты необходимо переиспользовать;
• как работать с API и состоянием;
• какие зависимости допустимы;
• как оформляются публичные экспорты;
• какие проверки нужно выполнить перед завершением задачи.

Главная ценность появляется тогда, когда документация формируется на основе реальной работы агента.

Документация на основе реальных действий

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

Аналогично возникают инструкции для создания компонентов, переноса функциональности, работы с формами, рефакторинга, обновления API, верстки по Figma, проведения технического исследования.

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

Документация как часть инженерной системы

Обычная проектная документация часто создается для онбординга или передачи знаний между разработчиками. Документация для агентов решает похожую задачу, но предъявляет более строгие требования к формулировкам.

Человеку часто достаточно общего принципа. Он способен понять контекст, задать вопрос и самостоятельно интерпретировать исключение. Агенту полезнее получить конкретное правило, область его применения и пример.

Вместо расплывчатой формулировки:

Компоненты должны быть переиспользуемыми.

лучше зафиксировать:

Перед созданием нового UI-компонента проверь существующие компоненты в shared/ui. Новый компонент создавай только в том случае, если существующие нельзя расширить без изменения их исходного назначения.

Еще лучше дополнить правило примерами правильного и неправильного решения.

Роль разработчика

Создание документации для AI не означает, что команда должна заранее описать каждое возможное действие.

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

Наиболее полезна документация, которая отвечает на практические вопросы:

• где этому место;
• что нужно переиспользовать;
• какие ограничения действуют;
• как проверить результат;
• когда агент должен остановиться и запросить решение разработчика.

В этом смысле работа с AI помогает команде лучше формализовать собственные процессы. Чтобы объяснить агенту, как правильно выполнять задачу, сначала необходимо самим договориться о том, что считать правильным.

Где AI не стоит использовать автономно

Чем больше задач команда передает AI-агентам, тем важнее понимать границы их самостоятельности.

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

AI работает с тем контекстом, который ему доступен. Если важное ограничение не описано в задаче, отсутствует в документации и не следует напрямую из кода, агент может его не учитывать.

Масштабные архитектурные изменения

AI хорошо работает, когда задача имеет четкие границы и проверяемый результат.

Гораздо опаснее передавать ему абстрактные поручения вроде «улучши архитектуру проекта» или «перепиши приложение современным способом».

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

Даже если отдельные изменения выглядят разумно, их совокупность может сделать систему сложнее.

Перед крупным рефакторингом необходимо сначала определить:

• какую проблему мы решаем;
• какие части системы разрешено менять;
• какое поведение должно сохраниться;
• по каким критериям оценивается результат;
• как будет выполняться поэтапная миграция;
• как можно откатить изменения.

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

Изменения с трудно проверяемым результатом

Агент наиболее эффективен, когда качество можно проверить автоматически или по понятному сценарию.

Например:

• TypeScript не содержит ошибок;
• тесты проходят;
• сборка завершается;
• компонент соответствует макету;
• API сохраняет контракт;
• производительность измеряется конкретной метрикой.

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

Перед передачей таких задач их необходимо превратить в конкретные проверяемые цели.

Например, вместо общей задачи «ускорь страницу» можно поставить несколько конкретных и проверяемых задач:

• перевести компонент MainHeader на отложенную загрузку, сохранив текущее поведение и внешний вид;
• устранить повторный запрос данных профиля при переходе между страницами, используя существующий кэш React Query;
• исключить повторные рендеры списка при изменении локального состояния фильтра, не меняя публичный API компонентов;
• проанализировать состав начального JavaScript-бандла и подготовить план его уменьшения с указанием основных источников веса, возможных вариантов оптимизации и рисков каждого изменения.

Такая постановка определяет конкретную область работы, ожидаемый результат и ограничения. Агенту не требуется самостоятельно выбирать, какую часть приложения оптимизировать, а разработчик может проверить предложенный план до внесения изменений.

Уровни самостоятельности агента

Не все задачи требуют одинакового контроля. На практике полезно разделять их по уровню риска.

Низкий риск

Агент может работать почти самостоятельно:

• создание шаблонных файлов;
• добавление типовых компонентов;
• обновление локальных стилей;
• переименование внутри ограниченного модуля;
• подготовка документации;
• написание тестов для уже известного поведения.

Средний риск

Требуется промежуточное согласование:

• рефакторинг нескольких модулей;
• изменение работы с API;
• перенос функциональности;
• обновление общих компонентов;
• изменение состояния приложения;
• внедрение новой библиотеки.

Сначала проверяется план, затем реализация.

Высокий риск

AI используется как помощник, но не как автономный исполнитель:

• безопасность;
• авторизация;
• платежи;
• критичная бизнес-логика;
• персональные данные;
• крупные архитектурные изменения;
• изменение производственной инфраструктуры.

В таких задачах агент помогает анализировать, искать варианты и выполнять ограниченные подзадачи, но решение принимает человек.

Человек остается владельцем результата

Использование AI не меняет того, кто отвечает за код после его попадания в production.

Нельзя объяснить ошибку тем, что решение предложил агент. Для пользователя и бизнеса это часть продукта, созданного командой.

Поэтому разработчик должен понимать:

• что именно было изменено;
• почему выбрано это решение;
• какие сценарии проверены;
• какие риски остались;
• как его откатить при необходимости.

Если команда не может объяснить сгенерированный код, такой код не готов к использованию.

Задача команды заключается не в том, чтобы предоставить AI максимальную автономность. Цель — подобрать уровень самостоятельности, соответствующий риску конкретной задачи.

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

Такой подход позволяет использовать преимущества AI, не передавая ему ответственность, которую он не способен нести.

AI ускоряет выполнение решений, но владельцем этих решений остается разработчик.

Заключение

AI-агенты уже сегодня способны выполнять заметную часть фронтенд-разработки: создавать компоненты и страницы, работать с макетами через MCP, планировать изменения, проводить рефакторинг, проверять технические гипотезы и переносить готовую функциональность между проектами.

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

Разработчик определяет цель, формулирует ограничения, предоставляет контекст, принимает архитектурные решения и отвечает за итоговое качество. Агент берет на себя анализ, повторяющиеся действия, создание первого варианта и техническую проверку результата.

Вместе с этим меняются и требования к самим проектам.

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

В этом смысле внедрение AI становится не только способом ускорить разработку, но и поводом улучшить всю инженерную среду.

Мы видим в AI-агентах не замену разработчиков, а новый уровень автоматизации. Они позволяют сократить время на шаблонные операции, быстрее проверять гипотезы и переносить часть механической работы из ручного процесса в управляемый сценарий.

При этом основной принцип остается неизменным:

AI может выполнять работу, но ответственность за результат остается у команды.

Чем понятнее устроен проект, чем точнее описаны правила и чем надежнее система проверок, тем более сложные задачи можно безопасно передавать агентам.

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