У меня начался новый учебный год и сегодня были первые лекции.

Честно говоря, мой предмет «Дизайн в цифровой среде» позволяет двигаться в самых разных направлениях, и пока я обозначил для себя такие планы:

Генеративный ИИ и прототипирование. Мы будем уделять больше внимания генеративным моделям и созданию продуктовых прототипов. В качестве рабочей платформы, скорее всего, возьмем Lovable — у них новые токены доступны каждый день, что удобно для учебной работы.

AR и новые формы интерфейсов. Я убежден, что дизайнер — это не тот, кто делает интерфейсы, а тот, кто способен создавать новое. Поэтому попробую выйти за рамки привычных для себя решений и поговорить об AR: его истории, текущем развитии и возможностях. Если найду достаточно простое технологическое решение, то мы даже попробуем что-то поделать своими руками. В Unity AR Foundation или Unity MARS пока погружаться не готов — это для меня слишком новая область, и хочется начать с малого.

Партнерство с бизнесом. Хочу привлечь Совкомбанк как партнера для студенческих кейсов. Идея выглядит немного утопичной: студенты — непредсказуемы, банк — консервативен. Но о встрече я уже договорился, и надеюсь, мы найдем способ это запустить. Мне кажется, что крупному бизнесу стоит активнее идти в образовательные проекты, потому что причин и пользы для этого достаточно. А я вот становлюсь проводником такой возможности.

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

Вести с полей вайбкодинга. Для меня появление инструментов генерации кода имеет еще одну любопытную сторону.

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

С переходом в Figma многое упростилось… и потерялось. Да, интерактивность осталась (хоть и упростилась), но редко кто открывает макеты в реальном размере браузера. Чаще всего их просматривают внутри Figma, и уже здесь возникает дистанция между проектом и опытом пользователя. Так не у всех, конечно, но я слишком часто такое наблюдаю. Особенно часто такое встречаются в B2B-продуктах, решения, которые в реальности выглядят странно и непродуманно. Там пользователи обычно уже привыкли пользоваться тем, что дают, лишь бы работало.

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

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

p.s. В иллюстрациях продолжение моих экспериментов.

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

И вот отличный кейс от Khyati Trehan https://x.com/KhyatiTrehan/status/1963957981642416345

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

Что ценно в этом примере:
- ничего лишнего и никакого перегруженного функционала;
- свежий взгляд на привычную тему;
- LLM встроена в процесс органично и незаметно для пользователя;
- и, конечно, приятная визуальная подача.

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

Про новое SEO. Я еще для себя не определился, какой термин стоит использовать: GEO (Generative Engine Optimization), AEO (Content Portfolio Strategy) или какой-то другой. Думаю, что в итоге закрепится только один вариант. Но сути это не меняет: под AI-запросы все равно придется проводить специальную работу по оптимизации, если хочется оставаться в поле видимости пользователей.

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

Новое исследование Omnisend показывает: пользователи, по крайней мере в США, все чаще обращаются к LLM для поиска и выбора товаров. И главное — находят этот процесс удобным. А это значит, что тренд будет только расширяться. По мере того как новые LLM-инструменты станут доступнее, они быстро охватят и другие страны.

В июле 2025 года Omnisend опросили 4000 взрослых из США, Великобритании, Канады и Австралии о том, как они используют ИИ при онлайн-покупках. Краткие выводы такие:

- около 50% онлайн-покупателей в каждой стране используют GenAI для e-commerce-задач хотя бы раз в месяц;
- каждый четвертый утверждает, что ChatGPT предлагает товары лучше, чем Google;
- около 27–29% отмечают, что AI делает процесс онлайн-шопинга менее утомительным.

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

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

Продолжаю эксперименты с V0. В записках у меня лежала идея проекта еще с 2012 года, для которого я тогда сделал пару набросков интерфейса. Сейчас подумал: а почему бы не попробовать собрать полноценный интерфейс и посмотреть, что из этого выйдет? Результат можно увидеть на видео.

Новые наблюдения из опыта вайбкодинга:

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

- Для мелких правок CSS я стабильно перехожу к ручному редактированию. Добиться точечных улучшений проще своими руками. А вот с непонятными для меня конструкциями работаю через ChatGPT: загружаю фрагменты и прошу написать правильный код по моим требованиям. Он может давать несколько вариантов решения, что не мешает, а иногда даже помогает. В целом, с задачами справляется хорошо.

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

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

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

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

Как делать проект в вайбкодинге. Сегодня я пробовал подход, когда сразу в проект загружаешь большой набор требований.

Для чистоты эксперимента я скормил один и тот же длинный промт нескольким платформам: V0 (с подпиской), Bolt, Lovable, ChatGPT и Figma Make.

Что получилось?

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

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

