Человекоцентричность, или тихая революция в дизайне

Одна из самых значимых перемен в интерфейсном дизайне последних лет происходит почти незаметно. Экран перестал быть самостоятельным продуктом с фиксированной информационной архитектурой. Теперь пользователь формулирует запрос, а агент выполняет задачу и возвращает вместе с текстом UI-компоненты — таблицу, график, карточку с действием или карту. Такой подход называется Generative UI, или GenUI. Но сам по себе пересобираемый экран — не революция. Персонализированную ленту и адаптивную вёрстку индустрия делает уже давно, но каждый раз в итоге пользователю приходиться изучать язык системы, просто другой.

Сейчас наблюдаются две перемены. Первая в том, что точкой входа в сценарий впервые становится жизненная ситуация пользователя, описанная его словами. Вторая в том, что единицей работы дизайнера становится правило, исполняемое в миллионах сгенерированных экранов. Отсюда термин «человекоцентричность», который так часто звучит рядом с GenUI, и трактовать его стоит буквально.

Что такое человекоцентричность

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

Применительно к дизайну он сводится к трём принципам.

• Контекстуальность. Интерфейс выстраивается от жизненной ситуации пользователя, а не от структуры каталога.

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

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

Пример первый: маркетплейс, от неопределённости к покупке

Первые два принципа — классический user-centered design. Человекоцентричность отличает от него третий, который меньше всего проработан в индустрии и к тому же конфликтует с выручкой. Приведу два примера, где все три принципа видны в действии.

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

Каталог превращается в цифрового консьержа и отрабатывает сценарий в четыре шага.

1. Снятие неопределённости. Первый экран уточняет контекст («Похоже, идёт этап приучения к горшку — ребёнку около двух лет?») и подсказывает, что искомое называется «тренировочные трусики». Пользователь возвращает себе контроль над запросом.

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

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

4. Бесшовное завершение. Покупка не требует продолжать диалог, потому что на каждой карточке есть стандартная кнопка «В корзину» на привычном месте, а размер подбирается по весу ребёнка. После нажатия генерация завершается — пользователь уходит в стандартный чекаут. Система не экспериментирует там, где работает мышечная память.

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

Однако, маркетплейс — пример, где перемена выглядит скромнее всего, ведь в конечном счёте это улучшенный поиск.

Пример второй: госуслуги, от каталога услуг к оркестрации ситуации

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

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

2. Одно заявление вместо нескольких. Из аттестованных ведомствами блоков собирается составная интерактивная форма. Основная масса данных подхватывается из профиля и реестров; пользователь заполняет только то, чего у государства нет.

3. Инвариантное подтверждение. Окно проверки и подпись — фиксированный экран хоста, одинаковый для любой цепочки. Здесь пользователь должен точно знать, на что соглашается.

4. Маршрутизация. После подписи части заявления уходят в разные ведомства. Если чего-то не хватает, приходит не отказ, а запрос на уточнение или межведомственный запрос, который агент инициирует сам.

5. Трекер. У пользователя есть статус исполнения, как у почтового отправления, и он не ждёт, а видит, что его вопросом занимаются и на каком он этапе.

Здесь меняется не экран, а единица сервиса, которой становится ситуация человека, а не услуга ведомства. Агент оркестрирует цепочку запросов в рамках политик — примерно так, как это делается в конструкторах агентных сценариев, — а интерфейс оказывается отпечатком этой цепочки. GenUI в этой схеме — самая простая часть. Сложная — правовая основа составного заявления (кто отвечает, если цепочка собрана неверно), доступ к данным между ведомствами и регламент, по которому нехватка документа порождает запрос, а не отказ. Без этих слоёв останется красивый чат, который собирает форму, а дальше приходят пять отдельных отказов.

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

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

Что под капотом: четыре степени свободы

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

Статический уровень. Дизайнер заранее проектирует компоненты — карточку товара, график, форму, — а агент лишь выбирает подходящий и наполняет его данными. Так работают Vercel AI SDK UI и большинство корпоративных ассистентов. Интерфейс полностью предсказуем, но каждый новый сценарий требует разработки.

Декларативный уровень. Агент описывает экран в JSON, используя только компоненты одобренного каталога, а клиент рендерит описание сам. Так устроен протокол A2UI от Google и формат Open-JSON-UI, который приписывают OpenAI. Агент свободно комбинирует блоки, но не может создать элемент, отсутствующий в дизайн-системе.

Открытый уровень. Модель генерирует HTML, CSS и JavaScript с нуля под каждый запрос. Единственный крупный продакшн-пример — dynamic view в Gemini и AI Mode в поиске Google, запущенные 18 ноября 2025 года. Максимальная выразительность при минимальной предсказуемости.

