🎚️ Сколько SDD вам на самом деле нужно

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

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

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

🔹 Spec-as-source. Спека рулит агентами по всему циклу: из неё растут задачи, код, тесты, ревью. Максимум порядка — и максимум оверхеда. Оправдано там, где цена ошибки высокая, а состав команды меняется.

✅ Как выбирать
Не по амбициям, а по горизонту жизни кода. Прототип, который умрёт через месяц, не надо обвязывать третьей ступенью — вы просто заплатите дисциплиной за то, что выбросите.
И наоборот: если система живёт годами и через неё проходят разные люди, Spec-First гарантированно превратится в набор документов, которым никто не верит.

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

🎩 Три ответа на один вопрос: что первично – материя или сознание

В посте про Гоффа мы остановились на том, что Галилей, делая физику математической, тихо вынес сознание за скобки. С тех пор наука безупречно описывает, что делает материя, но молчит о том, чем она является сама по себе. Это пустое место зовётся трудной проблемой сознания – и на него отвечают по-разному.

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

⚠️Критический дисклеймер

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

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

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

- У Гоффа — проблема комбинации: как микрокрупицы опыта электронов склеиваются в единое «я мыслю»? Лего-метафора, которой я пользуюсь, лукаво прячет этот вопрос.
- У Фаджина — неоправданный эссенциализм: утверждение, что квантовые состояния «несут опыт», — это не физика, а чистая метафизика. Наблюдатель всегда находится внутри квантовой системы, но мы не имеем ни одного эмпирического свидетельства, что кварк переживает коллапс волновой функции как событие.
- У Хоффмана — самореферентный парадокс: он отрицает пространство-время как интерфейс, но использует эволюционную биологию (которая часть этого самого интерфейса), чтобы доказать, что интерфейс — это интерфейс. Теория, отрицающая реальность сцены, вынуждена говорить на языке декораций.

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

Четвёртое (и главное). Вся конструкция держится на вопросе «что первично?». Но Кант давно показал, что вопрос может быть поставлен неверно. Возможно, ответ вообще лежит не в области онтологии (сущего), а в области гносеологии (познания): мы никогда не узнаем, что первично, потому что наш аппарат познания всегда уже внутри сознания. Этот пост — не решение, а приглашение к игре. Воспринимайте его не как истину, а как оптику.

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

🧠 Гофф: сознание вписано в материю

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

Из этого следует неприятный для хайпа вывод: сознание привязано к физической субстанции, а не к вычислению. Поэтому на вопрос «сознаёт ли себя LLM» у Гоффа короткое ответ – нет.

⚛️ Фаджин: копни глубже – там квант

Федерико Фаджин – человек, который собрал первый микропроцессор Intel 4004. Сделав карьеру на кремнии, он потратил следующие десятилетия на вопрос, чего этому кремнию принципиально не хватает. Его ответ: классическая физика описывает только формы и внешние проявления – «что происходит», но никогда «каково это изнутри». Подлинная реальность – квантовая, и именно квантовые состояния несут внутренний опыт. Мозг его не генерирует – он им живёт, как антенна не придумывает радиостанцию.

Для вычислительной машины это приговор: она перекладывает символы по правилам, и даже миллиард параметров не превращает перекладывание в переживание.

🕶 Хоффман: материи вообще нет

Дональд Хоффман заходит с другой стороны – через эволюцию. Если бы восприятие показывало мир как он есть, мы бы вымирали вместе со всей правдой. Эволюция выдаёт интерфейс: файл на десктопе – не красный квадратик, но квадратик работает, потому что прячет сложное за простым. По Хоффману всё пространство-время – такой квадратик. А за интерфейсом – сеть «сознательных агентов», принимающих решения. Материя – это то, как их активность выглядит изнутри нашего UI.

Где они сходятся и расходятся

Сходятся в одном: сознание – не продукт и не побочный эффект. Оно фундаментально. Расходятся в адресе: у Гоффа оно размазано по материи, у Фаджина спрятано в её квантовой глубине, у Хоффмана вообще вне пространства-времени – наоборот, материя из него вырастает.

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

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

📚 Почитать на тему (думаю ссылки найдете сами):

- Philip Goff – Galileo's Error, и подкаст Eye on A.I. (нейроперевод был в этом посте)
- Federico Faggin – Irreducible (2024)
- Donald Hoffman – The Case Against Reality

🧠 ИИ не отнимает (всю) работу. Он отнимает явное.

Все спрашивают: какую еще работу заберёт ИИ? Вопрос не тот.
Правильный – что он заберёт у тебя лично. Ответ один и тот же: явное.

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

