Дизайн — это код

Как логика клеточных автоматов изменит агентные дизайн-системы и почему будущее веб-разработки, возможно, уже записано в простых правилах

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

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

Какая именно? Дизайн — это код.

Это не просто броская фраза. Это признание того, что мы, возможно, движемся к миру, где дизайн-системы работают как клеточные автоматы: простые правила порождают сложное, эмерджентное поведение. К миру, где грань между «проектированием» чего-либо и его «программированием» исчезает полностью. Где автономные агенты не просто используют дизайн-системы, а являются дизайн-системами в действии.

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

Мы посмотрим, как Drupal и современные CMS-платформы интегрируют ИИ с помощью таких модулей, как Schema.org Blueprints и Drupal AI. И подумаем, что всё это значит для дизайнеров, разработчиков и будущего создания цифровых продуктов.

Клеточные автоматы и логика эмерджентности

Красота простых правил

В 1970 году математик Джон Конвей представил «Игру «Жизнь»» — «игру без игроков», которая стала одной из самых изученных систем в теории вычислений. Правила захватывающе просты:

1. Любая живая клетка, у которой меньше двух живых соседей, умирает (недостаток населения)
2. Любая живая клетка с двумя или тремя живыми соседями выживает
3. Любая живая клетка, у которой больше трёх живых соседей, умирает (перенаселение)
4. Любая мёртвая клетка ровно с тремя живыми соседями оживает (размножение)

Из этих четырёх правил, выражаемых горсткой бинарных условий, возникает поразительная вселенная сложности. Глайдеры скользят по бесконечным сеткам. Осцилляторы пульсируют в вечном ритме. «Ружья» выпускают потоки узоров в клеточное пространство. И самое удивительное: доказано, что «Жизнь» полна по Тьюрингу: всё, что можно вычислить алгоритмически, в принципе можно вычислить на простой сетке Конвея.

Рисунок 1: «Ружьё Госпера» в игре «Жизнь» Конвея. Этот узор непрерывно порождает поток глайдеров и показывает, как простые правила способны создавать бесконечную, самовоспроизводящуюся сложность.

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

Петли Лэнгтона и самовоспроизведение

В 1984 году Кристофер Лэнгтон развил этот принцип в своих самовоспроизводящихся петлях — клеточном автомате, продемонстрировавшем подлинные принципы искусственной жизни. В отличие от игры «Жизнь» Конвея, где возникает сложность, в петлях Лэнгтона возникает размножение.

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

Рисунок 2: Петля Лэнгтона в начальной конфигурации. Генетическая информация циркулирует по петле и направляет построение дочерних петель с помощью растущего отростка.

«Если в клеточном автомате возможна самовоспроизводящаяся машина, то и жизнь, возможно, достижима для машин».

— Кристофер Лэнгтон, «Изучение искусственной жизни с помощью клеточных автоматов» (1986)

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

• Набор простых локальных правил
• Механизм кодирования инструкций
• Процесс, в котором эти инструкции исполняются

Правила — это организм. Замысел — это код.

В 1999 году Хироки Саяма представил эволупы — варианты, в которых есть структурная растворимость и фенотипические взаимодействия, что допускает спонтанные мутации и эволюционную динамику. Эти петли эволюционируют через прямые физические столкновения во время размножения, что приводит к вариациям генотипа, росту морфологического разнообразия и усложнению от поколения к поколению. В отличие от фиксированного размножения у Лэнгтона, эволупы демонстрируют наследуемые мутации без внешнего вмешательства.

Правило 110 и универсальные вычисления

Исследование элементарных клеточных автоматов Стивеном Вольфрамом завершилось поразительным открытием: Правило 110 — одно из всего 256 возможных правил для простейшего типа одномерного клеточного автомата — способно к универсальным вычислениям.

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

Рисунок 3: клеточный автомат «Правило 110». Несмотря на простое определение, Правило 110 демонстрирует поведение класса 4 — сложные узоры, которые не являются ни полностью устойчивыми, ни полностью хаотичными, — и для него доказана полнота по Тьюрингу.

«Чтобы выполнять универсальные вычисления, вовсе не нужен целый компьютерный процессор. Достаточно вот этого маленького правила».

— Стивен Вольфрам, «Новый вид науки»

В 2004 году Мэтью Кук опубликовал доказательство того, что Правило 110 с определённым повторяющимся фоновым узором полно по Тьюрингу. Доказательство показывает, что Правило 110 способно эмулировать циклические системы тегов, а те, в свою очередь, могут эмулировать любую машину Тьюринга. Из 88 возможных уникальных элементарных клеточных автоматов Правило 110 — единственное, для которого полнота по Тьюрингу доказана напрямую.

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

