Если кодовые агенты уже умеют собирать интерфейсы, следующая проблема почти неизбежна: как заставить их держать единый визуальный стиль без бесконечных ручных правок. Именно сюда и бьёт DESIGN.md — открытая спецификация от Google Labs Code, которая пытается превратить дизайн-правила в понятный для агентов рабочий контекст.

Источник: google-labs-code/design.md

Что это такое

DESIGN.md — это формат для описания визуальной идентичности продукта и правил дизайн-системы так, чтобы с ними могли работать кодовые агенты. По сути, это не отдельный сервис с кнопкой «сделай красиво», а слой спецификации: команда фиксирует, как должен выглядеть интерфейс, а агент получает не смутные пожелания, а структурированное описание.

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

Как это работает

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

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

Сколько это стоит

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

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

Плюсы

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

Минусы

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

Какие есть альтернативы

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

Вердикт

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

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

Кому стоит попробовать

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

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