Lovable. Дал самый обнадеживающий результат с первой итерации. Вначале были технические ошибки, но платформа их сама исправила. Потом удалось изменить один из модулей через запросы, но проблемы с вводом текста и связями между узлами так и не решил (и это общая проблема для всех протестированных платформ у кого код на React). Рабочий прототип здесь.

ChatGPT. Решил использовать как инструмент вайбкодинга после разговора с Олегом Ващуком. Оказалось, что работа через чат, вполне рабочим вариантом. Хоть и не хватает некоторых сервисных функций, но того, что есть для экспериментов достаточно. Если говорить субъективно, то ChatGPT лучше держит контекст (возможно, за счет того, что лучше понимает русский язык), но тоже ошибается и не всегда хочет исправлять. Проект тут.
Figma Make. Результат удивительно похож на V0 (видимо, внутри та же LLM от Anthropic). Схожесть даже в структуре сохранения файла проекта. Визуально получилось приятно, но функционально без прорыва. Можно посмотреть здесь.

В качестве заключения

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

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

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

Это моя попытка собрать проект на базе Google AI Studio после экспериментов с другими системами. И, честно говоря, результат меня приятно удивил. Вышло так, что мне самому понравилось, а это уже показатель. Сегодня как раз расскажу о том, что получилось.

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

Поэтому я люблю ресурсы вроде researchgate.net или academia.edu. Там можно найти не только что-то доказательное и новое, но и работы прошлых лет.

Недавно наткнулся на курс по UX от Keith Andrews опубликованный в 2017 году — «Human-Computer Interaction». Вроде бы знакомые вещи, но все-таки одна иллюстрация зацепила своей новизной. Я раньше ее не встречал, и она оказалась удивительно для меня полезной.

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

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

Так что спасибо старым публикациям, за свежие идеи.

Собрал на Google AI Studio небольшой визуальный проект. Честно говоря, без конкретной цели, просто ради эксперимента: посмотреть, как поведет себя Gemini на странных запросах.

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

Но вот с чем я сталкиваюсь постоянно — это повторяющиеся ошибки вида «Minified React error #300...». И тут сразу видно, что React для меня темный лес. Влезать в его изучение только ради того, чтобы вручную разбирать такие баги — совсем не то, ради чего я затевал эксперимент.

Из жизни вайбкодинга: куда уходят кредиты в V0. Залез в статистику и посчитал, как тратятся кредиты в V0. Если смотреть на стоимость миллиона токенов, то V0 находится примерно на уровне средних моделей OpenAI и Anthropic. В конечном счёте, под капотом там работает Claude 3.5 (для больших запросов модели поновее), как сама сеть призналась в одном из моих запросов. Так что дешевле оно и не может быть.

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

Дешевые запросы:
- старт проекта без истории,
- стилистические правки в готовом проекте (но надёжнее делать руками),
- справочные вопросы без генерации кода.

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

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

David Kossnick из Figma написал о большом обновлении.
Похоже, оно сделает работу над дизайном еще проще.

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

С одной стороны — это экономия времени. С другой — кто теперь объяснит менеджеру, что это не просто два пикселя подвигать?

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

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

Материал умеет передавать текстуру объекта. Представьте, провел рукой по виртуальному камню и почувствовал шероховатость.

Больше о технологии в публикации Skin-attached haptic patch for versatile and augmented tactile interaction

Немного про стратегии клиентов. За последний месяц я столкнулся с несколькими клиентскими проектами, которые можно объединить по одному признаку — отсутствию стратегии развития.

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

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

В качестве отступления: у YC (еще со времени управления Сэмом Альтманом) есть хорошие лекции о том, как делать стартапы, и у Harvard Innovation Labs есть отличные материалы по этой теме.

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

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

Когда-то таких проектов было много по рынку, и казалось, что это уже в прошлом. Раньше с такими идеями ходили люди без бюджета и опыта, но с большими фантазиями. Сейчас, возможно, на волне AI-оптимизма, эту роль занимают компании с опытом (но не в IT), с деньгами, но без реалистичных планов.

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

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

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

На обложке один из слайдов лекции Майкла Скока (Michael Skok) про роудмап успешного стартапа.

Национальное бюро экономических исследований (NBER) опубликовало большое исследование об использовании ChatGPT в США. Данные собирали в течение длительного времени, и там много интересного.

Меня же зацепили два факта.

Первый: среди ранних пользователей ChatGPT преобладали мужчины. Возможно, это отголоски нашего «первобытного» инстинкта — первыми переться в незнакомую чащу. Но сейчас использование почти выровнялось по гендеру. А это может значить, что LLM уже стало привычной областью, которую приняло общество.

Второй: доля использования ChatGPT для программирования невелика — всего 4,2%. Почти столько же, сколько доля занятости в ИТ среди взрослых американцев (по разным оценкам — это около 2%). Получается, большие языковые модели уже стали универсальным инструментом, а не чем-то нишевым.

Доклад по ссылке How People Use ChatGPT