Метаячейка 0E0P: настоящее самовоспроизведение

В октябре 2018 года Адам П. Гоучер завершил построение метаячейки 0E0P — паттерна в «Игре жизни» Конвея, способного к настоящему самовоспроизведению. В отличие от прежних метаячеек, которым требовались готовые копии поблизости, метаячейка 0E0P может построить свои копии с нуля, включая собственную ленту инструкций.

Это достижение — веха в области искусственной жизни: система, которая распространяет саму себя в вычислительной среде, пользуясь только локальными правилами. 23 ноября 2013 года Дейв Грин построил первый в «Игре жизни» репликатор, создающий полную копию самого себя, включая ленту инструкций, — и показал, что даже простой двухсостоятельный автомат Конвея способен поддерживать неограниченное самовоспроизведение.

Дизайн-системы как вычислительная среда

От атомарного дизайна к агентному дизайну

Методология атомарного дизайна (Atomic Design) Брэда Фроста, представленная в 2013 году, произвела революцию в том, как мы думаем о дизайн-системах. Разбивая интерфейсы на атомы (базовые элементы вроде кнопок и полей ввода), молекулы (простые сочетания), организмы (сложные разделы интерфейса), шаблоны (макеты страниц) и страницы (итоговые реализации), атомарный дизайн дал иерархическую структуру для управления сложностью.

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

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

- Джош Кларк, «Самые интересные дизайн-системы скучны»

В феврале 2023 года Брэд Фрост написал о «дизайн-системах в эпоху ИИ»:

«ИИ — естественный потребитель дизайн-системы... Дело в том, что значительная часть работы над компонентами дизайн-системы действительно механическая и предсказуемая. Мы уже используем такие инструменты, как PlopJS, чтобы выдавать заготовку компонента, повторяющую устройство остальной библиотеки. Я был бы рад помощи ИИ в создании множества типовых заготовок».

- Брэд Фрост

Именно механическая и предсказуемая природа дизайн-систем делает их пригодными для работы по принципу клеточных автоматов. Когда правила ясны, локальны и применяются последовательно, агенты могут действовать самостоятельно — так же как клеткам в «Жизни» Конвея не нужен центральный контроллер, чтобы порождать глайдеры и осцилляторы.

Императив машиночитаемости

Инициатива Storybook MCP (Model Context Protocol) — важный шаг эволюции в этом направлении. Анонсированный в конце 2025 года, Storybook MCP предоставляет ИИ-агентам для написания кода машиночитаемые метаданные компонентов из уже существующих настроек Storybook.

Главное здесь в том, что агентам нужен не сырой код и не визуальная документация. Им нужно:

• Манифесты компонентов: структурированные метаданные о каждом компоненте — его свойства, варианты, привязки к дизайн-токенам и примеры использования
• Семантические имена: токены с явным смыслом, такие как action.primary.confirm — они передают агентам значение, а не просто величину
• Циклы проверки: возможность запускать тесты, видеть сбои и самостоятельно исправлять ошибки

«Storybook MCP помогает агентам следовать вашим паттернам и проходить ваши тесты. Он даёт агентам то, чего у них раньше не было: машиночитаемые метаданные компонентов и итеративный цикл, в котором они сами исправляют свои ошибки».

- Команда Storybook

В Storybook MCP есть автономный цикл коррекции. Агенты запускают тесты ваших компонентов (взаимодействие и доступность), смотрят, что не прошло, и сами исправляют свои баги. Разработчику остаётся вмешаться лишь после того, как тесты пройдены. Больше не нужно нянчиться с промптами.

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

Манифест компонента как геном

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

Манифест компонента может задавать, например, следующее:

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

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

Я согласен с Брэдом Фростом в том, что нужен формат yaml.

Компоненты Drupal используют формат yaml. Примерно так

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

Дизайн — это код.

• Варианты
• Токены
• Свойства (Props)

• Ограничения (их можно добавить в компоненты)

• Правила для слотов (что можно размещать в других слотах и что разрешено размещать в моём слоте)

• Правила

• Примеры 

• Анимации  ( разрешено использовать или рекомендовано )

Затем наблюдайте и экспериментируйте с поведением.

как в https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Дизайн-токены как переменные среды

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

В современных архитектурах токенов используется несколько уровней:

• Базовые токены: Исходные значения, например color.blue.500: #3B82F6
• Семантические токены: Ссылки, отражающие назначение, например color.action.primary: color.blue.500
• Токены компонентов: Применение в рамках компонента, например button.background.primary: color.action.primary