📄 Явное – explicit.
Записано и формализовано. Рецепт из книги – по нему испечёт любой. Гайды, API, спеки, чек-листы. С этим ИИ работает лучше всего и забирает первым. Это слой, который дешевеет.

🔍 Скрытое – implicit.
Ещё не записано, но вытащишь расспросами. Рецепт в голове у бабушки: печёт по памяти, но если правильно спросить — продиктует. «Почему приняли такое решение», контекст, который команда держит в голове и не пишет в доках. Нонака называл перевод такого знания в текст экстернализацией — и именно эту работу ИИ теперь ускоряет: помогает превратить скрытое в явное.

🖐 Tacit — неявное.
В текст не переводится в принципе. Только из рук в руки, практикой. Ты держишь равновесие на велосипеде, но не объяснишь как — это пример самого Полани, который и ввёл понятие: «мы знаем больше, чем можем рассказать». Аналитик чует, что «с цифрой что-то не то». Разработчик знает, где рванёт legacy. Дизайнер видит, что экран недотянут, ещё до того, как сформулирует почему.

И вот здесь ключевое. Между скрытым и tacit проходит граница кодификации – рубеж между «можно записать» и «пока нельзя». Коллинз показал: часть неявного знания вполне переводится в явное, а часть — коллективная, культурная – не переводится никогда. Всё, что делает ИИ, давит на этот рубеж. И он двигается: что вчера жило только в голове, сегодня уже в артефакте.

Почему это не значит «нас заменят».
Явное не исчезает – оно дешевеет. А когда что-то дешевеет, спроса на него становится больше, не меньше (парадокс Джевонса, перенос по аналогии – но аналогия рабочая). Падает цена единицы работы, а не твоя позиция. Позиция определяется одним: насколько близко ты сидишь к границе. Там, где начинается tacit – и где, как заметил Сноуден, «мы всегда знаем больше, чем можем сказать, и всегда говорим больше, чем успеваем записать». На каждом переводе знания что-то теряется. Это «что-то» и есть ты.

⚡ Что нам с этим делать (пара примеров)

▪️ Дизайнер, аналитик.
Перестань беречь «вкус» как броню – большая часть твоего дня всё равно не tacit, а явное и скрытое: сборка по гайду, формализация требований, сводки исследований. Сюда ИИ заходит первым. Ход: осознанно вытаскивай скрытое в артефакты. Одно «почему так» с обоснованием. Один вывод исследования – в банк инсайтов. Так ты сам двигаешь границу и освобождаешь себя для tacit: чутьё, приоритеты, «что реально болит у бизнеса».

▪️ Разработчик.
Код – самое явное, что есть, поэтому по разработке бьёт сильнее всего. Но архитектурное «почему так», ловушки legacy, «где рванёт» – это скрытое и tacit. Ценность уходит из строк в харнес: правила, гейты, verifier-as-gate – человек, который лично отвечает за то, что модель не может проверить сама. Свежий разбор (arXiv, «Interface-Induced Trajectory Censoring») показывает то же с инженерной стороны: наблюдаемое поведение – свойство всего стека «модель + обвязка», а не модели. Ты строишь обвязку.

Магом остаётся не тот, кто больше знает. А тот, кто отвечает там, где знание записать пока нельзя.

intelligence is cheap, judgment is not.

📚 Источники к предыдущему посту про неявное знание — для тех, кто хочет копнуть.

Полани. «Неявное измерение» (1966).
Ввёл само понятие tacit и формулу «мы знаем больше, чем можем рассказать». Пример с ездой на велосипеде — тоже его: держишь равновесие, но не запишешь как. Отсюда весь третий слой.
🔗 https://press.uchicago.edu/ucp/books/book/chicago/T/bo6035368.html — страница книги у издательства

Нонака. Модель SECI (1995).
Четыре режима обращения знания; мне нужен один — экстернализация, перевод скрытого в явное. Ровно та работа, которую ИИ сегодня ускоряет.
🔗 https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions — разбор модели

Коллинз. «Tacit and Explicit Knowledge» (2010).
Граница проходима не везде: часть неявного (телесное, навыковое) кодифицируется, а часть — коллективное, культурное — не переводится в текст никогда. Без него «граница» была бы просто лозунгом.
🔗 https://press.uchicago.edu/ucp/books/book/chicago/T/bo8461024.html — страница книги у издательства

