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

В работе Expectation vs Reality in Users’ Willingness to Delegate to Digital Assistants создается модель «готовности делегировать»: определены основные «переменные» и причинно-следственные связи.

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

Теоретическая модель на основе изученной литературы

Модель на основе проведенного исследования и применения математического аппарата

Ключевые тезисы и рекомендации

Завышенные ожидания пользователей от ассистентов

1. Чем проще работа с ассистентом, тем выше желание делегировать ему задачу (или как минимум попробовать)
2. При этом, чем больше человек пробовал работать с агентами, тем меньше желание делегировать (видимо, столкнулся с негативным опытом и понял ограничения)

Выводы отсюда очевидные: работать над качеством, менеджить ожидания, более сдержанно давать обещания

Процесс работы ассистентов не прозрачен, а контроля практически нет

Чем важнее задача, тем меньше желание делегировать. Так как нет доверия к системе, то и делегировать «субъективно рисковые» задачи не хочется. Даже если пользователь думает, что агент мог бы быть полезен.

Чтобы повысить шанс допуска агентов к более сложным задачам со стороны юзера, нужно:

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

Полезность ассистентов возрастает, когда человеку сложно выполнить задачу, но при этом увеличивается и субъективная сложность работы

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

Частотность сценариев работы ассистента не связана с субъективной полезностью, но повышает доверие к системе

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

Ссылки

1. Краткая видео-презентация и слайды
2. Научная работа
3. Сайт автора работы

Когда я обсуждаю с сотрудниками потенциальные пути развития, то часто вспоминаю статью Staff archetypes от Уилла Ларсона. Автор — опытный IT-шник, который побывал как в управленческих должностях, так и в роли исполнителя.

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

В тексте вводится понятие архетипов, которые построены на основе десятков интервью с релевантными людьми на этих ролях. Он составил четыре портрета экспертов, которые встречаются в бизнесе:

1. Техлид формирует техвидение, стандарты, практики, растит лидеров, выстраивает устойчивую систему принятия решений. «Свой парень на деревне», т. к. глубоко погружен в предметную область, заработал авторитета у руководителя и коллег.
2. Архитектор задает общий вектор движения технологического стека организации или нескольких связующих центральных технологий, чтобы это было экономически целесообразно на долгой дистанции. Может писать код, а может и не писать.
3. Решала — это спецназовец, которого можно кинуть в любую «горящую точку» в бизнесе и с высокой вероятностью он поднимет с колен вверенное направление. Зачастую, долго не будет задерживаться на спасенном проекте и его перекинут тушить пожар в другом месте.
4. Десница короля — «правая рука», персональный консультант лиц принимающих решения. В целом, из них можно сделать менеджеров в любой момент, т. к. у них много операционного влияния и стратегического контекста, который помогает строить роудмап.

Классификацию Уилла можно представить иначе и разложить архетипы по двум осям:

1. Фокус: Операционка ↔ Долгосрочное видение
   Насколько человек сфокусирован на...
   • непосредственном выполнении/доставке результата: разруливать конкретные проекты, доводить до прода, устранять блокеры здесь-и-сейчас
   • формировании направления: стратегии, задавать технический вектор, принципы, долгосрочные ставки, выбор “куда идти”.

2. Способ донесения ценности: Сам ↔ Через людей
   Насколько влияние достигается через...
   • личный вклад: глубоко копать, проектировать, писать код, быть “экспертом, который делает”
   • других людей и систему: выстраивать процессы, согласовывать между командами, строить коалиции, создавать условия, чтобы другие команды успешно работали.

В разные периоды жизненного цикла продукта/бизнеса нужны разные люди.

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

Почитать подробнее можно в оригинальной статье.

Конспект лекции от Фила Купмана

Чтобы охватить надежность «воплощенных» ИИ-систем с разных сторон, нужно разобраться в четырех областях:

1. Системная безопасность / теория надежности
2. Кибербезопасность
3. Машинное обучение / искуственный интеллект
4. Человеко-машинное взаимодействие (Human-Computer Interaction, HCI)