Когда агент генерирует компонент Button, ему не нужно знать, что «primary» означает синий цвет. Достаточно сослаться на button.background.primary и довериться тому, что система токенов подставит нужное значение. Среда (слой токенов) хранит информацию, а компонент (клетка) лишь должен на неё откликаться.

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

Экосистема Drupal и интеграция ИИ

Интеграция ИИ в системы управления контентом — идеальная лаборатория для изучения принципа «дизайн — это код». CMS вроде Drupal уже воплощают его основные идеи: структурированные типы контента, определения полей, связи и правила композиции.

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

 Идеальный компьютерный набор, о каком можно мечтать. Разработчики, словно перенесённые из будущего «Звёздного пути», говорят с компьютером, чтобы он программировал за них.

Агентский опыт (AX) и новый пользователь

Проектирование для машин

В начале 2025 года Матиас Бильманн, генеральный директор Netlify, ввёл понятие «агентский опыт» (Agent Experience, AX) — новой дисциплины, изучающей, как ИИ-агенты взаимодействуют с продуктами и платформами.

Сдвиг здесь принципиальный. Десятилетиями UX (пользовательский опыт) оптимизировали под человеческое восприятие, мышление и поведение. DX (опыт разработчика) оптимизировали под людей, которые создают программное обеспечение. AX исходит из того, что агенты становятся основными пользователями цифровых систем — а потребности у них совсем другие:

• Их не волнует визуальная эстетика — им нужны только структурированные данные, которые можно разобрать программно
• Они не перемещаются по интерфейсам — они вызывают API и обрабатывают манифесты
• Они не читают документацию так, как люди — им нужен машиночитаемый контекст
• Они не выносят субъективных суждений — они следуют правилам и ограничениям

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

— AX Research

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

Задача двойного интерфейса

Проектировать для AX значит одновременно создавать два интерфейса:

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

Это отражает архитектуру клеточных автоматов, в которой сосуществуют две разные точки зрения:

• Локальная точка зрения: каждая клетка (агент) следует простым правилам, опираясь на своих ближайших соседей
• Глобальная точка зрения: возникают сложные паттерны, которые видны только в масштабе целого

«Проектирование агентского опыта (AX) должно обеспечивать удобство использования как для агентов, так и самими агентами. Поэтому хороший AX ведёт к хорошему пользовательскому опыту (UX). Если ИИ-агент сталкивается со сломанным процессом, протоколом или даже непоследовательными формулировками в разных системах, он не может выполнить задачу. Для агента это плохой опыт, а он, в свою очередь, приводит к плохому опыту клиента или сотрудника».

— Кэт Холмс, директор по опыту (Chief Experience Officer), Salesforce

От UX к AX: эволюция цифрового дизайна

Стигмергия и непрямая коммуникация

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

В агентских дизайн-системах стигмергия проявляется так:

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

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

Паттерны агентского проектирования

Эндрю Ын и другие выделили четыре ключевых паттерна для агентных ИИ-систем:

1. Рефлексия: ИИ оценивает собственный результат и шаг за шагом улучшает его
2. Использование инструментов: ИИ взаимодействует с внешними инструментами, API и системами
3. Планирование:ИИ разбивает сложные задачи на подзадачи и выполняет их последовательно
4. Мультиагентность: Несколько специализированных агентов совместно решают сложные задачи

Эти паттерны напрямую соответствуют понятиям клеточных автоматов:

Дизайн — это код: более глубокое прочтение

Что на самом деле означает «Дизайн — это код»

Когда мы говорим «дизайн — это код», мы одновременно утверждаем сразу несколько вещей:

1. Семантическая эквивалентность

Дизайнерские решения, если их правильно закодировать, становятся исполняемыми. Токен дизайна — это не просто значение, а инструкция. Спецификация компонента — это не просто документация, а программа. Когда агенты используют эти артефакты, они не только реализуют дизайн, но и исполняют его.

2. Порождающая способность

Так же как Rule 110 может вычислить всё, что вообще вычислимо, достаточно полная дизайн-система способна породить любой допустимый интерфейс. Система содержит в себе потенциал всех своих допустимых проявлений. Что из неё получится, зависит только от начальных условий (требований) и правил (ограничений).

3. Возникающая сложность

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

4. Вычислительная несократимость

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

5. Самомодификация