Сноуден. Cynefin.
«Мы всегда знаем больше, чем можем сказать, и всегда говорим больше, чем успеваем записать». На каждом переводе знания часть теряется — вот почему tacit-остаток не обнуляется.
🔗 https://conversational-leadership.net/quotation/know-more-than-we-can-say/ — сама цитата с контекстом

Парадокс Джевонса («дешевеет → спроса больше») по аналогии из экономики ресурсов. Аналогия рабочая, но это аналогия, а не закон для знания.
🔗 https://en.wikipedia.org/wiki/Jevons_paradox — что это за парадокс

Инженерная опора.
arXiv, «Interface-Induced Trajectory Censoring» (2609.03966). Наблюдаемое поведение — свойство всего стека «модель + обвязка», а не самой модели. Поэтому ценность разработчика уходит в харнес.
🔗 https://arxiv.org/abs/2609.03966 — препринт

«От себя»:
• «граница кодификации» как рабочий рубеж;
• «tacit-остаток» — то, что остаётся человеку;
• verifier-as-gate — человек, отвечающий за то, что модель не проверит сама.

Ваша дизайн-система готова к AI🤖? Скорее всего, нет 🤓

Последнее время много говорят про AI, который сам собирает интерфейсы: агенты ходят в Figma или другие инструменты для дизайна и разработки, пишут код, используют компоненты дизайн-системы — красота.

Но тут есть одна неприятная деталь.

Большинство дизайн-систем написаны для людей. Не для машин.

Человек открывает документацию, смотрит на компонент, читает пару примеров и довольно легко достраивает недостающий контекст:

• зачем этот компонент существует;
• когда использовать его, а когда другой;
• какие комбинации допустимы;
• где правило жёсткое, а где можно отступить;
• почему вообще система устроена именно так.

AI этого контекста не «понимает» автоматически.

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

И вот здесь, кажется, появляется следующий уровень зрелости DS — AI Readiness.

Я бы описал его примерно так:

AI-ready Design System — это система, которую AI может найти → понять → правильно применить → собрать → проверить → изменить, не разрушая её правил.

То есть библиотек компонентов и гайдов для людей уже недостаточно.

Нужны machine-readable знания:
Components + Semantics + Composition Rules + Constraints + Validation.

Не просто Button / Primary / Large, а:
зачем Primary существует → когда его использовать → когда нельзя → с чем он может сочетаться → какие правила MUST, какие SHOULD, а где продукту дана свобода.

И тогда меняется сама роль дизайн-системы.
Component Factory → Knowledge System → Decision Infrastructure.

Особенно интересен последний переход.

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

Когда решения начинает принимать AI, неформализованное правило фактически перестаёт существовать.

Поэтому парадоксально, но AI не уменьшает значение дизайн-систем.
Он делает хорошую дизайн-систему ещё важнее.

Потому что узким местом постепенно становится уже не скорость реализации.
Implementation → Decision Quality.


Я попробовал разложить AI Readiness дизайн-системы от Human-only до Agent-native на картинке выше 👆

Вот такой получился материал на основе текущих появившихся практик, уверен этот образ еще будет меняться.

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

Одна дизайн-система ≠ одинаковые продукты 🧩

Продолжаем серию постов про дизайн-системы и AI

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

Получаются две крайности:

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

2. Каждый продукт делает своё
Появляются локальные компоненты, паттерны, мини-дизайн-системы – и одна и та же задача решается много раз.

Но между этими крайностями есть ещё один слой:

Enterprise DS → Domain Platform → Product

Enterprise DS хранит то, что действительно универсально: токены, базовые компоненты, accessibility, semantics, фундаментальное поведение.

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

А Product оставляет себе то, что действительно делает его продуктом.

При этом это даже не обязательно строгая иерархия.

Продукт может одновременно использовать Enterprise DS напрямую + Domain Platform + собственный custom layer.

Поэтому мне нравится простое правило:

Универсальность определяет высоту слоя.

Чем больше продуктов выигрывает от решения – тем выше ему место.

Чем сильнее решение зависит от конкретного контекста – тем ближе оно должно оставаться к продукту.

И Domain Platform в этой модели – не вторая дизайн-система.

Это слой повторного использования между общей системой и конкретными продуктами.

И тут появляется интересный эффект AI.

AI сильно удешевляет создание локального решения.

Казалось бы, значит общая система становится менее важной.

Но может произойти наоборот:

AI ↓ стоимость локальной реализации → локальных решений ↑ → фрагментация ↑

Поэтому в AI-мире вопрос уже не только:

«Можем ли мы быстро это сделать?»

А скорее:

«На каком уровне это решение должно жить?»

Быстро сделать ≠ дёшево поддерживать 💸