Гибрид MCP Apps. Особняком стоит расширение протокола MCP, официальное с 26 января 2026 года, в котором интерфейс проектирует сервис, а агент лишь вызывает его. Именно так Figma, Canva, Slack, Asana и Salesforce принесли в Claude и ChatGPT собственные виджеты, работающие в изолированном iframe внутри диалога.

Нравятся ли людям такие интерфейсы

Судя по исследованиям — да, с оговорками. Самое цитируемое, «Generative UI: LLMs are Effective UI Generators», опубликовала Google Research в феврале 2026-го. Авторы сравнили пять форматов ответа на один запрос — сайт, спроектированный дизайнером, сайт, сгенерированный Gemini 3 Pro, первый результат поиска Google, обычный текст и markdown. В парных сравнениях сгенерированная страница выиграла у markdown в 82,8% случаев, у первого результата поиска — в 90%, у чистого текста — в 97%. Страница эксперта оказалась сильнее, набрав 50% побед против 35% у генерации. Людям показывали готовые страницы, время генерации в оценку не входило, а визуальную консистентность между генерациями обеспечивала подробная секция «Style» в системном промпте.

Критические работы дают менее оптимистичную картину. Систематический обзор двадцати исследований (журнал Computers, 2026) показал, что одинаковые промпты дают разные интерфейсы как между инструментами, так и при повторных запусках одного, а многостраничные интерфейсы теряют связность навигации. Авторы называют генеративные системы «вероятностными дизайн-агентами» и рекомендуют дать пользователю возможность фиксировать структурные решения.

Исследование «Design Theater» (AIES 2026) проверило, насколько инструменты выполняют заявленные требования. На выборке из 120 интерфейсов более четверти дизайн-решений не были реализованы, среди функциональных требований — треть. Попутно выяснилось, что разные инструменты на одинаковый запрос выдают похожие макеты.

Nielsen Norman Group смотрит шире. Якоб Нильсен назвал генеративный ИИ первой новой парадигмой взаимодействия за шестьдесят лет, в которой пользователь задаёт намерение и результат, а последовательность действий остаётся за системой. Его коллеги описывают будущее дизайна как outcome-oriented — дизайнер проектирует цели и ограничения — и предупреждают, что постоянно меняющиеся интерфейсы создадут проблемы юзабилити.

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

Кто владеет интерфейсом: сервис, хост или модель

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

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

В модели A2UI интерфейсом владеет клиент, в котором работает агент. У клиента есть каталог доверенных компонентов, и любой сервис может лишь наполнять их данными. Это логика нативной платформы с единой дизайн-системой, которая даёт полную консистентность, но растворяет бренд сервиса.

В модели Gemini dynamic view интерфейсом владеет модель. Она сама определяет стиль под запрос, и ни сервис, ни хост не контролируют результат напрямую. Google компенсирует это детальными стилевыми инструкциями в системном промпте и возвращает контроль дизайнеру через него.

Что показал рынок

В ChatGPT, по независимому подсчёту, опубликовано около двух тысяч приложений; каталог коннекторов Claude за одно лето вырос на несколько сотен позиций. Gemini показывает сгенерированные страницы пока только подписчикам в США. Ни OpenAI, ни Anthropic не публикуют метрики использования, поэтому о реальной распространённости приходится судить по косвенным данным.

Единственный крупный кейс с цифрами оказался отрицательным. 29 сентября 2025 года OpenAI вместе со Stripe запустила Instant Checkout — покупку прямо в чате — и обещала, что к ней подключится больше миллиона продавцов с Shopify. По данным, которые Shopify передала Forrester в феврале 2026-го, реально работало около тридцати магазинов; The Information в начале марта насчитала около дюжины. В марте OpenAI свернула нативный чекаут и перевела покупки в приложения самих ретейлеров. Walmart, выставивший в ChatGPT около двухсот тысяч товаров, сообщил WIRED, что конверсия внутри чата была втрое ниже, чем при переходе на собственный сайт. Google ответил протоколом Universal Commerce Protocol с Shopify, Target и Walmart по модели «найди в ИИ — купи в магазине» без покупок внутри чата.

Прогнозы при этом остаются позитивными. Gartner ожидает, что к концу 2026 года 40% корпоративных приложений получат встроенных агентов, а к 2028-му треть пользовательского опыта перейдёт с нативных приложений на агентные фронтенды. Вместе с тем, тот же Gartner предупреждает, что более 40% агентных проектов закроются к 2027 году из-за высоких затрат и неясной ценности.

Граница между изменчивым и инвариантным

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

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

• Консистентность. Интерфейс остаётся узнаваемым от сессии к сессии.

• Безопасность. Агент не может сгенерировать кнопку оплаты, отсутствующую в каталоге.

• Тестируемость. Конечное множество компонентов вместо бесконечного пространства генераций.

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