Как эволупы (evoloops), мутирующие при репликации, дизайн-системы, готовые к работе с агентами, могут развиваться в процессе использования. Компоненты, созданные агентами, становятся частью библиотеки, которую будут использовать будущие агенты. Система учится, адаптируется и растёт.

Расширенная метафора клеточных автоматов

Больше чем метафора: реальная конвергенция

Но это не просто метафора. Конвергенция реальна и происходит прямо сейчас:

• Storybook MCP превращает библиотеки компонентов в машиночитаемые инструкции, которые исполняют агенты
• Model Context Protocol стандартизирует то, как агенты получают доступ к инструментам и контексту, создавая универсальную основу для агентных операций
• Мультиагентные архитектуры распределяют работу между специализированными агентами (архитектор, программист, ревьюер), которые взаимодействуют по протоколам — как клетки с разными функциями
• Самовосстанавливающиеся циклыи **агентов** запускать тесты, находить ошибки и повторять итерации — те же механизмы обратной связи, с помощью которых клеточные автоматы развивают устойчивые конфигурации
• Schema.org Blueprints делает структуры контента машиночитаемыми и семантически осмысленными
• Drupal AI даёт инфраструктуру, с помощью которой ИИ-агенты самостоятельно создают, изменяют и ведут контент

Мы не рассматриваем принцип «дизайн — это код» как философскую позицию. Мы строим его как техническую инфраструктуру.

Что это значит и что ждёт впереди

Для дизайнеров

Роль дизайнера меняется: из «рисовальщика прямоугольников» он становится «автором правил». Как заметил Брэд Фрост:

«Дизайнерам и разработчикам, которые видят свою работу в рисовании прямоугольников, есть о чём беспокоиться. А тем, кто видит свою работу в решении задач — и лишь попутно рисует или использует какие-то прямоугольники, — бояться почти нечего».

— Брэд Фрост

В агентном будущем дизайнеры будут:

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

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

Для разработчиков

Разработчики становятся архитекторами агентных систем. Как пишет Anthropic:

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

Разработчикам предстоит:

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

Для веб-разработки и CMS-платформ

Интеграция ИИ в такие платформы, как Drupal, указывает на будущее, в котором:

• Модели контента становятся пригодными для агентов благодаря стандартам вроде Schema.org
• Редакционные процессы получают помощь агентов — черновики, модерация и оптимизация с поддержкой ИИ
• Поиск эволюционирует от сопоставления ключевых слов к семантическому пониманию с помощью эмбеддингов и векторных баз данных
• Персонализация становится автономной — агенты изучают предпочтения пользователей и в реальном времени подстраивают контент
• Разработка ускоряется — агенты генерируют компоненты, тесты и документацию

То, что экосистема Drupal активно осваивает ИИ — через такие модули, как Drupal AI, Drupal Canvas, Schema.org Blueprints и интеграцию с ИИ-провайдерами, — показывает, что это будущее уже строится.

Для организаций

Конкурентное преимущество будет у тех организаций, чьи дизайн-системы в наибольшей степени «готовы к агентам». У таких систем есть:

• полное покрытие состояний и вариантов компонентов
• семантические имена, отражающие назначение
• машиночитаемая документация и контекст
• инфраструктура валидации и тестирования
• чёткие ограничения, очерчивающие пространство допустимых результатов
• API, спроектированные для использования агентами (AX-first)
• контентные архитектуры, ориентированные на Schema.org

Для будущего цифровых продуктов

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

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

Вывод: код жив

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

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

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

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

Мы стоим на пороге новой эры цифрового творчества. Агенты уже здесь. Протоколы складываются. Дизайн-системы становятся подложкой для искусственной жизни.

Дизайн — это код.
И код оживает.

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

• Design Systems in the Time of AI — Брэд Фрост (Brad Frost)
• Storybook MCP Sneak Peek — Storybook
• Introducing AX: Why Agent Experience Matters — Матиас Билман (Mathias Biilmann)
• Building Effective Agents — Anthropic

Ресурсы по Drupal AI

• Drupal AI

• Модуль Schema.org Blueprints

   

Ресурсы по клеточным автоматам

• Conway's Game of Life Lexicon — около 1500 фигур
• A Working Turing Machine in Game of Life
• Langton's Loops — Wikipedia
• Rule Sets for Cellular Automata
• A New Kind of Science Online — Стивен Вольфрам (Stephen Wolfram)
• Cellular Automata — Nature of Code

Исследование идей на стыке теории вычислений, дизайн-систем, искусственного интеллекта и веб-разработки.

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

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

Дизайн — это код, когда система работает в цикле, подобном жизненному циклу, внутри выбранного холста и набора правил.