Попросите ИИ-агента сделать страницу настроек, и через минуту она готова. Код компилируется, тесты проходят, выглядит почти как надо. Откройте diff: там может оказаться новый компонент кнопки, несколько hex-цветов и шкала отступов, которую никто не утверждал. Агент не игнорировал вашу дизайн-систему. Он её просто не видел.
В статье разбираем механику: почему агенты пишут рабочий интерфейс в обход системы, почему такого кода становится всё больше и что на самом деле помогает.
Коротко
- 84% разработчиков пользуются ИИ-инструментами или собираются начать. Главное раздражение: код «почти правильный, но не совсем» (Stack Overflow Developer Survey 2025).
- Агент знает только то, что есть в его контексте. Ваших токенов, компонентов и соглашений там обычно нет.
- Код в обход системы проходит тесты: тесты проверяют поведение, а не то, взят ли цвет из токена.
- Дайте агенту систему как контекст, а результат проверяйте вне модели, так же как любой другой код проверяет линтер.
Что пишет агент
Вот такой компонент агент пишет, если попросить главную кнопку для страницы настроек (условный пример, а не вывод конкретного инструмента):
export function SaveButton({ onClick }: { onClick: () => void }) {
return (
<button
onClick={onClick}
style={{ background: "#2563eb", color: "#fff", padding: "10px 18px", borderRadius: 8 }}
>
Save changes
</button>
);
}А вот что в системе команды уже было:
import { Button } from "@acme/ui";
<Button variant="primary" onClick={onSave}>Save changes</Button>Обе рисуют синюю кнопку. Но только одна последует за ребрендингом, тёмной темой, исправлением фокусного кольца или новым состоянием загрузки. Сгенерированная кнопка — это обход системы: код идёт мимо системы, хотя в ней есть всё нужное.
Почему агенты обходят дизайн-систему
Агент видит окно, а не вашу систему
Модель пишет из того, что лежит в её контексте: промпт, открытые файлы, всё, что нашёл инструмент. Дизайн-система обычно живёт в другом месте. Это пакет в node_modules, библиотека в Figma, сайт документации или файл токенов через три папки. Если ничего из этого нет в окне контекста, агент берёт общие шаблоны. А в открытом коде полно кнопок со стилями, написанными руками.
DevClass в материале об исследовании качества кода GitClear 2025 года описывает тот же механизм: «ИИ реже предлагает переиспользовать похожую функцию из другого места в коде, отчасти из-за ограниченного размера контекста» (DevClass, 2025).
Ничего не падает
В сгенерированной кнопке нет бага, который поймал бы тест. Она нажимается, сохраняет, подпись верная. Нарушение дизайн-системы не ошибка времени выполнения, поэтому CI остаётся зелёным. В этом отличие от ошибки типов или упавшего теста: ничто не заставляет кого-то посмотреть.
Больше ИИ-кода, больше дублей
ИИ-помощники стали нормой. В Stack Overflow Developer Survey 2025 84% участников пользуются ИИ-инструментами или собираются начать, а 50,6% профессиональных разработчиков работают с ними каждый день (Stack Overflow). По данным GitHub, почти 80% новых разработчиков на платформе пробуют Copilot в первую же неделю (Octoverse 2025).
Чем больше сгенерированного кода, тем больше интерфейса должен проверить каждый ревьюер. DevClass пишет, что тот же анализ GitClear охватил 211 млн изменённых строк. 2024 год стал «первым, когда скопированных строк оказалось больше, чем перемещённых», а блоков из пяти и более повторяющихся строк за год стало в восемь раз больше (DevClass). Локальный SaveButton — такое же дублирование, только в интерфейсе.
Разработчики и сами не до конца доверяют
Разработчики здесь не наивны. В том же опросе точности ИИ-инструментов не доверяют больше участников (46%), чем доверяют (33%). А 66% называют главным раздражением «ИИ-решения, которые почти правильные, но не совсем». Компонент вне системы и есть это «почти правильно», только в интерфейсе.
Как не дать ИИ-интерфейсу уйти из системы
Брэд Фрост (Brad Frost) в посте о своём курсе по ИИ и дизайн-системам прямо называет ставки. По его словам, генеративный ИИ «может устроить огромный бардак», а дизайн-системы «дают качественную инфраструктуру интерфейса и важный организационный контекст, который помогает удержать ИИ на рельсах» (Brad Frost, 2025). На практике это два слоя.
1. Дайте агенту систему
Агент может переиспользовать только то, что найдёт. Вот три способа положить систему в его контекст, от простого к надёжному:
Rules-файл — самый дешёвый старт. Несколько строк в AGENTS.md или в rules-файле вашего редактора уже меняют то, за чем тянется агент:
## UI
- Build UI from `@acme/ui`. Check its exports before writing a component.
- Never hard-code colours, spacing or radii. Use tokens from `@acme/tokens`.
- A button is always `Button` from `@acme/ui`, with `variant` and `loading`.Третий вариант — MCP (Model Context Protocol), стандартный способ вызывать инструменты прямо во время задачи. Инструмент дизайн-системы может ответить раньше, чем агент что-то напишет. Обмен может выглядеть так (условный пример):
agent → find_component("button with a loading state")
tool ← Button from @acme/ui
props: variant = "primary" | "secondary", loading: boolean
used in 142 files; example: <Button variant="primary" loading={saving}>
deprecated: LegacyButton, use Button insteadТеперь у агента есть причина импортировать Button, а не писать SaveButton.
2. Проверяйте результат вне модели
Контекст снижает число обходов, но не сводит его к нулю. Поэтому проверка должна стоять там, где проходит каждое изменение: в pull request.
- Ловите обходы линтером. Зашитые цвета, отступы без токенов и токены палитры ловит правило, одинаково для кода человека и ИИ. Два примера:
color-no-hexв Stylelint (для стилей) иensure-design-token-usageот Atlassian. В заметке о том, как найти зашитые цвета в кодовой базе React, есть шаблоны поиска, из которых можно собрать свои правила. - Отмечайте дубли компонентов. Новый файл, который рисует
<button>с инлайн-стилями в репозитории, где уже естьButton, заслуживает комментария на ревью. - Следите за трендом. Считайте обходы по неделям. Если их число растёт вместе с использованием ИИ, слой контекста пока не работает. Как считать, показываем в руководстве по измерению здоровья дизайн-системы.
Где здесь FISYCO
Мы делаем FISYCO, и он закрывает оба слоя. Его MCP-сервер отвечает агентам до того, как они напишут интерфейс: какие компоненты есть, как их вызывают в этом репозитории, что устарело. Каждый вызов записывается в журнал. Лид дизайн-системы видит, как часто агенты переиспользовали систему и чего не нашли. В журнал попадает вызов инструмента, а не ваш исходный код и не промпт агента. С другой стороны, FISYCO индексирует код и показывает обходы токенов и компонентов в отчёте о здоровье системы.