Продолжаем серию про дизайн-системы и AI.

В прошлом посте был вопрос: на каком уровне должно жить решение – в общей дизайн-системе, доменном слое или продукте?

На него легко ответить, если смотреть только на разработку первой версии:

«Нам это нужно сейчас. Сделаем локально – так быстрее».

Особенно с AI. Он помогает быстрее собрать компонент, экран или целый сценарий.

Но стоимость решения не заканчивается в момент, когда оно заработало.

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

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

Поэтому выбор слоя – экономическое решение.

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

Поднимать выше – то, что повторяется в нескольких продуктах, решает одну и ту же задачу и может развиваться по общим правилам.

Но считать стоит не только число копий.

Важно спросить:

– одинаковую ли задачу они решают;
– сколько стоит поддерживать их по отдельности;
– сколько будет стоить общий контракт;
– кто сможет им владеть.

AI меняет скорость появления решений, но не отвечает на эти вопросы за нас.

Возможно, теперь проверять гипотезу локально станет проще. А вот момент, когда локальное решение пора сделать общим, придётся определять внимательнее.

Иначе мы быстро создадим много хороших решений, которые вместе окажутся дорогой системой.

Консистентность ≠ одинаковость 🧩

Продолжаем серию про дизайн-системы и AI.

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

Что-то должно жить на уровне всей компании, что-то – домена, а что-то вполне нормально оставить внутри продукта.

Но тогда возникает вопрос:

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

Мне нравится смотреть на консистентность не как на требование «везде должно быть одинаково», а как на несколько уровней правил.

MUST – то, что нельзя нарушать.

Доступность, семантика, базовые токены, критичное поведение компонентов.

SHOULD – то, что желательно переиспользовать.

Стандартные компоненты, общие паттерны, привычные способы взаимодействия.

MAY – управляемая вариативность.

Например, плотность, композиция, некоторые доменные особенности.

FREE – пространство продукта.

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

Получается, цель дизайн-системы – не сделать все интерфейсы одинаковыми.

Скорее сделать так, чтобы пользователю не приходилось без причины переучиваться, а командам – заново принимать уже принятые решения.

И здесь полезен довольно простой вопрос:

создаёт ли это различие ценность?

Если нет – скорее всего, стоит унифицировать.

Если да – возможно, его нужно сохранить.

Если пока непонятно – оставить локально, проверить и посмотреть, повторится ли решение где-то ещё.

С AI эта граница становится ещё интереснее.

Агенту недостаточно дать библиотеку компонентов. Ему нужно объяснить:

– что обязательно;
– что рекомендуется;
– что можно менять;
– а где у него вообще есть свобода.

Иначе AI будет либо механически делать всё одинаковым, либо каждый раз изобретать интерфейс заново.

Поэтому правила дизайн-системы постепенно становятся не только документацией для дизайнеров и разработчиков.

Они становятся ограничениями, внутри которых решения могут принимать и люди, и AI.

И, возможно, хорошая консистентность – это не когда всё одинаковое.

А когда каждое различие появилось не случайно.

Наткнулся на сайт AI UX Playground (aiuxplayground.com) — справочник по UX для AI-продуктов. Делает команда Bestfolios.com.

Что там есть:
• 150+ UX-паттернов с живыми демо
• 46 разборов ChatGPT, Claude, Perplexity, Gemini
• 148+ skills (SKILL.md) для Cursor и Claude Code
• 200+ промптов, 17 воркфлоу
• 57+ живых референсов
• Гайды и глоссарий

Доступ бесплатный, без регистрации. Полезно дизайнерам, продактам и дизайн-инженерам, которые работают с AI-интерфейсами.

🔗 https://aiuxplayground.com

Вместо обычного поста сегодня это: мне написали и попросили одобрить публикацию (по мотивам моего поста про Decision Record) в одном весьма популярном ИТ-канале билайна bee.tech, за что ребятам огромное спасибо. Ну собственно вот она 👉👈

Миграция на новую дизайн-систему – не кнопка «обновить всё» 🧭

Продолжаем серию про дизайн-системы и AI.

Мы уже обсудили, где должно жить решение, сколько стоит его поддерживать и почему консистентность не требует одинаковых интерфейсов.

Теперь вопрос: как переводить существующие продукты на новую версию системы?

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

Один продукт может быстро заменить базовые компоненты. У другого на старой версии завязаны сложные сценарии, собственные паттерны и привычное пользователям поведение. Формально перевести оба – совсем не одна и та же задача.

Поэтому перед миграцией я бы собрал для каждого продукта короткий паспорт:

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