Использование LLM несет не только пользу, но и издержки.
Речь идет о двух исследованиях 2025 года «Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task» и «The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers».

Первое исследование изучало влияние LLM на студентов в процессе написания эссе. Оценивали как итоговые тексты, так и когнитивные изменения при помощи электроэнцефалографии и опросов. В результате оказалось, что постоянное использование LLM снижало нейронную связность, ослабляло память и снижало чувство авторства. Итоговые работы становились менее разнообразными и менее креативными. Зафиксированное снижение когнитивных способностей исследователи назвали «когнитивным долгом». Речь идет не о том, что люди «тупеют», но об устойчивом снижении вовлеченности и самостоятельности, что и показали результаты исследования.
Второе исследование проводилось среди работников, которые регулярно используют генеративные ИИ в повседневных задачах. Вывод похожий: при высокой уверенности в ИИ и низкой уверенности в себе уменьшается объем критического мышления. Люди начинают меньше времени тратить на решение задачи и больше времени на интеграцию решения в рабочий процесс. Такая перестройка процесса в долгосрочной перспективе может снижать способность к самостоятельному решению задач.

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

Немного про эффективность сотрудников и влияние состава команды на успех проекта.

Наверное не будет ошибкой сказать, что от качества команды зависит успех проекта. При этом реальную производительность измерить непросто. Поэтому придумывают множество метрик и методик (ревью, KPI, OKR и пр.). В свое время, меня особенно впечатлила презентация Construx Software , посвящённая индивидуальной эффективности программистов и влиянию организационных моделей работы на результаты.

Согласно классическим исследованиям, между лучшими и средними программистами есть огромная разница. Даже с учетом разных условий (языков, опыта, типа работы) разрыв остается значительным — от 5 до 10 раз. Есть обзоры, которые заявляют о еще большем разрыве.
Зато влияние методологии работы обычно намного скромнее. По данным Project Management Institute, при грамотном применении гибридного подхода (комбинация Agile, Waterfall и пр.) производительность проектов сравнима с любой отдельной методикой. Иными словами, удачные методики повышают эффективность, но в гораздо меньшей степени, чем разница между людьми. Обычно называют улучшение в пределах 20-40%.

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

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

Когда воображение не справляется с перегрузкой. Недавно наткнулся на исследование (The capacity limits of moving objects in the imagination) о том, как мы отслеживаем объекты в воображении. Суть исследования была проста, испытуемых просили представить окончания событий, которые они не видели целиком, событием были движущиеся объекты.

Оказалось, что люди довольно успешно предсказывают траекторию одного движущегося объекта. Но как только объектов становится два — скорость и точность предсказаний значительно падает. Похоже, мы можем стабильно удерживать в воображении только один подвижный предмет. А если предметов больше, то представляем их последовательно, переключаясь с одного на другой, что приводит к задержкам и снижает точность ответов.

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

Игровые интерфейсы? Возможно. Но думаю, там это давно известно на уровне эмпирики.

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

В итоге остаётся ощущение, что исследование скорее подтверждает то, что люди интуитивно знали давно.

О разнице между фактическим временем выполнения задачи и календарным временем проекта. Недавно работал над небольшой задачей. По факту ушло 9 часов чистой работы. По календарю - 22 дня.

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

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

На второй итерации прототипа я не стал тратить время на новую встречу, а записал видео с презентацией и разослал заинтересованным сторонам. Это ускорило сбор обратной связи. Были комментарии, под которые я сделал третью версию прототипа.

Здесь стоит отметить важную вещь: дизайн-решение - это почти всегда набор компромиссов. Я старался не ломать существующую дизайн-систему, но вследствии этого, в прототип просочились устаревшие решения. Это было одно из возможных решений, но не всем это нравилось. Потребовалась еще одна встреча, чтобы определиться с приоритетами - сохраняем дизайн-систему или делаем новые компоненты невзирая на сопутствующие издержки. Так прошла вторая неделя.

Четвёртую версию прототипа я сделал не сразу, пара дней ушла на другие задачи. В итоге, подготовил прототипы, записал видео с презентацией, разослал. Через два дня получил подтверждение: “Ок, забираем в работу”. Еще неделя.

В итоге: Задача решена. В эстимейт уложился (он был 2-12). Проект длился три недели, кажется, что не быстро, но никто не торопил. Команде придется доработать дизайн-систему под новые элементы: дополнительная работа для дизайнеров и разработчиков.

Общий результат по задаче не лучший, но, как по мне, вполне рабочий. Из выводов - нужно быть честным в оценке и учитывать не только “сколько займёт сделать”, но и “сколько займёт согласовать”.

Еще один простой эксперимент в Figma Make c вайбкодингом. Ничего конкретного, просто ради забавы. У меня на текущий результат ушло 13 запросов, в основном, чтобы уточнить физику объектов. Но, если вы захотите попробовать у себя такое сделать, то вот вам краткий промт:

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

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

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

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

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

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

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

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