Пятый аргумент дал «Design Theater», показав, что модели всё равно сходятся к шаблонам. Вопрос лишь в том, будут ли эти шаблоны явными и управляемыми или неявными и случайными.

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

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

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

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

Новая работа дизайнера: правила вместо экранов

В новом подходе работа дизайнера расслаивается на три уровня. Первый — строгая дизайн-система из атомарных компонентов с описанной анатомией, отступами, состояниями и адаптивным поведением. Второй — UX-политики в машиночитаемом формате, то есть промпт-дизайн как дисциплина. Третий — обучение агента эргономике, где закон Фиттса, закон Якоба и принципы гештальта должны быть для него такими же непреложными, как законы физики для инженера.

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

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

Дизайн-система превращается из библиотеки в машиночитаемый контракт для агента. Каталог компонентов становится единственным словарём, доступным агенту. Токены цвета и типографики задают рамку. Правила композиции описываются в формате, который читает модель. Google Labs уже предлагает формат DESIGN.md, текстовое описание дизайн-системы, которое агент загружает перед генерацией.

Персональный каталог и пять решений гибридной модели

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

Nielsen Norman Group формулирует эту ставку прямо. Сегодня интерфейсы проектируют под усреднённого пользователя, а GenUI позволит собирать под каждого его собственный. На первый взгляд это противоречит их же предупреждению о вреде постоянно меняющихся интерфейсов. Противоречие снимается, если персонализация — это однократно выбранная и сохранённая идиома. Авторы системы Maru (UIST 2026) назвали это проблемой персистентности. Сейчас пользователю приходится заново формулировать предпочтения при каждой генерации, тогда как сохранять их нужно как именованные правила.

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

1. Скелет фиксирован хостом. Системные действия, навигация, подтверждения, подпись и оплата инвариантны.

2. Тело экрана собирается декларативно из каталога компонентов.

3. Глубокие сценарии — редактор, карта, дашборд — живут как интерфейс сервиса в песочнице.

4. Открытая генерация допускается только для одноразового контента, такого как объяснения, симуляции и визуализации.

5. Одобренный пользователем вид сохраняется и воспроизводится —везде, где он встречает агента.

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

Доверие против конверсии

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

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

2. Регуляторный. Digital Services Act в ЕС прямо запрещает платформам интерфейсы, которые манипулируют выбором пользователя, и генеративный интерфейс от этого запрета не освобождён.

3. Структурный. Агент, живущий у хоста — ChatGPT, Claude, Gemini, — действует от имени пользователя, политики пишет хост, а сервисам остаётся конкурировать за то, чтобы агент их выбрал. Чем больше сценариев уходит к хостам, тем меньше у сервиса пространства для давления.

Главное возражение бьёт по первому аргументу. Он держится на слове «замеченного». В каталоге пользователь видит альтернативы, а значит, видит и давление. Консьержу он делегирует выбор — и альтернатив не видит вовсе. Агентский канал делает манипуляцию невидимее. Консьерж, который просто не показал лучшее предложение, не вызовет укола недоверия, потому что сравнить не с чем. Хрупкость доверия работает против грубых обманов; тонкие в этом канале безопаснее для бизнеса, чем в каталоге.

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

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

Где подход полезнее всего и из чего собирать

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

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

Подход работает плохо в ежедневных рабочих инструментах вроде торговых терминалов, ERP, диспетчерских, кассовых и медицинских информационных систем. Там пользователь владеет предметным словарём лучше агента. Агент там полезен как ассистент внутри интерфейса, а не как его автор.

Готового решения, в которое можно загрузить каталог и получить такой маркетплейс или такой портал, пока нет. Но строительные блоки зрелые и воспроизводят описанную архитектуру, в которой агент определяет структуру, а движок собирает экран из вашего каталога. Для собственного сайта и приложения главный кандидат — json-render от Vercel Labs. Разработчик описывает каталог допустимых компонентов и действий, модель генерирует только JSON внутри этого каталога, а из одной спецификации рендерятся React, Vue, Svelte, React Native и PDF. Рядом — Tambo, open-source toolkit для React со встроенным циклом агента, стримингом и поддержкой MCP, и CopilotKit, наиболее полный фреймворк с рантаймами агентов, ориентированный на продуктовые команды. assistant-ui даёт примитивы чата с генеративным UI по белому списку компонентов. A2UI от Google — протокол с готовыми рендерерами и Material-каталогом.

Кто первым задаст норму

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

Ждать зрелости рынка — разумная стратегия. Но ментальные модели пользователей формируются именно сейчас, и по закону Якоба все последующие интерфейсы будут оцениваться по меркам того, который они освоили первым. Кто начинает первым, берёт на себя риски, но и получает шанс стать законодателем мод в буквальном смысле. Его правила станут эвристиками, которые через пять лет будут преподавать.

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