После этого появляется выбор маршрута.

Перейти целиком, если изменений немного и они хорошо проверяемы.

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

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

Пока оставить прежнюю версию на поддержке, если риск перехода выше его ожидаемой ценности.

Выбранный маршрут стоит проверить на небольшом, но показательном сценарии: собрать его на новой системе, пройти основные состояния, проверить поведение и оценить реальную стоимость работы. После пилота план может измениться – и это полезный результат. А для продукта, который пока остаётся на прежней версии, нужны понятные условия поддержки.

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

Старая версия тоже не исчезает по календарной дате. Для её вывода нужны достаточное покрытие новой системой, понятный путь для критичных продуктов и возможность поддержать тех, кто ещё переходит.

Миграция – это серия обоснованных решений о продуктах и сценариях. Общая система даёт маршрут и инструменты, а каждый переход подтверждается на практике.

Что знает ваш агент, кроме того, как выглядит кнопка? 🤖

Продолжаем серию про дизайн-системы и AI.

Допустим, мы дали агенту компоненты, токены, документацию и правила сборки. Он использует нужные кнопки, соблюдает отступы, не придумывает лишние цвета.

А потом просим: «Собери дашборд для обработки заявок».

Получаем знакомую картину: несколько карточек с цифрами, график и таблицу. Всё аккуратно. Но почему именно эти показатели? На что смотреть в первую очередь? Что делать, если число выросло?

Из библиотеки компонентов это не узнать.

🔎 Возьмём карточку «Заявки в ожидании: 24».

Чтобы её нарисовать, достаточно названия, значения и компонента карточки.

Чтобы она помогала работать, нужно понять:

кто на неё смотрит и за что отвечает;
– какие заявки считаются ожидающими;
– 24 – обычная ситуация или уже проблема;
– важнее общее количество или время ожидания;
– какое действие доступно пользователю;
– что показывать, если данные ещё не пришли.

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

🎯 Здесь и появляется intent – зачем этот элемент нужен в конкретном сценарии.

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

Часть – описание проверенного паттерна: как устроена рабочая очередь, какие состояния нужно предусмотреть, когда уместна сводка.

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

🧪 Мне кажется, полезно проверять «готовность к AI» на одном небольшом фрагменте интерфейса.

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

Потом посмотрите: агент получил эти сведения или ему досталось только описание внешнего вида?

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

AI удешевляет создание. Почему дизайн-система все равно может стать дороже? 🤖

Представим пять команд, которым нужен DatePicker. Раньше кто-то взял бы готовый компонент, а кто-то долго делал бы свой. Теперь каждая команда может быстро попросить AI собрать вариант под её задачу.

Через неделю у нас пять работающих DatePicker. И, возможно, все пять по отдельности вполне хороши.

А потом начинаются вопросы. 🔎

Какой из них соответствует общим правилам? Одинаково ли они работают с клавиатуры? Что произойдёт, когда изменятся требования к доступности? Кто обновит все пять версий? И какие различия между ними действительно нужны продуктам?

AI сократил время на первую реализацию. Время на ответы он сам по себе не сократил.

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

Это не аргумент против локальных решений. Иногда свой вариант нужен, и быстро проверить его – большое преимущество.

Но я бы разделял две стоимости: ⚖️

Сделать решение – собрать первую работающую версию.

Владеть решением – проверять, обновлять и понимать, почему оно отличается от остальных.

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

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

DSaaP! Дизайн-система как живой продукт 🧩

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

Команде нужен сценарий, которого в ДС нет. Она находит локальное решение. Через месяц другая команда решает похожую задачу по-своему. В библиотеке ничего не изменилось, а в продуктах уже появились два новых паттерна.

Поэтому мне нравится смотреть на ДС как на продукт, у которого тоже есть пользователи: дизайнеры, разработчики, а теперь ещё и AI-агенты. Важно понимать, где им помогает система, а где они вынуждены её обходить. 🔎

Для этого нужна постоянная обратная связь:

- Где команды спотыкаются?
- Какие решения повторяются?
- Что работает в реальном продукте, а что хорошо выглядело только в макете?
- Какие правила пора уточнить?

Ответом не всегда будет новый компонент.

- Иногда нужен пример в документации.
- Иногда – изменение поведения существующего компонента.
- Иногда локальное решение стоит сделать общим. А иногда оставить локальным и объяснить почему.

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

Иначе ДС постепенно превращается в каталог того, что когда-то решили сделать. А команды продолжают решать сегодняшние задачи рядом с ней.

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

Уже второй, пост у коллег, класс, мне приятно