Ключевые вопросы

1. Что такое допустимый/приемлемый риск?
2. Какие актуальные вопросы стоят в индустрии?
3. Переопределение и развитие системной безопасности в контексте интеллекутальных систем

Люди совершают ошибки, но и компьютеры тоже

Концепты системной безопасности

1. Задача — снижение рисков. Нужны методы...
   • Определения угроз и рисков
   • Снижение рисков и валидации принятых мер
2. Технологисекие аспекты
   • Резервирование систем для повышения отказоустойчивости
   • Соответствие стандартам
   • Проектирование систем безопасными, а не только тестирование на безопасное поведение
3. Создание рабочей среды / культуры, где инструменты обеспечения безопасности реально используются, а не просто существуют для галочки

Анализ рисков

Риск = Частота * ТяжестьПоследствий

Простaя таблица рисков 2х2, которую используют для подобного анализа:

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

Safety Integrity Level (SIL) — это уровень полноты безопасности, стандартизированный показатель, который количественно оценивает надёжность систем, предотвращающих аварийные ситуации.

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

SIL и требуемые меры проработаны во многих промышленных стандартах, но они только формируются для робототехнических / «вопрощенных» систем.

Вызов №1 — только негативные случаи имеют значение

Метрики надежности могут выглдяеть как:

• «99.999.999 vs. 99.999.998 км без инцидентов»
• «1 vs. 2 инцедента на 100.000.000 км»

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

Как следствие — единичная короткая поездка ничего не говорит о надежности системы.

Вызов №2 — редкие и тяжкие события

Какой уровень риска у событий с околонулевой вероятностью, но тяжелейшими последствиями?

zero probabilty * infinity cost = ???

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

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

