Оптимизация кода с помощью ИИ-агентов: роль дизайн-систем и MCP-протокола

# Оптимизация кода с помощью ИИ-агентов: роль дизайн-систем и MCP-протокола

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

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

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

Основная трудность заключается в различии между абстрактными паттернами и конкретными контрактами. ИИ-модели прекрасно знают, как создать flex-контейнер или как расположить элементы по центру. Однако они не знают имен компонентов, допустимых значений пропсов и семантических токенов, используемых в конкретной компании. Вместо использования утвержденных компонентов дизайн-системы (например, FCC UI), модель может сгенерировать код, где стили прописаны через styled.div, а цвета заданы в виде жестко закодированных HEX-значений.

Такой код может функционировать, но он нарушает внутреннюю договоренность проекта. Для бизнеса это «лабораторное чудовище» — решение, которое невозможно интегрировать в существующую архитектуру и поддерживать в будущем. Модель воспринимает задачу поверхностно, игнорируя тонкости реализации.

Архитектура эксперимента

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

1. Базовый режим: Агент работал без каких-либо подсказок или дополнительного контекста. 2. Режим со скиллом: Агенту были даны инструкции (скиллы) о правилах работы с дизайн-системой: запрет на использование сторонних библиотек, необходимость использования компонентов FCC, запрет на inline-стили и HEX-цвета. 3. Режим с MCP: Был подключен сервер MCP (Model Context Protocol), предоставляющий агенту прямой доступ к документации дизайн-системы. Это позволяло модели запрашивать список компонентов, их пропсы, примеры использования и иконки. 4. Комбинированный режим: Включение и скиллов для формирования намерения, и MCP-сервера для получения точных технических данных.

Что такое MCP?

Модель контекстного протокола (MCP) в данном контексте выступает в роли шлюза между мозгом ИИ и реальными данными проекта. Он заменяет абстрактные знания на фактические данные: «какие компоненты существуют», «какие значения принимает параметр цвета», «какие иконки доступны». Это позволяет агенту не гадать, а опираться на актуальные факты.

Анализ результатов

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

* Без контекста: Агент собрал базовую структуру, но использовал неверные методы (align, m0), закомментировал цвета в HEX-коде и не прошел проверку типов. Критически важный уровень. * Только скиллы: Агент понял принципы и отказался от HEX-цветов, используя токены, но ошибся в специфических параметрах компонентов. Код требовал ручной правки, так как агенту не хватало точной информации об API. * Только MCP: Код прошел проверку и был рабочим. Однако реализация была менее детальной. Например, статусы отображались как простые текстовые бейджи, без использования дополнительных иконок, так как модель не знала о необходимости их добавления без направляющих правил. * Комбинация (Скилл + MCP): Этот подход оказался наиболее эффективным. Модель использовала компоненты FCC и семантические токены, избегая хардкода. Она добавила иконки для различных состояний (активный/архивный) и прошла все проверки. Примечательно, что наличие скилла помогло агенту структурировать запросы к MCP, сделав их более эффективными.

Риски и ограничения автоматизации

Несмотря на успех комбинированного метода, эксперимент выявил новые точки отказа. Во-первых, подключение MCP делает процесс зависимым от работы внешнего сервера. Ошибки, задержки или неполные данные от сервера могут привести к сбоям в работе модели. Во-вторых, статические правила (скиллы) требуют ручного обновления. Если в дизайн-системе появятся новые компоненты или изменятся правила, инструкция в скилле станет устаревшей, и модель будет следовать некорректным правилам, воспринимая их как актуальные.

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

Вывод

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

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