Один из ярких инцедентов в 2023г привел к закрытию бизнес-направления (см. дело Cruise https://en.wikipedia.org/wiki/Cruise_(autonomous_vehicle) )

Тем не менее, в 2025-м году General Motors возобонил проект и нанимает команду
https://www.bloomberg.com/news/articles/2025-08-11/gm-plans-renewed-push-on-driverless-cars-after-cruise-debacle
https://www.businessinsider.com/gm-hires-former-tesla-exec-ronalee-mann-self-driving-cruise-2025-12

Кибербезопасность

1. Целостность и доступность

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

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

3. Физический доступ к устройству
Злоумышленник может подключиться к eAI систете и провести более сложные манипулации, нежели с удаленным сервером.

ML

1. Обучается по примерам и отталкивается от статистики, вероятностей, частотности
   • Модели не закладывают фундаментальные законы работы мира
   • [прим. АМ] для роботехники разрабатываются специальные модели, которые имеют представление о законах физики и причинно-следственных связей, но на уровне научных исследований
   • Машинное обучение несовместимо с Vee-моделью создания надежных технических систем.

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

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

Тут видимо идейно про то, что нельзя сделать ТЗ для конкретных микро-фичей и ожидать корректность работы всей системы. Нельзя решить задачу надежности для ML в общем виде

Что с этим делать? Уходить от абстрактной задачи обеспечения надежности к более конкретным. Проектировать дизайн эксперемента (датасеты и критерии успеха) так, чтобы можно было аргументированно рассказать почему разработчик системы считает, что это повышает надежность.

Human & eAI Safety

Человек плохо подходит для рутинной задачи контроля почти идеального автопилота

1. Perception-Response Time (PRT)

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

2. Ирония автоматизации удленяет PRT
   • больше автоматизации ведет к меньшей практике людьми => во время отказа системы, у оператора может не хватить квалификации для своевременного принятия верного решения
   • предвзятость в пользу автоматизации (automation bias) — люди склонны доверять решению специализированной системы, а не себе. особенно, если система долгое время работает корректно
   • чем дольше система работает корректно, тем больше человек ей доверяет и тем сложнее быстро вмешаться, когда что-то идет не так
   • Ирония: чем эффективнее автоматика тем менее эффективен процесс контроля за ней со стороны людей

Этическая и юридическая проблема

1. Кто отвественен за некорректное поведение eAI системы?

2. Перекладывание отвественности на человека, не делает систему надежнее и безопаснее.

Moral crumple zone («моральная зона смятия») — концепция, описывающая ситуацию, когда человек становится «буфером ответственности» в сбоях сложных автоматизированных или автономных систем.
Термин построен на аналогии с зоной смятия в автомобиле (энергопоглощающей частью кузова, которая деформируется при ударе, защищая пассажиров). В социотехнических системах «моральная зона смятия»: «поглощает» вину за сбой системы;
перекладывает моральную и юридическую ответственность на человека‑оператора;
защищает репутацию и целостность технологии/организации, жертвуя репутацией или правовым положением человека.
Понятие предложил исследователь Мэдлин Клэр Элиш (Madeleine Clare Elish) в работе «Moral Crumple Zones: Cautionary Tales in Human‑Robot Interaction» (2019). Она показала, как медиа и юридические системы часто упрощают причинно‑следственные связи, делая человека «удобным» виновником.

Известные проблемы...

...которые видны за последние годы пилотных запуском

1. Ложные срабатывания систем безопасности автомобиля

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

2. Непредсказуемость работы системы

• Какие гарантии, что система поведет себя точно так же в такой ситуации? Зачастую поведение недетрменировано, а ситуации хоть чуть-чутьт да различаются.
• Сколько раз система должна пройти тестовый сценарий, чтобы убедиться в корректности работы? Хватит ли одного раза? Десяти? Тысячи? Миллиона?

3. Статистический подход при работе с надежностью

• Технические метрики для ML-систем в районе 90%-99% это супер-круто
• Но в задачах надежности нужны 99.9999999...% . Какие подходы могут добиться этих значений при обучении моделей?

4. «Длинный (бескончный) хвост» редких и необычных случаев

• Как построить надежную eAI-систему, которая не может физически быть обучена на всех видах ситуаций?
• Нужен человеческий бекап + система должна понимать когда она не может работать

Безопасность — это не только про травмы и смерти, но и про неадекватное (рисковое) поведение.

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

Социальные риски из будущего

1. АТ может быть в среднем безопаснее, но иметь явный паттерн рискового поведения. Это ОК или НеОК?
2. АТ приоритезириует безопасность людей в салоне относительно людей на улице.
3. АТ может быть законопослушным, но что если другой участник движения нарушил ПДД и это сподвигает АТ нарушить ПДД, чтобы избежать рисковой ситуации? (механизм компенсации)
4. Роботакси теоретичеки может не закончить поездку до конца и высадить пассажира в «плохом районе в плохое время».

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

Юридические аспекты

Duty of Care for Human (осторожное поведение / забота)

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

2. Пренебрежение этих норм можно описать как халатное поведение

Duty of Care for Computers

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

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

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

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

Запутывающий слоган

Обратная сторона тезиса «автопилоты спасают жизни». Нужны другие слоганы

1. Чтобы это доказать надо миллиарды киллометров
2. Медийка не даст времени, чтобы это доказать.
   • Любой прецидент будет использован, чтобы поставить под сомнение основной тезиc
   • Люди воспринимают истории, а не статистику
   • Фотка с ДТП имеет большой эффект наглядности, который будет бить любую статистику

Лидеры прошлого десятилетия с высокой вероятностью не будут хорошими лидерами в новом

(не все готовы менять подходы и/или не успевают учиться)

Избранные слайды

Делать то что?

1. Находить время и силы на адаптацию к трендам.

2. Развивайте «вкус».

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

3. Ну и т. к. про инжиниринг — прогайте. Например автор доклада как раз описывает свой недавний опыт в качестве СТО, но который стал делать много PR из-за доступных технологий-ассистентов. https://lethain.com/coding-at-work/

The new wave of AI tooling like Claude Code or OpenAI Codex are extremely susceptive to creating low-quality commits, but my experience is that used effectively they also provide several opportunities for creating useful code contributions are well. > > They are effective at:

1. answering questions into a codebase, e. g. “what are our most common patterns for working with authn and authz? what are good examples of each?”
2. writing code that fits the existing codebase’s patterns and structure, particularly with a well-written AGENTS.md’s guidance
3. taking general feedback to revise the approach, e. g. “look for existing utilities that solve date math within our codebase and reuse those”
   Most importantly, you can do each of those in a few minutes at a time. Between meetings at work, I generally pop back into one of several Claude Code sessions to see where it got to on a given task, review the code, and suggest next steps.

It’s worth acknowledging that there’s a significant learning curve to doing this well. I’ve spent a meaningful amount of time in the last year learning to write software this way, and each month there are new caveats that I’ve had to understand. Slowly but surely, I’ve built a mental model of both how writing software with AI works, and how Imprint’s codebases work.

Ссылки

1. Статья «Good engineering management» is a fad
2. Весь набор слайдов
3. Презентация на YouTube

Недавно коллега из роботов-доставщиков рассказал историю про раскапывание причины падения метрики.

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

Снарядили отряд аналитиков для выявления причины. Первая гипотеза — проблема где-то в приборах измерения. Проверили всё: поставку данных, ETL, формулы, код, дашборды.

Нареканий нет, всё корректно.

Вторая гипотеза — видимо, что-то меняли, но что? Релизов софта не было в момент наблюдения спада метрики.

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

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

So What?

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

Вот какие тренды намечаются... ИМХО, касается всех продуктовых ролей.
Источник: Why I’m Giving Up My Design Title—And What That Says About The Future of Design

—-

Сафф Сайед решил отказаться от должности Head of Design и перейти к роли технического специалиста в области ИИ. .loud По его словам, дизайн давно не успевает за прогрессом и перестал быть движущей силой индустрии.
Тем, кто хочет оставаться значимым, придётся менять профиль своей деятельности.

Главное из статьи:

1. С появлением агентных систем и стремительным развитием ИИ акценты сместились в сторону инженерии, организации работы моделей и построения инфраструктуры для них
2. Эпоха агентных систем меняет парадигму самих продуктов. Интерфейсы будут генерироваться динамически, что делает статичный UI и роль классического продуктового дизайна менее актуальными
3. Новый подход потребует совершенно иных навыков и инструментов, которые сильно отличаются от тех, что дизайнеры использовали раньше
4. Дизайн почти никогда не определяет инновации. Ключевые открытия происходят в инженерии и продукте, а дизайн остаётся поддерживающей силой
5. Лидеры в новой реальности — это не руководители больших команд, а люди, способные самостоятельно и быстро запускать решения с помощью ИИ
6. Современные инструменты и библиотеки сделали качественные интерфейсы и UX доступными для всех, а значит, они больше не дают решающего преимущества
7. Сегодня инженеры-одиночки в области ИИ получают сверхвысокие зарплаты, потому что могут выполнять действительно важную и коммерчески ценную работу за целые отделы. На этом фоне дизайн обесценивается
8. Будущее за специалистами «на стыке», которые понимают и устройство ИИ-систем, и опыт пользователей и могут встроить ИИ в продукт без упрощения до чата

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

Сегодня я услышал любопытные слова:

Любая истина проходит через три этапа: сначала её высмеивают, затем яростно отрицают, а затем воспринимают как нечто очевидное.

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

Пока искал, повстречал много ИИ-галлюцинаций, которые приписывали авторство то героям в романе Достоевского, то главе Microsoft, то философам из какого-то цитатника афоризмов СССР.

Но, как нечасто бывает, искал медь, а нашел золото. Добрый человек из Department of (!) Computer Science at University of Waterloo проделал работу за меня, но тоже так и не понял конкретного автора: https://cs.uwaterloo.ca/~shallit/Papers/stages.pdf

С удовольствием прочитал эту небольшую работу и узнал много интересного исторического контекста, в котором развивались «три стадии истины».

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

Как сказал Уильям Эдвардс Деминг, американский учёный, статистик и консультант по менеджменту:

In God we trust; all others must bring data